[Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review

[Dominik Huber]

Lennart Regebro wrote:
> On 3/20/06, Tres Seaver <tseaver at palladion.com> wrote:
> [...]
> This doens't really make the number of statements smaller, and it
> doesn't save very many lines of ZCML. But it *does* make it pretty
> darn obvious what to do. Because you can't do much else.
>
> Note again that this is not a proposal. I'm not saying we should do
> this. I'm just saying that simplifying can be done in several ways,
> and this would be one (not nessecarily good) way.
>
> (In fact, I think I like this, but it can without any problems be made
> into a separate product that adds this statement to ZCML, for
> simplified product creation).
I like your focus to higher levels of usability.

level 1 -> ca basics: class, utility and adapter
                    ^
                     |   implemented by
                     |

level 2 -> developer patterns: class, utility, adapter, view, factory, 
skin, layer etc.
                    ^
                     |   implemented by
                     |
level n -> ...

As you pointed out the question of simplicity depends on a certain 
abstraction level (perspective).

It's important to provide different logical abstraction levels, because 
there are a lot of people interacting perfectly with a physical system 
on a certain abstraction level without knowing any implementation 
details on a deeper level [1].

Phillip's design principle ("There should be one-- and preferably only 
one --obvious way to do it.") is very important within a certain 
abstraction level [2], but if we apply this rule over all levels we will 
increase complexity for higher level use cases. IMO for a bunch of 
people that's pure-zope 3-anti-marketing :(

Regards,
Dominik

[1] Example:
Use case on level 2:
Register and invoke a factory:
It's necessary to have an API for the factory registering and 
-invocation, but it's not necessary at all to know that factories are 
implemented as utility.
Register a class:
It's important to register a class including its marker interfaces, its 
factory and its security declaration in simple way.

[2] Example:
The biggest violation of this principle is the adaption-mechansim 
itself: Neither the convenience function IFoo(context) nor the other 
API's provide uniform adapter artefacts (-> adapters providing location, 
location proxied adapters, security proxy around the context, security 
proxy around the adapter). This lack cannot be hidden properly on higher 
abstraction levels. This fact is leading to weird ZCML-directives.