Aranfoolcaytar

There are several aspects you could judge a good online form by. One of the most important parts is the ease of understanding it, how much time it takes to submit content, and how frustrating it is to make a mistake.

Take, for example, the worst case.

The form contains a multitude of text fields, but they are not clearly labeled to show what should be filled in (nor in what form it should be filled in). Making a mistake results in one of two things: The form is rejected - preferably without any explanation of what mistake precisely you made - and you get the empty form to fill out from scratch. Or, arguably worse, your erroneous content is submitted and published for all to see (or quietly accepted, until some days later you realize that you never actually subscribed to the newsletter.

Now, the best would be the exact opposite. Apart from designing the form itself in a clear and intuitive way, the process of submission should be easy, fool-proof and cope with as few clicks as possible.

AJAX is good with that, but I manage to suck at JavaScript even more than JavaScript itself sucks. And those who use it regularly know that's not easy. So I try different ways.

The last I experimented with is HTTP redirection. The submission page for, say, a Guestbook, doesn't actually do anything besides say that your entry was saved, and would you please wait while you are redirected back to the book. My idea was to cut that part out and go *straight* back to the book - with your newly added entry. For this, I use the HTTP status code 303 - See Other.

There are several redirection codes, for different purposes. 301 permanently redirects a page. 302 does it temporarily. But neither of them is supposed to be respected if you are sending a POST form - which in this case, you are. (Note I say "supposed" - Firefox 2.0 follows 302 without complaints, converting the POST to a GET request counter to the specification.) 303 is meant for exactly those cases where you are submitting a form, and the server wants to redirect you from the form destination to a new page.

In this case, the "new page" is the book itself, which also contains the form.

So I have a guestbook page that lists the entries. The form is out of the way, at the bottom of the page - an anchor link is at the top that allows you to jump right down to the form.

The form is sent to add_entry.php, which verifies it. Now, one of two things happens: Either the post is deemed okay, and is saved in the database.

Then the script redirects thus:Or the post is NOT okay, in which case it redirects back to the same page, but scrolls right downto the form:Of course, we are no better than the worst web form ever if we empty the form without even telling the use what was wrong. But here's one problem: How do you transfer information between these redirects? They're specifically designed not to redirect post requests, so those form contents get dropped in the redirect.

My solution is to transmit them back to the user as a cookie before redirecting.

The full code for the failed form check is therefore:And so on. Note that the redirect doesn't mean cookies are ignored. The browser will save the cookies and *then* follow the redirect. Needless to say, the guestbook.php page must be equipped to fill the cookie contents back into the form.

For good measure, the successful redirect also sets a cookie, saying your message was saved.

Now, in the background, the browser is loading three pages. Firstly, the guestbook page, secondly, the add_entry.php script, and thirdly, the guestbook page again.

But the user has seen only a single page - the main guestbook page. The user fills out the form on this main page, clicks "Submit", and (to his eyes) the same page is loaded again with the post. Or, if there was an error, the page is loaded again with a filled form and an error message.

As content submission forms go, it's convenient. And it copes with a minimum of server or client resource usage - as opposed to the JavaScript, which tends to slow down browsers and potentially crash.

I named it "TinyBook", in part because it also consisted of only two PHP files. Of course, it will grow once any noteworthy features are added, but its core really consists of only two files: The one that reads/displays, and the one that writes. It's primitive. But compared to the third-party scripts I tried before I gave up and started from scratch, it is quite smooth.