Lennart Regebro wrote:
On 3/20/06, Tres Seaver <[EMAIL PROTECTED]> 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 :(


[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.
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to