Illustration by Brendan Davis

Introduction to Zope 3

The present article deals with the following topics:

• Where the development of Zope 3 currently stands
• What has been achieved
• How Zope 3 differs from Zope 2
• What to expect as development continues and Zope 3 matures
• An explanation of some of the code-level features of Zope 3

There's been a lot of buzz about Zope 3. We've had sprints and sprintathons where both programmers and user-interface designers have come together for 3 days to a week to move Zope 3 forward:

Pictures of the Sprintathon here:

We've had an "alpha" release of Zope 3X, so that a wider audience of Zope software developers can get a feel for how Zope 3 development is going.

There's another "alpha" release of Zope 3X due any day now. I'll say a few words about the difference between "Zope 3X" and "Zope 3" a bit further down.

We've had over 100 Proposals for improvements and enhancements from the Zope community, many of which have been implemented.

We have over 3000 unit tests, which get run on the code in CVS every night on Windows, Linux and FreeBSD. A unit test is a short program that is used to check that parts of a large program work correctly. Every piece of Zope 3 code is accompanied by a 'unit test' program.

But what is Zope 3, and what will it mean to Web developers and applications programmers? I hope the rest of this article will show where Zope is going, and what you'll be able to do when we get there.

Zope 3 is fundamentally a lot like Zope 2. It is about publishing objects and content and programs as Web pages, with flexible security, storing data in the ZODB, querying relational databases, scripting languages...

Everything you can currently do with Zope 2, you'll be able to do with Zope 3. But also a lot of things that are hard to do or complex in Zope 2 will be at least somewhat easier with Zope 3.

I think of Zope 3 as being what you would get if you pulled Zope 2 apart and then put it back together in a better way. But not only that, if you put it back together like so many Lego bricks, so you could easily rearrange it again later, to suit your needs.

Further down, I'll explain by way of some concrete examples of how things are different in Zope 3.

Above I mentioned "Zope 3X" and "Zope 3". Right now, the Zope 3 development community is working on a project called "Zope 3X". The "X" is really just a marker to distinguish it from "Zope 3", but it might stand for "X the Unknown" or "eXperimental" or "eXtreme". What this means is: we are building Zope 3X without worrying about whether what we do is backwards-compatible with Zope 2. This gives us a lot of freedom to do things better, and to create innovative solutions to problems. But, Zope 3X is not Zope 3.

Once development of Zope 3X has slowed down, and we have a stable base to start from, work can start on Zope 3 proper. Zope 3 will take its inspiration from Zope 3X, but will contain extra code to help with backwards-compatibility.

In summary:

• Zope 3 is the next major-version Zope release, following Zope the 2.x series
• Zope 3X is a research-and-development project loosely based on Zope 2

Some people have expressed the worry that since some of the people who were working on Zope 2 are focusing their time and energy on Zope 3, Zope 2 might be on the way out.

Zope 2 isn't dead; far from it. Rob Page, CEO of Zope Corporation issued the following statement:

"Zope Corporation will continue to support, enhance, and solicit enhancements for Zope 2.x for the foreseeable future."

There's been a lot of discussion about the importance of providing a smooth transition for those who want to move from Zope 2 to Zope 3. Jim Fulton recently said:

"It's critical to the many Zope businesses around the world, including ZC, that the transition from Zope 2 to Zope 3 be as clear and understandable as possible."

There will be some means of migrating code and data from Zope 2 to Zope 3, but it is too early to start working on this now. Zope 3 is still under development, and still changing quite a lot.

In this article, I want to give a taste of the shape of things to come. Like forecasting the weather, this can't be done with absolute certainty. Things I say here will probably change before Zope 3X is finished and this will have an effect on the shape of Zope 3. Nonetheless, the kind of facilities I describe will be available in some form.

Some of this article describes things that exist already and that you receive when you download Zope 3X from CVS, or they will be in the next alpha release. Other things are planned for inclusion later, depending upon when people will have the time to write them.

Zope 3 is still about taking objects and publishing them in various ways through the Web, and via FTP and XML-RPC. There is still integrated security based on users, roles and permissions. But...:

• Individual Users can directly have permissions and roles. You no longer need to assign permissions via roles, although this will still be possible, and will be recommended practice.
• There will be groups of permissions and groups of users.

There are still scripts and templates and pages and queries that you can add using a browser.

• There's still DTML (as you can see from the screenshots) but its syntax has been simplified.
• There are still Zope Page Templates (these are now called Templated Pages).
• There will be Python Scripts for those ad-hoc bits of code to glue pages to database adapters, and pre-process results, and that kind of thing.

• You can name the contents almost anything you want. This is an improvement on Zope 2, where you have to avoid names like REQUEST and manage_tabs.
• There is no automatic 'implicit acquisition'. You can't just refer to an object in a folder, and expect it to be found from a higher-up folder. On the whole, this is a good thing because it makes developing software with Zope easier to understand and debug, and more predictable. You use 'Resources' and 'Views' and 'Services' when you want explicitly to acquire shared capabilities. It is easy to do this from page templates, scripts and DTML.
• If you're writing a product for Zope 3, you don't need to mix-in other classes such as SimpleItem to get the correct behaviour when you put an object in a folder. You use 'Adapters', some of which will be written already for you, to achieve the same ends.

