A Case Study: Mozquito Factory and FML

The reality for Web programmers today is that browser manufacturers have made it nearly impossible to develop highly interactive Web sites that also make use of the latest and greatest in Web technologies. For instance, in order to create a dynamic form that enables users to toggle between screens, edit pull-down menus, and calculate values on the fly, a programmer must first code the application using several JavaScript functions. Then that programmer has to go back through the program and debug it until it works on all DHTML-supporting versions of Netscape and Internet Explorer. Next, a second-round of tests must ensure the program runs on all Macintosh and Windows versions of both browsers.

Once the application is complete, the programmer must create a backend CGI script that confirms the user has filled in all the mandatory data fields when the form is submitted. This is not a pretty picture – especially for Web authors who haven't had time to learn basic JavaScript, let alone how to make sure what they produce doesn't shut out half their user base. This is where Mozquito.com's Mozquito Factory comes in. Developers can design and create dynamic forms using an extension of XHTML 1.0 called Forms Markup Language (FML).

The Mozquito Factory Approach Sounds a little too simple doesn't it? You may wonder how an extension to a relatively new standard would work in existing browsers if none of them even correctly support XML or XHTML. When developing your page in the easy-to-use FML, simply clicking a button in Mozquito Factory converts the FML into DHTML that any browser supporting JavaScript 1.2 understands. In the meantime, this solution enables you to use a soon-to-be standard now and – once browsers have the full support necessary to handle this iteration of XHTML – you can use your FML documents as they are.

One of the issues with HTML forms is that they haven't been modified since HTML 2.0 was released in 1995. Everything done with forms since then has been the result of creative Web developers utilizing DHTML, JavaScript, PHP, and CGI scripts, among other tools. With Mozquito, working with forms using a markup language gets a kick-start. While it was created first, FML is in compliance with the W3C XForms standard currently under development. As XForms matures, so does Mozquito's handling of it. FML fulfills many of the current requirements for XForms, including those found in the W3C Working Draft, "XForms Requirements." When XForms reaches full-fledged standard status, FML 2.0 will be 100 percent compliant. What I hope to cover in this article includes an introduction on how to use Mozquito Factory and an indepth look at FML, including content validation, input reuse, on-the-fly calculation, and editable select lists. I do all this using an example of an online order form similar to what you might find on any ecommerce site today.

Using Mozquito Factory Before you dive into FML and start making your first form, work on getting a grasp on Mozquito Factory and how to use its various features. This will be important later when you use it as your FML authoring tool. When you think of Mozquito Factory, picture it as having three separate functions:

1.The XHTML Validator.

2.The Mozquito Engine. This segment takes the XHTML-FML you author and converts it into an HTML document with a JavaScript application. Be sure to take a look at one of the HTML sources of the resulting document throughout the authoring process. It gives you a good idea of the amount of JavaScript you would have to learn in order to accomplish what the FML does.

3.The Editor. This is a simple Java-based application in which you type in your XHTML-FML and it brings the Validator and Engine together, enabling you to use all three functions.

Note Keep in mind that if you're more comfortable using your preferred HTML editor to author your HTML, convert it to XHTML, and add in your FML, then by all means take that route. You still need to use Mozquito to validate your XHTML-FML before you run the conversion process. Conceivably, Mozquito may show up in your favorite authoring tool in the form of a plug-in or bundled as a separate application. If you choose this route, you can open up the template discussed next in your own editor. It appears in the "templates" subdirectory in whatever directory Mozquito is installed. The file you want to open is template1.xhtml.

When to use Mozquito in your Web development Don't use XHTML-FML for every page on your Web site. Its primary purpose is to add more interactivity to forms whether they are a simple feedback form, a questionnaire, a registration form for an event, or a standard "shopping cart" form. If you already use JavaScript in some of your projects, you may also discover (through the following example) that you can also substitute XHTML-FML for DHTML layers. When Mozquito Factory converts the XHTML-FML to JavaScript, only users with certain browsers will be able to view your dynamic content. People using older browsers or with disabilities won't be able to make use of what you produce. With Web accessibility becoming more of an issue for Web developers, it will be important to tweak the resulting Mozquito HTML. Be sure to read the section at the end of this article on Web accessibility to find out how, within the same HTML file that your Mozquito-produced JavaScript is, you can create a duplicate version of your FML form in universally accessible HTML.

Downloading and installing Mozquito

Before you can actually use Mozquito Factory, you have to download and install it. Go to the Mozquito Web site at http://www.mozquito.com, click Download, and make sure you follow the instructions for the "30-day trial version." If you find out you like the Mozquito Factory authoring environment after working with the demo, you can always go back to the Web site and purchase it. Because Mozquito Factory is Java-based software, you also need to download a Java Runtime Environment (JRE) or a software program that will allow you to run Java applications. For Windows 95, 98, 2000, and NT, a JRE is automatically downloaded as part of the Internet Explorer 5.0 browser package. However, the folks at Mozquito.com recommend using the JRE 1.1.7 or higher from either IBM (http://www6.software.ibm.com/dl/dkw/dkre-p) or Sun Microsystems (http://java.sun.com/products/jdk/1.1/jre/download-jre-windows.html). To run Mozquito on a Macintosh system, you need to download and install the MacOS Runtime for Java (MRJ). Be sure you get at least version 2.1.4 or newer to prevent any problems when running Mozquito. Your system should be running MRJ already. If it isn't, you can find a copy at Apple's Java Web site (http://www.apple.com/java).

