从JSF和Ext看WebUI开发－－给对JavaScript 有恐惧感的朋友

话题由来：http://www.iteye.com/post/523520?page=1

把其中我的观点整理出来：

100％支持fins！！！ B端和S端彻底分开，分别有自己的框架，“UI层与系统其他层面的东西的唯一联系应该是"数据" ，UI层应该是在后台系统不变的情况下可切换的”，这种架构策略完全可行，而且实际代码上也比JSF/asp.net等“server page”变种优雅，本人已经在N个项目中实践过：

http://www.xjawa.org/xjawa/kontent/10020.html

使用这个7wxAop框架（浏览器端7wx + 服务器端Aop），有个朋友喜欢用Ext做前端，他就把7wx替换成Ext， 照样跑得很好：

http://www.deepsoft.com.cn/ext-aop/demo.html


那些不理解fins得同学，可能是没做过ajax开发，或者ajax用的比较少，或者思想已经被“server page ”方式禁锢。虽然本质上 jsf 还是“server page”，但确实比jsp、tag强很多；但是比起B/S完全分开得架构，jsf还是很丑陋。 我们公司有个项目组用得是SAP得WebDynpro，和jsf类似，要比jsf成熟，但实际开发起来也是很多问题。

个人认为，fins设想的这种架构之所以未被普遍关注，是因为它损害了J2ee大厂商的商业利益，因此他们控制的主流IT媒体不愿宣传。想想：如果Server只是用来接受数据->处理逻辑->返回数据，服务器端将非常Lightweight和Performance，大厂商的J2EE服务器还有高性能硬件还会有几个项目需要？ 

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

。。。正如我前面提到的，不理解fins的人大多是思想被“server pages”禁锢者，总认为浏览器只能负责 html render，其他一切都应该在服务器上完成，就如IT业早期的主机－字符终端模式。这种思想本质上是把浏览器看作21世纪的字符终端，完全忽略和闲置了目前运行浏览器pc的强大计算功能。

。。。在一个server和UI无关的模式下（下面称为“server business”，与“server pages”对应），server只是一个business logic server（只接受UI请求改变或查询系统的state），大致相当于砍掉了J2EE的Web层，Lightweight是肯定的了，至于Performance，除了节省处理
'UI layer'(NOT ONLY 'presentation layer') 的CPU开销，更重要的是大量节省服务器的出口带宽开销。

。。。“server business”模式(SB)与“server pages”模式(SP)本质上是不同的,SP下的'presentation layer'概念并不适合SB模式。

。。。将ajax单纯地视为transition technology本身也没什么错，虽然Ext等前端组件已经超越了这一概念。用Javascript framework称呼基于浏览器的“全功能UI Layer"并不适当，后者 = HTML + DHTML(DOM) + JS，JS只是一个粘合剂，Ext等前端组件本质上只是扩展了HTML Element，假设HTML 6.0包含了功能强大的TreeView、ListView(GRID)等通用UI组件，则JS将回归为单纯的DHTML API操纵语言。 至于RIA(javaFx or Flex)，我认为它是侧重多媒体表现的“全功能UI Layer"的等价物，它的发展前景取决于厂商对它的定位，如果你认同RIA，就没有理由不认同“全功能UI Layer"的思路。
 

JSF：基于服务器端的UI模型，Ext:基于浏览器端的UI模型。

很多人质疑以JavaScript为中心的UI开发，其实是对html/JavaScript的恐惧。

1、 不要把《 HTML(含CSS) + DHTML（或DOM）API + JavaScript开发》 简单理解成 JavaScript 开发。很多人觉得“JavaScript”难以掌握，是因为他们混淆了JavaScript脚本语言本身和它所要操纵的API：其实JavaScript本 身 非常简单，但它所要操纵的API“非常复杂”，因为HTML(含CSS) + DHTML（或DOM）API所涉及的API对象、属性、方法、事件数量巨大，可以说和Win32 API,JDK API（不单是swing/awt）同一个数量级。

2、HTML(含CSS)作为UI的表达语言，其“潜在的”界面表达能力应该说远远超越任何已有高端UI组件库（asp.net，jsf，Ext...）,因为它们本 身 都是基于HTML(含CSS)开发的，要想完整地（还不含绘图）、无障碍表达WebUI，掌握HTML(含CSS)及其API--DHTML（或DOM）是必由之路。

