Illustration by Brendan Davis

Introduction to Zope 3

Got a Web browser? Then you can develop in Zope! So goes the promise of through-the-web (TTW) development in Zope. Many devoted users of Zope initially got hooked because of this ability.

However, TTW development and management in Zope 2 has its issues, which we discuss below. In Zope 3, both the component architecture and the site development interface are being rethought for TTW development.

The present article – Part 1 of a 2-part article - talks about Rotterdam, a new user interface for Zope 3. We'll start with a quick tour to show the interface, then discuss the background, the goals, and the project. In Part Two we will look at the code of Rotterdam and show ways to extend the interface.

What does Rotterdam look like? After logging in, this is the first view you see:

Adding a new item lets you type in place, without the multistep process of Zope 2 and CMF:

You can "introspect" objects and find out what components were used:

The class browser makes it much easier in Zope 3 to find out what you can do with a component via its API:

The Navigation box lets you browse software as well as content:

This includes system configuration:

The interface will be discussed in detail below.

The ZMI makes it very easy to get started in Zope. You don't need special software and special access to the filesystem on the server. Also, you get a forms-based interface to guide you through the process of working with objects. The file explorer metaphor is already familiar to new users and is a good fit for many user goals.

One class of users is the "site developer": http://dev.zope.org/Zope3/SiteDeveloper.

The site developer doesn't have the time nor perhaps the skill to master a large integrated development environment (IDE) such as Visual Studio or Emacs.

However, the ZMI has some issues, both in its approach and its implementation. First, the ZMI tries to be a single interface for many different audiences. Trying to get so many goals accomplished in one interface was a challenge for the ZMI programmers.

The ZMI also has some implementation issues:

• HTML 3.2 with almost no JavaScript does not give a powerful toolset for building a productive workbench
• It is essentially impossible to extend or customize the ZMI, as many assumptions are hardwired. This includes localization.
• While the spartan look is relatively fast and appeals to early adopters, the larger crowd of mainstream users might want a more elegant design and intuitively productive environment.

Thus, in discussing a new management interface, we hope to learn from both the good and the bad in the current ZMI:

• Know your audience. Understand who is -, and, more importantly, who isn't - the target for the environment.
• Design the new ZMI so that it can be easily be replaced. While there might be a default interface, there might never be a one-and-only interface, since it is too hard to meet all the needs of all the various audiences. Further, discussion of this subject invariably produces a broad range of irreconcilable positions. Make sure people can scratch different itches.
• Adhere to standards. Even if these standards can't be used on older browsers we are building a basis for the *next* three years, not the previous three years.
• Attractive is better than spartan. People must have a positive first impression.
• No alarms, no surprises. This is a slogan from Jeffrey Shell. A good interface doesn't need documentation, as Amos Latteier used to say.

The ZMI is only half of the equation. The machinery underneath must work in concert with the visible part to produce an improvement in TTW development.

In Zope 2, ZClasses were an important entry point for site developers. This audience is primarily interested in adapting existing software, rather than creating new components and modules. Many were attracted to ZClasses as a way to very quickly create a new kind of object without visiting the months-long "Zope Re-education Center".

While ZClasses were an attractive idea, the execution of the idea had flaws that have made them a "controversial and not-recommended part of Zope".

See: this mailinglist posting

For instance, you can't change the base class of a ZClass. However, the fact remains that a certain audience found them a more attractive option than becoming "full" Zope developers.

Thus, the machinery side of Zope is being revisited along with the UI for site developers. This project is defined in Jim Fulton's fantastic "TTW Development proposal".:

See: http://dev.zope.org/Zope3/ThroughTheWebSiteDevelopment for Zope 3.

With this, the important motivations that ZClasses tried to fulfill will be implemented, but this time without the warts.

Jim's TTW Dev proposal focuses deeply on the skills and goals of the site developer, with primary support for the following activities:

• Customizing the look-and-feel of a site and its software
• Creating and configuring components
• Managing the configuration of a site

The development of a site developer UI is proceeding in tandem with the refinement and implementation of TTW development. The ideal outcome here would be: the structure of the UI should be guided by, and guide, the machinery.

So what is actually happening with regard to Zope 3's UI? Although there were two previous attempts made at developing a user interface for Zope 3, neither of these two projects are active and neither focused on a particular target audience.

A new project was needed. A group of 8 Zope folks formed a UI team at the Rotterdam sprint in December 2002 and started working on a UI that focused on the goals mentioned above. The team included several of the core developers from Plone, which provided the needed expertise on browser development.

