Am 30.01.2012, 14:33 Uhr, schrieb Jan-Carel Brand <li...@opkode.com>:
... lots cut ...
Yes, the values must be unique, because we do value lookups.
The "title" attr doesn't have to be unique though. You could have a
"Forestry" department for two different regions. The title will be the
same, but the value and token attrs can't.
I think the tests should be extended to show that this also includes
nesting because this is non-obvious. ie. I believe that the region "Izmir"
is within the state of "Izimir" in Turkey.
This should be possible by calling _getPathToTreeNode during one
of the passes through _flattenTree. getTermPath would then just need to
a lookup on this.
I don't like the way the path_node gets implicitly populated during a
call to _flattenTree.
hm, okay. Personally, I think you should be able to populate your
dictionaries with only a single pass through the terms. However, as this
only needs to happen when the application starts we don't need to worry
too much about the performance.
I'd rather have a separate method that calculates the path and then
explicitly assign it to self.path_node.
In any case, there is now a node_index in the code
>> but I don't see the advantage of
>> cls.createTerm(*args) over SimpleTerm(*args)
> See above. "createTerm" is there to let developers override it and
> provide their own term objects.
Do you have a concrete use case for this?
Not really, but that doesn't mean it doesn't exist.
Then someone will speak up for it if they need it or do their own
subclassing/composition as required. Otherwise it's just food for warts.
Remember that createTerm is a
convenience method only. Frankly, I don't see the need for it in what
fairly specialised class.
I like consistency and symmetry, so if SimpleVocabulary has it, as an
add-on developer I'd expect for TreeVocabulary to also have it.
I don't however feel very strongly about it though, and I wanna get this
done, so I removed it.
Well, we could always think about removing it from SimpleVocabulary: it's
not in the interface so no subclass actually has the right to depend on
Clark Consulting & Research
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -