Tapestry

谈到tapestry,我使用了tapestry4.0做了电子采购系统，包括中央中直机关采购中心，河南采购网，郑州采购网等等，了解它，可以简单的看到它使用了.page和.html，基于java web的开发，最初，我要下载相关的包，把里面的jar包导入到项目里，当你需要用到里面的组件时，会自动调用的，里面需要注意的是，常用到的一些接口，以及如何读取数据，在页面中需要知道什么，那么在编辑类中要继承basePage,获取相应的构造函数，然后在页面中我使用相应的对象 ，通过一些类型，可以通过@insert等，读取数据时，使用jwcid="ognl:对象.属性名"，对于它和struts的区别，Struts、Tapestry、Wicket框架的比较

一、Strust
要论当前Java 世界中Web 开发框架的No1 是谁，Struts 是当之无愧的王者，它遵循MVC 结构，在标准的Java Servlet 和JSP 上进行封装。

在View 这一层，它还是使用JSP 来进行输出，同时提供了许多标签处理页面输出，将指定的数据以Html 方式输出。另外在进行数据交互的时候，使用了ActionForm 在客户端和服务器端进行数据传递，以property 的方式来访问ActionForm 中的数据。但ActionForm
被设计为一个实际类而非接口，也一直是为大家所诟病的，这样就无法使用Pojo，而且为
了传递数据，程序员不得不编写相关的ActionForm 实现。

对于Model 这一层，Struts 没有作任何强制处理，但对于中小项目，许多时候为了加快开发速度，Model 这一层与View 层经常有一些重复，分离的不是很清楚，常见的就是许多用于Model 的类直接继承了ActionForm 类，显然增加了系统的混乱，同时也给程序的单
元测试带来许多问题。

对于Control 这一层，Struts 提供了Action，它不仅可以处理ActionForm 的数据传递，而且可以根据XML 文件载入相关的流程转向。程序员也可以编写相关的业务处理类进行各种业务的处理，当然对于小系统，也可以直接在这里处理业务。而且它还支持Token，以避免数据的重复提交(但Struts 的Token 基于Session，对于同一个Session，只支持一个Token)。

因此从上面的分析看来，Struts 并没有完整的对JSP 和Servlet 进行了封装，程序员仍然需要了解许多与Servlet 相关的信息，如Request 和Response，Session，Parameter 等基本信息。而且对于Pojo 等支持不足，造成单元测试的困难，所谓StrutsTestCase 也实在没有减少多少单元测试上的麻烦。

我个人认为Struts 最大的问题出现在View 层上，对于中小项目而言，UI 层的开发绝对不是一个可以忽略的因素，在我负责及参与的多个中小项目中，View 层开发的工作量一般不低于30%，原因可能是多方面的:
1. 用户的需求会产生各种变化，经常需要对界面进行调整；
2. Struts 对界面的控制度比较差，如果要控制一个文本框或者是一段文字不可见，需要编写大量的Tag 进行控制，如<logic:equal>等，当然也可以由开发人员编写Tag，这样的处理并不比直接在JSP 页面中使用Java 代码来的轻松；
3. 由于Struts 仍然使用JSP 作为主要的View 载体，而对于美工而言，使用Tag 几乎是一件不可能完成的任务，虽然网上有些朋友建议美工学习一下标签，但是这个不太现实，毕竟分工不同。对于已经含有Tag 的网页，如果经过美工处理，结果往往是惨不忍睹，不能很好的协同工作，对于开发效率无疑是一个重大的影响因素。
4. JSP 通常在执行的时候才能看到效果，而且要经过编译，因此每次修改以后，其测试也是一件很痛苦的事（JSP 属于模板结构，混合了代码和界面，所以无论对哪方面的修改，都要重新编译和运行，其执行时是编译成Servlet 的Java 代码来运行，因此需要比较多的时间来编译和执行，速度比较慢），而且许多Tag 的异常和页面的异常无法准确定位，这个也是程序员十分讨厌的一件事。（一些新版本的Web 服务器，遵循了JSR 标准，如Tomca t5,WebLogic8 都可以很好的支持JSP错误定位了）。

以上都是Struts1版本的属性，在Struts2中有很大改善。主要有：
1、 前台和服务器传递数据用pojo，不再用ActionForm。
2、 与Spring集成，采用了依赖注入。
3、 与OGNL表达式语言集成。

二、Tapestry

