Tres Seaver wrote:
[snip]
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.

I'm trying to understand what is proposed that would break them. All existing content objects will continue to use acquisition. Only things like Five views will stop using acquisition and switch to a __parent__ pointer. I doubt there are that many scripts that rely on getting a .aq_parent, say, on a Five view. There will be view code that relies on this, so I imagine we expect that should be rewritten to use the functions instead, but not scripts.

If we were to change OFS so that it'd start using __parent__ then I can see where you're coming from, but I don't think anyone's proposing that?

Regards,

Martijn

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

Reply via email to