Hi Lars, Thanks for elaborating and also the nice illustration, it helps alot.
Am Montag, den 29.10.2007, 11:25 +0100 schrieb Lars Trieloff: > For script resolution, we create a weighted list of candidate paths. > As soon as a script is found in a candidate path, we start looking for > refinements, or mixin-specific scripts. So far, so (almost) good. See my comments further ahead. > The first candidate is the path denoted by slingResouceType. If this > is not set, we resort to the primaryNode type. In fact, this is overkill as the slingResourceType is intended to be either set from a property or the primary node type if there is no such property. So just checking the SlingResourceType suffices it. > If there is no script > available, we build a graph of declaredSuperTypes and use the first > matching script. > > If two nodes in the graph have the same distance to the primaryType, > following rules are applied: > 1) nt:base has precedence over nt:unstructured I agree with David, that we should probably prefer nt:unstructured over nt:base as nt:base is the mother of all types > 2) built-in node types have precedence over nt:base In short: nt:base is only used as a last ressort and as such has lowest weight of all (taking my above note into account) > 3) user-defined node types have precedence over built-in node types If you can decide, which node types are user-defined and which are built-in and what you mean by "built-in"... This is somewhat hard to define as it may be the node types defined by the spec, or those additional node types defined by Jackrabbit or even those node types defined by Sling ... > 4) an alphabetical precedence ordering takes place Well, this is sort of like trying to resolve and unresolvable issue: As the order of mixins of a node as well as the order the supertype declaration of a node type definition is not defined, trying to add an order is fragile ... And just using alphabetic ordering does not make it any better: you will come up with types such as 000xyz:000file. > > In the case of a defined slingResourceType, we deal with mixins in the > following way: if there are sub-folders in the folder denoted by the > slingResourceType that have a naming pattern that matches the declared > mixin types, descend into these folders and try to find a script. A > deeper descend beats a more shallow descend, so for instance > /mix/referenceable/mix/versionable beats /mix/referenceable if two > scripts are found at the same level, the precedence rules expressed > above take place, so that > /mix/versionable/mix/userdefined beats /mix/referenceable/mix/ > versionable because of rule 3) Do you think, that rendering will be so much different for a node depending on whether it is versionable as to warrant a separate script ? BTW: Is it correct that the path build order is alphabetical by mixin type name. This would probably make sense in this situation (much more than above in step 4). Overall, I have to admit, that I come to think this is overkill :-) and it tends to get so complicated that (1) no-one will probably understand it and (2) it will be so expensive to calculate as to take the server down. So I would rather stay simple, clean and probably not as flexible as you propose at least in microsling. In Sling I would propose to also provide a simple default implementation just taking the slingResourceType into account. More complex implementations can still be devised and tried on Sling by just replacing the default implementation by a complex implementation. Regards Felix
