[ https://issues.apache.org/jira/browse/SLING-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13920616#comment-13920616 ]
Carsten Ziegeler commented on SLING-3423: ----------------------------------------- As stated in the mail thread, I'm against any service returning resources which are not part of the resource tree - as this will create all kinds of problems and bypasses all of Sling's concepts like resource decorators, resource access security, feature flags - just to name a few. I'm fine with having a service which returns a data structure for merged resource, something like: public interface MergeData { String[] getMergedPaths(); ValueMap getMergedValueMap(); } with a method public MergeData merge(String[] paths) on the service. If the application wants to go the risky way of wrapping this in a resource, this can be easily done on the app level > 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)