Bitter JSPs - Bitter Java - page 97

<FORM METHOD="post" ACTION="/servlet/bbs.CompoundJSPController">
<P>Please complete the form.</P>
<P>board
<BR>

<INPUT TYPE="text" NAME="board" ID="board" SIZE="20" MAXLENGTH="20" >
</P>
<INPUT TYPE="hidden" NAME="mlname" ID="mlname" VALUE="HTML">
<P>
<INPUT TYPE="submit" NAME="Submit" ID="Submit" VALUE="Submit">

&nbsp;

<INPUT TYPE="reset" NAME="Reset" ID="Reset" VALUE="Reset">

&nbsp;
</P>
</FORM>

</BODY>
</HTML>
Aside from the board name, this page could have been pure HTML , but it's
returned as a JSP . Especially for error conditions that typically don't have a
significant performance impact, it often makes sense to bite the bullet and
deliver them as JSP s even when HTML would suffice to keep the overall code
more readable and the tooling more uniform. Many development shops opt
for a uniform delivery of JSP s. Those that do usually precompile them.
Our refactoring steps for Compound JSP s are straightforward:
Steps to refactor compound JSPs
Compound JSPs have too much decision logic. While the problems caused are relatively
minor, the simplicity of refactoring can make them an effective target. To refactor,
move the decision logic to the controller.

We broke the JSP s into distinct pages, with no more Java in each than
necessary.

1

We moved the decision point into the controller. 2

We located the decision after the execution of our commands and
before dispatching the result.

3

We dispatched the result to the appropriate JSP .

4

If the Compound JSP is simple and based on decisions made at the command
level, the refactoring in this case should be painless. This example took 10
minutes to refactor and another 10 minutes to test.