Jeff Shell wrote:
> [snip]
> 
> 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.
> 

Hey, thanks Jeff. Less magic was what I was looking for in my original
post. If my View Class is going to end up having BrowserView in its base
classes, I want to see it in the class definition, for exactly the
reasons you stated.

 For having understandable code I think that's much more important than
'getView' vs 'getMultiAdapter'.

I had done a fair amount of searcing through the code, API docs and
mailing list, and both books, and up until now had not known than
IBrowserView was where the 'context' and 'request' attributes were
coming from. Feel like I'm having one of those "I was absent that day"
episodes. Thanks for the excellent clarification.

-- Wade

_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to