[Zope3-dev] what is ZCML?

[Jeff Shell]

On 3/16/06, Martijn Faassen <faassen at infrae.com> wrote:
> Shane Hathaway wrote:
> [snip]
> > But the ZCML I've
> > written gives me a sick feeling, because I don't know how to refactor
> > ZCML.  The sick feeling doesn't go away, so I get scared of Zope 3. Then
> > I come here, hoping to find comfort.
>
> I share these sentiments. Not that I have a particularly sick feeling
> (I've been immunized by too much exposure? :) but because I'm grasping
> for ways, patterns, to make my code look better, briefer, shorter, less
> repetition, more reuability.

Reuse is overrated. :)

Honestly, I think reuse best happens in Python. I've found it easy to
wrap and roll things up into more common APIs for personal use. This
has been one of the really positive things of Zope 3. But for that
sort of roll up to happen, the environment needs to support common
refactoring patterns (extract method/class/etc). I do not believe that
ZCML supports that.

> > I would feel more comfortable if one of the following things were to
> > happen:
> >
> > 1. The group acknowledges that repetition in ZCML is bad.
>
> I definitely acknowledge his one.
>
> > 2. Someone shows me how to avoid repetition in ZCML.

Use less ZCML. Be creative. Have fun. This answer doesn't work for
everybody, and isn't as easily applicable as I would like.

> > 3. We decide that ZCML is a failed experiment.
>
> On the one hand, I'm not willing to do that. On the other hand, if ZCML
> is to be a simple registration language, I am starting to idly wonder
> why a bunch of CSV tables wouldn't do (and might not be clearer and
> simpler).

Because editing CSV tables sucks an even bigger electrical outlet.
(Honestly - I'm too stupid to understand Excel... But maybe I'm saying
that after spending a week writing an CSV inventory importer. Ugh).

> If ZCML is to be a simple registration language, I'd also like there to
> be a 1 to 1 mapping of ZCML statement to Python code. Right now there is
> a mapping and while it may be reasonably straightforward, I personally
> am still lost in APIs (and it looks like Jeff Shell is too). This
> learning curve should be smaller.

I agree. I think Jim said early on that ZCML should be theoretically
replaceable. Looking at many of the directive implementations, I do
not see this.

If the "Zope 3 CA" vision that I had is to have a good chance of
succeeding outside of this community, I'd hope that it doesn't ship
with or require ZCML.

> Whatever we do, if ZCML is to be replaced we need to replace it with
> something. I think many of the notions of ZCML are dead on - this
> registration shouldn't be happening in normal Python code mixed with the
> rest but as a separate activity. It should allow overriding. It should
> be amenable to analysis.

I'm mixed about whether this should happen in normal Python code. A
few months ago I laid out a vision for how I think it would work.
Basically, configuration would have to be a very locked-down module:
it couldn't really be imported by regular code, wouldn't really
execute when called from 'regular' code. It would, in short, try to
somehow enforce the "importing a package should NOT automatically
register its components."

> > 4. We decide that ZCML should gain more qualities of a high level language.
>
> I personally am quite interested in exploring this, but I'd like to see
> some examples of what this would actually look like, concretely.

We have a high level language. It's Python. I think that people just
have gotten bad at thinking in objects and usable APIs and have
somehow developed a strange fear of the language. I don't get it.

class ArticleEditForm(form.EditForm):
    form_fields = fields.FormFields(IArticle, ITaggable)
    form_fields['tags'].custom_widget = ...

Wow. So much better than <browser:editform>. It's possible to design
other parts of the system like this. I just know it is.

"like this?" "yes" "what is this?" "respects the Python developer".

Now I know forms are a special case, as Tres or Shane or both brought
up. I was just impressed by the amount of actually-helpful objects,
APIs, and base classes in formlib. That one package has made me more
productive and flexible than most of the rest of Zope 3's default
elements (zope.interface/component/schema/app.container excepted). I
think we can learn something from it. At least, I hope we can. Zope
can, at the end of the day, only provide some good core tools. I think
those tools, and the concepts behind them, should be simple. Then if
someone wants to build the giga-framework on top of it, they can. But
also, if I'm writing what should be a simple application like the
PyWebOff example, I don't have to waste time on countless elements
that don't apply. I don't have to waste time editing more XML than
Python. Etc.

Honestly: Rails is very appealing with its "we use Ruby for
everything" message. But Ruby's syntax and use of blocks seems to make
this more tenable than it is in Python. I'm not a big fan of their
"convention over configuration" design, but it's winning me over
slowly. The more I fight with ZCML and all of the surprises I've
fought with in recent weeks, the more appeal that design has. I'm not
advocating that we go to it. I'm just saying that it's an INCREDIBLY
appealing message, especially to someone who's not trying to write a
super powerful framework but instead is just writing a one-off web
application like Snippets [1]

[1] http://www.bigbold.com/snippets/

> > 5. We solve this some other way.
>
> This would be satisfactory too. :)
>
> > I recognize that #3 and #4 are very risky, and we've already been over
> > the risks, but I include them because they still feel better than the
> > status quo.
>
> We can mitigate some of the risks of both #3 and #4 as we could do them
> as separate, experimental, non-Zope projects.
>
> > I can't help but wonder if ZCML is largely a reaction to the horrible
> > initialize(context) methods in CMF products.
>
> In non-CMF Silva we also got horrible initialize(context) methods, and
> we've got horrible and long install.py files. When looking at ZCML we
> should clearly keep in mind that what it replaces. Silva's install.py
> expressed in ZCML would be preferrable to what we have now in most ways.

I have files like that. Even worse, because in a lot of mine I've put
registration code in the top level of the module (or the top level of
an __init__.py!). Import the module, it does crap to the registries.
Ugh. Bad choice. It doesn't mean that Python was a bad choice, but
just that the way I used it was. That's the danger. But at least I had
a chance of putting a 'import pdb; pdb.set_trace()' statement in that
module and stepping through what was going on when I didn't understand
something. ZCML code has not been so easy to follow.

The zope.component API (particularly the bits for registering and
getting adapters and utilities) is easy to follow and easy to keep in
my head. So, where possible, I just want to keep my ZCML closer and
closer to that. Less conceptual leaps.

--
Jeff Shell