[Grok-dev] Re: ZCML

[Kent Tenney]

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 find parallels to LDAP, which at first glance looks arbitrarily
complex and arcane.
With study, it becomes apparent that it's architecture allows amazing
scalability,
things like transparently adding a branch which lives in a different
db accross the globe.
I'll never do that, but it takes the edge off the learning curve to realize that
there are good reasons behind the oddness.

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 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.

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

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.

Thanks,
Kent

>
> 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
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>