[Zope-dev] Make simple ISource usable

[Jim Fulton]

On Aug 29, 2008, at 9:01 AM, Roger Ineichen wrote:

> I'll try to make the ISource API smooth and usable
> for other components. Right now ISource provides no
> simple API for work with terms.
>
> Since a ISource only provides a __contains__ method
> and the IterableSource the __iter__ method,
> there is some more needed which makes it easy to
> work with terms next to the ISourceQueriables API.
>
> The zope.app.form.browser.interfaces.ITerms
> defines one possible way to make it work
> like a vocabulary because it defines the methods
> getTerm(value) and getValue(token).
>
> The z3c.form.interfaces.ITerms defines also
> such a query API but right now only or vocabularies.
>
> I propose to define such a ITerms interface in
> zope.schema.interfaces which makes it possible
> to implement simple ISource terms and work with
> the ITerm values like we do in vocabularies.

I'm not in favor of adding UI-support interfaces to zope.schema.  The  
presense of terms in zope.schema.interfaces was a mistake.


> This whould not affect other implementations like
> the ISourceQueriables etc. It only offers the
> a way to implement reusable simple ISource components
> without the need that every UI framework needs to
> implement their own interfaces for query ISource
> component in their own way (e.g. ITerms).

Why can't they use zope.app.form.interfaces.ITerms


> The current state of ISource/ITerms concept whould not
> work if someone will switch form zope.app.form based
> sources to z3c.form based sources because of it's
> different ITerms implementations.

Why? If the interface is the same, why does it matter if the  
implementations differ.

> Or if someone defines a zope.schema.ISource in a 3rd party
> package, the zope.app.form.browser.interfaces.ITerms is
> often used for query ITerms even if it's only used in python
> code without any form framework. That's a real bad dependency.

Why?

> Fazit,
> The only query API defined for ISource in zope.schema
> is the ISourceQueriables API. That's defently to less
> and makes it required to implement custom query APIs
> in UI frameworks if we need to work with terms.

I'm not convinced that a more specific API, except maybe one based on  
simple search strings will be generally useful.  An earlier attempt to  
define a query interface was a disaster.

> I no one objects, I'll start a zope.schema branch and
> let you know about the progress and a hopfully a simple
> solution.

I object.

Jim

--
Jim Fulton
Zope Corporation