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.
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.
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).
This message was sent using IMP, the Internet Messaging Program.
Zope3-dev mailing list