[ZDP] Next Part...

[Tom Deprez]

Ok, I keep writing, I hope you all keep reading and correcting it...

Maartijn, I've incorporated your text. If you don't like this, just say so.

Pavlos, I've also incorporated your excellent explenation. If you don't
want this, just say. Please, report miswritings.

So what we have right now, is :

Zope World
 CHAPTER I
 1 Introduction
 2 A Web Application Platform
 3 Zope as a web application platform
    Scripting Languages
    Object Oriented Scripting Languages
    Growing to a Web Application Platform
 4 Looking at Zope
 5 First impression

 CHAPTER 2
 1 Release the Power of Zope
 2 Zen of Object Publishing
    Zen of Acquisition
    Zen of Objects
 3 Architecture
    Zope publishing
 4 The Different Layers
    Zope Publisher
    Zope Object Request Broker
    Zope Object Database
 
------------------------------- Hope you like it

One part : 

A Web Application Platform

To have a better understanding of the way Zope is, you need to know some
basic things about the evolution of the web and it's web applications.

 ------------------ Maartijn Faassen (see prev. mails) -----------------
....
importantly, a web server application platform should be powerful and
flexible -- many types of web applications are possible, after all.

Zope as a web application platform

Scripting Languages

Here we are, but this isn't everything. In one of the evolution stages in
the web, people started to use programs for creating their web pages on the
fly. We only talked about Perl in the previous section. But Perl isn't the
only programming language somebody can use. Almost every programming
language (i.e. C, C++, VB, Delphi, Java,...) can be used for programming
CGI applications. However, Perl is one of the most frequently used ones,
because of it platform idependency. This, because, like previously said,
Perl is a scripting language. That's also why we speak of a Perl script,
instead of a Perl program. The perl script can run on every platform, it is
the interpreter of Perl which is platform dependend. So a Perl script can
be executed on every PC platform if an interpreter exists for that
platform. This makes an terpreted language very attractive, because it has
to be only written once and can be used on many platforms. The interpreter
however has to be written for every platform, but this can be done by a
small group of people and only once per platform.
But, you should also remember (from the previous section) that Perl,
besides it's very powerfull, it isn't a very clear langauge and certainly
not for a beginner. Knowing that, other 'scripting' languages appeared on
the horizon. One of them is Python. 

Object Oriented Scripting Languages

Python was created long after Perl. This was certainly a benefit, because
there is a certain evolution in programming too. You could say that Perl is
written with the knowledge of programming in the early beginnings, while
Python has the structure of a programming language of today. Python is a an
object oriented (OO), scripting language. In OO, programmers create
Objects. Objects contain data and methods, which are needed to handle the
data of the objects. All Objects have a place in a hierachy. An object
always has a parent, except the special cases offcourse, i.e. the one on
top of the hierarchy. They can have brothers and childs. E.g. We create a
object 'fruit', which contains data special to fruit. Then we make a new
object, which is a child of 'fruit'. We call it 'apple' and it will contain
data specific to the fruit 'apple'. Another child of 'fruit' could be
'pear' which contains data specific only to the fruit 'pear'. Because of
the fact that 'apple' and 'pear' are childs of 'fruit', they also have the
data specified in 'fruit'. Schematic this results in :

					Fruit
                                !
                         ----------------
                       apple           pear

Thus, OO programming languages have a syntax which enforces readability, so
its code is always easy to understand and modify. This is certainly a
benefit over Perl, and makes life easier for programmers and certainly for
beginners. But, after all, programmers, still have to provide the
interfaces for HTTP and other Web Protocols. Which makes it still hard to
create safe and good code.

Growing to a Web Application Platform

A great start is to make it managable, keeping everything together. So it
would be handy to have a database keeping all the python objects together.
It is obvious that you would use an object database to store all these
objects. Here we see the first realisation of Zope. That is, Zope has an
object database to store all the objects. The database is simply called the
Z Object Database. So, at this point, we've on one end a container full of
python objects, organised in a hierarchy, that have publishable methods.
Publishable methods of an object are methods which can be called by another
object, so that the called object is possible of showing (publishing) it's
contents in a certain way. On the other end we have a way of viewing the
data. The desire is to provide network access to these objects and their
methods, so we need a protocol that is flexible enough to pass around a
request string and a number of arguments. The HTTP protocol provides enough
flexibility and is a widespread protocol. For instance, a published method
of the object 'apple' could wrap it's contents in HTML and show it through
a webbrowser. This can be achieved with a program between your web server
and your object database. This program will handle the translation from
HTTP request to object traversals. Besides this, it should take care of
several common tasks which are a burdon to programmers. Like, automatically
including of HTML tags when needed etc. Zope has such a program (or module)
and it's called the ZPublisher.
However, seeing the revolution of the net, having the possibility to
distribute objects isn't the only thing you need for a dynamic web site.
Because that is what we've now, with a web server and the ZPublisher you
can build a complete distributed objects application. In dynamic web sites,
people also need the ability to send data to the server. So, how can we
pass the URL, cookies and parameters to the ZPublisher so it can do its
job? Well, wasn't CGI created for this? A cgi enable web server will pass
all the relevant information (and even more) to the requested cgi script,
which is exactly what ZPublisher requires. Therefor, you can publish
objects with any web server that supports cgi. Reading all this, you should
understand why Zope is called to be a Web Application Platform.