3、所有高端UI组件库的设计思想都是提高组件粒度，以掩盖HTML(含css)的复杂性。不同在于，服务器端UI组件（asp.net，jsf）试图“彻底”掩盖，它们排斥直接使用HTML(含css)，并且操纵UI组件的API面向后端语言（C#,VB,java）；而浏览器端UI组件（Ext等）是“开放性的”封装，允许直接操作HTML(含css)，操纵UI组件的API面向javascript。

4、服务器端UI组件的使用者，一般不太关心组件的具体实现，而且使用中也缺乏HTML+JS的训练，当组件功能满足不了要求时，自己扩展组件的难度很大，也就时说使用组件和开发组件之间存在巨大鸿沟。而浏览器端UI组件的使用者，一般会大致了解组件的实现，使用中频繁接触HTML，JS操纵能力也得到训练，因此他们会比较自然地形成组件改造扩展能力，使用组件和扩展组件之间得学习曲线是平滑的。

5、因此，从开发人员自身职业发展的角度看，要想成为无障碍的Web开发者，使用浏览器端UI组件模式应该是更好的选择。

作为Web开发者，必须热情拥抱HTML（css）和javascript，否则只能是半拉子开发人员。

 

评论

74 楼 s79 2008-05-04  

·B端和S端彻底分开，分别有自己的框架。
彻底分离以前的确有严重问题——客户端计算机的性能和客户端脚本的成熟、应用程度。
现在这种问题越来越少了。在某些强交互类站点如gmap、gmail等，后台可以不生成任何html代码，只是给出数据就可以了。当然对于论坛等需要搜索引擎收录内容的站点，后台还是要把数据混杂在html里发到浏览器，这样的另外好处是在不支持js的客户端仍可浏览。

·何为封装良好的IFrame？
一个更通用的异步通讯方法，应该不仅使用XMLHttpRequest对象，还要使用动态创建<script>元素或<iframe>元素与跨域的服务端交互。因为XMLHttpRequest虽然可以提供更多的交互信息，但他是受同源策略限制的。
leebai所说的原文是“封装良好的IFrame通讯机制比XMLHttpRequest更好用，也更易用。”而不是“封装良好的IFrame”。

73 楼 xzs 2008-05-04  

leebai 写道

Ajax框架的核心是浏览器和服务器之间的异步通讯，通常的Ajax程序使用非W3C标准的 XMLHttpRequest 作为通讯组件，7wxAop没有用XMLHttpRequest，而是采用简单的IFrame。从7wxAop的实践看，封装良好的IFrame通讯机制比XMLHttpRequest更好用，也更易用。

有没有哪个高手告诉我，这段话是否有地方存在问题？何为封装良好的IFrame？

leebai 写道

引用

7，S和B端全部传送的是数据，B端调用的是S端的服务，是否可以把S端完全改造为OO的?业务流程变为B（ajax）-->应用服务--->领域服务--->DAO等基础设施服务。

完全可以。我提倡的就是 View(就是你说的B（ajax）)<－－> Model编程，7wx调用后台Model(WebActions)的方法,就是一种RPC，和dwr是类似的，但比dwr简单。

把后端用OO替换，话说起简单，做做看？一个数据对象在jpa,spring里全部ＯＯ，可到表现层必须一个个肢解然后sendXX到脚本代码里面，别扭吗？特别是模型聚合模型时，难想象。还有业务层提供的ＯＯ数据是否还能够使用7xm的tree和list？不能使用的话就自己重写脚本画界面吧，form就不用说了，已经被多业务层阻挡。

to leebai:
请教一下你的数据页面，当一个表单target到某个内嵌框架IFRAME(buffer)的时候，你是如何做到通过buffer.name的方式获取后台数据的，在你的代码中我没有找到类似new buffer()；buffer.add(var name)之类的代码。每个数据页面中都会出现XcurBuffer=window，为何不直接写死在sys_core.js中？

72 楼 xzs 2008-05-04  

引用

不就是HTML在Server端还是在Client端生成的区别而已吗。

本质如此，可演化出了一种程序思想！

引用

B端和S端彻底分开，分别有自己的框架，“UI层与系统其他层面的东西的唯一联系应该是"数据" ，UI层应该是在后台系统不变的情况下可切换的”，这种架构策略完全可行，而且实际代码上也比JSF/asp.net等“server page”变种优雅

彻底分离是否存在某些严重的问题？如果没有问题，那么这样的框架应该早百年就流行了。不过看到下面这段话把我吓一跳！！
leebai:

引用

我认为，不管是哪种粗粒度界面组件实现，最好都由浏览器厂家联合来做，做出标准、通用、有持久生命力的界面组件。微软推出.net的时候，粗看简介我还以为是理想中的界面层技术，细看代码原来还是“服务器动态页面”，后来SUN的JSF也这么学，我们公司一个项目组现在在用的SAP的webDypro也是，因此我都有点怀疑:业界大佬们之所以不愿意在客户端组件上下功夫，之所以不想变革目前的Web应用架构，不是因为他们没看到技术需求，而是因为，他们的根本利益在于利润丰厚的各种服务器端产品；Web开发之所以搞得这么复杂，里面说不定有什么惊天大阴谋；或者说，这些业界大佬们睁一只眼闭一只眼地看着广大Web开发者累得死去活来，看着Web独立开发商和集成商一个个倒下去，却背过身去窃笑着点着大把的钞票----扯远了:)，这问题有空发个专贴，反正做了6年IBM独立开发商就给我这种感觉。

惊天大阴谋，高手果然就是高手
下载的xjawa.zip第一天跑得很欢，可正当准备研究它的时候出问题了，主页可以打开，但进不了论坛：

71 楼 nickcen 2008-04-30  

不就是HTML在Server端还是在Client端生成的区别而已吗。

70 楼 leebai 2008-04-29  

