[
https://issues.apache.org/jira/browse/SLING-5469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123697#comment-15123697
]
Julian Sedding commented on SLING-5469:
---------------------------------------
[~kwin] Could your use-case (1) also be solved by creating a mixin type that
allows setting the {{sling:hideProperties}} and {{sling:hideChildren}}? Then
your {{jcr:primaryType}} could remain the same.
Regarding use-case (2) I suspect you may be abusing the feature. Could you
please expand on your use-case, so it becomes clearer what you are trying to
achieve? Ideally with an example. Thanks.
> 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
>
> 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
(v6.3.4#6332)
