[ https://issues.apache.org/jira/browse/SLING-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922248#comment-13922248 ]
Bertrand Delacretaz commented on SLING-3423: -------------------------------------------- It would be nice if whoever needs this stuff can briefly document their use cases so that we have all of them in a single place and are not guessing at what other people need. Best is probably a new page under https://cwiki.apache.org/confluence/display/SLING/Index > ResourceMergerService API must allow custom merge paths > ------------------------------------------------------- > > Key: SLING-3423 > URL: https://issues.apache.org/jira/browse/SLING-3423 > Project: Sling > Issue Type: Bug > Components: Extensions > Affects Versions: Resource Merger 1.0.0 > Reporter: Alexander Klimetschek > > From http://sling.markmail.org/thread/3wt33wniwgflmk27 > The ResourceMergerService added by SLING-2986 must have this one central API, > where the caller = application defines the merge paths! > Resource merge(ResourceResolver resolver, String mergeRootPath, String > relativePath, String... mergePaths) > Example values for the use case of the overlay resource provider: > resolver = based on the current request (user) > mergeRootPath = /mnt/overlay > relativePath = <dynamic part>, for example: "projectX/content/ui/toolbar" > mergePaths = /apps, /libs > This was in the original patch [1], sadly removed and later added back but > completely missing the point. > Currently it is all tied to the sling search path internally, but this would > just be ONE of different options the application might want to chose for it. > The specific /mnt/overlay ResourcerProvider would take the sling search path > and expose resources based on calling the merger service with this as the > mergePaths. (Currently there is a single implementation > MergedResourceProviderFactory for both ResourceMergerService and the > ResourceProvider service). > This is simply a proper separation of concerns. > Another application with different merge paths would be to merge resource > type hierarchies: use the resource type and its super types. This could allow > one to put UI dialogs in the resource types (say at ./dialog) and then be > able to extend dialogs in sub resource types using the merger service. > [1] > https://github.com/gknob/sling-resourcemerger/commit/a3e1b78c87e54cd5c32a58627a4de0420229e1f9 -- This message was sent by Atlassian JIRA (v6.2#6252)