#3: Death to portal_form!

Contents

1. Motivation
2. Proposal
3. Implementation
4. Deliverables
5. Risks

Proposed by

Geoff Davis

Proposal type

Architecture

State

completed

Motivation

Form validation is currently a pain in the ass. Requiring portal_form in URLs is cumbersome and easy to forget to do. The requirement that validators and navigation be registered separately from forms is cumbersome. It would simplify things greatly if:

1. it were unnecessary to include portal_form in URLs, and
2. one could specify default validation and navigation within a page template and use form properties and navigation properties only for overriding these defaults.

Proposal

Get rid of portal_form. Simplify form validation.

Implementation

I see this proceeding in 4 stages:

1. Remove portal_form. We define a new class of page template, a PlonePageTemplate, that subclasses PageTemplate. When rendered, PlonePageTemplates invoke the validation machinery that is currently invoked by portal_form. This would be the release 1.0 version.
2. Define syntax for specifying default validators and navigation within a page template. Some ideas are presented below.
3. Add i18n for error messages a nice way.
4. Enhance validation by wiring up Zope Corp style validators to work with the PlonePageTemplate validation/navigation machinery so that you can add, say, an integer validator by simply naming a variable 'foo:int'.

Default validation and navigation would be specified inline via hidden variables. Some possible syntax for specifying validators/navigation:

For specifying validators:

'<input type="hidden" name="form.validators:list" value="script1, script2, script3"/>'

This default validation should be overridable via a mechanism similar to the existing form_properties property sheet.

For specifying post-validation actions:

'<input type="hidden" name="form.action.STATE" value="ACTION_TYPE:PARAMETERS"/>'

where 'STATE' is a value returned by the validators, 'ACTION_TYPE' is a type of action, e.g. redirect to a page, invoke an action associated with an object, invoke a named action, or by default traverse to a script or web page. There should be a process for registering new types of actions. If there is no action specified for the returned state, the page would be redisplayed, so there would be no need for a form.action.failure if, as is typically the case, the desired action was to redisplay the page.

Some examples:

'<input type="hidden" name="form.action.success" value="success_script"/>'
Traverse to the script/template success_script when “success" is returned by the validators.

'<input type="hidden" name="form.action.success" value="action:view"/>'
Traverse to the context object's view action.

'<input type="hidden" name="form.action.success" value="redirect:page2"/>'
Redirect to page2.

Allow an action to be overridden by naming it:

'<input type="hidden" name="form.named_action.action1" value="action:edit"/>'

and then having:

'<input type="hidden" name="form.action.success" value="named_action:action1"/>'.

The named action would be overridable via something like the existing navigation properties.

Multiple buttons:

Something else to think about is how to set up variable validation / navigation when there are multiple buttons on a page and you want each button to invoke a different set of actions. Maybe something like the following?:

<input type="submit" name="button1:button"/>

<input type="submit" name="button2:button"/>

<input type="hidden" name="validators.button1:list" value="v1, v2"/>
<input type="hidden" name="validators.button2:list" value="v1, v2"/>

<input type="hidden" name="form.action.button1.success" value="redirect:page1"/>'  
<input type="hidden" name="form.action.button1.success" value="redirect:page2"/>'  

Please give me feedback on these naming conventions!!

Deliverables

Code: A new PlonePageTemplate class and FSPlonePageTemplate class and a new set of property sheets in portal_properties.

Documentation: (1) A tutorial on using the new-style forms, (2) guidelines for creating and registering new form actions, and (3) guidelines for creating and registering new ZC-style variable name validators.

Risks

Migration will be hassle, but well worth it.

I know squat about i18n, so unless I get good feedback and input, the syntax might be awkward for i18n.