Martin Aspeli wrote: > > > Maurits van Rees-3 wrote: >> Rocky, on 2007-04-22: >> Two thoughts after a conversation with Jean-Paul Ladage who had a >> conversation with Daniel Nouri :) >> >> 1. context might need to be callable >> > > Context needs to be the context content object. I don't see any requirement > that it should be callable. But IBrowserView (or rather, things it derives > from) specifies that 'context' is the object (and not a list as in the > CMFPlone.utils.BrowserView base class)
Reinout means: It should be a property. >> 2. Would it not be better if Five took care of all aq stuff, like >> wrapping context in aq_inner? >> > > It can't. No matter what you put in self.context, the wrapping happens on > *retrieval* so if self inherits from Acquisition.Explicit, when you do > self.context you get back context aq-wrapped in self. I would experiment and look at aq_chain for a context that's a property that returns 'aq_inner(self._context)'. Needless to say, I'd prefer this option if it works because it's the natural way to get context. >> Combining these two thoughts in Five/browser/__init__.py : >> >> from Acquisition import aq_inner >> class BrowserView(Acquisition.Explicit, >> zope.app.publisher.browser.BrowserView): >> """Five browser view >> >> Mixes in explicit acquisition so that security can be acquired for >> views""" >> >> def __init__(self, context, request): >> self._context = context >> self.request = request >> >> @property >> def context(self): >> return aq_inner(self._context) >> > > Unfortunately, acquisition doesn't work properly inside Python property > __get__ accessors. I've seen this pattern before, but I've seen people have > various problems with it (that I can't remember the details of right now). Hmm, I've been using @property now for quite a long time for handling context without any problems. It would be good to have a minimal failing example. I know that formlib actions, which are applied via a decorator, have problems with acquisition. But then, they do much more than @property. -- http://danielnouri.org _______________________________________________ Product-Developers mailing list Product-Developers@lists.plone.org http://lists.plone.org/mailman/listinfo/product-developers