[Zope3-dev] Form framework, adapters and pau

[Dominik Huber]

Jim Fulton wrote:

>> - 1
>> It might be a trap too, because developers must be aware of the 
>> pretty implicit differnces between trusted and unstrusted adapters.
>
>
> We just need to make this explicit.
>
> We already "implicitly" set __parent__ in the trusted adapter
> factory. I suggest we make this explicit.  If you ask for a trusted
> adapter, then we'll set __parent__ on the adapter to the adapted object,
> adding a location proxy, if necessary.

How can I ask for trusted adapters explicitly inside a framework such as 
edit view?

If we adapt a context to a certain schema (given by the schema attibute 
of the editform directive) we have no chance today to ask explicitly for 
a trusted adapter but rather we get either an untrusted or a trusted 
one. So if we don't like to end up in the status-quo-bug we have still 
to handle unlocatable untrusted adapters someway.

>> where unstrusted adapters require a dedicated permission the editview 
>> has still to proxy those adapters to procede correctly. Would it be 
>> possible to deprecate the unstrusted adapters or proxy them to?
>
>
> I would strongly discourage the use of untrusted adapters that
> require a permission other than zope.Public.

Then we should not allow to set the permission attribute in the adapter 
directive ;)
But I use the permission attribute registering multiadapters (views) all 
the time, what's the problem there? I'm not aware of any problems.
The zope.Public permission is within all our use cases no alternative.

> In general, adapters are rarely accessed from untrustes code
> and are rarely security proxied.  I would not want to location
> proxy them in general.

Yup.
But my problem is the implicite behavior of the adapter interfaces. IMO 
we still end up in code like the following
...
adapter = IAnyInterface(context)
if not ILocation.providedBy(adapter):
    locatable_adapter = LocationProxy(adapter)
    locatable_adapter.__parent__ = context.__parent__
    locatable_adapter.__name__ =  context.__name__
else:
    locatable_adapter = adapter

doAnyLocationSensitiveProcedure(locatable_adapter)
...

IMO all permission related stuff is possibly location sensitive stuff, 
therefore the 'real' criteria must be this permission issue and not the 
trusted/untrusted-issue.

IMO the optimum of explicitness would be reached using only a location 
helper function such as assertLocation(). We should resign our plans to 
modify the trusted adapter factory using location proxies if not 
ILocation is provided by the adapter, because those arrangements do not 
solve the problem really, as long as we have to differ adapters in 
relation to their location behavior.

from zope.app.location import assertLocation

locatable_adapter = assertLocation( IAnyInterface(context))
doAnyLocationSensitiveProcedure(locatable_adapter)

>> Then we have to build location proxies most of the time. Is that not 
>> a performance issue?
>
>
> Yes, we don't want to do this most of the time.  It makes sense IMO,
> to use them for trusted adapters, but I consider trusted adapters to
> be a fairly specialized (and useful) tool.
>
That would be strengthen the location helper function, too.


Summary:
----------
I try to collect + and -:

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
0 Developer: Have to be aware of the location issue

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

Regards,
Dominik