JSP meets IBM Forms enterprise web application development

Using simple Java™ expressions and scriptlets, JavaServer™ Pages makes it easy for web application developers to populate web content before serving it. Enterprise IBM® Forms are powerful data collection documents made up of a high precision user interface, an XML data layer, interactive calculation and data validation rules, attachments, digital signatures, web service calls, and web submission capabilities. This article shows how to use JSP to pre-populate, serve, and process the submitted results of enterprise IBM Forms in an IBM Websphere® Application Server environment. JSP is also discussed in the context of the design and maintenance lifecycle of an IBM Form. This content is part of the IBM WebSphere Developer Technical Journal.

John Boyer, Ph.D (boyerj@ca.ibm.com), IBM Distinguished Engineer, IBM  

Dr. John Boyer has been chief architect of enterprise IBM Forms and one of its developers for nearly two decades. John has represented IBM Forms in W3C standards development, including as chair and editor of XForms and editor or author of XML Signatures specifications. In 2001, John earned a Ph.D. in computer science, and he has published numerous journal articles and conference papers on topics including algorithm analytics, computer security of documents, document engineering, and XML-related technologies.


developerWorks Contributing author
        level

20 March 2013

Introduction

JavaServer Pages (JSP) technology remains popular because it simplifies the development of a wide class of web applications. The JSP author decorates a web page template with code fragments that access server-side data sources to pre-populate the web page before it is served. When the JSP is first requested, the web application server automatically compiles the JSP page into a servlet (or it is pre-compiled for better performance). Just like any Java EE servlet, this generated servlet has an input stream and output stream. When the JSP is requested, data can be posted or sent to on the input stream, and the JSP code fragments can access the input stream data. The generated servlet places the pre-populated web page on its output stream. Of course, the web pages produced by a JSP can include JavaScript libraries to drive the dynamic client-side user experience, in addition to using JSP code fragments to pre-populate and serve the initial web page, plus process the end results of the interaction and provide the next web page. JSP is intended as an alternative to Java EE servlets for lighter weight solutions (or as parts of a larger solution) because it makes them easier to develop and maintain as content.

An enterprise IBM Form is an XML-based document that describes a rich interactive data collection experience, including a high precision user interface definition, calculation and data validation rules and scripts, digital signature security, and web service calls. XFDL is the XML vocabulary for enterprise IBM Forms documents, and XFDL forms templates are typically pre-populated, served by, and submitted to Java EE servlets. This article describes how to enable an XFDL form to be used as the web page template in a JSP. Enterprise IBM Forms web application developers will now be able to use JSP as a simplifying alternative to Java EE servlets, and JSP developers will now be able to use sophisticated IBM Forms in their web applications.


Using JSP to pre-populate an XFDL form

In order to drive the client-side user experience in a web browser, XFDL forms are converted to HTML and JavaScript by the Translator module of the IBM Forms Webform Server. To use an XFDL form as the web content template of a JSP, two things are required to connect the JSP's generated servlet to the Translator. The first is a JSP page directive, shown in Listing 1, and the second is a JSP declaration, shown in Listing 2.

The JSP page directive does four things:

  1. It sets the output content type to application/vnd.xfdl because the JSP's web page template is an XFDL form, and so that is the correct output type of the JSP's generated servlet.
  2. The page encoding is set to UTF-8 to ensure the JSP compiler uses the same encoding as the XML-based XFDL form.
  3. The import attributes are used to pull in IBM Forms classes, including the one that connects the JSP to the IBM Forms Translator module.
  4. The extends attribute is used to get the JSP's generated servlet to use an IBM Forms Server servlet subclass that routes the JSP's output (which is a pre-populated XFDL form) to the Translator.

From a JSP authoring perspective, you simply copy-paste the page directive in Listing 1.

Listing 1. JSP page directive for pre-populating an XFDL form
<%@ page contentType="application/vnd.xfdl"
    pageEncoding="UTF-8"
	    import="java.io.IOException"
    import="com.ibm.form.webform.framework.servlet.IBMWorkplaceFormsServerServlet" 
    extends="com.ibm.form.webform.framework.servlet.IBMWorkplaceFormsServerServlet"%>

The required JSP declaration in Listing 2 comes immediately after the page directive. It overloads getInitParameter() to tell the JSP the location of the IBM Forms Translator. This technique is used because the @WebServlet annotation doesn't work in a JSP and because it eliminates the need for a web.xml file. The doGet() and doPost() overloads are also needed to help the JSP servlet and the Translator communicate. The JSP declaration in Listing 2 is also a copy-paste inclusion, except you need to change localhost to match your environment because the IBM Forms Server might be deployed remotely and shared by a development team.

