Currently views are registered as components providing zope.interface.Interface; this is unfortunate since other kinds of components may use the same specification, namely (context, request). An example of this is ``IAbsoluteURL``; it clashes with the resources view*. In the words of Christian Theune: "I think it looks like one should never ask for adaptions to Interface." I suggest we then register views as components providing ``zope.component.IView``; browser views should provide ``zope.publisher.interfaces.browser.IBrowserView``. \malthe *) ``zope.app.publisher.browser.resources.Resources``.
Hi there, Malthe Borch wrote: [snip]
I suggest we then register views as components providing ``zope.component.IView``; browser views should provide ``zope.publisher.interfaces.browser.IBrowserView``.
I think this would improve things, and thanks for bringing this up. There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B? Regards, Martijn
Martijn Faassen wrote:
There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B?
It deserves consideration, but I don't think code will be prone to break since we're merely providing more information to lookup a view component, not less. \malthe
On Jun 18, 2008, at 1:44 PM, Malthe Borch wrote:
Martijn Faassen wrote:
There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B?
It deserves consideration, but I don't think code will be prone to break since we're merely providing more information to lookup a view component, not less.
Exactly. The interface passed to getMultiAdapter or queryMultiAdapter is a minimum requirement. Making views provide IView won't stop them from providing Interface, which is the default. On a somewhat related matter, it would be great if the browser:page ZCML directive could be augmented to have a provides= attribute, so that even more specific categories of views can be marked. E.g. for Malthe's Collage add-on for Plone, which does page compositing, we want to look up a named view on an object, but only if the view provides ICollageView. David Glick Project Associate ONE/Northwest New tools and strategies for engaging people in protecting the environment http://www.onenw.org davidglick@onenw.org (206) 286-1235 x32 Subscribe to ONEList, our email newsletter! Practical advice for effective online engagement http://www.onenw.org/full_signup
David Glick wrote:
On Jun 18, 2008, at 1:44 PM, Malthe Borch wrote:
Martijn Faassen wrote:
There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B?
It deserves consideration, but I don't think code will be prone to break since we're merely providing more information to lookup a view component, not less.
Exactly. The interface passed to getMultiAdapter or queryMultiAdapter is a minimum requirement. Making views provide IView won't stop them from providing Interface, which is the default.
Well, true, view *lookup* for Interface will still work if we register views for a more specific interface. But if Zope's browser publication now starts looking up views with the more specific interface and there are still views around that haven't been registered for that but for Interface, we'll run into backward compatibility problems. I suppose the browser publication would have to be smart about it and do a legacy lookup for Interface if it can't find a view for the specific one. Either way, it's not *that* simple...
On Jun 19, 2008, at 9:37 AM, Philipp von Weitershausen wrote:
David Glick wrote:
On Jun 18, 2008, at 1:44 PM, Malthe Borch wrote:
Martijn Faassen wrote:
There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B?
It deserves consideration, but I don't think code will be prone to break since we're merely providing more information to lookup a view component, not less. Exactly. The interface passed to getMultiAdapter or queryMultiAdapter is a minimum requirement. Making views provide IView won't stop them from providing Interface, which is the default.
Well, true, view *lookup* for Interface will still work if we register views for a more specific interface. But if Zope's browser publication now starts looking up views with the more specific interface and there are still views around that haven't been registered for that but for Interface, we'll run into backward compatibility problems.
I suppose the browser publication would have to be smart about it and do a legacy lookup for Interface if it can't find a view for the specific one.
Either way, it's not *that* simple...
I suggest: - decide on and advertise the new interface - continue to do look ups the way we do now - update relevant zcml directives (view, page, resource. etc.) to use the new interface - issue informative deprecation warnings when we register adapters providing Interface. - Later, switch to looking up using the new interface. Maybe make this an application option so that people can choose to use the new interface sooner. Jim -- Jim Fulton Zope Corporation
On Thu, Jun 19, 2008 at 09:46:35AM -0400, Jim Fulton wrote:
I suggest:
- decide on and advertise the new interface
- continue to do look ups the way we do now
- update relevant zcml directives (view, page, resource. etc.) to use the new interface
- issue informative deprecation warnings when we register adapters providing Interface.
- Later, switch to looking up using the new interface. Maybe make this an application option so that people can choose to use the new interface sooner.
+1 Would it be reasonable to also issue a warning if someone does a lookup for Interface? 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 Jun 19, 2008, at 10:46 AM, Christian Theune wrote:
On Thu, Jun 19, 2008 at 09:46:35AM -0400, Jim Fulton wrote:
I suggest:
- decide on and advertise the new interface
- continue to do look ups the way we do now
- update relevant zcml directives (view, page, resource. etc.) to use the new interface
- issue informative deprecation warnings when we register adapters providing Interface.
- Later, switch to looking up using the new interface. Maybe make this an application option so that people can choose to use the new interface sooner.
+1
Would it be reasonable to also issue a warning if someone does a lookup for Interface?
No, because clients have to look up using Interface as long as the component they need might be registered with it. Jim -- Jim Fulton Zope Corporation
On Thu, Jun 19, 2008 at 10:50:00AM -0400, Jim Fulton wrote:
Would it be reasonable to also issue a warning if someone does a lookup for Interface?
No, because clients have to look up using Interface as long as the component they need might be registered with it.
Is that an argument for a grace period? I wondered about the case in general or in the long run. -- 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 Jun 19, 2008, at 10:53 AM, Christian Theune wrote:
On Thu, Jun 19, 2008 at 10:50:00AM -0400, Jim Fulton wrote:
Would it be reasonable to also issue a warning if someone does a lookup for Interface?
No, because clients have to look up using Interface as long as the component they need might be registered with it.
Is that an argument for a grace period? I wondered about the case in general or in the long run.
The grace period. Jim -- Jim Fulton Zope Corporation
Hey, Jim Fulton wrote: [snip]
I suggest:
- decide on and advertise the new interface
- continue to do look ups the way we do now
- update relevant zcml directives (view, page, resource. etc.) to use the new interface
+1 Update the relevant grokkers to use the new interface too. :) Regards, Martijn
Hey, One question is what to do for persistent registrations in local sites. I don't imagine they're used a lot, but it'd mean a content upgrade to re-register them, right? Regards, Martijn
Martijn Faassen wrote:
One question is what to do for persistent registrations in local sites. I don't imagine they're used a lot, but it'd mean a content upgrade to re-register them, right?
The only piece of software that, to my knowledge, can actually *make* local view registrations is five.customerize. Plone uses it to allow local customization of Zope 3 views and viewlets. I suppose they'll just have to write an upgrade script (after having update five.customerize itself).
Malthe Borch wrote:
Martijn Faassen wrote:
There's one major problem that I see. What's the backwards compatibility story? I'm sure there are a lot of cases in lots of code where people look up views with a getMultiAdapter, and if we started registering views differently, wouldn't that code break? How to we get from A to B?
It deserves consideration, but I don't think code will be prone to break since we're merely providing more information to lookup a view component, not less.
Hm, you're right, I think, good point. I think it will lead to trouble as old code doesn't get updated and excepts to get a view when actually it'll get something entirely different. Regards, Martijn
Hi, On Wed, Jun 18, 2008 at 10:31:30PM +0200, Malthe Borch wrote:
Currently views are registered as components providing zope.interface.Interface; this is unfortunate since other kinds of components may use the same specification, namely (context, request).
An example of this is ``IAbsoluteURL``; it clashes with the resources view*.
In the words of Christian Theune: "I think it looks like one should never ask for adaptions to Interface."
In those cases the adapters are chosen solely on the specificity of the adaptation's requirement and it becomes easy to mix up semantics from unrelated code. I'd be interested in a use case where adapting to Interface is not just a (questionable) convenient short-cut but an actual semantically correct operation and could not be replaced with a more specific interface. Looking at zope.component.interfaces I find that there is an inconsistency in the APIs. The actual registry APIs all require an interface to be specified for an adaptation, but the module-global facade API provides zope.interface.Interface as the default. I take that as another indicator for an anti-pattern.
I suggest we then register views as components providing ``zope.component.IView``; browser views should provide ``zope.publisher.interfaces.browser.IBrowserView``.
I don't think zope.component wants to know about views. The interface should be in a package that already knows about views. 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
Christian Theune wrote:
I don't think zope.component wants to know about views. The interface should be in a package that already knows about views.
I agree it's an inappropriate location, however, zope.component *does* define an ``IView`` interface as it is (zope.component.bbb.interfaces). Perhaps it should be moved to zope.app.component which defines the "view" meta directive. \malthe
On Jun 18, 2008, at 5:03 PM, Malthe Borch wrote:
Christian Theune wrote:
I don't think zope.component wants to know about views. The interface should be in a package that already knows about views.
I agree it's an inappropriate location, however, zope.component *does* define an ``IView`` interface as it is (zope.component.bbb.interfaces).
The bbb signifies deprecation. Jim -- Jim Fulton Zope Corporation
On Jun 18, 2008, at 4:31 PM, Malthe Borch wrote:
Currently views are registered as components providing zope.interface.Interface; this is unfortunate since other kinds of components may use the same specification, namely (context, request).
Right. This is a historical accident that I would love to see corrected. It's just never been a high enough priority. ... Note that resources have the same problem.
I suggest we then register views as components providing ``zope.component.IView``; browser views should provide ``zope.publisher.interfaces.browser.IBrowserView``.
zope.component isn't the right place. What's more, "View" isn't the right word. I think this needs more thought, but I think that: - the interface is about publication (not components or views) - the interface is for objects that want to be published, regardless of whether they are adapters. Basically, when you get to the end of URL traversal, you should get an object that wants to be called to get a result and that implements or can be adapted to this interface. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote:
On Jun 18, 2008, at 4:31 PM, Malthe Borch wrote:
Currently views are registered as components providing zope.interface.Interface; this is unfortunate since other kinds of components may use the same specification, namely (context, request).
Right. This is a historical accident that I would love to see corrected. It's just never been a high enough priority.
...
Note that resources have the same problem.
I suggest we then register views as components providing ``zope.component.IView``; browser views should provide ``zope.publisher.interfaces.browser.IBrowserView``.
zope.component isn't the right place. What's more, "View" isn't the right word.
I think this needs more thought, but I think that:
- the interface is about publication (not components or views)
- the interface is for objects that want to be published, regardless of whether they are adapters.
Basically, when you get to the end of URL traversal, you should get an object that wants to be called to get a result and that implements or can be adapted to this interface.
Right. I think zope.publisher.interface.browser.IBrowserPage already fits this description, but feel free to correct me if I'm wrong.
Malthe Borch wrote:
Currently views are registered as components providing zope.interface.Interface; this is unfortunate since other kinds of components may use the same specification, namely (context, request).
An example of this is ``IAbsoluteURL``; it clashes with the resources view*.
In the words of Christian Theune: "I think it looks like one should never ask for adaptions to Interface."
I suggest we then register views as components providing ``zope.component.IView``; browser views should provide ``zope.publisher.interfaces.browser.IBrowserView``.
IBrowserView is IMHO not the right one. Anything, including absolute_url and standard_macros, can be a browser view. But browser views aren't necessarily *publishable*. In other words, Zope 3 won't resolve URLs like http://localhost:8080/standard_macros or http://localhost:8080/absolute_url. (Zope 2 will publish such URLs which is quite terrible). Browser pages (as opposed to browser views) are components that *are* publishable on the other hand. That's because they provide IBrowserPublisher (IBrowserPage extends this interface). That's why I think IBrowserPage is the right interface to adapt to. But perhaps it should be something else, though either way it should be based on IBrowserPublisher.
participants (6)
-
Christian Theune -
David Glick -
Jim Fulton -
Malthe Borch -
Martijn Faassen -
Philipp von Weitershausen