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 <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
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
