当你在浏览器中键入URL来执行
JSP时,
JSP在以HTML的形式提交给用户之前需要经历一系列的处理。正是因为这些处理,因此当第一次请求
JSP的时候需要的时间要比其后对这个
JSP页面的访问需要的时间要长很多。很多的开发人员都知道在发布的时候预编译
JSPs的重要性,同样的,在开发阶段进行预编译也是很有用的。
你可以在编译代码的阶段,在编译与
JSP相关的javabean、自定义标签处理类(custom tag handler classes)、其他一些相关的类以及servlet的同时预编译
JSP。这样只需要进行一次的编译,减少了某一个时间内需要的编译的时间。对于开发人员来说,这非常有好处,因为在等待编译的时候,他们很容易分心。因此一次性的进行所以的编译相对与只是在请求
JSP的时候才进行编译是很有好处的。
预编译可以发现语法问题(parser problem)以及其他一些翻译时期(translation-time)出现的问题。这些问题通常需要多个步骤才能够定位。这样对于开发人员来说是有意义的,这样开发人员就不需要通过浏览多个页面后才可以定位存在问题的页面了。如果使用
JSP document.话,那么还可以在预编译的时候来验证
JSP document.结构。
预编译的另一个好处是可以在发布的war文件中包含你的编译了的
JSP版本,而不是实际的
JSP源代码。
JSP进行编译后,就可以以.class文件包含在发布的产品中(这些.class文件名满足容器的供应商特定的命名约定)。
大多数的Java 2平台,J2EE以及一些java工具都支持
JSP预编译,专业的网络容器也支持
JSP预编译,尽管可能是通过一种非标准的命令或者界面。许多的网络容器都支持命令行形式的
JSP预编译,你可以在你的scripted builds中加入这些命令行。
组织文件和目录
下面的技术有助于
JSP的开发与维护,能够使得你的
JSP开发和维护更容易和高效:
l 组织Web的根目录
l 组织好WEB-INF目录,合理的使用子目录
l 以.
JSPf的扩展名来标识
JSP fragments(需要被include在其他
JSP页面中的
JSP文件,译者注)
l 使用IDE,ANT,以及其他一些自动生成工具
组织Web的根目录
你可以通过将所有的Web应用所有的文件直接的放到web的根目录下面,这个目录就是WEB-INF目录所在的目录。我推荐合理的组织这个目录,比方说在其中加入
JSP,html,css以及css等子目录。对于简单的应用来说,是否需要这样来划分目录还有争议但是对于大的网络应用来可以增强理解以及维护性能。
组织WEB-INF目录
标签酷是在
JSP开发中很有价值的资源。大的网络应用可能包含有几个标签库比方说:JSTL标签库、Struts标签库以及其他的一些标签库。我推荐在WEB-INF目录下面建立一个tld子目录来存放这些标签库而不是将这些标签库放在WEB-INF目录下面。这样可能会“淹没”了这个目录。
以.
JSPf的扩展名来标识
JSP fragments
在最近版本的
JSP规范中的
JSP segments(以前版本称为
JSP fragments)即.
JSPf文件是不完整的
JSPs,是用来被其他的
JSP来包含的。
JSP规范建议使用命名规范来区别“外层”的
JSPs和
JSP fragments/segments。通常将命名完整的“外层”的文件以“.
JSP”为扩展名,而
JSP fragments/segments以“.
JSPf”为扩展名,但是规范并没有要求这样做。我同样推荐将完整和“外层”的
JSPs放在一个不同的目录下面。
使用IDE,ANT及其他的一些自动工具
IDEs可以加速开发和部署的时间,并且减少书写以及其他的一些错误。有许多的IDE工具提供了J2EE工具和向导。这些工具同样同一些框架相集成(如Struts和JSTL标签库)。
Ant是defacto标准的创建和部署java和j2ee应用的工具。Ant提供了创建和部署应用时很多有用的特性,同样也支持创建和部署war以及ear文件。许多工具内嵌支持Ant。当不能使用IDEs时,我任务Ant时必不可少的。其他一些工具也可能支持自动创建和部署,也能提供ant提供的特性,但是ant一个最重要的特点就在于它的费用(免费)以及它支持很广泛。
同样我推荐Apache的Apache Maven,在考虑管理整个java项目时它也是一个很有用的产品。
重新考虑与规范不相容(nonspecification-compliant)的特性
Web Server偶尔会提供一些与供应商特定(vendor-specific)的特性,这些特性在开发时非常有用,可以提高性能、安全以及其他一些特性。在有些情况下,使用这些与供应商相关(vendor-specific)的特性是合理的,因为它所带来的优点远远的超过了其所可能蕴涵的危险。然而你需要意识到使用与供应商特定的特性时所蕴含的危险,因此在同样的情况下应该优先的考虑使用和规范相容的特性。记住,并不是所以的特性都是按照规范而“呼唤”出来的,在这种情况下,任何一个供应商的实现都是私有的。
技术的依赖并不总是使得供应商特点的特性蕴含危险。特定的Web servers供应商提供的自定义标签库可能在所有的支持自定义标签的Web server都可以使用,这种情况下你需要注意的是版权(licensing issues)问题了。
最佳实践(best practice)依赖与变换Web servers的可能性。当我不使用tomcat做为web server时,我通常会在其他别的web servers上面部署基于j2ee的网络应用来检验规范的相容性。需要记住的一点是,即使你一直使用一种web server,随着时间的发展,使用供应商特定的特性也存在危险。因为j2ee规范不断的进步,在某一个特定的供应商以他们特有的方式实现了一定的特性的时候,j2ee规范可能就会以一种标准的形式来定义这个特性。这种情况下,这个供应商就会转向这个同一的标准。
使用XHTML语法
在“
JSP Best Practices”中,我推荐在
JSPs中使用HTML的最佳实践(best pratices)。更近一步,我发现在创建
JSP document.XHTML规范提供很有用的HTML标签语法(I now find that the XHTML specification offers the most useful version of HTML tag syntax in authoring
JSP document.),XHTML使得更容易的来创建XML相容的
JSP document.甚至
JSPs page的作者也发现了在
JSPs中使用XHTML是有好处的。
因为完全的XML相容,XHTML语法比HTML遵守个严格的规则。标准的HTML和XHTML标签的不同见:World Wide Web Consortium's XHTML 1.0 pages.
只能做的更好(It only gets better)
JSP技术是用来简化灵活的web开发的。近来产生JSTL技术延续了这一趋势。甚至servlet方面规范的进步也大大的方便了
JSP的开发。
JSP和servlet规范的进步、一些新的工具的产生、
JSP编码标准的共享都使得高可维护的
JSP的开发比以前更加的容易。