[Pydotorg-redesign] The Zope question

[Dylan Reinhardt]

Ugh... I meant to send this to where it *really* belongs, pydotorg, not
pydotorg-redesign.

Sorry for the bother.

Dylan


On Fri, 2003-08-08 at 13:22, Dylan Reinhardt wrote:
> 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
> 
> 
> _______________________________________________
> Pydotorg-redesign mailing list
> Pydotorg-redesign at python.org
> http://mail.python.org/mailman/listinfo/pydotorg-redesign