sure! and yes it makes much more sense in that direction! thanks for bringing this
Le mar. 29 mars 2022 à 17:13, Julian Sedding <[email protected]> a écrit : > 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 > > > > > > > > > > > > > > >
