[Zope3-dev] Form framework, adapters and pau

[Dominik Huber]

Jim Fulton wrote:

> Whether something is trusted or not is an implementation decision of the
> adapter.

Yup.
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))
or
    >>> 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.

Regards,
Dominik