Philipp von Weitershausen wrote:
Stephan Richter wrote:
- You do not argue how the decision-making process is "highly inconsistent".
Fair enough. I will update the proposal later. Supper first :).
- I do not understand what's so bad about coming up with your 3rd-party ZCML
directives. They are extremely easy to write and use. I think that 3rd-party
ZCML directives are not a bad thing. And yes, I would like to keep those in
a separate namespace.
Sure, it's easy to write ZCML directives. It's also possible to write ZCML
directives that are easy to use, but just as well to write ones that are hard
to use. So your generalization above is a bit too, well, general :).
The problem is uncontrolled ZCML directive proliferation. It's "bad" enough
that you have to familiarize yourself with a new API when dealing with a 3rd
party Zope package. But having to learn a new set of ZCML directives?!? I
think many people would be skeptical. Me included.
I don't see the problem with learning new ZCML directives when I'm
learning a new package. I can see why you'd like to reduce the
occurence, and I think sometimes configuring things in ZCML is actually
doing it in the wrong place, as information needs to be persistent
sometimes. Learning a new ZCML directive is the least of my concern when
learning how to use a new package, however.
Moreover, sometimes a package introduces new ways to configure
components. Five does so, for instance, and Silva will too eventually.
As we have learned that we can reduce nearly all component tasks to adapters
and utilities, many tasks revolving around registration and configuration of
policy also only involve adapters and utilities. By using those "elementary"
directives we can stimulate the learning process for developers ("there should
only be one way of doing things"). Yes, you might have to use two or three
directives instead of just one new one, but you'll know what you're doing...
And you'll remember it in 2 months. I think that's more valuable than saving a
couple of lines today.
I think I disagree with this one too; the situation is at least rather
more subtle. Sometimes a new, short directive is a lot easier to
remember than to remember long.dotted.names.pointing.to.places and 3
directives. Having to remember (or worse, look up) long dotted names is
extremely common in ZCML and I consider it at least as big a problem as
having to learn directives. Let's use abstraction and naming things
where it makes sense.
Heh, perhaps we need to go the other way and add a namespace directive
for long dotted names instead. :)
That said, there might still be a small percentage of cases where custom
directives are a valid tool. I can accept their being on the same namespace as
others. In fact, I would like it to be that way, reducing the amount of dead
chickens (namespace declarations).
Namespace declarations are not dead chickens. They're things that the
XML language requires. Indentation and colons are not dead chickens in
Python either. *particular* namespace declarations may be unnecessary -
but not dead chickens, just perhaps the wrong solution.
Zope3-dev mailing list