[
https://issues.apache.org/jira/browse/SLING-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14027670#comment-14027670
]
Justin Edelson commented on SLING-3657:
---------------------------------------
I was thinking that ResourceMergerService would be
Resource getMergedResource(String path, ResourceResolver resolver,
Iterable<Resource> resources)
Resource listMergedChildren(String path, ResourceResolver resolver,
Iterable<Resource> resources)
Which, come to think of it, could just as easily be done in an exported
abstract ResourceProvider.
IMHO, the ResourceMergerService should *just* be merging resources, not
discovering the resource to be merged. The whole point of having a separate
service should be to allow any number of resource selection processes to be
created (i.e. ones you and I can't even think of).
> Create a ResourceMerger-style ResourceProvider which merges based on resource
> super types
> -----------------------------------------------------------------------------------------
>
> Key: SLING-3657
> URL: https://issues.apache.org/jira/browse/SLING-3657
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Justin Edelson
> Attachments: SLING-3657.patch
>
>
> The current MergingResourceProvider does a good job of a single use case -
> merging resources relative to the search paths. A second use case for merging
> is to merge resources based on their sling:resourceSuperType inheritance, i.e.
> /content/siteA@sling:resourceSuperType=/content/siteB
> /content/siteB@sling:resourceSuperType=/content/siteC
> It should be possible to generate a merged resource which combines
> /content/siteA, /content/siteB, and /content/siteC (in reverse order so that
> siteA overrides siteB, etc.).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