<div class='quote_title'>asheng88 写道</div>
<div class='quote_div'>
<div class='quote_title'>引用</div>
<div class='quote_div'>你老盯着那cms/bbs干嘛，重点是框架。。。。7wxAop代码很少，读读代码就知道性能好不好了。 <br/></div>
<br/>呵呵，对于框架和应用系统我更喜欢研究应用系统，应用系统的性能不是框架决定的吗？ <br/><br/>在tomcat6.0上安装XJawa宣告失败，建议官网上直接提供可运行包下载！要框架让更多的人使用就要低高手一起照顾，再说真正高手又有几个。 <br/><br/></div>
<p> </p>
<p> </p>
<p>看错误信息，是路径映射没成功。看看这个加了没有：</p>
<p><span style='color: #999999;'>  &lt;servlet-mapping&gt;<br/>    &lt;servlet-name&gt;cms5server&lt;/servlet-name&gt;<br/>    &lt;url-pattern&gt;/xjawa/*&lt;/url-pattern&gt;<br/>  &lt;/servlet-mapping&gt;</span></p>
<p><br/><br/>还要注意第4步： <br/><br/><span style='color: #888888;'>4、库lib：将{xjawa}/lib/下的所有文件复制到{WebRoot}/WEB-INF/lib/，将其中的cmsbbs.zip解压到{WebRoot}/WEB-INF/classes/。 <br/></span><br/>cmsbbs.zip解压后，不能是classes/<span style='color: #ff0000;'>cmsbbs</span>/com/xjawa/。。。应该是classes/com/xjawa/</p>
<p> </p>
<p> tomcat太大了，怕它。</p>

69 楼 asheng88 2008-04-29  

引用

你老盯着那cms/bbs干嘛，重点是框架。。。。7wxAop代码很少，读读代码就知道性能好不好了。

呵呵，对于框架和应用系统我更喜欢研究应用系统，看看这个框架真正面对应用系统的时候具备怎样的趁手程度！

在tomcat6.0上安装XJawa宣告失败，建议官网上直接提供可运行包下载！要框架让更多的人使用就要低高手一起照顾，再说真正高手又有几个。

68 楼 leebai 2008-04-29  

<div class='quote_title'>asheng88 写道</div>
<div class='quote_div'><br/><br/>谢谢你的回答，可不可以把这个框架在tomcat中部署具备web.xml标准部署文件的文档帖过来，我在网站上找了下没找到？或者贴一个能够直接运行在tomcat中的helloworld.war。 <br/>对于XJawa论坛的速度，因为在线人数不多，如果来个几千人在线不知道速度会咋样？非OO编程基本上不用考虑堆内存问题，回到了php和早期asp直接刷页面无线程时代，Java编程最考验我的就是服务器的多线程了。对于这个框架如你所说已经被很多项目所检验，我不去怀疑它的稳定，安全以及性能，我会继续学习它并尝试把后端改造成ＯＯ的。 <br/></div>
<p><br/><br/>web.xml：<a href='http://www.xjawa.org/xjawa/kontent/80111.html'>http://www.xjawa.org/xjawa/kontent/80111.html</a></p>
<p>你老盯着那cms/bbs干嘛<img src='../../../../../../images/smiles/icon_twisted.gif' alt=''/>，重点是框架。。。。7wxAop代码很少，读读代码就知道性能好不好了。</p>
<p> </p>

67 楼 KKFC 2008-04-29  

不用怕JS,去看EXTJS OO的源码！

66 楼 asheng88 2008-04-29  

leebai 写道

谢谢这么认真地看我写的东西，呵呵。
对开发者来说，相比传统程序，Web程序的独特魅力在于，同样的功能，可以有N种不同的实现方法，开发语言可以不同、开发框架可以不同、开发思想可以不同、实现技巧可以不同。。。掌握不同技术的人，有时候连沟通的词汇表达都不容易相一致，所以，要理解7wxAop这样的“与众不同”的框架，首先要“解放思想”，回归Web应用本质性的东西（也就是底层技术）：HTTP、HTML/javascript、Servlet API(对java阵营)。在本质性的东西上面，任何开发者之间其实都是很容易沟通的

谢谢你的回答，可不可以把这个框架在tomcat中部署具备web.xml标准部署文件的文档帖过来，我在网站上找了下没找到？或者贴一个能够直接运行在tomcat中的helloworld.war。
对于XJawa论坛的速度，因为在线人数不多，如果来个几千人在线不知道速度会咋样？非OO编程基本上不用考虑堆内存问题，回到了php和早期asp直接刷页面无线程时代，Java编程最考验我的就是服务器的多线程了。对于这个框架如你所说已经被很多项目所检验，我不去怀疑它的稳定，安全以及性能，我会继续学习它并尝试把后端改造成ＯＯ的。

65 楼 leebai 2008-04-29  

to edzhh:

呵呵，是有点像。。。。

所以大家都说ajax是新瓶装旧酒。。。。。

64 楼 leebai 2008-04-29  

to asheng88:

谢谢这么认真地看我写的东西，呵呵。

对开发者来说，相比传统程序，Web程序的独特魅力在于，同样的功能，可以有N种不同的实现方法，开发语言可以不同、开发框架可以不同、开发思想可以不同、实现技巧可以不同。。。掌握不同技术的人，有时候连沟通的词汇表达都不容易相一致，所以，要理解7wxAop这样的“与众不同”的框架，首先要“解放思想”，回归Web应用本质性的东西（也就是底层技术）：HTTP、HTML/javascript、Servlet API(对java阵营)。在本质性的东西上面，任何开发者之间其实都是很容易沟通的。

引用

1，既然这个框架用的是servlet，怎么没有出现WEB-INF,web.xml这些东东啊？如果我要搞一些过滤器，监听器,容器安全认证之类的咋弄？

如果要在框架自带的“剥去皮的Jetty服务器”上安插过滤器等东西，则直接修改org.xjawa.system.server.MiniServer[ 你可以把MiniServer当做web.xml（.java其实比.xml容易阅读:-)）。 ]；如果将框架部署在Tomcat等标准服务器上，则可以使用标准的web.xml，网站上有一个其他服务器部署文档，你可以看看。

历史：WEB-INF,web.xml是Servlet API 2.2版本的后才出现的概念，早期（2000－2002）的7wxAop运行在IBM Websphere 2.x 3.x以及老的Oracle APP server上面,这些应用服务器对Servlet API版本的支持相对滞后，所以7wxAop最早的运行环境没有WEB-INF,web.xml。

引用

2,<meta http-equiv="refresh" content="0; URL=index.page">，index.page这是啥跳转法？

同1，如果部署在其他服务器下，你可以用标准的配置方法。index.page其实就是index.jsp，*.page是一个路径映射（其实是CMS的一个设计，框架临时借用）。

引用

3，论坛首页的那个index.jsp中com.xjawa.cms5server.*引用的java类在哪里，src没有啊？而且src下的程序用eclipse重新编译一下错误一大串。

这个包属于框架之外的Kontent CMS，src中没有，对应文件是/lib/cmsbbs.zip。按文档指示的步骤导入所有lib、src，就不会有编译错误了。

引用

4，论坛的index.jsp显示的数据浏览器是什么时候从服务器取过来的，是否是页面加载的时候自动调用loadok函数？例子helloworld是自己触发一个按钮callServer然后回调得到的数据，struts也至少有一个action到jsp页面的转发过程。

就是loadok。要理解7wxAop机制，就要彻底忘掉struts/MVC，回到Web技术最基本的东西。

引用

5，搞不懂response.sendRedirect("/xjawa/kontent/10000.html");是咋个跳转的？我怎么找不到这些文件，伪静态吗？好像没见到支持伪静态的什么包啊？

这是Kontent CMS 的一个路径映射，读读org.xjawa.system.server.MiniServer你就清楚了。

引用

6，XJawa！网站速度还可以，但是我印象中速度最快还是算jdon了，XJawa论坛有缓存吗？没有缓存都这么快，神了！

这也是Kontent CMS 的东西。cms/bbs都有缓存，7wxAop的代码很简洁,即使不用缓存速度也很快的（你可以操作一下Kontent cms的后台管理）。

引用

7，S和B端全部传送的是数据，B端调用的是S端的服务，是否可以把S端完全改造为OO的?业务流程变为B（ajax）-->应用服务--->领域服务--->DAO等基础设施服务。

完全可以。我提倡的就是 View(就是你说的B（ajax）)<－－> Model编程，7wx调用后台Model(WebActions)的方法,就是一种RPC，和dwr是类似的，但比dwr简单。


欢迎大家继续提问或质疑。

63 楼 edzhh 2008-04-29  

这种模式很早前就有应用了,中兴有套AJAX中间件也差不多,我是在中兴的一套电信"电子运维系统"中接触到的,我在几个项目中也应用过类似的模式.

62 楼 edzhh 2008-04-29  

有做广告的嫌疑!!!

61 楼 asheng88 2008-04-29  

牛人leebai老大，你的框架使我眼前一亮，看了一下，好多地方被迷惑住了：

1，既然这个框架用的是servlet，怎么没有出现WEB-INF,web.xml这些东东啊？如果我要搞一些过滤器，监听器,容器安全认证之类的咋弄？

2,<meta http-equiv="refresh" content="0; URL=index.page">，index.page这是啥跳转法？

3，论坛首页的那个index.jsp中com.xjawa.cms5server.*引用的java类在哪里，src没有啊？而且src下的程序用eclipse重新编译一下错误一大串。

4，论坛的index.jsp显示的数据浏览器是什么时候从服务器取过来的，是否是页面加载的时候自动调用loadok函数？例子helloworld是自己触发一个按钮callServer然后回调得到的数据，struts也至少有一个action到jsp页面的转发过程。

5，搞不懂response.sendRedirect("/xjawa/kontent/10000.html");是咋个跳转的？我怎么找不到这些文件，伪静态吗？好像没见到支持伪静态的什么包啊？

6，XJawa！网站速度还可以，但是我印象中速度最快还是算jdon了，XJawa论坛有缓存吗？没有缓存都这么快，神了！

7，S和B端全部传送的是数据，B端调用的是S端的服务，是否可以把S端完全改造为OO的?业务流程变为B（ajax）-->应用服务--->领域服务--->DAO等基础设施服务。

60 楼 leebai 2008-04-28  

to achun :

你那个也是一条路，但怎么做都有代价，编程很多时候是平衡的艺术。

59 楼 leebai 2008-04-28  

hax 写道

leebai 写道

如果新的 HTML Specification 能包含treeview、listview、grid。。。等大粒度组件，web UI模式之争其实没有任何悬念，甚至RIA都不是对手（flex/javafx等要达到HTML/CSS同等的表达能力几乎是不可完成的任务，如果达到了，就是另外一个浏览器引擎了），虽然多媒体及图形方面RIA将会保持自己的价值。

在HTML升级之前，我认为最好的办法是以现有的，形式最接近的HTML元素为骨架，组合其他合适的HTML元素,通过扩充骨架HTML元素的属性、方法、事件，来构造大粒度的UI组件。目前的7wx组件已经很老了，新版本将会融合近来的一些想法，应该会有比较大的更新。

非常赞同。实际上我觉得有了HTML5，基本上客户端模板就没有用武之地了。所以还不如做一个框架来在早期浏览器上实现HTML5。

确实，看了HTML5 Draft，貌似极其强大，datagrid控件，Data Templates，离线应用支持，Client-side session及DB。。。

但太强大了，估计要有浏览器支持也是3－5年之后，还是自己继续想办法吧。

58 楼 achun 2008-04-28  

to leebai:
呵呵,你用最简单的(应该是IFRAME吧)方式处理了这个问题.也是一种安逸的方案.
至于

引用

还有以下问题：假如一页显示10条，增加5条或删除5条后一页应该显示几条？如果当前已经被翻到了第200页，增加一条后显示哪一页？B/S系统是典型的多用户系统，如果你增加了一条数据期间，另外其他用户还增加了3条数据，那列表显示哪些数据,列表的总条目数怎么显示？

为了简单和方便我倒是有个简单的方法,假设页面上初始记录是10条.添加/删除后,
记录数变化了,直接添加/删除对应页面上的表格行就行了,没有必要一直保留10条不变呀.也同样没有必要在添加的时候抱着必须按某某次序排列的规则.
我现在的项目就是这样干的,而且更新也是动态的重新改写对应的表格行.仅仅是那一行,如何定位这一行很简单根据数据的值生成一个规则的唯一ElementID就行了.
jQuery代码

$('#ElementID').attr('id','').after(youhtml).remove();

至于youhtml就是生成的更新数据的代码了.
另外attr('id','')这个也不是必须的,纯粹是出于严谨的角度做的.

57 楼 leebai 2008-04-28  

<div class='quote_title'>achun 写道</div>
<div class='quote_div'>to leebai: <br/>就举你的xjawa包里面的例子吧: <br/>xjawa后台里面有个对文章管理的模块，里面的数据都是主帖，你的例子里没有从贴（分页帖子）， <br/>如果有的话（很多文章都有的，这可以随处看到）， <br/>你的从贴信息如何显示？ <br/>如果要修改主贴或者从贴，按你现在的演示，肯定要刷新多次的。 <br/>因为在没有从贴的先在你的修改就要刷新页面，要是带上从贴刷新就更烦了。 <br/>你不要说这符合习惯，习惯是可以改的， <br/>再说你可以说这符合普通用户的习惯，如果是你做文章的审核，你自己也这样不停的切换刷新页面，你不烦么？ <br/>而且现在你的页面，每次修改的时候，表格状的信息列表都消失了，如果有很多记录要处理，而且还是记录分页的，每次刷新完了之后，重新定位到上次某个记录分页，这个信息你放到那里？cookie?session?后退？ <br/>如果是无刷新的页面这些问题可能就都解决了，而且操作起来会很舒服。 <br/>所以说用户也许不需要，可我们自己的编辑审核人员确实需要，给自己方便那是提高直接的效率，是有意义的。 <br/>其实我上面的这个说法已经是妥协的说法，退一步的说法了， <br/>所谓的用户习惯，户体验度，那是因为你没有给他更好的选择，给了他更好的选择不信他不要。 <br/>页面上不只是有给最终浏览者看的方式，还有信息管理者的需求。</div>
<p> </p>
<p> 基本明白你说的意思了，好像和主从表无关，应该就是那个经典的问题： </p>
<p><span style='text-decoration: underline;'>信息列表中的条目增、删、改时，信息表单页和信息列表页之间如何互动，信息列表页的列表显示如何更新。 </span></p>
<p><br/><strong>1、先说列表页与表单页如何互动（增、改时）。</strong></p>
<p>C/S和桌面应用一般是先显示列表界面，再打开单独的Model对话框显示表单，在最初的7WX UI模型 模拟C/S和桌面应用，也是保持列表页不变，另打开新页面显示表单，但感觉IE初始化一个新窗口有点迟滞，不够流畅。</p>
<p>B/S应用的习惯是页面切换，既表单页打开时替换了列表页，不用打开新窗口。表面上，你现在看到的<span style='color: #ff0000;'>7WX UI改进模型</span>就是典型B/S方式，但其实不是，如下图所示，7WX其实同时布局了列表页<span style='color: #ff0000;'>listView</span>和表单页<span style='color: #ff0000;'>DocView</span>两个窗口，打开DocView时，listView并未关闭，只是默认隐去，你可以点一个键将其显示出来。当然，这种方式也未必是最好的方式，咱们可以讨论探寻<span style='color: #ff0000;'>更人性化、更流畅</span>的界面方式。 </p>
<p> </p>
<p><img src='../../../../../../topics/download/cbf42c6e-cf72-3324-9e88-668115fb4d31' height='270' alt='listview and docview' width='692'/> </p>
<p> </p>
<p><strong>2、再说列表显示的更新问题(增、删、改时)。</strong></p>
<p>B/S应用的列表显示与桌面应用不同，牵涉翻页问题：数据条目可能有几万条，但每页一般不超过百条。即使是Ajax开发，也不能一次性把所有条目都取到浏览器，7wx的设计是：每页显示几条，就取几条，不做过度设计。</p>
<p>增、删、改时，Ajax模式下首先要向服务器发送更新请求，请求被正确处理返回后，要进行列表显示更新，有两种办法：</p>
<p>* <span style='color: #ff0000;'>客户端独立完成的列表更新</span><br/>* <span style='color: #ff0000;'>从服务器重新取列表数据进行更新</span></p>
<p>7wx权衡后采用的是后者，缺点是增加一点服务器开销，优点是用户程序极其简单（7wx中，用户程序只需一个调用：Xrefresh();）。<br/>如果为了降低一点服务器开销采用前者，则，除了用户程序繁琐外，还有以下问题：<span style='color: #ff0000;'>假如一页显示10条，增加5条或删除5条后一页应该显示几条？如果当前已经被翻到了第200页，增加一条后显示哪一页？B/S系统是典型的多用户系统，如果你增加了一条数据期间，另外其他用户还增加了3条数据，那列表显示哪些数据,列表的总条目数怎么显示？</span>这类问题估计不止这些，我认为，客户端独自更新列表获取的好处，相比其导致的问题，很不值。</p>
<p>此外：7wx的列表翻到某一页时，你更新这一页的某个条目后，框架自身能确保：<span style='color: #ff0000;'>刷新列表（Xrefresh()）显示的还是这一页</span>，用户程序不需任何干预，既，不用考虑你说的“。。。这个信息你放到那里？cookie?session?后退？”，你可以操作试试。</p>

56 楼 icewubin 2008-04-28  

hax 写道

icewubin 写道

对呀，如果不是为了点击量，不停刷新太消耗服务端资源了吧。

这里有两个问题。用户体验相对来说更加重要。至于服务器性能倒是次要问题。

如果使用户量大的网站，会很容易导致服务器的负载数下降的，既然你说“用户体验更重要”可能使我对讨论的问题理解有问题。至少觉得，刷新的频率要控制一下，稍微智能点，开个玩笑，比如用户手动操作很久不动了，就不要再刷了，呵呵。

55 楼 leebai 2008-04-28  

太晚了，简单回答JJYAO同学：
1、组件接口是封装的，而且符合你的简洁原则，只不过是接收数组作为参数，不知你为何觉得不妥？

2、你说的Action就是我说的Web层，已去掉；我说的Action就是业务方法。

3、如1

4、感觉你还是没有意识到（可能和你的工作背景有关）：B-UI中，页面导航根本不是问题。

5

6、多文件批量查找、替换其实都很简单，关键是善用工具。一直感觉改XML文件不如改代码。我用这个做项目6－7年了，还没见到后台要变包名，方法名的情况。

谢谢，先睡觉去了。