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.
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to