Re: Sling Declarative Dynamic Resources
Hi, I haven't really thought about this in detail but when the use case came up the first thing that came to my mind was to somehow hook into the servlet resolution mechanism. In some way the bundled scripts provide something similar, not exactly the same - but maybe it can be built in the same way. But as said, I haven't really looked into it and I guess this needs some more thinking :) Regards Carsten Am 27.04.2021 um 00:03 schrieb Andreas Schaefer: Hi Carsten Ruben told me that you think that this can be accomplished with a change to the Servlets Resolver. I am not sure how that would work as a servlet is driven by its resource type , extension etc. This in turn would mean that each child entry would need to adhere to that as well. - Andy On Apr 22, 2021, at 10:31 PM, Carsten Ziegeler wrote: Thanks Ruben, in my opinion /apps belongs to developers. In our case its immutable for good reasons. Drilling a hole into this and allowing non developers contribute to /apps, especially in a dynamic fashion circumventing the immutability sounds very risky and can result in security problems. I understand that extra configuration options are added to partially address this, but then it comes down to how effective these are and what holes they might have. Now, in general I'm not against a feature like dynamic resources - but making something immutable mutable especially for a different audience is too dangerous. Regards Carsten Am 22.04.2021 um 18:27 schrieb Ruben Reusser: Carsten, see inline On 4/22/2021 6:55 AM, Carsten Ziegeler wrote: Am 21.04.2021 um 15:30 schrieb Ruben Reusser: - for each website that is created we have to create a corresponding /apps folder for rendering purposes I assume the ddr solution is temporary and eventually the information is added to /apps directly? In this case I would do that immediately. we try to live in a composite nodestore world where /apps is not writable - so no, we can't write to apps when creating a website - we also want to give editors a certain control over group names, labels and the component variations an editor can pick from when creating a page That sounds as if that is part of content not stored in /apps? the default node structure we want to create if a user adds a component to a page is currently under apps but we would like to keep it somewhere in /content in the future our big motivation for DDR is to make authoring and maintaining a website less dependent on developers and allow for better customization options after the initial effort to build a site has been completed. Carsten Ruben -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling Declarative Dynamic Resources
Sling does not mandate anything to be mutable or immutable. Products build on top of Sling however might do. Ruben has noted that the solution he is working on is immutable with respect to /apps and ours is, too. That is for production systems - not development systems. As noted, a mechanism like proposed here (or the superimposing one) makes sense to me in general. But in my opinion it creates problems with solutions having parts immutable. Again that's of course a decision everyone can make for themselves. Still my suggestion for everyone having an immutable part in the repository would be to look for a less intrusive solution Regards Carsten Am 27.04.2021 um 01:06 schrieb Cris Rockwell: Where are the docs about making apps completely immutable? Sounds like it would be huge pain to be a site (customer) developer for a system like that. On Fri, Apr 23, 2021, 1:32 AM Carsten Ziegeler wrote: Thanks Ruben, in my opinion /apps belongs to developers. In our case its immutable for good reasons. Drilling a hole into this and allowing non developers contribute to /apps, especially in a dynamic fashion circumventing the immutability sounds very risky and can result in security problems. I understand that extra configuration options are added to partially address this, but then it comes down to how effective these are and what holes they might have. Now, in general I'm not against a feature like dynamic resources - but making something immutable mutable especially for a different audience is too dangerous. Regards Carsten Am 22.04.2021 um 18:27 schrieb Ruben Reusser: Carsten, see inline On 4/22/2021 6:55 AM, Carsten Ziegeler wrote: Am 21.04.2021 um 15:30 schrieb Ruben Reusser: - for each website that is created we have to create a corresponding /apps folder for rendering purposes I assume the ddr solution is temporary and eventually the information is added to /apps directly? In this case I would do that immediately. we try to live in a composite nodestore world where /apps is not writable - so no, we can't write to apps when creating a website - we also want to give editors a certain control over group names, labels and the component variations an editor can pick from when creating a page That sounds as if that is part of content not stored in /apps? the default node structure we want to create if a user adds a component to a page is currently under apps but we would like to keep it somewhere in /content in the future our big motivation for DDR is to make authoring and maintaining a website less dependent on developers and allow for better customization options after the initial effort to build a site has been completed. Carsten Ruben -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling Declarative Dynamic Resources
Where are the docs about making apps completely immutable? Sounds like it would be huge pain to be a site (customer) developer for a system like that. On Fri, Apr 23, 2021, 1:32 AM Carsten Ziegeler wrote: > Thanks Ruben, > > in my opinion /apps belongs to developers. In our case its immutable for > good reasons. Drilling a hole into this and allowing non developers > contribute to /apps, especially in a dynamic fashion circumventing the > immutability sounds very risky and can result in security problems. > > I understand that extra configuration options are added to partially > address this, but then it comes down to how effective these are and what > holes they might have. > > Now, in general I'm not against a feature like dynamic resources - but > making something immutable mutable especially for a different audience > is too dangerous. > > Regards > Carsten > > Am 22.04.2021 um 18:27 schrieb Ruben Reusser: > > Carsten, see inline > > > > On 4/22/2021 6:55 AM, Carsten Ziegeler wrote: > > > >> Am 21.04.2021 um 15:30 schrieb Ruben Reusser: > >>> - for each website that is created we have to create a corresponding > >>> /apps folder for rendering purposes > >> > >> I assume the ddr solution is temporary and eventually the information > >> is added to /apps directly? In this case I would do that immediately. > >> > > we try to live in a composite nodestore world where /apps is not > > writable - so no, we can't write to apps when creating a website > > > >>> - we also want to give editors a certain control over group names, > >>> labels and the component variations an editor can pick from when > >>> creating a page > >>> > >> That sounds as if that is part of content not stored in /apps? > >> > > the default node structure we want to create if a user adds a component > > to a page is currently under apps but we would like to keep it somewhere > > in /content in the future > > > > our big motivation for DDR is to make authoring and maintaining a > > website less dependent on developers and allow for better customization > > options after the initial effort to build a site has been completed. > > > >> Carsten > >> > > Ruben > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org >
Re: Sling Declarative Dynamic Resources
Hi Carsten Ruben told me that you think that this can be accomplished with a change to the Servlets Resolver. I am not sure how that would work as a servlet is driven by its resource type , extension etc. This in turn would mean that each child entry would need to adhere to that as well. - Andy > On Apr 22, 2021, at 10:31 PM, Carsten Ziegeler wrote: > > Thanks Ruben, > > in my opinion /apps belongs to developers. In our case its immutable for good > reasons. Drilling a hole into this and allowing non developers contribute to > /apps, especially in a dynamic fashion circumventing the immutability sounds > very risky and can result in security problems. > > I understand that extra configuration options are added to partially address > this, but then it comes down to how effective these are and what holes they > might have. > > Now, in general I'm not against a feature like dynamic resources - but making > something immutable mutable especially for a different audience is too > dangerous. > > Regards > Carsten > > Am 22.04.2021 um 18:27 schrieb Ruben Reusser: >> Carsten, see inline >> On 4/22/2021 6:55 AM, Carsten Ziegeler wrote: >>> Am 21.04.2021 um 15:30 schrieb Ruben Reusser: - for each website that is created we have to create a corresponding /apps folder for rendering purposes >>> >>> I assume the ddr solution is temporary and eventually the information is >>> added to /apps directly? In this case I would do that immediately. >>> >> we try to live in a composite nodestore world where /apps is not writable - >> so no, we can't write to apps when creating a website - we also want to give editors a certain control over group names, labels and the component variations an editor can pick from when creating a page >>> That sounds as if that is part of content not stored in /apps? >>> >> the default node structure we want to create if a user adds a component to a >> page is currently under apps but we would like to keep it somewhere in >> /content in the future >> our big motivation for DDR is to make authoring and maintaining a website >> less dependent on developers and allow for better customization options >> after the initial effort to build a site has been completed. >>> Carsten >>> >> Ruben > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
Re: Sling Declarative Dynamic Resources
Carsten, I think I understand your security concern - do you see another way to solve this in that case? Ruben On 4/22/2021 10:31 PM, Carsten Ziegeler wrote: Thanks Ruben, in my opinion /apps belongs to developers. In our case its immutable for good reasons. Drilling a hole into this and allowing non developers contribute to /apps, especially in a dynamic fashion circumventing the immutability sounds very risky and can result in security problems. I understand that extra configuration options are added to partially address this, but then it comes down to how effective these are and what holes they might have. Now, in general I'm not against a feature like dynamic resources - but making something immutable mutable especially for a different audience is too dangerous. Regards Carsten
Re: Sling Declarative Dynamic Resources
Thanks Ruben, in my opinion /apps belongs to developers. In our case its immutable for good reasons. Drilling a hole into this and allowing non developers contribute to /apps, especially in a dynamic fashion circumventing the immutability sounds very risky and can result in security problems. I understand that extra configuration options are added to partially address this, but then it comes down to how effective these are and what holes they might have. Now, in general I'm not against a feature like dynamic resources - but making something immutable mutable especially for a different audience is too dangerous. Regards Carsten Am 22.04.2021 um 18:27 schrieb Ruben Reusser: Carsten, see inline On 4/22/2021 6:55 AM, Carsten Ziegeler wrote: Am 21.04.2021 um 15:30 schrieb Ruben Reusser: - for each website that is created we have to create a corresponding /apps folder for rendering purposes I assume the ddr solution is temporary and eventually the information is added to /apps directly? In this case I would do that immediately. we try to live in a composite nodestore world where /apps is not writable - so no, we can't write to apps when creating a website - we also want to give editors a certain control over group names, labels and the component variations an editor can pick from when creating a page That sounds as if that is part of content not stored in /apps? the default node structure we want to create if a user adds a component to a page is currently under apps but we would like to keep it somewhere in /content in the future our big motivation for DDR is to make authoring and maintaining a website less dependent on developers and allow for better customization options after the initial effort to build a site has been completed. Carsten Ruben -- -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling Declarative Dynamic Resources
Carsten, see inline On 4/22/2021 6:55 AM, Carsten Ziegeler wrote: Am 21.04.2021 um 15:30 schrieb Ruben Reusser: - for each website that is created we have to create a corresponding /apps folder for rendering purposes I assume the ddr solution is temporary and eventually the information is added to /apps directly? In this case I would do that immediately. we try to live in a composite nodestore world where /apps is not writable - so no, we can't write to apps when creating a website - we also want to give editors a certain control over group names, labels and the component variations an editor can pick from when creating a page That sounds as if that is part of content not stored in /apps? the default node structure we want to create if a user adds a component to a page is currently under apps but we would like to keep it somewhere in /content in the future our big motivation for DDR is to make authoring and maintaining a website less dependent on developers and allow for better customization options after the initial effort to build a site has been completed. Carsten Ruben
Re: Sling Declarative Dynamic Resources
Am 21.04.2021 um 15:30 schrieb Ruben Reusser: Bertrand, Carsten, On 4/20/2021 10:57 PM, Carsten Ziegeler wrote: I totally agree that we should try to avoid overlapping solutions and as mentioned superimposing and ddr sound pretty similar. I understand the use cases on a higher level. However - similar to Bertrand - I'm a little bit worried. The readme for ddr talks about circumventing an immutable repository. If its possible to basically make immutable parts mutable, then this is entering dangerous territory. I understand your concern - that is one of the reasons why we made sure we allow blocking of resource types in ddr. we tried to outline our usecase we need to solve: - for each website that is created we have to create a corresponding /apps folder for rendering purposes I assume the ddr solution is temporary and eventually the information is added to /apps directly? In this case I would do that immediately. - we also want to give editors a certain control over group names, labels and the component variations an editor can pick from when creating a page That sounds as if that is part of content not stored in /apps? Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: Sling Declarative Dynamic Resources
Dan, I am in favor of adding the features from ddr to sling-superimposing - is that ok for others too? Ruben On 4/20/2021 4:14 PM, Daniel Klco wrote: IMO the biggest difference is how this defines the root of the dynamic resources, e.g. via creating a resource at that path or providing a configuration with the source and target. This alone is a major advantage as it means that ddr configurations can be defined at runtime with a composite store. The problem I see here is that we are trying to solve the same problem multiple ways. My take on the problem is: As a developer or superuser, I want to be able to present a virtual tree of resources generated from a tree of resources and a configuration tree. Resource merger solves this problem by anchoring a root and then defining source paths which can be overlayed and configured in order. This works well in the case where you have only two trees and you want to present a merged copy of these two trees, but does not work for arbitrary anchor points. Superimposing supports creating arbitrary roots but these roots can only be tied to one source. It also only allows overriding the overlayed resouces by using a lower level api (such as JCR) because the sling post servlet will update the source resources. Generally, I think it's better to have fewer ways of doing the same thing, do it makes sense to consolidate if possible. Given that resouces merger is widely used, I can't see how it would be worth the effort to regression check potential breaking issues. However, given that SuperImposing has not been significantly updated in years, I would recommend that we: 1. Update SuperImposing to work on Java 11 / OSGi 6 / Sling 12 2. Update SuperImposing to support defining virtual trees by source and source+target and other DDR features 3. Define a feature model to install the bundle and create an oak index for the mixin 4. Release this as the 1.0 version of SuperImposing I've already taken a run at updating SuperImposing and am ~75% there. What do others think? -Dan On Tue, Apr 20, 2021, 5:34 PM Andreas Schaefer wrote: Here is a short recap after trying to compare Superimposing Resource (SIR) and the Declarative Dynamice Resource (DDR). They are similar in some respect and different in others: Feature SIR DDR Resource Resolver type Admin RRService RR Linking fromTarget Source Mixin Supported Not Supported Resource ChangesSupported Supported Property ChangesNot Supported Supported Configure Parent by 1st Level Child Supported Not Supported OverlaysSupported Not Supported 2nd Level Redirection Not Supported Supported Filtering (Security)Not Supported Supported Java 11 Not Supported Supported Sling 12Not Supported Supported Cheers - Andy On Apr 20, 2021, at 6:13 AM, Stefan Seifert wrote: hello ruben. use case sounds a bit similar to https://github.com/apache/sling-org-apache-sling-superimposing (a bit outdated) and https://github.com/apache/sling-org-apache-sling-resourcemerger can you differentiate what DDR does differently? stefan -Original Message- From: Ruben Reusser Sent: Tuesday, April 20, 2021 1:54 PM To: dev@sling.apache.org Subject: Re: Sling Declarative Dynamic Resources totally forgot to add the link to the code base - sorry https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr On 4/19/2021 10:29 AM, Ruben Reusser wrote: dear sling community Andreas has been working to create a way to dynamically create component proxies in Sling based on a configuration. In peregrine-cms we are planning to use this approach when a new tenant (a new website) is created by a user. It allows us to proxy the base components into a new /apps folder for the website. A super user for the site can then potentially change the title/group of a component and the default structure that is used when adding a component to a page. We hope this component may be useful to other sling based content management systems as well. We'd like to ask to move this module out of the whiteboard - but of course we welcome any comments/concerns/things we should consider to make sure everybody can benefit from this module. looking forward to your comments! Ruben
Re: Sling Declarative Dynamic Resources
Bertrand, Carsten, On 4/20/2021 10:57 PM, Carsten Ziegeler wrote: I totally agree that we should try to avoid overlapping solutions and as mentioned superimposing and ddr sound pretty similar. I understand the use cases on a higher level. However - similar to Bertrand - I'm a little bit worried. The readme for ddr talks about circumventing an immutable repository. If its possible to basically make immutable parts mutable, then this is entering dangerous territory. I understand your concern - that is one of the reasons why we made sure we allow blocking of resource types in ddr. we tried to outline our usecase we need to solve: - for each website that is created we have to create a corresponding /apps folder for rendering purposes - we also want to give editors a certain control over group names, labels and the component variations an editor can pick from when creating a page would love to hear if there is a better alternative for this Regards Carsten
Re: Sling Declarative Dynamic Resources
I totally agree that we should try to avoid overlapping solutions and as mentioned superimposing and ddr sound pretty similar. I understand the use cases on a higher level. However - similar to Bertrand - I'm a little bit worried. The readme for ddr talks about circumventing an immutable repository. If its possible to basically make immutable parts mutable, then this is entering dangerous territory. Regards Carsten Am 21.04.2021 um 01:14 schrieb Daniel Klco: IMO the biggest difference is how this defines the root of the dynamic resources, e.g. via creating a resource at that path or providing a configuration with the source and target. This alone is a major advantage as it means that ddr configurations can be defined at runtime with a composite store. The problem I see here is that we are trying to solve the same problem multiple ways. My take on the problem is: As a developer or superuser, I want to be able to present a virtual tree of resources generated from a tree of resources and a configuration tree. Resource merger solves this problem by anchoring a root and then defining source paths which can be overlayed and configured in order. This works well in the case where you have only two trees and you want to present a merged copy of these two trees, but does not work for arbitrary anchor points. Superimposing supports creating arbitrary roots but these roots can only be tied to one source. It also only allows overriding the overlayed resouces by using a lower level api (such as JCR) because the sling post servlet will update the source resources. Generally, I think it's better to have fewer ways of doing the same thing, do it makes sense to consolidate if possible. Given that resouces merger is widely used, I can't see how it would be worth the effort to regression check potential breaking issues. However, given that SuperImposing has not been significantly updated in years, I would recommend that we: 1. Update SuperImposing to work on Java 11 / OSGi 6 / Sling 12 2. Update SuperImposing to support defining virtual trees by source and source+target and other DDR features 3. Define a feature model to install the bundle and create an oak index for the mixin 4. Release this as the 1.0 version of SuperImposing I've already taken a run at updating SuperImposing and am ~75% there. What do others think? -Dan On Tue, Apr 20, 2021, 5:34 PM Andreas Schaefer wrote: Here is a short recap after trying to compare Superimposing Resource (SIR) and the Declarative Dynamice Resource (DDR). They are similar in some respect and different in others: Feature SIR DDR Resource Resolver type Admin RRService RR Linking fromTarget Source Mixin Supported Not Supported Resource ChangesSupported Supported Property ChangesNot Supported Supported Configure Parent by 1st Level Child Supported Not Supported OverlaysSupported Not Supported 2nd Level Redirection Not Supported Supported Filtering (Security)Not Supported Supported Java 11 Not Supported Supported Sling 12Not Supported Supported Cheers - Andy On Apr 20, 2021, at 6:13 AM, Stefan Seifert wrote: hello ruben. use case sounds a bit similar to https://github.com/apache/sling-org-apache-sling-superimposing (a bit outdated) and https://github.com/apache/sling-org-apache-sling-resourcemerger can you differentiate what DDR does differently? stefan -Original Message- From: Ruben Reusser Sent: Tuesday, April 20, 2021 1:54 PM To: dev@sling.apache.org Subject: Re: Sling Declarative Dynamic Resources totally forgot to add the link to the code base - sorry https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr On 4/19/2021 10:29 AM, Ruben Reusser wrote: dear sling community Andreas has been working to create a way to dynamically create component proxies in Sling based on a configuration. In peregrine-cms we are planning to use this approach when a new tenant (a new website) is created by a user. It allows us to proxy the base components into a new /apps folder for the website. A super user for the site can then potentially change the title/group of a component and the default structure that is used when adding a component to a page. We hope this component may be useful to other sling based content management systems as well. We'd like to ask to move this module out of the whiteboard - but of course we welcome any comments/concerns/things we should consider to make sure everybody can benefit from this module. looking forward to your comments! Ruben
Re: Sling Declarative Dynamic Resources
IMO the biggest difference is how this defines the root of the dynamic resources, e.g. via creating a resource at that path or providing a configuration with the source and target. This alone is a major advantage as it means that ddr configurations can be defined at runtime with a composite store. The problem I see here is that we are trying to solve the same problem multiple ways. My take on the problem is: As a developer or superuser, I want to be able to present a virtual tree of resources generated from a tree of resources and a configuration tree. Resource merger solves this problem by anchoring a root and then defining source paths which can be overlayed and configured in order. This works well in the case where you have only two trees and you want to present a merged copy of these two trees, but does not work for arbitrary anchor points. Superimposing supports creating arbitrary roots but these roots can only be tied to one source. It also only allows overriding the overlayed resouces by using a lower level api (such as JCR) because the sling post servlet will update the source resources. Generally, I think it's better to have fewer ways of doing the same thing, do it makes sense to consolidate if possible. Given that resouces merger is widely used, I can't see how it would be worth the effort to regression check potential breaking issues. However, given that SuperImposing has not been significantly updated in years, I would recommend that we: 1. Update SuperImposing to work on Java 11 / OSGi 6 / Sling 12 2. Update SuperImposing to support defining virtual trees by source and source+target and other DDR features 3. Define a feature model to install the bundle and create an oak index for the mixin 4. Release this as the 1.0 version of SuperImposing I've already taken a run at updating SuperImposing and am ~75% there. What do others think? -Dan On Tue, Apr 20, 2021, 5:34 PM Andreas Schaefer wrote: > Here is a short recap after trying to compare Superimposing Resource (SIR) > and the Declarative Dynamice Resource (DDR). They are similar in some > respect and different in others: > > Feature SIR DDR > > Resource Resolver type Admin RRService RR > Linking fromTarget Source > Mixin Supported Not > Supported > Resource ChangesSupported Supported > Property ChangesNot Supported Supported > Configure Parent by > 1st Level Child Supported Not Supported > OverlaysSupported > Not Supported > 2nd Level Redirection Not Supported Supported > Filtering (Security)Not Supported Supported > Java 11 Not Supported Supported > Sling 12Not Supported > Supported > > Cheers - Andy > > > On Apr 20, 2021, at 6:13 AM, Stefan Seifert > > > wrote: > > > > hello ruben. > > > > use case sounds a bit similar to > > > > https://github.com/apache/sling-org-apache-sling-superimposing (a bit > outdated) > > and > > https://github.com/apache/sling-org-apache-sling-resourcemerger > > > > can you differentiate what DDR does differently? > > > > stefan > > > >> -----Original Message- > >> From: Ruben Reusser > >> Sent: Tuesday, April 20, 2021 1:54 PM > >> To: dev@sling.apache.org > >> Subject: Re: Sling Declarative Dynamic Resources > >> > >> totally forgot to add the link to the code base - sorry > >> > >> > https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr > >> > >> On 4/19/2021 10:29 AM, Ruben Reusser wrote: > >>> dear sling community > >>> > >>> Andreas has been working to create a way to dynamically create > >>> component proxies in Sling based on a configuration. In peregrine-cms > >>> we are planning to use this approach when a new tenant (a new website) > >>> is created by a user. It allows us to proxy the base components into a > >>> new /apps folder for the website. A super user for the site can then > >>> potentially change the title/group of a component and the default > >>> structure that is used when adding a component to a page. > >>> > >>> We hope this component may be useful to other sling based content > >>> management systems as well. We'd like to ask to move this module out > >>> of the whiteboard - but of course we welcome any > >>> comments/concerns/things we should consider to make sure everybody can > >>> benefit from this module. > >>> > >>> looking forward to your comments! > >>> > >>> Ruben > > > >
Re: Sling Declarative Dynamic Resources
Here is a short recap after trying to compare Superimposing Resource (SIR) and the Declarative Dynamice Resource (DDR). They are similar in some respect and different in others: Feature SIR DDR Resource Resolver type Admin RRService RR Linking fromTarget Source Mixin Supported Not Supported Resource ChangesSupported Supported Property ChangesNot Supported Supported Configure Parent by 1st Level Child Supported Not Supported OverlaysSupported Not Supported 2nd Level Redirection Not Supported Supported Filtering (Security)Not Supported Supported Java 11 Not Supported Supported Sling 12Not Supported Supported Cheers - Andy > On Apr 20, 2021, at 6:13 AM, Stefan Seifert > wrote: > > hello ruben. > > use case sounds a bit similar to > > https://github.com/apache/sling-org-apache-sling-superimposing (a bit > outdated) > and > https://github.com/apache/sling-org-apache-sling-resourcemerger > > can you differentiate what DDR does differently? > > stefan > >> -Original Message- >> From: Ruben Reusser >> Sent: Tuesday, April 20, 2021 1:54 PM >> To: dev@sling.apache.org >> Subject: Re: Sling Declarative Dynamic Resources >> >> totally forgot to add the link to the code base - sorry >> >> https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr >> >> On 4/19/2021 10:29 AM, Ruben Reusser wrote: >>> dear sling community >>> >>> Andreas has been working to create a way to dynamically create >>> component proxies in Sling based on a configuration. In peregrine-cms >>> we are planning to use this approach when a new tenant (a new website) >>> is created by a user. It allows us to proxy the base components into a >>> new /apps folder for the website. A super user for the site can then >>> potentially change the title/group of a component and the default >>> structure that is used when adding a component to a page. >>> >>> We hope this component may be useful to other sling based content >>> management systems as well. We'd like to ask to move this module out >>> of the whiteboard - but of course we welcome any >>> comments/concerns/things we should consider to make sure everybody can >>> benefit from this module. >>> >>> looking forward to your comments! >>> >>> Ruben >
Re: Sling Declarative Dynamic Resources
On Tue, Apr 20, 2021 at 3:30 PM Ruben Reusser wrote: > ... sling-org-apache-sling-superimposing may in fact provide almost the same > functionality we are looking for and is definitely worth a try from our > side!... I haven't looked at that or DDR in detail but overlaying/shadowing/masking things makes all sorts of alarms go on in my little brain, in terms of the potential for making troubleshooting and understanding a Sling-based system very complicated. Please make sure these things are *very* transparent, in terms of logging, tracing, maybe even adding synthetic Resource properties which help explain what's going on, to make troubleshooting at least possible and ideally easy. -Bertrand
Re: Sling Declarative Dynamic Resources
Stefan, thanks for the pointers dynamic declarative resources is I think something between the 2 solutions you pointed out - its meant to be a simple overlay of nodes in /apps using a configuration in /conf ro support immutable /apps trees sling-org-apache-sling-superimposing may in fact provide almost the same functionality we are looking for and is definitely worth a try from our side! thanks Ruben On 4/20/2021 6:13 AM, Stefan Seifert wrote: hello ruben. use case sounds a bit similar to https://github.com/apache/sling-org-apache-sling-superimposing (a bit outdated) and https://github.com/apache/sling-org-apache-sling-resourcemerger can you differentiate what DDR does differently? stefan -Original Message- From: Ruben Reusser Sent: Tuesday, April 20, 2021 1:54 PM To: dev@sling.apache.org Subject: Re: Sling Declarative Dynamic Resources totally forgot to add the link to the code base - sorry https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr On 4/19/2021 10:29 AM, Ruben Reusser wrote: dear sling community Andreas has been working to create a way to dynamically create component proxies in Sling based on a configuration. In peregrine-cms we are planning to use this approach when a new tenant (a new website) is created by a user. It allows us to proxy the base components into a new /apps folder for the website. A super user for the site can then potentially change the title/group of a component and the default structure that is used when adding a component to a page. We hope this component may be useful to other sling based content management systems as well. We'd like to ask to move this module out of the whiteboard - but of course we welcome any comments/concerns/things we should consider to make sure everybody can benefit from this module. looking forward to your comments! Ruben
Re: Sling Declarative Dynamic Resources
Ruben, IMO it's a really interesting concept. A few thoughts: - I'm not a huge fan of the node type sling:DDR, would sling:dynamicResource work? I feel like it's more descriptive - Your node definition has sling:DDR extend sling:Folder, rather than extending this specific type, would it make sense to make this a mixin? - Should there be an Oak Index associated with this to optimize initial startup performance? - It would be nice as well if there were a mbean / osgi console or similar for diagnosing issues On Tue, Apr 20, 2021 at 7:54 AM Ruben Reusser wrote: > totally forgot to add the link to the code base - sorry > > https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr > > On 4/19/2021 10:29 AM, Ruben Reusser wrote: > > dear sling community > > > > Andreas has been working to create a way to dynamically create > > component proxies in Sling based on a configuration. In peregrine-cms > > we are planning to use this approach when a new tenant (a new website) > > is created by a user. It allows us to proxy the base components into a > > new /apps folder for the website. A super user for the site can then > > potentially change the title/group of a component and the default > > structure that is used when adding a component to a page. > > > > We hope this component may be useful to other sling based content > > management systems as well. We'd like to ask to move this module out > > of the whiteboard - but of course we welcome any > > comments/concerns/things we should consider to make sure everybody can > > benefit from this module. > > > > looking forward to your comments! > > > > Ruben > > > > >
RE: Sling Declarative Dynamic Resources
hello ruben. use case sounds a bit similar to https://github.com/apache/sling-org-apache-sling-superimposing (a bit outdated) and https://github.com/apache/sling-org-apache-sling-resourcemerger can you differentiate what DDR does differently? stefan >-Original Message- >From: Ruben Reusser >Sent: Tuesday, April 20, 2021 1:54 PM >To: dev@sling.apache.org >Subject: Re: Sling Declarative Dynamic Resources > >totally forgot to add the link to the code base - sorry > >https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr > >On 4/19/2021 10:29 AM, Ruben Reusser wrote: >> dear sling community >> >> Andreas has been working to create a way to dynamically create >> component proxies in Sling based on a configuration. In peregrine-cms >> we are planning to use this approach when a new tenant (a new website) >> is created by a user. It allows us to proxy the base components into a >> new /apps folder for the website. A super user for the site can then >> potentially change the title/group of a component and the default >> structure that is used when adding a component to a page. >> >> We hope this component may be useful to other sling based content >> management systems as well. We'd like to ask to move this module out >> of the whiteboard - but of course we welcome any >> comments/concerns/things we should consider to make sure everybody can >> benefit from this module. >> >> looking forward to your comments! >> >> Ruben
Re: Sling Declarative Dynamic Resources
totally forgot to add the link to the code base - sorry https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr On 4/19/2021 10:29 AM, Ruben Reusser wrote: dear sling community Andreas has been working to create a way to dynamically create component proxies in Sling based on a configuration. In peregrine-cms we are planning to use this approach when a new tenant (a new website) is created by a user. It allows us to proxy the base components into a new /apps folder for the website. A super user for the site can then potentially change the title/group of a component and the default structure that is used when adding a component to a page. We hope this component may be useful to other sling based content management systems as well. We'd like to ask to move this module out of the whiteboard - but of course we welcome any comments/concerns/things we should consider to make sure everybody can benefit from this module. looking forward to your comments! Ruben
Sling Declarative Dynamic Resources
dear sling community Andreas has been working to create a way to dynamically create component proxies in Sling based on a configuration. In peregrine-cms we are planning to use this approach when a new tenant (a new website) is created by a user. It allows us to proxy the base components into a new /apps folder for the website. A super user for the site can then potentially change the title/group of a component and the default structure that is used when adding a component to a page. We hope this component may be useful to other sling based content management systems as well. We'd like to ask to move this module out of the whiteboard - but of course we welcome any comments/concerns/things we should consider to make sure everybody can benefit from this module. looking forward to your comments! Ruben
