[Zope] Usability of Zope (Was: DTML Syntax contd. + rant)

[Anthony Baxter]

[Paul violates his own 'please move stuff to zope-dev' post, so I'm going
to do so, too :) ]

>>> Paul Everitt wrote
> Zope's usability needs to improve a LOT.  I got a good dose of this when
> I taught a three day Zope course several months back.  When you have to
> explain it to people, you really find out how baroque Zope can be.

The major problem I, and the people where I work, have is not just that
DTML's syntax is, ahem, 'distinctive', but that when you have a problem,
you really don't get enough to help you solve it. Often trying to fix a
problem involves just randomly trying permutations of the DTML that you
want, until you hit the magic combination. I've almost given up entirely
on ZClass programming (for anything but the simplest tasks) in favour of
Python Products for this reason - when my python is defective, I can find
out very quickly and very easily _why_. Inside a ZClass, there's no real
way to figure out what the heck is going on.

This isn't just a matter of not being familiar with DTML - I've been 
smacking my head against it since Principia days. That I haven't just
given up entirely is testament to the other parts of Zope (the good 
stuff) - no matter how clunky DTML gets when you start trying to do  
the logic of your site in it, the rest of Zope is good enough to make
up for it.

> Though I agree with Andrew that the problem isn't just DTML, that seems
> to be a locus.  DTML *is* being used in a way that violates its design
> (separation of presentation and logic).  But at the same time we at DC
> lead the way on this violation, and aren't actively promoting viable
> alternatives.

Python Methods are a promising approach, and one I'd like to see more
work on - they allow the convenience of coding Python, without having 
to restart each time. I'm not _entirely_ sure about the security of them,
but then, I'm prepared to take the tradeoff - the people who are working
on the sites I work on all have logins to the box anyway (and if I need
to give access to people I don't trust, then they don't get to work with
the PMs).

> I'll say this about an ngDTML effort: good luck.  The current quandry
> exists for a reason: there are a lot of tough design choices.  That
> which is clear to the Python hacker is obtuse to the HTML newbie.  That
> which is clear to the DTML developer is inefficient to the
> parser/renderer.  That which is...

I don't know that a different DTML will solve the problem - if anything,
I'd guess it would make it worse, since the temptation to throw every
other feature in would be strong.

-- 
Anthony Baxter     <anthony@interlink.com.au>   
It's never too late to have a happy childhood.