50.html

Jsp精华文章合集,JSP方面各种知识介绍

property="contextPath"/&gt;/index.html"&gt;HomePage&lt;/a&gt;<br>
Using a template engine there's no Java code and no ugly syntax. Here's the same command written in WebMacro: <br>
<br>
&lt;a href="$Request.ContextPath;/index.html"&gt;Home page&lt;/a&gt;<br>
In WebMacro, ContextPath is seen as a property of the $Request variable, accessed using a Perl-like syntax. Other template engines use other syntax styles. <br>
<br>
An another example where JSP requires Java code in the page, assume an advanced "view" needs to set a cookie to record the user's default color scheme -- a task that presumably should be done by the view and not the servlet controller. In JSP it requires Java code: <br>
<br>
&lt;% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %&gt;<br>
In WebMacro there's no Java code: <br>
<br>
#set $Cookie.colorscheme = "blue"<br>
<br>
As a last example, assume it's time to retrieve the color scheme cookie. For the benefit of JSP, we can presume also there's a utility class available to help since doing this raw with getCookies() is ridiculously difficult. In JSP: <br>
<br>
&lt;% String colorscheme = ServletUtils.getCookie(request, "colorscheme"); %&gt;<br>
In WebMacro there's no need for a utility class and it's always: <br>
<br>
$Cookie.colorscheme.Value<br>
For graphics artists writing JSP pages, which syntax would be simpler to learn? <br>
JSP 1.1 introduced custom tags (allowing arbitrary HTML-like tags to appear in JSP pages executing Java code on the backend) which may help with tasks like this, assuming there becomes a widely known, fully featured, freely available, standardized tag library. So far that has yet to occur. <br>
<br>
Problem #3: Simple Tasks are Hard<br>
Doing even a simple task such as header and footer includes is overly difficult with JSP. Assume there's a "header" template and a "footer" template to be included on all pages, and each template includes in its content the current page title. <br>
In JSP the best way to do this is as follows: <br>
<br>
&lt;% String title = "The Page Title"; %&gt;<br>
&lt;%@ include file="/header.jsp" %&gt;<br>
Your content here<br>
&lt;%@ include file="/footer.jsp" %&gt;<br>
<br>
Page creators must not forget the semi-colon in the first line and must make sure to declare title as a Java String. Plus, the /header.jsp and /footer.jsp must be made publicly accessible somewhere under the document root even though they aren't full pages themselves. <br>
In WebMacro including headers and footers is done easily: <br>
<br>
#set $title = "The Page Title"<br>
#parse "header.wm"<br>
Your content here<br>
#parse "footer.wm"<br>
<br>
There are no semi-colons or String types for designers to remember, and the .wm files are found in a customizable search path, not under the document root. <br>
Problem #4: Lousy Looping<br>
Looping is overly difficult in JSP. Here's the JSP code to iterate over a vector of ISP objects printing the name of each. <br>
&lt;%<br>
Enumeration e = list.elements();<br>
while (e.hasMoreElements()) {<br>
out.print("The next name is ");<br>
out.println(((ISP)e.nextElement()).getName());<br>
out.print("&lt;br&gt;");<br>
}<br>
%&gt;<br>
<br>
Someday there will be custom tags for doing these loops. And custom tags for "if" checks too. And JSP pages may look like a grotesque Java reimplemented with tags. But meanwhile, the webmacro loop is already quite nice: <br>
#foreach $isp in $isps {<br>
The next name is $isp.Name &lt;br&gt;<br>
}<br>
<br>
The #foreach directive could be replaced by a custom #foreach-backwards directive fairly easily as well if such a thing were necessary. <br>
Will custom tags really solve this problem? Probably not. Here's a possible &lt;foreach&gt; tag. <br>
<br>
&lt;foreach item="isp" list="isps"&gt;<br>
The next name is &lt;jsp:getProperty name="isp" property="name"/&gt; &lt;br&gt;<br>
&lt;/foreach&gt;<br>
<br>
Which would a graphics artist prefer? <br>
Problem #5: Useless Error Messages<br>
JSP page syntax errors can cause surprisingly odd and useless error messages. This is due to the fact the page is transformed into a servlet and then compiled. Good JSP tools can help narrow down errors to likely syntax error locations, but even the best of tools will probably have problems making all error messages meaningful. Some errors will just be impossible for tools to diagnose, due to the transformation. <br>
For example, assume a JSP page needs to set a title common across all pages. What's wrong with the following? <br>
<br>
&lt;% static String title = "Global title"; %&gt;<br>
<br>
Well, the Tomcat reference implementation for JSP says this is wrong: <br>
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected.<br>
static int count = 0;<br>
^<br>
This cryptic error is trying to say that scriptlets like the above are placed inside the _jspService() method and static variables aren't allowed inside methods. The syntax should be &lt;%! %&gt;. Page designers won't recognize this error, and programmers likely won't either without looking at the generated source. Even the best tools probably won't be much help with errors such as these. <br>
Assuming all the Java code could be moved out of the page, that still doesn't solve this problem. What's wrong with this expression that prints the value of count? <br>
<br>
&lt;% count %&gt;<br>
<br>
The Tomcat engine says: <br>
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: Class count not found in<br>
type declaration.<br>
count <br>
^<br>
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Invalid declaration.<br>
out.write("\r\n");<br>
^<br>
In other words, there's an equal sign missing. It should be &lt;%= count %&gt;. <br>
Because a template engine can operate directly on the template file without any "magical" translation to code, it's far easier to properly report errors. To use an analogy: When commands are typed into a command line Unix shell written in C, you don't want the shell to create a C program to execute the command. You want the shell to simply interpret the command and behave accordingly, with direct error messages when necessary. <br>
<br>
Problem #6: Need a Compiler<br>
JSP requires a compiler be shipped with the webserver. That's problematic, especially since Sun doesn't give away the tools.jar library containing their javac compiler. Web servers can package an outside vendor's compiler such as IBM's jikes; however such compilers generally don't work on all platforms and (being written in C++) aren't much help to a pure-Java web server. JSP has a pre-compile option that can help some here, although that's a less than elegant solution. <br>
Problem #7: Wasted Space<br>
JSP consumes extra hard drive space and extra memory space. For every 30K JSP file on the server there must be a corresponding larger-than-30K class file created. This essentially doubles the hard drive requirements to store JSP pages. Considering how easily a JSP file can &lt;%@ include&gt; a large data file for display, this becomes a real concern. Also, each JSP's class file data must be loaded into the server's memory, meaning the server may eventually store the entire JSP document tree in memory. A few JVMs have the ability to remove class file data from memory; however, the programmer generally has no control over the rules for reclaiming and for large sites the reclaiming probably won't be aggressive enough. With template engines there's no need to duplicate the page data into a second file, so hard drive space is spared. Template engines also give the programmer full control over how templates are cached in memory. <br>
There are also some downsides to using a template engine: <br>
<br>
Template Problem #1: No Specification<br>
No specification exists for how a template engine should behave. However, it's interesting to note that this is far less important than with JSP because, unlike JSP, template engines demand nothing special of the web server -- any server supporting servlets supports template engines (including API 2.0 servers like Apache/JServ which can't fully support JSP)! Healthy competition for the best template engine design could actually spark innovation, especially assuming open source implementations that can leverage each other's ideas and code. As it stands now, WebMacro exists like Perl, a tool where the open source implementation is the specification. <br>
Template Problem #2: Not Widely Known<br>
Template engines aren't widely known. JSP has had a tremendous amount of marketing and has gained terrific mind share. Using template engines is a relatively unknown alternative technique. <br>
Template Problem #3: Not Yet Tuned<br>
Template engines have yet to be highly tuned. No performance numbers have been taken comparing template engine and JSP performance. Theoretically a well tuned implementations of a template engine should match a tuned implementation of JSP; however in the world today, considering the effort third party vendors have given to JSP so far, the odds are good that JSP implementations are better tuned. <br>
The Role of JSP<br>
So is there a place for JSP in the future? Certainly. JSP is entirely relevant if what you're trying to do is wean people off of ASP. There's an extremely strong argument for providing something familiar looking in a new environment. This was one of the big motivations behind the creation of JSP, and that shows from the name -- it's no coincidence "JSP" is just one letter off from "ASP". <br>
Yet there's a difference between what's suitable to someone who is new to an environment, and what's actually the best way to use that environment. <br>
<br>
JSP is going to turn out to be one of the most important Java technologies for convincing people to leave the ASP world in favor of Java -- and hence there's a strong business case for Sun supporting it, and for any Java booster to support it. <br>
<br>
However, that doesn't make it the best solution for the Java platform. That makes it the Java solution that is most like the non-Java solution. <br>
<br>
</p>
</td>
  </tr>
