[Zope3-dev] Re: One namespace for ZCML

[Martin Aspeli]

Philipp von Weitershausen <philipp <at> weitershausen.de> writes:

> 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.

Or a new python API... your package will have to come with documentatio about
how it is to be used. If Zope encourages a consistent way of demarcating what is
ZCML-configured, what is python-configured and what is not configuration at all,
this problem will go away.

> 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.

There is always a balance between the aesthetic beauty of reducing everything to
a few axiomatic principles, and the way people think. I think you'll find that
many people get confused by the view/multi-adapter duality. Yes, it's very neat
when you finally get it, but it took me a long time to get my head around it
(partially, I admit, because I was reading poor documentation... when I read
your book, it made a lot more sense). Be sure to draw a clear line between what
things are the same because the implementation lends itself to use the same
primitive components, and what things are actually semantically equivalent.

> 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).

I think this is based on a misunderstanding of how XML works (or should work)
combined with a somewhat irrational fear of writing a few extra letters. You
don't have to declare namespaces you don't use in any particular file, nor do
you have to stick to long-winded prefixes if you don't want to. The URIs of
namespaces are unique identifiers and can be quite short (e.g.
http://zope.org/dtd/core). Ideally, they should resolve to DTDs that can be used
for XML validation and by tools to create code-completion etc.

Now, if Zope decides that it has a sufficiently small set of concepts to warrant
keeping them in a single namespace, that's probably a good thing - less to
learn, less to remember. If it turns out there are very clear components with
different areas of use, having different namespaces may well work. I'm not a fan
of the core vs. browser namespace separation at the moment, for example, but I
could see how something radically removed from the core Zope use case would find
use for a separate namespace.

But third party products that have not (yet) been rolled into core Zope must
have their own namespace, to avoid clashes, to permit validation, and simply to
meake it clear what is being provided by the third party product.

Martin