困扰JSP的⼀些问题与解决⽅法
  如今每⼀个使⽤servlets的开发者都知道JSP，⼀种由Sun公司发明并花费⼤量精⼒加以推⾏并建构在servlet技术之上的web技术。JSP将servlet中的html代码脱离了出来，从⽽可以加速web应⽤开发和页⾯维护。实际上，由Sun发布的官⽅"应⽤开发模型"⽂档上说得更远： "JSP技术应该被视为标准，⽽servlets在多数情况下可视为⼀种补充。" ( Section 1.9, 1999/12/15听取意见版 )。
  本⽂的⽬的在于听取对该申明的合理性的评估 -- 通过⽐较JSP和另⼀项基于servlets的技术： template engines（模板引擎）。
  直接使⽤Servlets的问题
  起初，servlets被发明，整个世界都看到了它的优越。基于servlet的动态⽹页可以被快速执⾏，可以在多个服务器之间轻易转移，并且可以和后台数据库完美地集成。 Servlets被⼴泛接受成为⼀种web服务器端的⾸选平台。
但是，通常通过简单⽅式即可实现的html代码现在却要让程序员通过 out.println()调⽤每⼀⾏HTML⾏，这在实际的 servlet应⽤中成为了⼀个严重问题。 HTML内容不得不通过代码来实现, 对于⼤的HTML页来说不啻是⼀项繁重费时的⼯作。另外，负责⽹页内容的⼈员不得不请开发⼈员来进⾏所有的更新。为此，⼈们寻求这⼀种更好的解决⽅式。
  JSP到！
  JSP 0.90出现了。在这种技术中你可以将Java代码嵌⼊到HTML⽂件，服务器将⾃动为页⾯创建⼀个 servlet。 JSP被认为是⼀种写servlet的简易⽅式。所有HTML可以直接得到⽽不必通过out.println()调⽤，⽽负责页⾯内容的⼈员可以直接修改HTML⽽不必冒破坏Java代码的风险。
  但是，让页⾯美术设计师和开发⼈员在同⼀⽂件上⼯作并不理想，让Java嵌⼊HTML被证明是就象将HTML 嵌⼊Java⼀样令⼈尴尬。读取⼀堆很乱的代码仍然是⼀件困难的事情。
  于是，⼈们在使⽤jsp⽅⾯变得成熟，更多地使⽤了JavaBeans。 Beans包含了jsp所需的业务逻缉代码。JSP中的⼤多数代码都可以取出来放到bean中去，⽽只留下极少的标记⽤于调⽤bean。
  最近，⼈们开始认为这种⽅式下的JSP页⾯真的很象是视图（view）。它们成为⼀个⽤于显⽰客户端请求的结果的组件。于是⼈们会想，为什么不直接对view发送请求呢？⽬标view如果对该请求不合适⼜将如何？说到底，很多的请求有多种可能来取得结果view视图。例如，同⼀请求可能产⽣成功的页⾯，数据库例外出错报告，或者是缺少参数的出错报告。同⼀请求可能产⽣⼀个英⽂页⾯也可能是西班⽛⽂页⾯，这取决于客户端的locale。为什么客户端必须直接将请求发送给view?为什么客户端不应该将请求发送给⼀些通⽤的服务器组件并让服务器来决定JSP view的返回?
  这使很多⼈接受了已被称为"Model 2"的设计, 这是在JSP 0.92中定义的基于model-view-controller的模型。在这种设计中，请求被发送到⼀个servlet控制器，它执⾏了商业逻缉并产⽣⼀个相近的数据"model"来⽤于显⽰。这⼀数据随后通过内部送到⼀个JSP "view"来进⾏显⽰，这样看起来JSP页就象是⼀个普通的嵌⼊的JavaBean。可以根据负责控制的servlet的内部逻辑来选择适当的JSP页⾯进⾏显⽰。这样，JSP⽂件成为了⼀个漂亮的template view。这就是另⼀种发展，并被另外⼀些开发者所推崇⾄今.
  进⼊Template Engines
  问题 #1: Java代码太模板化了
  虽然被认为是不好的设计，JSP仍试图将Java代码加⼊web页⾯。这有些象是Java曾经做的，即对C++的简化修
改，template engines也通过将jsp中的较低层的源码移去来使之简化。Template engines实⾏了更好的设计。
  问题 #2: 要求Java代码
  在JSP页中要求写⼀些Java代码。例如，假设某页要决定当前web应⽤中根的上下⽂从⽽导向其主页，
在JSP中最好使⽤如下Java代码：
  ＜a href="＜%= ContextPath() %＞/index.html"＞Home page＜/a＞
  你可以试图避免 Java代码，⽽使⽤＜jsp:getProperty＞标记但这将给你六下难以阅读的字串：
  ＜a href="＜jsp:getProperty name="request"
  property="contextPath"/＞/index.html"＞HomePage＜/a＞
  使⽤template engine则没有Java代码和难看的语法。这⾥是同样要求下在WebMacro中的写法：
  ＜a href="$Request.ContextPath;/index.html"＞Home page＜/a＞
  在WebMacro中, ContextPath 作为 $Request变量的⼀个属性，使⽤类似Perl的语法。其它er template engines使⽤了其
它的语法类型。
  再看另⼀个例⼦，假设⼀个⾼级的"view"需要设定⼀个cookie来记录⽤户缺省的颜⾊配置 -- 这种任务看起来⼤概只能由view⽽不是servlet控制器来完成。在JSP中要有这样的Java代码：
  ＜% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c); %＞
  在WebMacro中则没有Java代码：
  #set $lorscheme = "blue"
  作为最后⼀个离⼦，假如⼜要重新回原来的cookie中的颜⾊配置。对于JSP，我们可以认为也有⼀个相应的⼯具类来提供帮助，因为⽤getCookies()直接做这样低层的会变得可笑⽽且困难。在JSP中：
  ＜% String colorscheme = Cookie(request, "colorscheme"); %＞
  在WebMacro中没有对⼯具类的需要，通常是：$lorscheme.Value ．对写jsp的图形艺术师，⼜是哪⼀种语法更容易学习呢？
  JSP 1.1 引⼊了⾃定义标记（custom tags）允许任意的和HTML相似的标记在JSP页⾯中在后台执⾏Java代码，这将具有⼀定的价值，但前提是要有⼀个⼴泛知晓的，全功能的，可以免费得到的，标准化的标记库。⽬前还没有出现这样的标记库。
  问题 #3: 简单⼯作仍然很累⼈
  即使是很简单的⼯作，例如包含 header和 footer，在JSP中仍然很很困难。假设有⼀个 "header"和⼀个 "footer"模板要包含到所有页⾯，⽽每⼀个模板要在content中包含当前的页标题。
在JSP中最佳办法是：
  ＜% String title = "The Page Title"; %＞
  ＜%@ include file="/header.jsp" %＞
  ...你的页⾯内容...
  ＜%@ include file="/footer.jsp" %＞
  页⾯设计者要记住不能遗漏第⼀⾏的分号并要将title定义为⼀个字符串。此外， /header.jsp和/footer.jsp必须在根⽬录下并且必须是可存取的完整⽂件。
  在WebMacro中包含headers和footers做起来⽐较简单：
  #set $title = "The Page Title"
  #parse "header.wm"
  Your content here
  #parse "footer.wm"
  这⾥对设计者来说没有要牢记的分号或对title的定义， .wm⽂件可以放在可⾃定义的搜索路径下。
  问题 #4: 很粗的循环
  在JSP中循环很困难。这⾥是⽤JSP重复打印出每⼀个ISP对象名字。
  ＜%
  Enumeration e = list.elements();
  while (e.hasMoreElements()) {
  out.print("The next name is ");
  out.println(((Element()).getName());
  out.print("＜br＞");
  }
java和jsp  %＞
  也许什么时候会有⽤户⾃定义标记来做这些循环。对"if"也是如此。JSP页可能看上去成了很古怪的java代码。⽽同
时，webmacro循环很漂亮：
  #foreach $isp in $isps {
  The next name is $isp.Name ＜br＞
  }
  如果必要的话，#foreach指令可被⾃定义的 #foreach-backwards指令很容易地取代。
  ⽤jsp的话很可能变这样：（这⾥是⼀个可能的＜foreach＞标记）
  ＜foreach item="isp" list="isps"＞
  The next name is ＜jsp:getProperty name="isp" property="name"/＞＜br＞
  ＜/foreach＞
  设计者当然地回选择前者。
  问题 #5: ⽆⽤的出错信息
  JSP常有⼀些令⼈惊讶的出错信息。这是因为页⾯⾸先被转换成为⼀个servlet然后才进⾏编译。好的JSP ⼯具可以相对增加到出错位置的可能性，但即使是最好的⼯具也⽆法使所有出错信息都能容易地被读懂。由于转化的过程，⼀些错误对⼯具来说可能根本不可能被识别。
