Here's an alternate proposal:

Let's put the proxying in the trusted adapter factory.

Let's make the trusted adapter factory add the proxy
if the adapter doesn't set ILocation. Then the form code
stays clean and other code will benefit.  This would become
part of the definition of trusted adapters.

If there are no objections, let's do it this way.


Jim Fulton wrote:
Garrett Smith wrote:

Jim Fulton wrote:

Garrett Smith wrote:

I don't understand the pushback against location proxying
security-proxied objects. LocationProxy does actually play well with
security-proxied objects.

That was not our experience in the recent past.  I'll have to document
the problems, assuming that I can reproduce them.

Are you referring to the problems Gary ran into when he modified the form setup machinery? I ran into the same problems in our application, which led to the mods to make LocationProxy work with security proxied objects.


I wonder if it would make sense for the trusted adapter machinery to
simply set __parent__ on adapters if either the adapter provides
ILocation *or* the adapter doesn't already have a __parent__. This would solve
the problem and avoid the proxy.

Apart from the "works/doesn't work" issue (your previous point), are you concerned that we'll see LocationProxy popping up whenever we need location-sensitive lookups? Would that be a bad thing?


I've found LocationProxy to be essential providing location-specific
lookup capability in more than forms. E.g. I often location-proxy
objects in events where handlers perform operations that want local
authentication facilities.

My main objection is that it seem too implicit to me.

My objection is that we would be doing something for the adapter
that it should have done for itself.  With this change every adapter
that doesn't provide ILocation will get proxied even if the adapter
is actually public.

I'm willing to give in on this though.

If y'all want to change this back, I'll go along as
long as it doesn't break things. :)


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to