On Wed, 22 Feb 2006, Alec Flett wrote:
Ted Leung wrote:
- There are other nasty issues around putting custom attribute name/
value pairs in the label field: what about conflicts with OOTB
attributes, what happens when stamping a new kind creates a conflict,
how do we validate input in this field, how do we parse and report
errors on complex values on non-text OOTB attributes (and what if they
contain commas, like dates eg "Feb 24, 2006", which are illegal in the
label field)? What about OOTB attributes that are references
(emailAddress lists, etc)?
This one is definitely on my list.
Andi said the other day "I have an idea about how to do custom attributes"..
Andi do you want to chime in?
Just to be sure we're talking about the same thing, I said I had an idea for
implementing support for ad-hoc attributes, that is, named values added by the
end-user at will for which there is no schema definition.
Because of that, ad-hoc attributes should be constrained in a way that makes
writing generic python programs around them simple:
- there need not be direct python-programmer 'item.attribute' syntax support
for them and they should live in a different namespace altogether
- all ad-hoc attribute values are items (bi-directional refs)
- all ad-hoc attributes are of cardinality 'list', that is, they are setup to
contain zero, one or more values
If these constraints are acceptable then the idea I was referring to the other
day is that ad-hoc attributes could be implemented with a new type of ref
collection I'm planning to add soon anyway, a dictionary of RefList. In other
words, adding support for having repository attributes of cardinality 'dict'
containing simple ref collections (of cardinality 'list')
How does this translate into support for ad-hoc attributes ? We'd add a new
pair of bi-directional ref attributes of cardinality 'dict' to the ContentItem
kind for containing any user-chosen ad-hoc attribute values. The keys in that
dictionary would be the ad-hoc attribute names and the corresponding values
would be simple ref collections containing their values.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
