中科永联高级技术培训中心（www.itisedu.com）
Cocoon是一种Java服务器框架，它允许使用XSLT（XML样式表语言转换(XML
StylesheetLanguage-Transformation)）转换动态发布XML内容。通过依靠XML描述内容以及使用XSLT将内容转换成多种格式，Cocoon提供了用于构建内容、逻辑和表示在很大程度上彼此分离的应用程序的平台。
相关站点/下载地址：http://jakarta.apache.org/tapestry/
cocoon是一个基于XML的Web发布框架，提供了一套机制真正实现了内容，逻辑，和表现形式的分离cocoon具有高效的可配置性和复杂的缓存机制.
Cocoon使用管道的概念来描述将内容发布到Web的过程。它包含各种各样的可重用组件，这些组件可以配置成使用最低限度的Java开发生成复杂的行为。例如，通过单独使用XML和XSLT，Cocoon可用于：
提供静态文件和动态生成的响应使用任意数量的处理将用户请求透明地映射到物理资源执行简单和多级XSLT转换将参数动态传递到XSLT变换生成各种各样的输出格式，包括XML、HTML、PNG、JPEG、SVG和PDF这大大增加了使用XML和XSLT中现有技巧进行工作的功能。Cocoon让您能以最少的麻烦生成动态网站。
一、Cocoon1和Cocoon2
Cocoon是一个开放源码项目，它是作为ApacheXML工作的一部分开发的。Cocoon2完全重写了原始的Cocoon应用程序，并且是建议使用的版本。新用户应该一开始就使用Cocoon2，同时鼓励Cocoon1的现有用户进行升级。
Cocoon2项目的目的是吸取Cocoon1开发中的教训并使用它们来设计一个更有效和更可伸缩的平台。特别是，Cocoon1依靠文档对象模型（DocumentObjectModel(DOM)）API在组件之间传递XML数据。DOM是传递数据的一种低效方式，因为通常的DOM树会消耗几倍于原始XML文档的内存。这在很大程度上限制了Cocoon的可伸缩性。Cocoon2是围绕SAXAPI构建的，SAXAPI是操纵XML数据的一种轻量级方法。
两个Cocoon版本之间的另一个主要区别集中在应用程序管理上。在Cocoon1中，个别的XML文档通过包含Cocoon处理指令信息声明了应该如何处理它们。这将文档绑在特定处理上，极大限制了以不同方式重用内容的灵活性。Cocoon2将处理的管理划分到一个称为网站地图（sitemap）的配置文件。这将处理逻辑与内容本身分离，依次分离内容、逻辑和显示。
二、cocoon的安装
cocoon本身是一个web application,需要在有Servlet engine的服务器中运行。 解开cocoon的安装包（现在稳定的版本是2.0.3)，会有一个名为cocoon.war的WAR包, 这是安装唯一用到的文件。将它Copy到TOMCAT_HOME/webapps目录下，然后启动Tomcat, Tomcat会自动解开cocoon.war到TOMCAT_HOME/webapps/cocoon目录，这时键入URL: http://localhost:8080/cocoon ,如果看到cocoon的Welcome页面，就表明Cocoon已经成功的安装了，非常简单。需要注意的是，这时应该关了tomcat,将cocoon.war删除，原因是我们将要在以后的时间里不断的修改和配置TOMCAT_HOME/webapps/cocoon中的文件， 而cocoon.war已经无用了。
三、cocoon是一个高度的可配置性的环境，有几个文件是和配置有直接关系的。
TOMCAT_HOME/webapps/cocoon/WEB-INF/web.xml
TOMCAT_HOME/webapps/cocoon/WEB-INF/cocoon.xconf
TOMCAT_HOME/webapps/cocoon/WEB-INF/logkit.xconf
TOMCAT_HOME/webapps/cocoon/sitemap.xmap
cocoon本身是web application,自然有web.xml
cocoon.xconf是cocoon的配置文件，相当于JSP中的web.xml文件在JSP中的作用logkit.xconf是cocoon的日志配置文件，灵活性很大。
sitemap是cocoon的一个核心的概念，sitemap.xmap中有许多复杂的配置项，要会配置他们,首先要对cocoon有一个整体的认识，随着你对cocoon认识的更多，你对sitemap.xmap的配置也就越了解。
四.cocoon的基本概念
Pipeline是Cocoon2(cocoon2和cocoon1是有很大的不同的，所以无需知道任何关于cocoon1的东西)的基本概念.Pipeline由多个cocoon 组件构成,输入流经过Pipeline到输出流，每个组件会对输入流进行处理，然后送到下一个组件处理，直到最后的输出。处理的组件和输入流都是在前面提到的sitemap中配置的。在一个应用中可以有多个Pipleline,每个Pipeline中可以有多个不同的处理，每个处理和输入的URL有关。
4.cocoon的基本组件
Matcher :是捕获URL地址，将其和Pipeline的一个处理流向关联
Generator :将输入流转换成Java 的SAX程序，为后续的处理提供SAX程序
Transformer :对Generators产生的SAX程序进行格式转换
Serializers ：对经过Generators和Transformer转换的结果产生最后的输出流，
输出流可以是html,xml,wml,jpeg,png,pdf等不同格式的文件.
XSP:全称是eXtension Server Page,也有人叫XML Server Page,是Cocoon提供的一种服务器脚本语言，类似于JSP或ASP,但是完全基于XML的,它可以作为Generator的输入流
5.一个简单的URL请求处理的过程
cocoon在sitemap中寻找和URL匹配的Matcher项，然后对应Generator中配置的输入流(通常是XML文件或XSP文件A，用相关的Generator处理组件处理输入流,接着读取Transformer的中的输入流B(通常是XSL文件，Transformer组件用B对A进行格式转换(如将XML文件转换为HTML格式),一个管道中可以有0个或连续多个Transformer处理,最后Serializer组件根据Serialize的类型(html,wml,pdf,jpeg等)产生最后的输出。
相关的Sitemap片断
<map:pipelines>
<map:pipeline>
<map:match pattern="hello">
<map:generate src="hello.xsp" type="servERPages"/>
<map:transform src="dynamic-page2html.xsl"/>
<map:serialize/>
</map:match>
</map:pipeline>
</map:pipelines>
再谈Cocoon兼谈JSPhax（原作）
发信人: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语句中的业务逻辑）。也可以用像<c:if>、<c:forEach>之类的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、Serializers、Aggregators等）、内部逻辑单（Response、Sitemap、XSP、XSP-Request、Util、XSP-Cookie、Log等）。这样它就有一个非常适合Web发布的环境。而使用JSP，相对来说，需要自己进行配置和写部分的基础代码。
从角色任务上看，站点管理员负责定义Sitemap，程序员主要负责XSP逻辑单，设计者编写XSLT样式表（包括XSLT和目标代码如HTML），因为程序员和设计者都使用XSLT，其实就是在写格式转换，只是编写者需要熟悉如何处理输入和输出（如设计者要面对HTML，程序员要考虑数据库）。此外，在此之前需要有额外的角色来定义所用到的XML或其他中间格式。我认为这种框架比较适合于非Java程序员为主的团队，管理员只要熟悉XML，程序员和设计者需要掌握XSLT；以及适合于业务逻辑相对简单，而着重于xml数据和灵活的格式转换需求的应用。
（来源：http://www.xml.org.cn；http://www.netbei.com）