它的结构与ASP.NET 相似，但不是基于控件处理，而是基于Bean 的Property 进行处理。也就是通过一个配置文件在UI 和Bean 之间进行绑定（Page 文件），根据JavaBean 的属性来控制UI 控件，如UI控件是否可见和文本框中的值。最令人高兴的是，Tapestry 当时是Apache 下Jakarta 小组的一个子项目，Apache 出品，必属佳作，这在Java 世界里是已经公认的。

Tapestry 的4.0 也发布了一段时间，而Tapestry5 也蓄势待发，但我没有仔细看过其内容，据网上而言，变化很大，而且HiveMind 绑定了，我觉得作为一个比较成熟的框架，Tapestry 应该是很容易与其它的IOC 容器进行整合的，毕竟走回头路的人不会太多，果不其然，很快就有大量的文章来讲述，如何同时使用Tapestry 和Spring。

因为基于组件结构，所以它不使用Tag，而且在Tapestry 中使用了JavaAssist 进行二进制级的优化，与JSP 相比，性能得到了很大的提高。另外Tapestry 的多语言支持，使得不同国家地区的浏览看到的内容不仅仅是文字上的翻译，还可以是整个风格的变迁，应该说
Tapestry 是我见过最为优秀的Java Web 开发框架。

如果非要说它的缺点，我觉得有点勉强，就是它的开发思想比较特殊，完全区别与以往的JSP，Struts，与老式的C/S 开发也不相同，基于JavaBean 和配置文件管理页面，是一种全新的组件方式，这也使得Tapestry 的学习曲线比较高，对于一个生手而言，短期里很
难上手。我个人认为这是Tapestry 在Java 世界用户相对较少的一个主要原因，因为无论是习惯以前JSP 开发还是习惯Delphi 那种C/S 开发方式的人，学习Tapestry 时，几乎都要重头再来，而且并不是所有的程序员都有很好的设计基础和OO 思想，学Tapestry 还是很费力气的。如果想好好学习Tapestry，更深入的了解OO，会带来学习上的便利。我常在想，如果Tapestry 是一个产品的话，可能又是一个技术成功，而市场失败的产品。

今天的Tapestry 已经很成熟了，象J2EE 的No.1 网站TSS，就是构建在Tapestry 的基础上，而且据测试，性能较JSP 有两倍的提高。

三、Wicket

用Wicket 小组的话说，Wicket 与Tapestry 和Echo 相类似，事实如此。Wicket 在UI的处理上，与Tapestry 采用了同一手法，即使用原生的Html 元素，但通过添加Html 元素的属性来表明这个特殊的控件，然后由后台的Html 解析器进行分析，抽取这些元素，再
由后台进行处理，最终输出Html。这样做的好处:

1．避免了开发一个专用的IDE 用来处理Html。毕竟Java 的Web 框架往往是个人和小组织的产品，做一个Web 开发的IDE 未免力不从心。而直接使用Html，则可以充分利用市场上各种Html 编辑工具，如DreamWeaver。

2．多语言的支持其实对于Web 框架是非常重要的。以往的Web 框架一般在属性文件中放置各种资源，而自从Tapestry 后，不仅支持语言的改变，还支持布局的变化，Wicket对多语言的支持与Tapestry 如出一撤。以上的优点同样适用于Tapestry，但Wicket 最大的优点在于学习曲线。在后台的处理上与ASP.NET 相同，直接将前台的Html 中的控件映射到Java 对象中，通过Java 对象来直接操作控件的输出和行为。例如设置一个文本框不可见，只需要用textField.setVisiable(false)即可，这样看起来是不是和ASP.NET 以及以前的C/S 程序非常相似啊。而且Wicket 根据文件名自动查找Html（也可以定制查找的方式），不需要一个XML 文件在Java 文件和Html 文件间进行绑定。事实上个人认为，在这里使用XML 文件的方式，弊大于利。使用规则的方式进行绑定，还有利于代码的规范。因为如果不规范，就无法正常运行，带有一定的强制性。

Wicket 不仅清楚的区分了程序和美工的工作范围，而且清楚的划分了Web 开发的层次，也有利于程序的开发和维护。
Wicket 可以自动管理服务器端和客户端的数据交互和状态，有效的避免了"脏数据"，"重复提交"，而且支持Pojo，有利于单元测试。
Wicket 还可以定义各种控件，有利于复用。最后就我个人而言，Wicket 和Tapestry 的开发思想非常相似，仅仅在程序员的开发方
式上有所不同。Wicket 较之Tapestry 的最大优点在于学习曲线低。而Tapestry 则是一个非常成熟的Web 框架，其成熟度不是目前Wicket 可以相比的。