Improving Zope3 Forms

Status

• Created: 20/04/05 by MarkShuttleworth
  

• Priority: MediumPriority
  

• People: StuartBishopLead, SteveAlexanderSecond
  

• Contributors: MarkShuttleworth
  

• Interested: BjornTillenius
  

• Status: BrainDump, BreezyGoal, UduBof, LaunchpadSpecification
  

• Branch:
  

• Malone Bug:
  

• Packages:
  

• Depends:
  

Introduction

This spec describes features of an improved Zope3 form system. Specifically, these forms should be able to include fields from multiple interfaces, and allow the application to hook into their processing in a simple fashion.

Rationale

Currently, forms in Zope3 are rather limited. There are addforms and editforms, but these make a great deal of assumptions about the nature of the form and are not suitable for many applications. For example, they assume that the form should map to only one underlying content object, so the form is either adding or editing a single underlying object. But in many cases, the form would be better off representing a collection of objects, of the same or different types, and so we need some intermediate processing both with the rendering and with the parsing of the form.

Scope and Use Cases

In several cases in Launchpad we have had to hand-craft forms. These forms suffer from poor maintainability over time, are difficult to internationalise, and are difficult to keep consistent with the rest of the site in terms of look and feel.

Typically, such hand-crafted forms have been required where the underlying model uses several tables (content objects) to represent a single concept. For example, when adding a message to a bug we have to add a Message, as well as a BugMessage. This is not possible with a simple addform so we resort to some custom code, but the custom code is somewhat hamstrung by virtue of being a subclass, in effect, of the normal addform.

It would be better if one could define a form:

1. As consisting of a set of fields, which might be drawn from a number

   • of different schemas. For example, the form to create a new distribution might include the fields from its first distrorelease so that both could be validated and created together. Rather than creating a new content object (c.f. the amazing BugAdded it should be possible to conjour up a form that includes fields from both Distribution and DistroRelease.

2. Specify the context as usual, but specify a particular view class
   • and method to be used to parse the form.
3. Include a standard way to validate the form components, including
   • validation that is related to the content of other components. For example, if a form is gathering upstream revision control details, and someone has chosen "SVN" upstream then we need to validate that they have given an svnrepository, but we don't need to validate that if they have chosen CVS.
4. Support multi-page forms, or wizards, with a straightforward modelling
   • of the ability to go to the previous or next page, and validation that can be smart enough to take into account data gathered earlier in the wizard.

Implementation Plan

Data Preservation and Migration

Packages Affected

User Interface Requirements

Outstanding Issues

CategoryUdu CategorySpec