On 11/28/08, Alexander Klimetschek <[EMAIL PROTECTED]> wrote: > 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).
well, i think not :-) one power of sling is its flexibility when it comes to resource/script resolution. the hassle you have changing a node type is very big and defining a mixin does not make sense, since you normally create the node before you assign a mixin. changing a node type last is also troublesome - so i would stick to the very few nodetypes that are really needed. IMO you should only need 3: sling:Folder, nt:file for the hierarchy of the scripts, nt:unstructured for content. i still don't see the need for a list of all resource types. since each primary type, each node in /content, each node with a sling:resourceType property, each OCM mapped object can be a 'resource type'. so you would end up in a list of gazillion resource types which you would present in a UI ?? and if you just go for the scripts - you have a similar problem, since most of the scripts/servlets can render html. another issue you'll face is that you mandate that all the resources types need to provide a 'selector' script of you snippet. this is of course a natural idea, but results in problems as soon as you add more resource types. the new resource types needs to know about your snippet-selector and needs to provide one - otherwise it will destroy your snipped-aggregator. the only way to prevent this would be to extend it from your base resource type. regards, toby
