Hi,
Carsten Ziegeler schrieb:
> Hi,
>
> while changing the script resolution in the last days a little bit to
> make it cacheable, I stumbled across the handling of the resource super
> type.
> The jcr resource implementation checks if the node has the
> sling:resourceSuperType property and returns this value if existent.
> If not, it tries to find a resource under the search paths (usually libs
> and apps) with the resource type converted to a path. So if a resource
> has the type "a/b", the resources /apps/a/b and /libs/a/b are tested if
> they exist and contain a resource super type property.
>
> Other resource implementations like the bundle resource always returns
> null. The fs resource implemenations returns a special resource type for
> the resource super type.
>
> I think this behaviour is a little bit inconsistent.
I agree, that the behaviour of the Resource.getResourceType()
implementation for the bundle resource and filesystem resource
implementations is inconsistent.
The filesystem provider returns "sling/fs/resource" as its super type.
IMHO this is an interesting abstraction to apply common behaviour to
filesystem provided resources.
Therefore, I suggest we enhance the bundle resource provider to return
"sling/bundle/resource" as the resource super type.
> I would change it
> that if a resource does not know it's super type, it should return null.
So it is currently implemented and defined, IIUIC.
> So basically this effects the implementation of the jcr resource.
So the JcrNodeResource returns the value of the sling:resourceSuperType
property if set. If the property is not set, null is just returned. The
JcrPropertyResource returns null immediately, since a property does not
have a property.
> The script resolver already checks if the resource super type is null
> and then applies the above algoritm from the jcr resource as well.
The servlet resolver should first do a Resource.getSuperType(). After
that the resource type (or the resource super type) is used as the basis
for the ResourceUtil.getResourceSuperType(ResourceResolver, String)
method. Right ?
Consequently:
* ResourceUtil.getResourceSuperType(ResourceResolver, String) remains
as is resolving the resource super type as the supertype of the
resource type resource.
* ResourceUtil.getResourceSuperType(Resource) is removed, since it
brings no added value (it only has been added yesterday).
* JcrResourceUtil.getResourceSuperType(ResourceResolver, String) is
deprecated and is implemented calling the new
ResourceUtil.getResourceSuperType(ResourceResolver, String)
method.
* JcrResourceUtil.getResourceSuperType(Resource) is deprecated and is
implemented to call Resource.getSuperType() on the resource first
and then calling ResourceUtil.getSuperType(ResourceResolver,
resource.getResourceType()) as a fallback.
Is that what you had in mind ?
Regards
Felix
>
> Otherwise each resource implemenation should apply the algorithm to be
> consistent. But I would prefer the first solution.
>
> While the change is incompatible, I think this doesn't have any real effect.
>
> WDYT?