Feel free to explore this mini-tutorial if you want, although I cover everything in it step-by-step throughout this article. When you're ready to get started, click OK and continue reading the article. Let's get to know a little bit about using Mozquito so you can get started on the example. Create your first "new" document by clicking the File menu and choosing New (or File→New). Notice you now have the choice of several documents including XHTML-FML and the three XHTML 1.0 DTDs: strict, transitional, and frameset

Pushing your FML through to a browser In its current state, pushing the FML shell through a browser results in a blank page in the browser window. In order to test the Mozquito "Display in Default Browser" function, you need to add in some XHTML:

   <body>
   <h1>My first test page for  using FML in Mozquito Factory</h1>
   <p>This is a test..a test of  the Emergency XHTML Broadcast system.<br />
   If this were a real emergency, your  browser would explode and chaos would ensue.</p>
   <hr />
 

Note Make sure your document is both well formed and valid before you push it through to the browser. Otherwise, Mozquito Factory adds an error message to your JavaScript that is the only thing to display when your document appears in the browser. If you want to have Mozquito double check this before any exporting of your XHTML-FML, you can set this in the Edit®Options window under the Settings tab. Make sure "Check validity on export" is checked before you click OK. If at any point you'd rather not preview your XHTML-FML in a browser but would like to just convert it to the HTML file for later use, go to File→Export, name your file with an .html extension, and click Export.

In order to work with FML, you must choose the XHTML-FML selection for your first document. After you make your selection, the structure for a basic XHTML-FML document appears in the Mozquito Editor window. Notice the DOCTYPE declaration contains information for an XHTML-FML 1.0 document as shown here:

   <!DOCTYPE html PUBLIC  "-//OVERFLOW//DTD XHTML-FML 1.0//EN"
 "http://www.mozquito.org/dtd/xhtml-fml1.dtd">

In addition to the XHTML namespace, the HTML element contains a reference to the FML namespace:

   xmlns:x="http://www.mozquito.org/xhtml-fml"

This means that the Forms Markup Language namespace is now available for use in the document using the prefix x: for each element.

Error-checking your XHTML-FML Even though you barely have a shell of a document, you can still check for its well-formedness andYou can also automatically validate and convert your XHTML-FML files without the Mozquito Factory Editor even running. When Mozquito Factory originally installs on Windows machines, it automatically associates itself with any .xhtml file on your system. Provided you haven't modified that association, double-clicking any .xhtml file pushes it through the Mozquito Engine, verifies its well-formedness and validity, converts it to HTML and JavaScript, displays it in your browser, and places a copy of the HTML file in the same directory as your XHTML-FML document.

Note Mozquito.com also has a server-side solution called Chameleon that does the validation and conversion process on the fly. If all you want to do in your authoring process is create XHTML-FML files, run Chameleon on your server instead of manually converting your documents every time you make a change. Here's the code you should see:

   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//OVERFLOW//DTD  XHTML-FML 1.0//EN"
   "http://www.mozquito.org/dtd/xhtml-fml1.dtd">
   <html  xmlns="http://www.w3.org/1999/xhtml"
   xmlns:x="http://www.mozquito.org/xhtml-fml">
   <head>
   <title>Untitled</title>
   <meta name="generator"  content="Mozquito Factory 1.2" />
   </head>
   <body>
   <x:form>
   ...
   </x:form>
 </body>
 </html>

Remember from earlier in the article the discussion on the use of the FML DTD in the DOCTYPE declaration and the FML namespace. Notice that your first FML element <x:form> makes use of this namespace. This eventually becomes your order form with two parts. First, I guide you through the basics of FML by creating the contact information form. Then you move on to some of the more complex features of FML by authoring the shopping cart segment of the form.

A simple contact information form The FML element you need to learn first (<x:form>) is already in place. Notice that the FML form container almost identically matches its HTML 4.01 counterpart, with the exception that it utilizes the FML namespace prefix. Also notice that most of the form components for FML are very similar to HTML 4.01, which enables you to learn this markup language quickly. The next FML element you use is the text input box, or <x:textinput>. If you were doing this in HTML, it would read <input type="text">. As you go through this example and learn the basic FML elements, remember their HTML counterparts. You need them when you get to the section about Web accessibility. Now let's give it an ID of name. This labels the text-input box; if it gets called by other parts of the form, it knows which text box the form wants.

   <x:form>
   Name:
   <x:textinput id="name"  /><br />
   </x:form>
   <x:  textinput>
 

