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 <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