📄 l5.html
字号:
possible, be excluded from the presentation. <br>
<br>
Model I: Simple 2 1/2 Tier Application<br>
In a team environment where everyone knows Java and HTML, or if you're doing
it all yourself, this approach can work well, provided everyone maintains a
clear coding structure (that discussion is outside the bounds of this
article). The primary advantage of this approach is that there is only one
file to maintain for changes to your application. The major disadvantage is
readability! Unless great care is taken, your HTML and Java code can become
so intermingled that it becomes difficult to debug and maintain your
application. <br>
<br>
For this example, we are going to revisit the "Sample Page" from
the JSP Quick Start chapter. I'm going to add a TimeZone element, so we'll
have a JSP that returns the time based on the desired timezone. If no
TimeZone is submitted, we'll default to that of the server.<br>
<br>
======================================================================<br>
<xml version="1.0" ?><br>
<H1>Time JSP</H1><br>
<jsp:scriptlet><br>
//the parameter "zone" shall be equal to a number between 0 and 24
(inclusive)<br>
TimeZone timeZone = TimeZone.getDefault(); //returns the default TimeZone
for the server<br>
if (request.getParameterValues("zone") != null)<br>
{<br>
String timeZoneArg = request.getParameterValues("zone")[0];<br>
timeZone = TimeZone.getTimeZone("GMT+" + timeZoneArg +
":00"); <br>
// gets a TimeZone. For this example we're just going to assume <br>
// its a positive argument, not a negative one.<br>
}<br>
//since we're basing our time from GMT, we'll set our Locale to Brittania,
and get a Calendar.<br>
Calendar myCalendar = Calendar.getInstance(timeZone, Locale.UK);<br>
</jsp:scriptlet><br>
<%= myCalendar.get(Calendar.HOUR_OF_DAY) %>:<br>
<%= myCalendar.get(Calendar.MINUTE) %>:<br>
<%= myCalendar.get(Calendar.SECOND) %><br>
======================================================================<br>
Similarly, the data to be displayed could have been gotten from a JavaBean.
We'll see a little of that in the next example. <br>
Model II: Redirecting Requests<br>
In a team environment where some members are HTML designers and others are
Java programmers, this approach can be particularly strong. The Java
programmers can focus on creating (re)usable code, while the HTML designers
can focus on presentation. While the two remain dependant on each other, one
or the other can change dramatically so long as the principle inputs and
outputs (respectively) remain the same. <br>
<br>
Now we'll take the same desired behaviour from the Model I example, and
present it using the Model II methodology. This methodology follows the
Model-View-Controller (MVC) paradigm (cite Design Patterns book). For this
example, we'll have one class (or page or servlet) process the request
(Controller), get the TimeZone, set all the required variables for
presentation, and pass control off to a presentation page (View). For simple
apps like this, there is no "Model". <br>
<br>
Controller: timeByZone.jsp<br>
The controller can be a servlet or a jsp file. I prefer to use JSP, as I
don't have to worry about compiling the class each time I make changes.
However, you lose granularity this way, and make it more difficult to extend
this class later (we'll review this in Advanced JSP Programming). <br>
<br>
======================================================================<br>
<xml version="1.0" ?><br>
<!--Worker Class, nobody should see me--><br>
<jsp:scriptlet><br>
//the parameter "zone" shall be equal to a number between 0 and 24
(inclusive)<br>
TimeZone timeZone = TimeZone.getDefault(); //returns the default TimeZone
for the server<br>
if (request.getParameterValues("zone") != null)<br>
{<br>
String timeZoneArg = request.getParameterValues("zone")[0];<br>
timeZone = TimeZone.getTimeZone("GMT+" + timeZoneArg +
":00"); <br>
// gets a TimeZone. For this example we're just going to assume <br>
// its a positive argument, not a negative one.<br>
}<br>
TimeBean timeBean = new TimeBean();<br>
timeBean.setHours = myCalendar.get(Calendar.HOUR_OF_DAY);<br>
timeBean.setMinutes = myCalendar.get(Calendar.MINUTE);<br>
timeBean.setSeconds = myCalendar.get(Calendar.SECOND);<br>
HttpSession mySession = request.getSession();<br>
mySession.putValue("tempTimeBean", timeBean);<br>
<br>
</jsp:scriptlet><br>
<jsp:forward page="displayTime.jsp" /><br>
======================================================================<br>
View: displayTime.jsp<br>
Again, the view can be either a servlet or a jsp file. Here we'll get the
Bean from the Session, and display its values. We'll actually do this twice,
to illustrate again how Beans are used.<br>
<br>
<br>
======================================================================<br>
<xml version="1.0" ?><br>
<H1>Time JSP</H1><br>
<jsp:useBean class="TimeBean" id="tempTimeBean"
scope="session" /> <br>
<jsp:getProperty name="tempTimeBean"
property="hours">:<br>
<jsp:getProperty name="tempTimeBean"
property="minutes">:<br>
<jsp:getProperty name="tempTimeBean"
property="seconds"><br>
<!-- these would have printed "null" if tempTimeBean was not
instantiated by timeByZone.jsp --><br>
<br>
<jsp:scriptlet><br>
HttpSession mySession = request.getSession();<br>
TimeBean timeBean = mySession.getValue("tempTimeBean");<br>
if (timeBean != null)<br>
{ // check to make sure its not null, to avoid NullPointerExceptions<br>
out.print(timeBean.getHours());<br>
out.print(":");<br>
out.print(timeBean.getMinutes());<br>
out.print(":");<br>
out.print(timeBean.getSeconds());<br>
}<br>
else<br>
{<br>
out.println("Press your Back button and select a TimeZone");<br>
}<br>
</jsp:scriptlet><br>
======================================================================<br>
The second method (using code inside) may be more cumbersome, but allows the
developer to ensure against ugly output (such as "null:null:null
null") if the Session bean has not been instantiated & had its
values set. This would likely only happen if the client somehow called the
View page directly. The point is that using scriptlets allows for greater
control. If you are certain you can control url access, the bean approach
certainly eases development, and makes the View page easier for HTML
designers to work with. <br>
<br>
The above is the "traditional" Model II design. You'll note that
all the variables are wrapped up and placed into the Session object. This
has two weaknesses: 1) no Session is availabe because the client has refused
to participate, 2) unless the Session variable is explicitly removed it will
continue to exist until the Session is destroyed or expires. <br>
<br>
The first case is most likely to happen when cookies are used as the State
mechanism and the developers have failed to provide for the alternative form
of State maintenance, URL rewriting. <br>
<br>
The second case is even more serious, as it can lead to great memory use if
Sessions are defined to exist for more than the standard amount of time (30
minutes appears to be the standard). Even in the case of 30 minute Sessions,
this Model can lead to disastrous memory leaks in systems under great use.
Why? Objects get instantiated, set inside the Session object, and are not
removed until the Session ends. Because they still have references (the
Session object) pointing to them, they are not garbage-collected. In the
Model II pattern, many objects are placed into the Session (either directly
or via a JavaBean). As the Session progresses (more pages are accessed)
memory-use increases and persists until the client ends the Session or the
Session times out. Until the Session is invalidated, the objects placed
there cannot be garbage-collected, and thus consume memory that could be of
use elsewhere. <br>
<br>
One means of addressing this issue is to place the Beans or other variables
into the Request object, and use RequestDispatcher.include() rather than
RequestDispatcher.forward(). By doing so, the View page has access to the
same Request object as the Controller, and the weaknesses of the traditional
Model II design are obviated. <br>
<br>
One final comment: despite all the above, I have a personal distaste for the
Model II paradigm as it is commonly implemented. The creation of a system
where the client is sent to an address, but is redirected to a different
class, is for some reason abhorrent to me. For this reason, I've modified
the design in the following manner: <br>
<br>
Controller: timeByZone2.jsp<br>
As before, the controller uses the Request values to obtain the necessary
data and put that data into the Request object. The difference this time is
that the View page will call the Controller using
RequestDispatcher.include(). In this way, the client is never redirected,
and Requests are not "chained". Rather, the class/jsp called asks
someone else to do some work for it, then continues.<br>
<br>
======================================================================<br>
<xml version="1.0" ?><br>
<!--Worker Class, nobody should see me--><br>
<jsp:scriptlet><br>
//the parameter "zone" shall be equal to a number between 0 and 24
(inclusive)<br>
TimeZone timeZone = TimeZone.getDefault(); //returns the default TimeZone
for the server<br>
if (request.getParameterValues("zone") != null)<br>
{<br>
String timeZoneArg = request.getParameterValues("zone")[0];<br>
timeZone = TimeZone.getTimeZone("GMT+" + timeZoneArg +
":00"); <br>
// gets a TimeZone. For this example we're just going to assume <br>
// its a positive argument, not a negative one.<br>
}<br>
TimeBean timeBean = new TimeBean();<br>
timeBean.setHours = myCalendar.get(Calendar.HOUR_OF_DAY);<br>
timeBean.setMinutes = myCalendar.get(Calendar.MINUTE);<br>
timeBean.setSeconds = myCalendar.get(Calendar.SECOND);<br>
request.setAttribute("tempTimeBean", timeBean);<br>
</jsp:scriptlet><br>
======================================================================<br>
View: displayTime2.jsp<br>
Much like displayTime.jsp, however you'll see that timeByZone2.jsp is called
at the top of the page. Notice that the scope of <jsp:useBean /> has
changed to "request".<br>
<br>
======================================================================<br>
<xml version="1.0" ?><br>
<H1>Time JSP</H1><br>
<br>
<jsp:include page="timeByZone2.jsp" /><br>
<br>
<jsp:useBean class="TimeBean" id="tempTimeBean"
scope="request" /> <br>
<jsp:getProperty name="tempTimeBean"
property="hours">:<br>
<jsp:getProperty name="tempTimeBean"
property="minutes">:<br>
<jsp:getProperty name="tempTimeBean"
property="seconds"><br>
<!-- these would have printed "null" if tempTimeBean was not
instantiated by timeByZone2.jsp --><br>
<br>
======================================================================<br>
In a system currently under construction, we've made use of this method to
create chains of classes, each responsible for its own processing. By
identifying common presentation formats, we've created View objects that can
be reused in yet higher level JavaServer Pages. Our goal is to create pages
that are designed for reuse, and to reduce the number of presentation
classes. <br>
<br>
Single Servlet Model (A Model II Design)<br>
When I've had time to adequately research and implement this idea, I'll post
something here.
</td>
</tr>
<center>
<tr>
<td colspan="2" height="10" width="758"></td>
</tr>
</td>
</tr>
</td>
</tr>
</div>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -