[
https://issues.apache.org/jira/browse/SLING-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14106904#comment-14106904
]
Carsten Ziegeler commented on SLING-3657:
-----------------------------------------
The question for me is, do we really have a use case for arbitrary merging
resource provider implementations - or can't we handle all three use cases
mentioned initially in the same bundle and are done? So basically three
implementations sharing some code?
I think three different ways is already hard to understand, but opening it up
to N implementations makes it complicated as you first have to know it's a
merging provider and then also you have to know how exactly the merging works.
I would think if we can provide the common stuff in a service, than we can also
directly provide the resource providers.
Yes, the CUD part doesn't play a role in this discussion.
> 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)
