[Zope] Where is the code?

[Rik Hoekstra]

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