Web DevCenter    
 Published on Web DevCenter (http://www.oreillynet.com/javascript/)
 See this if you're having trouble printing code examples


Essential JavaScript

Working With Forms: An Introduction

03/09/2001

Also in Essential JavaScript:

Extending Dreamweaver: Let Dreamweaver Create Your Menus

Extending Dreamweaver with its JavaScript API

Accessing Dreamweaver's JavaScript API

Creating Themes with CSS and JavaScript

Parsing and DOM-Tree Building With JavaScript

Working With Forms: An Introduction

Forms are an important way to interact with web-site visitors. But, since their introduction in 1993, they have not changed much. From the user's point of view, they still might be good enough, even though they are missing fancier elements like tree controls or sliders. But from the programmer's viewpoint, they generally fall short of their potential.

Related Reading

JavaScript: The Definitive Guide, 4th EditionJavaScript: The Definitive Guide, 4th Edition
By David Flanagan
Table of Contents
Index
Sample Chapter
Full Description

Often one of the missing but highly desired features is form validation. Validating a form means checking all required elements for valid data. An application performing form validation must take care that the form can't be submitted before all the elements are valid. If all preconditions match, a form can be submitted to the server and processed. Unfortunately, this functionality is absent in HTML today.

Using client- and server-side solutions

You have two options where to validate a form; either you choose a client-side or a server-side solution. Any of these has its advantages and limitations. For the final check you really need a server solution, because you can't be sure that the data has not been manipulated. On the other hand, a server solution is also slow and eats up bandwidth.

But, the most important argument for using a client-side solution is simply usability. A form just becomes more usable if the user receives an immediate feedback on his actions, which is one of the most important factors in successful GUI design.

JavaScript owes much of its popularity to this problem. Form components were the first elements of HTML that were exposed to the client through a common document object model. An abstract definition of a document object model was published by the W3C in DOM Level 1, the current recommendation is DOM Level 2. The rapid evolution of XML-based languages and applications influenced the development process, which means that the DOM is not bound to HTML any longer and is designed to work with all XML-based languages.

This is exactly the point for us to start -- when the DOM is not bound to HTML anymore. Why not extend documents by using your own language? But, before we talk about a JavaScript-driven solution, let's have a brief look at what (might) come next.

The next generation - XForms

The W3C noticed the demand for a better and more flexible forms concept. In Spring 2000, the XForms working group came out with their first requirements draft of XForms; the first working draft was published in December 2000.

XForms was designed to serve as a replacement for existing forms. The logic, data, and presentation are separated from each other, thus making XForms independent of a specific implementation or application. The goal is to use XForms as an addition to other languages like SVG, WML, etc. Another important issue is to implement new elements like the already mentioned tree element or a color chooser. If you are interested in more information about XForms, you should visit their home page.

The W3C's mills work slowly however, so we'll most likely be forced to stick to existing HTML forms and their existing elements for quite some time. This gets even worse if you consider how long it takes for a new standard to spread after it has been released.

On the other side, XForms are far more complicated than HTML forms. Even though new languages are being integrated into the Web every day, HTML continues to survive. This is undoubtedly because of its simplicity.

The solution

So, why wait for the heavyweight specs to arrive? As I mentioned before, why not extend forms yourself by creating some pragmatic advances?

The Document Object Model is not another language; it's a tool to work with XML-based languages. It provides an abstract view to a document, no matter in which language it might be coded. Plainly speaking, all the DOM is interested in are nodes and parent-child relations between those nodes. On the other hand, one of XML's basic concepts is interoperability between XML-based languages.

Shaking in a little pinch of JavaScript provides the solution: We are able to define a new language conforming to XML which only consists of a set of attributes and is mixed into the existing HTML pages. These attributes describe the elements, whether they are required, which content type they must have, etc. All we need to make this work is an interpreter that translates the newly defined attributes into already supported functionality after the document has been loaded.

This solution not only has the advantage of separating the logic and the code; it's also much easier to read and remember. But there is also another advantage: Because we code our extensions in a well-defined format, it's easy to translate it into other formats as well. You could create a Perl script, which takes the HTML code of the form and creates a server-driven form validation solution, for example. The day XForms come out, you will be able to translate your existing codes, also.

Next week we'll have a look at the ForX docs, then dive into the implementation details. Plus I'll explain further enhancements to our new project, so stay tuned.

Claus Augusti is O'Reilly Network's JavaScript editor.


Return to the JavaScript DevCenter.

Copyright © 2009 O'Reilly Media, Inc.