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.
Attempting to debug some random ZCML error was what drove me screaming away from Zope3 last year (having done a fair amount ofThat'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.
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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
