Here's my take on an answer to the fundamental question, "What is Zope?"

What is Zope, and What Does It Do?

Theme - Bridging Computer Media

Zope's purpose in life is to make it as easy as possible (and no easier) to hook computer applications / databases to the network, particularly the web, with as much integration and as little waste of user efforts as we can muster.

There's a concept in electronics which captures the essence of Zope's approach: impedence matching.

"Impedence Matching" - Maximizing Energy Transfer

In electronics, impedence matching is about maximizing the transfer of power between two circuits. It's common for the connection between the circuits to represent a transition between media - an antenna taking signals from space transferring to electrical signals in an amplifier, back to air signals in a loudspeaker.

Like those circuits, you can look at Zope as a kind of bridge, between the network and applications you implement or connect to with Zope - and also as a bridge between layers of an application you're implementing.

(Note that computer languages and APIs could be seen as impedence-matching devices, in this light. Computer languages bridge from textual or graphical controls suited for use by people, to machine code for the computer. APIs constitute collections of routines also tailored for people's use, in programs, bridging to the computer functionality suited to a particular application domain. You can look at many of Zope's components as being like languages and APIs.)

Zope as Impedence Matching Bridge

More specifically, Zope has a number of pieces that bridge between the different data representations in the layers of an application. Zope provides many crucial bridges to maximize the user's (developer, content manager, end user, whoever's) efforts - to waste as little energy as possible in dealing with the transitions:

• between network requests and object transactions
• between objects and persistent storage - ie, the ZODB and persistence
• between the object namespace and the web URL (or other network address) namespace - ie, the Zope object publisher ORB
• between network authentication and object ownership and access permissions
• between object APIs and HTML (or XML or FTP) presentation - ie DTML [and its successor]
• between relational and object-oriented data - ie Zope database adapters
• between the implementation language (python) and the application framework

There are probably more - the above start to indicate the flavor of things we're talking about.

Zope matches data representation "media" layers so that what is easy to express in one representation layer translates as easily and consistently as we can arrange onto the corresponding (underyling/overlaying) repesentation layer.

The secret of Zope's power is the comprehensiveness and transparency of its framework and the fidelity of the transitions it offers. Some transitions are more successful than others, but the framework is sufficiently comprehensive and extensible that the rough bits can be improved over time without having to flounder on gaping holes in the meanwhile.

The ZODB persistence model, for instance, is one case where Zope does exceedingly well. It is fully transactional, and it provides its services about as transparently as you want. The Zope object programmer need take very little or no special measures to get reliable, undoable, verionsionable, etc.able storage behavior for their objects. If, on the other hand, you wish to control transaction boundaries, you can. The integration is so fundamental that the benefits of transactions extend to all levels of the system, from the outward-most presentation layers down through business logic to the object layer and storage.

The hookup between presentation and internal application logic has further to go. It wins in that the hookup is expressed as templates in the presentation (html) code, rather than as procedural code - procedural code being pretty removed from natural layout expression.

This means that it is easier to see the presentation layout in the control template format than it would be if using a procedural language for expressing control. So that's a plus. However, the coupling between the expression of the control features and the presentation features is loose, so that:

1. The resulting combination of control and presentation expressions are separate, though near, hence prone to clutter.
2. There is a disconnect between the unrendered and the rendered code, such that you can't make adjustments to the control aspects in the rendered version - it's not round-tripable.

(We have plans in the works to rectify this situation, along the lines of XMLC.)