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 .
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 , 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 :(
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.
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