Hi Felix! On Fri, Nov 28, 2008 at 10:01 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > The problem is that a resource type in Sling is just a string which is > used to build a resource path to locate scripts. There is no more > semantics contained in resource types. > > In addition, given a script location of /libs/nt/folder and a search > path of [ /apps, /libs ], the resource types /libs/nt/folder and > nt:folder and nt/folder resolve to the same location but are three > distincts strings. > > In short, there is no list of resource types and it is not possible to > come with a conclusive list of such resource types.
You are right, it is an illusion to get a complete and correct list and it would require a complete tree traversal to build the list - since absolute paths are possible as resource types - which would make it a rather slow operation. I think the right solution then is to use primary node types or mixins to identify the types of resources that are in the system - which is also more standardized (part of JCR), allows listing via the node type registry and is more integrated with JCR observation, where you can listen for specific node types to have a focused filter on the lots of events that could happen. IMHO a good practice for sling apps is to always define a node type for all the resources (or at least a mixin) they will handle. This node type a) defines a sling:resourceType with a default value (but one that can be changed later) and b) which allows residual properties (for the full JCR flexibility - although YMMV here). Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