Listing 2. JSP page declaration for pre-populating an XFDL form
<%!
    public String getInitParameter(String name) {
        if (name.compareTo("translatorLocation") == 0)
            return "http://localhost:8085/translator";
        return super.getInitParameter(name);
    }

    protected void doGet(HttpServletRequest request, 
                         HttpServletResponse response) 
                         throws ServletException, IOException {
        _jspService(request, response);
    }
    protected void doPost(HttpServletRequest request, 
                          HttpServletResponse response) 
                          throws ServletException, IOException {
        _jspService(request, response);
    }
%>

At this point, you are equipped to serve out an XFDL form template with JSP and to use JSP scriptlets and expressions within the XFDL form template. The overall structure of the XFDL-based JSP is shown in Listing 3.

Listing 3. Structural overview of an XFDL-based JSP
<?xml version="1.0" encoding="UTF-8"?>

<%@ The above JSP page directive  %>

<%! The above JSP declaration %>

<% An optional initializing JSP scriptlet %>
	 
<XFDL xmlns="http://www.ibm.com/xmlns/prod/XFDL/8.0" ...>
   ...
   <xforms:instance ...> 
      <!-- the XML data layer -->
      <% JSP scriptlets %>
      <%= JSP expressions %>
   </xforms:instance>
   ...
   <!-- the XFDL/XForms user interface -->
   ...
</XFDL>

Based on Listing 3, one question a JSP author who is accustomed to HTML-based JSP might ask is: Why do the scriplets and expressions appear only in the XML data layer that is surrounded by the <xforms:instance> element? In HTML, scriptlets are often used to duplicate content to form tables. In fact, JSP scriptlets and expressions could be used anywhere in the XFDL document, but XFDL internally uses a W3C industry standard known as XForms, which contains a powerful user interface binding mechanism that can automatically duplicate user interface template content according to how much data is in the XML data layer. This means your JSP scriptlets and expressions can stay focused on the data layer, which is quite useful since it is data that they use to pre-populate a form. This will be covered later in more detail in the next section.

A second question an experienced JSP author might ask about Listing 3 is: Why is there an optional initializing JSP scriptlet depicted after the required JSP declaration and before the XFDL start tag? One reason is to take advantage of more advanced features of the IBM Forms product suite. Another reason is to initialize the IBM Forms API. You see, just as with HTML-based JSPs, the current JSP cannot be the first in the user experience, and in that case, the current JSP could receive as posted input a filled XFDL form that was served by a preceding JSP (or Java EE servlet). The IBM Forms API would be used to read the input XFDL form so that its values could be used in the JSP code fragments that pre-populate the JSP output. This capability is discussed more later.

A third question you might ask about Listing 3 is: How does the XFDL form manage to still be well-formed XML once the JSP decorations are added, as shown in Listing 3? The short answer is that it is not XML once the JSP decorations are added because the less-than symbol (opening angle bracket) used to start each JSP decoration is also a reserved character in XML. A side effect of this fact is that the JSP decorated file cannot be loaded into an XML-based editor. This is a completely unacceptable state of affairs from a software lifecycle perspective because an XFDL form decorated with JSP (Listing 3) cannot be loaded into the IBM Forms Designer for maintenance and upgrade purposes. However, this is not a difficult issue to resolve, and a simple workaround is presented in a later section.

A fourth question is: Why is the XML syntax for JSP not used? The short answer is that it could be used, but the very design of the XML syntax for JSP produces limitations that make the non-XML syntax more natural and appealing. The means of using the XML syntax for JSP, as well as those language design limitations, are also discussed in a later section.


JSP scriptlets and expressions in an XFDL form

Once the page directive is added. and the initializing declaration is added and given the proper Translator URL domain, then the creative forces of the JSP developer are unleashed, and they are called JSP scriptlets and expressions. by exposing critical, in-house applications to externally available sites and devices.

Before diving into them, it is worth making a few notes about JSP style. You should place larger pieces of logic into supporting Java methods and inner classes in the JSP declaration, not inline in scriptlets. Common functions that must be shared by JSPs should be developed as separate Java classes in a common package for the solution. The common package can then be imported by the JSP page directive, as shown in Listing 1 for the IBM Forms Server support classes. Use the optional initializing JSP shown in Listing 3 to consolidate your logic that grabs values from places like the servlet input stream or back end data sources. These practices will help you to ensure that the JSP scriptlets and expressions you embed within the XFDL form data layer are small, easily maintained nuggets of cleverness that are laser focused on placing customized data values into the output stream of the JSP's generated servlet.-friendly standards and platforms such as HTML5, Dojo, and JSON-capable interfaces.

