Editorial note

This document was created in 2001. It describes the original motivations for starting the Zope 3 project. These motivations largely remain. Rather than updating this document, we'll leave it intact as a historical document.

Executive Summary

This paper summarizes current thinking at Digital Creations about where Zope is going. We plan to evolve Zope in a number of ways with the goal of making life easier for developers. We want to allow you to more rapidly develop web applications with Zope and more easily reuse your code.

Zope has developed over a number of years as a project aimed at content managers with short shrift given to developers. We hope to learn from Zope's current shortcomings and offers key improvements going forward.

• Provide a clearer programming model that supports rapid development and reuse.
• Reduce the learning curve by simplifying Zope's architecture and improving consistency and documentation.
• Allow developers and designers to work with familiar tools using their normal working methods.
• Provide much stronger content management facilities with the Content Management Framework (CMF), a Zope add on.

These improvements are currently in development. We are considering the architectural changes necessary to support these features. This white paper gives a technical discussion of how we plan to evolve Zope to meet these goals.

Zope Directions Overview

Goals

The major goal of evolving Zope is to apply the lessons we've learned over the last several years to redesign Zope to better serve developers. This goal is in line with Digital Creation's own business goal of providing more effective consulting on the Zope platform. Just like you, we need a platform that allows us to rapidly deliver rich web services to our customers.

We intend to make life easier for developers by simplifying the Zope development model and breaking content management features out into the CMF add on. The core knowledge required to develop for Zope will be greatly reduced, allowing you to learn Zope in bite sized chunks. Additionally, the Zope framework will focus on consistency and explicitness rather than convenience. We know that Python is a great language because it has a small core of concepts, values explicitness and consistency, and has a great standard library. Zope will follow this lead.

Audiences

Web applications are built and maintained by many people. Zope has always provided strong collaborative capabilities. We want to take this idea further by providing more powerful environments for the different actors.

Here's how we picture Zope applications being built and maintained by developers, designers, and administrators. Developers build components which provide reusable logic. Designers build applications by wiring components together with scripts and user interface templates. Administrators deploy applications and handle issues such as upgrading and clustering.

For developers we want to offer a greatly improved experience. The development model will be simplified. In addition developers will be able to use familiar filesystem-based tools to build Zope components. Components will help developers by allowing them to quickly build re-usuable code. Components will be easily deployed and updated.

Designers will benefit by being able to use their familiar tools for HTML editing and scripting. We will phase out DTML in favor of Presentation Templates for presentation, and Perl and Python scripts for logic. The designer's life will be easier since they will build applications with pre-built components and use standard tools and techniques for scripting and presentation.

Content managers will benefit from the pre-built components available in the CMF. The CMF will offer services such as workflow, indexing, integration, and decentralized management. Content managers will be able to work with familiar tools such as Microsoft Word to manage content.

Development Timeline

New Zope features will appear in successive Zope releases. Additionally some technologies will first appear as Zope add ons and will migrate to the standard distribution as they mature. None of the advancements we are considering will break backward compatibility.

A number of Zope features such as Python Scripts and Interfaces are already available in Zope 2.3 Pearl Scripts are currently an add on. Presentation Templates are currently under development and will be released as an add on. Other features such as a component model need to be further elaborated.

All new Zope features will be developed through the fishbowl process. You will be able to participate and contribute to Zope's development.

Zope Features Current and Planned

Rapid Development and Deployment

Applications built with Zope typically take half the time required for comparable solutions. In the future, Zope will allow you to develop and deploy applications even faster thanks to the forthcoming component architecture.

Easier to Learn

In the future, Zope will be easier to learn because it will offer a simpler development model and will not require using new tools. We will also reduce the learning curve, allowing you to learn Zope one bite at a time.

Scalability

In the future, Zope will come with scalability features out of the box, allowing you to scale your application across multiple processes and machines.

Rich Services

Zope offers many services to your applications such as persistence, security, transactions, full-text indexing, XML support, caching, networking, database connectivity, sessions, HTTP, FTP, WebDAV, XML-RPC, and more. In the future, services will be added and made easier to use.

Code Reuse

Using components you can more quickly leverage your existing code to build new web applications. Component deployment will also be improved allowing you to more easily plug in existing components into your applications.

Standards Support

Zope supports many Internet standards including: HTTP, FTP, WebDAV, XML-RPC, XML, XHTML. It also supports the two most popular standard scripting languages Perl and Python. In the future, we will add support for more standards.

Open Source

Zope is fully open source. This will not change. Not only is it free to use, but you can change and redistribute Zope as you see fit. You cannot be held hostage by a vendor when you control your application code. In addition Zope attracts a large community that improves and extends it, and offers great peer support.

Planned Zope Changes

