浅谈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企业级应该可以吧:)

以上愚见,入门之徒    

你可能感兴趣的:(Ajax,应用服务器,企业应用,gwt,wicket)