关于 Cocoon 优缺点的讨论

很多思想经历都比较相似。:-)
我在几年前见到Cocoon，也觉得Cocoon代表着Web未来（现在也一直保持高度关注，XML/XSL/XSP/XForm/Continuation)。后来，也觉得属于“叫好不叫座”，主要用于内容出版领域。

简单易学的东西会长期保持它们的生命力。这也是我的看法。
PHP目前好像一直是Web开发中使用最多的语言。好像份额还在增大？

关于HTML，我的看法，恰恰是觉得它还不够简单。:-)
CSS使得HTML本身简单了，同时，样式的复杂度转移到CSS里面了。

coocon是一个纯xml的框架 加入任何非xml的东西都比较麻烦 但也不是没有办法. 我不清楚4年前的cocoon是什么样子 但现在的coocon是可以用来做项目的 除了速度慢了点 并不比任何现有的框架差. 当2.2版本完成的时候 我相信cocoon能变得更接近实用.

我过去用autocad做机械设计 我认为svg真正的威力是提供真正有用的图形. 在网络越来越重视实用的今天 这点很重要. flash在这方面是弱项.

在google上搜索一下能找到很多svg的可视化开发工具  ,当然还不算强大. 由于svg本身的简洁 灵活 做一个开发工具不是一件难事. 有趣的是任何公司都可以根据特别的需要 开发自己专用的svg可视化开发工具 甚至是全自动的开发工具.

这也是现在这些垄断厂商不愿意推出svg工具的原因 这样会动摇他们的地位.但就象股市一样 一旦他们挺不住了 形势就会逆转.

你的观点我完全理解. 反正在我们公司是没有问题 呵呵

看到樓上兩位都提到Coconn了﹐四年前我還沒有進入WEB這個領域呢﹐所以對Coconn也是前不久才了解的﹐覺得它的思想真的是蠻不錯的﹐可是為什么四年了卻還沒流行起來﹐看了兩位的說明才明白了它的局限性﹐謝謝.

"我在几年前见到Cocoon，也觉得Cocoon代表着Web未来（现在也一直保持高度关注，XML/XSL/XSP/XForm/Continuation)。后来，也觉得属于“叫好不叫座”，主要用于内容出版领域。 "

国内有没有用cocoon开发的群体 或者论坛什么的 ? 也太孤单了 !

cocoon现在已经改用cform 感觉除了速度有些慢以外 还是很好的 比其他mvc的form方案要强大.

我有一个同事，在用Cocoon 2 Continuation featuer 开发一个相当规模的网站。实现一些步骤选择之间的状态控制，相当方便。目前处于开发阶段，单机测试，性能问题还不明显。
我从感觉上，觉得XSL存在性能问题。(XPath DOM搜索，字符串处理)。不知道处于什么数量级的速度。
同样其他的一些模板技术，大量采用server script, taglib, reflect等，也没有显得很慢。不知道处于什么数量级的速度。

关注Cocoon的人相当多，使用的却不多。你可以把你的使用经验和心得与大家共享。说不定能成为该领域的先锋。:-)

1、我也没有说过 CSS 不是用来做排版的啊。排版和样式是非常重要的，值得我们花大力气去学习。没有人说过在 JavaEye 就只能讨论编程语言。至少我、robbin、o6z、庄表伟都没有定过这个规则。不过 CSS 要发挥最大的效力，必须要和 JavaScript、DOM 很好地结合起来。

2、CSS 就是实现界面自定义的捷径。你可以定义多套 CSS 样式，然后使用 JavaScript 来切换。
这里有一个 JS 脚本教你怎么做这件事情。
http://www.alistapart.com/d/alternate/styleswitcher.js

我再来说说 Cocoon，这里的两位对 Cocoon 的评价还是很高的，但是我并不认为 Cocoon 是非常可行和值得推广的 Web 开发架构。
1、首先，复杂性。
Cocoon 首创了自己的编程语言——XSP（XML Server Pages），一种基于 XML 格式的脚本语言，完全基于 Tag，有点象 ColdFusion 或者 JSP 的 Taglib。这意味着很大的学习成本。会 Servlet/JSP 的人还需要再去学习 XSP。XSP 低层是由 XSLT 驱动的，为了解决开发过程中遇到的复杂问题，开发者还必须要精通 XSLT。我并不认为 XSLT 会比经过良好封装的 OO API 界面更直观，重用性更好。XSP 本身也很难说是 OO 的，这让熟悉 Java 的程序员充满了抵触心理。

2、其次，完全服务器端的解决方案。
Cocoon 是一种完全服务器端的解决方案（完全没有考虑如何与客户端的技术相结合）。因此它难以充分利用好客户端浏览器所提供的资源（CSS/JavaScript/DOM）。它完全称不上是一种 Rich 的解决方案。这个在我四年前看到 Cocoon 所生成的 plain 的界面后就对 Cocoon 完全失望了。我所寻找的是类似于 Flash 这样真正 Rich 的解决方案。我对 fastm 不了解，但是 fastm 同样也是一个完全的服务器端的解决方案。JSP/Taglib/JSTL/Struts/JSF 同样都是，我对这些方案全部都不感兴趣。

