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 _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com