[Seaside-dev] #decorationClasses preference
Julian Fitzell
jfitzell at gmail.com
Mon Jul 28 08:26:23 UTC 2008
Lukas,
As I look at the preference for decoration classes, I wonder how
useful it is. First of all, most of the decoration classes require
parameters to be set, so they can't be created just by knowing the
class.
Secondly, there's the issue of property value inheritance, which we
were discussing. While I can imagine an implementation of a collection
attribute value that allows additions and/or deletions from the
inherited value instead of just overriding it, the ordering of
decorations is going to be frequently very important. Plus, if you are
inheriting a value from several parents, how do you merge those (or do
you?)
If I try to picture an interface that lets you deal with merging
several inherited collections coming up with a working ordering, and
then defining deletions and insertions in the correct location so you
*still* have a correct ordering I just can't imagine how it would
work.
I'm inclined to drop that preference and add one that adds a tool
decoration, since that was presumably the immediate need.
Thoughts?
Julian
More information about the seaside-dev
mailing list