Section 14.9. Live Form

14.9. Live Form

Dynamic, Live, Real-Time, Validation

Figure 14-27. Live Form

14.9.1. Goal Story

Tracy is using a Live Form to apply for a new online brokerage account. Upon declaring her place of residence, some additional regulation-related questions specific to her region appear. Several asset classes can be traded. She clicks a box to indicate that she wants to trade in bonds, and further questions specifically for that asset class appear. She then clicks on another box, for options. A moment later, a warning appears that new users can trade in either options or bonds, but not both. After further refinement, she successfully submits the form and sees it fade into a welcome message.

14.9.2. Problem

How can the user submit data as quickly as possible?

14.9.3. Forces

• Most data submission tasks require some flexibility. A particular answer for one item may necessitate further questions. Often, this must occur server side, where business logic and data usually reside.

• Most data submission requires validation. This must occur server side to prevent browser-side manipulation of inputs.

• Users get frustrated waiting for data to be validated and continuously refining data upon each explicit submission.

14.9.4. Solution

Validate and modify a form throughout the entire interaction instead of waiting for an explicit submission. Each significant user event results in some browser-side processing, often leading to an XMLHttpRequest Call. The form may then be modified as a result.

Modifying the form is similar to responding to a Microlink (Chapter 15)there's usually a server call followed by some Page Rearrangement (Chapter 5). Typical modifications include the following:

• New controls appear.

• Controls become disabled.

• Information and error messages appear.

The result is a more interactive form. The user doesn't have to wait for a page reload to find out if a form field is invalid, because it's validated as soon as she enters the value. Due to the asynchronous nature of XMLHttpRequest Call, the validation occurs as a background process while the user continues entering data. If there's an error, the user will find out about it while filling out a field further down on the form. As long as errors don't happen too often, this is no great inconvenience.

Validation doesn't always occur at field level though. Sometimes it's the combination of data that's a problem. This can be handled by checking validation rules only when the user has provided input for all related fields. A validation error can result in a general, form-level error message or a message next to one or more of the offending fields.

A Live Form usually ends with an Explicit Submission (Chapter 10), allowing the user to confirm that everything's valid. Note that unlike a conventional form, the Explicit Submission does not perform a standard HTTP form submission but posts the contents as an XMLHttpRequest Call.

14.9.5. Real-World Examples

14.9.5.1. WPLicense

