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 <cziege...@apache.org> 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
