[Pydotorg-redesign] The Zope question

[Dylan Reinhardt]

Hi all,

Over on the Marketing Python list, we've had several threads around marketing strategy that have intersected with issues of concern to this group.  Several requests have been made to move this discussion over here.

One thread in particular that seems to belong here is the Zope question.

As a strategic issue, there may be significant value in showcasing Zope.  I believe there are also strong arguments to make from a usefulness and manageability standpoint.

So here's a post in which I took up the question posted to the other list: why use Zope?

>From here, I'll try to keep my web-related advocacy over here where it belongs.  :-)

Dylan


---- forwarded message follows ----

On Fri, 2003-08-08 at 09:43, Skip Montanaro wrote:
> Can you give some reasons why Zope (2 or 3) would be a better way to build
> python.org than the current ht2html tools?

I expect there are far more than I could think of, but I'm happy to
throw out a few.  

The core advantage of Zope is that it facilitates user participation. 
Zope (including CMF/Plone) is a very solid platform for building systems
that allow users to contribute and manage content.  

Zope makes it possible to create and manage content without touching the
filesystem.  Zope provides workflows that ensure that only
moderator/editor-approved content may be published.  Once content is
approved, it can transparently make that content available to the
systems used to search the site.

Zope's chief advantage, IMO, is that it opens the door to
user-contributed howtos, white papers, etc. while significantly
*reducing* administrator workload.   

In a system (such as our current one), content resides on the
filesystem.  Access to the filesystem is not given out willy-nilly, of
course.  Thus, the person who is responsible for maintaining the site is
pressed into service as the editor/gatekeeper for content.

In Zope, content editors/moderators don't need access to the filesystem
to perform their responsibilities.  The admin is thus freed to focus on
what *admins* do, keeping data backed up, logfiles rotated, etc.  As
roles are more narrowly defined, work becomes easier to delegate.

But wait... there's more!  Templating is trivially easy.  Search
functions actually work.  Forums are simple.  Structured, link-heavy
subsystems like the FAQ become far easier to keep up to date.  

Imagine... to add something to the FAQ, an authorized user might need
only to add an FAQ object through the web.  That FAQ object has a small
number of  properties such as an index number, a question string, an
answer string and maybe a way of selecting related questions.  Once
added (and/or approved) the new question/answer is seamlessly integrated
into the FAQ index and search function.

Roles can be as fine-grained as you wish.  If you want to establish
different levels of responsibility for contributing an FAQ vs.
contributing a howto, you can.  If you want to give specific people
editorial control, but only over a specific part of the site, that's
easy.

All that, and replication & caching are trivial.  A one-line shell
script is all it takes to take a snapshot of a Zope system and cache it
locally.  Zope is easily integrated with proxying systems like Apache or
Squid.  Content is easily changed and updated, but the end result is
only as dynamic as you choose to make it.

Moreover, Zope is easily maintained.  If Zope is installed to use the
DirectoryStorage product, the Zope database is stored as a collection of
files, each of which is basically a pickle of an object in the
database.  This storage method is easy to back up incrementally and can
be copied into a CVS.

So... to summarize:
1. User contributions
2. Finer-grained roles
3. Reduction of admin workload
4. Easy replication/caching
5. It's cool as heck

I could go on and on... but hopefully that makes enough of a case to
determine whether it's worth considering in any greater detail.

Dylan