WPLicense (http://yergler.net/projects/wplicense) is a plugin for the WordPress blogging framework, allowing users to specify a copyright license for their blog content (Figure 14-28). Refer to Cross-Domain Proxy (Chapter 10) for details on the plugin and to the section "Code Example: WPLicense," later in this chapter, for a walkthrough of its Live Search implementation.

Figure 14-28. WPLicense

14.9.5.2. Betfair

Betfair (http://betfair.com) lets the user make a bet using a Live Formone which changes but doesn't actually interact with the server (Figure 14-29). You can try this even as a nonregistered user by opening up a bet from the Drilldown (see earlier in this chapter) menu. There are three columns on the page: the left column shows the current bet topic within the Drilldown, the center column shows odds for all candidates, and the right column shows your stake in the bet. Click on a candidate to make it appear in your stake form, where you can then set the amount for the bet you're placing. As you change your stake, a Status Area shows your total liability. Another column shows your profit with respect to each potential outcome. There are also some "meta" controlse.g., the "Back All" button, which creates an editable row for every candidate.

Figure 14-29. Betfair Live Form

14.9.5.3. MoveableType Comment hack

Simian Design (http://www.simiandesign.com/blog-fu/2005/07/ajax_comments_b.php#comments) is a blog where you can add comments, Ajax style. As you type into the text box, a live preview appears beneath it and takes markup into account. If you click on Preview or Post, the text fades and an animated Progress Indicator (see earlier in this chapter) bar shows that the server is processing. Page Rearrangement then embeds the result in the page.

14.9.6. Code Example: WPLicense

WPLicense (http://yergler.net/projects/wplicense) is a form with a live component. Initially, the "License Type" field simply shows the current license, if any. But when the user clicks on the update link, a new block opens up and a conversation between the browser and server ensues to establish the precise details of the license. (More precisely, the conversation is between the browser and the Creative Commons web site; see the corresponding example in Cross-Domain Proxy (Chapter 10). Each license type has associated questions, so the license options are fetched according to the user's license type selection.

When the user launches the plugin, a PHP function begins by drawing the Live Form. In this case, the form is ultimately submitted as a conventional POST upload, so the form has a conventional declaration:

   <form name="license_options" method="post" action="' . $_SERVER[REQUEST_URI] . '">     ...     <input type="submit" value="save" />     <input type="reset"  value="cancel"  />     ...   </form> 

The current license is shown and loaded with initial values along with the link that triggers the cross-domain mediation to update the license setting:

   <tr><th>Current License:</th><td>     <a href="'.get_option('cc_content_license_uri').'">' .get_option('cc_content_license').'</a>   ... 

The form includes hidden input fields to capture information gleaned during the Ajax interaction. They will be populated by JavaScript event handlers:

   <input name="license_name" type="hidden"           value="'.get_option('cc_content_license').'" /> 

Also, an initially invisible div will be shown once the user decides to change the license. Don't confuse this with the hidden input fieldsthose will never be shown to the user, whereas this just happens to have a hidden style when the page initially loads. Most critically, the div contains a selection field:

   <select > <option >(none)</option>   ...   foreach($license_classes as $key => $l_id) {     echo '<option value="' . $key . '" >' . $l_id . '</option>';   }; // for each...   ...   </select> 

Now for the live part. The licenseClass selector is associated with retrieveQuestions, a function that fetches the questions corresponding to the chosen license. The call is made courtesy of the Sack library (http://twilightuniverse.com/2005/05/sack-of-ajax/), which paints the server's HTML directly onto the license_optionsdiv. When you switch to a new license class, the form automatically shows the questions associated with that class:

     el.onchange = function( ) {       retrieveQuestions( );     } // onchange   function retrieveQuestions( ) {     ajax = new sack(blog_url);     ajax.element='license_options';     ajax.setVar('func', 'questions');     ajax.setVar('class', cmbLC.value); ''Current license passed to server''     ajax.runAJAX( );     ...   } 

The server determines the appropriate questions to ask and outputs them as HTML Messages. (See the section "Code Example: WPLicense" in Cross-Domain Proxy [Chapter 10] for details.)

Now how about those hidden fields? Well, not all the information related to the options is hidden: the license URL is shown to the user, so that also needs to be updated after an option is chosen. Each time the user changes the server-generated options, the server is called to get a bunch of information about the current selection. That information then comes back to the browser, and the callback function updates both the hidden fields and the URL accordingly:

     [Updating the hidden fields]     document.license_options.license_name.value = licenseInfo['name'];     document.license_options.license_uri.value  = licenseInfo['uri'];     document.license_options.license_rdf.value  = licenseInfo['rdf'];     document.license_options.license_html.value = licenseInfo['html'];     [Updating the visible license URL]     href_text = '<a href="' + licenseInfo['uri'] + '">' + licenseInfo['name'] + ' </a>';     document.getElementById("newlicense_name").innerHTML = href_text; 

Now, what, so far, changed on a permanent basis? Well, nothing. Everything so far has served the purpose of setting up the form itself. But that's fine in this case, because the form is submitted in the conventional manner. So as soon as the user clicks on the Submit button, all of those hidden fields will be uploaded and processed as standard HTTP form data.

14.9.7. Related Patterns

14.9.7.1. Microlink

Like Live Form, Microlink (Chapter 15) opens up new content directly on the page. Indeed, a Microlink can be used on a Live Form to open up supporting information.

14.9.7.2. Live Search

Consider including a Live Search (see earlier) when users need to perform a search within the Live Form.

14.9.7.3. Suggestion

Consider offering Suggestions (see earlier) to help users complete fields within the Live Form.

14.9.7.4. Drilldown

Consider including a Drilldown (see earlier) when users need to identify an item within a hierarchy.

14.9.7.5. Progress Indicator

Use a Progress Indicator (see earlier) to show that the server is working to process a field with a Progress Indicator.

14.9.7.6. One-Second Spotlight

Since Live Forms are usually submitted with an XMLHttpRequest Call, a One-Second Spotlight (Chapter 16) effect, such as Fade Out, is a good way to convey that the form has been submitted.