JSP Technology -- Friend or Foe?

Single-processing vs. multi-tasking

Ideally, as discussed above, a designer ought to be able to perform a single process, working purely on graphic design, and a developer should be able to focus purely on coding. So the designer should be able to work on a page after it has been converted to an application-suitable format. In the case of a JSP page, that would be after JavaBeans have been imported, inline coding has been inserted, and custom tag libraries have been added to the page. The problem is that some designers use HTML editors, such as HoTMetaL, Macromedia Dreamweaver, or FrontPage, that do not recognize code scriptlets or tag libraries, which means the designer effectively receives only a partial page. Imagine the difficulties when tag libraries or code fragments generate rows of a table, or other formatting details for the page. Designers using the incompatible HTML editors can't see what those elements look like. When designers can't easily revise pages after developers finish coding them, instead of clarifying distinct roles, JSP coding can cause them to merge: a developer must multitask, becoming developer, designer, and more.

Unconvinced about the importance of this feature? Then download the J2EE Reference Implementation and load one of the included JSP pages into a WYSIWYG HTML editor, such as Dreamweaver. The page immediately fills with yellow areas letting you know about all the "illegal" markup contained within the page. Of course, the yellow results from the JSP tags and code, rather than any real error in the page.

To date, no JSP-capable WYSIWYG editors exist, and I have not heard of any efforts to build one. While template engines have this same problem, many Java-based solutions, such as my favorite, Enhydra, allow you to supply the markup page as input to the presentation technology. In this case, the designer can make changes as often as needed and resupply the markup page. Running the engine or compiler for the presentation technology converts it to the proper format, and no code changes have to be made (in the typical case). The result is the desired one: designers remain designers, and developers remain developers.

So, be wary of the promise of JSP technology as compared to the reality of what it delivers. In practice, to function in a JSP technology-driven environment you must either have your developers handle a large portion of the markup or have designers learn at least some JSP coding.

HTML vs. XML

One of the most significant disadvantages of JSP technology, and one of the most overlooked, is its incompatibility with XML. More precisely, and particularly in the HTML realm, JSP pages are not required to be XHTML-compatible. XHTML is a World Wide Web Consortium (W3C) specification that is now replacing HTML 4.0. XHTML defines the HTML tagset in terms of a well-formed XML document. For example, the <br> tag must be converted to <br/> to ensure XML compliance. (If this doesn't make much sense, you can check out the XML specification and the developerWorks article about XHTML, listed in Resources.) Similar rules are applied to image tags, and in XHTML 1.1 (recently coming of age) most font properties and other styling move into CSS stylesheets. Still, most standard HTML documents convert easily to XHTML 1.0, which means they can be read directly with any XML-compliant parser, such as Apache Xerces, and manipulated as XML.

"What's the big deal?" you ask. The big deal is that XML quickly is becoming the global standard for inter- and intra-application communication. Passing data around in an XML format lets any other application that employs basic XML data-handling facilities use your application's data easily. Imagine being able to communicate with credit card companies for e-commerce simply by moving your data into an XML format! Many times, your presentation of data needs to be exchanged with other companies as well. The most common case is the portal application, which receives content from a variety of providers (weather, stock quotes, and news, for example), often with branding from the provider. JSP pages, however, with their mix of code and custom tag libraries, cannot function well in this environment.

JSP pages are rarely well-formed XML documents, never mind conforming to XHTML, a markup language that doesn't allow the various JSP custom tag libraries. More important, though, is that the code snippets inserted in JSP pages are not any form of markup and will create loads of parser errors once they are processed by another application.

Before you go quoting me on this, let's get the whole story out there. If the application were to allow the JSP page to be evaluated by the original client, the result would be pure HTML (or WML, VoXML, and so on). Most applications that request this data, however, employ some form of caching, as network round-trips are very expensive. In these cases, the cached page returns stale data. In those cases, then, you'd probably prefer to return pure XML-compliant results, preferably in a static form. And it is in those cases that JSP technology cannot help; JSP pages must always be evaluated at runtime to remove the JSP code scriptlets and tag libraries.

Apply the litmus test: Can some other presentation technology do this? The answer is yes. The decided leader in this arena is the Apache Cocoon project, which is based entirely on XML and an application of XSLT stylesheets (which can be applied either at runtime or statically). Because XML Server Pages (called XSP in the Cocoon framework) are actually XML documents, they are always XML-conformant. Other technologies like Tea and Enhydra XMLC that allow the input of a pure markup language page also allow this, although they do not mandate it. In these cases, the user can use XHTML or standard HTML. Still, this is better than the JSP case, where well-formed XML cannot be accomplished statically.

Summary

I hope that I have opened your eyes a bit about the advantages and disadvantages of JSP technology and that now you can look at JSP coding as one alternative among many presentation technologies. At this point, you might also be a bit skeptical about the entire J2EE programming model. If you're convinced to further investigate the platform options, look for alternatives to JSP coding in Apache Cocoon, Enhydra, and the various templating engines.

Finally, keep in mind that, despite all appearances to the contrary, this article isn't about recommending you use JSP or that you avoid it. I do intend to encourage you to peel back the layers of any technology to make sure it's right for you. Programming models are like examples; sometimes they make sense, and sometimes they don't. Look around, find out what works best for you, and make the informed decision, rather than the quick one.

Have fun, and see you on the Web!