[Zope3-dev] Adaption versus Implementation (ILocation code in zope/app/form/editview.py)

[Dominik Huber]

Excuse me for the late response, I had nice winter vacations :)

Almost a years ago I put that location proxy code into zope 3 because I 
experimented with self-adaption (__conform__).
Within the edit-view calls somewhere a zope2-like __parent__-attribute 
patching happens. That was causing a securiry exception. After a 
discussion with Jim the location proxy seemed to workable solution at 
that time.

I was not happy with that solution too because it introduced another 
distinction between adaption and implementation. The editview code had 
already other adapter-user-traps. IMO we should try to prevent them, 
because they are not very obvious for developers using such a package 
and they will provoke errors as long they exist.

IMO we should generalize that issue because it is actually an adaption 
versus implementation issue.

*IMO the whole adapter story should be strongly transparent*. That means 
nobody should care if something is implemented or adapted inside 
mini-applications or frameworks such as the form framework for example. 
We should not introduce distinctions between adaption and implementation 
there because it will reduce the main benefits as simplification we 
wanted to earn introducing the adapters.

other two examples:

events
------
zope\app\form\browser\editview.py, line100:

                if changed and self.context is self.adapted:
                    notify(ObjectModifiedEvent(content))

Events should not be an issue between adaption and implementation, but 
rather an issue of different abstraction or functionality layers of an 
application  Why a certain schema adapter should care about events? IMO 
a realisation should provide functionality that belongs to its 
abstraction level only. That means the realisation of a stupid schema 
should be always stupid. If a developer does not have to care about 
events implementing a certain schema within a content type, he will be 
not aware using events coding an adapter providing the same schema. Such 
an issue may look artificial at the first glance but it will instabilize 
*all* mini-applications or framework listen to ObjectModifiedEvent 
(Serial error risks in perspective of risk assessment).

different adaption mechansim
-----------------------------
At least the security proxy confusion is pretty old too. The 
self-adaption (__conform__) was proxying allways like
the trusted adapters today (proxy around the adapter). On year ago there 
were no trusted adapters and the adapter was never proxied, only the 
object inside. I was pretty suprised that I should handle results of 
different adaption mechanism differently, because I found no way until 
now how I should handle that circumstance inside my code properly. At 
that time I got the following response from Jim:
 >/ 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.
/
True, but I like to be lazy in matters of deeper abstraction layers. 
That means I should not care about different proxy mechanism of the 
result if I'm using adapted = IAnyInterface(object).

Thoughts?

Dominik Huber
/
/