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