Paul Boddie wrote:
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.
ZCML is not so much descriptive; that's left to interfaces. I can
imagine scenarios like this arising, though I haven't run into clear cut
cases that I can recall myself.
If you moved your configuration to explicit Python code, I don't see how
this would change, however. Only if you could somehow derive your
configuration from Python code would this be better, but I'd be far more
worried about the magic involved in that than about possible skew
between ZCML and Python code.
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.
I don't know J2EE well enough to judge that. ZCML is just a language
where you can hook things to other things. You can specify which adapter
can adapt a certain interface to another, for instance. You can also
specify "template 'something.pt' is used to view objects of interface
IFoo through the web, under name 'bar.html'". There are also bits about
security, and what appears in which menus (if you use Zope 3's ZMI), and
special statements to quickly build edit forms from schema information, etc.
For some tasks Python is *not* the ideal language.
[snip]
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);
I worry about the same thing exactly. I do not think the Zope 3 tutorial
by Jim Fulton is very encouraging to beginners. If he gives the tutorial
in real life, it takes two days, and at the beginning of day 2 you're
lucky if you write your first functional doctest. Which doesn't give any
gratification at all. The two recent Zope 3 books do better hopefully (I
have only browsed through both so far). I've tried myself with my Five
tutorial, which has the benefit of focusing on that subset of Zope 3
which is usable from Zope 2. I've had some feedback to that which seems
to indicate I'm on the right track there.
and the way Zope 3 is promoted and how visible/accessible its
documentation is.
Yup, that just really plain sucks. See my comment here, if you haven't
already seen it:
http://faassen.n--tree.net/blog/view/weblog/2005/04/06/0
Now the developers will probably make the argument that it's not ready
for wide usage yet and that we should still promote Zope 2, but I think
that's not correct, as the only way we'll make it ready for wide usage
is to actually have increased usage, and for that, we need to promote it. :)
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).
Perhaps it was my blog; you might recognize it. :)
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.
Yes, I think both issues, both inspectability and risk (because of the
wide scope of Python it's tempting to use it wrongly) are good
arguments for domain specific languages once every while, let it be for
web templating or component configuration. That said, I'm sure a
suitably documented Python API would also do the trick. You'd just load
a 'configure.py' instead of a 'configure.zcml'. I am not sure whether
the complaints would go away though if you did that, and the risk of
having this mixed with functional code is large.
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.
And the people in the "Python datastructures trump XML" camp as well.
Sometimes they do trump XML, and sometimes they don't, but the
"sometimes they don't" seems to be convieniently ignored all too often.
Yes, Pythonic APIs are good, but you can have them when manipulating XML
as well, and some pain for interoperability and cross-language
understandability can be worth it, anyway.
Regards,
Martijn
_______________________________________________
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
