[jira] [Updated] (SLING-3423) ResourceMergerService API must allow custom merge paths

["Alexander Klimetschek (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Klimetschek updated SLING-3423:
-----------------------------------------

    Summary: ResourceMergerService API must allow custom merge paths  (was: ResourceMergerService API is wrong)

> 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.1.5#6160)