|MySQL Conference and Expo April 14-17, 2008, Santa Clara, CA|
Working With Forms: An Introduction03/09/2001
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.
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.
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.
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.
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.