-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > > Tres Seaver wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Philipp von Weitershausen wrote: >>> Rocky wrote: >>>> On Feb 23, 3:50 pm, Martin Aspeli <[EMAIL PROTECTED]> 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. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF42Ot+gerLs4ltQ4RAqPLAJ9vnHfe6tO7paPMhs8bPnmYxx4SqQCfciUd IUgd7g+CHTxhNXufTCbKKqk= =+R0J -----END PGP SIGNATURE----- _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests