[Zope3-dev] Form framework, adapters and pau

Jim Fulton jim at zope.com
Fri Apr 8 10:55:32 EDT 2005


OK, here's an alternate proposal:

   If the permission attribute is used in the adapter directive and the
   permission is not zope.Public, then:

     If the adapter doesn't provide ILocation, we location proxy it and
     set the parent.

     If the adapter does provide ILocation and it's __parent__ is None,
     we set the __parent__.

   This will be accomplished with a custom factory.

Does this make you happy? :)

Jim


Dominik Huber wrote:
> 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
> 


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the Zope3-dev mailing list