[Zope3-dev] Re: RFC: ZConfig and other formats for ZCML

[Philipp von Weitershausen]

Martijn Faassen wrote:
> After thinking about it for a little bit, -1.

Same here.

I too am all for experimenting with new ways of expressing component
configuration. That can include the amount of what we configure in ZCML,
the semantics and the syntax. There should be no tabus. Before we go
experimenting, however, we should be clear of the current deficiencies,
though. Just stating that "some people feel that using XML for
configuration is too cumbersome" doesn't do it for me and from quickly
reading over this thread, I haven't gotten much more than vague
statements about the unaesthetics of ZCML. (Of course, to us
Pythonistas, aesthetics are somewhat important...)

The proposal doesn't go into a lot of detail (it's bit of stirring
around) but then again mentions generating SAX events from ZConfig
directive. This all sounds very speculative to me.

A lot of people have expressed in this thread that using XML has certain
advantages. I share everyone of those points (easy parsing and
generating in 3rd party tools, validation, etc.). I think we can adress
some of the people's concerns first by making ZCML itself less
cumbersome. I volunteer helping out here. My blog entry where I propose
a lot of changes has been quoted several times already. I want to start
there.

> * Lesson from Gnome: adding more options doesn't make a user interface
> (including our APIs and configuration languages) easier to use; the
> reverse happens. It shouldn't be used as a way to avoid debates about
> what the right one way should be. Concretely, genericity won't bring us
> much: ZConfig might be considered by the community as the 'new way', or
> people will stick with ZCML -- people won't generally invent new
> syntaxes when they write a new Zope 3 application.

I think it is important for any kind of system that deals with humans to
provide one obvious way of doing things. Python, believe it or not, is
that way. Of course, you can still do things in many different ways, but
when I read other people's code, I'm always most comfortable when it's
Python because usually I would have written it the same way.

I don't want to have to familiarize myself with custom configuration
syntaxes that people come up with just because it suits themselves. Zope
should be a bit educational in that respect (as it already is with other
things, such as ZPT, for example), just as much as Python is educational.

> * I don't think the few people that are interested in such syntax
> experimentation need implementation support for this in Zope 3, at
> present. Writing code that generates ZCML is easy enough -- XML
> generation is well-understood.
> 
> I'm not convinced ZCML is intimidating primarily due to its syntax. I
> think the XML syntax is only a minimal issue compared to the other
> things that make it intimidating, namely that ZCML exposes the component
> architecture.
> 
> I think there's lower-hanging fruit to invest energy in simplifying ZCML
> *semantically* as it is now first, before we work on alternative
> syntaxes or consolidating engines.
> 
> Finally, ZCML works. We've spent energy in educating the Zope community
> (3 and 2) in its use. People have learned it. We have working code. Why
> throw away that effort and introduce something new? Is ZCML really that
> horrible? Do we really think people will come in droves to Zope 3 after
> we change it to ZConfig? The *syntax* of ZCML is a very minimal issue
> compared to everything else when learning Zope 3. I think we have much
> more to gain in improving the semantics of ZCML first, then come back
> and reconsider syntax.

I *do* think that ZCML is intimidating as it is, especially to Python
programmers. I also think that if there's a problem with something in
Zope it needs to be fixed, no matter how much working code or docs we
have. Perhaps I'm a utopian in that respect, though certainly a bit of a
devil's advocate.

I think there are ways to make ZCML less of a problem for Zope 3's easy
adoption: a) make Zope 3 "scale down" e.g. via bobo, b) reduce ZCML to
be more about application policy (on/off switches) and less about
definition. Fortunately, people have announced that they'll work on both
of these things in the future. We should wait and see what these
projects bring. If the improvements they promise will still not be
enough, we can re-evaluate.

Philipp