+1 for clarifying and fixing the meaning of sling:hideChildren and sling:hideProperties. I think it is much more intuitive that it only affects the inherited children and properties.
Regards Julian On Wed, Feb 3, 2016 at 11:41 AM, Konrad Windszus <[email protected]> wrote: > I was still thinking about the original problem: > What is a use case for hiding local properties/resources? > > I could only come up with one use case actually: > You rely on sling:resourceSuperType for the OverridingResourcePicker and > don't want to expose that property in the merged view! > For that you could use sling:hideProperties="sling:resourceSuperType" because > that will hide the local property as well as the property with that name from > all of the underlying resources. > Just removing that property from your resource is not an option here (because > it is important for the merging itself). > > Since this is not a very convincing use case I would propose to just change > the meaning of sling:hideChildren and sling:hideProperties to only act on the > underlying resources. This affects the wildcards as well as the case where > you give individual names as values. > The only exception would be sling:hideResource as that will hide the local as > well as the underlying resources of that name. > > That way it is easy to completely disable inheritance (by setting both > sling:hideProperties=* and sling:hideChildren=*), which is IMHO a much more > common use case. > > I will propose a patch in SLING-5468. > Konrad > > >> On 03 Feb 2016, at 08:43, Julian Sedding <[email protected]> wrote: >> >> Hi Konrad >> >> I read through the page. Good job! It looks fine and I didn't spot any >> error. (Not that I am an authority on the Resource Merger...). >> >> Regards >> Julian >> >> >> On Tue, Feb 2, 2016 at 7:54 PM, Konrad Windszus <[email protected]> wrote: >>> I contributed some documentation in >>> http://sling.staging.apache.org/documentation/bundles/resource-merger.html >>> <http://sling.staging.apache.org/documentation/bundles/resource-merger.html>. >>> Would you be so kind and quickly cross-check? >>> I would still be interested though in someone else’s opinion on how the >>> sling:hideProperties=* is supposed to work. >>> Thanks >>> Konrad >>> >>> >>>> On 29 Jan 2016, at 18:09, Julian Sedding <[email protected]> wrote: >>>> >>>> There is some more documentation at >>>> https://github.com/gknob/sling-resourcemerger, where the feature was >>>> originally developed. Haven't had time to read it yet. >>>> >>>> Regards >>>> Julian >>>> >>>> On Fri, Jan 29, 2016 at 6:02 PM, Konrad Windszus >>>> <[email protected]> wrote: >>>>> As being suggested by Julian Sedding in >>>>> https://issues.apache.org/jira/browse/SLING-5468 I want to get your input >>>>> on how the properties >>>>> "sling:hideProperties=*” and "sling:hideChildren=*” are supposed to work >>>>> in the Sling Resource Merger. >>>>> >>>>> At least for the OverridingResourcePicker using the wildcard hides both >>>>> the local as well as the inherited resources/properties. This is causing >>>>> some trouble as that way I cannot easily replace the whole resource >>>>> without considering any underlying resources. >>>>> The only documentation about those properties is at >>>>> https://issues.apache.org/jira/browse/SLING-2986?focusedCommentId=13802834&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13802834 >>>>> but that does not really explain how those should behave in terms of >>>>> inheritance. Also the implementation changed quite a bit due to the >>>>> refactoring being done in >>>>> https://issues.apache.org/jira/browse/SLING-3423. >>>>> >>>>> For me this looks rather like a bug because I cannot come up with a good >>>>> use case where you would be interested to even hide your own/local >>>>> properties/child resources. Those properties should IMHO always refer >>>>> only to the inherited/underlying resources/properties but not to the >>>>> local ones (i.e. the ones next to the resource defining >>>>> sling:hideProperties or sling:hideChildren. >>>>> WDYT? >>>>> >>>>> Thanks for your input, >>>>> Konrad >>>>> >>> >
