Uploaded image for project: 'Suggestion Box'
  1. Suggestion Box
  2. SUGGEST-14

LightModule resources distribution: Define a convenient best practice

    XMLWordPrintable

    Details

      Description

      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).

      My suggestion:
      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.

        Checklists

        Acceptance criteria

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                Unassigned Unassigned
                Reporter:
                cringele Christian Ringele
                Votes:
                3 Vote for this issue
                Watchers:
                10 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Date of First Response:

                    Checklists

                    DoD