[Grok-dev] Re: ZCML

[Martijn Faassen]

Hey,

A debate about ZCML. Let's step back for a bit and think about the 
audiences Grok is reaching and wants to reach:

a) existing Zope 2 developers (familiar or not with Zope 3 tech)

b) existing Zope 3 developers

c) other Python developers who may never have used Zope

Grok is currently reaching a) pretty well. This is really good, as it's 
a related community already familiar with Zope 3 technology and a 
relatively easy way get contributors and users of Grok technology. A 
debate about ZCML may be relevant here.

A debate about ZCML is certainly relevant to existing Zope 3 developers, 
b). There aren't that many of them, and we decided early on that we're 
not really in the business of trying to convince these developers to use 
Grok. It's just not worth it, and we're already allies as we're 
effectively using the same framework anyway!

For c), ZCML is not relevant at all. At most ZCML as something alien and 
non-Python will scare off most of those developers, irrespective of its 
true benefits or drawbacks.

Marketing-wise, we need to reach out to c) the most. We are marketing 
pretty well to Zope 2 people anyway, as we know them, and we're 
partially even the same people. With Zope 3 people we aren't really even 
trying.

Discussions about ZCML are just not relevant for a primary audience we 
want to reach, as they don't know what ZCML is. With that established, 
let's have a discussion about ZCML. :)

Jan Ulrich Hasecke wrote:
[snip]
> Am 31.07.2008 um 03:23 schrieb Robert Gravina:
>> ZCML is dead! Long live the Grok!
> 
> I am more and more uneasy about these statements, though only about the 
> first part. ;-)
> 
> If you get an application from someone else, you only have to look into 
> the ZCML-files and you will soon understand the architecture of the 
> application. The redundancy which violates the DRY-law, seems to me 
> helpful if you read the application.

You make the argument that ZCML is harder to write but easier to read 
than Grok. I wonder however why you wouldn't get the same benefit in 
Grok applications. If you see something is a subclass of grok.Adapter or 
grok.View, you do have a good idea what's going on without even having 
to consult a ZCML file, after all.

I myself also don't have the experience that looking at ZCML files gives 
me a very good idea of the architecture of the application. I might see 
adapters being registered, for example, but I still have no idea how 
they're being used, after all. I can get some idea of which views are 
there, though often the indirection with interfaces still requires I 
look at the code to understand how I can actually look at those views in 
a web browser.

So in my case in order to understand the architecture of an application 
I feel I need to study the code in any case. Since with Grok-based code, 
I can then see the registrations right where I read the code, I will be 
helped in understanding what the application is all about, not having to 
consult a separate file and merge things together in my mind so much.

I'd therefore argue that Grok-based code is usually easier to read than 
code where the registrations are separate. :)

 > Writing ZCML sucks, but it sucks if you do it with vim, emacs or
 > whatever editor you like. If we had a ZCML-aware IDE, it would be
 > possible to build a valid ZCML-file with a few mouse clicks.

I myself don't believe in automating away redundancy with code 
generation, if the code generated is something a human being needs to 
look at.

Plus we don't have a ZCML-aware IDE, and even if we magically had one, 
we won't be able to make everyone use it.

I think there is another tool that helps people explore the workings of 
an application: the introspection tool. This is a tool we actually can 
build and are building. If an introspection tool can show which adapters 
and views are registered for an object, this should help tremendously in 
understanding an application's architecture.

> If you take the ZCML-files as a blueprint of your application, it seems 
> to me a clean tool to master really big an complex applications. I 
> cannot foster this with my own experience, but I've heard people say 
> that ZCML saved their lives.

Well, I have never heard people say that, myself! I've heard people 
indicate that ZCML helped them understand the application before, yes. 
It hasn't really greatly helped me; I find when exploring a new library 
I stare at the doctests and interfaces.py and the code and the ZCML 
files all, and then have to think quite hard to get a picture of what's 
going on.

I haven't heard people with experience with Grok say that Grok makes it 
*harder* than ZCML.

We don't have a lot of experience with a component architecture 
introspector yet.

I'd say it's incorrect to say that ZCML-files are a "blueprint" of any 
kind of your application. By themselves they don't mean very much at 
least in my experience.

> And from a marketing point of view these statements are really bad. How 
> shall I solicit Zope, if more and more people tell me that the tool that 
> hold all these components together sucks? How shall I convey trust to 
> the public, if the Zope guys start to build up a new framework every 
> five years?

The whole idea is that Grok *isn't* a new framework. It's Zope 3, with 
some conveniences, an attitude towards better beginner documentation, 
and a new way to glue things together. Grok could go so far so fast 
*because* it's built on Zope 3. We've never denied this. Grok is new in 
the ways we can get marketing and community benefits from it, and it is 
old in the ways we can reuse lots of great ideas and code.

Zope 3 to me isn't defined by ZCML; the ZCML aspect is just a very small 
part of it. I imagine ZCML looks bigger than it is to many people 
because it's so different and it's so in your face, so you can't help to 
think about it when you think about Zope 3. It might as a result obscure 
the underlying framework more than it helps show its inner workings. It 
surely makes the learning curve a lot steeper early on.

> Let Grok smash ZCML, it is nice to have more than one way to build web 
> applications, but don't curse ZCML.

I didn't see Robert curse Zope 3 or ZCML, just saying it's dead. :)

The funny thing is that Grok uses almost *all* of ZCML's machinery 
expect the XML-based directive parser, which is replaced by Martian. The 
actions that ZCML directives produce are produced by Grok as well, and 
are compatible with them. Grok's configuration system was only possible 
as we had an established, well-known base to build it on.

One of Grok's major features is that it gets rid of the separate file 
XML description of how things are glued together and replace it with 
in-python code declarations instead, with rules for defaults of many of 
them so you don't have to learn them all at once. I believe Grok's way 
is a better way. We can't promote that without saying something negative 
about separate file XML configuration. Criticism, yes. Cursing, no, but 
I didn't see people curse it.

You admit yourself you're not speaking from personal experience 
concerning ZCML. I'd say, don't praise ZCML too much either, then.

Regards,

Martijn