> Zope being Python (and python making my aestheticle hurt) I haven't
> looked much at Zope. (it's funny how the unappealing look of the code
> has made me stay away from Python.  

I'll admit that the notion of whitespace being significant -- an extra
tab breaks your script -- is weird!

> could you sum up Zope in a few lines?  exactly what does it do?

I see it as an industrial-strength version of my dhttp idea. That is,
for starters, it's a 100% scripted long-running HTTP daemon, which
maps HTTP requests directly into scripted method calls. Then, it's an
ASP/JSP/ColdFusion-style template processor, where the template tag
language is augmented by native method calls in the same script
language (Python), and this is pretty quick because the engine itself
is the aforementioned long-running Python daemon. The tag language
also interpolates SQL calls and results very much as in
ASP/JSP/ColdFusion. Then, it's an object database whose structure maps
to your site's structure, and which is also a persistent
representation of a Python-ish class hierarchy. This makes it great
for "factoring" the functionality of a site. Then, it's a vehicle for
the deployment of packaged "products" that plug into this architecture
-- for example, there's a slashdot-alike called SquishDot which you
install, very simply and cleanly, into Zope to add a slashdot-like
component to a Zope site. Then it's a GUI admin interface on top of
all this, so the site is fully Web-managed, and this includes advanced
features like "sessions" in which you can explore alternate paths of
development, which you can then commit or roll back. Finally, since
the whole thing is Web-driven, it is automatically scriptable from the
outside -- a huge point in its favor in my book.

I ported my wife's simple site to Zope, just to get the feel for it,
and it was pretty easy to do. I came up with a nice Zopish solution to
a navigational widget that I use on the site. My biggest concern is
that you have to dump everything into its object database --
templates, images, etc. I see the value of a consistent
object-database model, but it would make me nervous to do that with,
say, the 15,000 files I used to dynamically generate for byte.com but
statically serve out of a file system. (Not to mention the impedance
of doing a bunch of editing in HTML <textarea> widgets, though in
principle Zope's WebDAV support will alleviate that problem.) I've
explored the idea of keeping node placeholders in Zope's db, to enable
its object magic, while sourcing content from the filesystem. This
wouldn't be ideal, though, you'd lose a lot of the clean manageability
of Zope. Ultimately to use it, I think you have to buy all the way in
to the object database, and trust it, and see what happens. 

-- 
Jon Udell | http://udell.roninhouse.com/ | 603-355-8980