</table>

<p>
<CENTER><a href="http://www.jsp001.com/forum/newreply.php?action=newreply&threadid=50">点这里对该文章发表评论</a></CENTER>
<p>该文章总得分是 <font color=red>0</font> 分，你认为它对你有帮助吗？
				[<a href=javascript:void(0) onclick=window.open("http://www.jsp001.com/forum/codeVote.php?threadid=50&intVote=4","","menubar=no,toolbar=no,location=no,directories=no,status=no,resizable=no,scrollbars=no,width=70,height=40,top=0,left=0")>非常多</a>](<font color=red>0</font>) 
				[<a href=javascript:void(0) onclick=window.open("http://www.jsp001.com/forum/codeVote.php?threadid=50&intVote=2","","menubar=no,toolbar=no,location=no,directories=no,status=no,resizable=no,scrollbars=no,width=70,height=40,top=0,left=0")>有一些</a>](<font color=red>0</font>) 
				[<a href=javascript:void(0) onclick=window.open("http://www.jsp001.com/forum/codeVote.php?threadid=50&intVote=1","","menubar=no,toolbar=no,location=no,directories=no,status=no,resizable=no,scrollbars=no,width=70,height=40,top=0,left=0")>无帮助</a>](<font color=red>0</font>) 
				[<a href=javascript:void(0) onclick=window.open("http://www.jsp001.com/forum/codeVote.php?threadid=50&intVote=-1","","menubar=no,toolbar=no,location=no,directories=no,status=no,resizable=no,scrollbars=no,width=70,height=40,top=0,left=0")>是灌水</a>](<font color=red>0</font>) </p>
<script language="javascript" src="http://www.jsp001.com/include/read_thread_script.php?threadid=50"></script>
<p><CENTER>
Copyright &copy; 2001 - 2009 JSP001.com . All Rights Reserved <P>

<IMG SRC="../image/jsp001_small_logo.gif" WIDTH="85" HEIGHT="30" BORDER=0 ALT="">
</CENTER></p>

</body>
</html>