Server-side Java: Advanced form processing using JSP

Use the Memento design pattern with JavaServer Pages and JavaBeans

By Govind Seshadri, JavaWorld.com, 03/01/00

Page 2 of 5

There should be nothing unusual about the form shown in Listing 1. It contains all of the commonly used input elements, including text-entry fields, checkboxes, and radio buttons. However, notice the action clause of the form:

<form action="/examples/jsp/forms/process.jsp" method=post>

Although typically you may have specified a servlet or Perl script, note that a JSP is perfectly capable of processing data posted from an HTML form. This should not surprise you, since after all, what is JSP? It is nothing but a high-level abstraction of servlets. Thus, in most cases it is entirely feasible to write a JSP equivalent to a servlet.

Still, you should always remember that JSP technology was created for an entirely different purpose than serving as an alternate (some would say easier!) mechanism for creating servlets. JSP is all about facilitating the separation of presentation from dynamic content. Although you can embed any amount of Java code within a JSP page, your best bet is to encapsulate the processing logic within reusable JavaBean components. Nevertheless, in my opinion, it should also be perfectly appropriate to develop controller JSP pages. These pages would still delegate the bulk of the processing to component beans, but they would also contain some conditional logic to respond to a user's actions. But these controller pages would never contain presentation logic to display UI elements. This task would always be externalized into separate JSPs, which will be invoked as needed by the controller.

Listing 2 demonstrates a JSP serving as a controller.

Listing 2. process.jsp

<%@ page import="java.util.*" %>
<%! 
    ResourceBundle bundle =null;
    public void jspInit() {
       bundle = ResourceBundle.getBundle("forms");
      }
%>
<jsp:useBean id="formHandler" class="foo.FormBean" scope="request">
<jsp:setProperty name="formHandler" property="*"/>
</jsp:useBean>
<% 
   if (formHandler.validate()) {
%>
    <jsp:forward page="<%=bundle.getString(\"process.success\")%>"/>
<%
   }  else {
%>
    <jsp:forward page="<%=bundle.getString(\"process.retry\")%>"/>
<%
   }
%>

Because we are delegating the bulk of the processing to JavaBeans, the first thing the controller has to do is instantiate the bean component. This is done with the <jsp:useBean> tag as follows:

<jsp:useBean id="formHandler" class="foo.FormBean" scope="request">
    <jsp:setProperty name="formHandler" property="*"/>
</jsp:useBean>

The <jsp:useBean> tag first looks for the bean instance with the specified name, and instantiates a new one only if it cannot find the bean instance within the specified scope. Here, the scope attribute specifies the lifetime of the bean. Newly instantiated beans have page scope by default, if nothing is specified. Observe that in this case, I specify that the bean have request scope before a response is sent back to the client, since more than one JSP is involved in processing the client request.

You may be wondering about the <jsp:setProperty> within the body of the <jsp:useBean> tag. Any scriptlet or <jsp:setProperty> tags present within the body of a <jsp:useBean> tag are executed only when the bean is instantiated, and are used to initialize the bean's properties. Of course, in this case I could have placed the <jsp:setProperty> tag on the outside of the <jsp:useBean>'s body. The difference between the two is that the contents of the body are not executed if the bean is retrieved from the specified scope -- which is moot in this case since the bean is instantiated each time the controller is invoked.