Hi Christian
Betreff: Re: [Zope-dev] Make simple ISource usable
[...]
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...)
The ISource whould not be different in different skins. ISource must work ata python level without any interaction (request). This means you don't have a skin at that moment. I agree that you can do such crazy thing. But I guess we should not support that concept by default or we will never find an agreement with everybody on such an API. Yes, 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.
I Source contains nothing by default. ISource provides just a __contains__ method. This forces us to implement an explicit query API for ISource. One API is ISourceQueriable. We all agree that this API does not work wor any usecase. One soulution is, we provide special kind of ISource interfaces or we provide another query interface next to ISourceQueriable e.g.ISourceTerms or ITerms whihc let us implement an adapter for ISource which knows how to handle terms. The later is implemented in zope.app.form but that's not usable for others which do not use zope.app.form.
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.
Yes exactly, it's up to the developer how they implement something useful for handle ISource objects. If it comes to implement a widget framework is looks a little bit different. A widget framework can define an API which othter can use. ITerms in zope.app.form does that already. You can do what ever you need to do in such an ITerms adapter for access the ISource and return standard ITerm objects which the widget can handle. The ITrems is a standard API for handle ISource, doesn't nmatter how you will query or get our data form an ISource.
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.
That's inconsistent bcause, zope.schema provides ISourceQueriables that's exactly the same as ITerms whould define. ISourceQueriables and ITerms are an API to work with ISource. ISourceQueriables uses a queryable and ITerms could use ITerm objects. That's just a standard concept which defines how other packages can implement usable components to work with ISource. Right now other packages are using the ITerms interface from zope.app.form for implement a working component which can handle ISource objects. e.g. PrincipalSource. Regards Roger Ineichen
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
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )