JSP实践：使用JSP include机制改进外观(1)

JSP实践：使用JSP include机制改进外观(1)

本系列文章中的所有最佳实践都基于 JavaServer Pages 技术。要运行任何一种实践，需要在本地机器或测试服务器上设置符合 JSP 的 Web 容器，如 Apache Tomcat。您还需要使用文本编辑器或 IDE 编写 JSP 页面代码。请参阅参考资料，获取 Tomcat 和与 JSP 兼容的 Web 容器和 IDE 的清单的链接。

更好的外观

为 Web 页面创建一致的设计和布局是确保获得专业化外观的最容易方法之一。您或许看过足够多的网站，知道单个站点中的大部分页面都共用统一的页面头、页面尾以及某种类型的导航栏。在设计良好的站点上，这些元素将在每个页面上呈现相同的布局、内容和功能，而主面板通常称为内容窗格）会随着每个视图而变化。

以前，这种布局几乎完全由框架和框架集实现。每段静态内容被放置在一个框架中，而页面的主体内容被放置在中间框架中。框架的麻烦就是不同的浏览器常常会以不同方式显示它们，使它们的外观不一致。使用框架从内部页面链接外部站点则比想像的更加困难。原本是想允许用户在不离开站点的情况下查看外部内容，但结果往往不一致。用户最终看到的是整个站点被挤进小得多的框架中，更糟的是，您的站点最终会嵌套在另一个站点框架中。这种混乱驱使 Web 设计者寻找一种更佳的解决方案。服务器端 includeserver-side include，SSI）就是一种。

服务器端 include

不久前，SSI 还是用于创建共享内容的最受欢迎的选项之一。简单的 SSI 伪指令允许您创建包含另一个页面内容如头和脚注文件）的页面，如清单 1 中所示。

清单 1. 正使用的 SSI 

＜![CDATA[
＜html＞
＜head＞
＜title＞Simple SSI test＜/title＞
＜/head＞
＜body＞
This content is statically in the main HTML file.＜br /＞
＜!--#include virtual="included.html" --＞
＜/body＞
＜/html＞
]]＞

我们不久将使用该文件来做一个练习。目前，您应该将它另存为 test-ssi.shtml。在大多数设置中，SSI 文件必须以 .shtml 结尾，这让 Web 服务器知道将它们解析为 SSI 伪指令。清单 2 显示了名为 included.html 的包含文件的内容。

清单 2. 包含的内容 

＜![CDATA[
This content is in another file, included.html
]]＞

当请求 test-ssi.shtml 时，您将看到该文件的内容以及 included.html 的内容。您可以在任何支持 SSI 的 Web 容器如 Apache Tomcat，请参阅参考资料）上查看这些文件。

从用户角度看，SSI 与框架相比有重大改进，因为在单个文件和从其它被包含文件引进内容的文件之间没有显而易见的差别。不利方面就是 SSI 需要一种特定的服务器设置，而 Java 开发人员常常无法使用这种设置。另外，SSI 通常要求被包含内容是静态的，尽管在后面的版本中加入了动态内容包含。

对于在网站或 Web 应用程序中包含不同类型的内容来说，SSI 是可行的解决方案，但它们不是 Java 开发人员的最佳选择。这不仅因为 JavaServer Pages 技术是替代 SSI 的全 Java 技术，还因为这两种技术不太容易结合在一起。JSP 页以扩展名 .jsp 结尾，这表示要使 SSI 伪指令起作用，必须更改 SSI 配置以解析 JSP 文件给每个 JSP 页解析增加开销），或者更改 JSP 配置以将 .shtml 扩展名作为 JSP 页处理这是一个坏主意）。对于 Java 开发人员来说，JSP 技术是最好的内容管理解决方案，幸运的是，其 include 机制很容易掌握。