Thus the "Rotterdam skin", aka Rotterdam, was born. Rotterdam is *a* (but not *the*) user interface for Zope. This interface is targeted at a certain class of users with certain skills and goals – as mentioned above, site developers – and the interface reflects the views and values of its contributors. Certainly Rotterdam can't, and probably shouldn't please everyone – at least shouldn't attempt to please everyone.

Rotterdam is an interface that tries to implement the evolving ideas of TTW development. Simple things should be simple and complex things should be possible. For standards, Rotterdam uses at present XHTML 1.0, ECMAScript, CSS, and XML.

Some might not agree with these standards. Some might not agree with the visual design. Some might want to scratch itches that have nothing to do with site development. The important thing to remember is that Zope 3 is designed to accept different user interfaces. It is simple to start your own UI project to satisfy different needs.

Now that Rotterdam is the default skin for using Zope 3, getting started is quite easy. Install Zope 3 and point your browser at the URL where you have Zope 3 set up. Usually this URL is "http://localhost:8080/manage".

Remember, Rotterdam requires a standards-compliant browser, namely, Internet Explorer or Mozilla!

The user interface is divided into sections, each of which is focused on site developer goals (see Figures 1-6 above). In the top right there is a box focused on the logged-in user. In the left column Rotterdam places the Navigation box and a Common Tasks box. Each of these are clearly labeled to assist with learning to work with Zope 3 and with documentation.

The big area in the middle provides a view of the currently selected resource. There are tabs for each view, with a stripe underneath containing actions for the resource. The standard views include "Content" (for folders), "Edit" (for items), "Preview", "Meta Data", and "Introspector". Just underneath the views and actions, Rotterdam places a breadcrumbs-style location stripe.

Rotterdam has several navigation paths. You can use the Navigation box to browse to a folder. You can also use the breadcrumbs-style Location to go back up to parent folders. Finally, you can view the listings of a folder and dive into an item.

Adding an item is simpler and faster than with the ZMI of Zope 2.x or the CMF UI. Browse to a folder location and choose the kind of resource you would like to add from the Common Tasks box. This immediately adds an item to the folder listing, with the cursor blinking to name the item. Note that this behavior is very similar to that of traditional file managers.

While the strategic goal of Rotterdam is to create a better experience for a more targeted audience, we have some tactical goals as well. Primarily, Rotterdam should be simple to change in a reliable, extensible way. Also, it should promote localization.

As such, Rotterdam is built as a logical set of components within the Zope 3 component architecture. This means that it leverages the power of views, ZCML for configuration, security, component interfaces, and schema-driven forms.

On the client side, Rotterdam aggressively uses Web standards. Because it is built to be heavily used by site developers, a better and more productive interface matters more than "useable in any browser".

As an example, the navigation tree was built to speed up navigation by decreasing trips to the server. Further, navigation can happen without repainting the screen. How? The navigation tree makes an asynchronous XMLHttpRequest from Javascript to retrieve an XML description of the tree, then formats the data into HTML for the interface. As new nodes are retrieved, the data is fetched in the background and added to the tree.

We will explore the Rotterdam architecture in more detail in Part Two.

As with all things in Zope 3, it is important to discuss the "who" as well the "what". Because all good ideas require someone to implement them, Zope 3 moves according to contributions and not speculation.

The primary contributor and shepherd for Rotterdam is Godefroid Chapelle. He has done the majority of the work to get Rotterdam moving and to keep it working as Zope 3 changes. Jim Fulton also worked closely with Godefroid to get the skin operational for Zope 3 alpha 1. Other contributors include Paul Everitt, Alex Limi, and Sidnei da Silva.

Rotterdam is primarily managed on the zope3-dev mailing list and on the #zope3-dev IRC channel at irc.freenode.net. The most important next step is to fulfill the goals of Jim's TTW Dev proposal. Subsequent steps in developing the interface include improving the visual appearance, making "Common Tasks" more useful, and improving the performance of the tree. There has also been discussion about backporting the UI to Zope 2 as a way to help the transition to Zope 3.

It is likely that Rotterdam will generate an intense amount of interest and input. The visual side always brings in comments and suggestions. However, Rotterdam needs contributions as much as suggestions. If several more people get involved during 2003, then Rotterdam can truly fulfill its site developer goals and provide a huge boost to Zope 3 adoption.

This article introduced the goals of site development and the role Rotterdam plays in meeting those goals. In Part Two we will discuss the implementation of Rotterdam and walk through a sample project to extend the user interface.

Paul Everitt: was co-founder of Zope Corporation, serving in a number of positions, including Vice President of Products, CEO, and Chief Strategy Officer. Before co-founding Zope Corporation, Paul was an officer in the United States Navy. He received a degree in materials engineering from the University of Florida in 1990. In 2002, Paul moved with his family to Rennes, France to start Zope Europe.