On 2/21/13 7:25 AM, "Carsten Ziegeler" <[email protected]> wrote:
>2013/2/21 Felix Meschberger <[email protected]>: >> >> What hierarchy ? >> >> ResourceUtil.getSuperType(Resource) first asks the resource for a super >>type and then falls back to >>ResourceUtil.getResourceSuperType(ResourceResolver, String) which uses >>the resource type as a resource and checks that. >> >> But yes, the JcrNodeResource does not do this. We should maybe fix this >>by calling ResourceUtil.getResourceSuperType(ResourceResolver, String) >>if there is no super type property ? Or maybe something else ? > >I think we changed this some time ago to exactly not do this - can't >remember why. So the current behaviour should be >Resource#getResourceSuperType only returns a value if the resource by >itself knows the super type (for jcr resources this means if it has >this property). I'm not sure if we should change this. > >> >> In fact, looking at the ResourceUtil.getSuperType(Resource) method, >>this should be changed to call into the new ResourceResolver method >>which in turn gets back to the >>ResourceUtil.getResourceSuperType(ResourceResolver, String) with the >>admin resolver. > >Yes, while implementing this :) I just noticed that we need three >methods on the ResourceResolver (notice I now name the method >getResourceSuperType :) ): > String getResourceSuperType(final Resource resource); > String getResourceSuperType(final String resourceType); > boolean isResourceType(final Resource resource, final String >resourceType); On a related note (IMHO), we ran into a separate irritating problem with SlingServletResolver where the wrapped resource becomes "untestable" using ResourceUtil.isA() AFTER a call to adaptTo(), because the wrapper delegates to the original resource whose resolver has no access to the types. (see SLING-2708) I think that: - adding ResourceResolver.isResourceType() - replacing some usages of ResourceUtil.isA() with ResourceResolver.isResourceType() Would fix this. So +1 to these changes :) > >Now, the corresponding three methods on ResourceUtil can be deprecated >and call the ResourceResolver methods instead. >The AbstractResource#isResourceType(String) method can be changed to >call the method on the ResourceResolver as well > >The final question is the first point in this mail - do we leave the >implementations of Resource#getResourceSuperType() as is (= returning >null if they don't know it) or do we change that to call the >ResourceResolver#getResourceSuperType? In the first case, we need to >clarify our docs, in the second we need to change the impls (and >clarify the docs) I would prefer Resource.getResourceSuperType() return null when the property is not set. I am trying to think of use cases that would get the super type, other than script resolution (internal to sling), or cases that are testing for type ancestry (which should ONLY use ResourceResolver.isResourceType()), so not sure where this comes up in an application use case? Thanks Tyson > >Regards >Carsten >-- >Carsten Ziegeler >[email protected]
