Applications seem to be the core idea of Enonic XP - yet there is not a lot of information available in your documentation about them, nor how you use them. This is my plea to you to document this.
Yesterday, me and @bwe did a rewrite of your app-open-graph app for a project I am working on. We decided to use an app to decorate our main website with SEO fields instead of a mixin, since it would adhere to the separation of concerns principle, as well as make the SEO module usable in other contexts as well.
It was a great experience. We plugged and played and refactored and redeployed and everything worked pretty well. Cool feature, very well implemented and in general a good idea. So why aren’t you documenting apps and how to use them to your advantage??
I’m lucky enough to work for a project that can afford hiring in external resources like @bwe - and I’m very thankful for that. However - a lot of other projects are not that lucky (especially in the open source / not-for-profit communities), and may never understand the possibilities this application concept offers.
So please, please, PLEASE look into developing a “what are apps, what are they good for and how can they benefit you?” guide for us developers - we will thank you for it!
"Applications are basically containers of functionality and code, but may even include data - for instance to be imported when the application is started.
An application can have just about any kind of purpose. Sites for instance can be created from one (or more) applications."
This seems to be saying what you were looking for, and the different features are described in the following pages.
On another note: How did you plug-and-play the SEO-stuff? Using a part with pageContributions inserting the proper tags? Sounds like a great idea!
Hmm, I thought they had that in the old documentation as well, but I now realize that it is a new page. Oops!
I am a third-party developer myself, but I guess I figured this out either through the course or during the meetups.
I actually think the modules-concept used in 5.x explained this better, as it was obvious that you were meant to plug-and-play several modules for use in one page. However, with the new documentation, I guess this concern is now removed…
To be honest though, I don’t think this little 6-paragraph introduction to the general concept is good enough. It gives a very basic overview and the idea that an application “can be anything” - which isn’t much help. Give me ideas, concepts and how they can integrate with other applications!
Finally, it doesn’t address how to deal with inter-app dependencies - ie. how a site can depend on n applications to be present in order to function correctly.
Wow, cool way of doing it! I never realized filters could be used to add to page contributions. I’ll definitely have to give it a try this weekend…
As you have discovered - we are working to improve the documentation!
Thanks for letting us know what you think needs improvement, we’ll do our best to get more info here fore the 6.4 release.
New to us when testing some things out was how mixins added as x-data to site.xml were handled. We found out that it is indeed added to the entire sites app-stack and all of it’s content. This was very helpful when adding fields for overriding SEO data on a per content level.
Duplicate mixin names in different apps will however add multiple fields to content. It’s not a big issue as we discover it and work around it. But it would be nice to have some kind of “only add this mixin if it’s not already in place”. Especially with SEO mixin there could be an app only for SEO adding the same mixin as an app that only does Open Graph.
Some info around “what happens when we …” in Apps would be really helpful. And as @selbekk wrote, perhaps a list of a few example app setups (website.no - with Analytics App and SEO App to add extra functionality). App can extend other apps, not only be “just a site”, that’s the message we need others to pick up from reading about it.
Another example is Apps as a “content archive”, we used this on a website that has a public website, an intranet, and two blogs. The same staff is working on all these sites, but all sites are their own apps. Instead of adding a “staff”-app to all of them with a staff-Contenttype, we created the “shared content” site, added the “staff”-app, and created the content only there, then re-used it on all the other sites as related content.
Filters also worked like a charm, something I knew thanks to working at Enonic, but I thing we’re not getting that message out properly. That info could also be listed briefly on an app page in the docs with link to more info. As filters stacks on the current site, other apps can “hook into” everything that happens to seamlessly integrate into each other, without the need to add parts.
Bobby, since mixins are made into an integral part of an app, with unique names - there is no such thing as a duplicate! If two or more applications are constructed to “eat” the same properties you can create a third application that only contains the mixins and go from there - or build everything into a single app.
Finally - I very much agree on getting more examples that will demo possibilities and how. Look forward to Enonic Market