[Picture : HTTP request -> Web Server (cgi enabled) -> ZPublisher -> ZODB]

Do know however that cgi is very inefficient. Every request has to restart
python, load the relevant libraries, read and execute the code and provide
the responce. Just the same as with Perl scripts and the like. However,
several alternatives exist to make it more efficient. Somebody created a
Persistant CGI (PCGI), which essentially starts a python process and keeps
it alive so that new requests can be served very fast. Higher performances
are possible, if ZPublisher can include a handler directly in the web
sever. With the handler, HTTP request can be 'intercepted' and 'redirected'
to the ZPublisher. Examples of such Web Servers is Medusa and
ZopeHTTPServer. On the following picture, you can see the possible setups
of Zope. 

[Picture 1 : HTTP request -> Web Server (cgi enabled) -> ZPublisher -> ZODB ]
[Picture 2 : HTTP request -> Web Server (cgi enabled) -> PCGI -> ZPublisher
-> ZODB]
[Picture 3 : HTTP request -> Medusa (cgi enabled) -> Handler -> ZPublisher
-> ZODB]

Picture 1 : An cgi enabled WebServer (Apache, Medusa/ZopeHTTPServer)
connected through CGI with ZPublisher
Picture 2: An cgi enabled WebServer (Apache, Medusa/ZopeHTTPServer)
connected through PCGI with ZPublisher
Picture 3: A cgi enabled Medusa/ZopeHTTPServer directly connected by means
of a handler with ZPublisher

------------------------------------------------------------------

Other part :

Architecture

[PICTURE: FULL PICTURE.. don't know how to draw it yet]

Zope publishing

When a request comes into the HTTP server it is passed to the Zope
Publisher. The Zope Publisher in turn passes the request to the Zope Object
Request Broker. The ZORB breaks the request into several parts and finds
from this information the exact Object to publish, which may be in the
requested location, or acquired from above. The Object then is asked to
publish itself. It does this by returning a template which is  passed back
up to the Zope Publisher, throught the ZORB. The Publisher
renders the template, calling the ZORB to render variables or make calls to
other objects, using the original environment of the object. This final
information is returned to the HTTP server.

Please, remark that however we only speak of a HTTP server and its HTTP
Protocol, we're not totally correct to do so. Because, thanks to the
layered approach, i.e. dividing the publishing process into a number of
discrete steps, the system is easily adjusted or upgraded to new protocols.
Changing one layer doesn't affect the others and vice versa, because they
aren't interwoven. We've only talked about HTTP, because this is the first
and most expanded protocol in Zope for the moment. The FTP protocol is
recently added, as WebDav. These three situations are shown in the next
figure :

[Picture 1 : HTTP request -> Medusa (cgi enabled) -> Handler -> ZPublisher
-> ZODB]
[Picture 2 : FTP request -> Medusa -> ZPublisher -> ZODB]
[Picture 3 : WebDav request -> Medusa -> ZPublisher -> ZODB]

[FIXME!!! : With FTP & WebDav, also a handler for Medusa? Is it possible to
use another FTP Server with ZPublisher]

The Different Layers

Zope Publisher

Z Publisher is the layer that communicates to the external environment,
which is usually a web server, but may be any properly designed program,
or example, ZClient is a program which permits Z Publisher access to be
easily scripted without needing an active web server or HTTP calls.
There exists several protocols which can be used in conjunction with your
choosen web server. Among others, Zope an be accessed through CGI, PCGI,
FastCGI, Netscape's Web Application Interface (WAI), COM, Medusa (which
provides HTTP, WebDAV, and FTP), and the included ZopeHTTPServer.
Zope can even listen to different protocols simultaneously, into the same
object system. Zope is moving towards ZODB3, which will provide
concurrency, and allow truly multi-threaded access to the object database.

The Z Publisher itself contains several modules. One of these modules is
the Zope Object Request Broker. Because Z ORB is the mostly used module of
Z Publisher, most of the time, people use these two terms in one sentence.
So sometimes when speaking of Z Publisher, people mean the ZORB and vica
versa. 

Zope Object Request Broker

For easy understanding, we do keep these two terms apart. However, keep in
mind that the Z ORB is a module, inside the Z Publisher. And thus, this
alinea should normally be place inside the the previous one.

Like all ORB's, the Z ORB breaks a request in several pieces. You can say
that an ORB analyses a request. The translation of a request is done by
walking down the object hierarchy, finishing into a method call of a
certain object.

You can think of Zope as a tree with objects as it branches. A web server
can't communicate directly to this 'hierarchy', because it works with
URL's. One of the tasks of Z ORB is to convert the URL's to the
object/sub-object traversal and vica versa. Thus, it delivers a plain
HTML-page to the web server and translates the request received by the web
brower. Other tasks are: marshalling of form data, cookie data and HTTP
file upload data, as well as automating exception handling, generating CGI
headers and performing authentication and authorization.

Zope Object Database

The Z ODB is used for storing all the Zope applications and web sites. The
database is build in such a way that it looks and feels like a filesystem
to end users. So, every object you create is stored in the Z ODB. This way
an object can look into the hierarchy of the Z ODB to determine it's context.

[More text: .. who can help me with this one?]

.... pfft. Please let me know what you think about it. And offcourse the
multiple corrections :-).

Tom.