(Note: A demo version of this is available to play with in my example site. The directory is open, so you can examine the separate pieces.)

In my latest web project, I’ve been working on a set of forms for user registration and information. No great shakes there, of course, but, as I was working through it, I realized a couple of things I wanted to have:

• I wanted to disambiguate some of the input entries on the form – some are not relevant, unless the user checks an option.
• In a ‘history’ table, I wanted to dynamically add static rows as the user entered information, and I wanted the rows sorted in reverse by time, and I wanted the entries to be editable after the fact, including the time entries.

Initially, this suggested an AJAX solution, and I started going in that direction.

Not Necessarily AJAX

As I proceeded into the implementation, I realized I don’t really care about intermediate results – the user can edit his brains out for three days straight, for all I care. The only thing I’m interested in is the end result.

Sensibilities vary in this regard: Some schools of thought advocate controlling everything from the server. Others advocate controlling as much as possible from the client – at least the display portions.

For this project, I fall very much on the latter side. I’d rather do as much as possible in the user’s browser. For one thing, this saves bandwidth and server load, which, for me, is a limited resource.

The Implementation

I’ve divided the demo into three sections. The first two deal with restricting available choices:

Section One:

This takes the approach that what the user doesn’t see, he can’t enter. Irrelevant inputs are simply not existent until the user pushes the controlling option.

This works, but the result is that other elements on the form can jump as the form re-lays itself out to accommodate the new pieces or the removed pieces.

Section Two:

This takes the approach that the input elements should always be visible, but are inaccessible (when not relevant) via a disabling mechanism. They are grayed out to reflect their status.

The first makes sense for large blocks of controls, such as a choice of payment schemes. A PayPal vs. Credit Card scheme, for example.

The second makes more sense for small groups of controls, and reflects more what a user might expect in an application.

Interactive Table

The last section is the interactive table input. The first row is an input row. When the ‘Add’ button is clicked, a static row of information is added to the table. The rows are dynamically inserted in reverse order, by date – much as you would expect a resume or medical history.

Finally, I wanted the rows to be editable. The first approach was to provide an ‘Edit’ button for each row: clicking on this removed the row and put the data back into the input row, which the user could edit and then re-add via the ‘Add’ button.

That worked, and it was a good intermediate solution, but I wanted a better solution: I’d rather have the row editable in-situ.

This led to the final implementation: the user can now click on a static cell, and the content is temporarily replaced by an appropriate control set to the current contents. The user can edit, and when the control loses focus, it is removed from the cell and the static contents updated.

This works pretty well (tested on the latest versions of IE, FireFox, and Safari.) It could be prettied up some more (likely will be in the final implementation). One concern is that the rest of the contents of the form will jump as rows are added and removed. I think this can be addressed by setting the static part of the table to a fixed size and allowing it to scroll.

Next: Data in, Data out – a bit of AJAX to help the demo.