newbie: Zope

[Cary O'Brien]

In article <3d3djk6jz2.fsf at kronos.cnri.reston.va.us>,
Andrew Kuchling  <akuchlin at mems-exchange.org> wrote:
>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.)
>

Hmm...  What's wrong with external methods for this stuff?  My
understanding (from reading the zope mailing list for a while) was
that SOP was to implement things with external methods when things
got too hairy for DTML/ZClasses, and to store data in an RDBMS when
the system had lots of writes.  External methods live in text files,
so you have CVS and grep, plus you can have a non-zope test suite that
is as complex as you want.  I just put the old if __name__ == '__main__'
thing at the end of the file, but you can get as complex as you
want.

Zope is complex, though.  Two software packages have actually
intimidated me with their power and complexity and subtlety,
zope and yorick.

>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

This is indeed a good point.

-- cary

>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









xx






xx





sorry.  Newsposter is strict.