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 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.

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

Reply via email to