JSP技术优缺点深入分析[6]

JSP 的拥护者会很快告诉您 JSP 标记库 可以帮助您避免这个问题标记库允许将自定义标记（例如 ﹤AUTHORS /﹥）添加到 JSP 页面然后在运行时在标记库内将其解析为代码片段

使用自定义标记和相关的标记库允许把以上示例转换为清单 所示的内容

﹤CENTER﹥

﹤TABLE width=% CELLPADDING= CELLSPACING= border=

BGCOLOR=#FFFFCC﹥

﹤ACTORS /﹥

﹤/TABLE﹥

﹤/CENTER﹥

在运行时将执行标记的代码并把正确的结果插入到页面中但是这并没有解决问题反对 JSP 技术的理由并不在于能否 分离内容和表示而是在于是否必须 分离只要 JSP 编码允许内联编码那么就可以很方便地对内联代码进行最后的修改（特别是逼近最后期限时）而不是将代码转换为一个标记库如果这不是真的那么 Java 语言为何会马上比 C 和 C++ 更流行Java 禁用了 C 中大量有问题的特性例如指针相加虽然您可以总是强调您不需要 在 C 中执行指针相加或者优秀的程序员将插入代码 scriptlet我们都知道实际会发生什么Java 语言是一种更好的选择因为它严禁 使用这些不好的习惯但是 JSP 在这方面更类似于 C允许实现一些非常糟糕的实践

检验 JSP 技术是否成功达到其所述目标的另一种方法是看它能否在实践中实现这个目标显然如果认为 JSP 无法实际实现目标这是不公平的大多数模板引擎比如 FreeMarker 和 WebMacro都提供了相同的内联编码功能通常附带了一种类似 Perl 的语言然而诸如 Enhydra 的 XMLC 这样的技术不 允许进行这种类型的编码相反这些技术将一个纯标记语言页面作为输入然后生成 Java 方法这实际上改变了编程流程应用程序并不像 JSP 技术那样使用页面从应用程序调用逻辑而是使用方法影响页面的值（Enhydra）以 Enhydra 为例使用 XMLC 将页面转换为一个 DOM 树然后使用 DOM 的 HTML 绑定更新页面中的 字段（有关 Enhydra XMLC 的更多信息请查阅 参考资料）

这里的重点是JSP 技术实现目标的能力远远超过 XMLC例如仅仅是允许标记库这一项就比 XMLC 强很多但是 Sun 规范总体趋向于始终维护向后兼容性或至少在相当长的一段时间内维护向后兼容性JSP 规范的当前版本为 它允许使用 scriptlets因此在未来几年内 JSP 页面内都会支持这个特性在深入探究 JSP 编码之前请注意在其强调的完全分离内容和表示的理念和实际实现之间存在一个很大的缺口它充其量只是假装分离了用户界面和驱动应用程序的代码

单处理和多任务处理

如前所述理想状态下设计师应该能够执行单独处理只关注图形设计而开发人员应该能够将注意力集中在编程上因此设计师可以在将页面转换为适合应用程序的格式后再对其进行处理对于 JSP 页面来说将页面转换为适合应用程序的格式就是指向页面导入 JavaBeans插入内联编码并添加自定义标记库问题是有些设计师使用的是 HTML 编辑器比如 HoTMetaLMacromedia Dreamweaver 或 FrontPage这些编辑器无法识别代码 scriptlets 或标记库这意味着设计师实际上只收到了页面的一部分想象一下标记库或代码片段只生成了表的若干行或是页面中其他格式化的细节这是多么麻烦的事情设计师使用了不兼容的 HTML 编辑器无法看到这些元素的外观在开发人员完成编码后设计师不能轻松地对页面进行修改这时不仅没有清晰地划分角色JSP 编码实际上将这两种角色合二为一开发人员必须执行多个任务必须担当开发人员设计师以及其他角色

如果您仍然对此表示怀疑那么请下载 JEE Reference Implementation 并将其中一个附带的 JSP 页面加载到一个 WYSIWYG HTML 编辑器例如 Dreamweaver页面立即被一些黄色区域填充告诉您页面中包含的所有 错误 标记当然黄色内容来自于 JSP 标记和代码而不是页面出现了什么真正的错误

迄今为止尚未出现支持 JSP 功能的 WYSIWYG 编辑器我也没有听说过任何与此相关的项目尽管模板引擎也具有相同的问题但是很多基于 Java 的解决方案例如我最喜欢的 Enhydra都允许您将标记页面作为输入提供给表示技术在这种情况下设计师可以根据需要频繁地进行修改并重新提供标记页面运行表示技术的引擎或编译程序将标记页面转换为适当的格式并且不需要修改任何代码（典型情况下）最终获得了理想的结果设计师和开发人员各司其职

因此要注意 JSP 技术作出的承诺和它实际交付的实现在实际中要在一个 JSP 技术驱动的环境下发挥功效必须让开发人员处理大部分标记或至少让设计师学习一些 JSP 编码

HTML 和 XML

JSP 技术最严重的缺陷之一（也是经常被忽视的一个缺陷）就是它与 XML 不兼容更确切地说并且特别针对 HTML 领域JSP 页面不要求具备 XHTML 兼容性XHTML 是一个 World Wide Web Consortium （WC） 规范目前正在取代 HTML XHTML 在实现格式良好的 XML 文档方面定义了 HTML 标记集例如标记必须被转换才能确保 XML 兼容性（如果这个例子没有解释清楚的话可以查阅 参考资料 列出的 XML 规范以及关于 XHTML 的 developerWorks 文章）同样的规则适用于图像标记并且在 XHTML （即将到来）中大部分字体属性和其他样式被移入到 CSS 样式表中另外大多数标准 HTML 文档可以轻松地转换为 XHTML 这意味着可以使用任何与 XML 兼容的解析器读取例如 Apache Xerces并且可以作为 XML 进行处理

您会问 这有什么关系呢？答案是关系重大因为 XML 正在快速成为一个在应用程序之间和应用程序内部进行通信的全球标准使用 XML 格式传递书籍可以让任何使用基本 XML 数据绑定功能的应用程序轻松地使用您的应用程序的数据想象一下通过将您的数据迁移到 XML 格式您就可以与信用卡公司进行网上交易！多数情况下您的数据表示还需要与其他公司进行交互最常见的情况是门户应用程序它接受来自各种提供者的内容（例如天气信息股票报价和新闻）通常附带有提供者的标记然而由于 JSP 页面将代码和自定义标记库相混合因此无法在这种环境下良好地工作

JSP 页面很少具有格式良好的 XML 文档并且不重视是否符合 XHTML而 XHTML 这种标记语言并不允许使用各种 JSP 自定义标记库然而更重要的是插入到 JSP 页面的代码片段并不属于任何标记形式因此当另一个应用程序处理它们时将产生解析器加载错误

在您提出质疑之前让我们先了解一下整个情况如果应用程序允许 JSP 页面由初始客户机处理结果将产生纯 HTML（或 WMLVoXML 等）然而大多数请求这个数据的应用程序使用了一定程度的缓存因为网络往返开销很昂贵在这些情况下缓存过的页面将返回过时的数据因此您可能更愿意返回与 XML 兼容的结果最好使用静态的形式而 JSP 技术在这些情况下无能为力JSP 页面必须始终 在运行时进行处理以去掉 JSP 代码 scriptlets 和标记库

看看最关键的考验其他一些表示技术能做到这一点吗？答案是可以这个领域最权威的领导者是 Apache Cocoon 项目它完全建立在 XML 和一个 XSLT 样式表应用程序（可以在运行时或静态状态下应用）的基础之上由于 XML Server Pages（在 Cocoon 框架中称为 XSP）实际上是 XML 文档因此始终与 XML 兼容像 Tea 和 Enhydra XMLC 等允许输入纯标记语言页面的技术也可以做到这点虽然它们的目的并不在此在这些情况下用户可以使用 XHTML 或标准的 HTML此外这比 JSP 技术要好因为 JSP 不能 静态地实现格式良好的 XML

结束语

希望我的努力能够让您进一步了解JSP 技术的优缺点并且您可以将JSP 技术看作是众多其他表示技术的替代品现在您可能对整个JEE编程模型也产生了一点怀疑如果您希望进一步研究平台选择那么可以在 Apache CocoonEnhydra 和各种模板引擎中寻找 JSP 技术的替代选择

最后请记住本文并不是建议您使用JSP或避免使用它尽管表面上像是这样我的目的是鼓励您对任何技术进行详细的分析确保它是正确的选择就像编程模型一样有时它们是合适的然而有些时候它们并不适合多进行一些比较找到最适合自己的技术并作出明智的决定而不是仓促地决定

[] [] [] [] [] []