Hi, Carsten Ziegeler schrieb: > Tobias Bocanegra 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'm wondering what our (= Sling's) suggestion as a good practice for > building own apps is? Define node types or use the sling:resourceType > property with nt:unstructured? Of course each use case is different and > might require a different solution.
Basically, Sling does not care for the actual node types. It just tries to get the sling:resourceType property, if this is missing the pluggable resource type resolver are called. If this does not resolve either, the primary node type is used. On the other hand, to help in the creation of nodes with setting the sling:resourceType property, Sling provides the sling:Resource mixin node type, which just defines the sling:resourceType property. Likewise there is a sling:ResourceSuperType mixin which defines the sling:resourceSuperType property. Final words: * Sling doesn't care for the actual node type * Sling helps setting the property providing a mixin node type for such nodes, whose actual node type prevents setting the sling:resourceType property. Hope this helps. Regards Felix
