Hi, Tobias Bocanegra schrieb: > 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 think you are misunderstanding Alex here. He suggested a solution to his own problem of finden locations of scripts for his use case. This is not a proposal to require node types for Sling servlet resolution. > > 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. Alex agreed on that ;-) Regards Felix > > 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 >