(I'll talk about Adapters further down.)

Zope is still written in Python

• As with Zope 2, there's a bit of C code here and there to make things run faster.
• Right now, Zope 3X requires Python 2.2.2.
• The naming of packages and modules is much more Pythonic, as is the Zope 3 code, which makes it easier to read than Zope 2 code. Partly, this is because things having to do with presentation, such as rendering HTML, are kept separate from the main bulk of the code. The Zope 3 naming was a direct influence of the Twisted project. http://twistedmatrix.com
• Because the classes that make up applications are not required to derive from special Zope mix-in classes such as SimpleItem, Zope 3 applications are easier to understand and debug.

Rather than explain how Resources, Views and Services work, I'll give a few examples of when you'd use them.

In Zope 2, you might put all of your images and CSS style sheets and .js JavaScript files into a folder inside the root folder, called 'Images'. You would then use acquisition to acquire 'Images/picture.jpg' from other pages in your site. You can use Resources for this in Zope 3. Each of your images and style sheets and other files becomes a Resource. You can access them from a page template like this: <img tal:attributes=”src context/@@/picture.jpg/absolute_url” /> The Resources Service ensures that a resource appears to come from the same absolute URL no matter where you access it from. This is important for allowing images and other large files to be cached in HTTP proxy caches.

Let's say you have a number of text files in different folders. In Zope 2, you can add a script in your root folder called 'summary_html' that extracts the first paragraph of text from a file and presents it to the browser. So, if you have the GNU Public Licence as a text file called 'gpl', if you go to http://example.com/licences/gpl/summary_html, you will see the summary of the GPL.

In Zope 3, you achieve the same thing by adding your script as a "view" that should apply to all text files. The advantage is that there is no need to have something called "summary_html" in your root folder. Also, this view is only used for text files, not for other kinds of things. So, there is no danger of inadvertantly using "summary_html" for an image or a folder.

Zope contributor Toby Dickenson humourously points out the dangers of this kind of thing in this message to the Zope developers' mailing list. http://mail.zope.org/pipermail/zope-dev/2000-October/007495.html

When you want to send email from a page in Zope 2, you add a MailHost in the root of your site, and use the <dtml-sendmail> tag or a Python script to format the email and send it off. In Zope 3, you add an SMTP Mail Service, and use the <dtml-sendmail> tag or a Python script to format the email and send it off. The difference is that, in Zope 3, there is no object called 'MailHost' in your root folder. Nothing will go wrong if someone decides to call a file 'MailHost' in some folder.

Look carefully at the screenshot above of a folder with stuff in it.

The image 'graphic.png' in that folder tells you its size in KB, and its dimensions in pixels.

The folder doesn't know how to do this. Otherwise, we'd have to keep extending the Folder code for each new kind of thing we wanted to add to a folder. On the other hand, since an image doesn't know how to behave as the contents of a folder, it would require that the programmer add code to the image's class to show its size in a list of folder contents. That would put an onerous requirement on people who want to write products for Zope 3. Instead, a simple 'adapter' knows how to show the size of an image. An adapter is an object that knows how to 'translate' one kind of object into another kind so that it can work under circumstances other than those it was originally designed for. In this case, we have an adapter that knows how to present the size of image objects.

There are different adapters for images and page templates and folders and files. The file's size is shown in MB, the template tells you how many lines of html and script it has, and the folder tells you how many items it contains: each of these presentations of "size" is achieved by means of a different kind of adapter.

Let's take a look at the code that adapts a folder (or other container) to give its size in "items".

        class ContainerSized:
            implements(ISized)

            def __init__(self, container):
                self._container = container

            def sizeForSorting(self):
                """See ISized"""
                return ('item', len(self._container))

            def sizeForDisplay(self):
                """See ISized"""
                num_items = len(self._container)
                if num_items == 1:
                    return '1 item'
                return '%s items' % num_items

That's it. That's an adapter. In the sizeForDisplay() method, it finds out the number of items in the container, and presents it either as "1 item" or as, say, "23 items" depending on the number of items it has determined.

The Sized adapter for images is similar, and like the adapter shown above, has a sizeForSorting method and a sizeForDisplay method. You can see what these methods are supposed to do in the ISized interface:

        class ISized(Interface):

            def sizeForSorting():
                """Returns a tuple (basic_unit, amount)

                Used for sorting among different kinds 
                of sized objects.'amount' need only be 
                sortable among things that share the
                same basic unit."""

            def sizeForDisplay():
                """Returns a string giving the size.
                """

An interface looks a bit like a class, but it doesn't actually do anything. It defines what methods and attributes something needs to have to meet expectations. The documentation tells you what these expectations are.

There's an Adapters Service whose job it is to keep track of what adapters are available, and what kinds of objects and interface expectations they work for.

End of Part I - For the next part of this article covering ZClasses in Zope 3 as well as an example Development scenario click here.

Steve Alexander: Steve Alexander was born in England in 1974. He holds an honours degree in Computer Science and Software Engineering, and is a member of the IEE. Steve runs a Zope consulting company that produces software for human resource departments. He is a contributor to the ongoing Zope 3 project, and has sprinted in Fredericksburg, Reading, Rotterdam, and Vilnius. Steve currently works from Vilnius, Lithuania, working alongside CodeWorks.