On 2008-08-30 16:54:57 +0200, "Roger Ineichen" <[EMAIL PROTECTED]> 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 · [EMAIL PROTECTED]
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 )

Reply via email to