[ 
https://issues.apache.org/jira/browse/SLING-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14137316#comment-14137316
 ] 

Alexander Klimetschek commented on SLING-3909:
----------------------------------------------

{quote}it changes it with a POST to the same path{quote}
This. POSTing to {{/mnt/overlay/some/path}} is the problem, the application 
can't chose where it wants the change.

(BTW, the sling post servlet still works with JCR anyway right?)

I have another new possible use case for merging. Configurations, and unlike 
overlaying some "product" content (/apps) with "customer" content (/apps) it 
allows for having shared global configurations that are inherited by child 
configurations. Here is an example (most specific at the bottom):

{code}
/conf/default
/conf/acme/global
/conf/acme/project1
/conf/acme/project1/subproject1
{code}

If you build a UI for that, you want to control where things go, probably in 
response to some user selection. E.g. "change global for all acme projects" -> 
modify {{/conf/acme/global}}.

The current approach of the hardcoded logic to change the most specific one 
would always modify {{/conf/acme/project1/subproject1}} only. And have no 
option to ever change that and direct it to something else, simply because in 
the context of the resource CRUD API there is no way to pass an additional path.

> 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
>            Assignee: Carsten Ziegeler
>             Fix For: Resource Merger 1.2.0
>
>
> 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)

Reply via email to