On Thu, Jul 8, 2010 at 5:04 PM, Martijn Faassen <faas...@startifact.com> wrote:
> The fix in my code was to make my model provide ILocation itself, so
> that it would adapt itself and therefore avoid the proxy. I think that
> might be correct but at the same time is really obscure; in my code the
> __parent__ is provided by a completely different subsystem (traject).
> Models that didn't provide ILocation used to work, and now they fail. Do
> we really want to require everybody to start providing ILocation in all
> their models?
> I propose the following adjustment:
>   try:
>      container = context.__parent__
>   except AttributeError:
>      container = ILocation(context).__parent__
> So, try to find the __parent__ the old way first, without adapter
> lookup. If that fails because the attribute is missing, look up the
> adapter. That might get one the proxy again, but at least not when a
> __parent__ is actually available. Still, this deserves some commenting
> for future people trying to debug what's going on.
> I've verified that at least in my application this unbreaks the code.
> I'll also try to add a test that demonstrates the expected behaviors so
> that this doesn't get broken again.
> Opinions?

I think this sounds reasonable. In Zope 2 Acquisition wrappers provide
__parent__ pointers, but they don't implement ILocation either. I
think the presence of the __parent__ pointer is the established
"protocol", independent of the ILocation interface.


P.S. Acquisition wrappers don't have interfaces of their own, but
defer all lookups to the wrapped object, so letting them provide
ILocation without changing the model classes isn't easily possible.
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to