[
https://issues.apache.org/jira/browse/SLING-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15141002#comment-15141002
]
Julian Sedding edited comment on SLING-5468 at 2/10/16 3:33 PM:
----------------------------------------------------------------
Regarding the use-case vs backwards compatibility issue, I agree with Konrad
that the current behaviour is weird. Adding a new property just to work around
this weirdness is IMHO damaging to the clarity and simplicity of the tool.
I could imagine a solution in the middle that may work:
- a value of {{*}} in {{sling:hideResources}} or {{sling:hideProperties}} is
applied only to all underlying resources
- any explicit value in {{sling:hideResources}} or {{sling:hideProperties}} is
applied also to the top resource.
The behavioural change in this case would be limited to the {{*}} value.
Currently the following is implied (please correct me if I am wrong):
- for {{sling:hideResources="*"}} the resource cannot have any children, even
if they are added on the top resource
- for {{sling:hideProperties="*"}} the resource cannot have any properties,
even if they are added on the top resource
IMHO none of these scenarios make much sense. And yet, they could still be
achieved by hiding all inherited children and/or properties using {{*}} and
then explicitly listing any children and/or properties of the top resource.
[~cziegeler] and [~kwin] WDYT? Could that be a workable "middle ground"
solution?
was (Author: jsedding):
Regarding the use-case vs backwards compatibility issue, I agree with Konrad
that the current behaviour is weird. Adding a new property just to work around
this weirdness is IMHO damaging to the clarity and simplicity of the tool.
I could imagine a solution in the middle that may work:
- a value of {{*}} in {{sling:hideChildren}} or {{sling:hideProperties}} is
applied only to all underlying resources
- any explicit value in {{sling:hideChildren}} or {{sling:hideProperties}} is
applied also to the top resource.
The behavioural change in this case would be limited to the {{*}} value.
Currently the following is implied (please correct me if I am wrong):
- for {{sling:hideChildren="*"}} the resource cannot have any children, even if
they are added on the top resource
- for {{sling:hideProperties="*"}} the resource cannot have any properties,
even if they are added on the top resource
IMHO none of these scenarios make much sense. And yet, they could still be
achieved by hiding all inherited children and/or properties using {{*}} and
then explicitly listing any children and/or properties of the top resource.
[~cziegeler] and [~kwin] WDYT? Could that be a workable "middle ground"
solution?
> Resource Merger: Provide a way to completely replace the underlying resources
> -----------------------------------------------------------------------------
>
> Key: SLING-5468
> URL: https://issues.apache.org/jira/browse/SLING-5468
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Affects Versions: Resource Merger 1.2.10
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
> Fix For: Resource Merger 1.3.2
>
> Attachments: SLING-5468-v1.patch
>
>
> Currently whenever the mount point of the {{MergingResourcePicker}}
> (/mnt/overlay) or {{OverridingResourcePicker}} (/mnt/override) is used, the
> merging always takes place. It is only possible to hide/modify individual
> resource/properties of the underlying resources but not to completely disable
> the inheritance (and by that replace the whole overriden/overlaid resource).
> A concrete usecase for that is in a CMS (e.g. AEM) where the dialog
> definitions are always loaded via /mnt/override/<resource type>. In that case
> it is not easily possible to completely replace the dialog of the resource
> super type (as only individual child resources or properties can be hidden
> but there is no special property to ignore the inherited resource
> alltogether).
> I propose the following:
> Add a new property {{sling:disregardInheritedResource=true}} in which case
> all the inherited resources would not be taken into account for merging.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
