Write XForms that work across browsers

A starter guide on getting it to work

Learn how XHTML and XForms documents should be hosted and written to ensure that your end users have the best experience with your XForms-based applications.

Share:

Steve K Speicher (sspeiche@us.ibm.com), Senior Software Engineer, EMC

Steve Speicher is an IBM Senior Software Engineer working on emerging standards, both infrastructure based and industry verticals (healthcare). He is a member of the W3C Compound Document Formats Working Group, he led the development of the Compound XML Document Toolkit, and he uses Model-Driven Development (MDD) to improve the development of standards. He has previously worked on change and release management tools in the Rational division and in IBM internal tools.


developerWorks Contributing author
        level

02 October 2007

Also available in Chinese

Introduction

XForms is intended to be used embedded within other markup. The most widely used, and the focus of this article, is within XHTML. There is a need to write your XHTML documents following some guidelines to ensure a smooth experience of a variety of browsers like Microsoft's® Internet Explorer, Mozilla's Firefox, X-Smiles, and Opera, to name some. As of this writing, the only desktop browser that natively supports XForms is X-Smiles. Therefore, an add-on, or sometimes referred to as a plugin, is needed for a browser to process the XForms content. There are also solutions that convert XForms markup to ECMAScript and HTML, which are more widely supported in deployed browsers. See the resources for more information.

Though this article attempts to show a thorough solution for a variety of deployment configurations, not all scenarios and configurations can be covered. As new versions of browsers and XForms processors are released, as well as standards support, the solutions outlined in this article may no longer be valid. The approach to solving this is done in a way to isolate these changes so that changes can be localized and broadly distributed.

What are XForms?

The W3C has developed the XForms standard for the presentation and collection of form data. As stated in the W3C Recommendation, XForms is intended to be "the next generation of forms for the Web." XForms provides a number of advantages over existing HTML forms technology. As the Recommendation itself declares, "By splitting traditional XHTML forms into three parts -- XForms model, instance data, and user interface -- it separates presentation from content, allows reuse, gives strong typing -- reducing the number of round-trips to the server, as well as offering device independence and a reduced need for scripting."

XForms documents feature a data model that contains one or more XML instance documents. The form manipulates such an instance document and provides for the submission of that XML to a back-end system.

XForms achieved a significant milestone with the release of the second edition of the XForms 1.0 specification in March of 2006.

Guidelines for serving content

Next there are certain considerations when hosting form documents from Web servers that need to be addressed. This depends directly on what your deployment environment will look like. I'll outline some possibilities in the table below:

Table 1. Some browser and XForms processor options
BrowserXForms Processor
Mozilla FirefoxMozilla XForms
FormFace
Microsoft Internet ExplorerformPlayer
MozzIE
FormFaces
X-SmilesN/A
OperaFormFaces
Apple SafariFormFaces

As you can see, it can get complicated based on your choices. There are also possibilities for using server-side processors, like Chiba, that could work across all these browser platforms. I've also intentionally left off operating systems supported, which is another dimension to consider.

There are advantages and disadvantages to picking one deployment configuration over another. This article is not intended to touch on those but to leave that to you to determine based on your specific needs. This article is intended to focus on building XHTML + XForms content so that the content can be used with most of the configurations outlined above.

Let's take this deployment scenario for the purposes of this article:

  • Mozilla Firefox with Mozilla XForms
  • Microsoft Internet Explorer with formsPlayer
  • X-Smiles
  • All others will use FormFaces

In order to ensure this works, there are two requirements on the server side:

  1. Firefox requires the content to be served with the HTTP response header content type with a value of application/xhtml+xml. To be technically accurate, it simply needs a content type that invokes its "standards" rendering mode. See the resources for more information on Firefox rendering.
  2. Internet Explorer requires the content to be served with HTTP response header Content-type with values of text/html or application/xhtml+xml. See the resources for more information on Internet Explorer's handling of content types.

Disclaimer: There are a variety of configuration parameters that are possible on different versions of Internet Explorer, and I'm sure there are combinations that will not work. See the resources for more details.

In order to serve your content from a Web server such as Apache Tomcat, simply update the web.xml configuration file as such:

Listing 1. Apache Tomcat web.xml configuration file
<mime-mapping>
  <extension>html</extension>
  <mime-type>application/xhtml+xml</mime-type>
</mime-mapping>

There are many other ways to set the Content-type header; it just depends on your Web server. To change the header from a Java™ Servlet, do the following:

Listing 2. Java Servlet setting HTTP header Content-type
protected void doPost(HttpServletRequest request,
    HttpServletResponse response) throws ServletException, IOException {
 // Logic to determine which content type goes here...
   response.setContentType("application/xhtml+xml");
}

To help better understand possible configurations and requirements, see Table 2, below, for how content should be served:

Table 2. HTTP Content-type header settings
ClientContent-type(s)
Firefox + Moz XFormsapplication/xhtml+xml
application/xml
application/___+xml (any +xml)
IE + formsPlayerformPlayer
MozzIE
FormFaces
IE + MozzIEapplication/xhtml+xml
X-Smilesapplication/xhtml+xml
Opera + FormFacestext/html
application/xhtml
application/xml
application/___+xml (any +xml)
Safari + FormFacestext/html
application/xhtml
application/xml
application/___+xml (any +xml)

Guidelines for authoring content

Guideline 1: Use XHTML's namespace as the default namespace

If you plan on using Microsoft Internet Explorer with a browser add-on like formsPlayer or FormFaces, you'll need to author your XHTML so that its default XML namespace is that of XHTML. Why is this? Internet Explorer doesn't support XHTML, but you can use the HTML processor by making sure you use valid HTML tag names and no XML namespace prefixes. See the example below in Listing 3 for an example of this.

Listing 3. XHTML with default XML namespace
<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml"...more namespace declarations go here...>
  <head>
    ...head contents go here...
  </head>
  <body>
    ...body contents go here...
  </body>
</html>

Hint:: Using a schema validator and schema-assisted editor will ease with developing well-formed and valid XHTML+XForms content. See the resources for more information.

Guideline 2: Add XML namespace declarations to XForms instances

Because of some of the limitations with providing XML within HTML, it is necessary to repeat certain namespace declarations on the XForms instance element. It will depend on what features you use and what namespaces your instances use. Namely these are the namespaces used for the XML instance, the XSI prefix (XML Schema instance) and XSD prefix (XML Schema). Keep this in mind if there are issues with some of your forms.

Handling activation and installation of XForms processors

In this section I'll outline a simple ECMAScript that can be included in all your XHTML files to perform appropriate checks and take your defined action. The script will be called xforms-check.js. Using this technique, form authoring becomes very simple. It only requires following the guidelines outlined in this article and included in the script download.

So updating the sample we have above to include the script, it now becomes:

Listing 4. XHTML with browser check
#
     

<?xml version="1.0"?>
<html xmlns="http://www.w3.org/1999/xhtml"
   ...more namespace declarations go here....>
  <head>
  <script src="xforms-check.js"></script>
    ...more head content go here...
  </head>
  <body>
    ...body contents go here..
  </body>
</html>

NOTE: Before diving into the details of the client-side ECMAScript that is used, a disclaimer about how the script determines which browser is used. Most sites have scripts or guidelines for determining this. The scripts below take a very simple approach to identifying the browser by just testing against navigator.appName.

Now we'll look at each individual browser and what is need to activate the processor. In some cases, we'll even go as far as installing the plug-in if it isn't installed.

Mozilla Firefox

First, let's start with Mozilla Firefox. Here is the portion needed:

