[Zope3-dev] Re: a plan for widgets?

[Jeff Shell]

On 3/20/06, Tres Seaver <tseaver at palladion.com> wrote:
> So *don't use ZCML*;  use Python:  there is literally nothing which can
> be done in ZCML which cannot be done in Python.  I wish that folks who
> don't like / need ZCML would quit trying to dictate how the rest of us
> use ZCML.

"Literally nothing"? Try literally everything. I'm sorry. But that was
the experience I had that set me in such a bad temperament. I had no
idea what half of these directives were doing, and when trying to
duplicate them in a test environment I nearly threw the laptop to the
ground and swore of programming forever. I was *INCREDIBLY*
frustrated. There is a lot of potentially valuable functionality
*hidden behind ZCML*. If a ZCML directive were a one line
wrapper/adapter around a common function, I'd feel different.

My argument and wish has been only this: simplify ZCML. Make it more
transparent what it is doing.

> Or, if you like ZCML but don't like the current directive set, feel free
> to propose a new set of directives you think are better, and implment
> them in *your* namespace:  if enough other people like them, we can talk
> about making people who are already using the current set change.  But
> let's quit tearing up what people have alredy learned in favor of a
> it-must-be-better-because-its-new variant which doesn't yet exist, and
> whose improved usability we have to take on faith.

My set of directives is <adapter>, <utility>, <class>, and maybe
<interface>. Inside of <class>, <requires>, <allows>, <implements>,
and <factory> (because I do believe that 'factory' there is a nice
shortcut).

Nothing new. Only less. Less concepts to have to remember. Less
concepts to have to look up. Less code to have to try to follow when
it's 10:30 at night and I've been working six hours too long and I
still can't figure out why my field adapter on an IChoice isn't
getting its value set properly and I can't get a vocabulary
bootstrapped up to write a test to debug and then verify the fix of
it.

Make ZCML do whatever you want. But if you're going to share it, it
needs a HELLUVA lot better documentation. I'm glad for what's there
now. But I've been surprised by ZCML one time too many, and have lost
too many hours trying to figure out the surprise. Too many similar
directives, too many possible attribute combinations, and too little
information about what certain choices will actually do or what
they're good for. And the source is not a readable, reliable backup
point to look at.

> I'll note that the "Refactor mercilessly" meme from XP is *not*
> particularly well-suited to frameworks / libraries:  it is best suited
> when applied to *applications*, where the impacts of such changes are
> borne entirely by the people who make them.  When you tear up the API of
> a framework / library, you force *other* people to make changes, often
> without any particular benefit to them.

What is well suited to frameworks and libraries is to provide maximum
playability with a minimum number of concepts. When the component
architecture was simplified (Zope 3.0 -> Zope 3.1), the whole thing
suddenly made a whole lot more sense to me. Utilities and Adapters.
Nice. There are a lot of ways those can be combined, especially when
multi-adapters come into play. But the core concepts are clean and
simple.

Transparency also counts, especially with open source. Even with books
and APIDOC, I still have to consult the source a lot (and a lot (and a
lot (and a lot (and a lot)))) to try to understand the best
application / use of something. ZCML lacks transparency - the language
of the directive implementation seldom plays out like something I can
read and understand. There's another framework, another run-time,
going on there. And I understand why: it's bootleg/startup service.
But when shit breaks, or acts funny, debugging it is nearly
impossible. At least with Zope 2's initialize(context), I could stick
a pdb.set_trace() at the beginning of such a function implementation
to step through the loading process. It wasn't the easiest code to
follow, and was a long and painful process sometimes, but I could at
least follow obscure (and accidental) bugs and problems to the source.

Go ahead and make ZCML the most beautiful new language you want it to
be. But it's got *severe* problems right now. And the "just about
anything doable in ZCML can be done in Python" line does not work. I
have scars to prove it.

--
Jeff Shell