困扰JSP的一些问题与解决方法--.doc

　　困扰JSP的一些问题与解决方法 如今每一个使用servlets的开发者都知道JSP，一种由Sun公司发明并花费大量精力加以推行并建构在servlet技术之上的l代码脱离了出来，从而可以加速plate engines（模板引擎）。 　　直接使用Servlets的问题 　　起初，servlets被发明，整个世界都看到了它的优越。基于servlet的动态网页可以被快速执行，可以在多个服务器之间轻易转移， 并且可以和后台数据库完美地集成。 Servlets被广泛接受成为一种l代码现在却要让程序员通过 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页面真的很象是视图（vieodel-vieodel来用于显示。这一数据随后通过内部送到一个JSP vieplate vieplate Engines 　　使用template engine来代替通常目的的JSP, 接下去的设计将变得简单，语法更简单，出错信息更易读，工具也更用户化。 一些公司已经做了这样的引擎，最著名的可能是acro (acro.org, from Semiotek)，他们的引擎是免费的。 　　开发者应该明了，选定一个template engine来取代JSP提供了这么一些技术优势，这也正是jsp的一些不足之处： 　　问题 #1: Java代码太模板化了 　　虽然被认为是不好的设计，JSP仍试图将Java代码加入plate engines也通过将jsp中的较低层的源码移去来使之简化。Template engines实行了更好的设计。 　　问题 #2: 要求Java代码 　　在JSP页中要求写一些Java代码。例如，假设某页要决定当前l＞Home page＜/a＞ 　 　　你可以试图避免 Java代码，而使用 ＜jsp:getProperty＞ 标记但这将给你六下难以阅读的字串： 　　＜a href=＜jsp:getProperty name=request 　　property=contextPath/＞/index.html＞HomePage＜/a＞ 　　使用template engine则没有Java代码和难看的语法。这里是同样要求下在acro中的写法： 　　＜a href=.ContextPath;/index.html＞Home page＜/a＞ 　　在acro中, ContextPath 作为 template engines使用了其它的语法类型。 　　 　　再看另 一个例子，假设一个高级的viee, blue); response.addCookie(c); %＞ 　　在acro中则没有Java代码： 　　#set .colorscheme = blue 123下一页 这篇文章来自..，。作为最后一个离子，假如又要重新找回原来的cookie中的颜色配置。对于JSP，我们可以认为也有一个相应的工具类来提供帮助，因为用getCookies()直接做这样低层的会变得可笑而且困难。在JSP中： 　　＜% String colorscheme = ServletUtils.getCookie(request, colorscheme); %＞ 　　在acro中没有对工具类的需要，通常是：.colorscheme.Value ．对写jsp的图形艺术师，又是哪一种语法更容易学习呢？ 　　JSP 1.1 引入了自定义标记（custom tags）允许任意的和HTML相似的标记在JSP页面中在后台执行Java代码，这将具有一定的价值，但前提是要有一个广泛知晓的，全