Note You will have several different iterations of this form, so you may want to split it into separate files and bring them together at the end. One file will contain the contact information and the other will have the catalog. Let's add the size attribute with a value of 30. As in HTML, the size attribute determines the approximate size of the input box. Next, let's add a second <x:textinput> element with an ID of email.

   <x:form>
   Name:
   <x:textinput id="name"  size="30" /><br />
   E-Mail:
   <x:textinput id="email"  size="30" /><br />
   </x:form>
 

Caution In most browsers, the number of characters that can fit in a text input box is based on the fixed-width Courier font. If you define a different font, either with a style sheet or by other means, you may not be able to fit the same number of characters as defined by the size attribute.

Input validation All you can do with your form at this point is enter information into the text boxes. This is an ideal point to have some sort of mechanism for verifying the format of the typed information. Normally this is done with complex JavaScripting. You also can accomplish this with the CGI script that handles form postprocessing after you click the Submit button. With the flexibility of FML, you can do this with two attributes in the <x:textinput> element called ctype (content type) and validation. All content type elements function in <x:textinput> as follows:

 <x:textinput id="email"  size="30" ctype="email"> :

The validation attribute enables you to choose between two types of validation: strict or loose. If you choose strict, then whatever the user typed previously into the field is deleted and the user either has to type it correctly or leave the field blank. Choosing loose validation leaves whatever data was in the box and sends a "friendly warning" to the user, enabling him or her to proceed without having to fix the format of the input. Let's add input validation to the e-mail input box:

   <x:form>
   Name:
   <x:textinput id="name"  size="30" /><br />
   E-Mail:
   <x:textinput id="email"  size="30" ctype="email" validation="strict"  /><br />
 </x:form>

Now push this through to your browser so you can test what happens. Once the modified form is opened in your browser, fill out the email field with text that doesn't resemble an e-mail address at all. Close the error box by clicking OK. Notice that whatever you typed into the e-mail box has disappeared. The cursor should be blinking in the e-mail box, awaiting you to reenter something correct. The ctype email looks for the following required features when verifying a correct e-mail address:

- An @ sign

- One or more alphanumeric characters before the @ sign

- One or more alphanumeric characters after the @ sign

- A dot: "."

- After the dot, two or more alphabetic characters

Note While it is possible to verify the format of an e-mail address, it is difficult to verify whether the e-mail actually exists. Normally, you could do this by sending a vrfy query to the SMTP server set up to handle that particular e-mail address. However the vrfy command is also seen as a way for spammers to verify, obtain, and catalogue e-mail addresses using a preprogrammed dictionary. In effect, it is often disabled.

Submitting forms Now you run a test to see how functional your form is and add the FML tags that enable the user to submit your form after they've filled it out. There are four things you currently need to add to your markup to enable you to send the form. First, you need to give the form itself an ID. Do this by adding the id attribute with a value of contactform to the <x:form> element:

 <x:form id="contactform">

Next you need to give the form a location to which it can send its data. This means you need to add the action attribute to your <x:form> element. You have not learned yet how to write a script to parse the form values that a Mozquito Factory form produces, so use an echo script located at Mozquito.com for the value of the action attribute. This preexisting script echoes the input from the various form fields to tell you that the form was submitted correctly.

 <x:form  id="contactform" action=" http://www.mozquito.org/servlets/Echo">

The next step in preparing your form for submission is to add another attribute to each of your <x:textinput> elements. The send attribute tells Mozquito whether the input in that particular box should be sent when the form is submitted. Input is not automatically sent by default. You need to add the send attribute with a value of yes if you want a particular field's data sent. The reasoning behind having to designate what data is sent and what is not lies in the fact that many of the features in an FML form may be used for navigational purposes only. In this case, there is no reason to submit such data along with the form. Consequently, it is important for you to indicate which input box's data to send. In order to submit your form, you need to create a button for users to click that sends the form off to wherever the action attribute points. So add the <x:button> element:

 <x:button value="Submit  Form">

The value attribute of the button element contains the text that appears on the button when the FML pops up in the browser. This element is similar to the HTML 4.01 counterparts of <button> and <input type="button">. Using the event handler attribute onclick, tell Mozquito what you want to happen when the button is clicked. Set the value of onclick to submit:contactform. This tells Mozquito that when the button is clicked, it should do whatever the action the form element with the ID of contactform says to do. <x:button value="Submit Form" onclick="submit:contactform">

Note This becomes very useful when you have a document with multiple forms as choices. Once the user selects a form, you can set up the rest of the document so only that particular form is submitted.

Caution In HTML, it is commonplace to use the event handler "onClick" instead of "onclick." Make sure all tags and attributes are lowercase including JavaScript handlers like onclick. Here's what your form looks like in its full FML glory:

   <x:form id="contactform"  action="http://www.mozquito.org/servlets/Echo">
   Name:
   <x:textinput id="name"  size="30" send="yes" /><br />
   E-Mail:
   <x:textinput id="email"  size="30" ctype="email" validation="strict"  send="yes" /><br />
   <x:button value="Submit"  onclick="submit:contactform" />
   </x:form>