Listing 4 shows how to pre-populate the XFDL form with a value from a URL parameter sent to the JSP. The initializing JSP scriptlet stores the value of the URL parameter called customerName in a Java String of the same name. The JSP expression embedded in the <name> element simply refers to the Java String as the way to put its value into the XML data layer at the location of the JSP expression.

Listing 4. Using JSP to inject a data value into an XFDL form
<?xml version="1.0" encoding="UTF-8"?>
...

<% String customerName = request.getParameter("customerName"); %>
	 
<XFDL xmlns="http://www.ibm.com/xmlns/prod/XFDL/8.0" ...>
   ...
   <xforms:instance xmlns="" ...> 
      <customer>
         <name><%= customerName %></name>
         <dependents>
            ... 
         </dependents>
      </customer>
   </xforms:instance>
   ...
   <label sid="uiCustomerName">
      <xforms:output ref="/customer/name">
         <xforms:label>Customer Name: </xforms:label>
      </xforms:output> 
   </label>
   <table sid="uiDependents">
      ...
   </table>
   ...
</XFDL>

When the JSP in Listing 4 is served, the pre-populated XFDL form is placed on the JSP servlet's output stream. Since the JSP extends the IBM Forms servlet subclass, the IBM Forms logic intercepts the XFDL content and routes it to the IBM Forms Translator. This generates the HTML that is delivered to the user's web browser. This includes translating to HTML the <label> item with the scoped identifier (sid) of uiCustomerName shown in Listing 4. This item contains an <xforms:output> element that binds the label to the data element indicated by the XPath expression /customer/name in the ref attribute value. As a result, the HTML for the XFDL <label> will display the content of the <name> data element.

We can now proceed to a more advanced example by expanding on the content of the <dependents> data element and the XFDL <table> user interface element that was omitted in Listing 4. For example, suppose this XFDL form is intended to enable the user to add to, delete from, or change the customer's list of dependents. Of course, there would be buttons for adding and deleting, but since the JSP is focused on pre-population, we'll concentrate on how to get the customer's current dependent list into the form with an editable user interface, whereas the next section will show how to receive and process data that has been edited and returned by a user.

In Listing 5, the initializing JSP scriptlet has been amended to show how to insert a dynamic list of data elements. In this case, you are inserting the number of dependents the customer needs to be edited using the form. It's not important to the JSP example that you get this from an actual database query, so instead Listing 5 just provides a mock back end data source. The important part is the JSP scriptlets and expressions that are then used to inject the dependent list data into the XML data layer of the XFDL form.

Listing 5. Using JSP to inject repeated data into an XFDL form
<?xml version="1.0" encoding="UTF-8"?>
...
<% String customerName = request.getParameter("customerName");
   // Mock back-end data source 
   String[] names = {"Alice", "Bob", "Carla"};
   int[] ages = {7, 8, 9};
%>
	 
<XFDL xmlns="http://www.ibm.com/xmlns/prod/XFDL/8.0" ...>
   ...
   <xforms:instance xmlns="" ...> 
      <customer>
         <name><%= customerName %></name>
         <dependents>
            <% for (int i=0; i < names.length; i++) { %>
            <dependent>
               <name><%= names[i] %></name>
               <age><%= ages[i] %></age>
            </dependent>
            <% } %>
         </dependents>
      </customer>
   </xforms:instance>
   ...
   <table sid="uiDependents">
      <xforms:repeat nodeset="/customer/dependents/dependent">
         <field sid="uiName">
            <xforms:input ref="name"><xforms:label/></xforms:input>
            ...
         </field>
         <field sid="uiAge">
            <xforms:input ref="age"><xforms:label/></xforms:input>
            ...
         </field>
      </xforms:repeat>
   </table>
   ...
</XFDL>

A strength of JSP is its ability to enable incomplete Java code fragments to be provided by separate JSP scriptlets so that the syntactic parts of a Java loop can surround a mix of output content and JSP expressions. Listing 5 uses this technique to generate XML <dependent> elements for the number of dependents a customer might have, and then the <name> and <age> sub-elements are pre-populated with JSP expressions that can reference both the back end data source variables from the initializing JSP scriptlet and the loop variable from the first JSP scriptlet embedded in the XML data.

