[WF-Infra] Infra Meeting: October

Philippe Jadin philippe at 123piano.com
Sun Oct 28 13:29:07 PST 2001


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

As the title says, it's a request for proposal, so it's nice to have
other's opinions.


> > 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

If dtml-docs and zope folders are not stable, then let's not use zope at
all. It's like saying that folders and text files are not stable under
linux.

> 2) In many cases there is nothing that truly meets our needs

Agreed, but the idea was to separate the page container and it's
content, so we can put any kind of content in it, including
compounddocs. So, whenever a new type of content is released, we can use
it directly, without the need to change anything (navbars, structure,
everything is based on a hierarchy of folders). 

The site can be adapted to "suits our needs" at anytime, simply by
letting people add a new type of content when needed.

> 3) Zope was designed so that the base objects where meant to be inherited
> from not used directly in the creation of sites.

I agree for the content objects. But as for the folder object, there is
no need to create a new kind of object. A folder is just this : a
container.

> 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.

Agreed, but isn't it even smarter to be able to use *any* kind of
content type? So we base our site on folders, and then we add the
content the way we like...

> 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.

The logic we can use is to find and catalog every object called
page_content, search into them, and when we find them, link to the
container of the page (which is allways the container folder).

> 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.

I thought about using the same technic used for the repository : the
objects are cataloged each time they are edited (and yes, it works
without problem).
 
> 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.

What are a few minutes every week if the benefit is the ability to use
ftp to edit the site content? Personnally, I really prefer to use my
text editor to edit content than my browser's text area.
 
> 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.

It will not be that hard to add multilingual support :

If there is page_content_de in the current folder, add a german flag
with a link to the translation
If there is page_content_fr in the current folder, add a french flag
with a link to the translation
... (we can also automagically display the right page using a user
session)

Not really rocket science imho ;-)
 
> 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.

Using simple code that checks if a property is in the folder or in the
parents, we can "disable" acquisition if needed. Some properties are
really usefull to acquire, such as color themes. It's imho the most
interesting feature of zope. Note also that with the current site, it
works like this : every page that has no content shows the 2d media site
map. Is it really what we need?
 
> More folders will also make the paths more complex and it will also
> increase the complexity of the queries.

It's far more easier imho : instead of looking for different content
types to generate the navbars, we only look for folders.

There is anoher big advantage if we use folders : we can add childs to a
page at anytime (we simply add a page (=folder) bellow the current one)

> 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.

Maybe you are right, but imho we should allways use a simple solution
that works and that can be extended by more people than using a solution
that needs intensive coding to work.

Let me add that a proof of concept prototype site is currently working
and available at http://moria.mit.edu:8080/wf/new.
 
> <snipped for brevity>
> I think the consequnces proposed are unrealistic because of the inhertent
> problems with the proposed system.

Imho any solution has tradeoffs, we just need to find which one has less
tradeoffs. I don't think it's a bad thing to experiment a bit about
differents solution for the website. Like we have differents clients, we
may, at some time, have differents testing area. It becomes a problem
when the testing area stays a testing area and never becomes a stable
product.

Note that we got a fully working prototype using the concepts I
explained in a few days. You can already edit/add pages, anywhere, using
a wf specific interface. You can add a description, choose to hide a
page in the navigation, change the order fo the page in the navigation,
etc.

This said, we need to decide which solution to keep (without counting
Bryce's effort on Eidetic, which seems at least as much advanced as
other solutions), as it's stupid to work on different solutions when at
the end we'll only need one web site.
 
Philippe



More information about the Infra mailing list