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

Reply via email to