Maurits van Rees-3 wrote:
>
> I was wondering what the best approach to BrowserViews is for 3rd
> party developers of Plone Products.
>
> Inherit from object
> -------------------
>
> class MyView(object):
> def __init__(self, context, request):
> self.context = context
> self.request = request
>
> The view is not Acquisition wrapped, which means that any permission
> you set in the configure.zcml is ignored and everyone can see this
> view, right?
>
> You define your own __init__() so you can handle the context anyway you
> please.
>
This doesn't work in Zope 2. You need to inherit from Acquisition.Explicit
at a minimum, or you'll get strange security errors.
> Inherit from Five
> -----------------
>
> from Products.Five.browser import BrowserView
> class MyView(BrowserView):
>
> The view is Acquisition wrapped, so Zope security kicks in, which is
> probably good.
>
> If you do not overwrite the __init__() you can use the context with
> self.context.
>
This is the correct approach, imho. However, note that whe you access
'self.context' it will be aq wrapped in the context of the view (since it
inherits from Acquisition.Explicit). If self.context is a content item, it
also has an inner acquisition chain from its containment. If you do
something on the object that needs to e.g. acquire tools or perform explicit
security checks, you probably want the inner chain since the outer one
contains the view. Therefore, I find it much safer to always do;
from Acquisition import aq_inner
from Products.Five.browser import BrowserView
class MyView(BrowserView):
def some_method(self):
context = aq_inner(self.context)
# use context in some way
> Inherit from Plone
> ------------------
>
> from Products.CMFPlone import utils
> class MyView(utils.BrowserView):
>
> Acquisition wrapped, same as Five.
>
> But in the __init__() of this BrowserView there is the line:
>
> self.context = [context]
>
> So you cannot use self.context in your code like you would do in the
> other cases, but you have to use this:
>
> context = utils.context(self)
>
> This is the only thing that is different from the Five BrowserView.
> All the browser views in CMFPlone/browser use this.
>
I really hate this view, and we're not using it any more in new views in
Plone 3. This is because:
- It makes self.context a list; this breaks compliance with the
IBrowserView interface
- You have to use that silly utils.context() thing
- It makes everything have a hard dependency on Products.CMFPlone
The rationale behind it is that storing things in a list means that upon
retrieval, the context doesn't get aq wrapped in the view's own aq context.
In theory, aq_inner could discard an outer wrapper that you *did* want, but
it's extremely unlikely that this will be the case (it certainly won't be
during normal traversal).
> I am still looking at product compatibility with Plone 2.5. Would the
> recommendation be different with Plone 3.0?
>
Apart from a conscious move away from Products.CMFPlone.utils.BrowserView,
I'm not aware of any incompatabilities between the use of views in Plone 2.5
and Plone 3.
Martin
--
View this message in context:
http://www.nabble.com/Browser-views%3A-inherit-from-object-or-BrowserView-from-Five-Plone-tf3601148s20094.html#a10060311
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