Once the XFDL form is pre-populated with the dependent data, it is ultimately translated to HTML, as previously described. In particular, the <table> shown in Listing 5 generates one row of user interface for each <dependent> element in the data layer. Here is is a quick tutorial on how that happens:

  1. The <table> contains an element called <xforms:repeat>, which has an attribute called nodeset. The value of this attribute is an XPath expression that indicates a set of XML data nodes.
  2. In Listing 5, the expression "/customer/dependents/dependent" indicates all <dependent> elements in the <dependents> child of the <customer> element.
  3. The <xforms:repeat> element automatically generates a user interface row for each <dependent> element matched by the nodeset expression. In Listing 5, this means that copies of the two XFDL <field> elements within the <xforms:repeat> are generated to provide text editing input boxes for the <name> and <age> data elements within each of the <dependent> data elements.

An XFDL form as input to a JSP

If a JSP is not the first user experience of a web application, then the request input stream can contain user responses in a filled XFDL form served by a preceding JSP or Java EE servlet in the web application. The most typical enterprise IBM Forms processing model is that an XFDL form goes out to the user, is filled, and then the whole form comes back to the server for processing. Although the data is typically extracted and used to drive back end business processes, the whole XFDL form is available to be stored in a content manager for archival purposes. This archival step is especially prevalent when the form contains attachments or has been digitally signed, since signatures protect the whole form from tampering, not just the data.

In order to process an XFDL form that has been posted to the JSP, you will first initialize the IBM Forms API and then use it to read the XFDL form and extract a data value from it. Listing 6 shows the first part — how to initialize the IBM Forms API — by adding more import attributes to the JSP page directive for IBM Forms API support classes and by adding a servlet init() method overload to the JSP declaration. Both of these are just copy-paste code blocks .

Listing 6. More imports for the IBM Forms API
<%@ page ...
    import="com.PureEdge.DTK"
    import="com.PureEdge.IFSSingleton"
    import="com.PureEdge.error.UWIException"
    import="com.PureEdge.xfdl.FormNodeP"
    import="com.PureEdge.xfdl.XFDL"
    ... %>

<%! ...		
    public void init() throws ServletException
    {
        super.init();
        try {
            DTK.initializeWithLocale(
                this.getServletContext().getRealPath(".") + this.getClass().getName(), 
                "1.0.0", "8.0.0", null);
        } catch (UWIException e) {
            throw new ServletException(
                e.getStackTraceString() + System.getProperty("line.separator") + 
                "Unable to initialize the IBM Forms API");
        }
    }	
%>

Listing 7 shows the second part, how to read the XFDL form and extract a value from it. This is copy-paste code for you to place in the initializing JSP scriptlet, except that you have to provide extractXFormsValue() calls that are specific to the data that needs to be extracted from the particular XFDL form on the input stream.

Listing 7. Reading the XFDL form and extracting data from it
<%
    String customerName = "";
		
    FormNodeP theForm = null;
    try {
        XFDL theXFDL = IFSSingleton.getXFDL();
        theForm = theXFDL.readForm(request.getInputStream(), XFDL.UFL_SERVER_SPEED_FLAGS);
        customerName = theForm.extractXFormsValue(null, "/customer/name", null, 0, null);
	    } catch (UWIException e) {
	        System.err.println(e.getStackTraceString());
    } finally {
        try {
            if (theForm != null)
                theForm.destroy();
        } catch (UWIException e) {
		        }
	    }
%>

Compared with Listing 5, Listing 7 simply shows the customerName string value being obtained from an XFDL form rather from a URL request parameter. Once obtained in the initializing JSP scriptlet, the string value can be used in JSP expressions, just as was done in Listing 5.

The resources customerName.jsp and customerDependents.jsp, which accompany this article, give you full working JSPs that contain the code listings presented so far. Given an IBM Websphere Application Server into which the IBM Forms Server Webform Server Framework has been installed, these two JSPs should be deployed to the same directory, such as in the WebContent of a WAR. The customerName.jsp serves an XFDL form that just collects a customer name and provides a button that submits the filled form to customerDependents.jsp. This latter JSP uses the code from Listings 6 and 7 to crank up the IBM Forms API and read the customer name from the received form, and then it uses the code from Listings 4 and 5 to show the customer name and a table of the customer's dependents.


Preserving solution design and maintenance ability

