Martijn Faassen 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
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.
You're right, and Tres acknowledged that in a follow-up post already :).
What's more, views actually *do* have those aq_* attributes for BBB, so
even those scripts that do view.aq_parent will continue to work no
problem. See my answer to Tres's post.
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?
Nope. And it would be quite an involved thing to do, because currently
Zope 2 objects have no persistent reference to their parent whatsoever
(in fact, parent i.e. cyclic references used to be unsupported by early
ZODB versions). So basically, if you wanted to introduce __parent__
pointers to existing Zope 2 objects, you'd have to traverse the whole
object tree and set them based on their acquisition parent. I *suppose*
this could be done ad-hoc (when you first traverse over an object that
doesn't yet have its __parent__ pointer set), but I'd rather not think
this through right now.
So, like I said, it's not on my list, and I bet it won't be for a long
time. Mostly because a) it's probably unnecessary and b) much code in
fact relies on content being of the type Acquisition.Implicit...
<dtml-var standard_dtml_header> anyone? :)
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -