[Web-SIG] Re: ZCML and Zope 3

[Martijn Faassen]

Paul Boddie wrote:
> Martijn Faassen <faassen at infrae.com> 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