Mikel Larreategi wrote:
> 
> Well, everything inside CMFPlone/browser/* still depends on that
> BrowserView (at least in the latest svn-Plone3), and I think that many
> developers, like me, have written their BrowserViews in that way, just
> because "Plone does it in that way".
> 

Yes. This is quite unfortunate. These were pretty much the first things we
ever did with browser views.



> For many of us, acquisition is "magic that works", so we don't really
> care about it until we have problems (like with UnicodeErrors :)).
> 

True. I've found in my own development that I only really had to understand
acquisition when I started chasing down errors with browser views. :)



> What I would like to see, is a common pattern to create BrowserView, not
> having utils.BrowserView here and Five.browser.BrowserView there. It
> seems that, following Martin's post, "the right way" is to inherit from
> Five.browser.BrowserView. I will try to do that in my new BrowserViews
> of my products for Plone 2.5, but perhaps deprecating (if possible)
> CMFPlone.utils.BrowserView will be a good idea, to try to avoid
> upgrading problems.
> 

I think this would be a good idea. Whether we have time to fix all the views
in Products.CMFPlone.browser is a slightly different issue. Our
documentation (certainly the documentation I've written) will say this
pattern is right (the base class) and safest (the context unwrapping):

from Acquisition import aq_inner
from Products.Five.browser import BrowserView

class MyView(BrowserView):
    """My new view
    """

    def some_view_function(self):
        context = aq_inner(self.context)
        # Now use 'context' in some way

If you forget the aq_inner() it will probably still work 9 times out of 10,
but the 10th time you're screwed and wondering why you're getting insane
errors about user folders and attributes not being found.

Martin
-- 
View this message in context: 
http://www.nabble.com/Browser-views%3A-inherit-from-object-or-BrowserView-from-Five-Plone-tf3601148s20094.html#a10079345
Sent from the Product Developers mailing list archive at Nabble.com.


_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers

Reply via email to