Listing 5. Browser check for Firefox
  if (isFirefox()) {
    if (hasMozXForms()) { message('Firefox: XForms add-on is installed'); return; }
    
    var xpi ='';
    var rel = '0.8';
    var relName='Mozilla XForms ' + rel + ' Release Extension';

    var relURL='...';
    if (navigator.platform == 'Win32') {
      xpi={relName : relURL + '_win.xpi'};
    } else if (navigator.platform == 'Linux') {
      xpi={relName : relURL + '_linux.xpi'};
    } else if (navigator.platform == 'MacOSX') {
      xpi={relName : relURL + 'macosx.xpi'};
    }
    /* If appropriate platform, start the installer. Let the
      installer handle browser version checks. */
    if (xpi != '') { 
      message('Firefox: Installing XForms add-on...');
      InstallTrigger.install(xpi); 
    } else { 
      alert('Firefox: Mozilla XForms not available for your browser platform');
    }

First a browser test is performed for Firefox, and next there is a check to see if the Mozilla XForms add-on is already installed. If it is installed, we have nothing else to do so we return; otherwise, we invoke the installer with the appropriate plug-in XPI for XForms.

Microsoft Internet Explorer

Next we'll check for Internet Explorer and enable formsPlayer as such:

Listing 6. Browser check for Internet Explorer
} else if (isIE()) {
  var useFormsPlayer = 1;
  if (useFormsPlayer) {
    /* No need to test for formsPlayer, below code will handle */
    var classId="CLSID:4D0ABA11-C5F0-4478-991A-375C4B648F58";
    var fpCab="http://www.formsplayer.com/download/download/cab/formsPlayer.cab";
	  document.write('<object classid="'+classId+
      '" height="0" id="formsPlayer"'+
      'width="0" codebase="'+fpCab+
      '" ><b>formsPlayer has failed to load!'+
      ' Please check your installation.</b></object>'+
      '<?import namespace="xforms"'+
      ' implementation="#formsPlayer"?>');
	  message('IE: Enabling formsPlayer,'+
      ' may see additional messages if installation is needed.');
  } else {
    ... 
  }

In order to activate formsPlayer, an <object> must be used to link the CLSID to the application in the local Windows® registry. We can cause the installation of the plug-in by referencing the formsPlayer cabinet file.

See the resources for specifics on enabling formsPlayer.

Opera and Safari

Based on our deployment configuration, FormFaces will be used when the browser is either Opera or Safari. To do this, a check is made for the appName and then the formsfaces.js implementation is included into the HTML DOM. Then instead of xforms-check.js being referenced, FormFaces.js is referenced. Below shows how the <script> is dynamically added to accomplish this:

Listing 7. Browser check for Opera and Safari
} else if (isOpera() || isSafari()) {
  message('Opera/Safari: Enabling FormFaces');
  var script = document.createElement('script');
  script.src = 'FormFaces/formfaces.js'; /* Wherever FormFaces is installed */
  script.type =  'text/javascript';
  var head = document.getElementsByTagName('head')[0];
  head.appendChild(script);

X-Smiles

Since X-Smiles supports XForms natively, by default we'll provide the user an alert or other corrective action such as:

Listing 8. Browser check for X-Smiles
} else if (isXSmiles()) {
  message('XSmiles: Builtin XForms support, no action taken.');

alphaWorks XML Forms generator

If you're a user of this IBM® alphaWork's toolset, you'll realize part of this article documented some of what the action "Convert for XForms Renderer->" does. It can simply change the default namespace and remove namespace prefixes and lastly add the "xforms-check.js" script. This tool is great also for developing XForms applications. See the resources for more information.

Conclusion

This article has shown that by taking a few steps in authoring and hosting, it is possible to create XForms-based Web pages that can not only work across browsers but can also install necessary add-ons as needed.

Perhaps there will soon be a day when these browsers support XForms and XHTML natively, therefore simplifying the consumption of these Web applications by end users.


Download

DescriptionNameSize
XHTML, XForms, and JavaScript simple samplecross_browser_xforms.zip3KB

Resources

Learn

Get products and technologies

  • Mozilla XForms: Render your standards-compliant forms in Mozilla Firefox using this plug-in.
  • MozzIE: an open-source plug-in that allows you to render XForms in Internet Explorer.
  • FormsPlayer: a plug-in for Internet Explorer that renders XForms.
  • X-Smiles: an open-source browser that natively supports XForms.
  • Opera: a standards-based browser from Opera.
  • Apple Safari: a standards-based browser from Apple.
  • Chiba: a server-side XForms processor.
  • FormFaces: a browser-based XForms processor utilizing JavaScript.
  • XML Forms Generator: Create functional, standards-compliant forms with a click of the mouse using this Eclipse-based tool from alphaWorks.
  • Visual XForms Designer: Check out the home page, with links to installation instructions, prerequisites, and the forum.
  • Compound XML Document Toolkit: Explore other open-standard XML markups, including Scalable Vector Graphics (SVG), MathML, VoiceXML, and Synchronized Multimedia Integration Language (SMIL).

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into XML on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=XML, Web development
ArticleID=259196
ArticleTitle=Write XForms that work across browsers
publish-date=10022007