Re: [Zope3-Users] How come no IView?
It will probably not comfort you that the concept of a view (at least by that name) is going to disappear sometime post-3.2. I hope I explain this properly; here goes. A view is a registration for a named multiadapter. The thing that is registered (the view) adapts two objects that implement interfaces to a different interface. Part of what makes a view a view is that it's registered to accept two objects in its factory: a content object and a request object. Another kind of named multiadapter might accept three, four, or five objects in its factory. A view happens to accept two, and only by convention are these two objects that are context and request objects. When you look up a view, the two objects you pass to getView (context and request) conventionally implement, respectively, IBrowserRequest and a content class interface. There is a class registered to adapt them to a marker interface (zope.Interface). So when a view is looked up like this: from zapi import getView from zope.interface import Interface from zope.interface import implements from zope.publisher.interfaces.browser import IBrowserRequest class IContent(Interface): pass class Content(object): implements(IContent) content = Content() class Request(object): implements(IBrowserRequest) request = Request() getView(content, u'index.html', request) ... under the hood the lookup is translated to: getMultiAdapter((content, request), Interface, name=u'index.html') ... and you get back a view class instance. The view class constructor is passed content and request in its constructor because that's what getMultiAdapter is wired to do. If you were adapting more than two, the class constructor would be passed three, or four, etc. This is because the registration of a view class (when it happens via ZCML) is essentially: from zope.component import registerAdapter class SomeView(object): def __init__(self, context, request): self.context = context self.request = requests registerAdapter(SomeView, (IContent, IBrowserRequest), Interface, name=u'index.html') The concept of a view is purely convention. getView is actually deprecated in the trunk at least, as a result. I don't know if that makes anything clearer but I for one welcome our new simplification overlords. On Jan 1, 2006, at 12:20 PM, Wade Leftwich wrote: Since Zope 3 is all about being self-documenting and discoverable, it seems odd that something as central as a View has the implicit attributes 'context' and 'request'. Is there an architectural reason that we don't say that a View class implements an IView interface that gives the names of the expected attributes? If this question is hopelessly naive, please be gentle. -- Wade Leftwich Ithaca, NY ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] How come no IView?
Chris McDonough wrote: It will probably not comfort you that the concept of a view (at least by that name) is going to disappear sometime post-3.2. I hope I explain this properly; here goes. A view is a registration for a named multiadapter. The thing that is registered (the view) adapts two objects that implement interfaces to a different interface. Part of what makes a view a view is that it's registered to accept two objects in its factory: a content object and a request object. Another kind of named multiadapter might accept three, four, or five objects in its factory. A view happens to accept two, and only by convention are these two objects that are context and request objects. When you look up a view, the two objects you pass to getView (context and request) conventionally implement, respectively, IBrowserRequest and a content class interface. There is a class registered to adapt them to a marker interface (zope.Interface). So when a view is looked up like this: from zapi import getView from zope.interface import Interface from zope.interface import implements from zope.publisher.interfaces.browser import IBrowserRequest class IContent(Interface): pass class Content(object): implements(IContent) content = Content() class Request(object): implements(IBrowserRequest) request = Request() getView(content, u'index.html', request) ... under the hood the lookup is translated to: getMultiAdapter((content, request), Interface, name=u'index.html') ... and you get back a view class instance. The view class constructor is passed content and request in its constructor because that's what getMultiAdapter is wired to do. If you were adapting more than two, the class constructor would be passed three, or four, etc. This is because the registration of a view class (when it happens via ZCML) is essentially: from zope.component import registerAdapter class SomeView(object): def __init__(self, context, request): self.context = context self.request = requests registerAdapter(SomeView, (IContent, IBrowserRequest), Interface, name=u'index.html') The concept of a view is purely convention. getView is actually deprecated in the trunk at least, as a result. I don't know if that makes anything clearer but I for one welcome our new simplification overlords. Thanks Chris, that actually does make things clearer. As a Z3 beginner, longtime Z2 user (ZPTs, scripts, ZSQL), and corporate developer who is trying to promote Z3 in-house, I am all for the current trend toward simplification, especially of ZCML (http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less). It seems like view class is a useful concept that gets talked about a lot. We're not going to have to start saying named multiadapter for content and request, are we? -- Wade ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] How come no IView?
Thanks Chris, that actually does make things clearer. As a Z3 beginner, longtime Z2 user (ZPTs, scripts, ZSQL), and corporate developer who is trying to promote Z3 in-house, I am all for the current trend toward simplification, especially of ZCML (http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less). It seems like view class is a useful concept that gets talked about a lot. We're not going to have to start saying named multiadapter for content and request, are we? -- Wade No. It's pretty much understood what a View is... Typically it means a 'browser view', but it could in fact be anything. FTP, a graphical toolkit, and so on. The core component architecture doesn't tie anything to the web. But if you're looking for a base interface and class: interface: zope.app.publisher.interfaces.IBrowserView class: zope.app.publisher.BrowserView - has the __init__ with context and request, and is also locatable (mapping __parent__ to the context). This is a good one to subclass from, so if you need to do more work in __init__ you can call BrowserView's to ensure that anything it might do upon initialization in the future you get. But I doubt it will do much more than set self.context and self.request. While ZCML's view and page directives will put BrowserView into your base classes automatically if it's not there, I prefer to still use it as a base class directly. It makes the code more readable (I can see that 'SearchResults' is a browser view immediately), and is just a good concept (I believe) in making your code more Pythonic and less dependent on you or other readers of it understanding the ZCML 'magic' that goes on in the browser declarations. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
