Hi, > Given the current documentation of the Resource interface and the > implementation of e.g. JcrNodeResource, I suggest that we document > Resource#getResoureSuperType() as follows: > > [The method #getResoureSuperType()] Returns the value of the > "sling:resourceSuperType" property of the current resource if > available. Otherwise it returns the super type of the type of the > resource (as per #getResourceType()) or null if the type has no super > type. > > Does that sound reasonable? This would us require to change the getResourceSuperType method of our implementations to do the lookup in the resource tree. So I think we should change the docs to state that this method only returns a value if the "sling:resourceSuperType" property is set. Although this property might be implementation specific, so we need some different wording :)
Looking back, I think adding the isResourceType method to the Resource interface was wrong as this is using information outside of the scope of the resource. getResourceType and getResourceSuperType return the information from a resource only if the resource has this information. If you want to get the (calculated) resource super type of a resource, we have methods on ResourceUtil to do the trick. (Although these don't work because the resource tree is read with the resource resolver from the passed resource). I have the feeling that we should clean up this area... Carsten > > Regards > Julian > > > On Mon, Feb 11, 2013 at 11:56 AM, Carsten Ziegeler <[email protected]> > wrote: >> Hi, >> >> 2013/2/11 Julian Sedding <[email protected]>: >>> When you say overriding, do you mean, it eliminates an inherited >>> resource type, or is it squeezed in between? Example: >> >> It elimantes, so it's: >>> >>> Option A (eliminates inherited super-type): type, local-super, >>> local-super-super >> >>> >>> Surely there are more possible options, however, I think these are the >>> most sensible ones. It might also be worthwhile considering, what >>> happens if the two hierarchies join back on a common ancestor... >> >> The whole type hierarchy handling is on demand, so there are no checks >> enforced, a wrongly setup type hierarchy could e.g. end up in an >> endless loop etc. >> >>> I think we need to keep the override-mechanism due to backwards >>> compatibility, so adjusting the JavaDocs seems sensible. However, I >>> would like to document that a local sling:resourceSuperType property >>> overrides the default behavior, which is the traversal of the >>> inheritance-hierarchy (as is currently documented). In addition, if we >>> decide for one of the above options, this should also be documented. >> Which two options are you refering to? :) >> >> Regards >> Carsten >> >>> This would allow using only the expected/intuitive case (i.e. not to >>> use any local overrides). At the same time this should provide a >>> backwards compatible solution. >>> >>> WDYT? >>> >>> Regards >>> Julian >>> >>> >>> On Mon, Feb 11, 2013 at 9:44 AM, Carsten Ziegeler <[email protected]> >>> wrote: >>>> Hi, >>>> >>>> I agree we have a mismatch here. The way we usually handle >>>> getResourceSuperType and how it is implemented is, that it returns a >>>> super type information only if the resource by itself has set this >>>> (for example for a jcr node if it has the property). The method does >>>> not evaluate the resource hierarchy. >>>> As far as I remember (this dates really long way back...) the idea is, >>>> that a resource can either specify a super type by itself - using this >>>> method or if it doesn't, the super type is evaluated using the type >>>> hierarchy from the resource tree. This allows for overriding the >>>> resource super type on a per resource base. >>>> >>>> However, I agree that this is a little bit unexpected - so I think we >>>> should update the javadocs of the Resource interface to reflect >>>> realitity. >>>> We could add a method to get the real super type like we have for the isA >>>> check. >>>> >>>> WDYT? >>>> >>>> Carsten >>>> >>>> 2013/2/11 Julian Sedding <[email protected]>: >>>>> Hello all >>>>> >>>>> I stumbled over a behavior in Resource#getResourceSuperType() that is >>>>> unexpected to me. I would like to clarify the contract of this method. >>>>> >>>>> The JavaDoc for Resource#getResourceSuperType() states "Returns the >>>>> super type of the type of the resource or null if the >>>>> getResourceType() has no supertype.". I'll illustrate my understanding >>>>> of this contract with a simple example. >>>>> >>>>> /content/resource [sling:resourceType="type"] >>>>> /apps/type [sling:resourceSuperType="super"] >>>>> /apps/super >>>>> >>>>> Now if I have an instance of the Resource at /content/resource and >>>>> call ist getResourceSuperType() method, I'd expect to get the string >>>>> "super" as the return value ("the super type of the type of the >>>>> resource"). >>>>> >>>>> However, the JcrNodeResource[0], and possibly more importantly its >>>>> test cases[1] (specifically testResourceSuperType()), implement a >>>>> behavior that differs from my understanding of the documented >>>>> contract. In the above scenario, >>>>> JcrNodeResource#getResourceSuperType() would return null, while the >>>>> scenario below would yield "super". >>>>> >>>>> /content/resource [sling:resourceType="type", >>>>> sling:resourceSuperType="super"] >>>>> /apps/type >>>>> /apps/super >>>>> >>>>> To me the documented contract is more intuitive, as that is how >>>>> inheritance generally works in my experience (i.e. my grandmother can >>>>> only be my grandmother transiently via one of my parents). However, >>>>> I'm curious to see whether others have other opinions. >>>>> >>>>> BTW, MongoDBResource#getResourceSuperType() seems to implement the >>>>> same contract that JcrNodeResource does. Additionally, also >>>>> ResourceUtil#findResourceSuperType() supports the logic implemented in >>>>> JcrNodeResource. >>>>> >>>>> I noticed this while implementing a possible fix for SLING-2708, which >>>>> is concerned with the ResourceUtil#isA() and Resource#isResourceType() >>>>> methods. Depending on the implementation of those methods (whether >>>>> they rely on Resource#getResourceSuperType() or not), they may yield >>>>> different results. >>>>> >>>>> Thank you for your comments. >>>>> >>>>> Regards >>>>> Julian >>>>> >>>>> >>>>> [0] >>>>> http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java >>>>> [1] >>>>> http://svn.apache.org/repos/asf/sling/tags/org.apache.sling.jcr.resource-2.2.0/src/test/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResourceTest.java >>>> >>>> >>>> >>>> -- >>>> Carsten Ziegeler >>>> [email protected] >> >> >> >> -- >> Carsten Ziegeler >> [email protected] -- Carsten Ziegeler [email protected]
