[Zope3-dev] queryAdapter via __conform__

[Dominik Huber]

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.

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

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__' ****.

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

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

Thanks for being so patient...
Regards,
Dominik

*** example form framework: (zope.app.browser.form.editview.EditView):

    def _setUpWidgets(self):
        adapted = getAdapter(self.context, self.schema)
        if adapted is not self.context:
-->         adapted.__parent__ = self.context

**** example adapter registration
<class class=".BarFooSchema">
    <require permission="x.ManageBar"
             interface="IFooSchema"
             set_schema="IFooSchema"
--->         set_attributes="__parent__"
             />
</content>