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

[Philipp von Weitershausen]

On 26 Feb 2007, at 23:48 , Tres Seaver wrote:
>> 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.

Yes. Zope 3 is can be seen as a set of libraries -- and a number of  
approaches.

As far as acquisition (the concept) is concerned, I think the common  
perception is that Acquisition (the Zope 2 package) introduces pains,  
magic and unpredictability, whereas the way acquisition is  
implemented in Zope 3 (discrete places called sites from which you  
can acquire things after registering things explicitly) is a cleaner  
and more predictable concept.

I see this whole effort (making CMF tools available as utilities,  
etc.) a way to move from Acquisition (the Zope 2 package) to a better  
form of acquisition (using the Zope 3 Component Architecture). Such a  
process needs to be accompanied by clear statements what's encouraged  
and what's discouraged. That doesn't mean that the old way is "evil",  
but we can certainly give a clear recommandation as to what's better  
(not necessarily "wonderful" but better).

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

Yes, but their wrapping is a detail of the traversal and security  
machinery. Hence it happens during traversal, not during component  
lookup.

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

registry.registerSubscriptionAdapter()

More on subscribers vs. subscription adapters:

* "Subscribers" are the event subscribers we know: simple callables.  
They don't return anything (well, they return None :)), hence there's  
nothing to wrap or anything.

* "Subscription adapters" are like regular adapters (and they are  
implemented exactly like a regular adapter). The difference is in the  
lookup. Instead of getting exactly 0 or 1 adapter in the adaption,  
you get n adapters (where n=0,1,2,3...) with subscription adapters.  
Basically, instead of finding the most specific adapter, subscription  
adapters will return *all* applicable adapters. So their lookup is a  
bit like the one of subscribers, hence the name.