[
https://issues.apache.org/jira/browse/SLING-12391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868609#comment-17868609
]
Henry Kuijpers commented on SLING-12391:
----------------------------------------
[~kwin] It looks like we have recently upgraded from Resource Merger 1.3.2
(which seems to be a version from 2016-ish), to the newest version (through
AEM's Service Pack 21, bumping the version to the newest). This causes
regression in AEM's TouchUI dialogs: Almost all fields are gone, where
"sling:hideChildren" was configured.
It looks like, with the current code from 1.4.4 in place, we need to update all
"sling:hideChildren" to also include all the local resources as well.
----
Honestly, I don't think this makes sense. I see you have also addressed all my
reasons for saying this is a bug: Why would you define a resource, right next
to the "sling:hideChildren"-instruction, that you would want to hide?
When "sling:hideChildren" is in place, adding a new resource is now always a
2-step-process: Add the resource + update the "sling:hideChildren"-instruction.
This feels very counter-intuitive.
> Resource Merger with negation hides local resources as well
> -----------------------------------------------------------
>
> Key: SLING-12391
> URL: https://issues.apache.org/jira/browse/SLING-12391
> Project: Sling
> Issue Type: Bug
> Affects Versions: Resource Merger 1.4.4
> Reporter: Henry Kuijpers
> Priority: Major
>
> For example
> Parent:
> * "basic" (with properties and children)
> * "expert" (with properties and children)
> Current: (Inheriting from parent)
> * (sling:hideChildren="!basic,*")
> * "basic" -> Parent "basic" + new subnode and adjustments to properties
> * "expert" -> Entirely new "expert"-node without any inheriting from the
> parent's "expert"-node
> Should result in:
> * "basic" being inherited, and in the current node we could do any
> modifications / overrides still
> * "expert" not being inherited at all, but we would be free to define a new
> "expert"-node with other properties/subnodes/... Which has no relationship at
> all with the parent "expert"
> Currently the behavior is that the "expert"-node, defined in parent, is not
> available in current, at all. Even though there is a completely new
> definition of properties and subnodes defined as well.
>
> Why else would we define these properties and subnodes?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
