[
https://issues.apache.org/jira/browse/SLING-10150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17292515#comment-17292515
]
Julian Sedding commented on SLING-10150:
----------------------------------------
The documentation on
https://sling.apache.org/documentation/bundles/resource-merger.html#merge-properties-1
says the following about {{sling:hideChildren}}:
{quote}
Hides the child resources with the given names. * hides all child resources
(since version 1.3.2 the wildcard only affects underlying child resources and
no longer local ones, see also SLING-5468). If one value starts with ! this is
a negation (which means the property with the given value should not be
hidden). Since by default nothing is hidden the negation is only useful if you
specify multiple values for this property. E.g. giving the values [!child1,*]
hides all children except for the one with the name child1. If you have a
resource name starting with ! you must escape it with an additional ! in front
if you want to reference it in sling:hideChildren, e.g. !!child1 means that the
resource with the name !child1 should be hidden.
{quote}
I believe we need to relax your suggestion a little, because we should respect
the documented behaviour as far as possible.
Support for the "*" value in negated lists needs to be kept (without warning)
and it may appear at any position in a negated list (no required ordering is
documented, only an example given). It can be made optional, in which case the
docs should be adjusted to reflect the relaxation of this requirement. ("Since
by default nothing is hidden the negation is only useful if you specify
multiple values [...]").
Furthermore, we have an issue with escaping of exclamation marks, because the
current docs are not sufficiently specific. The docs only say that the resource
named "!child1" can be hidden (i.e. listed as non-negated) by listing it as
"!!child1". However, what happens if we want to exclude it? I assume
"!!!child1". And what about the resource named "!!child2". Do I hide it with
"!!!!child2" and not hide it with "!!!!!child2"? This would imply that odd
numbers of leading exclamation marks constitute a negation, and all following
"!" would need to be unescaped.
Given that a negated list is determined by its first (non "*") element, we
_could_ relax the requirement for escaping "!" in non-negated lists. But that
would make it impossible to know when to log a warning for seemingly negated
entries.
Furthermore, we _could_ relax the requirement for escaping in all but the first
element of a list, because then we already know if it is negated or not.
I don't think that these relaxed requirements for escaping would be a good
idea. I also don't think that node names starting with "!" are very common. So
keeping it simple and documenting it properly is probably best.
> Sling Resource Merger completely hides parent when whitelisting in
> combination with asterisk is used for sling:hideChildren
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: SLING-10150
> URL: https://issues.apache.org/jira/browse/SLING-10150
> Project: Sling
> Issue Type: Bug
> Affects Versions: Resource Merger 1.3.10
> Reporter: Henry Kuijpers
> Assignee: Konrad Windszus
> Priority: Major
> Fix For: Resource Merger 1.4.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Provided a failing test case here:
> https://github.com/apache/sling-org-apache-sling-resourcemerger/pull/3/files
> TODO: Fix
> When trying to configure a whitelisting approach to inheriting nodes from a
> parent (i.e. through resource super type, or through overlaying), the
> following way:
> /apps/base/test/tabs/undesired-tab
> /apps/base/test/tabs/desired-tab
> /apps/base/test/tabs/desired-tab/items/field@title="title"
> &
> /apps/overlay/test/tabs@sling:hideChildren="[!desired-tab,*]"
> /apps/overlay/test/tabs/desired-tab/items/field@description="test"
> One would expect that requesting the children of /merged/test/tabs would
> yield the "desired-tab" only, i.e. "undesired-tab" (and other nodes not
> whitelisted) being hidden. This is working as expected.
> One would also expect the "desired-tab" to have the properties of the
> base-structure as well as the properties of the overlay-structure. This is
> also working as expected.
> One would expect that the underlying nodes of "desired-tab" from the base
> would remain intact and would be merged with the underlying nodes of
> "desired-tab" in the overlay. So, while listing the items of desired-tab, one
> would expect:
> MergedResource containing properties [title=test, description=test]
> consisting of original resources
> [/apps/base/test/tabs/desired-tab/items/field,
> /apps/overlay/test/tabs/desired-tab/items/field]
> However, instead, the following is returned:
> MergedResource containing properties [description=test] consisting of
> original resources [/apps/overlay/test/tabs/desired-tab/items/field]
> So, the original "base" resource is not considered anymore!
> I believe the issue is in MergingResourceProvider.ParentHidingHandler, in the
> constructor, actually. At some point, it decides that the parent resource
> (which indeed has the sling:hideChildren property defined) defines an exclude
> entry which is "*" and adds that entry to the list.
> Then, when the class starts checking the parent of the parent (marked with
> "// also check on the parent's parent whether that was hiding the parent") -
> There it will find that asterisk exclude that was defined on the parent, not
> taking into account that it was preceded by a whitelisting "!desired-tab" -
> Removing the parent of the parent's children entirely.
> I believe this should be changed into a more robust way of handling this
> use-case. Probably the asterisk exclude can be global(?), even though it
> should still be desired that any child of the parent still is able to remove
> that exclude. But whenever those excludes are considered, also the includes
> that were preceding it should be considered to figure out if it's a real
> include in the case of that specific path.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
