Dominik Huber wrote:
A few months ago the following code block was removed in, and (revision 29418):

   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,

As a consequence each trusted adapter class should now implement ILocation

One could, as an alternative, use an non-trusted adapter that is public and rely on the underlying object protection.

> that the TrustedAdapterFactory can set the location of adapter
instances correctly. Otherwise, only the global authentication is involved and the edit view fails if any local principal tries to edit a certain field (security.canWrite(source, name) in line 207).

I would like to revert those changes. IMO a framework like the form framework knows the context (location) and adapts that context to a certain schema. If the following procedures depends on location information, the framework itself should pass such informations in a smart way. It's an unnecessary <se?lp=ende&p=/Mn4k.&search=unnecessary> expense <se?lp=ende&p=/Mn4k.&search=expense> to force all schema adapters to implement ILocation:

- The solution using the location proxy seems fairly famillar
 compared with the container framework and containment that does not
 provide ILocation.

Except that the object being location proxied is already security proxied. Location proxies were not designed to proxy security-proxied objects.

- An adapter that implements more than one interface cannot be registered
 with the implicit adapts and implements informations.


- A regular schema does not extend ILocation therefore it is not obvious to
 write an adapter implementing ILocation.


Any objections?

Yes. :)

Why not simply use an untrusted public adapter?


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to