[Zope3-dev] queryAdapter via __conform__

[Jim Fulton]

Dominik Huber wrote:
 > Jim Fulton wrote:
 > [...]
 >
 >>But __conform__ is a very different mechanism. Given that it is
 >>a very differtent mechanism, I'm not surprised that the way things
 >>are proxied is different.


 > Given the fact we can't change the different mechanism to obtain a
 > consistent behavior we are faced with the problem to make the
 > overlying frameworks and users kind of __conform__-aware. We have to
 > declare that adapters can be proxied or unproxied.

 > I'm not surprised too because meanwhile I almost know the blackbox
 > inside queryAdapter :) But somebody who uses the api queryAdpater
 > (as I before) has no chance to be __conform__-aware and he will
 > *except* a consistent behavior whatever very different mechanism are
 > encapsulated inside.

I don't know of anyone else who has been surprised by this before,
because:

- Almost no one is using __conform__.

- Use of adapters in forms is also rare.

Two rares make a very rare. :)

 >
 >
 >>It would be cleaner if the __conform__ method set the __parent__
 >>attribute before returning the adapter.  It would be good
 >>to modify editview to check whether the parent was already set before
 >>setting it. Feel free to make that change if you want. :)
 >
 >

 > I'm willing to change the form framework (if the others appreciate
 > those changes) but I'm not realy happy with your proposed solution.
 > The purpose is to provide an IFoo adapter via __conform__. IFoo does
 > not declare __parent__. In the real live I have no chance to guess
 > that somebody in an overlying framework likes to inject a __parent__
 > attribute into my IFoo adapter. (In those moments it's pretty cool
 > to have a security-proxied adapter that resents such intrusive
 > intentsions :)

Good point.

 > I would prefer to change the form framework the same way containers
 > behave handling its simplistic containments. IOW I would like to
 > decorate __parent__ inside an overlying frameworks instead of
 > injecting __parent__ into the adapter*** or extending all class
 > directives by set_attributes = '__parent__' ****.

Which is what the form framework does now, sort of.

 > Would that be a passable way? I'm not realy aware of all the
 > possible invocations of such a decorated adapter during his journey
 > through zope3 (-> Event publishing).

 > Should such a decorator implement ILocation? Or another interface
 > like IAdaptionContext:

 > class IAdaptionContext(Interface):
 >     """Locate an adapters via it context.
 >     """
 >     __parent__ = Attribute("The context of the adapter")

Hm, we should probably use a LocationProxy here.

See zope.app.location

 >>What is important is that the underlying content is protected.
 >>The current schema achieves that.  Adding extra proxies around adapters
 >>that adapt proxied objects doesn't improve the protection.
 >>Removing proxies
 >>around adapters of unproxied objects removes needed protection.
 >
 >

 > When I looked at the problem the second time I recognized that
 > security-proxied adapters supply a pretty cool protection.

 > A metaphor illustrating the fact: I see a proxy like a protection
 > shield (blue laser orb).  Providing an global adapter is similar to
 > wrapping such a protection shield (including its object) inside a
 > carton box (adapter). The carton box is still outside an has to
 > resent intrusive intentsions such as __parent__ injections by
 > overlying frameworks.  The other way is the adaption via
 > __conform__: It puts the carton box into the 'same' protection
 > shield via the proxy-mechanism. The carton box is protected too and
 > does not get wet. (I do not intend to provide nested laser orbs. I'm
 > already happy with the __conform__ way).


 > I don't intend to bother you with stupid questions but would it not
 > possible to achieve the same protection for global adapters too?
 > Kind of unbag the object, then wrapping the unproxied object and
 > then proxy the resulting adapter.

See:

   http://mail.zope.org/pipermail/zope3-dev/2004-February/009742.html

for a discussion on this topic.

Generally, you want to adapters to be publically accessable
and to protect the objects they adapt.  I want to make this
easier to spell.

Jim

-- 
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