[
https://issues.apache.org/jira/browse/SLING-3423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923115#comment-13923115
]
Alexander Klimetschek edited comment on SLING-3423 at 3/6/14 9:45 PM:
----------------------------------------------------------------------
[~jsedding] Yes, you are right, that could be an alternative. However, I would
say it is more complicated/not intuitive ("the other way around"). You have to
configure a separate resource provider (through a factory) with a specific
implementation of the MergeResourceSelector service, so these will require a
dedicated name to identify them in configuration/service ldap filter, for
example "search-path-selector". Just adding a custom ResourceProvider with
plain scr and config seems more straightforward to me.
Also, who says there isn't at some point later a need for the service
independent of a resource provider - maybe hooking it in via decorator etc.
could make sense.
BTW, the {{path.startsWith('/mnt/overlay/')}} part must be in the resource
provider, the selector doesn't know the mount path (= mergeRootPath in the
issue description above).
was (Author: alexander.klimetschek):
[~jsedding] Yes, you are right, that could be an alternative. However, I would
say it is more complicated/not intuitive ("the other way around"). You have to
configure a separate resource provider (through a factory) with a specific
implementation of the MergeResourceSelector service, so these will require a
dedicated name to identify them in configuration/service ldap filter, for
example "search-path-selector". Just adding a custom ResourceProvider with
plain scr and config seems more straightforward to me.
Also, who says there isn't at some point a need for the service independent of
a resource provider - maybe hooking it in via decorator etc. could make sense
(for now it makes sense).
BTW, the {{path.startsWith('/mnt/overlay/')}} part must be in the resource
provider, the selector doesn't know the mount path (= mergeRootPath in the
issue description above).
> 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)
