[Zope-dev] Make simple ISource usable

[Roger Ineichen]

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 at 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 at 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 )
>