Re: [Sling] Merging of content resources

[Patrick Fauchere <fa...@adobe.com>]

Hi,

I am reactivating the thread as we really would like to successfully 
mutualize the merging of resources [1] in some particular cases as well. 
The following use case [0] implies:

- Merging of two semantically related resources that do not share a 
relative path
- The location of the two resources is not limited to the search paths as 
they will be located under <config>, <etc/design>, <libs> and <apps>
- The resources are not components as they only are a tree of resources 
representing configurations
- Currently some useful classes from 
<org.apache.sling.resourcemerger.impl> and containing the merging logic 
are not publicly accessible such as <MergedResource> or <MergedValueMap>

What could or should we do to achieve our goal ?

[0] https://jira.corp.adobe.com/browse/CQ-88886
[1] https://jira.corp.adobe.com/browse/CQ-49953


Cheers,


Patrick Fauchère
Software Engineer
Adobe 
Barfüsserplatz 6
CH-4051 Basel, Switzerland
+41 (0)61.226.57.62 (tel), +41 (0)78.613.47.66 (cell)
fauchere@adobe.com
www.adobe.com









On 6/17/16, 10:47 AM, "Christanto Leonardo" <cl...@adobe.com> wrote:

>Hi,
>
>I would say using prefix (e.g. /mnt/merge) is not a problem.
>
>Cheers,
>Christanto
>
>
>
>On 17/06/16 00:34, "Justin Edelson" <je...@adobe.com> wrote:
>
>>The thing with the path prefix is one of circularity. If you say 
>>/content/resource2 is the merging of /content/resource2 and 
>>/content/resource1, then you have an endless loop of merging. So we have 
>>to be able to say that <someotherpath> is the merge of those two 
>>resources. And that other path needs to contain the “start point” for 
>>the merging (i.e. /content/resource2 in this case).
>>
>>There’s no duplicated nodes. The Sling Resource Merger makes generic 
>>what can be generic (i.e. the actual merging logic) while leaving the 
>>part that can’t be (i.e. the identification of resource to be merged) 
>>open for pluggability.
>>
>>Justin
>>
>>On 6/16/16, 6:10 PM, "Gabriel Walt" <gw...@adobe.com> wrote:
>>
>>
>>Yes.
>>
>>It would be great to have a generic Sling feature to virtually merge 
>>trees, in order to avoid duplicating nodes when it doesn’t make sense.
>>
>>Maybe overlays are not intended for that? But on the other hand, we use 
>>that already for merging dialogs of sling:resourceSuperTypes, which is a 
>>very similar use-case. It would however be nice if the resource merger 
>>could be used for any tree that refers to another tree with a specific 
>>property.
>>
>>Gabriel
>>
>>
>>On 16/06/16 23:57, "Justin Edelson" <je...@adobe.com> wrote:
>>
>>By “strongly limited” do you mean requiring a path prefix?
>>
>>
>>
>>On 6/16/16, 5:56 PM, "Gabriel Walt" <gw...@adobe.com> wrote:
>>
>>
>>Are you aware of any particular reason why overlays are so strongly 
>>limited? Because this typically doesn’t allow to have overlays within 
>>the same path, and makes it impossible for any arbitrary resource to act 
>>as overlay of another resource it would reference.
>>
>>
>>
>>On 16/06/16 23:33, "Justin Edelson" <je...@adobe.com> wrote:
>>
>>Hi Gabriel,
>>Sling merging can’t do that exactly, but it could do
>>
>>/mnt/merge/content/resource1
>>   @sling:overlay = “/content/resource2”
>>    * header
>>        @jcr:title = “Hello World!”
>>    * foo …
>>
>>i.e. right now, there must be some kind of path prefix.
>>
>>Regards,
>>Justin
>>
>>
>>
>>
>

Re: [Sling] Merging of content resources

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Mon, Jul 4, 2016 at 3:51 PM, Patrick Fauchere <fa...@adobe.com> wrote:
> ...I am reactivating the thread as we really would like to successfully
> mutualize the merging of resources...

It looks like you didn't mean to send this here, but if you find
things that can be solved at the Sling level please let us know. I
suppose https://sling.apache.org/documentation/bundles/resource-merger.html
can help for your use cases, and maybe we can make it more reusable in
different contexts.

If this is "only" about aggregating and formatting resources for JSON
clients, the discussion about simpler customization of JSON rendering
might be relevant, http://markmail.org/thread/xltws7uqtuibfpvh

-Bertrand