On 2008-08-30 16:54:57 +0200, "Roger Ineichen" <dev@projekt01.ch> said:
Hi Chritian
Betreff: Re: [Zope-dev] Make simple ISource usable
On Fri, 2008-08-29 at 15:01 +0200, Roger Ineichen wrote:
[...]
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 no one objects, I'll start a zope.schema branch and let you know
about the progress and a hopfully a simple solution. Additional to
them I started allready a z3c.form branch for adjust the ITerms
implementation. As far as I can see right now this refactoring will only provides
additional features.
What do you think? Any objections or hints about that?
Terms require access to a request. Any application's model
code should be happy to only deal with the values of sources.
I agree, ITerm lookup from an ISource should work without the request.
Terms are used to map values to the UI parts of an
application (by providing identification tokens and user
readable titles).
IMHO zope.schema doesn't need to know about terms.
I agree if you think about the ITerms adapter pattern like defined in zope.app.form using (source, request) as discriminators.
Which would be good. The term could very well be different in different skins, could it not? At least the title is language dependent (hm, okay, translation comes later...)
But zope.schema does already know about term. ITerm is a
part of zope.schema. ISource uses ITerm as items. But
No, ISource contains just "values", i.e. ISource can contain any python object. It doesn't even say that there must be a way to create a Term vor a value.
the only query API is ISourceQueriables. There is no
simple query API for work with terms.
You'd probably convert a term to a value and then look it up in the source. This of course works (inefficiently) for IIteralbeSources. But you cannot search a plain ISource (besides plain containment) so that's not a problem. Also it is good that ISource is not iterable, because it is of couse possible to define non-iterable sources.
I do agree that the whole issue of searching/querying sources
is currently underdesigned.
What do you think about an ITerm interface next to the ISourceQueriables interface. This interface could offer getTerm and getValue and offer a base for access none
queriable ISource implementations.
Of corse such a ITerms adapter for ISource doesn't adapt the request. The PrincipalSource ITerms implementation from zope.app.security doesn't even use the implemented request.
Probably we should named the new interface in zope.schema ISourceTerms instead of ITerms?
Wait. zope.schema really shouldn't know about terms. Terms are about the user interface, hence title/token. That has really *nothing* to do with zope.schema. For searching you don't need titles or tokens. For a search *UI* you do, but that doesn't belong to zope.schema either. Regards, -- Christian Zagrodnick · cz@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development