I'll try to make the ISource API smooth and usable for other components. Right now ISource provides no simple API for work with terms. Since a ISource only provides a __contains__ method and the IterableSource the __iter__ method, there is some more needed which makes it easy to work with terms next to the ISourceQueriables API. The zope.app.form.browser.interfaces.ITerms defines one possible way to make it work like a vocabulary because it defines the methods getTerm(value) and getValue(token). The z3c.form.interfaces.ITerms defines also such a query API but right now only or vocabularies. I propose to define such a ITerms interface in zope.schema.interfaces which makes it possible to implement simple ISource terms and work with the ITerm values like we do in vocabularies. This whould not affect other implementations like the ISourceQueriables etc. It only offers the a way to implement reusable simple ISource components without the need that every UI framework needs to implement their own interfaces for query ISource component in their own way (e.g. ITerms). The current state of ISource/ITerms concept whould not work if someone will switch form zope.app.form based sources to z3c.form based sources because of it's different ITerms implementations. Or if someone defines a zope.schema.ISource in a 3rd party package, the zope.app.form.browser.interfaces.ITerms is often used for query ITerms even if it's only used in python code without any form framework. That's a real bad dependency. Fazit, 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? Regards Roger Ineichen _____________________________ Projekt01 GmbH www.projekt01.ch Boesch 65 6331 Hünenberg phone +41 (0)41 781 01 78 mobile +41 (0)79 340 52 32 fax +41 (0)41 781 00 78 email roger.ineichen@projekt01.ch _____________________________ END OF MESSAGE
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. 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 do agree that the whole issue of searching/querying sources is currently underdesigned. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
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. But zope.schema does already know about term. ITerm is a part of zope.schema. ISource uses ITerm as items. But the only query API is ISourceQueriables. There is no simple query API for work with terms.
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? Regards Roger Ineichen
Christian
-- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
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
On Sun, Aug 31, 2008 at 10:23:00PM +0200, Christian Zagrodnick wrote:
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.
Are you arguing that zope.schema.Field should not have a title attribute? Marius Gedminas -- As far as we know, our computer has never had an undetected error. -- Weisert
On Sun, 2008-08-31 at 16:51 -0400, Marius Gedminas wrote:
On Sun, Aug 31, 2008 at 10:23:00PM +0200, Christian Zagrodnick wrote:
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.
Are you arguing that zope.schema.Field should not have a title attribute?
IMHO he is not. To me that idea feels like architecture astronaucy. However, I think we do have a couple of cases where the field's title doesn't directly become the widget's title. But then again, a static title that doesn't tie the schema framework to the interaction is fine by me. I guess there's some 80/20 rule at work here. Or at least 99/1. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Christian
Betreff: Re: [Zope-dev] Make simple ISource usable
On Sun, 2008-08-31 at 16:51 -0400, Marius Gedminas wrote:
On Sun, Aug 31, 2008 at 10:23:00PM +0200, Christian Zagrodnick wrote:
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.
Are you arguing that zope.schema.Field should not have a title attribute?
IMHO he is not. To me that idea feels like architecture astronaucy. However, I think we do have a couple of cases where the field's title doesn't directly become the widget's title.
But then again, a static title that doesn't tie the schema framework to the interaction is fine by me.
I guess there's some 80/20 rule at work here. Or at least 99/1.
Moving ITerms to zope.schema, even if we skip the request as adapter discrimintator, can offer support for your 20% or 1%. This let us implement ITerm or title tokenized term adapter based on a standard ITerms interface for ISource. I'm not 100% sure, but it looks to me that if you use zc.sourcefactory every ISource implementation from you will 100% depend on ITerms if it comes to widgets, doesn't matter if you use title token term or what ever. You don't have to implement that part because zc.sourcefactory does it for you. Can you agree that every ISource implementation based on zc.sourcefactory depends on ITerms from zope.app.form. Take a look at MappedTerms in zc.sourcefactory.browser.mapping. I guess this mapping is used for any zc.resourcefactory implementation. right? I'm not sure because I don't use that package right now. Regards Roger Ineichen
Christian
-- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
On 2008-08-31 22:51:38 +0200, Marius Gedminas <marius@gedmin.as> said:
On Sun, Aug 31, 2008 at 10:23:00PM +0200, Christian Zagrodnick wrote:
Wait. zope.schema really shouldn't know about terms. Terms are about=20 the user interface, hence title/token. That has really *nothing* to do=20 with zope.schema. For searching you don't need titles or tokens. For a=20 search *UI* you do, but that doesn't belong to zope.schema either.
Are you arguing that zope.schema.Field should not have a title attribute?
No no no, sorry :) I only don't see why I need titles for a source all the time. If you need both tied toogether (which frankly quite often is the case) zc.sourcefactory does the right thing (for me). If you just need to define a set of values you can just define the source (i.e. __contains__). -- 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
Hi Christian
Betreff: Re: [Zope-dev] Make simple ISource usable
[...]
Are you arguing that zope.schema.Field should not have a title attribute?
No no no, sorry :)
I only don't see why I need titles for a source all the time. If you need both tied toogether (which frankly quite often is the case) zc.sourcefactory does the right thing (for me). If you just need to define a set of values you can just define the source (i.e. __contains__).
You've got the point zc.sourcefactory does the right thing for you. Do you know why? It uses the bridge to the widget world. It offers component from ISource to ITerms. e.g. class MappedTerms(object): """A terms implementation that knows how to handle a source that was created through a source factory. """ zope.interface.implements(zope.app.form.browser.interfaces.ITerms) This very important ITerms interface which other widget framework can use should be a part of zope.schema and not zope.app.form Right now only the zope.app.form offering the missing part and makes the ISource working. I don't think every widget framework should depend on zope.app.form. And other framework can not reuse zc.sourcefactory because z3c.form will never depend on zope.app.form. Right now it's a of; If we move ITerms from zope.app.form, then we can useit in z3c.form and reuse all existing ISource implementations whihc offer ITerms support within z3c.form out of the box. If this interface will stay in zope.app.form we never can use such ITerms/ISource component. Of corse we could remove the request as a required adapter discriminator from ITerms by default. Regards Roger Ineichen
-- 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 )
On Aug 31, 2008, at 4:51 PM, Marius Gedminas wrote:
On Sun, Aug 31, 2008 at 10:23:00PM +0200, Christian Zagrodnick wrote:
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.
Are you arguing that zope.schema.Field should not have a title attribute?
I don't think title is in the same class. Jim -- Jim Fulton Zope Corporation
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 )
Hi, sorry for removing all the quotes, but I need to clarify your baseline question a bit. On Sun, 2008-08-31 at 23:23 +0200, Roger Ineichen wrote:
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.
This sounds like you want to implement something different than ITerms but that you see a structural similarity between what you want and what ITerms already do. I think this causes some confusion (and resistance by my side) right now. Can you try to phrase what you want to achieve and maybe not use the word 'ITerms' (for now)? Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
On 2008-09-01 06:58:16 +0200, Christian Theune <ct@gocept.com> said:
Hi,
sorry for removing all the quotes, but I need to clarify your baseline question a bit.
On Sun, 2008-08-31 at 23:23 +0200, Roger Ineichen wrote:
Yes exactly, it's up to the developer how they implement something useful for handle ISource objects. =20 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. =20 The ITrems is a standard API for handle ISource, doesn't nmatter how you will query or get our data form an ISource.
This sounds like you want to implement something different than ITerms but that you see a structural similarity between what you want and what ITerms already do.
I think this causes some confusion (and resistance by my side) right now.
Can you try to phrase what you want to achieve and maybe not use the word 'ITerms' (for now)?
Right. What's the difference from the ITerms we have now? Why do I need it? -- 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
Hi Christian
Betreff: Re: [Zope-dev] Make simple ISource usable
[...]
This sounds like you want to implement something different than ITerms but that you see a structural similarity between what you want and what ITerms already do.
I think this causes some confusion (and resistance by my side) right now.
Can you try to phrase what you want to achieve and maybe not use the word 'ITerms' (for now)?
Right. What's the difference from the ITerms we have now? Why do I need it?
I know that you are using the zc.sourcefactory package. Take a look at that package and you will see that this package can't do what it does without ITerms from zope.app.form. If we don't move that from zope.app.form to another location. We can never support ITerms in z3c.form. ITerms is the bridge from ISource to the widget world. Regards Roger Ineichen
-- 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 )
Hi Christian
Betreff: Re: [Zope-dev] Make simple ISource usable
[...]
The ITrems is a standard API for handle ISource, doesn't nmatter how you will query or get our data form an ISource.
This sounds like you want to implement something different than ITerms but that you see a structural similarity between what you want and what ITerms already do.
I think this causes some confusion (and resistance by my side) right now.
Can you try to phrase what you want to achieve and maybe not use the word 'ITerms' (for now)?
I don't like to implement something different then ITerms defined in zope.app.form. I'm fine if we remove the request as an adapter discriminator. ITerms could adapt only the ISource as a single object. The important thing is. zope.schema defines ITerm and ITitledTokenizedTerm and offers support wihthin the SimpleTerm for implement simple usable components if it comes to using widgets. A widget needs most the time a label for represent a token and needs a HTML aware token id. This ITerm is not a requirement for make an ISource implementation usable. It's just one concept, but this one is accepted and used in zope e.g. zope.app.security. Right now ITerms defined in zope.app.form brings in some bad dependencies to zope.app.form. e.g. in zope.app.security and makes it impossible to use it in z3c.form. That's all I like to solve. My Fazit is, all of you agree on the ITerms pattern and you are using that pattern within zc.sourcefactory. Can you explain why this ITerms interface should be a part of a specific form framework like zope.app.form? Regards Roger Ienichen
Christian
-- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Jim
Betreff: Re: [Zope-dev] Make simple ISource usable
On Aug 30, 2008, at 10:54 AM, Roger Ineichen wrote:
But zope.schema does already know about term.
This was a mistake.
Let's fix that mistake and do it right. That's all I'm asking for. Just saying no that's bad doesn't help. Any idea how we can do it? My motivation is to have less dependencies which is allways a good thing. or not?
...
ISource uses ITerm as items.
No it doesn't.
Ok, that wasn't correct. Let's say it right. ITerms uses ITerm as items. And we have widgets which know how to work with ITerms. ITerms adapter can adapt an ISource. And this adapter knows about ITerm which widgets can work with. Not every ISource have to use that pattern. But that's the second pattern we support in zope within an interface next to ISourceQueriable. Of corse everybody can implement a own API and query sources how the like to. But the benefit of a standard API like we have with ITerms is that we are able to implement reusable components which the different widget framework can use. This means ITerms should not be a part of a specific widget framework. The same is true for ISourceQueriable which is not a part of zope.app.form and that's good so. Regards Roger Ieichen
Jim
-- Jim Fulton Zope Corporation
On Aug 29, 2008, at 9:01 AM, Roger Ineichen wrote:
I'll try to make the ISource API smooth and usable for other components. Right now ISource provides no simple API for work with terms.
Since a ISource only provides a __contains__ method and the IterableSource the __iter__ method, there is some more needed which makes it easy to work with terms next to the ISourceQueriables API.
The zope.app.form.browser.interfaces.ITerms defines one possible way to make it work like a vocabulary because it defines the methods getTerm(value) and getValue(token).
The z3c.form.interfaces.ITerms defines also such a query API but right now only or vocabularies.
I propose to define such a ITerms interface in zope.schema.interfaces which makes it possible to implement simple ISource terms and work with the ITerm values like we do in vocabularies.
I'm not in favor of adding UI-support interfaces to zope.schema. The presense of terms in zope.schema.interfaces was a mistake.
This whould not affect other implementations like the ISourceQueriables etc. It only offers the a way to implement reusable simple ISource components without the need that every UI framework needs to implement their own interfaces for query ISource component in their own way (e.g. ITerms).
Why can't they use zope.app.form.interfaces.ITerms
The current state of ISource/ITerms concept whould not work if someone will switch form zope.app.form based sources to z3c.form based sources because of it's different ITerms implementations.
Why? If the interface is the same, why does it matter if the implementations differ.
Or if someone defines a zope.schema.ISource in a 3rd party package, the zope.app.form.browser.interfaces.ITerms is often used for query ITerms even if it's only used in python code without any form framework. That's a real bad dependency.
Why?
Fazit, 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'm not convinced that a more specific API, except maybe one based on simple search strings will be generally useful. An earlier attempt to define a query interface was a disaster.
I no one objects, I'll start a zope.schema branch and let you know about the progress and a hopfully a simple solution.
I object. Jim -- Jim Fulton Zope Corporation
On Tuesday 02 September 2008, Jim Fulton wrote:
This whould not affect other implementations like the ISourceQueriables etc. It only offers the a way to implement reusable simple ISource components without the need that every UI framework needs to implement their own interfaces for query ISource component in their own way (e.g. ITerms).
Why can't they use zope.app.form.interfaces.ITerms
Because it makes every project that uses sources in a meaningful way depend on zope.app.form, which has a lot of dependencies that I do not want. It prohibits another form framework, such as z3c.form to not depend on zope.app.form, which suck to say the least. :-) An alternative to Roger's proposal would be to move the ITerms declaration and any possible generic implementation of such into its own package zope.terms. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hi Stephan
Betreff: Re: [Zope-dev] Make simple ISource usable
On Tuesday 02 September 2008, Jim Fulton wrote:
This whould not affect other implementations like the ISourceQueriables etc. It only offers the a way to implement reusable simple ISource components without the need that every UI framework needs to implement their own interfaces for query ISource component in their own way (e.g. ITerms).
Why can't they use zope.app.form.interfaces.ITerms
Because it makes every project that uses sources in a meaningful way depend on zope.app.form, which has a lot of dependencies that I do not want. It prohibits another form framework, such as z3c.form to not depend on zope.app.form, which suck to say the least. :-)
An alternative to Roger's proposal would be to move the ITerms declaration and any possible generic implementation of such into its own package zope.terms.
+1 I'm fine with that. Everything is better then having this interface in zope.app.form since zope.app.security is using it and glues many zope packages and the testing enviroment together. Regards Roger Ineichen
Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Sep 2, 2008, at 10:38 AM, Stephan Richter wrote:
On Tuesday 02 September 2008, Jim Fulton wrote:
This whould not affect other implementations like the ISourceQueriables etc. It only offers the a way to implement reusable simple ISource components without the need that every UI framework needs to implement their own interfaces for query ISource component in their own way (e.g. ITerms).
Why can't they use zope.app.form.interfaces.ITerms
Because it makes every project that uses sources in a meaningful way depend on zope.app.form, which has a lot of dependencies that I do not want. It prohibits another form framework, such as z3c.form to not depend on zope.app.form, which suck to say the least. :-)
An alternative to Roger's proposal would be to move the ITerms declaration and any possible generic implementation of such into its own package zope.terms.
I don't have a problem with that. :) Jim -- Jim Fulton Zope Corporation
On Tuesday 02 September 2008, Jim Fulton wrote:
An alternative to Roger's proposal would be to move the ITerms declaration and any possible generic implementation of such into its own package zope.terms.
I don't have a problem with that. :)
That's what I thought. Impasse resolved? :-) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hi Jim, Stephan
Betreff: Re: [Zope-dev] Make simple ISource usable
On Tuesday 02 September 2008, Jim Fulton wrote:
An alternative to Roger's proposal would be to move the ITerms declaration and any possible generic implementation of such into its own package zope.terms.
I don't have a problem with that. :)
That's what I thought. Impasse resolved? :-)
Yeah, this sounds very good to me. I'll pick that up next week and implement this part in a branch for review. Regards Roger Ineichen
Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
participants (6)
-
Christian Theune -
Christian Zagrodnick -
Jim Fulton -
Marius Gedminas -
Roger Ineichen -
Stephan Richter