Hi Carsten
Agreed, Option A resembles the currently implementation most closely.
This also ensures that there is only a single inheritance hierarchy
(or line of inheritance), so there won't be any problems.
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?
Regards
Julian
On Mon, Feb 11, 2013 at 11:56 AM, Carsten Ziegeler <cziege...@apache.org> wrote:
> Hi,
>
> 2013/2/11 Julian Sedding <jsedd...@gmail.com>:
>> 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 <cziege...@apache.org>
>> 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 <jsedd...@gmail.com>:
>>>> 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
>>> cziege...@apache.org
>
>
>
> --
> Carsten Ziegeler
> cziege...@apache.org
