MoinMoin vs ZWiki

[Peter Hansen]

Ng Pheng Siong wrote:
> 
> According to Peter Hansen  <peter at engcorp.com>:
> > [...] Zope's relatively weak documentation and
> > architectural flaws and shove that in your face.
>   ^^^^^^^^^^^^^^^^^^^
> Would you mind elaborating?

Sure!  (I'll first spin a little and say I may not have chosen the best
wording as I was in a hurry, just got out of bed, and hadn't eaten yet. 
Or some other excuse.  "Architectual flaw" might not be quite what I
meant, but let's see what I did mean...)

Actually, I am one of Zope's biggest fans.  Don't get me wrong: it's a
wonderful creation with *enormous* potential and we're making it the
centre-piece of our development environment for several purposes and
reasons (ZWikis being but one).  Even with the warts I see, it stands
head and shoulders above any alternative that exists.

That said, Zope does have a tremendous learning curve.  I pride myself
on being a very fast learner, and have proven it (to my own
satisfaction, anyway ;-) many times in the past with new technologies. 
Zope, I have to say, has made me feel *really* slow.  It's partly the
documentation, but I believe the design is weak in some ways.  With a
self-consistent design, I can typically figure out how to get something
working well even *without* resorting to documentation.  I haven't been
able to do that with Zope.

The 30,000 foot view is good: modular, object-oriented, reliable,
robust, good performance, scalable, other buzzwords as desired.  That's
actually all that matters in the long run, as the rest can be fixed.

At about 5,000 feet (just under a mile, for other non-Americans :-),
things get a little shaky.  

There's DTML.  DTML is a curious blend of HTML-like markup with
programming language abilities and some DTML-unique characteristics:
Python code mixed in but very restricted in what it can do, oddities
like the "under namespace" with "_.this()" and "_['that']", mysterious
uses of this() and REQUEST and things like <dtml-var xxxx> or <dtml-var
"xxxx"> or <dtml-var expr="xxxx"> with overly brief explanations of what
it all does, how to use it, what not to do, and so on.  Very little of
this looks much like Python and Python is to me one of the biggest
strengths of Zope.

To use Python, you have to get into "External Methods" and/or Python
Products.  The only real way to learn to use these is examples, and by
poring through the source code to Zope.  Examples are an excellent way
to learn; looking at your application's source should not be necessary. 
In my case, the examples only went so far, because as soon as I wanted
to do something for which I had no good example I was stumped again. 
There are good support groups for this, however, here and in the Zope
mailing list.  Historically, I've never had to depend on such things, so
again Zope defeated me a little here.

There are other problems in various areas, especially (for me) in terms
of security configuration.  The default installation (without add-in
products) has minimal support for user ids, with no proper interface for
users to change passwords, no obvious way to create such an interface
cleanly, no centralized store of user information (you have to create
separate user folders in different directories for certain types of
installation, and that means maintaining redundant user information in
various places, increasing the security risk), and as near as I can tell
a security system that is powerful but complex enough to make it  more
likely that somebody will misconfigure it than that they will set it up
properly.

I could mention a few other areas, no doubt, but that would be really
unfair, and I could probably list even *more* areas where Zope is just
the cat's pajamas (pyjamas for non-Americans).  

In fact, just posting this makes me feel I should emphasize once again
just how much I *like* Zope.  I've become dependent on it in several
ways into my work and life and, as I've said before, I *can* remember
what life was like before Zope (and Python!) and it wasn't very pretty. 
(In the area of software engineering, that is, since life outside of
computers was actually just fine.  I *do* have a life.  No, really. 
Well, I did once.  :-)

In the end, I see strong evidence that Zope will only improve
significantly in the future, and that it could well live up to all its
potential.  It will take a *lot* of work on DC's part, and I wish them
the best of luck and success in their efforts.  The $12 million should
help.  The fact that the Dirty Dozen (or whatever the headcount in
Guido's Gang is these days :-) has come on board spells nothing but Good
Things for Zope, Python, me, the world, and of course Digital
Creations.  Have I gotten the point across: Zope is a good thing, just
not yet a fully polished "digital creation"... but it is "digicool".

Cheers,
Peter Hansen