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 >>>> >>
