Hi, Carsten Ziegeler schrieb: > Felix Meschberger wrote: >> 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. > +1, I'll do the change. > >>> 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. > No, see below. > >>> 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. > No, the JcrNodeResource does the lookup of the resource type if it does > not have a super type atm.
Hmm, maybe my description is about the desired state not about the current reality ;-) > >> 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 ? > Yes, exactly. > >> Consequently: >> >> * ResourceUtil.getResourceSuperType(ResourceResolver, String) remains >> as is resolving the resource super type as the supertype of the >> resource type resource. > Yes. > >> * ResourceUtil.getResourceSuperType(Resource) is removed, since it >> brings no added value (it only has been added yesterday). > Yes, I thought this, too. > >> * JcrResourceUtil.getResourceSuperType(ResourceResolver, String) is >> deprecated and is implemented calling the new >> ResourceUtil.getResourceSuperType(ResourceResolver, String) >> method. > Yes > >> * 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. > Yes > >> Is that what you had in mind ? > With the addition that JcrNodeResource returns null for the super type > if it doesn't have the property. Yes, as I described above the "desired state". Regards Felix > > Carsten >> 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? >> >> > >
