[Zope-CMF] Re: Five's local sitemanager, CMF, etc

Philipp von Weitershausen philipp at weitershausen.de
Mon Feb 26 16:41:58 EST 2007

Tres Seaver wrote:
> Hash: SHA1
> Philipp von Weitershausen wrote:
>> Rocky wrote:
>>> On Feb 23, 3:50 pm, Martin Aspeli <optil... at gmx.net> wrote:
>>>> yuppie wrote:
>>>>> Maybe I'm missing something. But wasn't a major goal of
>>>>> five.localsitemanager to return acquisition wrapped tools?
>>>> That was my understanding, too. I thought this would just mean
>>>> aq_base'ing the utility and aq-wrapping it back into the context (the
>>>> portal root). Without this, we start requiring users of the interface to
>>>> know when aq wrapping is needed and do it explicitly with __of__() which
>>>> I think we agreed was unacceptably detailed and ugly. :)
>>> Alright, I've gone ahead and put code in place for this (albeit a bit
>>> naively) with r72810.  The next question is whether we should be doing
>>> the same with adapters and subscribers as well (even though this
>>> doesn't affect the whole tools-getting-acquired-properly issue).
>> One more thing: This acquisition wrapping should clearly be marked (with 
>> comments) as something that's done to for BBB because some tools happen 
>> to want acquisition. I think in the future, it should be discouraged to 
>> expect acquisition in CMF tools.
> - -1.  This is not *yet* BBB, until we require a version of Zope which no
> longer uses acquisition for anything crucial.  Premature deprecation is
> "crying wolf", IMNSHO.

I nowhere said anything about deprecation. All meant was to discourage 
relying on acquisition when developing new tools. I think that deserves 
a comment (I suggested nothing more). No deprecation warning or anything 

>> To get to the portal root / CMF site, I suggest a pattern that is 
>> sometimes used in Zope3: We register the CMF site object as a utility 
>> providing ICMFSite (or whatever). Then whichever code that's executed 
>> below the portal (and that includes CMF tools) can do 
>> getUtility(ICMFSite) to get to the site.
>> Adapters and subscription adapters should not be acquisition wrapped.
> They darn well better be able to get a wrapped context (which means that
> the event *must* have a wrapped attribute) or they will be less than
> useless.

That's something else. Adapters and subscription adapters will get 
whatever they are looked up with. If that's wrapped, fine. E.g. if you 
do IWhatever(obj) and you got obj thru acquisition, then the IWhatever 
adapter will see obj with all its acquisition glory. But The adapter 
objects themselves shouldn't be wrapped. It would break, say, views 
which happen to be adapters.

Note that subscription adapters != subscribers. Subscribers don't return 
objects upon lookup, they're just executed. Subscription adapters are 
more like adapters.

http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5

More information about the Zope-CMF mailing list