[WF-Infra] Infra Meeting: October

kosh at aesaeion.com kosh at aesaeion.com
Sun Oct 28 01:10:32 PST 2001

On Fri, 26 Oct 2001, Philippe Jadin wrote:

> > 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").
This is inpactical for many reasons.
1) Nothing is ever truly stable
2) In many cases there is nothing that truly meets our needs
3) Zope was designed so that the base objects where meant to be inherited
from not used directly in the creation of sites.
4) Learning to program in zope is easy since you basically just need to
learn a little python so as long as the license is open we can really
maintain anything.
> 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.
This causes some practical problems as well. Items will not get cataloged
automatically and unless they are a distince object type having zope find
all the items it needs to catalog is impractical. It also causes a problem
on search returns in that you get the document back that it found but you
would not get the folder back since it is not the document it found. This
would cause your search return form to have a fair bit of logic in it to
get back the proper items you want. It would also involve manually
selecting which items in the site to index unless you wanted every dtml
document indexed. Even after you decided which items you want indexed you
still have to run the indexer. That overall would not take too long since
zope can reindex a few hundred megs of data in a few minutes.

> 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.
This has the problem of the first area of a catalogging problem.
This also causes a problem of it you delete the item from the zope via ftp
that will not get registered in a catalog unless it is a catalogware
object so you will desync your search engine after the first deletion.
You can have zope resync it but it has to reindex to do that which could
take a few minutes to do.

> 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)
There is more to translation then that since you also need to change the
character set in many cases. You also have the situation where your render
has to be made very smart which will slow down every page view on the site
and not just the pages that actually use that additional smarts.

> Rule 3 :
> The folder has properties such as :

Folders inherit values from folders above them so you have to make sure
you set those values on every folder on the site otherwise you will get
values inheriting that you don't want.

> - 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.)
More folders will also make the paths more complex and it will also
increase the complexity of the queries.
> 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)
The problem with this is that simple is based on your knowledge of the
problem domains. Many simple solutions look complex and many complex ones
that have nice domino affects look simple.

> Consequences :
> --------------
<snipped for brevity>
I think the consequnces proposed are unrealistic because of the inhertent
problems with the proposed system.

> 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".
I don't see this as easy since it looks like this is setting off a very
large domino problem.

More information about the Infra mailing list