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.