Zope Explained

Note: this was originally written by Dave Parker on the Northeast Wisconsin Linux User Group mailing list. I've posted it with permission from him. - .djc.

I want to explain better what Zope is - it really is a *very* different

way of thinking about web programming and web publishing. The trick

with zope is understanding just what it's all about in the first place.

I think it's going to still come off kind of abstract, but I'll try to

give some concrete examples and drive it down to the real world

eventually.

My first thought was "oh, a web based publishing environment with

database ties - interesting". But that's really giving it a seriously

short shrift.

Zope is much more like a Smalltalk

(pure OO) environment that is tightly

bound (inextricably wedded) to the web (http), complete with all the OOP

essentials: encapsulation, inheritance, and polymorphism. All of the

native objects live in a multi-threaded, multi-user object database.

The object database is *not* a relational database backend - it's a real

object database with oids and optimistic locking and all that. Zope

also has facilities called "database adapters" which allow you to

exploit an elegant (nearly transparent) object to relational mapping

mechanism.

Within all that is an authentication/authorization system. Users have

roles. All non-user objects in the system have permissions, which map

to roles (which are infinitely definable). Permission to role mappings

can selectively be inherited from parent objects or defined at the level

of any given object regardless of parent mappings. So the granularity

of authorization is extremely fine (if you want it to be).

The authentication system by default relies on user objects that are

defined in the object database. But since the authentication system is

a component like anything else, it's possible to install alternative

systems that authenticate off of other sources, like relational

databases or flatfiles or LDAP servers or IMAP servers. Depending on

the capabilities of the authentication backend, you can actually have as

much flexibility with them as you can with the native system (roles

etc). LDAP would allow this for example.

The eventual goal of all that is to let you create dynamic (and static)

web content.

"Publishing" in the zope environment is 100% web based - you will

**NEVER** be at a command prompt - all interaction with Zope occurs

through http or ftp (primarily http).

The most basic type of publishing is the familiar "create content with

your local HTML WYSIWYG editor and publish with http PUT or ftp" thing.

From the perspective of http PUT and ftp, Zope's object environment

appears to be a filesystem of the ordinary sort, and your content shows

up as expected.

When you publish to zope in this way, you take advantage of the two most

basic types of "products" (roughly "classes", but they're more involved

than that): "Folders" and "DTML Documents". These will be generated for

you automatically.

If you choose to work directly with Zope via it's web interface, you'll

work more directly with "products" and you'll have a much wider variety

of them at your disposal (plus you can create new ones, package them up,

and distribute them).

The key to dynamic publishing in Zope is it's "DTML" language. DTML is

a superset of html that ties tightly with the object database and the

O-R mapping mechanism. The genius of it lies in it's layering of

namespaces as relates to your current context - and the fact that all of

*that* maps to http (read: URLS) automatically.

PHP is just a scripting language - really leagues away from what Zope is

(PHP is closer to Perl w/extensions than it is to Zope).

To really figure it out, you have to work with it. If people are really

interested we can do a demo (I'd be glad to do it). Otherwise, get an

account at http://www.zope.org or set one up yourself and play with it.

The more you use it, the more you find.