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
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.
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.
For example, consider ExampleÂ 13-1, an enhanced version of the plain vanilla form from ChapterÂ 1.
ExampleÂ 13-1.Â Simple form
name="first"/><br> Last Name: <input type="text"
name="last"/><br> Your Email: <input type="text"
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,
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
actionattributes that provide pertinent information about how the form should be processed.
onsubmitattribute is the standard way of performing client-side validation. Returning
falsefrom a validation routine prevents the form from being submitted to the server.
actionattribute provides the URL for submitting the form.
Form fields that represent meaningful state should include a
nameattribute, 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 and the Enter key submits the form. Although not demonstrated, the
tabindexattribute can change the default tab order.
In general, there are multiple kinds of controls, as specified by the
typeattribute. This particular example illustrated three different kinds of buttons: one for triggering the
onsubmitevent, one for resetting the form, and one for handling a custom action.
formnecessarily reloads the page with whatever the server returns if an
actionattribute is provided in the form. If no
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).
 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.