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.