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 <[email protected]> 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 > >> <[email protected]> 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 >
