[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