50.html

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

在JSP中循环很困难。这里是用JSP重复打印出每一个ISP对象名字。 <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>
也许什么时候会有用户自定义标记来做这些循环。对"if"也是如此。JSP页可能看上去成了很古怪的java代码。而同时，webmacro循环很漂亮： <br>
#foreach $isp in $isps {<br>
The next name is $isp.Name &lt;br&gt;<br>
}<br>
<br>
如果必要的话，#foreach指令可被自定义的 #foreach-backwards指令很容易地取代。 <br>
用jsp的话很可能变这样：（这里是一个可能的 &lt;foreach&gt;标记） <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>
设计者当然地回选择前者。<br>
<br>
<br>
问题 #5: 无用的出错信息<br>
<br>
<br>
JSP常有一些令人惊讶的出错信息。这是因为页面首先被转换成为一个servlet然后才进行编译。好的JSP 工具可以相对增加找到出错位置的可能性，但即使是最好的工具也无法使所有出错信息都能容易地被读懂。由于转化的过程，一些错误对工具来说可能根本不可能被识别。 <br>
例如，假设JSP页面需要建立一个对所有页通用的标题。以下代码并没有错： <br>
<br>
&lt;% static String title = "Global title"; %&gt;<br>
<br>
但Tomcat会提供以下出错信息： <br>
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected.<br>
static int count = 0;<br>
^<br>
<br>
此信息认为以上脚本被放入 _jspService()方法而静态变量不允许放入方法中。该语法应该是 &lt;%! %&gt;。页面设计者很难读懂这些出错信息。即使最好的平台在这方面也做得很不够。即使所有 Java代码都从页中移出也无法解决问题。另外，以下表达式有什么错？ <br>
<br>
&lt;% count %&gt;<br>
tomcat给出： <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>
<br>
换句话说，只是遗失了一个标记而已。应该是 &lt;%= count %&gt;。<br>
<br>
 <br>
由于template engine可以在template文件中直接产生而没有任何戏剧性的向代码转化，所以可以非常容易地给出适当的出错报告。  依次类推，当c语言的命令被打入Unix shell的命令行， 你并不希望shell 会生成一个C程序来运行这个命令，而只是需要shell简单地解释命令并加以执行，如有错误也直接给出。 <br>
问题 #6: 需要一个编译器<br>
<br>
<br>
JSP需要一个置放在webserver中的编译器。由于Sun拒绝放弃包含了他们的javac编译器的tools.jar库， 这其中就变得有问题了。Web服务器可以包含进一个第三方的编译器如ibm的 jikes。但这样的编译器并不能在所有平台上顺利工作(用 C++写成的) 也不利于建立纯Java 的web服务器。 JSP有一个预编译选项可以起到一定作用，尽管并不完美。<br>
<br>
 <br>
问题 #7: 空间的浪费<br>
<br>
<br>
JSP消耗了额外的内存和硬盘空间。对服务器上每30K的JSP文件，必须要有相应的大于30K的类文件产生。实际上使得硬盘空间加倍。考虑到JSP文件随时可以很容易地通过 &lt;%@ include&gt;包含一个大的数据文件，这样的关注有着很现实的意义。同时，每一个JSP的类文件数据必须加载到服务器的内存中，这意味着服务器的内存必须永远地将整个JSP文档树保存下去。少数一些JVM有能力将类文件数据从内存中移去；但是，程序员通常无法控制这样的规则来重新申明，而且对大的站点来说重新申明可能不是很有效。对template engines由于没有产生第二个文件，所以节省了空间。Template engines还为程序员提供对templates在内存中进行缓存的完全控制。<br>
<br>
<br>
使用template engine也有一些问题： <br>
<br>
Template的问题 #1: 没有严格定义<br>
<br>
<br>
template engine该如何工作并没有严格定义。可是，但相对jsp来说，其实这并不很重要，和 JSP不同的是，template engines对web服务器没有任何特殊要求 -- 任何支持servlet的服务器都可以支持template engines (包括API 2.0服务器如Apache/JServ，它们并不能完全支持 JSP)! 如果为最好的template engine设计提供健康的竞争本可以引起一场耀眼的革新，特别是有开放源码的促进，（可以让思想相互推动和促进），那么今天的WebMacro就会象Perl一样，没有严格定义但公开源码组织的推动就是它的标准。<br>
<br>
 <br>
