[Web-SIG] Re: Just lost another one to Rails

[Martijn Faassen]

Anthony Baxter wrote:
> On Wednesday 13 April 2005 23:05, Martijn Faassen wrote:
> 
>>Buggy? I don't think ZCML is buggy. Where's that coming from?
> 
> I wouldn't say ZCML is *buggy* as such, but it _is_ an utter pain
> in the arse to debug and get right. If you spell it wrong, you either
> get a broken web application with no useful traceback, or else a 
> monstously hideous traceback that's almost entirely useless. 

That traceback actually is useful fairly often, though it's indeed long 
and intimidating.

> The only way I found to do ZCML sanely was to copy an existing
> product's ZCML and modify it - this is nuts.

I've had some horrifying experiences at Zope 3 development sprints while 
trying to do something new with Zope 3. I haven't had this in actual 
application development, and my experiences with Five. Adding a new page 
to an existing object, say, is not very complicated, and just one ZCML 
statement.

I'm trying to say two things:

* ZCML is imperfect, I agree. There are learning curve issues and 
sometimes it just gets hairy, though I suspect the hairiness is more 
about glueing up too many components which are spread out too much and 
are factored out too much...

* I don't think ZCML, and the concept of ZCML as a domain specific 
language for glueing things together, are fundamentally wrong.

>>In the mean time, in the world of HTML templating, we see a lot more
>>agreement that sometimes a domain specific language is useful. People
>>generally don't want to be producing all their HTML from Python
>>functions. I've seen far less complaints about ZPT being cumbersome and
>>buggy.
> 
> That's because when you make a mistake in ZPT, it's nearly always 
> extremely obvious what the problem is. 

That is not completely my experience. I've had my share of long 
incomprehensible tracebacks going into the bowels of the ZPT engine. I 
think in part people feel more comfortable with templating engines than 
ZCML because they're far more familiar with the former.

> This is not the case with ZCML -
> well, unless this has changed dramatically since about the middle of
> last year.

I'm not sure when the ZCML rewrite landed, I think earlier than mid-last 
year though.

>>That's not say ZCML as it stands doesn't have some didactic/learning
>>curve issues. But to reject this out of hand just like that is a bit too
>>easy, I think.
>  
> Attempting to debug some random ZCML error was what drove me 
> screaming away from Zope3 last year (having done a fair amount of
> work on and with it). I was spending far more time on debugging the 
> "simple" task of configuration and hooking things together than I was 
> on _actually_ _writing_ _code_. Screw that for a game of soldiers. 

Could you give me more details of what was going wrong that cost you so 
much time? Were you registering views and adapters for a simple web app, 
or doing something more complicated? I for one know that creating local 
services was an utter hell in Zope 3, but that's all gone now.

> I _like_ a lot of the stuff in Zope3. But ZCML was just too awful for
> me to continue working with it. It was too much like just changing 
> stuff randomly and hitting it with a stick for my liking 

This isn't my experience with ZCML when building a concrete application; 
I've been involved in a few Zope 2 applications that use Five by now, 
and it's mostly view registrations with a few edit forms thrown in here 
and there, and 1.5 adapters.

I'd therefore really like to hear more about what you were doing and 
where this sense of frustration came from.

> - there were 
> far too many different XML tags with non-obvious names and what 
> felt like a pile of dead chickens required to get it right.

Okay, that's a complaint about the design of the language, and I agree 
that ZCML is far from optimal. I feel the tags are okay, but the amount 
of combinations of *attributes* to those tags sometimes get pretty 
ridiculous. Someone with a feel for language design could write a 
frontend on top of this that experiments with different ways of 
expressing the same thing.

I don't think ZCML requires a lot of repeating of what you already said 
in the code, though.

Another alternative I've been thinking about a bit since this discussion 
started here is to see how far you can push Python to get at least 
simple views going outside of ZCML, without losing the flexibility of 
being able to add a view to someone else's code witout changing it. I 
haven't gotten very far with this yet.

Regards,

Martijn