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 Seaver          +1 540-429-0999          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to