[Zope3-dev] RFC: Reducing the amount of ZCML directives

Philipp von Weitershausen philipp at weitershausen.de
Mon Feb 13 07:49:23 EST 2006

Lennart Regebro wrote:
> Uhm. -1, actually. I think getting things out of ZCML is a good idea,
> but I think this shoots slightly beside the goal. This proposal aims
> mostly at getting rid of statements that can be done with other
> statetements, but using more lines.

Sometimes not only using more lines, sometimes only using 2 or 3 more lines.
I'd say whoever wants to save 2 or 3 lines at the expense of indirection is

> I think that goal is misguided, as
> it would require you to make longet ZCML files with more basic
> statements. This in  turns means you need to understand more of what
> you are actually doing.

Well, how much longer would the ZCML files really be? Sometimes one, sometimes
two lines longer per statement. dav:provideInterface is a very very rare

Plus, I don't think letting people in on the secret that factories are
utilities, for example, is a bad idea. Let me tell you something, I as a book
author have to explain it anyways. And you as a reader of my book will want to
know it, too. Now, you already know factories are utilities. Let's register
them that way, then. You might actually soon enough remember the usage of the
utility directive, but do you always remember the usage of the factory

There should be one and only one way to do things. Even if it takes us one
extra line.

> Remember that many of these statements were
> introduced because ZCML was too obscure and you needed to understand a
> lot of different interfaces do know between which interfaces to adapt
> for example.

I think that this will make ZCML less obscure. I also don't think my proposal
is about the really obscure ZCML statements.

> Many of the statements you want to deprecate should be deprecated,
> true.

I'm confused. I thought I'm shooting slightly beside the goal :).

> But I think the main effort of ZCML simplification is to move
> things into Python that does not belong into ZCML at all.

Yes. This proposal is only scratching the surface of this problem. As I said in
my email and point out at the end of the proposal, this is just the beginning.
The more extensive ZCML directives like browser:page and the form directives
require a lot of thinking. I'm not there yet :). Let's take it step by step.

> And my main
> contender for ZCML deprecation would be the adapter statements.  As
> you say. "In general, ZCML should only be responsible for registering
> a component, but not for defining its behaviour". When you write an
> adpater, it will be hardcoded into the adapter itself which interfaces
> it adapts between. You can not take an adapter written to adapt
> between two interfaces and use them to adapt between two completely
> different intefaces, for obvious reasons. So why would the adapter
> statement be necessary at all? Well, currently I think it's necessary
> because we need to have adapter factories, and there are
> multi-adapters and such. But somehow I feel that at least most of
> these cases can be done without any ZCML statements at all.

The adapter statement is still necessary as an on/off switch. Who says that you
always want that adapter? And perhaps you want to override it with a different
one. ZCML is good for on/off switches, Python isn't.

> Simplification of ZCML should have the goal not to have less
> statements, but not to do things in ZCML that shouldn't be done in

I disagree. The simplification should be about both.

> and to have statements that are easy to understand, even for
> people who do not have all interfaces in zope.app in their head.

I hope zope.app will go away :). Seriously, I rather have meaningful interfaces
with which I register *and* look-up stuff the same way than registering
something with a factory directive and looking it up by IFactory. I see no
connection obvious connection there. And you will have to remember the
interface anyway, whether you use <factory /> or not...


This message was sent using IMP, the Internet Messaging Program.

More information about the Zope3-dev mailing list