On 2007-10-01 21:41:36 +0200, Philipp von Weitershausen
<[EMAIL PROTECTED]> said:
Christian Theune wrote:
Zagy and I are trying to make z3c.form compatible with sources.
Shrug... Why wouldn't it be compatible already? Shouldn't the widget
abstract everything away?
We had to investigate zope.schema for that and found the mess of vocabularies
and sources that is still around.
Here are some facts we found:
- The Choice field has an attribute `vocabulary` which it says to be an
'IBaseVocabulary' object.
- Reading the code of the choice field turns out that the actual
contract is an 'ISource'.
Actually it behaves as follows:
choice.vocabulary is either ISource or None
if choice.vocabulary is None, choice.vocabularyName will not be none,
but that's an internal.
If the field is *bound* bound.vocabulary will be ISource in any case.
- Most client code working against the `vocabulary` attribute actually
assumes it to be an IIterableVocabulary.
That should be fixed then. Adaption to some iteration interface seems sensible.
- The vocabulary code is badly entangled and mixes up concepts that
sources get right.
- Widgets for the choice field have to react differently to sources and
vocabularies.
We think:
- The contract for the `vocabulary` attribute should be ISource.
+1
Making a contract more loose than it already is is always possible.
- Client code (e.g. a widget) should adapt the generic source it gets to
a more specific and richer interface like IIterableSource.
- Widgets for the choice field shouldn't have to care for two different
things that the source could be.
- Vocabularies ought to die.
No can do. But perhaps we can keep the amount of BBB dance as small as
possible. Vocabularies are just special ISource implementations. They
should work, even if they mix stuff. Mixing stuff isn't forbidden...
Well ... producing terms is so boring I'd not want to do it ;)
We'd love to remove all traces of vocabularies from zope.schema and it
more clear how to use sources.
+1 to making sources more straightforward.
Actually you cannot make sources more straightforward as
zc.sourcefactory made it.
As deprecation has fallen out of favor, we wonder how to get rid of
vocabularies. We definitely do not want to fork zope.schema. Would a
sufficiently newer version (3.5, 4?) rectify breaking something in this
way?
I estimate that providing BBB is going to be a real pain. :/
So pain it is...
So, when the contract is ISource, a widget would need to adapt
choice.vocabulary to IIterableSource to get the values. For terms it
should multiadapt (choice.voabulary, request) to
zope.app.form.browser.interfaces.ITerms.
There probably could be standard adapters for:
IIterableVocabulary -> IIterableSource
IVocabularyTokenized -> ITerms (using multi adapter of (vocab, request))
We also might think about not using choice.vocabulary but choice.source
... but that might break quite a lot more....
--
Christian Zagrodnick
gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
