Re: Revisiting the resource super type handling
On Fri, Jun 26, 2009 at 10:30 AM, Carsten Ziegelercziege...@apache.org wrote: 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 would change it that if a resource does not know it's super type, it should return null. So basically this effects the implementation of the jcr resource. The script resolver already checks if the resource super type is null and then applies the above algoritm from the jcr resource as well. 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. i agree that the resource should not know about search paths. imo, the resource resolver should be used for 'resolving' the resource super type. regards, toby
Re: Revisiting the resource super type handling
Hi, Tobias Bocanegra schrieb: On Fri, Jun 26, 2009 at 10:30 AM, Carsten Ziegelercziege...@apache.org wrote: 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 would change it that if a resource does not know it's super type, it should return null. So basically this effects the implementation of the jcr resource. The script resolver already checks if the resource super type is null and then applies the above algoritm from the jcr resource as well. 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. i agree that the resource should not know about search paths. imo, the resource resolver should be used for 'resolving' the resource super type. Actually, the ResourceResolver *is* used to resolve the super type from a resource type resource: // resource type rel path, e.g. nt/file String path = resourceTypeToPath(resourceType); // resolve resource type resource Resource rtResource = resourceResolver.getResource(path); The getResource method applies the current search path as described and required and requested. Regards Felix
Re: Revisiting the resource super type handling
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?
