-----BEGIN PGP SIGNED MESSAGE-----
Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>>> The second problem that might arise, is that the implicit assumption
>>> that every object inside Zope 2 inherits from Acquisition base classes
>>> no longer holds. Code that relies on the various aq_* attributes to be
>>> there need to be adjusted to use the Acquisition methods instead.
>> The major downside here is that restricted code doesn't have access to
>> the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and
>> hence use the attributes. ('aq_base' should not be allowewd at all, as
>> it strips away security context).
>> There are probably thousands (or even tens of thousands) of templates
>> and scripts "in the wild" which use these attributes. I don't think we
>> can break them in a single release: we need to deprecate them first
>> (with suitalbe logging output), and maybe even provide
>> '__parent__'-aware workarounds / fallbacks in their implementations.
> Here's the deal:
> * Instances of (subclasses of) Acquisition.Implicit and .Explicit still
> have those aq_* attributes. So basically all content objects still have
> them, no change there.
> * Five's BrowserView class doesn't inherit from Acquisition.Explicit
> anymore, but we've provided the aq_* attributes for backward
> compatibility. So if a template does view/aq_parent, it will still work
> (we have tests for this). We haven't set an expiry date for this BBB,
> nor are we logging a warning. We probably should, though, if we
> eventually want to phase out Five's BrowserView class.
> So, off the line there's no backward-compatibility problem. Now if
> people decide to implement their content objects without Acquisition
> (which they now can), then it's their problem if their templates still
> do obj/aq_*. This can be alleviated with a mix-in that Five has, which
> makes classes regain the aq_* attributes. Not sure if we want to make
> this public in any way, currently it's basically used for BrowserView
> and ViewletBase.
I realized after I sent it that BBB was "automatic" for the content
objects, making only views a possible issue: I'm glad to learn that the
views have the attributes available. I would recommend a "perpetual
deprecation" for the view BBB (log the warning with a note of the
recommended change, but don't indicate a removal release).
In any case, given the clarification, +1 to the merge.
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -