[Bese-devel] RFC: FORMs (draft)

[Marco Baringer]

I think that in my life i have written (or some how created) about a
gazillion "data entry forms." For "data entry form" I mean an html
form whose goal is to allaw the manipulation (creation, deletion and
modification) of some kind of "object" in the application.

There are 3 main issues involved:

1) We need to allow complete control over what the form looks like (ie
   the mapping from object -> html). However, in the common case we
   will only want to speciy that a few of the many forms are different
   from all the rest, most of the forms are completly alike and should
   be automatically built, given the proper defaults.

2) We need to specify how to translate what data we get from the
   client (strings which can be maliciously manipulated) into objects
   the server can deal with.

3) We need to gracefully deal with objects which are linked to other
   objects. We also need to gracefully deal with sequences and
   indexed-arrays.

Assuming this is going to be integrated with UnCommon Web and will use
TAL/yaclml for generating the html here are my thoughts on the matter,
comments welcome:

We'll create a new class of components (not really components, but
obscenly similar) called FORM. A FORM will be an object representing a
(single) common lisp object which we want to user to be able to
monipulate via an html form.

Form objects can composed in a hierarchy (or container/contained
relationship). All form processing happens bottom up.

A form class is a sub class of:

(defclass web-form ()
  ((c-value :documentation "The client side representation for this
            object. either a string or another web-form object.")
   (s-value :documentation "The common lisp object for this form.")))

And will define methods on the following generic functions:

(defgeneric validate ((form web-form))
  (:documentation "Returns T if the user's values are \"good\", NIL
  otherwise. If it returns T it MUST also set the s-value slot to the
  corresponding common lisp object."))

(defgeneric render-on ((res response) (form web-form))
  (:documentation "Create the proper html input tag."))

When processing the user's input we will set all the c-values from
the request and then call validate bottom up:

1) if a web-form's c-value is a a web-form object then we call first
call validate on every slot in the c-value, then continue validating
this object.

2) if a web-form's c-value is text (or a list of strings) we can simply
validate the text.

This _should_ be enough to create generic "data-entry" forms, reuse
form processing logic in multiple places, and at the same time allow
fine grained control (and rendering) where it's needed. Of course,
there'll have to be a few "built-in" form classes for the simple input
tags (text, textarea, select/option, file, etc.) and for simple
collections of objects (list, indexed/ordered list, key indexed list,
etc.)

Is this really enough to cover all the cases?

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen