Alternative Approaches to Markup Generation

All the approaches we've considered so far are templating solutions, in which a template language renders content made available to it by a Java view adapter. This is not the only valid approach for views. Let's now consider some approaches in which the view is built using Java code. In our framework, this means that there will be a distinct implementation of the com.interface21.web.servlet.View interface for each page that will actually generate content.

HTML Generation Libraries

One approach is to use what I'll refer to as an HTML generation library: a set of Java classes that enables us to construct HTML documents using Java code. In this model, rather than use a view template such as a JSP or Velocity template, we use Java code to construct an HTML document as an object composed of objects representing text, formatting, form fields etc before writing the generated markup to the response. The HTML generation library ensures that the generated markup is well formed, and conceals the complexity of the eventual output. This concept is quite old, and the earliest implementations predate JSP, although none has become very popular. Most generation libraries are HTML-specific. However, some concepts can be shared between different output formats. The iText library, which we'll discuss below, allows some commonality between generating HTML and PDF, for example. The advantages of object generation libraries are:

The disadvantages include:

Probably the most highly developed object generation library was BEA's htmlKona. See for a description of its capabilities. This was a closed-source, proprietary product bundled with WebLogic server. In WebLogic release 6, htmlKona was deprecated, in favor of JSP - an indication that the HTML generation library didn't prove a runaway success. The Jetty servlet engine also includes an HTML generation library that can be used separately. See Later we'll look at an example of using iText to generate PDF. This illustrates a similar authoring model to HTML generation libraries.


I dislike HTML generation libraries and can't think of a reason I would choose to use them. However, their use is compatible with good MVC design, and can be supported by our web app framework like any other view technology.


The only way to address the most serious problems with HTML generation libraries - the need for a Java developer to make any presentational change, and the difficulty in turning an (X)HTML mockup into Java code to generate it - is to automate the generation of Java code to create or manipulate a predefined output format. One technology to achieve this is XMLC. It was originally developed by Lutris as part of the Enhydra app server, but is now in open source. XMLC is a very different approach to view generation to any we've seen so far. XMLC preserves some of the advantages of HTML generation libraries, while almost eliminating the basic problem of creating holding template structure in Java code. XMLC drives the generation approach from the markup. A page designer first creates a mockup site with static HTML. XMLC will "compile" the mocked up HTML pages, resulting in Java source code and/or classes. These classes, "XMLC objects", using the W3C DOM, represent the HTML content in Java, and allow programmatic manipulation of the HTML before it is output. Content from the static mockup can be changed if it is within a tag with an id attribute. For example, a page title can be given an id attribute to allow it to be changed. When larger sections of markup need to be changed, an HTML <span> or <div> tag can be introduced to enclose it (these standard structural tags are defined in the HTML 4.0 specification). The XMLC object, and the HTML it represents, can be manipulated either through the standard DOM interfaces (which allow retrieval and modification of elements) or using convenience methods added by XMLC. Thus Java developers fill in the blanks and add or delete context to the static templates with dynamic content. So long as the blanks don't change, the designers and Java developers can continue to work independently, with revised mockups resulting the generation of new Java objects. The HTML mockups are effectively a contract, defining the dynamic content of the view. Thus at design time the XMLC approach involves the following steps:

  1. Create HTML content with placeholders for dynamic data

  2. "Compile" the HTML content to XMLC objects (Java classes) with XMLC
  3. Write Java code to manipulate the XMLC objects before output

At run time the XMLC approach involves the following steps:

  1. Construct a new instance of the "XMLC object" for the view in question

  2. Manipulate the state of that object, for example by adding elements, deleting elements or setting dynamic element content
  3. Use XMLC to output the object's final state to the HttpServletResponse

XMLC offers the following advantages:

The disadvantages of XMLC include:

An XMLC Template for Our Example

The template is standard HTML, without any XMLC-specific tags. In fact, I started work on it by saving the dynamic output of the Velocity view. The only special requirement is that elements with dynamic content must be given an id attribute, using an enclosing <span> or <div> tag if necessary. Note that the values inserted in template will be visible when the template is viewed in a browser. The title is given an id, enabling us to append the performance name to its initial content of template text. We could also use a java.text.MessageFormat here:

 <title >Seats reserved for </title> 

