Programmatic HTMLDocument generation using Java

问题:

Does anyone know how to generate an HTMLDocument object programmatically in Java without resorting to generating a String externally and then using HTMLEditorKit#read to parse it? Two reasons I ask:

Firstly my HTML generation routine needs to be very fast and I assume that parsing a string into an internal model is more costly than directly constructing this model.

Secondly, an object-oriented approach would likely result in cleaner code.

I should also mention that, for licensing reasons, I can't resort to using any libraries other than those shipped with the JVM.

Thanks, Tom

回答1:

One object-oriented approach is to use a library called ECS.

It is quite simple library, and has not changed for ages. Then again, the HTML 4.01 spec has not changed either ;) I've used ECS and consider it far better than generating large HTML fragments with just Strings or StringBuffers/StringBuilders.

Small example:

Option optionElement = new Option();
optionElement.setTagText("bar");
optionElement.setValue("foo");
optionElement.setSelected(false);   

optionElement.toString() would now yield:

<option value='foo'>bar</option>

The library supports both HTML 4.0 and XHTML. The only thing that initially bothered me a lot was that names of classes related to the XHTML version started with a lowercase letter: option, input, a, tr, and so on, which goes against the most basic Java conventions. But that's something you can get used to if you want to use XHTML; at least I did, surprisingly fast.

回答2:

I'd look into how JSPs work - i.e., they compile down into a servlet that is basically one huge long set of StringBuffer appends. The tags also compile down into Java code snippets. This is messy, but very very fast, and you never see this code unless you delve into Tomcat's work directory. Maybe what you want is to actually code your HTML generation from a HTML centric view like a JSP, with added tags for loops, etc, and use a similar code generation engine and compiler internally within your project.

Alternatively, just deal with the StringBuilder yourself in a utility class that has methods for "openTag", "closeTag", "openTagWithAttributes", "startTable", and so on... it could use a Builder pattern, and your code would look like:

public static void main(String[] args) {
    TableBuilder t = new TableBuilder();
    t.start().border(3).cellpadding(4).cellspacing(0).width("70%")
      .startHead().style("font-weight: bold;")
        .newRow().style("border: 2px 0px solid grey;")
          .newHeaderCell().content("Header 1")
          .newHeaderCell().colspan(2).content("Header 2")
      .end()
      .startBody()
        .newRow()
          .newCell().content("One/One")
          .newCell().rowspan(2).content("One/Two")
          .newCell().content("One/Three")
        .newRow()
          .newCell().content("Two/One")
          .newCell().content("Two/Three")
      .end()
    .end();
    System.out.println(t.toHTML());
}

回答3:

When dealing with XHTML, I have had much success using Java 6's XMLStreamWriter interface.

OutputStream destination = ...;
XMLOutputFactory outputFactory = XMLOutputFactory.newInstance();
XMLStreamWriter xml = outputFactory.createXMLStreamWriter(destination);

xml.writeStartDocument();
xml.writeStartElement("html");
xml.writeDefaultNamespace("http://www.w3.org/1999/xhtml");

xml.writeStartElement("head");
xml.writeStartElement("title");
xml.writeCharacters("The title of the page");
xml.writeEndElement();
xml.writeEndElement();

xml.writeEndElement();
xml.writeEndDocument();

回答4:

I think manually generating your HTML via something like a StringBuilder (or directly to a stream) is going to be your best option, especially if you cannot use any external libraries.

Not being able to use any external libraries, you will suffer more in terms of speed of development rather than performance.

回答5:

javax.swing.text.html has HTMLWriter and HTMLDocument class among others. I have not used them. I have used the HtmlWriter in .Net and it does exactly what you want, but the java version may not work out to be the same.

Here is the doc: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/html/HTMLWriter.html

Also, I can't imagine a StringBuilder being slower than building with an object layer. It seems to me that any object oriented approach would have to build the object graph AND then produce the string. The main reason not to use raw strings for this stuff is that you are sure to get encoding errors as well as other mistakes that produce malformed documents.

Option 2: You could use your favorite XML api's and produce XHTML.

回答6:

You may want to build some Element object with a render() method, and then assemble them in a tree structure; with a visit algorhytm you may then proceed to set the values and then render the whole thing.

PS: have you considered some templating engine like freemarker?

回答7:

It appears that you can accomplish what you are attempting using direct construction of HTMLDocument.BlockElement and HTMLDocument.BlockElement objects. Theses constructors have a signature that suggests direct use is possible, at least.

I would suggest examining the Swing sources in OpenJDK to see how the parser handles this, and derive your logic from there.

I would also suggest that this optimization may be premature, and perhaps this should be a speed-optimized replacement for a simpler approach (i.e. generating the HTML text) only introduced if this really does become a performance hotspot in the application.

回答8:

You can use any decent xml library like JDom or Xom or XStream. Html is just a special case of XML.

Or, you can use one of the existing templating engines for server side java like jsp or velocity.

回答9:

Basically you can insert html into your HTMLDocument using one of the insert methods, insertBeforeEnd(), insertAfterEnd(), insertBeforeStart(), insertAfterStart(). You supply the method with the html you want to insert and the position in the document tree that you want the html inserted.

eg.

doc.insertBeforeEnd(element, html);

The HTMLDocument class also provided methods for traversing the document tree.