[Zope3-dev] ILocation code in zope/app/form/editview.py

[Gary Poster]

On Mar 8, 2005, at 4:11 PM, Garrett Smith wrote:

> Gary Poster wrote:
>> Roger pointed out a problem with the new security checks in
>> zope/app/form/utility.py, setUpEditWidgets, when used in conjunction
>> with the LocationProxy.
>>
>> I've looked at it a bit: it's a bit thorny, with proxies inside of
>> proxies and some odd code.  Jim's suggestion was to try and bypass the
>> whole problem: get rid of the LocationProxy in editview.  I like this
>> idea, but we need to make sure that everyone agrees.  Here's the
>> current pertinent code.
>>
>>      def _setUpWidgets(self):
>>          adapted = self.schema(self.context)
>>          if adapted is not self.context:
>>              if not ILocation.providedBy(adapted):
>>                  adapted = LocationProxy(adapted)
>>              adapted.__parent__ = self.context
>>          self.adapted = adapted
>>          setUpEditWidgets(self, self.schema, source=self.adapted,
>>                           names=self.fieldNames)
>>
>> Jim's proposal is that this become the following:
>>
>>      def _setUpWidgets(self):
>>          self.adapted = self.schema(self.context)
>>          setUpEditWidgets(self, self.schema, source=self.adapted,
>>                           names=self.fieldNames)
>>
>> If the adapter is trusted and implements ILocation, the trusted
>> adapter factory will set the __parent__ and __name__ itself.
>
> Does this happen now?

For trusted adapters, yes.

> I'm surprised that this would be hard-coded in the
> adapter factory. Why not just require the adapter to configure itself,
> if that's what it wants/needs to do?

Good question.  I'm vaguely in favor of that too; maybe Jim knows why, 
though.

>
>> Most or
>> all trusted adapters will want to do this.  If a normal adapter wants
>> to care about the location of its context, it receives it and can do
>> with it what it wills.  This may also have been added before the
>> local site was a thread global, so local component lookup was harder.
>>
>> Roger, this would mean that my suggestion of having your adapters
>> implement ILocation would in fact be the proper thing to do.
>>
>> Thoughts?
>
> I may be missing something, but I'm not comfortable with the seeming
> magic of setting __parent__ and __name__ if an adapter provides
> ILocation.

Makes sense to me, but I don't know the story about that part of the 
machinery.  That's a further code reduction than the one I propose, 
though (or that Jim proposes, I should say), and my immediate goal is 
to unblock Roger.  If Jim is in favor of the change you propose as 
well, and no one else vociferously opposes it, then maybe I can do it 
too.

Gary