## page was renamed from NewZopeForms
## page was renamed from LaunchpadDevel/NewZopeForms

= Improving Zope3 Forms =

== Status ==

  * Created: 20/04/05 by MarkShuttleworth<<BR>>
  * Priority: MediumPriority<<BR>>
  * People: StuartBishopLead, SteveAlexanderSecond<<BR>>
  * Contributors: MarkShuttleworth<<BR>>
  * Interested: BjornTillenius<<BR>>
  * Status: BrainDump, BreezyGoal, UduBof, LaunchpadSpecification<<BR>>
  * Branch: <<BR>>
  * Malone Bug: <<BR>>
  * Packages: <<BR>>
  * Depends: <<BR>>

== 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.

  1. Specify the context as usual, but specify a particular view class
     and method to be used to parse the form.

  1. 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.

  1. 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