<%-- Page directive that applies to entire page. --%> <%@ page language="java" %>
<%-- Identifies bean as "worker" and tells the page where to locate the bean. --%> <jsp:useBean id="worker" class="jdc.quiz.QuizResponses" scope="request" />
<%-- Set bean properties with a wildcard. --%> <jsp:setProperty name="worker" property="*" />
<%-- Scoring --%>
<%-- Variable declaration in code scriptlet --> <% int score = 0; %>
<%-- The method getOne() was set up in the bean with the id "worker" --%> <%-- All Java code is enclosed in <% %>, leaving HTML to be easily --%> <%-- changed or updated. --%>
<TD VALIGN="TOP"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> Every JavaServer Pages<SUP><FONT SIZE="-2">TM</FONT></SUP> (JSP)<SUP><FONT SIZE="-2">TM</FONT></SUP>source page is compiled into a servlet before it is executed at runtime.</A><BR><BR></FONT></TD></TR>
<TD VALIGN="TOP"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> When large amounts of Java scriptlet code are mixed with HTML markup within a JSP page, not only do readability and reuse suffer, but often bugs are introduced as web-production team members, who may not be familiar with Java programming, need to modify the accompanying markup. Additionally, dependencies now exist among various teams competing for the same file, making the development process less efficient. </FONT> </TD></TR>
<TD VALIGN="TOP"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> Doing an HTTP redirect requires a round-trip to the client. If this is not required, and the only desire is to forward the request to another resource, then this can be much more efficiently accomplished with the <CODE>RequestDispatcher</CODE>. Additionally, when using the dispatcher the state of the request object is maintained between resources, which will not be the case with the HTTP redirect.
<TD VALIGN="TOP"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> Business logic is better contained in a JavaBean<SUP><FONT SIZE="-2">TM</FONT></SUP> or a servlet, which is owned by a software developer. When lots of Java code is embedded directly within the JSP page as scriptlets, the "cut-and-paste" mentality tends to prevail when it comes to code reuse. </FONT> </TD></TR>
<TD VALIGN="TOP"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> Since the servlet is the initial contact point for each request, it is well-suited to handle logic that is common across multiple requests. A good example of this type of logic is an authentication check. </FONT> </TD></TR>
<TD VALIGN="TOP"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> Using a business delegate reduces coupling between the presentation and business tiers. The presentation tier has no knowledge of the EJB implementation details, such as Java Naming and Directory Interface<SUP><FONT SIZE="-2">TM</FONT></SUP> lookup. </FONT> </TD></TR>
<TD VALIGN="TOP"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> Using Java scriptlets is the accepted method of doing iteration in JSP<SUP><FONT SIZE="-2">TM</FONT></SUP> 1.0. In JSP<SUP><FONT SIZE="-2">TM</FONT></SUP> 1.1, a custom tag may be used, which will hide the implementation details of the iteration code.
<TD VALIGN="TOP"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> The term <I>Page-Centric</I> is used to describe an architecture where the initial contact point for the request is a JSP page. An example is shown visually below: <P> <IMG SRC="Image1.gif" WIDTH="412" HEIGHT="204" ALT="JSP Page-Centric"> </FONT> </TD></TR>
<TD VALIGN="TOP"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> When the forward method is used, the invoking resource does not regain control. Multiple include invocations can be made from the same resource, while the invoking resource maintains execution control. </FONT> </TD></TR>
<TD VALIGN="TOP"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> Error pages are invoked when there is an uncaught exception from within a particular page. In this case, we mention that the <CODE>validationGaurd()</CODE> method might throw an exception. If this exception is not caught within the page, then we vector control to the <CODE>errorPage</CODE>, as stipulated in the attribute of the given page directive.
<TR><TD colspan="3"><FONT FACE="Verdana, Arial, Helvetica, sans-serif"> <P>You missed<STRONG> <%= missed %></STRONG> <BR>Your score is<STRONG> <%= (int)grade %> </STRONG> percent. <H4>Source Code</H4> <P>This quiz used the <I>Page-View with Bean Approach</I>, detailed in <A HREF="/developer/Books/javaserverpages/">Chapter 12, JSP Archeticure</A>. The <A HREF="index.txt">first page</A> of the quiz consists of regular HTML with a form that calls <A HREF="answer.txt"><CODE>answer.jsp</CODE></A>. <CODE>Answer.jsp</CODE> requests parameters from the bean, in this case, called <A HREF="QuizResponses.txt">QuizResponses</A>. The <I>page-view with bean</I> approach for this quiz required extra work to write the bean, and it could have been done using the <I>page-view approach</I> without a bean, requesting invocation directly from the <CODE>answer.jsp</CODE> page. Deciding which approach is preferrable depends on the application and how much HTML and Java scriptlets need to be used. For this quiz we opted for the <I>page-view with bean</I> approach for illustration purposes.
<P><A HREF=/developer/Quizzes/jsp/index.html>Back to Quiz</A> <P><IMG SRC=/images/T7.gif ALIGN=LEFT>