Template的问题 #2: 没有获得公认<br>
<br>
<br>
Template engines并未被广泛知晓。JSP已经占据了极大的商业市场，并且深入人心。而使用g template engines只能是一种未被了解的替代技术。 <br>
<br>
<br>
Template的问题 #3: 尚未调配好<br>
<br>
<br>
Template engines还没有被高度地调配好。没有对template engine 和JSP两者进行性能测试和比较。理论上说一个调配完好的template engine实现应该和一个调配好的JSP相匹配；但是，考虑到第三方为jsp已经作出了这么深远的推动，结果只有jsp被很好地调配好了。 <br>
<br>
<br>
JSP的角色<br>
<br>
<br>
当然地，JSP在将来必然会有其地位。即使从名称上也可以看出JSP和ASP的相似性，它们只有一个字母的差别。所以如果要让使用asp的人们转向java,非常相似的jsp环境将对此起到很大的推动作用，和asp保持这种对应关系所能起到的作用应该也是被推出jsp的设计者重点考虑到的。 <br>
然而这里想要强调的一点是：有利于转入新环境的工作者，以及实际上是否是使用该环境的最佳方式，这两者是有很大不同的。 <br>
<br>
JSP日益显示出它正成为最重要的java技术之一， 它让人们离开ASP的世界 -- 由此，Sun将支持这一强有力的商业case, Java相关技术支持者也将给予更大力的支持。 <br>
<br>
可是，这并非java平台的最佳解决方案。这将使java解决方案变得好象是没有java的解决方案了。<br>
<br>
<br>
原文如下：<br>
<br>
The Problems with JSP <br>
January 25, 2000 <br>
by Jason Hunter (www.servlets.com/soapbox/problems-jsp.html<br>
<br>
By now almost everyone using servlets has heard about JavaServer Pages (JSP), a Sun-invented technology built on top of servlets. Sun has done a marvelous job promoting JSP as a way to get HTML out of servlet code, speeding web application development and improving web page maintenance. In fact, the official "Application Programming Model" document published by Sun has gone so far as to say, "JSP technology should be viewed as the norm while the use of servlets will most likely be the exception." (Section 1.9, December 15, 1999, Draft Release) This paper evaluates whether that claim is valid -- by comparing JSP to another technology built on servlets: template engines. <br>
<br>
The Problem with Straight-up Servlets<br>
In the beginning, servlets were invented, and the world saw that they were good. Dynamic web pages based on servlets executed quickly, could be moved between servers easily, and integrated well with back-end data sources. Servlets became widely accepted as a premiere platform for server-side web development. <br>
However, the commonly-used simple approach to generating HTML content, having the programer write an out.println() call per HTML line, became a serious problem for real servlet use. HTML content had to be created within code, an onerous and time consuming task for long HTML pages. In addition, content creators had to ask developers to make all content changes. People searched for a better way. <br>
<br>
Along Comes JSP<br>
Around this time JSP 0.90 came along. With this new technology you could put snippets of Java code inside your HTML, and the server would automatically create a servlet from the page. This helped quite a lot. There was no attempt to hide the Servlet API; JSP was considered a "cheap" way for a Java programmer to write a servlet. All the HTML code could be included directly without out.println() calls and page creators could make changes to the HTML without serious risk of breaking the Java code. <br>
But having artists and developers working on the same file wasn't ideal, and having Java inside HTML proved almost as awkward as having HTML inside Java. It could easily create a hard to read mess. <br>
<br>
So people matured in their use of JSP and started to rely more on JavaBeans. Beans were written to contain business logic code needed by the JSP page. Much of the code inside the JSP page could be moved out of the page into the bean with only minimal hooks left behind where the page would access the bean. <br>
<br>
More recently, people have started to note that JSP pages used this way are really a "view". They're a component used to display the results of a client request. So people thought, Why submit a request directly to a "view"? What if the targetted "view" isn't the proper view for that request? After all, many requests have several possible resulting views. For example, the same request might generate a success page, a database exception error report, or a required parameter missing error report. The same request might also generate a page in English or a page in Spanish, depending on the client's locale. Why must a client directly submit its request to a view? Shouldn't the client make a request to some general server component and let the server determine the JSP view to return? <br>
<br>
This belief caused many people to adopt what has been called the "Model 2" design, named after an architecture laid out in the JSP 0.92 specification and based on the model-view-controller pattern. With this design, requests are submitted to a servlet "controller" that performs business logic and generates an appropriate data "model" to be displayed. This data is then passed internally to a JSP page "view" for rendering, where it appears to the JSP page like a normal embedded JavaBean. The appropriate JSP page can be selected to do the display, depending on the logic inside the controlling servlet. The JSP page becomes a nice template view. This was another improvement -- and where many serious developers stand today. <br>
<br>
Enter Template Engines<br>
But why suffer the complexity of JSP just to do templating? Might it not be better to use a dedicated template engine? By using a template engine intended for this exact use instead of the general-purpose JSP, the underlying design can be cleaner, the syntax clearer, the error messages more meaningful, and the tool more customizable. Several companies have built such engines, the most popular probably being WebMacro (http://webmacro.org, from Semiotek) whose engine is free. <br>
Using a dedicated template engine instead of JSP offers several technical advantages that developers should be aware of: <br>
<br>
Problem #1: Java Code Too Tempting<br>
JSP makes it tempting to put Java code in the web page, even though that's considered bad design. Just as Java improves on C++ by removing the ability to use global variables and multiple inheritance, so do template engines improve on JSP by removing the ability to put raw code in the page. Template engines enforce good design. <br>
Problem #2: Java Code Required<br>
Doing mundane things in JSP can actually demand putting Java code in the page. For example, assume the page needs to determine the context root of the current web application to create a link to the web app home page: <br>
In JSP this is best done using Java code: <br>
<br>
&lt;a href="&lt;%= request.getContextPath() %&gt;/index.html"&gt;Home page&lt;/a&gt;<br>
You can try to avoid Java code using the &lt;jsp:getProperty&gt; tag but that leaves you with the following hard-to-read string: <br>
<br>
&lt;a href="&lt;jsp:getProperty name="request"<br>