[ZWeb] Why to use the ZDP-Tools on Zope.org

[ethan mindlace fremen]

I'm interested in this...

-------- Original Message --------
From: Maik Roeder <roeder@berg.net>
Subject: Why to use the ZDP-Tools on Zope.org
To: ethan mindlace fremen <mindlace@digicool.com>

In this small paper I will discuss why I think the ZDP-Tools are the
right choice of product to be used for content management on the
Zope.org
site. Although the ZDP-Tools are considered a prototype, they have a
proven track record of running zdp.zope.org for 8 months, and have been
extended in many ways. This has been extraordinarily easy because they
make
use of the Model/View/Controller paradigm.

1. DocumentFolder

The DocumentFolderClass defines all the templates that surround the
content. All other ZClasses in the ZDP-Tools are derived from this
ZClass, and thus they all share the same templates.

The content is:

name            the title of the document
nickname        a shorter title to be used in the breadcrumbs
abstract        a short description of the content
content         the main content

The templates that make use of the content:

Template        displays the surrounding table calls the other templates
breadcrumbs     display the path down the site tree, using the short
nickname
Header          dispays the long name of the document
Main_Abstract   displays the abstract
Main_Content    displays the content

2. Content can contain Content - CccC

The DocumentFolderClass is a Folderish ZClass. The idea of this is that
you can always have documents that contain documents that contain
documents ...

This is a simple but generic Content Management Framework, because you
are
always free to add whatever kind of content you want to anything that is
already there.

3. Hierarchy

When you have a hierarchy of documents, every single document has a
parent
which it belongs to, and this parent again has a document that it
belongs
to ... This is reflected in the breadcrumbs, which show you the way back
out of the wood :-) No more lost in hyperspace.

4. Model View Controller

We need an example to see how the ZDP-Tools are working. Let's assume we
want to add a Job Board to the ZDP-Tools. This is easy if you stick to
the Model View Controller paradigm.

Let's day you would add two ZClasses derived from DocumentFolder to
the ZDP-Tools:

JobFolderClass
JobClass

These ZClasses are easily created in a few minutes, and the nice thing
is
that you almost need no new templates, because it is all in the
DocumentFolderClass. In terms of Model View Controller, it would be like
this:

Model: JobClass
Controller: JobFolderClass
View: Parts of it in the JobClass, and parts of it in JobFolderClass,
and
      parts of it in DocumentFolder.

The JobFolderClass is responsible for the JobClasses. It has the
necessary
links for adding JobClasses and is also responsible for listing them.
There
is a generic list method, but it only takes a few lines of code to list
the JobClasses inside differently.

The JobClass itself is really just a dumb ZClass that does not know what
to do with itself. Perhaps you would like to change the look of the Jobs
a little bit, so you override a template or two, but nothing much has
to be done for this ZClass, really.

The View depends on from where you look :-) Well, if you look at the
JobFolderClass, it will list the contained JobClasses.  If you look at
the
JobClass, it will display only itself.

5. Why use the ZDP-Tools for Zope.org ?

- it can be completely managed through the web
- a design decision was to use no Python code because this is not
  what Paul Everitt calls "managed content"
- it can be easily extended (as shown above)
- it is a generic content management framework
- model view controller from the ground up
- it has been used extensively as a prototype for 8 months on
zdp.zope.org
- it is easy to bring the ZDP content to Zope.org

6. Some notes

If you find that the ZDP-Tools don't fit your style, please consider
stealing the following ;-) :

- Create a ZClass like DocumentFolderClass for the Templates
- Make DocumentFolderClass Folderish
- Derive all your ZClasses from DocumentFolderClass
- Stick to the Model Viel Controller Paradigm as described above
- Make no restrictions on what can be contained in what - you never know
  when this can become handy !
- Let the Controller list the Model
- Let the Model become a Controller if it contains Models on its own
- Let all DocumentFolderClasses have an abstract next to the main
content
- Use one property for the main name of each kind of document - name

7. Some things I would do different now:

- Don't rely on bobobase_modification_time for your creation date
- Add a "created_date" field to DocumentFolderClass
- Add a "last_changed_date" field to DocumentFolderClass
- Add a content_type_abstract property
- Add a content_type_content property
- rename "name" to "title"
- rename "nickname" to "shorttitle"


-- 
Uzopia - Digging la vida Zopa - http://uzopia.editthispage.com