[Zope-dev] Re: Proposal: Merge philikon-aq branch into Zope trunk

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
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

iD8DBQFICKz6+gerLs4ltQ4RAqI9AJ9wWjhsca8iljbeb8z77eHMHgBv/gCdHfa4
SkkZqvDRAxPLPicSQM8ZCPQ=
=o+xz
-----END PGP SIGNATURE-----