[Zope-ZEO] Advice

[Jim Fulton]

Greg Ward wrote:
> 
> [I crudely slag Zope]
> > One of the reasons our group is moving away from Zope is that it has
> > very poor support (if any) for the development/staging/live model.  We
> > like this model.  We think it's a good thing.  But sync'ing code across
> > multiple Zope installations is a royal PITA.
> 
> [Jim steps in]
> > I'd like to hear more about the problems you've had and how
> > you overcome them in a different system.

Hm. You really haven't answered my staging question.

> Personally, my gripes with Zope boil down to one fundamental
> disagreement:
> 
>     code != data

Many OO systems try to bring code and data together into
objects.  I think this is a good thing, however, Zope
can accomidate a number of approaches.
 
> IOW, I don't think my source code -- specifically, DTML methods and
> documents, but also all the other stuff that make up a Zope web
> application -- should be put into a big opaque database. 

I'm not sure what you mean by opaque.  You can certainly get at anything
you want in a number of ways.

> Source code
> belongs in the filesystem, because stuff in the filesystem can be:
>   * version-controlled (RCS/CVS)
>   * grep'ed
>   * edited with a real editor
>   * rsync'd

But I can do all of these things, to a greater or lesser degree
with Zope.  I'll grant that there are file-system-based tools
that currently do some of these things better in some ways that
Zope does, OTOH, I would argue that the Zope ZODB approach
has it's advantages too, such as dealing with rich objects,
and transactions.  I certainly consider ZEO to be superior
to rsync.
 
(snip)
 
> > > And no, versions are *not* the answer.
> >
> > Well, they are a pretty good answer for lots of applications
> > in my experience.
> 
> I suspect Zope is very good at content management, which I understand is
> what it was designed for in the first place.  Zope's model is that
> content (data) is king, and logic (code) is ancillary and not very
> important.  (If you can't version control it or grep it, how important
> can it be?)

But we do both of these.

>  The model that makes sense for application development is
> that code is king, and it exists to present a web interface to a
> database.
> 
> In my experience, Zope is not very good at application development,
> because it doesn't let you do the natural things programmers like to do
> with source code. 

I disagree, OTOH, I certainly acknowledge that file-system-based
tools are more mature. Of course, you can do *all* of your Zope
development on the file system if you wish.

> (Also, DTML is a pain in the neck, but that's a minor
> problem compared to the fact that it's locked away out of the reach of
> grep/emacs/rsync/cvs/etc.)

DTML, when used as a template language, does a good job at 
separating HTML generation from the rest of the application.
There are newer ideas that I expect will replace DTML, but I
still think it solves an important problem.

Zope lets you search DTML pages in a grepish manner. Zope's
FTP support lets you edit DTML stored in Zope using an FTP-aware
editor, like emacs. ZEO lets you replicate your application
pretty transparently and in a transactionally consistent manner.
The new history feature in Zope lets you view and compare different
versions of DTML (and in the future, other kinds of source) pages.

Of course, if you want to build Zope applications entirely on the
file system, you can do that too. A common pattern is to develop
some of an application on the file system and some through the web.
 
Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.