newbie: Zope

[Andrew Kuchling]

Geoff Talvola <gtalvola at nameconnector.com> writes:
> I too tried out Zope and found myself overwhelmed by all of the new concepts I'd
> have to learn.  I don't want to have to learn and use DTML.  I don't want to
> store everything in an object database -- I want to use a regular source control
> system.  I don't want to have to figure out ZClasses, Products, Versions, etc.
> I don't need through-the-web administration.  I just want a nice way to write a
> web application as a Python application.  Zope is a _very_ ambitious system, and

Yes, this is pretty much what we've found; we wrote Quixote for our
own purposes instead of using WebWare, but the principle is much the
same.  Zope works really well if you have a bunch of simple things --
objects that are mostly bags of attributes, rows of data from a SQL
database, pieces of text -- and can glue them together with DTML.  For
example, Squishdot is well suited to Zope, because an article or a
follow-up isn't that complicated an object, so you can implement it, a
bit painfully but not too bad, and then use DTML to combine objects
flexibly.

We're not in that problem domain; we have *complicated* objects glued
together in complicated ways.  For example, Greg Ward has drawn a
state diagram for one object (process runs).  It has 5 major states,
each of which occupies a page with a dozen or so substates.
Implementing this as a Zope product, or even a ZClass, would drive you
made because you're cut off from the skills and tools available to
regular Python: you don't have CVS, you can't grep through files, you
can't easily write a test suite for the object, and DTML is unsuitable
for complex code.  (PythonMethods would alleviate the latter issue,
but I don't want to edit Python code in a Netscape text area.)

Worse, features exact a cost whether you need them or not; the
through-the-web editing means code has to live in an object database,
and a complicated security model is required to manage it.  Object
traversal is complicated since objects can affect how they're
traversed.  DTML is handy, but complicated applications become really
messy since you don't have very good mechanisms for calling other
methods.

The shock of recognition came when I was sitting on the bus reading
the RFC for NFS, aiming to write an NFS server on top of a ZODB so we
could use grep and CVS.  Suddenly I sat up and thought "What am I
doing?  I have an object database on top of a filesystem, and now I'm
emulating a filesystem on top of it?  Why not just use a filesystem in
the first place?"  And so we started designing and implementing
Quixote, so named because writing Yet Another web devel. environment
is certainly tilting at a windmill, and using the ZODB to store
objects.  (And the ZODB works well so far; my hidden agenda is to
encourage more people to use the ZODB, as we do, so that there are
more users of it and more tools written for it.  Even if Zope itself
isn't applicable to a given task, the ZODB might well be.)

--amk