Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Java Tip 140: Automatically generate JavaBeans from XSL files in J2EE applications

Use an XSL parameter parser to convert HTML parameter names to JavaBeans

By Klaus P. Berg, JavaWorld.com, 07/11/03

Page 2 of 3

Look at the HTML form

Because we create dynamic HTML output pages using servlets, XML, and XSL, let's look closer at the HTML form elements that deliver user input data. As mentioned earlier, these HTML statements are embedded in XSL files. Therefore, we investigate XSL files to know what HTML input parameters must be read by a servlet's helper class to examine a user request. Every HTML form element has a name and a value that will be delivered if a user fills the form with data or makes a selection in a choice or radio box. These relevant form tags are:

<input type="text" name="text_parameter_name"...
<input type="checkbox" name="checkbox_parameter_name"...
<input  type="radio name="radio_button_name"...
and sometimes we need hidden parameters too, e.g.,
<input type="hidden" name="ReportName" value="First_Report"/>

If we need to examine the user data entered with these form tags in Java, we use the servlet's request object. Such a statement looks like this:

String inputText1 = request.getParameter("text_parameter_name");
// Then check for null value

A better approach is to use the O'Reilly ParameterParser (see Resources):

import com.oreilly.servlet.ParameterParser;
ParameterParser parser = new ParameterParser(request);
String inputText1= parser.getStringParameter("text_parameter_name", "");
// Provides a default value ("") too
This parser is especially useful when dealing with checkboxes:
boolean someBooleanValue = parser.getBooleanParameter("checkbox_parameter_name", false);

It is critical to have the right HTML form parameter name as a string in the Java statement. You should copy and paste from the XSL file into Java source code or read the parameter name in the XSL file and type it into the Java source. There is no other way. This is cumbersome and error-prone. Moreover, because each HTML form parameter value is in a Java variable, we need to store these values in corresponding JavaBeans that represent the intermediate model for an HTML page until the data has been saved in a database or enterprise information system. This means first coding a JavaBean by hand or with little support from an IDE, and second, calling every bean setter method to store the value. Here's where this tip can help you.

Two generators

I developed two generators that ease a J2EE developer's life when dealing with Java and XSL: the first one is a JavaBean generator and the second one is a parameter parser and bean "filler" generator (it produces setter method calls for a JavaBean generated with the first code generator). These generators are based on regular expression statements. I use Jakarta regular expressions, so you are not bound to Java 2 Platform, Standard Edition (J2SE) 1.4. Both generators use an argument parser that allows you to specify certain arguments in the command line (e.g., the generated JavaBean is dedicated to a special Java package and can implement an interface or extend a superclass). The most interesting part of the source code is the regular expressions definition block: