Love Mike G

Another Reason Why IE Ruins My Motivation to Code

Have you ever known something to be true but never really had it sink in until you experience it first hand? For quite some time I’ve known that detecting form submissions on the server side by testing for the presence of a submit button is a bad idea. I just never understood why until today.

Assume a form that requires the use of two submit buttons:

<form action="post_test.php" method="post">
        <input type="text" name="test" />
        <input type="submit" name="submit" value="Edit" />
        <input type="submit" name="submit" value="Delete" />
</form>

This interface pattern is commonplace in content management systems where “Edit” and “Delete” actions are assigned to a large group of items in a record set — especially where batch operations are required (IE: edit/delete multiple records at once). At first glance this doesn’t seem like that big of a deal. Your server-side parser would look similar to the following (of course, the real parsing code would replace the print_r() call):

<?php

if(isset($_POST['submit'])) {
    print_r($_POST);
}

?>

To test this open up a browser fill out the form and hit “Edit”. You should see:

Array
(
    [test] => hi
    [submit] => Edit
)

Similarly if you hit the “Delete” button:

Array
(
    [test] => hi
    [submit] => Delete
)

The headache comes when you don’t use either one of the buttons. Using the Enter key on the keyboard is a well-known technique for form submission used by armatures and well-seasoned computer users alike. It works both on the OS-level as well as within a web browser. In other words, this is a common behavior and should be planned for.

So what happens? Try it out. If you’re on a normal browser, you should see that it accepts the user input, and uses the first submit button it sees to send the data. If you’re using IE, you see something very different: nothing at all. This is because of specific implementation of the conditional used to detect if a form was submitted. It looks specifically for the $_POST['submit'] value that should be passed. However, because you’re using forms improperly, IE punishes you by not allowing a submit element to be passed.

A solution I’ve been using for years is to test to see if $_POST is not empty instead of looking for a specific element.

<?php

if(!empty($_POST)) {
    print_r($_POST);
}

?>

As promised, the form now submits under both browsers. The remaining problem is that IE still doesn’t pass the submit field with the rest of the posted data:

Array
(
    [test] => hi
)

So how do we know whether or not to delete? You can assume that when no submit field is present, a user wants to edit a record instead of deleting it. Really, it’s only one little conditional:

<?php

if(!empty($_POST)) {
    if(!isset($_POST['submit']) {
        $_POST['submit'] = 'Edit';
    }

    print_r($_POST);
}

?>

Sure, it works. But for how long? What happens if the order of the buttons changes to Delete coming first and Edit coming second? Now you have to update your code in two places in order for your application to behave how they expect it to.

Terrible.

This entry was posted on Sunday, July 8th, 2007 at 8:23 pm and is filed under Code, Opinion. Both comments and pings are currently closed.

4 Responses to Another Reason Why IE Ruins My Motivation to Code

Comments are closed. Sorry.