The "view"
The purpose of the view is to present the data acquired by the
bean called from the controller. This means that when the view is
called, all the "critical" operations have taken place. It is
important that such operations have taken place since errors that
occur when HTML is being sent to the browser can result in corrupted
pages--meaning unreadable pages with strange error messages in the
browser.
Generally speaking "nothing should go wrong in the view". Well,
any experienced programmer knows that anything can go wrong when a
computer is involved, but you should use the "nothing should go
wrong"-phrase as a guideline when you "code" the view. Don't attempt
to access any databases, and avoid any lengthy Java code. In the view
you gently pick up the data in the beans and maybe from the Session
object and mix them with your HTML.
In practice it's difficult to avoid inserting Java code in the
view, but if you have to, then always consider if this code could be
moved to the controller--or into a bean. Java code can go wrong when
executed, so try to avoid it. Another possibility outside the scope
of this article would be to use tag libraries to hide Java code.
The structure of the JSP-view
Let's see what our view looks like:
<%@ page import="java.util.*" %>
<%@ page errorPage="error.jsp" %>
<jsp:useBean id="customer" class="hansen.playground.Customer" scope="request" />
<%@ include file = "util.inc" %>
<html>
<head>
<title>Customer info</title>
</head>
<body>
<h3>CUSTOMER SEARCH</h3>
<b><%=cString(session.getValue("customerinfo.message"))%></b>
<form name=myform action="ctrlcustomerinfo.jsp" method=post>
Please enter the customer ID: <input type=text name=id value="<%=customer.getId()%>">
<input type=submit value="Search">
<input type=hidden name=command value="getdata">
</form>
Name: <%=customer.getName()%><br>
Address: <%=customer.getAddress()%><br>
</body>
</html>
Note the following in the code:
- The name and address of the customer is taken from the bean using
get-methods. Since the get-methods are simple wrappers of the bean's
properties, this is a rather safe operation.
- The message text on top of the page is taken from the Session
object.
- When the use clicks the "Search" button, the form is submitted to
the controller. It only contains the ID that the user has entered
plus the action "getdata" through a hidden field.
- The "post" method is used in stead of "get" simply to avoid
showing the data from the form in the browser's address field.
- If you like you could check if the user has entered a valid ID
before you do the submit. I'd advise to at least to check if the
ID-field has been filled in. This is simple to do by some JavaScript
code:
<script>
function filled() {
return (myform.id.value != "")
}
</script>
and you'd have to include this in the FORM-tag:
onsubmit="return filled()"
Running the application
To start the application you enter a URL invoking the controller
with the command "prompt":
ctrlcustomerinfo.jsp?command=prompt
All files used in the application can be found in
this zip-file.
In a forthcoming article I'll show how this architecture
facilitates adding new features to the "Customer Search" page.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
