Cocoon原始动力

关于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数据和灵活的格式转换需求的应用。