Martijn Faassen <[EMAIL PROTECTED]> wrote: > >Buggy? I don't think ZCML is buggy. Where's that coming from?
I'd guess that what may have been meant by "buggy" is the observation that by introducing a configuration language alongside the actual work-performing system components, there may be the chance of subtle bugs and misbehaviour arising from difficulties synchronising the ZCML descriptions of the components and the components themselves. Not that I've looked deeply into ZCML, however, but I can sort of understand people when they say that Zope 3 has drifted into J2EE territory. >For some tasks Python is *not* the ideal language. I've seen the >way we glue up components in Zope 2; either stuff is stored in >inaccessible ZODB based databases configured through a lot of bad >web user interfaces, or you see a lot of grotty Python code which >hacks together component configuration. A domain specific language >which does this and only this is a massive improvement. Just the >ability to *think* about this problem separately helps. We >*weren't* writing clean Python code. I've seen this problem occur >over and over in Zope 2 projects. I don't doubt it. The Zope 2 configuration hooks produce quite a neat user experience for administrators, but there's a lot of boilerplate to get wrong (and to confuse beginners). One of the most significant innovations that I saw in the Zope 2 world, albeit from outside, was the whole "components" thing which I presume led to the more pervasive use of interfaces in Zope 3. However, for all this cleaning up, I wonder about two things: the optimism about how patient beginners are in following huge tutorials which don't seem to really show that much (even though instilling the test-driven development discipline may be important); and the way Zope 3 is promoted and how visible/accessible its documentation is. As I noted on someone-or-other's blog, people following tutorials get quite confused and impatient if they're required to "stack up" lots of seemingly arbitrary details. And as someone else noted on their blog, the entry point to Zope 3's documentation is something of a case of "beware of the leopard" (as is following such discussions on different blogs, of course). >I see this attitude towards domain specific languages all across >the python world. People don't like XML document formats either, as >they can just use clean, simple, Python datastructures. And lose >interoperability, accessibility by a host of programmers that >*don't* know your codebase, and code yourself onto an island. There's so much to say on this, but not enough time! I think that the principal objection is that since Python is a programming language, and that Python programs are effectively object manipulating and configuring "scripts", Python may be the best tool for the configuration of components. Of course, there's always the issue of whether you can inspect such "configurators" from other technologies if they're written in Python, and there's always the contention that a full-on programming language can cause more trouble than it gives benefits in such narrowly-defined situations. I think it's harder to argue for using Python when expressing bundles of "pure data", although there are always going to be people in the "S-expressions trump XML" camp who will keep the argument going. Paul ___________________________________________________________ $0 Web Hosting with up to 200MB web space, 1000 MB Transfer 10 Personalized POP and Web E-mail Accounts, and much more. Signup at www.doteasy.com _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
