Alexander Klimetschek created SLING-3423:
--------------------------------------------
Summary: ResourceMergerService API is wrong
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.1.5#6160)
