当前页面: 开发资料首页 → JSP 专题 → 再谈Cocoon兼谈JSP

再谈Cocoon兼谈JSP

摘要: cocoon jsp xslt mvc

一年前的旧文，今天看来仍有其价值。

发信人: HAX(海曦), 信区: WebDevelop

标  题: 再谈Cocoon兼谈JSP

发信站: 饮水思源 (2002年06月06日01:17:17 星期四), 站内信件

著名的 IBM DW 中文网站，推出了Cocoon 2的简介教程，从而再次把我们

的目光吸引到Cocoon上。以下是我在CSDN的XML讨论区发表的个人看法，

贴过来涨点人气。

IBM的这个教程非常好，强烈推荐。BTW，IBM的DW网站比CSDN有用多了。

关于Cocoon，希望有一本《XSP/Cocoon/XML核心技术内幕》，基本上

编译了一些基本的Cocoon文档，有一定的参考价值。这也是我看到的

国内唯一的一本Cocoon的参考书。但是该书如同其它国内书籍一样，

对于基本理念的阐述不够详细和清晰。

Cocoon的原始动力是为了实现Content-Style-Logic的三层分离，这是

一个Web Engineer的很好的实践。

Cocoon也源自于以前的ServerPages技术（主要是针对JSP，当然ASP和

PHP也有同样的问题）的缺陷。尽管JSP提出了JSP Model 2，来实现

Model-View-Controller分离，即用JavaBean表示数据（内容），用

Servlet控制业务逻辑，用JSP实现显示逻辑和表现层，但还是有些实践

上的缺陷。关于这个问题的描述，在2000年10月的文章《JSP 技术 -

- 是友还是敌？》（http://www-900.ibm.com/developerWorks/cn/

java/w-friend/index.shtml）中有详尽的讨论。

但是如果我们跟上技术发展的步伐，就会看到这个问题由于标签库技

术的成熟和servlet过滤器机制的诞生而得到解决。TagLib早就有了，

但是直到临近JSTL即JSP Standard Tag Library的正式发布，其威力

才真正显现。

从角色任务上看，程序员主要负责JavaBean、Servlet和编写自定义标

签库（现在可以使用JSTL从而大大减少负担）；设计者编写“不包含

java代码”的JSP，实际上是若干种标记的混合，HTML+JSTL+自定义标

签。我认为这种框架比较适合于以Java程序员为主的团队，以及业务

逻辑复杂的应用。

注意，正如JSP的内嵌Java代码可以实现业务逻辑，JSP的TagLib技术，

一样可以用于实现业务逻辑。当然使用TagLib将比内嵌Java代码好

许多，因为代码被封装到了TagLib中，因此对于小的应用还是可以使

用JSP，而不用写Servlet。例如使用JSTL的sql tag，来直接处理数据

库（这实际上意味着基本没有或者只有极其简单的包含在sql语句中的

业务逻辑）。也可以用像、之类的tag来处理业务

逻辑，虽然通常应该只被用来处理显示逻辑。固然，这些功能会“引

诱”一些人过度使用TagLib的能力而破坏了设计原则，但对于原型开

发、测试以及轻量级应用，实在是太有用了！如果是企业级应用，相

信有能力做企业级应用的程序员，也会有足够的意识来按照MVC模式开

发。

Apache的Struts是一个基于JSP实现MVC的很好的框架，建议有兴趣的

同志研究研究。

而Cocoon，用XML表示数据（内容），用XSP（非常类似JSP的XML形式

）编写业务逻辑，用XSLT实现表示层（HTML、WML、某种格式的XML甚

至PDF），并用sitemap（Cocoon 2）集中管理。XSP逻辑单则与JSP的

TagLib从概念到用法非常相似，只是实现方法略有不同。JSP的TagLib

包括一个xml格式的定义文件和实现的Tag类，并被编译使用；而XSP

逻辑单则在运行时（当然可以进行Cache）应用XSLT进行从标记到代码

的转换。

（按照我对IBM教程的理解）事实上按照管道的概念，从原始数据到最

终呈现可以有任意层，至于如何分层，每个层的用途，则在于设计者。

这也是为什么Cocoon被定位于Web发布“框架”。

一个处理流程可以被描述为：（摘自IBM教程）

从用户接受请求。

确定用来解释该请求并生成响应的适当管道（使用匹配器）。

从可用的预配置的组件构造管道。

指示管道为请求服务。

将由管道生成的响应返回用户，可能对结果进行高速缓存以便以后使用。

在JSP Model 2里，Servlet扮演“调度员”的角色，我们用它来控制

任务分派，这有点类似管道所作的事情。事实上，Cocoon就是一个大

Servlet。只是Servlet在2.3之前缺乏管道机制，只能进行简单的

forward和include，如果需要多重处理机制，就不得不依靠扩展库

（比如IBM的WebSphere），或者采用Cocoon。但是现在Servlet有非

常强大的filter机制。这使得Cocoon与JSP越来越有结合的趋势。

但Cocoon的特点在于，除了核心功能（Core-Cocoon）之外，它还包括

内部组件（包括Matchers、Generators、Transformers、Serializer

s、Aggregators等）、内部逻辑单（Response、Sitemap、XSP、XSP-

Request、Util、XSP-Cookie、Log等）。这样它就有一个非常适合Web

发布的环境。而使用JSP，相对来说，需要自己进行配置和写部分的

基础代码。

从角色任务上看，站点管理员负责定义Sitemap，程序员主要负责XSP

逻辑单，设计者编写XSLT样式表（包括XSLT和目标代码如HTML），因

为程序员和设计者都使用XSLT，其实就是在写格式转换，只是编写者

需要熟悉如何处理输入和输出（如设计者要面对HTML，程序员要考虑

数据库）。此外，在此之前需要有额外的角色来定义所用到的XML或其

他中间格式。我认为这种框架比较适合于非Java程序员为主的团队，

管理员只要熟悉XML，程序员和设计者需要掌握XSLT；以及适合于业务

逻辑相对简单，而着重于xml数据和灵活的格式转换需求的应用。

--

※ 来源:·饮水思源 bbs.sjtu.edu.cn·[FROM: 202.120.15.34]