|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-02-21
dlee 写道 WebWork的基础设施的价值在以数据为中心的Ajax应用中仍然是很可疑的。这样用的话，你不是一样还是要自己打造基础架构？即使仅仅做一些集成，仍然没有达到你的开箱即用解决方案的目的（当然我的方案也没有达到，但是我并没有追求这个目的）。
我们不能凭借这些只言片语来做出判断，我们需要进行更加深入的架构分析。 下面继续robbin启动的这个话题：基于tag封装的Ajax开发方式优雅吗？这样的解决方案足以包治百病吗？ 复杂的交互需求不存在吗？其实很多，我来多举几个，讨论一下那种方式建造起来方便？那种方式更加优雅： a. 基于tag封装，返回innerHTML的方式； b. 直接包含静态的JS（相对于服务器端），通过robbin所谓的web remoting方式请求数据的方式。 1. 实现一个模仿Excel操作模式的Grid组件，可以选择、全选、反选、删除，可以根据某个条件筛选数据。可以按每一列排序。可以直接在界面上面添加一行，修改每一行的数据。可以定义表达式计算某一列的值。可以拖动某一列到另外一个位置。自动实现分页。 这样的Grid在企业应用中非常有用，尤其是需要产生大量报表的应用中。 2. 一个复杂的Tree组件，可以展开多层，在展开某层的时候自动获取数据。这类组件大家都用的比较多了。 3.讨论一下类似于Google Maps的地图拖动，使用第一种方案是否很方便地建造。 上面这些应用的基础其实都是采用以数据为中心的方式来建造的，即使最后封装为tag，也只是最后一道工序。所以以数据为中心的方式比以内容为中心的方式更加基础、更加灵活、更加强大。 国内的有些公司其实在JS开发方面，已经有了大量的积累，有的还形成了成熟的商业产品。 robbin可以看一下这个公司的展示： http://www.bstek.com/ 虽然只能运行于IE之上（IE5/IE6），但是这套组件功能是很丰富的，对于企业应用非常有帮助（还有人说企业应用不需要Ajax吗？）。我们可以逐一探讨一下这些组件如果采用WebWork推荐的基于tag的以返回innerHTML为主的开发方式开发起来，是否真正优雅，开发起来是否会比直接写JS，通过某种Ajax remoting方案请求数据更加方便。 |
| 返回顶楼 | |
|
发表时间：2006-02-21
引用 WebWork的基础设施的价值在以数据为中心的Ajax应用中仍然是很可疑的。这样用的话，你不是一样还是要自己打造基础架构？即使仅仅做一些集成，仍然没有达到你的开箱即用解决方案的目的（当然我的方案也没有达到，但是我并没有追求这个目的）。
你好像没有仔细过看我的总结陈词，在web remoting方式下，当然不需要webwork，这一点我上面发言已经多次提到了。 引用 下面继续robbin启动的这个话题：基于tag封装的Ajax开发方式优雅吗？这样的解决方案足以包治百病吗？
我可从来没有说webwork基于tag封装的AJAX开发方式是优雅的，你看看我上面发言，我明明说的是webwork的AJAX支持是丑陋的。其实我用webwork搭配prototype/buffalo的话，那也是直接在页面里面写JS，和JSP Tag可不搭界。 引用 实现一个模仿Excel操作模式的Grid组件，可以选择、全选、反选、删除，可以根据某个条件筛选数据。可以按每一列排序。可以直接在界面上面添加一行，修改每一行的数据。可以定义表达式计算某一列的值。可以拖动某一列到另外一个位置。自动实现分页。这样的Grid在企业应用中非常有用，尤其是需要产生大量报表的应用中。
基于prototype的rico有这样的grid组件，基本上实现了你上面说的大部分功能，这个和是不是web remoting没有啥关系吧，我就不web remoting一样可以用rico做到。另外比较置疑的是，产生大量报表的grid难道还能允许你删除条目，和拖动列？ 引用 2. 一个复杂的Tree组件，可以展开多层，在展开某层的时候自动获取数据。这类组件大家都用的比较多了。
这个并不一定要用web remoting，dojo就有这样的tree组件，也就是web request方式实现的。 引用 3.讨论一下类似于Google Maps的地图拖动，使用第一种方案是否很方便地建造。
这个不了解。 引用 上面这些应用的基础其实都是采用以数据为中心的方式来建造的，即使最后封装为tag，也只是最后一道工序。所以以数据为中心的方式比以内容为中心的方式更加基础、更加灵活、更加强大。
其实我上面也说过好几次，很多情况下是必须用web remoting，我没打算否认采用web remoting实现以数据为中心应用的必要性。 引用 > 国内的有些公司其实在JS开发方面，已经有了大量的积累，有的还形成了成熟的商业产品。
> robbin可以看一下这个公司的展示： > http://www.bstek.com/ > 虽然只能运行于IE之上（IE5/IE6），但是这套组件功能是很丰富的，对于企业应用非常有帮助（还有人说企业应用不需要Ajax吗？）。我们可以逐一探讨一下这些组件如果采用WebWork推荐的基于tag的以返回innerHTML为主的开发方式开发起来，是否真正优雅，开发起来是否会比直接写JS，通过某种Ajax > remoting方案请求数据更加方便。 这两个框架不好直接比较，因为首先他不兼容FireFox，就被我排除在外了，更何况他又不是开源和免费的软件。 |
| 返回顶楼 | |
|
发表时间：2006-02-21
cleverpig 写道 我想无论MVC、Ajax都无法解决的一个问题就是当用户交互出错时的back问题，如果只是简单的history.back那就失去了其原有的意义。
我想从这一点看wicket作的很好，因为它将浏览器中的交互组件化，每个组件都保存其状态。 由于组件在其生命周期中具备了状态，用户信息就被很好的保存下来，这虽然增加了server上的内存开销，但是丑陋的history.back问题能够顺畅的被pass掉。 这也是wicket设计者的初衷之一。 使用Struts开发，我们将获得全部的状态管理权。这对于建立大规模的、高升级空间的、集群应用来讲是很好的，因为我们将获得对HttpSession上每件事物的控制权。但是对于中小型应用，我们将没有缘由编写一些额外的代码。这样将导致应用变得复杂和编写费时。 在状态管理上，Wicket可以作为一个不错的选择。Wicket框架默认代管所有的组件状态。这对于中小型应用，在状态管理上的代码量几乎为0。但是 Wicket也提供了一些API使我们进行标准状态管理和实现自己的状态管理。这样，即使是大型应用，我们也能够全权掌握状态管理。事实上，即使在使用 Wicket编写大型应用时，通常也是先让Wicket代管所有的状态，然后再慢慢的实现自己定义的状态管理以提高应用性能。 Wicket是基于web应用框架的高级组件，其主要特点： * 在HTML和java之间的明确分隔 * OO组件模式 * 自动状态管理 * 高度生产化 * 低学习投入 * 屏蔽Servlet API、HTTP协议细节 * 无需XML配置文件 * 易于构造可重用组件 而Struts是以Model2 MVC 为蓝本构建的web应用框架。其工作围绕着处理HTTP请求的action类来完成。配置方式采用XML文件。 有关wicket的信息可以看看：http://wicket.sourceforge.net/ - 显示引用文字 - |
| 返回顶楼 | |
|
发表时间：2006-02-21
dlee 写道 你去看一下rico请求的究竟是数据还是html片断。如果请求的是数据，就是以数据为中心的应用。共产主义并不是总是为你准备的，还是有一天你有必要建造自己的JS组件的。 另外比较置疑的是，产生大量报表的grid难道还能允许你删除条目，和拖动列？ 为什么不能删除？难道你使用Excel的时候不能删除某一行吗？输错了当然可以删除。 拖动列的需求也是存在的，我来举个例子，比如报表很宽，有20几列，在同一个屏幕上看不到，这个时候就有必要把某些列隐藏掉，显示后面的列。长长的水平滚动条方式来实现是很笨拙的。还有有些时候，需要对打印的列的顺序做出一些调整，这个时候也有必要拖动某些列。 我的主要意思还是说，以数据为中心的Ajax开发方式是最基础的，实际上XMLHttp诞生的时候所有的例子都是这种方式。建造复杂的JS组件必须基于这种方式。只有一些简单的交互场合，才适合使用以内容为中心的Ajax开发方式（就是服务器生成HTML片断，直接为innerHTML赋值）。而我们在开发过程中，感觉这种以数据为中心的开发方式对于90%的交互场合都够用了。WebWork和Struts的基础设施最初并不是为这样一类应用服务的，所以在以这种开发方式为主的环境中，价值大打折扣。我想我们最后在这个问题上，已经基本上达到了一个共识。 |
| 返回顶楼 | |
|
发表时间：2006-02-22
太长了，后面的没太多的看，我以为前面的两种做法都没什么错，HTTP REQUEST+Ajax Remoting和纯粹的Ajax Remoting。
就像是两个人争论 甲说：这个柱子是圆的 乙说：不对，这个柱子很长 其实两个人都对，我上一个项目里就是用纯粹的Ajax Remoting，就像robbin说到的遇到很多的基础编码工作，当然很大程度上都需要自己解决，不过由于项目的规模小，所以还好，但是问题的关键是在尝试，技术平台的发展我们可以作些探索工作，不一定总要等到别人做好现成的，我们也可以努力让自己成为问题的解决者。 |
| 返回顶楼 | |
|
发表时间：2006-02-23
我觉得纯粹的Ajax Remoting在server端也是要用到serverlet，这时如果用webwork来做这部份不也可以；如果要纯数据，我的result返回xml或者客户端需要的数据格式，把webwork的action 当作service。
这样我的选择余地就比较多，而且也保留了我已有的知识，然后逐步实现ajax，在前途不明或者实现有瓶颈的时候 也容易掉转船头。 我觉得现阶段不是优先考虑server端，而是优先做一些client关于内容转换的一些好的框架，专注于得到一个数据怎么构造视图，比如象displaytag在js实现，只要给一个列表数据，就能生成对应的grid。 xmlhttp请求也发了，数据也到client端了，能不能有个成熟的框架能让开发者通过简单的调用，生成比较出彩的view出来。也许和前面dlee说的什么xul之类的技术有点类似。 因此我觉得现在应该做好client这边的处理先，而不要一下子就要server、client两头抓。可以在做client的时候定义它需要的数据内容和格式，就像xml和dtd的关系，然后把这个提供给调用者，只要规定调用我的ajax，server side给我的数据必须是这样提供的。这时才不管你server是java的还是静态的文本文件，只要拿的出规定格式的数据就行，即使是一段heml片段只要框架允许就行。 |
| 返回顶楼 | |
|
发表时间：2006-03-12
我想我也仅仅只有半只脚是踩在Ajax的门里面而已。：）。
讲讲偶对Ajax的看法，可能没涉及到PK，只是对前面的讨论有些少的想法。 Robin所说的ajax request和ajax remote在我看来实际上是一样的东西。都是异步地向服务器发了个请求，服务器总会有所谓的网关来为这些请求服务。 ajax request的情况，比如使用Webwork,js 这样写open("xxx.action");这时处理请求的是Webwork的Servlet或是Filter，返回来的是些页面片断。这页面片断可以是HTML，XML，纯文本，Json对象图等等等等。。。如果把它当作HTML来看，那只需要在客户端拿到响应对象的ResponeseText直接写在某个DIV块上就得了。如果是XML，Json对象图之类的（这算是返回数据了吧。。嘿），就还得在客户端用Js Rend一下，这样ajax request不一样有了ajax remote的味儿了吗。 ajax remote的情况，不管是DWR还是Buffalo，为了给客户端的JS提供（好像叫“暴露”更爽些）服务，同样在服务器端实现网关。同样是Servlet。而响应方面，我了解DWR给客户端返回的是XML格式的数据，Json Rpc返回的是Json对象图，说白了还是文本。 嘿。说到这里，发觉就不觉得有什么本质上的区别了。剩下的，也许只有喜好上的区别罢了。我很赞同Robin的做法，因为我在项目上也是这样做的。也由于历史遗留和设计的根本原因，我们不可能光用DWR这样的Remote框架，然后自已去实现一大堆的资源国际化，权限管理等等（Webwork做得那么好，我都不忍心不用）。 返回数据，让客户端来Rend的方法，必要的时候会用。目前来说，在服务器端返回一个HTML片断，已经能让偶很爽了。 上面仅代表个人喜好。也许并不触及讨论的本质。如的确如此，莫见怪。 
|
| 返回顶楼 | |
|
发表时间：2006-03-13
web reqeust和web remoting本质上没有区别，都是通过XMLHTTP通讯，也可以定制一个Web Action来充当Web Remoting方式下的Gateway，这是一个显而易见的事实，我想讨论的不是这一点。web request还是web remoting这种区别不是通讯方式上的区别，而是服务器端和客户端两端架构上的差别。
|
| 返回顶楼 | |
