Red Pineseed wrote:

Thanks Rik,

You answered my question perfectly. This was my guess and found the Data.fs. This makes me wonder though how the implementation of the three tier separation, ie data/logic/presentation is achieved. Do you have any idea?

Yes I do. The key point is that in Zope everything _is_ content, DC says. I fact I think it is more proper to say that in Zope everything is an object. But there are several kinds of objects, as they 'specialize' in something, so to say. This is to say that objects have behaviour and this behaviour is of a certain type. That's why you can tier up your application in three tiers, or even more if that's useful. An example may clarify this. Say we have a simple application that presents the users with data retrieved from a relational database. It has a navigation bar of a breadcrumbs style (like home > mypages > myapp) and there is a stylesheet attached to it. In schematic form a page from the app looks like this: * Header * Breadcrumbs * data from a database * footer in Zope you could make the following objects that represent different parts of the application 1. stylesheet object (containing stylesheet) 2. breadcrumbs object (depends on context) 3. header object (consists of HTTP header including stylesheet and breadcrumbs) 4. database adapter (managing the connection to your relational database) 5. ZSQL Method (a querying object) 6. Queryform (for inputting query values optional) 7. Report object (formatting retrieved data) 8. footer (to close the page. Might also the breadcrumbs)

What is the advantage of putting everything in a db?

The db is the object repository. It would be hard to have persistent object without repository ;-)

Apparently if the db down, we will lose everything and recovering from a db is pain as you may already know.

Um, I'm no systems administrator, so there are probably many people who can say much more sensible things about this then I can. Anyway, a few remarks. First, the zope database is quite stable and it will be difficult to break it... Recovering is mostly just done by restarting the server. Usually SQL databases will give you much more trouble in this respect. Second, if you are concerned about failover of your server using the ZEO (Zope Enterprise Option) makes it easy to make your server distributed. This is also where Zope flexibility comes in: in default you data are stored in the zope database, but there are a number of other storage possibilities, including directory storage, bsddb storage, demo storage (storing everything in RAM so that you can run Zope from CD) and recently there Oracle storage has been added, though I'm not sure if that's public or stable as yet (I don't have Oracle myself anyway) If you insist on putting files on the filesystem, there is a Zope product called LocalFS that will include local directories and serve the contents from Zope. Moreover there are strategies for hybrid solutions in which you may serve static content or large files from Apache and do the dynamic stuff from Zope.

though it is great performance improvement to load the db in RAM at run time, do you know of an other benefits?

the db as a whole won't load in RAM, objects will only be 'woken up' when they are called. Benefits... Uh, it would be hard to imagine another way of making persistent object available especially doing it the way Zope does. Reversely it would be hard to make everything an object (and thus factor out common behaviour and make reusable code) without a persistent object system. Zope as a whole makes your applications easier to build and to maintain, because of the everything is an object approach. But like I wrote above, if you insist you can put part of your files on the filesystem. Or in relational databases for that matter. so much for now Rik