例如，假设JSP页⾯需要建⽴⼀个对所有页通⽤的标题。以下代码并没有错：
  ＜% static String title = "Global title"; %＞
  但Tomcat会提供以下出错信息：
  work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Statement expected.
  static int count = 0;
  ^
  此信息认为以上脚本被放⼊ _jspService()⽅法⽽静态变量不允许放⼊⽅法中。该语法应该是＜%! %＞。页⾯设计者很难读懂这些出错信息。即使最好的平台在这⽅⾯也做得很不够。即使所有 Java代码都从页中移出也⽆法解决问题。另外，以下表达式有什么错？
  ＜% count %＞
  tomcat给出：
  work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: Class count not found in
  type declaration.
  count
  ^
  work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Invalid declaration.
  out.write("\r\n");
  ^
  换句话说，只是遗失了⼀个标记⽽已。应该是＜%= count %＞。
  由于template engine可以在template⽂件中直接产⽣⽽没有任何戏剧性的向代码转化，所以可以⾮常容易地给出适当的出错报告。依次类推，当c语⾔的命令被打⼊Unix shell的命令⾏，你并不希望shell 会⽣成⼀个C程序来运⾏这个命令，⽽只是需要shell简单地解释命令并加以执⾏，如有错误也直接给出。
  问题 #6: 需要⼀个编译器
  JSP需要⼀个置放在webserver中的编译器。由于Sun拒绝放弃包含了他们的javac编译器的tools.jar库，这其中就变得有问题了。Web服务器可以包含进⼀个第三⽅的编译器如ibm的 jikes。但这样的编译器并不能在所有平台上顺利⼯作(⽤ C++写成的) 也不利于建⽴纯Java 的web服务器。 JSP有⼀个预编译选项可以起到⼀定作⽤，尽管并不完美。
  问题 #7: 空间的浪费
  JSP消耗了额外的内存和硬盘空间。对服务器上每30K的JSP⽂件，必须要有相应的⼤于30K的类⽂件产⽣。实际上使得硬盘空间加倍。考虑到JSP⽂件随时可以很容易地通过＜%@ include＞包含⼀个⼤的数据⽂件，这样的关注有着很现实的意义。同时，每⼀个JSP的类⽂件数据必须加载到服务器的
内存中，这意味着服务器的内存必须永远地将整个JSP⽂档树保存下去。少数⼀些JVM有能⼒将类⽂件数据从内存中移去；但是，程序员通常⽆法控制这样的规则来重新申明，⽽且对⼤的站点来说重新申明可能不是很有效。对template engines由于没有产⽣第⼆个⽂件，所以节省了空间。Template engines还为程序员提供对templates在内存中进⾏缓存的完全控制。
  使⽤template engine也有⼀些问题：
  Template的问题 #1: 没有严格定义
  template engine该如何⼯作并没有严格定义。可是，但相对jsp来说，其实这并不很重要，和 JSP不同的是，template engines对web服务器没有任何特殊要求 -- 任何⽀持servlet的服务器都可以⽀持template engines (包括API 2.0服务器如Apache/JServ，它们并不能完全⽀持 JSP)! 如果为最好的template engine设计提供健康的竞争本可以引起⼀场耀眼的⾰新，特别是有开放源码的促进，（可以让思想相互推动和促进），那么今天的WebMacro就会象Perl⼀样，没有严格定义但公开源码组织的推动就是它的标准。
  Template的问题 #2: 没有获得公认
  Template engines并未被⼴泛知晓。JSP已经占据了极⼤的商业市场，并且深⼊⼈⼼。⽽使⽤g template engines只能是
⼀种未被了解的替代技术。
  Template的问题 #3: 尚未调配好
  Template engines还没有被⾼度地调配好。没有对template engine 和JSP两者进⾏性能测试和⽐较。理论上说⼀个调配完好的template engine实现应该和⼀个调配好的JSP相匹配；但是，考虑到第三⽅为jsp已经作出了这么深远的推动，结果只有jsp被很好地调配好了。
  JSP的⾓⾊
  当然地，JSP在将来必然会有其地位。即使从名称上也可以看出JSP和ASP的相似性，它们只有⼀个字母的差别。所以如果要让使⽤asp的⼈们转向java,⾮常相似的jsp环境将对此起到很⼤的推动作⽤，和asp保持这种对应关系所能起到的作⽤应该也是被推出jsp的设计者重点考虑到的。
然⽽这⾥想要强调的⼀点是：有利于转⼊新环境的⼯作者，以及实际上是否是使⽤该环境的最佳⽅式，这两者是有很⼤不同的。
  JSP⽇益显⽰出它正成为最重要的java技术之⼀，它让⼈们离开ASP的世界 -- 由此，Sun将⽀持这⼀强有⼒的商业case, Java相关技术⽀持者也将给予更⼤⼒的⽀持。
  可是，这并⾮java平台的最佳解决⽅案。这将使java解决⽅案变得好象是没有java的解决⽅案了。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。