How do I integrate HTML design into my Servlet?

Alex Chaffee

The question can be rephrased, "How can I design a work flow that incorporates HTML designers and programmers to build a dynamically generated web site that will keep expanding and growing over time?" This is a special case of the intractable Content Management Problem of the Web in general. The real problem is to allow HTML designers (that is, humans) to use their favorite HTML editing tools without learning Java, and to allow marketing people (arguably humans) to change the look of the site on a whim, without having to alter the database access code inside the servlet. (And vice versa -- to alter the business logic and data access without altering the user interface.)

See my article at Servlet Central (http://www.servletcentral.com/1998-12/designprocess.dchtml) for an expansion on these themes.

There are many, many possibilities... The list below is not complete, but should give you some guidelines.

A. Hardcode HTML. You can just put HTML inside of print statements in your Servlet's doGet() or doPost() method.
Pro: easy to code, easy to understand for the programmer.
Con: difficult to understand for the designer; when a change has to be made, the programmer has to wait for the designer to finish her HTML, then re-hard-code it all back into print statements, then make sure the generated HTML actually does what the original HTML did. Basically, good for a hello world servlet, not good for a real web site.

B. Server Side Includes (SSI). Use the <SERVLET> tag inside your HTML file (and rename it .shtml). The HTML designers will make pretty pages; your servlets will output small pieces of text that get spliced in to the web page by the server.
Pro: separates UI (HTML) and code.
Con: You have two possible end paths with SSI: either your servlet outputs many tiny bits of text with no HTML tags, or your servlet outputs a big bunch of text with embedded HTML tags. In the first case, your code can't take advantage of its knowledge of the structure of the data -- for example, you can't format an HTML table from a database. In the second case, you're back to hardcoding HTML, thus making it hard to change the look of your pages.

C. Presentation Templates. This is a good way to put common navigation elements (button bar, credits, etc) on all of your pages. The technology is built in to the Java Web Server, and implemented by several (though not all) of the servlet engines.
Pro: you don't have to enter in the same common HTML for all the countless pages in your web site.
Con: your servlet code still has to hardcode HTML if it wants to be powerful (see item B, SSI).

D. JSP Java Server Pages. You write files in HTML format, and embed actual Java code inside the HTML. This is kind of like using JavaScript, only it's on the server, and it's real Java. This is directly parallel to Microsoft's ASP.
Pro: it's really cool; you only need a single file to do both UI and layout code; you don't have to type "println" so much.
Con: if you do anything interesting, then your HTML designers will get really confused looking at the interlaced Java and HTML code -- so make sure to put the complicated code inside a JavaBean where it belongs, not in the JSP page.

The new version of the JSP spec has lots of features for integrating with JavaBeans, which is a great way to separate user interface (JSP) from data and business logic (beans). See also the JSP FAQ (see our References section for a link).

Halcyon Software has a product called Instant ASP, which allows you to execute Microsft IIS-style ASPs (including code in VBScript, Jscript, Perl, Java, and JavaScript) in any Servlet Engine. Also Live Software has CF_Anywhere, which executes Cold Fusion CFML pages. See the References section for links.

E. Write your own page parser. If for some reason you're not happy with the standard mechanisms for doing templates (see B-D above), you can always write your own parser. Seriously. It's not rocket science.

F. HTML Object Model Class Libraries e.g. htmlKona, XML. With these class libraries, you write code and build an object model, then let the objects export HTML. This doesn't really work for complicated layouts -- and forget about letting your designer use an HTML editor -- but it can be useful when you have a highly dynamic site generating HTML, and you want to automate the process. Unfortunately, you still have to learn HTML, if only to understand and validate the output. See the References section of this FAQ for a listing of some class libraries that can help.

G. Do it all yourself Develop a database-driven content management system. Think C|Net. It has a lot of standard content, but the database is king. HTML designers have little pieces of the page that they can play with, but ultimately they're just putting content into a database, and the site (servlet) is generating every page request dynamically. This sort of system is very difficult to design and build, but once you've built it, it can really pay off -- but only if you have dozens of writers, editors, designers, and programmers all working on the same site on an ongoing basis.

For a brief list of alternate page template systems, see the References section of this FAQ.