Java Reference
In-Depth Information
This configuration information can be modified by system administrators as per the cus-
tomization needs to alter the runtime behavior of the application. Unfortunately, eInsure
had only a small set of configuration parameters, making it vulnerable to code changes.
In this and subsequent chapters, I will discuss in greater detail some of the problems
in the application under consideration. I will then provide solutions to these problems by
applying the Spring Framework and design patterns and highlighting the best practices.
This chapter builds on the foundation laid in Chapters 1 and 2. It shows the first glimpses
of how design patterns and the Spring Framework can work in unison to form the back-
bone of a high-quality software application. In this chapter, I shall focus only on the
presentation tier.
Front Controller
Problem
So far, I have been pointing out the negatives of eInsure. Now I will introduce you to a
modified version of the source from this application. The source has been cleaned up
considerably to concentrate on the problem.
Listing 3-1 shows a simplified version of the JSP that was used to create and modify
policy details. It is evident from the JavaScript comments that the request was posted
after URL-rewrite. Since the same JSP was used for different underwriting operations, the
JavaScript always passed an event code and screen code combination. This was the case
with 95 percent of the JSPs in the application.
Listing 3-1. Policy.jsp
<title>Underwriting</title>
<script>
function eventValidateAndSubmit (){
//modify URL
//submit form
document.uwr.submit();
}
</script>
<body onLoad="displayError(<%=request.getAttribute("ERROR_MESSAGE")%>)">
<form name="uwr" action="UnderwritingController.jsp" method="post">
Name of Insured <input type="text" value="" /><br/>
<input type="button" value="Create"
onClick="eventValidateAndSubmit('UWR001','SCR001')"/>
 
Search WWH ::




Custom Search