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

Tres Seaver tseaver at palladion.com
Mon Feb 26 17:48:13 EST 2007

Hash: SHA1

Philipp von Weitershausen wrote:
> 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 
> necessary;.

OK.  I do think we need to have some resistance to the "Zope2 is evil,
Zope3 is wonderful" fundamentalism which sometimes shows up around here.
 Frankly, Zope3 *is* a cool library, but it does not address a number of
the scenarios Zope2 does, and maybe never will.

>>> 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.

I'll note that five views are already required to be acquisition wrapped
if they use any objects protected by Zope2 security machinery.

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

I don't know of such a distinction.  Please explain how one registers a
"subscription adapter".

- --
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Zope-CMF mailing list