Chapter 13. Form Widgets

This chapter provides systematic coverage of the various dijits that enable you to create fantastic-looking forms with minimal effort. Like everything in Dijit, the controls you'll learn about in this chapter can be defined entirely in markup, require very little JavaScript, and were designed with accessibility considerations in mind. With that said, realize that you're about to embark upon reading a very hefty chapter. The functionality offered by dijit.form is quite intense, packing tons of breadth and depth; the form dijits are by far the most object-oriented widgets in the toolkit, so you'll see deeper inheritance hierarchies via dojo.declare in this chapter than anywhere else in the book.

Drive-By Form Review

While the HTML 4.01 specification (http://www.w3.org/TR/html401/) provides the authoritative specification on forms and is quite worthy of careful reading on its own, this section attempts to summarize some of the most useful content about forms that will help you to get the most out of this chapter. If you're reading this book, a working assumption is that you've designed a form or two, so it is not necessary to belabor fact that a form is a collection of one or more controls that capture information and send it back to a server for processing.

However, it is noteworthy to highlight that the AJAX revolution has really skewed the paradigm of passing data to a server for processing. Previously, data would be submitted to a server handler that broke it into convenient key/value pairs, used these hashes as part of a processing routine, and then returned a new page that somehow reflected these form choices. To make the whole process more elegant, the form might have even been included in an iframe so that the effect of the page reload would be minimized. Now, however, the XMLHttpRequest (XHR) object makes it easy to asynchronously send small chunks of data to a server without an explicit form submission or a page reload of any kind.

Of course, the XHR object, AJAX, and slicker ways of interacting with the user certainly don't make forms obsolete. Forms are still a battle-tested standard; they work even when JavaScript is disabled, and they are important for accessible implementations. In general, it's almost always a good idea to make sure that any fancy way of passing information back to the server is degradable and accessible. In other words, it isn't a matter of "either forms or AJAX"; it's a matter of "both forms and AJAX."

For example, consider Example 13-1, an enhanced version of the plain vanilla form from Chapter 1.

Example 13-1. Simple form

<html>
    <head>
        <title>Register for Spam</title>
        <script type="text/javascript">
            function help(  ) {
                var msg="Basically, we want to sell your info to a 3rd party.";
                alert(msg);
                return false;
            }

            //simple validation
            function validate(  ) {
                var f = document.getElementById("registration_form");

                if (f.first.value == "" || f.last.value == "" || f.email.value
== "") {
                        alert("All fields are required.");
                        return false;
                }

                return true;
            }
        </script>
    <head>
    <body>
        <p>Just Use the form below to sign-up for our great offers:</p>
        <form id="registration_form"
            method="POST"
            onsubmit="javascript:return validate(  )"
            action="http://localhost:8080/register/">

            First Name: <input type="text"  name="first"/><br>
            Last Name: <input type="text" name="last"/><br>
            Your Email: <input type="text" name="email"/><br>
            <button type="submit">Sign Up!</button>
            <button type="reset">Reset</button>
            <button type="button" onclick="javascript:help(  )">Help</button>

        </form>
    </body>
</html>

While as bland as it can possibly get, this form is quite functional, and would behave properly on virtually any browser; the incorporation of a nice CSS stylesheet could make it look quite nice. There's even a Help button to tell the user why the form really exists. On the server side, a simple script would process the form, probably after a web server has already distilled the named fields in the form out of their raw format. A functional CherryPy script might process the form, as in Example 13-2.

Example 13-2. CherryPy script to process a form

import cherrypy
class Content:
    """
    A routine for processing a form submission.
    Named form fields are easily accessible.
    """
    @cherrypy.expose
    def register(self, first=None, last=None, email=None):

        #add user information to evil database here...

        #send back this customized html page
        return """
        <html>
            <head><title>You're now on our spam list!</title></head>
            <body>
                <p>Congratulations %s %s, you're gonna get spammed!</p>
            </body>
        </html>
        """ % (first, last) #substitute in variables

cherrypy.quickstart(Content(  ))

While extremely simple, the previous example did touch on several fundamentals regarding forms:

  • Forms controls should be enclosed in a FORM tag.

  • The FORM tag almost always includes name, method, onsubmit, enctype, and action attributes that provide pertinent information about how the form should be processed.

  • The onsubmit attribute is the standard way of performing client-side validation. Returning false from a validation routine prevents the form from being submitted to the server.

  • The action attribute provides the URL for submitting the form.

  • Form fields that represent meaningful state should include a name attribute, which is what most server-side frameworks will collect into key/value pairs and pass to the specific routine that handles the form submission.

  • Forms are innately accessible with the keyboard; tabs move between fields[24] and the Enter key submits the form. Although not demonstrated, the tabindex attribute can change the default tab order.

  • In general, there are multiple kinds of controls, as specified by the type attribute. This particular example illustrated three different kinds of buttons: one for triggering the onsubmit event, one for resetting the form, and one for handling a custom action.

  • Submitting a form necessarily reloads the page with whatever the server returns if an action attribute is provided in the form. If no action attribute is provided, custom JavaScript or DHTML actions could be taken by attaching scripts to DOM events such as onclick.

Tip

Throughout this chapter, the term "attribute" is frequently used to describe both form attributes and object attributes. The intended usage should be apparent from context and is not anything to get hung up over.

While nowhere near exhaustive, hopefully this brief review sets the stage for a discussion of the various form dijits. For a great desktop reference on HTML forms, consider picking up HTML & XHTML: The Definitive Guide by Chuck Musciano and Bill Kennedy (O'Reilly).


[24] Mac OS X Firefox 2.0+ users may need to download the Configuration Mania add-on at https://addons.mozilla.org/en-US/firefox/addon/4420 to enable tabbing into buttons.

Get Dojo: The Definitive Guide now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial