Hi Felix,
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.
Ok. So this describes what microsling already does.
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)
Agreed.
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 ...
JCR Spec < Jackrabbit < Sling < User-defined
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.
Right. But alphabetic ordering is something everybody can understand,
this is why I chose it.
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 ?
Yes. You could think of these mixin-specific scripts as aspect-
oriented rendering. For example combining a mix:versionable with a
history-selector could result in a generic history visualization or a
mix:referenceable with a permalink-selector into a permalink
representation.
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).
No. The algorithm is descending the tree and finding the deepest node.
For nodes with same depth, the rules described above apply.
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.
It is probably too complicated, I agree. But I still think having a
level of inheriance and aspect-orientation in rendering is something
we want, because it eases the development process.
You can simply define a default rendering for a wiki page and override
this for special incarnations of wiki pages. And you could define a
default history-rendering for versionable resources and override this
only if necessary.
I think in most cases the resolution algorithm will come to an end
after a few iterations, what I outlined above are only the edge-cases.
Lars
