Alexander,
I have a hard time understanding how there would be added complexity by
incorporating the nodeType hierarchy into a determination as to whether
a specific resource is of a specific type. Multiple hierarchies are
fairly common in programming languages, like the instanceof I mentioned
that does both the class hierarchy and the interface hierarchy. I also
don't see much confusion occurring from implementing this. If I am
attempting to validate a whether something is inherited from nt:base I
clearly have a need in mind that would be separate from desire to know
if it's a sling component that inherits from foundation/list
I would like to use resources as much as possible :) The flexibility
however ends when I need to validate an associated nodeType,
--
Jason
On Thu, Sep 11, 2014, at 03:09 PM, Alexander Klimetschek wrote:
Sling resource types have their own super type hierarchy. Using jcr node
types if no sling:resourceType is specified was added as a fallback for
cases where it is impractical to set a sling:resourceType. But it does
not take into account the node type hierarchy, I think because it would
simply be too complex, since you then have to look at two hierarchies.
I would use sling resource types as much as possible over node types,
since they are a lot more flexible.
HTH,
Alex
On 11.09.2014, at 14:54, Jason E Bailey jason.bai...@24601.org wrote:
I understand the difference between the Sling Resource Type and the JCR
Node type. However the resource.isResourceType is not specifically
dealing with one or the other. If I had a resource of a node with a
primaryNodeType of nt:file then doing resource.isResourceType(nt:file)
would return true.
I had to dig through the code to see what was going on.
The basic idea is that calling resource.getResourceType() will return
the sling:resourceType and if that's not there then it will return the
jcr:primaryType. When calling isResourceType it will compare against
the resource.getResourceType() and if that's not a match will march of
the chain of getSuperResourceType looking for a match, and that matches
only against the sling:resourceType.
I can sorta see where that's useful from a script resolution point of
view. I find it odd overall as it's missing out on a section of
inheritance. It's like having a java instanceof operator ignoring
interfaces.
--
Jason
On Wed, Sep 10, 2014, at 01:13 PM, Paul McMahon wrote:
There isn't necessarily a mapping between Sling Resource Type and the JCR
Node type. The sling resource type is determined based on the value or
the sling:resourceType property on the node, where as the JCR Node type
is determined based on jcr:primaryType value. In most cases nodes of
sling:resourceType will always be the same jcr:primaryType, but technical
that isn't a requirement. In reality there are most jcr:primaryTypes map
to many different sling:resourceType (or no sling resource type).
Paul McMahon
Acquity Group, Part of Accenture Interactive
On Wednesday, September 10, 2014 9:56 AM, Jason E Bailey
jason.bai...@24601.org wrote:
Lets say I have a node of type sling:Folder.
Calling
node.isNodeType(nt:folder)
will return true, since sling:Folder extends nt:folder
However
resource.isResourceType(nt:folder)
will return false. I'm assuming since it's attempting to
resolve up the resource heirarchy(?)
My question, is there a Foo utility to determine if a given
resource is of a particular type via the node definition?
TIA.
--
Jason E Bailey
