JSP Technology -- Friend or Foe?
by Brett McLaughlinWednesday, 3rd August 2005
The promise of JSP technology
Now, on to the specifics of JSP coding. The promise of JSP technology is to supply the designer and developer the only presentation technology they will ever need. JSP technology is part of the J2EE platform, which is the strongest show of support Sun can give one of its Java products. To give you an idea of how prevalent this solution is, try running a search on 'JSP' at amazon.com; you'll find more books devoted to JSP technology than about almost any other single Java API. Before I dive into the specific problems that JSP technology presents, you need a clear understanding of what it claims to do.
Content vs. presentation
Above all, JSP technology is about separating content from presentation, foremost in Sun's published set of goals for JSP pages. In fact, JSP design stemmed directly from the complaints of developers who were tired of typing out.println("<HTML><HEAD><TITLE>" + pageInfo.getTitle() + "</TITLE></HEAD>"); into their servlet code. This mixing of hard-coded content with runtime variables presented a horrible burden on servlet developers. It also made making even minor changes to the presentation layer difficult for the developer.
JSP technology addresses this situation by allowing normal HTML pages (and later, WML or other markup language pages) to be compiled at runtime into a Java servlet, essentially mimicking the out.println() paradigm, without requiring the developer to write this code. And it allows you to insert variables into the page that are not interpreted until runtime.
In a JSP page the HTML snippet shown in Listing 2 could look like the example in Listing 3.
<%@ page import="com.ibm.display.PageInfo" %>
<%
PageInfo pageInfo = (PageInfo)session.getAttribute("PAGE_DATA")
%>
<HTML>
<HEAD>
<TITLE>
<%=pageInfo.getTitle()%>
</TITLE>
</HEAD>
<BODY>
<!-- Other HTML content -->
</BODY>
</HTML>
Judging by these initial principles, then, JSP technology (at least in its stated design) would satisfy the first tenet of a presentation technology, as outlined above: that content be separated from presentation.
Code vs. markup
Second on the JSP technology's list of features is something that might raise a bit of concern. JSP coding lets you insert Java code directly into a page of markup. To understand why this decision was made, recall that when the JSP specification was being developed, Sun's competition from Microsoft was at an all-time high, primarily due to the success of Microsoft Active Server Pages (ASP). The similarity of the name JavaServer Pages to Active Server Pages was not merely coincidental. And the ability to mimic many of ASP's features was also intentional. So JSP authors were given the option to add Java code into their markup.
As an example of Java code being added to markup, the JSP snippet in Listing 4 dynamically adds rows as needed to show each item in the Vector of actors.
<%@ page import="com.ibm.display.PageInfo" %>
<%@ page import="com.ibm.people.Actor" %>
<%@ page import="java.util.Iterator" %>
<%@ page import="java.util.Vector" %>
<%
PageInfo pageInfo = (PageInfo)session.getAttribute("PAGE_DATA")
Vector actors = pageInfo.getActors()
%>
<HTML>
<HEAD>
<TITLE>
<%=pageInfo.getTitle()%>
</TITLE>
</HEAD>
<BODY>
<H2 ALIGN="center">Search Results: Actors</H2>
<CENTER>
<HR width="85%">
<TABLE width="50%" CELLPADDING="3" CELLSPACING="3" border="1"
BGCOLOR="#FFFFCC">
<%
for (Iterator i = actors.iterator(); i.hasNext()) {
Actor actor = (Actor)i.next();
%>
<TR BGCOLOR="#FFCCCC">
<TH width="50%" ALIGN="center">
<%=actor.getLastName()%>
</TH>
<TH width="50%" ALIGN="center">
<%=actor.getFirstName()%>
</TH>
</TR>
<%
}
%>
</TABLE>
</CENTER>
</BODY>
</HTML>
Remember that so far I am simply describing the initial design goals of JSP technology; I'll defer my own judgment about the goals until a later section about the problems of JSP technology. You might be a little suspicious already, however, since embedding code into a JSP page would seem to cause problems with the first goal of JSP technology, separating content from presentation. But really (ahem), I'm not editorializing yet.
Designer vs. developer
A final (and admirable) goal of JSP technology worth mentioning is that it seeks to establish clearly defined roles in the application development process. By ostensibly breaking content from presentation, JSP technology creates a clearer distinction between the designer and developer. The designer creates markup, using only standard HTML, WML, or whatever language is appropriate, and the developer writes code. Of course, many designers today have learned JavaScript, so it should come as no surprise that many of these same designers have begun to learn JSP coding. Often, instead of just doing pure markup, they encode a complete JSP page and hand it over to the developer. Then the usual tweaking takes place, and the developer puts the JSP page into place as a front-end for some portion of the overall application. The key, though, is that many designers do not learn JSP coding, so it must also be workable in that environment.
A final (and admirable) goal of JSP technology worth mentioning is that it seeks to establish clearly defined roles in the application development process. By ostensibly breaking content from presentation, JSP technology creates a clearer distinction between the designer and developer. The designer creates markup, using only standard HTML, WML, or whatever language is appropriate, and the developer writes code. Of course, many designers today have learned JavaScript, so it should come as no surprise that many of these same designers have begun to learn JSP coding. Often, instead of just doing pure markup, they encode a complete JSP page and hand it over to the developer. Then the usual tweaking takes place, and the developer puts the JSP page into place as a front-end for some portion of the overall application. The key, though, is that many designers do learn JSP coding, so it must also be workable in that environment.Options:
Printer Friendly
Email Friend
Brett McLaughlin has been working in computers since the Logo days ( remember the little triangle?). He currently specializes in building application infrastructure using the Java language and Java-related technologies. He has spent the last several years implementing these infrastructures at Nextel Communications and Allegiance Telecom, Inc. Brett is one of the co-founders of the Java Apache project Turbine, which builds a reusable component architecture for Web application development using Java servlets. He is also a contributor of the EJBoss project, an open source EJB application server, and Cocoon, an open source XML Web-publishing engine.