Architecture

Zope is a web application server. Zope applications run on the server and communicate with remote clients such as web browsers. Zope consists of an application server and an object database server. Both Zope servers can be clustered to serve the same application (or applications) from many processes and machines. Zope can also work with other servers including database servers, web servers, and other servers such as SMTP or LDAP servers.

Zope logic, data, and presentation information is all stored in the object database. This provides persistence, transactions, scalability, security, collaboration, and management services to logic, data, and presentation. Zope can be managed through the web, or via the filesystem.

There are no major planned changes to the Zope architecture. The major goal will be to simplify how components (now called products) are built and used. For example, currently some products are built in the filesystem and some are built in the object database. We want to remove this distinction so that all components can be edited via the filesystem and live in the object database.

Applications

Zope applications are built out of components. Components are pluggable, reusable, and persistent code modules. Components are written by developers. Site designers build applications by gluing together components with scripts and presentation templates.

The major planned changes to applications is the gradual phasing out of DTML as a presentation and scripting tool. Instead we will focus on using Python and Perl Scripts for scripting, and Presentation Templates for HTML presentation.

Presentation Templates

Presentation Templates will allow you to build your user interface in XHTML. This way you can use WYSIWYG HTML editors to develop and preview your application. Using special tag attributes you can connect your template to dynamic Zope data. Presentation Templates are evolving from HiperDOM and are partially inspired by XMLC. For more information on Presentation Templates, see the fishbowl project.

Python and Perl Scripts

Python Scripts are now part of Zope. Perl Scripts are currently an add-on. For more information see the Zope-Perl Wiki. Both Python and Perl Scripts are documented in the Zope Book.

Content Management Framework

The Content Management Framework (CMF) is a Zope add on for content management. It provides services for content management applications including search, directory, membership, reviewing, syndication, and integration. It comes with many pre-built content and user interface components.

Technically the CMF is a collection of components and services which you can use to develop applications. It comes with a sample portal application which you can customize. As Zope's component architecture solidifies, the CMF will be migrated to it.

The CMF will continue to develop separately from Zope. This will allow it to evolve without being bound by the Zope release cycle. In addition developers will benefit by separating content management from the core; it will simplify the Zope development model and provide more flexibility in content management applications.

The CMF will likely become a very important part of Zope since we are focusing much of our consulting work on it.

Components

The major architectural change planned for Zope is the move to a component model. Components are pluggable, reusable, and persistent code modules. In developer terms, components are objects with interfaces. Components will only talk to each other using methods defined in interfaces.

Components need not be as heavy weight as current Zope products. Components need not be persistent, nor provide a management interface. This will allow you to use components for all kinds of tasks, without having a lot of overhead.

Components will be written in Python. A component could be implemented as a function or a class. Components must implement interfaces. Interfaces are described using the Interface package. For more information on interfaces see the fishbowl project

Components will be edited via the filesystem as .py files. Components will probably be checked into and out of Zope via a CVS like facility. Components can be tested locally without checking them into Zope.

The first step down the road to components has already been taken; interfaces currently ship with Zope 2.3 Moving forward we will develop a component architecture and componentize existing Zope infrastructure. Components will also be integrated with the help system, so that component interfaces are browsable as API documentation.

Services

Services will be a major part of a component architecture. A service is standard facility provided by a component to other components. For example, a catalog component could provide a catalog service, and a mail host component could offer a SMTP service. Zope will provide a mechanism for components to provide and use services. Many of the services that Zope currently provides will take advantage of this framework, which will make it easier for developers to work with the Zope framework. Services will also make it easier for developers to provide standard Zope services such as user authentication with their own components.

Services will be elaborated in a fishbowl project as part of the component architecture project. Existing Zope services will be described with interfaces and moved to the service framework after it is developed.

Adapters

Adapters provide a way to decouple a component's logic from its presentation. For example, the Parsed XML project uses adapters to provide a management interface for its basic DOM components. Likewise, we anticipate a move to adapters in the future to provide protocol-specific publishing logic, and user interfaces for components. Zope will provide support for adapters as part of the component architecture.

In developer terms, an adapter maps one interface to another. So for example, an adapter might provide filesystem editing support to a document component by adapting the document interface to the filesystem publishable interface.

Adapters will be elaborated in a fishbowl project as part of the component architecture project.

Conclusion

Our goal for Zope development is for Zope to become more developer friendly. We want to make it easier to develop for, and to provide developers with richer services.

We plan to achieve these goals by separating content management into a CMF add on, moving to a component architecture and providing more support for the separation of logic and presentation. These changes should improve the Zope learning curve and allow you to use familiar tools to develop applications. We believe that these changes will improve your ability to rapidly develop and deploy web applications with Zope.