Zope 3 wiki → Developer Info →
last edited 1 year ago by Christian Theune
created: 2003-08-03

Vision Statement

Project Vision

Historical information: This page contains information that was drafted when Zope 3 did not exist. All references to "Zope" are meant to refer to Zope 2 in its former state.

Status: IsDraft

For background on a Zope component architecture see the Zope Directions document. It outlines the goals of a component architecture and talks about how it might be implemented.

Problem

General

Zope can be difficult to develop for.

You can't learn Zope development in bite sized chunks; you must learn the entire framework at once. It's hard to use familiar tools and techniques. It's hard to reuse code. The Zope development model (ie Products) often seem too heavy-weight. Zope products don't offer a good separation between logic and content.

In short, it is hard to extend Zope and use the framework in a way that's easy to learn and quick to develop and deploy.

Specific problems

Zope manages complexity through multiple inheritence. Complexity is divided among many mix-in classes. A class that wants to provide the many standard features of Zope objects must mix-in many different classes. The mix-in classes may require specific meta data or hooks that must be provided in the custom class. This presents an extremely complex programming model to the Zope developer.

Reuse is difficult.

  • Classes developed outside of Zope are hard to use in Zope because of the heavy framework and inheritence requirements.
  • To be reused, classes must provide exactly the needed behavior, which rarely happens. Functionality often needs to be added, removed, or modified. Alternate user interfaces are often desired. The inheritence based model used currently makes this very difficult.

The Zope ContentManagementFramework (CMF) addressed these problems by splitting behavior over many different objects:

  • CMFContent objects have no application-specific behavior. They expect application behavior to br primarily provided by CMFTools and expect presentation to be provided by CMFSkins.
  • CMFTools provide application-specific functionality and meta-data.
  • CMFSkins provide places to collect and override specific presentation templates and logic.

The CMF knits the various components through Zope acquisition and through meta-data provided in CMFType objects.

The CMF is a major step forward in Zope development. It provides a much simpler model for developing Zope objects through the separation of concerns among objects.

The CMF has a few limitations:

  • The use of implicit acquisition to knit things together makes things more brittle than desired. Names of acquired objects need to be chosen carefully so as not to conflict with content names, and content names that conflict with tool or skin names must be prevented. Preventing conflicts is problemantic if new tool or skin names are added over time.
  • Skins are collections of templates and scripts. Templates and scripts that cooperate to provide a user (web) interface for a function are connected only by convention. Collecting related templates and scripts into objects would provide greater structuring.
  • Use of acquisition to knit components together requires that component names include the types of the content they apply to.
  • CMFTools provide functionality that is
    • applicable to all (or mostly all) content types, and
    • centralized in the sense that, to function properly, they must be used by all the content in a site.

    There isn't a general facility in the CMF to provide content-specific application-specific behavior.

    • CMFContent objects have a number of contracts that they must fulfill. They have a much lower burden than most Zope objects, we'd like to reduce the burden further.
    • Distributing CMF content-type configurations is harder than it should be. A new content type has associated skins and configuration information that may be spread over many different objects. There aren't automatred ways to distribute this information.

Historical perspective

Zope 2 arose from a commercial product, Principia, that was designed to make it easier for non-technical people to create dynamic web sites. To this end, it automated as many functions as possible. The high degree of automation, or "implicitness" often made it harder for developers to learn and reason about the system. As a result, Zope, one of the most widely used Python applications, often actually puts off Python programmers.

Opportunities

Despite the problems noted above, Zope 2 has been very successful because it and the systems built on it, such as Plone, help people solve problems more quickly and effectively than other approaches!

Over the history of Zope 2, we've learned many things we would like to do differently and many improvements we would like to make. Zope 3 provides us the opportunity to learn from the past and build an even better version of Zope. To some degree, we can take out time to "get it right", thanks to the fact that we have an excellent system, Zope 2, that we can use while we build the future.

Proposed Solution

