Java Tutorial - Java Script :
Architectural Considerations
Template engines support a design pattern known as the Model-View- Controller (MVC) architecture. MVC is the most-used architecture for constructing Web applications today. MVC separates the logic for delivering a user interface (the view) from the underlying business logic (the model), connecting the two with a controller. The typical way of implementing MVC in a servlet environment is:
1. A request comes to the controller (a servlet), which then collects the information from the underlying business systems and packages it into one or more Java Beans.
2. The controller forwards the request to a JSP that invokes methods of the Java Bean to render the data into HTML.
The idea here is that by segmenting the design using the MVC architecture, the various components can be developed independently, while promoting reusability. The introduction of JavaServer Pages (JSPs) enables development duties to be better separated between the technical talent of the Java developer and the creative talents of the Web-page designer. Clearly, this provides a significant improvement over early development practices in which the servlet was used as the controller and model and provided the view through a series
of System.out.println() statements. Typically, a template engine is used as a replacement for JSP in the MVC architecture. Even though the JSP has significantly enhanced the development process, JSPs still leave many complexities for the developer to deal with. Followingis a typical example of JSP code:
<HTML>
<BODY>
<jsp:useBean id=”dataBean” scope=”page” class=”EventsSearchBean” />
<jsp:setProperty name=”dataBean” property=”*” />
<HR>
<P>Events in process:</P>
<%
Events[] Ev = dataBean.executeSearch();
if Ev.length > 0) {
%>
<TABLE WIDTH=’100%’ BORDER=’1’>
<TR>
<TH ALIGN=’left’>Contact</TH>
<TH ALIGN=’left’>Description</TH>
<TH ALIGN=’left’>E-Mail Address</TH>
</TR>
Controller
(Servlet)
Browser Model
View
(JSP) Data
<% for (int i = 0;i < ev.length; i++){ %>
<TR>
<TD><%= Ev.getContact() %></TD>
<TD><%= Ev.getDesc() %></TD>
<TD><%= Ev.getEmailAddress() %></TD>
</TABLE>
<% }
}
%>
</BODY>
</HTML>
The preceding code illustrates a couple of well-known controversies with JSPs. The first issue has to do with embedding Java code within the JSP. MVC purists maintain that this violates the convention established by the MVC paradigm, and that the commingling of HTML and Java violates the separation of the model and controller components from the view layer. The introduction of Java code to a JSP now requires that the Web-page designer know both Java and HTML. Although the model and view are separate, the skill sets required for implementation of each piece have not changed. Furthermore, the temptation to abuse Java code in JSPs and implement business and control logic within the JSP makes this a greater concern. The other problem evident from our example, and most \ developers would agree, is the terse and somewhat confusing nature of the looping construct with JSPs. It is simply messy and hard to read! Finally, add to this the somewhat ambiguous messages generated when error-laden JSPs are compiled, and it is clear why developers have sought an alternative to JSPs. Template engines avoid the potential problems of using JSPs and are designed to support the Web developer. They are also designed to be simpler and easier to use, and they do not support the embedding of Java code into the page. This means that they strictly enforce the separation of business logic from presentation logic. Defenders of JSPs will point out that the just released JSP 1.2 standard provides for the Java Standard Tag Libraries (JSTL 1.0). JSTL 1.0 provides a standard set of tag libraries that enable HTML developers to access objects stored in attribute values. JSTL also supports an expression language that allows access to objects stored in the standard session, page, request, and application contexts. We present examples of JSTL later in the chapter as an alternative to template engines.
