Implications of upgrading from 9.0, which generates HTML, to 9.1, which generates XHTML

Date: Archived
Product/Release: LANSA for the Web
Abstract: Implications of upgrading from 9.0, which generates HTML, to 9.1, which generates XHTML
Submitted By: LANSA Technical Support

After upgrading to LANSA for the Web Version 9.1, you should apply EPC623, which contains some changes to handle XHTML. Please refer to the EPC623 documentation.

Version 9.1 of LANSA for the Web generates XHTML. This document provides guidance concerning the possible impact on existing LANSA Web applications and specific advice regarding upgrade approach.

Please see the LANSA for the Web Guide for details on XHTML.

This document should be read together with:

  • Installing LANSA on iSeries
  • LANSA for the Web Guide

Compatibility LANSA V9.1 versus LANSA V9.0 or earlier:

LANSA for the Web Version 9.1 now generates Web pages in XHTML 1.0 format and must conform to XML syntax rules. This has the following implications:

  • LANSA for the Web applications developed using LANSA Version 9.1 may not work correctly on earlier versions due to issues such as case sensitivity (all XHTML elements are in lower case). If you want to deploy to LANSA systems on version 9.0 or earlier, you should develop your application on a LANSA version 9.0 system.
  • LANSA for the Web applications developed on version 9.0 or earlier can run on version 9.1 unchanged with some possible exceptions – see below.

Impact of XHTML:

Once you upgrade to V9.1 and continue to develop your application, pages will be a mixture of HTML (in pages which have not been recompiled, or from existing components containing HTML) and XHTML. This is not a problem and the browser will interpret the page correctly provided the HTML is "well formed".

XHTML is subject to stricter syntax rules (see LANSA for the Web Guide) and this syntax checking is enabled in the browser (see next comment) if the page contains:

"<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN "">"

The above line is inserted from the special XHTML page DTD_TRANSITIONAL. By removing this line from DTD_TRANSITIONAL you will disable validation of the XHTML in the browser. See "How to avoid the insertion of the DOCTYPE declaration" in the LANSA for the Web Guide for further details. This approach would enable you to avoid any problems due to badly formed existing HTML. However in the long run we recommend that you find and fix any badly formed HTML and re-enable this feature. Current popular browsers (Internet Explorer and Netscape Navigator) do not validate the XHTML page against the DTD when the page is sent as HTML. The option of removing the DTD is more to avoid confusion. If your page is not XHTML compliant, you don't want to include a DOCTYPE declaration, which says that it is.

Recommended Approach to Upgrading to V9.1 LANSA for the Web

If you have separate development and production machines:

  1. Upgrade the development machine to V9.1. Run through your Web application. Either find and fix any badly formed HTML issues or disable validation as above.
  2. Once you are happy with your Web application in development, upgrade the production machine. Either apply any changes found to be needed or disable validation if necessary.

If you have development and production on the same machine

The recommended approach in this case would be to have two copies of LANSA one for development and one for production. If this is not the case already, consider implementing this now. V9.1 will enable you to install a copy of LANSA (with different library names to your existing system), which uses a specific communications library (not QGPL). See Installing LANSA on iSeries for full details. Create your development partition in this new copy of LANSA and export/import from your existing system. Test your Web applications as above, when happy upgrade your existing copy of LANSA to V9.1 and again advice above.

If you have one copy of LANSA for development and production:

The best approach would be to set up another copy of LANSA as above. However if you wish to keep one copy of LANSA going forward, the recommendation would be to install a new copy of LANSA V9.1 into different libraries and by importing your Web applications into it, use it for testing. When happy, upgrade your existing V9.0 LANSA to V9.1 and as outlined above apply any changes found necessary or disable XHTML validation in the generated pages.

Running a V9.0 Web application on V9.1 without recompiling any functions

As noted above your Web pages will all be created as HTML and provided this is ‘well formed' this should run with no problems. Old HTML doesn't need to be well formed. Note that the runtime generates XHTML. So when you run your old HTML pages on V9.1, you will se a mixture of HTML and XHTML. Browsers will accept this mixture without problems.

What happens when I start to make changes in V9.1 to an existing Web application?

When you recompile an existing function with Generate HTML = Y or create new functions, the generated Web pages FOR THESE FUNCTONS ONLY will use XHTML. However, since a Web page is often "assembled" from a number of components, in fact your generated Web page for the recompiled or new function may contain a mixture of XHTML and HTML. As noted above provided this HTML is "well formed" this is not a problem. Again if your testing shows up problems then the options you can take are already outlined above. Note that the default and standard pages have been updated to XHTML in V9.1. Older HTML pages that use the new default/standard pages will also show a mixture of HTML/XHTML.

Potential Problems with V9.0 Web Applications when moved to V9.1

There are some potential problem areas:

The following issues are covered in the LANSA for the Web Guide Browselists
A graphical variable *LW3BLFC_<list name> may have been created for a browselist foreground colour containing a closing </FONT> tag as this was not previously generated. With 9.1, the font tag will be in lowercase <font> and will have a closing tag </font> automatically generated. Solution: remove the </FONT> tag from the graphical variable.

Within TABLE tags
In XHTML, it is not valid to have empty rows, so there may be instances where an empty row will now have <td> and </td> tags. Empty rows are OK in HTML but not in XHTML.


Manually created HTML components may not be ‘well formed' which could cause invalid XHTML. The LANSA Help documentation for the Web contains a list of XHTML syntax that should be adhered to.
Possible areas to look for include

  • Missing closing tags
  • Missing or misplaced quotes
  • Possible problems with JavaScript in the process specific script or JavaScript in components not being wrapped in <script type="text/javascript" language="javascript"> //![CDATA[//]]> </script>

These are only problems if you want to be XHTML compliant. Otherwise they are not an issue.

What happens if XHTML fails validation in the browser?

Where XHTML validation fails the page is not displayed, no warning or error message is shown and no indication of the cause is given. There are Web sites that allow you to validate your page. One is the W3C site at