Well, I’ve upgraded my FreeBSD server and everything is back in order, including a new version of WordPress.

And, I’ve reinstated the comments mechanism (restored the DB table) and installed the reCaptcha mechanism. So far, so good – spam appears to be throttled, but not completely eliminated.

At least it’s manageable.

On AJAX

I’m kind of mystified why so many sites haven’t incorporated AJAX – a lot of really big sites still do a full page refresh when something is updated. I can’t attribute it to ignorance, so it must be … dare I say … laziness?

Some notes on my approach to AJAX:

1. A lot of the AJAX libraries descend into baroque-ness, normally pointed toward updating parts of the page with HTML snippets. The MS implementation seems to be the worst offender. This seems like a bad idea, to me.
2. To maintain presentation/logic separation we like so much in architecture circles, you don’t want to be passing UI stuff over the wire – the only possible exception is if you’re creating all of your UI on the wire (which strikes me as prime fodder for loading up the server, so I don’t like to do that, anyway…)
3. JSON is the lingua-franca of AJAX, not HTML. Better to pass JSON-encoded data back and forth and let the server and the client handle their ends appropriately. I’m a big fan of off-loading as much as possible to the client, anyway. Stuff like forms validation should be done – at least preliminarily – at the client. The client should re-arrange itself based on JSON responses and data.
4. You never know what the next new big thing is. You’re client might be written in JS, now, but tomorrow’s need may likely be Flash, Silverlight, or who knows what? Passing back and forth snippets of JSON and keeping the semantics simple doesn’t break the back-end, or entail hoops trying to support multiple types of clients.
5. There’s nothing better than updating just part of a page. Full page refreshes are jarring.

I’m sure there are exceptions (there always are), but that’s the way things appear to this author, as of this writing.

(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.)

So, in the last post I talked about putting together a form that pretty much handled everything from the client side. In that, the goal was to eliminate as much interaction with the server as possible.

Of course, the server has to interact at some point – we need to get the data to the server, and data back out, since it’s likely the user will want to view his information or edit it in the future.

So, this bit requires a couple of extra pieces and a touch of AJAX just to get things working.

Other Pieces

doneform.php is a PHP file that gives the form a destination. It’s primary function is simple: receive the form output and do something with it. In this case, it does two things:

1. Dump the $_POST array so you can see the values.
2. If data was entered, store it somewhere. If not, clear anything that might have been stored, earlier.

(1) is easy. Just call var_dump on the $_POST array.

(2) is a bit trickier – I need someplace to store the information for subsequent editing. Since I’m reticent to devote database resources to a demo, I’m perfectly happy to use your browser as a data repository: if there is data to be stored, it’s stored in a session cookie (a session cookie is deleted by the browser when the session is ended. i.e., when you shut down your browser.) Valid $_POST information is detected at the top of doneform.php, and the cookie is set with some JSON, or deleted as appropriate. (I’m using the pear HTML_AJAX package for this endeavor.)

Editing

This is the bit of AJAX added – when the form is loaded, it checks with the server to see if there is any data to be used (is this an editing session?). This is done with an AJAX call to form_response.php, which checks for the cookie and retrieves it, if it exists.

If so, the server spits back a bit of JSON with the data (in this case, the cookie contents set earlier), and sets the form contents, accordingly. In addition, it brings up the red “Editing” banner at the top of the page. Other feedback might be nice to indicate to the user that he is editing current data.

Synopsis

This works well for the use I intended. If I were interested in intermediate results, or there was something that needed to be checked with the server before things could proceed, a bit more AJAX-ey approach would be necessary. But, for this usage, I really would rather offload processing to the client as much as possible, and keep bandwidth to an absolute minimum.

Could I have used a .js library? Maybe. I haven’t seen anything that allows manipulation of tables to the degree I’m looking for, here. Kits are always a trade-off – you can do what they expect you to want to do, easily. Doing what they might not expect you to want to do can be a real nightmare, and you’re better off rolling your own.

(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.