1 Introduction

Complex tasks often require a great amount of input. It may easily become unfeasible to manage this amount in a single form. It is often better to split the input into a set of simple forms and guide the user semi-intelligently through this form set. The Wizzard is a small product that manages the state of such a set of forms.

Unlike other related products (e.g. SmartWizzard or ZFormulator), it does not help to build the forms. Its only purpose is to manage the state: initialize form variables, remember and modify current form values.

2 Description

A Wizzard supports the step-by-step execution of a complex task through a series of forms. Each form is represented by a dispatcher which maintains the forms state.

The Wizzard is able to set and read the state of all controlled forms. To set the state, it supports the methods new, edit, clear and update. getValues returns the complete state in a single mapping object. If there are name conflicts between various forms, forms with a lower index take preceedance. getCollection is a synonym to avoid conflicts with the getValues method of dispatchers.

The tokens property Dispatchers__ holds the list of controlled dispatchers.

Wizzards derive from folders. Usually, the dispatchers are the Wizzards children. However, they can also be acquired. But, handling is more difficult then.

2.1 Properties


(tokens) list of dispatcher ids

Each id determines a dispatcher controlled by the Wizzard.

Ids are resolved by restrictedTraverse. This means, they can be URL fragments.

2.2 Methods


usually used to collect attributes for a new object

It calls each dispatchers new method and then renders a dispatcher.


usually used to change the attributes of an existing object

It calls each dispatchers edit method and then renders a dispatcher.


used to clear all remembered values (with the exception of fixed variables)

It calls each dispatchers clear method and then renders a dispatcher.


update remembered values

It calls each dispatchers update and then renders a dispatcher


the remembered variables as a mapping object


a synonym for getValues

2.3 Arguments

The methods new, edit, clear and update all take DTML like arguments.

The argument WizzardDestination__ controls which dispatcher is rendered, see Rendering.

The argument WizzardURL__ gives the Wizzards URL provided it can not be determined from the context. See Rendering for details.

2.4 Rendering

At the end of execution of new, edit, clear and update, the Wizzard usually renders a dispatcher. The argument WizzardDestination__ controls which dispatcher is rendered.

If there is not such argument, then the first dispatcher is rendered. If the argument is empty, then rendering is suppressed. Otherwise, it must be the id of one of the controlled dispatchers. And this dispatcher is rendered.

Rendering is performed by calling the dispatchers show method.

If the rendered object uses relative URLs, then it is important that the base URL is correct for their resolution. Without further action, this would be almost always wrong for objects rendered via a Wizzard. Therefore, the base URL must be explicitly set. If the methods are directly called via HTTP, then the Wizzard can derive its URL from the request context (URL1). However, when called indirectly (e.g. via DTML), then this may no longer work. In these cases, the argument WizzardURL__ must be used to inform the Wizzard about its URL. Note that we can not use absolute_url, because it discards all context from the URL.

3 Installation

Download the Wizzard and Dispatcher TGZ archives and unpack them into your Zope Products folder. Restart Zope. You should then find Wizzard and Form Dispatcher entries in your add-list.

4 License

This product is covered by a Python-like open source license. For details, see the Copyright notice at the top of Wizzard.py.

5 History

Zope 2.7 compatibility
Worked around some Zope security flaws
Provisions for use in ZClasses

Dieter Maurer
Last modified: Fri Jan 2 20:39:32 CET 2004