浅谈GWT与Wicket比较

在表现层接触过: JSP, GWT, Spry, Wicket...

其中JSP大家都很熟悉，它走的是servlet，每次都向服务器有请求，然后服务器接到请求然后返回所需要的值，并且页面信息也反回来，被重新编译成HTML。 最早接触struts 1.x 版本， 它将servlet封装，并有自己的一套标签，……

闲话不说了，进入正题。
首先是GWT,
对GWT很有感情，(毕竟写了八个月,呵呵)
可以这么说，如果你想实现Ajax, 只会java,那么GWT是最好的选择！
其中我认为比较重要的，一个是深刻理解listener,(这个是实现ajax的关键的关键，以便自己写需要的listener), 一个是理解它的回调RPC, rpc只要理解就好，没什么难度，它是GWT之间访问服务端的异步请求，（千万不要把服务端的代码写道客户端!）

接下来就随心所欲的写你想表现的东西，google已经做了很多widget， 你也可以自己创造，修改或组装满足需求的Widget, 用创造者的一句话"Java搞定一切！"

由于google将其介绍的非常清楚，一个普通的程序员都能上手。 虽对其不满和批评很多，但还很是喜欢。 由于大量javascript生成，第一次读取的数据一般都会很大，似乎暂时不适用于网站开发，而更适合企业运用。

中间接触了spry,struts2.0的标签，少有深入，接下来就是用wicket

最近正在使用Wicket作为我们的表现层，由于一些写法类似，便联想到一块了。其实是截然不同的表现层。
初次见面，感觉很好，很多代码一眼都知道是干什么的，也和GWT一样有写Swing的感觉。学习起来也很容易，上手很快，基本上不用管理页面，只要知道传什么值就好。然而，用了一段时间，发现它并不灵活，特别是当要做ajax应用时候，显得让人不太爽。而且，虽然不需要写页面，但页面上每一个要用的控件都得跟webpage的对应，并不觉得非常轻松（可能是学艺不精吧）。

其中，一个应用，一个二级连动菜单，结果第二个菜单在form提交后返回不到值，拼命弄了很久回来还是空，仔细寻找问题，发现是当它被上一个菜单的动作update后，虽然里面有值，你可以在页面上操作选定其，（是，在页面上成功）但提交的时候回来，发现Wicket不知道!! 因为它不知道你选择了这个值。 官方网站的例子也研究了，张磊的书也研究了，结果还没解决. 不过同样的写法既然在另一个页面返回，效果蛮好，太诡异了!

根据以上，本人觉得Wicket适合分层开发，页面人员可以利用充分。而且是不破坏html结构，可以有良好的url, 并可以生成纯静态页面，适合被搜索引擎找到。而在ajax能力上不足。适合一般网站开发。
GWT（I like it!:D）,可以让java人员实现复杂的ajax技术。做一个ajax企业级应该可以吧:)

以上愚见，入门之徒   

评论

2 楼 whale 2009-01-05  

w

liliang_xf 写道

Wicket 这个玩意生成的是HTML代码，那还不错啊

并不是生成，而是在里面fill datamodel. HTML已经有了，所以可以充分利用UI人员（他们不懂编程，但懂html，会设计静态页面）

1 楼 liliang_xf 2009-01-05  

Wicket 这个玩意生成的是HTML代码，那还不错啊