Jim Fulton wrote:

Whether something is trusted or not is an implementation decision of the

But if developer 'A' writes a framework such as the form framework, he does not implement the adapter himself. The adapters are implemented by others within different application for example developer 'X' and 'Y'.

So the code of 'A' adapts something:

   >>> adapted = ISomething(context)
   >>> doLocationSensitiveStuff(adapted)

'A' is not able to influence the implementations of 'X' and 'Y' ISomething-adapters. If 'X' or 'Y' does register an none-public-untrusted adapter 'A's framework will fail.

So 'A' has to force anyway all adapters to be locatable, if he wants handle this bug situation:

   >>> locatetable_adapted = assertLocation(ISomething(context), context)
   >>> doLocationSensitiveStuff(locatetable_adapted)

I thougth, you (Jim) wanted to ban such dedicated location proxy stuff out of the code. Therefore you proposed the trusted adapter factory solution. My exclusive objection is that we don't get rid of specific location assertions within frameworks unless we make all adapters locatable.


So are you agreeing with the proposal to add location proxies
in the adapter factory and not in the form machinery?

No. IMO we can not solve the problem correctly doing the location proxies inside the trusted adapter factory, because their might be a few untrusted adapters that requires a dedicated permission, too. So we have to do the proxying inside the trusted adapter factory and inside the form machinery and that's kind of pointless to me.

location helper function:
+ Performance: We don't have to build location proxies all the time
+ Explicitness: Excplicit in relation to the location issue after adaption
0 Developer: Have to be aware of the location issue

assert a location to all trusted adapters:
0 Performace: Ok because only the trusted adapters are affected
- Explicitness: Implicit in relation to the location issue after adaption

This doesn't make any sense to me.

If a programmers uses the trusted adapter facility, they do so exlicitly.
The trusted adapter facility is documented to provide location.

The mail before I asked you (Jim):
How can I ask for trusted adapters explicitly inside a framework such as edit view?
Your answer: You can't.

May that's the key for our mutual misunderstanding (and of course my english) :)

assert a location to all adapters:
- Performance: Diffinitaly an overhead
+ Explicitness: Excplicit in relation to the location issue after adaption

No, this is very implicit.  It messes with *all* adapters, which is
way too intrusive.

IMO the mess starts when I don't know what I'm going to get *extra* out of an adapter call, for example

   >>> adapted = ISomething(context)

and I have to introspect the result set before I can proceed because I might get an location for free ;)
In all those cases where ISomething does not extend ILocation, it's pretty implicit to asume to have gotten a locatin too, except their would be the absolute rule and single exception ILocation is provided in any case.

If we like to solve such a problem explicitly without such absolute commitments, we have to invent beside the existing Multi*For*Adapters the Multi*Provides*Adapters:

>>> something_with_location = zapi.queryMultiProvideAdapter(context, (ISomething, ILocation))
>>> something_with_location = zapi.queryMultiForAndProvideAdapter((context,), (ISomething, ILocation))

IMO such a solution would be explicit with no bad aftertaste, but it will probably break a few basic registry implementations.

Keep in mind too that proxies suck. They are deep magic, like metaclasses.
Like metaclasses, they provide a powerful tool to solve extra hard problems,
but they should be used sparingly.

YUP! Because the location proxying within the trusted adapter factory does not solve all my problems and I have still to go with dedicated framework solutions like proposed in the form machinery. I would suggest to straiten for dedicated framework solutions only and offer a helper function only.


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to