锁定老帖子 主题:web framework选型的困惑
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-01-03
一直在用struts开发,虽然对struts进行了封装和改进,并使用其动态formbean,但是,还是有狂多的配置文件,狂多的jsp,狂多的action,太多的机械性重复,页面不可以复用,action也不可以复用,我受够了。 以前在C/S结构里,一个界面可以完成许多按钮动作,但是现在,却不得不一个按钮对应一个动作、一个界面,真是折腾人。 所以,我决定做出改变,从而提出理想的web framework的两个基本标准: 其一:组件化,能抽象出几个form,比如单记录form,主从记录form,查询form等 其二:异步处理,天然的异步交换,拒绝不停的刷新页面。 按第一个标准,就只有jsf和Tapestry可以选择,按第二个标准,就没有了。 后来考虑用dwr+qooxdoo+freemark,但是去网上一搜,发现大家都用得灰心丧气的,不但没有减轻开发,反而增加了很多麻烦。听说gwt不错,一看到它是从服务器端生成js代码,类似RPC之类的调用,我就没兴趣了。 想来想去,又回到mvc,在struts 2和webwork之间逗来逗去,struts 2要实现0配置还需要一段时间,要实现类似jsf和Tapestry那种组件化的计划都没有。 唉,我都不知道该如何办才好。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-01-03
针对你的第二点,目前来说应该只有 ajax 能符合你的需求吧?
gwt 并不是“服务器端生成js代码”,而是 gwt 带有编译工具,把你的 java 程序(其实是符合java的一个子集的程序)编译成 javascript,然后纯粹在客户端执行。gwt 有两种运行方式,一是 hosted 方式,这是用 java 模拟运行,可以逐行调试;一是 compiled 方式,这是用 gwt 的编译器把 java 翻译成 javascript,是实际运行在浏览器上的代码。与服务器的通讯是通过 xmlhttp 实现的。 我觉得 gwt 是在浏览器上实现 (semi)richclient 的理想方式。 有时候不能不感叹 google 想象力丰富。 |
|
返回顶楼 | |
发表时间:2007-01-03
kdekid 写道 针对你的第二点,目前来说应该只有 ajax 能符合你的需求吧?
gwt 并不是“服务器端生成js代码”,而是 gwt 带有编译工具,把你的 java 程序(其实是符合java的一个子集的程序)编译成 javascript,然后纯粹在客户端执行。gwt 有两种运行方式,一是 hosted 方式,这是用 java 模拟运行,可以逐行调试;一是 compiled 方式,这是用 gwt 的编译器把 java 翻译成 javascript,是实际运行在浏览器上的代码。与服务器的通讯是通过 xmlhttp 实现的。 我觉得 gwt 是在浏览器上实现 (semi)richclient 的理想方式。 有时候不能不感叹 google 想象力丰富。 谢谢kdekid指点,看来我对gwt误会太深了,我还以为是又一个dwr呢,不过还是有些问题要请教: 第一:不知道用gwt开发erp之类的管理系统,有没有人实践过,毕竟我们开发gmail和gmap的机会很小的,大部分应用还是企业管理系统。 第二:我以前开发过swing,知道那里面的组件封装得还不错,不知道gwt能否使用已存在的ajax框架,比如qooxdoo等,如果不支持,gwt能否让我很好的扩展? |
|
返回顶楼 | |
发表时间:2007-01-03
dorado,我不是广告...
|
|
返回顶楼 | |
发表时间:2007-01-03
netfly 写道 谢谢kdekid指点,看来我对gwt误会太深了,我还以为是又一个dwr呢,不过还是有些问题要请教:
第一:不知道用gwt开发erp之类的管理系统,有没有人实践过,毕竟我们开发gmail和gmap的机会很小的,大部分应用还是企业管理系统。 第二:我以前开发过swing,知道那里面的组件封装得还不错,不知道gwt能否使用已存在的ajax框架,比如qooxdoo等,如果不支持,gwt能否让我很好的扩展? 不敢说指点,大家一起探讨吧。 gwt 诞生不过一年稍多的时间,个人觉得实际上算不上一个非常成熟的项目,论程度来说绝对比不上 struts, webwork 这些应用广泛的 framework。但我觉得 gwt 有几点优势:
不过相对来说,它也有以下的劣势:
以上是个人意见,仅供参考。 |
|
返回顶楼 | |
发表时间:2007-01-04
wicket比较适合
1.开源,并且比较活跃,开发者很勤奋 2.组件式,带有强烈的c/s结构的ui,有表格和树形控件,界面内容和对事件的响应用java实现,避免js的泛滥 3.界面的显示用纯html(仅仅添加了一个wicket:id,还算能接受),便于美工介入,同时多语言问题也较好解决了 4.在服务器端维护session的状态,适合解决用户交互复杂的情况。 5.支持ajax,适合第二项标准,并且不用编写javascript 6.适合企业应用的开发。企业应用的特点是session数不大,但是每个session的操作很频繁。所以把session保存在服务器端也是可以接受的(任何web架构都需要保存session的状态,只是保存的内容多少有差异,wicket保存的比较多)。 |
|
返回顶楼 | |
发表时间:2007-01-04
kenken0y 写道 wicket比较适合
1.开源,并且比较活跃,开发者很勤奋 2.组件式,带有强烈的c/s结构的ui,有表格和树形控件,界面内容和对事件的响应用java实现,避免js的泛滥 3.界面的显示用纯html(仅仅添加了一个wicket:id,还算能接受),便于美工介入,同时多语言问题也较好解决了 4.在服务器端维护session的状态,适合解决用户交互复杂的情况。 5.支持ajax,适合第二项标准,并且不用编写javascript 6.适合企业应用的开发。企业应用的特点是session数不大,但是每个session的操作很频繁。所以把session保存在服务器端也是可以接受的(任何web架构都需要保存session的状态,只是保存的内容多少有差异,wicket保存的比较多)。 支持wicket, wicket的session可以通过实现sessionstore来实现把session信息存储到数据库,文件等等其他地方,目前只实现了内存存储。 |
|
返回顶楼 | |
发表时间:2007-01-04
引用 Wicket是什么?简单点说,它就是一个基于Java的Web开发框架,与Struts,WebWork,Tapestry相类似。其特点在于对Html和代码进行了有效的分离(有利于程序员和美工的合作),基于规则的配置(减少了XML等配置文件的使用),学习曲线较低(开发方式与C/S相似),更加易于调试(错误类型比较少容易,而且容易定位)。如果你不对微软并不反感,可以把它看作Java平台上的ASP.NET。
这是Wicket开发指南上的原话,我知道Tapestry与JSF、ASP.NET类似,都是基于服务器组件式的开发,Wicket是不是也和Tapestry、jsf一样?能符合我的第二个标准吗?如果不是天然异步交互的,那我还不于选jsf,毕竟它是j2ee的标准。 |
|
返回顶楼 | |
发表时间:2007-01-04
netfly 写道 Wicket是什么?简单点说,它就是一个基于Java的Web开发框架,与Struts,WebWork,Tapestry相类似。其特点在于对Html和代码进行了有效的分离(有利于程序员和美工的合作),基于规则的配置(减少了XML等配置文件的使用),学习曲线较低(开发方式与C/S相似),更加易于调试(错误类型比较少容易,而且容易定位)。如果你不对微软并不反感,可以把它看作Java平台上的ASP.NET。 这是Wicket开发指南上的原话,我知道Tapestry与JSF类似,都是基于服务器组件式的开发,Wicket是不是也和Tapestry、jsf一样?能符合我的第二个标准吗? 不考虑dorado吗?我觉得完全符合你的需求,如果说缺点的话就是非开源。 |
|
返回顶楼 | |
发表时间:2007-01-04
dorado=struts+ajax?在技术上本来就不是很先进,而且不开源,绑定到dorado后就无翻身之日了,只能跟着dorado走。
而且一个简单的struts+ajax,被dorado搞得狂大了,40多M。 |
|
返回顶楼 | |