The IBM Forms Designer is a GUI and source editor for XFDL forms. From a software development and maintenance perspective, it is desirable to be able to use the IBM Forms Designer on JSP files (such as those that accompany this article) to update the XFDL design or source edit the JSP decorations. However, this is not possible because the JSP decorations disturb the XML well-formedness of the JSP files.

Fortunately, this problem is easy to solve using the power of the XML technology stack:

  1. You will use XML processing instructions to store JSP decorations in the XFDL form. This will enable the IBM Forms Designer to read the file, so the form author can make GUI design changes to the XFDL form template. The form author will also be able to use source editing to make changes to the JSP processing instructions in the XFDL form.
  2. When it comes time to deploy and use the file as a JSP, you will use a small XSLT that accompanies this article to publish the XFDL form to the JSP file format.

An XML processing instruction, or PI, has the form <?name content?>. The name and content of a PI indicate what action is to be performed on the containing XML document. You will create a PI named jsp to represent JSP decorations in an XFDL form, and its content will indicate whether it is a directive, declaration, scriptlet or expression. The content of the PI will also give the body of the directive, declaration, scriptlet, or expression. The XSLT provided with this article publishes XFDL to JSP by simply copying the input to the output, except for converting each jsp PI to a JSP directive, declaration, scriptlet, or expression. Table 1 shows the jsp PI formats and the substitutions performed by the provided XSLT.

Table 1. Usage and effects of the jsp processing instruction
Processing instruction usageSubstitution (Effect)
<?jsp directive jspDirective ?><%@ jspDirective %>
<?jsp declaration jspDecl ?><%! jspDecl %>
<?jsp scriptlet jspScriptlet ?><% jspScriptlet %>
<?jsp expr jspExpr ?><%= jspExpr %>

XML has one limitation that prevents this from being a perfect solution. PIs can be placed at any content location in XML, which means they cannot be placed in an XML attribute value. Attribute values are a legitimate part of the XML data layer. To solve this problem, you will create two more companion PIs, jspAttr and jspExpr, to be used when embedding JSP expressions in the XML data layer. The jspAttr PIs can be placed any number of times into any XML elements. As shown in the first row of Table 2, each jspAttr PI sets a JSP expression into an attribute of the containing XML element. The jspAttr PI content takes the form name=jspExpr, where name is the name of the attribute, and jspExpr is the expression to be injected into the attribute value. The jspExpr PI can be placed into any XML data element. As shown in the second row of Table 2, it sets a JSP expression into the content of the element, replacing all of the content of that XML element. The jspExpr is especially useful for setting the value of an XML element whose attributes also need to be set by jspAttr PIs. Table 2 shows the usage and effects of the jspAttr and jspExpr PIs.

Table 2. Usage and effects of jspAttr and jspExpr
Processing instruction usageSubstitution (Effect)
<e a=""><?jspAttr a=jspExpr ?></e><e a="><%= jspExpr %"></e>
<e><?jspExpr jspExpr ?></e><e><%= jspExpr %></e>

The accompanying file applyXSLT.java file is a quick wrapper around Java's built-in XSLT processor, and applyXSLT.class is the compiled version provided for convenience. The accompanying file XFDL2JSP.xsl is the XSLT that converts jsp, jspAttr and jspExpr PIs into actual JSP decorations. This XSLT is well-commented so that it can be customized or used for learning a little about XSLT, if desired. It uses one advanced feature of XSLT — the disable-output-escaping attribute — to cause the XSLT to output the desired JSP format rather than well-formed XML.

The net result of this section is that you can work with JSP in the XFDL form using the IBM Forms Designer for software development and maintenance purposes. During development, you use XML processing instructions that are very similar in grammar to the JSP decorations. Any time the actual JSP is needed for deployment to the application server, you can perform the publish command indicated in Listing 8.

Listing 8. Publishing XFDL to JSP
java applyXSLT MyForm.xfdl XFDL2JSP.xsl MyForm.jsp

The file customerDependents.xfdl that accompanies this article has been decorated with JSP processing instructions. Once XFDL2JSP.xsl is applied to the XFDL form, the result is functionally equivalent to customerDependents.jsp.


On the XML syntax for JSP

With all the emphasis the previous section placed on XML well-formedness, it is natural to ask why the XML syntax for JSP was not used. One answer is that the non-XML syntax is less verbose and so well-known that it would have been worth making it work in any case. A corollary to that answer is that the XML syntax for JSP could also be used. However, there are language architecture issues with the design of the XML syntax for JSP.

