一
概貌
Wicket是基于web应用框架的高级组件其主要特点
* 在HTML和java之间的明确分隔
* OO组件模式
* 自动状态管理
* 高度生产化
* 低学习投入
* 屏蔽Servlet APIHTTP协议细节
* 无需XML配置文件
* 易于构造可重用组件
Struts是以Model MVC 为蓝本构建的web应用框架其工作围绕着处理HTTP请求的action类来完成配置方式采用XML文件
下文将对Wicket和Struts在体系HTTP请求处理Servlet API和HTTP协议抽取状态管理配置这六方面进行比较
二比较第一方面体系
Struts体系基于解释每个HTTP请求并将其定向到某个处理该类型请求的指定Action类每个Action类将处理后的结果返回并决定下一步走向——通过转发或者重定向到另一个Action或者将控制权交给输出HTML的JSP页面从技术较大来讲虽然每个部分之间做到了很好的解耦但是基于HTTP请求的处理模式可谓与时代不符（与wicket相比就是过时了）两大原因如下
* Struts并不是真正意义上的纯粹面向对象每个Action类定义了一个abstraction（抽取）但是abstraction是由HTTP协议的请求机制决定的而并非面向对象的分析
* 除非我们在java代码中直接输出HTML（当然除非我们疯了）那么为了输出HTML我们就要学习另外的主流技术比如JSP和自定义tag使用在JSP中使用tag并非易事尤其是当我们把这项工作交给美工小组时这会直接导致两个结果JSP代码被他人作的一沓糊涂或者是我们自己完成这项任务
而Wicket的处理方式则不同从整体来讲应该说是更加优雅些它采用面向对象的组件技术实现web与用户的交互（这点有些如Swing）在Wicket中的每一页是由若干的使用组合设计模板生成的组件构成页面和组件各自渲染自己并直接或者间接的与markup文件（标识文件形式就像JSP）关联当HTTP请求到来时这些请求被转换传递到组件上的相应事件中来这一点与微软的VS很相象所以Wicket能够解决struts体系中存在的问题
* Wicket是完全面向对象的我们可以利用组件的继承性设计自己的应用这里不需要为处理HTTP协议的请求/响应而作任何工作
* Wicket所使用的markup文件与纯粹的HTML很接近所以容易上手使用Wicket在markup文件中所引入的内容非常整洁并符合XHTML标准任何了解HTML的开发者都可以如编辑HTML文件那样编辑Wicket的markup文件就好似他并不知道这是Wicket的markup文件一样
三HTTP请求处理
在Struts中一个HTTP请求被接收后Struts将在配置文件中查找request path和相应的Action类如果这些已经被配置好了它将将提取请求参数放入到ActionForm bean中并执行一些验证然后HTTP请求回应和ActionForm对象都将作为参数传入到Action类中从这点可以看出Action的开发者掌握着应用的方方面面他们必须处理HTTP session维护HTTP请求和session的属性并在action执行完时建立需要返回的信息最后还要返回相应的ActionForward以使struts知道下一步在哪里假如此时ActionForward将控制权交给了JSP页面开发者就要使用struts自定义的tag库编写JSP代码如此繁复的工作环节很容易出现错误而且struts还需要三个位置保持一致struts XML配置文件java Action类JSP自定义tag
而在Wicket中一个HTTP请求被接收后Wicket将确认HTTP所请求的那个页面和在这个页面关联的组件如果请求的目的是formWicket将自动提取请求参数验证参数进行一些预先规定好的类型转换设置form组件中的model（模式这里用法与MVC中类似但有不同）值接着转化请求为相应类型的事件调用目标组件上的相应事件侦听器这样就会导致事件处理代码运行来执行业务逻辑然后事件处理器还将指定下一步页面的位置被指定的页面将初始化（如果页面从未被初始化的话）并自动渲染渲染处理将按照顺序访问每个页面组件要求它们进行自我渲染在markup文件中能够组件仅通过名字与HTML元素进行映射
Wicket出色的原因
* 每个组件知道如何处理自己事件因此我们只需要将组件放到页面上编写事件处理器就行了如果一个页面中存在个能引发事件的不同的组件我们除了进行将它们添加到页面上的工作外没有别的工作但如果在struts中我们可能需要建立个不同的Action类或者一个具有个分支语句的Action类并要在XML配置中逐一添加
* Wicket带给了我们考虑组件/事件重用的机会而不用将注意力放到如何处理HTTP请求和回应上
* 与struts相比使用Wicket会降低我们的代码量这正是重用组件带来的益处Wicket本身不使用任何的XML配置文件只需要修改web容器的webxml文件中的servlet声明部分
假如我们曾经编写过Windows API并用过Visual Basic或者Borland Delphi的话下面的比较会更加让人印象深刻使用struts开发就像使用Windows API一样接收原始消息解码原始消息然后再处理这些消息由于Windows API是基于消息循环工作的所以系统除了消息回应外不期望任何的返回值
从另一方面看Dephi在TApplication类中隐藏了Windows消息循环使开发人员围绕着TApplication类建立其他的类原始的系统消息就这样被Dephi内建类接收被内建类解析并被确定其接纳者消息被转换为一个事件并被传送到某个特定的对象
如Windows应用程序一样Wicket应用也具有服务于文本和HTML模板的资源文件从这点看Wicket象用Delphi做桌面开发一样被用来做web开发
四Servlet API和HTTP协议的抽取
Struts没有隐藏Servlet API和HTTP协议的细节为了使用Struts我们必须乐于和HTTPServletRequestHttpServletResponse 和HttpSession类打交道并围绕着请求和回应建立应用这便是所有Model MVC wen框架与生俱来的弱点
正如上面说的Wicket隐藏了Servlet API和HTTP协议的细节对于一些应用我们甚至触及不到这些细节甚至对于非常复杂的应用我们也仅使用适当的Wicket协议抽取类而经常用到的是java组件类POJO业务模型纯HTML标记文件
五状态管理
使用Struts开发我们将获得全部的状态管理权这对于建立大规模的高升级空间的集群应用来讲是很好的因为我们将获得对HttpSession上每件事物的控制权但是对于中小型应用我们将没有缘由编写一些额外的代码这样将导致应用变得复杂和编写费时
在状态管理上Wicket可以作为一个不错的选择Wicket框架默认代管所有的组件状态这对于中小型应用在状态管理上的代码量几乎为但是Wicket也提供了一些API使我们进行标准状态管理和实现自己的状态管理这样即使是大型应用我们也能够全权掌握状态管理事实上即使在使用Wicket编写大型应用时通常也是先让Wicket代管所有的状态然后再慢慢的实现自己定义的状态管理以提高应用性能
六配置
不言自明Struts需要一个XML文件定义对HTTP请求和响应的映射和所有的ActionForm对象等这个文件可能非常大而且复杂而新版本的Struts提供了将这个文件分解为多个模块的方法虽然这样可以将模块分类但是这样同样要维护许多的小文件
Wicket不需要配置文件Wicket通过一个简单的应用配置类或者通过编写web容器的webxml文件中Servlet init参数来完成程序的初始化而HTTP请求到组件事件的映射组件如何输出HTML等被包含在了Wicket的应用逻辑里从而极大地简化了配置
七Wicket的RoadMap
* JavaScript support
* CSS support
* Markup inheritence
* Experimental AJAX support
* Improved URL handling
* Include of external markup
* Simplified Choice component
* Improved Feedback support
* Thread safe validation (bug fix)
* Immediate button support for Forms
* Panel support for TreeView
* Date picker component
* Component reference examples
* AJAX support
* Portlet support (JSR )
* Clean and pretty URLs
* JAAS/Acegi/other security integration
八参考资料
/Newuserguide
