Alexander -
So here's where I've come to agree with you:
* Doing resource.isResourceType(nodeType) under the current
implementation is an anti-pattern and should be avoided.
The reason for that; under the current implementation it falls back to
checking the primary node type only if there is no resource type. So
even if the primary node type doesn't change it's resource type could,
invalidating a check that you are attempting to perform.
Where I am not sure:
* Complexity to Servlet resolution.
I don't have a deep understanding of the resolution process, so at this
point I'll have to assume you do and defer to your judgement :) I don't
see it how it could. Because if I am asking for a servlet to kick off on
a type, which I currently can do since the getResourceType defaults to a
nodeType, then I am doing it for a good reason. May not be a smart
reason but you could argue that for the resource type as well.
Where I disagree:
> BTW, you can handle the case yourself:
>
> Node node = resource.adaptTo(Node.class);
> if (node != null) {
> if (node.isNodeType(nt)) {
> // ...
> }
> }
This may be possible in CQ land where everything is backed by a
JcrNodeResource but as you pointed out in your code snippet
resource != node
resource != map
resource != anything in particular
Yet at the same time we have the File and the Bundle resource provider
explicitly setting resource type to a node type even though there is no
associated node.
Node Types are important, it defines a descriptor of the content,
without regard for the content itself. Maybe the problem is that
resource.getResourceType is defaulting to the primary type. Maybe it
should have returned null from the very beginning so that it's
explicitly tied to resource and not create a connection between resource
and node type.
In the end though, I'm stuck here trying to categorize by Type and
jumping though hoops to do so.
--
Jason
On Fri, Sep 12, 2014, at 04:16 PM, Alexander Klimetschek wrote:
> On 12.09.2014, at 10:55, Jason E Bailey <jason.bai...@24601.org> wrote:
>
> > 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.
>
> Yes, but it gets complicated when you look at the servlet resolution:
> which super type hierarchy has a higher precedence? The current weighting
> is already pretty complex.
>
> And I think enforcing more use of resource types and less node types here
> is a good thing :)
>
> > 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"
>
> BTW, you can handle the case yourself:
>
> Node node = resource.adaptTo(Node.class);
> if (node != null) {
> if (node.isNodeType(nt)) {
> // ...
> }
> }
>
> Cheers,
> Alex
