Re: TreeVocabulary in zope.schema.vocabulary
"Charlie Clark" <[email protected]>
| Newsgroups | gmane.comp.web.zope.devel |
|---|---|
| Organization | Clark Consulting & Research |
| Message-ID | <[email protected]> |
Hiya, Am 30.01.2012, 14:33 Uhr, schrieb Jan-Carel Brand <[email protected]>: ... 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 >> do >> 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 > <snip> > >> >> 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 >> is a >> 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 it. ;-) Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 _______________________________________________ Zope-Dev maillist - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )