> > Just to try and understand this better - you're saying that instead of > Sling falling back to the jcr:primaryType property in case of JCR > resources, the JCR resource provider should instead synthesize that > property itself, even if it does not exist? > > Robert >
Right now there is an inconsistency between resources that are in the jcr and resources that are in other resource providers. That inconsistency is that all jcr resources have a jcr:primaryType. This is understandable because the jcr has a Type system and there is a defined hierarchy of types in the jcr that all lead back to nt:base. The fact that there is always a type is exploited by the ResourceResolver so that it falls back to checking the jcr:primaryType if there is no resourceType. This becomes problematic with ResourceProviders because initially, there was never a requirement for them to provide either. There has been talk recently about creating a type system for resources. https://cwiki.apache.org/confluence/display/SLING/Sling+Type+System%3A+motivation+and+requirements. For there to be a proper type system you need to have a Type hierarchy. Right now the getResourceType no longer allows you to return null, so it must return something, if you're creating a resource provider that could be a value that represents a "fake" resource. In a type system that doesn't make sense. If we implement a Sling Resource Type system we will be left with two options 1. All resources must have a valid sling:resourceType associated with it 2. Or consider a default sling:resourceType if none is present. -Jason
