Preliminary Discussion of Goals

I've begun to write up a set of things I'd like to be able to do with an AJAX enhanced form framework. This is by no means complete, so check back for updates.

Last updated: Wednesday 25th of April.


Use Cases for AJAX form framework
=================================

General Goal
------------

The general goal is to speed up the users ability to work with a web application. The smaller the amount of data transfered between server and client, the faster the user can perform tasks. Since lots of data transfered between client and server is duplicated, there is a lot of room for improvements.

Validation
----------

Some form validation can be done with javascript before the data is ever submitted to the server. Some examples would include data input for:

- numerical fields
- date fields
- choice fields (assuming they aren't using select elements).

One goal we should consider is implementing form validation in javascript for the simpler field types (those listed above). We will also want the ability to hook widgets up to custom javascript validators. So before a form gets submitted to the server, all widgets that have javascript validators, call the validators first.
The javascript validators should not replace the validators on the server side, to avoid problems with clients that do not support javascript. The overhead of validating input data twice will still be much less than the overhead of sending a whole error page to the client.

note: some widgets might do validation directly rather than through some other function that gets called on data submission. For example, a numerical input field might by a text input where the text turns red when the data in the field is not a number. This is the sort of thing where the "validator" would be called as the user types in the input field.

Unification of Display and Edit fields
--------------------------------------

When a user wishes to only change one attribute of an object, it can be cumbersome to load the entire edit form for the object. Since edit forms are generally accessed by first navigating to a display form, it would be beneficial if display forms could act as edit forms. Specifically, I see this working with widget switching, where a
display widget is switched to an edit widget. In this case there are two possibilities.

1. In the case that simple fields are being used, such as text
fields, modifying a simple display widget into a simple edit
widget is trivial and can be done entirely with javascript.

2. In the case of more complicated widget fields, for which there
are no javascript based renderers, a javascript function would
request the edit widget from the server via AJAX.

Wrapping Sub Forms in AJAX
--------------------------

When working with complex data input systems, it is sometimes the case that there are sub forms within a larger form. For example, we might have some kind of nested tree data structure where we wish to edit individual nodes within the tree. In a case like this, forms are recursively generated for each node and its children in the tree. Here the distinction between a widget and a sub form becomes vague. We may choose to define a widget that displays/edits a node or we may choose to define a sub form that displays/edits the node. Either method would work but the implementations would be slightly different.

I would like the ability to wrap a sub form in a widget. This way it would be possible to take existing sub forms and modify their data submission actions through javascript to funnel them into an ajax based data submission function. Here is how it might work.

1. Form object iterates through all widgets
2. One of the widgets links to a SubForm object.
- SubForm fields are not wrapped in form tags (i think that is the
only distinction between sub forms and regular forms)
3. Widget renders subform
4. js associated with widget parses subform html looking for
<input type="submit"> tags.
5. js modifies DOM to replace submit input elements with button elements
and hooks buttons up to a special handler
6. user clicks on button, handler is called
7. handler gathers all the data from the subforms fields and packages them
into a json-rpc request
8. Request is sent to json-rpc view on server that corresponds to the
wrapper widget
9. wrapper widget creates subform view, passing it input data.
10. subform view performs data conversion and validation, generating a
new html form (which might have error messages)
11. json-rpc view for widget sends back json message containing
subforms newly generated html
12. js handler replaces old widget with new widget that contains
updated subform.

In this scenario, the subform machinery is totally unaware that anything is different. But on the user side, the subform is submitted and regenerated without a page reload.