On 2016-08-02 09:41, Konrad Windszus wrote:
I think sling:resourceTypesWithChildren is the clearest suggestion up to now ([1] gives an example). From a pure user point of view, the terms "parent" or "ancestry" would be rather misleading, because what is matched by the restriction in the end are nodes below (and not above) the matched node with the given resource type, e.g. the restriction matches a node with resource type "myproj/news" with (or including) all children.
For me the matched node is the one I want to modify/insert, not the one carrying the ACE with the restriction.
correct - the node carrying the ACE is the upper boundary of possible matches (this is oak standard for all restrictions and does not really have to be repeated)
Maybe we should clarify that even more in the documentation, because when it comes to applying ACEs you are dealing with two different nodes: the one you try to modify and the one where the ACE is set (this is not necessarily the same node).
We have "Naturally (as with any oak restrictions), the rule is limited to its base path. In case the node /content/myprj/othernode is of resource type myproj/comp1, it will still not match." in the documenation, but I'm sure it can be improved...
For me the documentation at [1] is not clear enough in that regard, especially how inheritance is being treated. On which level is the resourceType being compared? On the level where the ACE is set or on the matched node level?
Like for all oak restrictions, any ACE is only applied if all given restrictions apply. sling:resourceTypesWithChildren (or probably better sling:resourceTypesWithDescendants) will be clever and also match descendants, even if it is not a direct match of a particular node.
@Konrad regarding the naming, which one of the following would you prefer?
- sling:resourceTypesDeep <-- less descriptive but also shorter - sling:resourceTypesWithDescendants <-- I think clearer, but longer Regards Georg
