Skip to content

Project description

Inaimathi edited this page Mar 6, 2011 · 1 revision

Goals

Boilerplate elimination

At the high level, form interaction in HTML requires

  1. Showing the user a form
  2. Get the response back
  3. Run a validation function per form field (or run a single validation function on all of the fields)
  4. If the validation passed, send them on, otherwise, show them the form again (but annotated to highight errors they need to correct)

and I don't want to have to type it all the time.

Simplicity

A declaration and show-formlet call is all that should be required to display, validate and potentially re-display a form.

Style

Automatically wraps the generated form in a UL and provides CSS classes and ids as hooks for the designers, making the look and feel easily customizable.

Completeness

The system will eventually support the full complement of HTML form elements, including select, checkbox and radio, as well as higher-level inputs like date or slider. Currently, it only supports password, text, textarea, file and recaptcha.

Non-Goals

Portability

The system assumes Hunchentoot + cl-who. This allows the internal code to take advantage of HTML generation, as opposed to tag formatting.

Run-time efficiency

The module is aimed at simplifying HTML form use for the developer. This is a place that's by definition bound by the slower of user speed or network speed. Furthermore, a single form is very rarely more than 20 inputs long in practice. Pieces will be made efficient where possible, but emphasis will not be placed on it.

Markup customization

While there are no assumptions about the CSS, formlet HTML markup is fixed by the implementation. A user can modify the show-form and show-form-field functions to change output, but this will not be made customizable by external variables.

Clone this wiki locally