[ https://issues.apache.org/jira/browse/SLING-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17291163#comment-17291163 ]
Konrad Windszus commented on SLING-5469: ---------------------------------------- Let's go for a simple mixin approach here. The new mixin must allow the four properties # sling:hideProperties (String{}) # sling:hideChildren (String[]) # sling:hideResource (Boolean) # sling:orderBefore (String) > Resource Merger: Add some name prefixing mechanism for properties which are > used by the resource merger itself > -------------------------------------------------------------------------------------------------------------- > > Key: SLING-5469 > URL: https://issues.apache.org/jira/browse/SLING-5469 > Project: Sling > Issue Type: Improvement > Components: Extensions > Affects Versions: Resource Merger 1.2.10 > Reporter: Konrad Windszus > Priority: Major > Fix For: Resource Merger 1.4.0 > > > Currently within the resource merger it is not possible to > # use the {{jcr:primaryType}} of the underlying resource, while the > overlaid/overridden resource has a different {{jcr:primaryType}}. > That is a problem because for a JCR the primaryType is mandatory for each > node. Some node type definitions don't allow arbitrary property names like > {{sling:hideResource}}. To be able to use those properties (which are only > relevant up the point where the resource has been merged) you might need to > use a more relaxed node type. Still you don't want that relaxed node type to > appear as primaryType in the merged resource. > # use the {{sling:resourceSuperType}} from the underlying resource, while the > overridden resource has a different {{sling:resourceSuperType}}. > This is kind of a edge case because sling:resourceSuperType would be used for > two different things here: > ** for getting the underlying resource path for the > {{OverridingResourcePicker}} > ** for the request resolution of the merged resource > Sometime the value for each of the cases would be different. > Therefore I propose a general property name mangling mechanism which allows > someone to use a prefix like {{sling-resource-merging_}} for the properties, > which are during the resource merging exposed as properties without the > prefix. One example for case 1): > {code} > /apps/my/resource > - jcr:primaryType=nt:folder > - sling:resourceSuperType=apps/my/super/resource > - sling:hideProperties=customNodeTypePrefix:property1 > - jcr:sling-resource-merging_primaryTypemyCustomNodeRestrictedNodeType > /apps/my/super/resource > - jcr:primaryType=myCustomNodeRestrictedNodeType > - customNodeTypePrefix:property1=test > - customNodeTypePrefix:property2=test > /mnt/override/apps/my/resource > - jcrPrimaryType=nt:unstructured (but should be > myCustomNodeRestrictedNodeType) > - customNodeTypePrefix:property2=test > {code} > In this example it is impossible to let my merged resource have the nodeType > {{myCustomNodeRestrictedNodeType}} (because that simply does not allow the > property {{sling:hideProperties}} to be set in {{/apps/my/resource}}. -- This message was sent by Atlassian Jira (v8.3.4#803005)