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
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.
OK
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
-- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com