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 · [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 ) > _______________________________________________ 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 )
