[Zope-CMF] Re: Five's local sitemanager, CMF, etc
Philipp von Weitershausen
philipp at weitershausen.de
Mon Feb 26 18:06:10 EST 2007
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.
More information about the Zope-CMF
mailing list