With the name, date, and time of the performance we must introduce <span> elements, as there's no markup element we can manipulate like the <title> element in the opening fragment:

 <b><span >Hamlet</span>: 
 <span >January 1, 1983</span>
 <span >7:30 pm</span>

Note that the contents of the <span> elements in the template will serve as placeholders, making the template display meaningfully in a browser. We adopt the same approach for the reservation information:

 <span >2</span> 
 seats in
 <span >Seat Type</span> 
 have been reserved
 for you for
 <span >5</span> 
 minutes to give you time to complete your purchase.

Displaying the list of seat ids involves creating a template list id (the <li> tag can be given an id, so we don't need a <span> or <div> tag to enclose it). Note that I've also added two rows of mockup data, identified with a class of "mockup". These elements will help make the template's appearance in a browser realistic, but can be deleted by XMLC before the generation of the XMLC object:

 The seat numbers are:
 <li >Z1</li> 
 <li >Z2</li>
 <li >Z3</li>

Displaying price information simply involves using <span> tags to identify potentially dynamic content. Note that we don't need to change these values: in some cases, we might be happy with the defaults, and only change them occasionally:

 The total cost of these tickets will be
 <span >totalPrice</span>.
 This includes a tutorialing fee of
 <span >bookingFee</span>.

As the content displayed if the seats reserved aren't adjacent includes a nested <form> element, we must use a <div> element, rather than a <span> element, to enclose it:

 <div id ="nonAdjacentWarning"> 
 <b>Please note that due to lack of availability, some of the
 seats offered are not adjacent.</b>
 <form method="GET" action="otherDate.html">
 <input type="submit" value="Try another date">

The only remaining dynamic data is the URL of the seating plan image. We give this element an id to allow manipulation, and give it a relative URL that will enable the template to display in a browser:

 <img alt="Java Seating plan" 
 src="../../static/seatingplans/1.jpg" />

This certainly separates template from Java code. The best thing about the whole process is that this HTML template looks exactly like the dynamically generated page, unlike any template we've seen. The list of seat names is populated with dummy entries, while other dynamic content has placeholder values. The only snag is the inclusion of the non-adjacent seating warning, which won't appear on most pages (we'll have to remove the unwanted branch programmatically at runtime). The following screenshots displays this template in a browser:

Java Click To expand

Compiling the Template

Before we can write Java code to implement the "Show Reservation" view, we need to generate an XMLC object. We can run the xmlc command shipped with XMLC, but I've chosen to use Ant to make the task repeatable. As only a single HTML file in the sample app is compiled using XMLC, I've hard-coded its name. However, it would be easy to make the Ant target more sophisticated:

 <target >
 <fileset dir="${lib.dir}">
 <include name="runtime/xmlc/*.jar"/>
 <arg value="-keep"/>
 <arg value="-nocompile"/>
 <arg value="-dump"/>
 <arg value="-ssi"/>
 <arg line="-sourceout src"/>
 <arg line="-delete-class mockup"/>
 <arg line="-class
 <arg value="war/WEB-INF/xmlc/showReservation.html"/> 

The most interesting content is in the flags to XMLC:

When this is complete we should have a class called com.wrox.expertj2ee.ticket.web.xmlc.generated.ShowReservationXmlcObject, which is the Java representation of the template HTML. We won't edit this class, but we will use its methods to manipulate its state. If generated XMLC objects are placed along with ordinary source code where an IDE can find them, an IDE should be able to provide context help on their methods, which is likely to prove very useful.

Manipulating the XMLC Object Generated from the Template

Let's now look at implementing the com.interface21.web.servlet.View interface for XMLC. In the XMLC object, as with a code generation library, we need a distinct Java object for each view. At runtime the HTML template is no longer required, but we need one view implementation for each XMLC-generated view. We don't need to start from scratch. Our MVC framework provides a convenient superclass for XMLC views - com.interface21.web.servlet.view.xmlc.AbstractXmlcView - which uses the template method design pattern to conceal the necessary plumbing from subclasses and leave them only the task of creating manipulating the relevant XMLC object. Subclasses need to implement only the following protected method:

 protected abstract XMLObject createXMLObject(
 Map model,
 HttpServletRequest request,
 HttpServletResponse response,
 XMLCContext context)
 throws ServletException;

Like most XMLC view subclasses, the concrete implementation that we use in the sample app doesn't expose any bean properties. Thus the entire bean definition in /WEB-INF/classes/ is as follows:



See Appendix A for information on installing and configuring XMLC, and a description of the implementation of the com.interface21.web.servlet.view.xmlc.AbstractXmlcView framework class.

Now let's move to our specific example, com.wrox.expertj2ee.ticket.web.xmlcviews.ShowReservationView. We begin by extending AbstractXmlcView:

 public class ShowReservationView extends AbstractXmlcView {

There are no bean properties, and don't need to provide a constructor. We implement the required protected abstract method as follows:

 protected XMLObject createXMLObject (
 Map model,
 HttpServletRequest request,
 HttpServletResponse response,
 XMLCContext context)
 throws ServletException {

We begin by constructing a new XMLC object. We can do this with a no-argument constructor, but it's more efficient to use the XMLC context argument to provide an object:

 ShowReservationXmlcObject showReservationXmlcObject =
 (ShowReservationXmlcObject) context.getXMLCFactory().create(

We now extract our model objects from the map, so we perform type casts once only:

 Reservation reservation = (Reservation)
 Performance performance = (Performance)
 PriceBand priceBand = (PriceBand)

Next we use similar code to that we've seen before to use standard Java internationalization support to format dates and currency amounts, based on the request locale:

 SimpleDateFormat df = (SimpleDateFormat)
 DateFormat.getDateInstance(DateFormat.SHORT, request.getLocale()) ;
 df.applyPattern("EEEE MMMM dd, yyyy");
 String formattedDate = df.format (performance.getWhen());
 df.applyPattern("h:mm a");
 String formattedTime = df.format(performance.getWhen());
 NumberFormat cf = NumberFormat.getCurrencyInstance(request.getLocale());
 String formattedTotalPrice = cf.format(reservation.getTotalPrice());
 String formattedBookingFee =
 cf.format(reservation.getQuoteRequest() .getBookingFee());

Now we can begin modifying dynamic content in the elements with an id attribute. XMLC spares us the ordeal of using DOM to do this, as it generates convenience manipulation methods. Setting dynamic text is very easy:

 showReservationXmlcObject.getElementTitle().getText() + " " +
 showReservationXmlcObject.setTextSeatsRequested("" +
 showReservationXmlcObject.setTextMinutesHeld("" +

To build the list of seat names, we need to obtain the prototype list item, clone it for each row of data in our model, and then delete the prototype row itself. This is a very different approach to any we've seen. It's not difficult, but it isn't particularly intuitive:

 // Get template node for seat list
 HTMLElement seatEle = showReservationXmlcObject.getElementSeat();
 for (int i = o; i < reservation.getSeats().length; i++) {
 reservation.getSeats() [i].getName());
 seatEle.getParentNode().insertBefore (seatEle.cloneNode (true), seatEle);
 // Remove template node seatEle.getParentNode() .removeChild(seatEle);

However, remember that this part of the XMLC authoring process is performed by Java developers, not markup developers (who are done when they've provided mockup HTML). So it's safe to assume the necessary coding skills. Remember that the "mockup" list data elements were ignored when XMLC generated a Java object from the HTML template: We handle the conditional display of the adjacent seats warning by deleting this element if it's not needed:

 if (reservation.getSeatsAreAdjacent()) {
 Element adjacentWarning =
 adjacentWarning.getParentNode() .removeChild(adjacentWarning);

Finally we obtain the <img> element that displays the seating plan graphic and set its source URL, before returning the configured XMLC object for the superclass to use to build the response:

 HTMLImageElement graphicEle = (HTMLImageElement)
 graphicEle.setSrc("static/seatingplans/" +
 performance.getShow() .getSeatingPlanId() + ".jpg");
 return showReservationXmlcObject;


XMLC offers a very different way of separating presentation template from dynamic code to most view technologies. Its strengths are that the standard-HTML templates it works with can display in a browser exactly as they will appear at runtime, populated with dynamic data; and that it can cope with HTML that isn't human-readable. However, it requires an additional "compilation" step in the development process and requires a greater learning effort than simpler technologies such as Velocity.

Further Reading on XMLC

See the following resources for further information about XMLC: