Hi Nicolas I suppose it could also work the other way around:
- first define a way to describe content transformations that can be used for decorating resources (and yes, that's the hard part) - then integrate support for the same descriptions into Sling pipes That way you don't have to support everything Sling pipes supports these days with the decorator approach. But you could still avoid the need to duplicate the definition for two sub-systems. I agree that not all of this has to happen now. But thinking about it now might make it a lot easier to add support for such scenarios later. Regards Julian On Tue, Mar 29, 2022 at 4:55 PM Nicolas Peltier <[email protected]> wrote: > > Hi Julian > > didn't necessarily want to bind both of them even if i get your point: > having both"$ some/type | write foo=bar" and something saying more or less > the same (point 2 of my former mail) looks cumbersome, but it's also a good > first step to get both hacking & "masking" parts simple. > Having some later translation service can still be planned but wouldn't be > a priority imo. > > Nicolas > > Le mar. 29 mars 2022 à 16:21, Julian Sedding <[email protected]> a écrit : > > > Hi Nicolas > > > > Do you think it would be possible to "apply" a Sling pipes execution > > only via a decorator until after the blue/green deployment is > > completed. And only after that lazily "apply" the pipes execution to > > the persisted content? > > > > That's what I read into your initial email, and that would IMHO be > > more desirable than re-defining the same changes in a different way. > > Or maybe my misunderstanding is on a more fundamental level? > > > > Regards > > Julian > > > > On Mon, Mar 28, 2022 at 5:23 PM Nicolas Peltier <[email protected]> > > wrote: > > > > > > 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 > > > > > > > > > > >
