Re: content hacks in the pipeline
sure! and yes it makes much more sense in that direction! thanks for bringing this Le mar. 29 mars 2022 à 17:13, Julian Sedding 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 > 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 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 > > > 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 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 > > > 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 < > > > > > peltier.nico...@gmail.com>: > > > > > > > > > > > > > > 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
Re: content hacks in the pipeline
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 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 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 > > 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 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 > > 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 < > > > > peltier.nico...@gmail.com>: > > > > > > > > > > > > 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 >
Re: content hacks in the pipeline
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 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 > 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 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 > 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 < > > > peltier.nico...@gmail.com>: > > > > > > > > > > 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 > > > > > > > >
Re: content hacks in the pipeline
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 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 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 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 < > > peltier.nico...@gmail.com>: > > > > > > > > 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 > > > > >
Re: content hacks in the pipeline
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 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 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 < > peltier.nico...@gmail.com>: > > > > > > 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 > > >
Re: content hacks in the pipeline
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 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 : > > > > 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 >
Re: content hacks in the pipeline
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 : > > 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
content hacks in the pipeline
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
