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

[Christian Theune]

Hi,

Zagy and I are trying to make z3c.form compatible with sources. 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'.

- Most client code working against the `vocabulary` attribute actually
assumes it to be an IIterableVocabulary.

- 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.

- 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.

Conclusion:

We'd love to remove all traces of vocabularies from zope.schema and it
more clear how to use sources.

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. :/

Christian
--
gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle/saale - germany
www.gocept.com - ***@gocept.com - phone [phone] -
fax [phone] - zope and plone consulting and development

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20070927/175cff26/attachment.bin

[Stephan Richter]

Post by Christian Theune
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. :/

We use vocabularies exclusively. Not having BBB would be very painful for us.

Regards,
Stephan

[Philipp von Weitershausen]

Post by Christian Theune
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?

Post by Christian Theune
We had to investigate zope.schema for that and found the mess of vocabularies
and sources that is still around.
- 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'.
- 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.

Post by Christian Theune
- 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.
- The contract for the `vocabulary` attribute should be ISource.

+1

Making a contract more loose than it already is is always possible.

Post by Christian Theune
- 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...

Post by Christian Theune
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.

Post by Christian Theune
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...

[Christian Zagrodnick]

On 2007-10-01 21:41:36 +0200, Philipp von Weitershausen

Post by Philipp von Weitershausen

Post by Christian Theune
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?

Post by Christian Theune
We had to investigate zope.schema for that and found the mess of vocabularies
and sources that is still around.
- 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.

Post by Philipp von Weitershausen

Post by Christian Theune
- 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.

Post by Christian Theune
- 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.
- The contract for the `vocabulary` attribute should be ISource.

+1
Making a contract more loose than it already is is always possible.

Post by Christian Theune
- 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 ;)

Post by Philipp von Weitershausen

Post by Christian Theune
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.

Post by Philipp von Weitershausen

Post by Christian Theune
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....

[Philipp von Weitershausen]

Post by Christian Zagrodnick
Actually you cannot make sources more straightforward as
zc.sourcefactory made it.

I agree. It's very nice.

Post by Christian Zagrodnick
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.
IIterableVocabulary -> IIterableSource
IVocabularyTokenized -> ITerms (using multi adapter of (vocab, request))

That sounds like a sensible solution.

Post by Christian Zagrodnick
We also might think about not using choice.vocabulary but choice.source
... but that might break quite a lot more....

Yup, therefore -1.

Probably-my-last-post-to-zope3-dev-ly,
Philipp