JSP Technology -- Friend or Foe?

Blurring the line between content and presentation

JSP allows Java code to be inserted into the markup language page, and this rather dangerous feature allows content to be intermingled with presentation. Even worse, business logic often makes its way into JSP pages, as shown in Listing 5.

JSP advocates are quick to let you know that JSP tag libraries can help you avoid this problem. Tag libraries allow custom tags (for example, <AUTHORS />) to be added to a JSP page, which at runtime are resolved into code fragments in, well, tag libraries.

The use of a custom tag and associated tag library would allow the example above to be converted to that shown in Listing 6.

At runtime, the code for this tag executes and the correct results are inserted into the page. But this does not solve the problem. The argument against JSP technology is not whether content and presentation can be separated, but whether they must be separated. As long as JSP coding allows inline coding, it is very convenient (especially when deadlines are looming) to make last-minute changes with inline code, rather than converting the code to a tag library. If this doesn't ring true, consider why the Java language immediately gained popularity over C and C++: Java disallowed many of the features that were problematic in C, such as pointer addition. While you can always argue that you don't have to perform pointer addition in C or that no good programmer would ever insert code scriptlets, we all know what happens in practice. The Java language is a better language because it mandates that these sorts of bad habits never surface. But JSP in this case is much like C, allowing some very bad practices.

An additional litmus test of the JSP technology's success in meeting its stated objectives is to see whether or not it is possible to achieve this goal in practice; certainly it isn't fair to hold JSP to an impossible standard. Most template engines, like FreeMarker and WebMacro, have this same inline coding facility, often with a Perl-analogue language. However, technologies like Enhydra's XMLC do not allow this type of inline coding. Instead, these technologies take a pure markup language page as input, and generate Java methods. This essentially is changing the program flow; instead of the page (JSP technology) calling logic from the application, the application (Enhydra) uses methods to affect the values of the page. In the specific case of Enhydra, XMLC converts the page into a DOM tree, and uses the DOM's HTML binding to allow "fields" in the page to be updated.

The point here is that more so than XMLC, JSP technology can achieve its goals, by only allowing tag libraries, for example. But the general tendency in Sun specifications is to always maintain backward compatibility, or at least maintain it for quite a long time. The current version of the JSP spec, 1.1, allows scriptlets, so expect to see code allowed in JSP pages for several years to come. Before diving into JSP coding, be careful of the rather large hole that lies between its ideal, a complete separation of content and presentation, and what it actually provides, which is at best a pseudo-split between your user interface and the code that drives your application.