Using light module development approach for front end leaves a couple of questions open in regards of: How to use it and distribute changes on life systems.
A main problems I see is:
- how to guarantie that the newest changes in light modules are distributed 100% equally trough all instances?
- how can a customer know which node has wich state of resources loaded? (How can I be sure public2 has the same resources as public1 or public3).
- When setting magnolia.develop=false changes in the light modules (file system) are detected, BUT the JS & CSS is still served cached. And we have no mechanism to flush the caceh on public instances (except activating something).
We could define a simple best practice approach:
They are observed & loaded & managed on the author, and distributed to publics as (JCR) CMS content via the publication mechanism.
Meaning that on the life public instances the resources are not loaded form a light module in the file system, but from a distribution over JCR.
- the author loads the light modules from the file system
- It provides a possibility to create a "live" set of it -> copy them into JCR repo.
This is in oposite to a "hot fix", its a recursive creation of the whole light module. Of all in it, not just one file.
Either all or none, not split-able (except by hot-fixing one singly).
- This "live" set would be published.
- A version of the whole tree would be created.
What it solves / advantages:
- All the main mechanisms we already have: Hot fixing for JCR copies. The loading cascading (classpath/filesyste/jcr), Publishing with transactional activation.
So not that much would have to be developed.
- On public its all within the CMS -> clone one public, you have it.
No need to think about the file system & resources in scope of public instances.
- Transactional activation ensures that its in sync on all publics.
- JCR versioning would provide:
- Clear knowledge of what was when active
- Possibility to roll back
- As its activation of content, Cache will automatically flush -> JS & CSS are re cached.
- Also simplifies for OnDemand, plugging in more Public nodes on the fly.
- It is not contradicting of using on life a file system approach., just remove the activation possibility on the author.
I see the chance of defining a convenient approach which can be easily be understood and sold.
A proper & clear "best practice", rather than that every customer needs to find a way to use it, even all they want is using it a simple/standard way..
And it is not restrictive to anybody, you can still use any file system based approach in combination with Git etc if needed.