Hi Tobi! On Sun, Nov 30, 2008 at 9:42 PM, Tobias Bocanegra <[EMAIL PROTECTED]> wrote: > 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.
As Felix correctly mentioned, you misunderstood me. I don't want to change the servlet resolution of Sling, nor do I want a list of resource types anymore. The discussion with Felix on this topic just pointed me to (my personal) "good practice for sling apps" as mentioned. Basically I propose to use node types when there is a need (as in my use case) for a listing of "resource types" in the repository, that goes beyond what Sling can offer itself. Since I prefer the unstructured way of jcr as well, I think it is good to use mixins on nt:unstructured or to allow residual properties in the custom node types, as I mentioned. Regards, Alex -- Alexander Klimetschek [EMAIL PROTECTED]
