Hi Carsten Thanks for your comments.
> This allows for overriding the > resource super type on a per resource base. When you say overriding, do you mean, it eliminates an inherited resource type, or is it squeezed in between? Example: /content/resource [sling:resourceType="type", sling:resourceSuperType="local-super"] /apps/type [sling:resourceSuperType="inherited-super"] /apps/local-super [sling:resourceSuperType="local-super-super"] /apps/inherited-super [sling:resourceSuperType="inherited-super-super"] Which would be the "correct" inheritance hierarchy in this example? Option A (eliminates inherited super-type): type, local-super, local-super-super Option B (injects local super-type) : type, local-super, inherited-super, inherited-super-super Option C (injects local-super-type hierarchy: type, local-super, local-super-super, inherited-super, inherited-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... > 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. 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. 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]
