[WF-Infra] Infra Meeting: October

Philippe Jadin philippe at 123piano.com
Fri Oct 26 09:32:43 PDT 2001


> Any and all
> ideas on how to quickly finish this migration and produce a product that is
> at least as functional as the current "wiki" website needs to be discussed
> immediately.

So, I think it's time to introduce some ideas I got while speaking with
zzorn, mithro, and others...

It's a bit longish, but at least this way you can have a good idea on
how it may work.

Your comments welcome !


RFC : proposal for the website
------------------------------

Intro : 
-------

Here is a proposal of a technical design for the website. It's separated
in two parts: 1. the "rules" for structuring the site in zope , 2. the
"helpers" to let us edit the site painlessly.

Some idea developed here could be used with another framework than zope,
but imho we have it running, we have people with zope knowledge, so
let's try to enhance the current system.


1. The "rules" (inner workings)
--------------

Rule 0 :

Use only "stable and used products". That means, use only stable
products released on zope.org, or even better only standard zope
products. This way we are sure the products will be maintained "almost
forever" (and are "bugfree").


Rule 1 :

Each page is a zope folder (can be created by ftp, or any means
supported by zope). This folder is a container for the page content, and
for subpages if any.


Rule 2 :

In this "page", we create a "page_content" object which can be a
dtml-method or anything else if we want to (for example, a compounddoc).
It only contains the content of this particular page. You can see this
as the "pure" content, stored the way you like. 

I see 3 types of content, usefull for now (pure text, structured text,
and html). We can add more if needed. It's the whole purpose of having a
"page_content" object in each folder.

More over, translations can be handled easily by adding a
page_content_fr, page_content_de, page_content_es, etc... in the page
folder. Choosing the right content would be handled by the page
"renderer" (don't worry, this is some kind of includes : it's not rocket
science)


Rule 3 :

The folder has properties such as :

- page_sort (float): order of the folder for the navbar display (if not
provided, then the pages are sorted on id or title)

- page_hide (boolean): if set to true, this page is not shown in the
navbar

- page_title (string): the title of the page

- page_type (tokens): the type of content added. (it can be html, text,
structured text, or wathever we want to support). Additional content
types can be defined btw.

- page_description (any kind of object) : description of the page. We
also came with idea that a short descirption could be extracted for
"tool tips" : this would be the first sentence of the description.

- page_history (any tabular object) : an history of the page (editors
can add entries)

- of course additional properties can be added as needed. We should keep
as a guideline to begin the property name with page_

Currently, top level folders have additional properties that define
color schemes used in different sections of the site.

The rendere of the page would be smart enough to show the properties
only if they exists (in some cases, however, it is nice to use the zope
feature called "acquisition" that lets you see "transparently" the
properties of parents folders as if they were part of the current page)


Rule 4 :

The navigation bars are based only on the folders. The concept of page
is equal to the concept of folder. You can "convert" a page without
childs to a page with childs by adding a new folder in it. This way we
can refine "content hierarchy" at any time (for example, a page begins
to be too huge :  you split it in two by adding two or more "childrens"
within it.)



Rule 5 :

No need to settle on a particular content object, we can add more if
needed. The only thing implied is it's id : "page_content"

--> we could for example have a part of the site which override the
navigation bar using input form an sql table. It would integrate
seamlessly with the rest of the site (and without modifying any of the
methods needed to render the site, for example the navbars).


Rule 6 :

"Keep it simple, stupid" (or wathever "kiss" means)



Consequences :
--------------

With this system, as you see, there is no real differenciation of
folders and content. Any page can become a container for others pages if
needed. The navigation is easier, because we don't use the differents
concepts of folders and documents. Everything is a folder which may
contain others folders or not.

As for outside support, because we use only standard zope products, we
would have the support of the core zope developpers which is not too bad
I'd say ;-).

Right now, this can be built really easily without the need to program
any custom zope product. Using only the management interface, and some
logic to display the navbars. This would be a semi-pita to add pages, as
you'd need to add a folder and a dtml method for each page (of course
we'll add "helpers").

The content would be supported by the whole zope infrastructure, which
is a good thing. For example, we would get ftp support, xml-rpc,
versioning, multiple undo, cataloging,...

Another thing that *is* important in the long run is the fact that we
can easily add multilingual support (simply add a content object for
each translation in the same folder).



2. The helpers (for everyone interested to add content to the site)
--------------


Once this is understood we can do something to make it easy for people
to add content. We don't want to bother the users : they won't edit the
website using the plain zope interface.

We need to create custom html form(s) (and some python logic) to let
people add and edit content. What we currently found usefull, is to have
a menu on the leftnavbar of the pages with:

- Edit Page
- Add Sub-Page
- Add News
- Manage



For zope interface lovers, we can add a new "tab" when you are editing a
folder : "edit content". This "tab" would ask to convert the current
folder into a page by adding content to it (as well as title and
description).

The content editing tool is practically the same as the one needed in
the repository (technically speaking), so it will be easy to adapt it to
the new site.



Conclusion:
-----------


I see this as the "fast and easy way" to create zope applications :
first use the zope interface only, then create your own management
interface. We should release the site when the custom management system
is ready. For internals testings, we'll use the zope management
interface, while following the "rules".

To sumarize the difference with the current zope site, we are doing it
an abstraction level deeper. The concept of page is beng changed to the
concept of folder. The system is then more flexible, and can be adapted
easily. Contents types from any source can be added.


Any comments are welcome, as those are important design choices.



Philippe



Note that after I wrote that, we wanted to test a bit more the idea
(yes, without asking... Now I ask, and of course I'm open to
anything...);

It is in test at 
http://moria.mit.edu:8080/wf/new/

You'll find there the prototype and at the same time you'll see the
theory of colors applied by zzorn (see previous mail) :-)



More information about the Infra mailing list