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 >