当然你会说，你又在胡扯了，要想利用好客户端的资源，你完全可以另外再写 JavaScript 啊，这是完全不矛盾的。看看，为了把事情真正做好（事情是否做好了用户说了算，他们只看你的界面和是否方便使用），堆砌了多少技术？搞得多么复杂！为什么不象 XAML/XUL/Flash/Ajax 一样直接把所有表示层的工作完全前推到浏览器端来做呢？
我上面说到过，XML+XSLT 本身没有如何嵌入多媒体内容的标准，因此不得不借助于 XHTML，而要实现 Rich 的效果，我还要在生成的 XHTML 中编写 JavaScript。那么这个 XSLT 将会何等的复杂？XSLT 文件中除了最终生成的 XHTML 标记，还要加入 JavaScript，还要加入 CSS，甚至还要加入 Flash！我为什么不能直接使用 XHTML 来做这些事情？
采用这套技术来实现一个 HTML/JS/JSP 就很容易实现的应用，成本上何其高昂？（又回到了第一个问题：复杂性）

3、第三，与当今一些先进的设计理念不合
Webwork、Spring、Hibernate 等开源框架的流行让拦截、AOP、低侵入性、OR-Mapping 等等概念深入人心。而 Cocoon 完全是自出机杼，它在 5 年前就已经成形了，结构上不可能发生根本性的改变来容纳这些新的设计理念。用 Cocoon 做开发甚至很难说是 OO 的。既然 Struts 的架构现在已经被广泛地认为落后了，我们有什么理由相信 Cocoon 就一定是先进的？我只能说 Cocoon 是非常有特点的开发框架（有一些独创的技术），但是要让我承认它是先进的，我很难做到。

基于上面的几个原因（还有其它原因，例如上面两位提到的性能问题，我甚至都不认为这是非常重要的问题。根据我带项目的经验，我一向是首先考虑开发效率和成本的），我认为 Cocoon 的应用仅仅限制在很有限的一些领域，例如新闻站点的内容发布。Cocoon 在我的眼里仍然是一个理论价值大于实用价值的充满学术性的东西。

用cocoon不需要懂OO 这属于cocoon开发者的范围 比如写自己专用的Generator将文本或其他东西转成xml. 使用的人只需要懂一些xsl javascript 就能开始工作 大多数时间在使用脚本语言.

我认为OO并不是web开发的理想概念 直接面相xml才是快速web开发的关键.

"Cocoon 是一种完全服务器端的解决方案（完全没有考虑如何与客户端的技术相结合）。因此它难以充分利用好客户端浏览器所提供的资源（CSS/JavaScript/DOM）。"

如果直接利用客户端的xsl cocoon的速度会比用server端处理快X倍 这是cocoon能很好的利用客户端的一个例证.  

"它完全称不上是一种 Rich 的解决方案。这个在我四年前看到 Cocoon 所生成的 plain 的界面后就对 Cocoon 完全失望了。我所寻找的是类似于 Flash 这样真正 Rich 的解决方案."

cocoon生成svg xul可以说是轻而易举的事情 界面不好是xhtml的问题 cocoon可以支持任何xml标准的输出.

"我上面说到过，XML+XSLT 本身没有如何嵌入多媒体内容的标准，因此不得不借助于 XHTML，而要实现 Rich 的效果，我还要在生成的 XHTML 中编写 JavaScript"

多媒体的标准也在靠近xml. 即便是现在cocoon的cform也比现有框架的交互能力强 实现事件驱动是很容易的 我认为比jsf要优雅 简洁.

"Webwork、Spring、Hibernate 等开源框架的流行让拦截、AOP、低侵入性、OR-Mapping 等等概念深入人心。而 Cocoon 完全是自出机杼，它在 5 年前就已经成形了，结构不可能发生根本性的改变来容纳这些新的设计理念。"

在cocoon一样可以使用hibernate 当然我可能会直接使用xmldb xquery那比hibernate还要简洁 方便. cocoon和struts完全是两回事 没有什么可比性. 虽然还比较原始 但它是真正的火车. 最早的火车确实比马车还慢.

直接处理 XML 开发起来是相当复杂的。至少基于 XML 的开发并没有一套如何提高重用的理论。要想积累一套成熟的表示层的控件，OO 还是最好的方法。

为什么一定要使用 XSLT，有没有更简单的开发方法？做 XSLT 开发就一定要使用 Cocoon 吗？

SVG！在浏览器的广泛支持成为现实之前，还是不要说未来 n 年才可能发生的事情吧。XHTML 有什么不好，具体说说。

事件驱动是两回事情，不要混在一起说。至少在目前，要想在页面中嵌入多种媒体，还是必须要借助于 XHTML。

如果你同意三层结构是合理的架构的话，业务层组件你用什么来实现？你实现的业务组件是不是还是只能在 Cocoon 里面运行？那么 Cocoon 的侵入性看起来不比 EJB 要小啊。还有用 Cocoon 做开发如何方便地做单元测试和 TDD？

那我们等它有一天跑得比马快的时候再用它，难道会有问题吗？

"我有一个同事，在用Cocoon 2 Continuation featuer 开发一个相当规模的网站。实现一些步骤选择之间的状态控制，相当方便。目前处于开发阶段，单机测试，性能问题还不明显。"

哦 ! 期待中 什么时候做好了通知一下

速度是个综合指标 如果程序简洁 中间步骤少 可能总体上也比较快吧. 现在的cocoon用sax应该比过去快多了. 数度优化可能要做很多工作.

我测过cocoon 的petstore 速度倒是很快 ! 看来开发cocoon还是需要很多技巧 我做的太随意了.

to winterwolf：
你啊，还是应该自己亲自去做一做啊。完全基于 XML 的开发（使用 DOM、XPath 直接操作 XML）我做得也不少啊。