[Zope3-dev] Re: ChoiceField and the use of sources/vocabularies

[Christian Zagrodnick]

On 2007-10-01 21:41:36 +0200, Philipp von Weitershausen 
<philipp at weitershausen.de> 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