Hi, so there are two levels to it:
1. how ultimately we decorate things up given a configured set of content hacks. I guess that decorator [2] plus yes something like [1] can help. Not sure how bad impact on performances would be though 2. how we configure those content hacks. I was initially thinking about annotations & headers, but i wonder if some tree of CA configurations would not be better, as it would fix already a lot of context specific questions. It would also allow to add/remove the hack by changing something more contentish than java code. Throwing this here to see if there is any more reaction from the community, and will soon start to work on a whiteboard draft. [2] https://sling.apache.org/documentation/the-sling-engine/wrap-or-decorate-resources.html Le jeu. 10 mars 2022 à 14:33, Julian Sedding <[email protected]> a écrit : > Hi Nicolas > > If you want to go with a decoration approach (whether it is via a > resource provider or decorator), a few classes I put into the > whiteboard a while ago might help [1]. I once used them to "mount" > repetitive and/or dynamic parts of AEM dialog definitions into a > static AEM dialog definition. > > Regards > Julian > > [1] > https://github.com/apache/sling-whiteboard/tree/feature/sling-resource-graft > > On Thu, Mar 10, 2022 at 10:55 AM Konrad Windszus <[email protected]> wrote: > > > > Hi Nicolas, anything which eases the process of content migration for > blue/green deployments will be highly appreciated. Hiding the differences > on the resource level sounds like a good idea although you probably have to > distinguish between read/write access. Looking forward to your proposal. > > Konrad > > > > > Am 10.03.2022 um 10:51 schrieb Nicolas Peltier < > [email protected]>: > > > > > > Hey, > > > > > > i've been discussing here & there several times about having sling > pipes in > > > a CI/CD pipeline as part of a new application deployment where content > > > handling changed substantially and application v(n+1) can't work with > > > content v(n). > > > pipes responsibility would be to handle the switch of content to > v(n+1). > > > > > > thinking/discussing about it, it does not sound right to me if there > is no > > > possibility to serve 2 versions of the content at the same time and to > > > quickly validate that everything is correct, as it ends up being non > > > validated code (pipe on specific prod content is new). > > > > > > The other alternative is to have code handling both versions of the > > > content, when no occurrence of the v(n) content is there anymore > (which can > > > be done by code, or accelerated eventually sling pipe execution), > switch to > > > a simpler version. To make that approach less expensive, i was thinking > > > about something at sling level (resource provider and decorator) that > would > > > help doing those things quicker, through some annotations. > > > > > > Any thoughts / feedbacks / concerns before i dig deeper ? > > > > > > Nicolas > > >
