[
https://issues.apache.org/jira/browse/SLING-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132433#comment-14132433
]
Alexander Klimetschek commented on SLING-3909:
----------------------------------------------
By application I mean code on top, using the merged resources.
{quote}it should operate against the resources directly{quote}
That's where I disagree. IMO it should be a separate utility, see also
SLING-3420, and ideally it should also work without a separate utility. Why?
1. The original use case was clearly split: a product developer sets up
components, another application developer could use the right properties to
overlay that with an extension, something that does not happen in code; only
reading & merging the final result is done programmatically in the merged
resource provider
2. Once we go to UIs that should be able to show AND modify such merged
resources we go into uncharted & dangerous territory – just look at the design
mechanism in AEM and all the different ways to modify it. I don't think there
is a single way to modify them, i.e. that edit most significant resource
described above. And when you provide CRUD on the returned resources you are
restricted to the resource & value map API and don't have a way to indicate
that you want to modify something else (say the conceptually 2nd most
significant resource), since you can't pass additional arguments.
And once we agree that there are multiple ways, at this point we don't even
know all the different creative ways you could leverage the resource merger
(simple UI definitions, components, configurations, etc.). Each way will have a
different way the UI works. It should also work with the sling post servlet.
Hence I think baking something in the resource merger and saying "this is the
one place to put the logic" will not work. We could have a separate utility,
and good documentation (e.g. how to do it with sling post servlet), with the
philosophy they are only "helpers", with the option to evolve.
> Merged ResourceProviders should be optionally modifiable
> --------------------------------------------------------
>
> Key: SLING-3909
> URL: https://issues.apache.org/jira/browse/SLING-3909
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
> Reporter: Justin Edelson
>
> This is a continuation of the work originally started in SLING-3420.
> Modification are always done on the "most significant" resource (i.e.
> /apps/foo instead of /libs/foo) as determined by the MergedResourcePicker.
> The algorithm for modification is as follows:
> * Create - if the most significant resource doesn't exist, one is created at
> that path; otherwise an exception is thrown.
> * Delete - if the most significat resource doesn't exist, the hide children
> property is set on the most signfiicant resource's parent. if it does exist,
> it is deleted and the hide children property is set.
> * Property Modifications - most significant resource is created as necessary.
> ** Create - created on most significant resource
> ** Modify - created/updated on most significant resource
> ** Delete - deleted if necessary on most significant resource and hidden.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