This project proposes, at a high level, to do a number of things:

  • Improve the development experience. We want to provide a much more rational development model that is attractive to Python and other developers.
  • Make it much easier to create objects that are usable in Zope:
    • Make it possible to use existing Python classes (with little or no change).
    • Utilize features of the Zope framework with small incremental changes.
  • Ease the leaning curve for developers
  • Facilitate software reuse
    • Use existing non-Zope-specific objects
    • Add, remove, and replace functionality of existing objects.
    • Change the user interface of existing objects,
    • Provide alternative access methods (e.g. FTP, XML-RPC, wxWindows) to objects.
  • Provide more flexibility for configuring Zope software
  • Apply lessons leaned from using and building Zope 2
  • Provide ground-up support for internationalization and localizatiopn
  • Integrate CMF technology and development patterns into Zope.

We propose the development of a component architecture. A this would make it easier to use the Zope framework. It would make it easier to develop extensions (ie components) quickly. It would make it easier for developers to use each others components (ie reuse).

See the UseCases for UserGoals? adressed by this effort.

What is Zope3

I (JimFulton) see Zope 3 as two things:

  • An application server that provides a platform for creating content-managemnt applications, especially web-based content-management applications.

    One of the outputs of the Zope 3 project will be a web-server application that is recognizable as Zope. There will continue to be the features and capabilities now present in Zope 2.

  • An component-based architecture for creating a variety of applications. We want an architecture that is robust and can be used for many kinds of applications, including applications that look nothing like the traditional Zope application server. There are two reasons that we want such an architecture:
    • We'd like to be able to leverage what we've built to support Zope with other application,
    • We believe that making the Zope architecture robust in this way will provide a sounder foundation for the application server.

Therefore, when designing the Zope architecture, we will not be limited solely by the needs of the application server, although, as a practical matter, the needs of the application server and it's users will drive development priorities.

Risk Factors

Please see the RiskFactors document.

Scope

This project will:

  • Define the basic theory, architecture, and techniques for component-based development in Zope.
  • Update CMF architecture according to the ComponentArchitecture and integrate it into Zope.
  • Provide a mechanism for distributing component configurations and content for the new component-based CMF. This is specific to the CMF limitation defined above. That is, that CMF content has associated objects that provide presentation and configuration information and we need an easier way of distributing this information together.

The project will not:

  • Make product management decisions such as deciding the relationship between the Zope and CMF products, or deciding what, if any, CMF software will be included in a particular Zope distribution.
  • Create new software distribution mechanisms other than the content-packaging mechanism for CMF content menioned above.

Deliverables

Documentation of the component basic and CMF component architectures.

New Zope software that implements:

  • ComponentArchitecture infrustructure software
  • Component-based CMF component infrustructure software.
  • Additional CMF products that provide remaining CMF functionality using the new component technology.

jshell (Dec 3, 2001 9:15 pm; Comment #1) Editor Remark Requested
Regarding "Events".... is there going to be a common way of handling events, notifications, and observations? An event channel has been long-planned for the CMF, but remains unseen. Is that work going to move over to the Component Architecture?
Jim (Dec 5)
I see events as being a part of some layer above the component architecture. I'm not sure that it's in scope for this particular project. Of course, that doesn't mean it won't happen.
Jim (January 2004)
Zope 3 now includes an event architecture
wilm (Dec 7, 2001 5:33 pm; Comment #2)
Above, it is stated that "it is very unlikely that we will remove the requirement for mixing in persistence any time soon." However, the component tutorial in cvs contradicts this: "It is likely that, in the future, it will be possible to store objects in Zope without mixing in Persistent, however, it will be necessary to make explicit calls when objects are modified so that changes can be saved."
Jim (Jan 2004)
Right, we don't require persistence. It's up to the developer to decide how to manage their data.
zopemaniac (Sep 19, 2002 11:42 am; Comment #3) Editor Remark Requested
I was going thru this documentation http://dev.zope.org/Resources/ZopeDirections.html

In this document of the above link i found a line "A component could be implemented as a function or a class"

which sounds quite confusing to me.

Would anyone like to explain, I really need to understand this line.

fredrik (Sep 27, 2002 3:15 am; Comment #4)
"A component could be implemented as a function or a class" tells us that a component can be implemented as a Python function or a Python class. Read the tutorial at http://www.python.org/doc/current/tut/tut.html if you don't know the difference.



( 96 subscribers )