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]