The XML syntax for JSP takes over the root element of the XML document. This might not even be permitted by the schema of the document format being enveloped by the JSP. It also means the JSP markup cannot be used with some processors of that document without either changing the processors or using a publication step anyway. For example, the IBM Forms Designer handles XFDL forms with a root element of XFDL, so the JSP root element would have to be enveloped by the XFDL, and then a publication XSLT would have to be used to invert the envelopment. Although this is not worse than the technique used in the previous section, it is also no better to use the XML syntax for JSP.

A much deeper problem with the use of XML elements for the JSP syntax is that it upsets the XML schema and XPath addressability of the XML being decorated. This is especially hard to accommodate in the XML data layer of the XForms-based form because the schema of the data layer is under the control of the solution's data architect, not the product architect of the forms technology. The data architect might be forced to permit the injection of foreign-namespaced elements into data elements whose schema would normally classify them as a simpleType or simpleContent type. Further, XForms user interface bindings require that input elements should bind to simpleType or simpleContent elements, and so design environments would report false positive errors or warnings about invalid user interface bindings due to XML-based JSP infestations. Even worse, the use of JSP element syntax can change the parent-child or sibling relationships of the true data elements, which upset the XPath expressions needed at design time relative to run time.

The problems reach an insurmountable climax when a JSP expression is required for an attribute value. To do this, the start tag of the XML data element containing the attribute must be turned into content of a <jsp:text>. Once this happens, the XML element is no longer an element; it's just content that will become an element when the JSP runs. Because the XML element is just a non-element content at design time, it is no longer addressable by XPath, nor can it be validated by the data schema. The only reasonable alternative for solving these problems is to use a processing instruction such as jspAttr.

On one hand, it might seem like a case of the old adage about hindsight being 20/20. On the other hand, it is quite difficult to ignore the technical direction on processing instruction usage that had already been set by XSL. And it is even more difficult to ignore the syntactic proximity of JSP decorations to XML processing instructions that were available at the time. Instead, once you have been forced to use a processing instruction like jspAttr for solving part of the problem of combining JSP into the design experience for the XML document, it is best to be consistent about it. This is how the primary solution above came to be based on processing instructions and not the XML syntax for JSP.


Conclusion

At the developer level, this article has equipped the JSP author with IBM Forms, and it has equipped the IBM Forms author with JSP. This facilitates rapid prototyping at more of an authoring level, and it simplifies development of a wide class of web applications.

For technical skills advancement, this article has covered some good introductory material about JSP as well as several layers of the XML technology stack, and it has also presented real use cases for some advanced features of JSP, XML, and XSLT. For JSP skills, the union with IBM Forms required review and use of a page directive, a declaration, scriptlets, and expressions. This article also covered extending the JSP from a class other than HttpServlet, setting the page encoding, use of imports, providing an initialization parameter without needing a web.xml or @WebServlet, and wiring doGet() and doPost() to _jspService(). For XML skills, this article showed the use of JSP to pre-populate a form's XML data layer, including scriptlets that repeat an XML data element using a loop. The article also discussed the the merits of the JSP tagging mechanism expressed as XML processing instructions, relative to language architecture issues with the XML syntax variant of JSP. For XSLT skills, this article has provided a simple wrapper class that gives you access to Java's built-in XSLT processor. This article also provided a well-documented XSLT that converts JSP processing instructions into JSP tags. Since JSP tags are not well-formed XML, this included disabling output escaping in order to emit a well-formed JavaServer Page.

Finally, at an architecture level, this article has covered three key considerations necessary to fully address the union of JSP and IBM Forms: the deployment model of the supporting technology for the forms language (that is, accommodating IBM Forms Server, not just the IBM Forms Viewer web browser plugin), the run time lifecycle (that is, handling the filled and submitted form, not just serving a pre-populated form), and software solution development and maintenance (tha tis, enabling the co-existence of JSP and XFDL together in the IBM Forms Designer without upsetting the XPath addressability of data elements and attributes, nor their XML schema validation).


Acknowledgements

My special thanks to Eric Dunn, the IBM Forms SEAL Team Leader, who thoroughly read this article and made numerous suggestions that helped me simplify the exposition to increase readability of the content.


Download

DescriptionNameSize
Code sampleIBMFormsSample.zip7KB

Resources

Learn

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 WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=861807
ArticleTitle=JSP meets IBM Forms enterprise web application development
publish-date=03202013