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