[Grok-dev] Re: ZCML

Martijn Faassen faassen at startifact.com
Thu Jul 31 12:55:27 EDT 2008

Kent Tenney wrote:
> On Thu, Jul 31, 2008 at 8:11 AM, Martijn Faassen <faassen at startifact.com> wrote:
>> Hey,
>> A debate about ZCML. Let's step back for a bit and think about the audiences
>> Grok is reaching and wants to reach:
> Re: public relations, it's been helpful to me to consider the heritage of ZCML,
> the fact that it emerged from a wealth of experience.

I definitely agree there. Grok has a very powerful configuration system 
and one of the main reasons it has the concept of configuration at all, 
and we're able to build cool things on top of this, is because Zope 3 
went the ZCML route, which was driven by experience.

> As a lurker, it looks to me like the complexity of ZCML is justified by it's
> capacity to virtually remove barriers to scaling in any direction.

I'd call this power the "Zope Component Architecture"; ZCML after all is 
just a particular way to fill the component registries. The ZCA indeed 
makes it possible to write applications that are pluggable out of the 
box, and in addition makes it very easy to write micro-frameworks for 
particular problem domains.

> I doubt I'll ever exploit that power, but Grok allows me to build simply,
> no interference from ZCML, but I don't have to worry about hitting
> any walls, because of the experience which has gone into the
> underlying Z3 and ZCML.

Agreed again - replacing "ZCML" with "ZCA" again. :)

> The powerful beast that is ZCML will only be unleashed if needed.

This is what Grok tries to add to plain Zope 3 - make the component 
architecture available, but not "in your face" until you end up needing it.

> After Pycon 2008 I read a post which opined that Django was heading
> for a wall which Zope2 hit. I'd like to hear that expanded on,
> I suspect it references issues which resulted in design aspects
> which include ZCML. I think that would make very good reading
> for framework shoppers.

I share this suspicion about Django, but I cannot really confirm it as I 
don't presume to know Django well enough. I think we should be very 
careful in comparisons with other frameworks in our public 
communication. It would be extremely interesting to hear from someone 
who has experience with both Grok (or pure Zope 3, perhaps) and Django, 
but to publish this on our site will undoubtedly invite accusations of bias.

One attempt in at least some comparison with the competition that I've 
made a while ago is here:


Grok is building on a system with an explicit notion of configuration, 
and a general system for component gluing and lookup. I myself am 
convinced that this is a tremendous advantage on the long term, for 
applications that need to grow, be extended and scale. It's 
unfortunately also hard to explain this advantage well without sounding 
very abstract.

I think the best way to show this advantage is by showing the *results* 
of the advantage, in two ways:

* "oh, you want to override that behavior? *of course* that's possible, 
here is how..."

* "sure, we have a component that can do that for you. we also have 
this, and that and that other feature."

I've tried to communicate things like this at my EuroPython talk this 
year; Grok is cool, Grok is based on deep experience, and feature-wise 
it has a lot and is overtaking the competition.



More information about the Grok-dev mailing list