从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，否则只能是半拉子开发人员。

 

评论

54 楼 achun 2008-04-27  

to leebai:
就举你的xjawa包里面的例子吧:
xjawa后台里面有个对文章管理的模块，里面的数据都是主帖，你的例子里没有从贴（分页帖子），
如果有的话（很多文章都有的，这可以随处看到），
你的从贴信息如何显示？
如果要修改主贴或者从贴，按你现在的演示，肯定要刷新多次的。
因为在没有从贴的先在你的修改就要刷新页面，要是带上从贴刷新就更烦了。
你不要说这符合习惯，习惯是可以改的，
再说你可以说这符合普通用户的习惯，如果是你做文章的审核，你自己也这样不停的切换刷新页面，你不烦么？
而且现在你的页面，每次修改的时候，表格状的信息列表都消失了，如果有很多记录要处理，而且还是记录分页的，每次刷新完了之后，重新定位到上次某个记录分页，这个信息你放到那里？cookie?session?后退？
如果是无刷新的页面这些问题可能就都解决了，而且操作起来会很舒服。
所以说用户也许不需要，可我们自己的编辑审核人员确实需要，给自己方便那是提高直接的效率，是有意义的。
其实我上面的这个说法已经是妥协的说法，退一步的说法了，
所谓的用户习惯，户体验度，那是因为你没有给他更好的选择，给了他更好的选择不信他不要。
页面上不只是有给最终浏览者看的方式，还有信息管理者的需求。

53 楼 leebai 2008-04-27  

晕，“页面需要不停的刷新”，icewubin和hax都看懂了，就我没看懂，看来这里又用重大的个人工作背景差异！

52 楼 hax 2008-04-27  

icewubin 写道

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

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

51 楼 leebai 2008-04-27  

<p>to achun: <br/><br/>“页面需要不停的刷新”？没看懂 <br/><br/>主从表的录入模式，主要考虑业务本身的<strong><span style='color: #ff0000;'>事务(transaction)特性</span></strong>：如果主记录可以独立存在（既，无子记录的主记录也是有意义的），则插入主记录的操作是<span style='color: #ff0000;'>独立的事务</span>，插入子记录也是独立的事务；如果主记录不可独立存在，则插入主记录和插入子记录应该设计成<span style='color: #ff0000;'>同一事务</span>。无论是前者，还是后者，我都没看出为何要“页面需要不停的刷新”，麻烦再说清楚点:-)</p>

50 楼 achun 2008-04-27  

hax 写道

初步看了achun的jct，不是很看好。看上去jct比较接近传统模板，只是放到了前端。希望能看到jct更多的文档。

有点欣慰，只要你看了，我就高兴。
不追求你能认同，因为都认同了这个世界就不会进步了。
不同才能进步。如果能启发你新的思路那就更好了。
另外就是你说什么有些问题js模板同样也解决不了，是什么?我对具体问题的热情，比纯理论探讨更有兴趣。
举个具体的问题。

49 楼 JJYAO 2008-04-27  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<div class='quote_title'>JJYAO 写道</div>
<div class='quote_div'>我大致看了下楼主自己开发的web框架，可以说是典型的JavaScript based的web框架。与几年前在市场上做的比较好的dorado类似。典型的特征是在客户端有一套相对比较丰富的JS UI组件和DataBinding机制 <br/><br/>首先肯定一下楼主的框架，XJawa具备以上特征，应该说也确实能够实现一定范围内的快速开发。但单纯从技术上看Xjawa，我觉得还有几点值得探讨 <br/>1. 客户端的对象类型都是Javascript数组 （是否意味着在客户端模型的基本仍然停留在JavaScript低层语言级别，开发人员还需要掌握JavaScript语法）。另外，这套框架应该开放了大量的JS接口，这套接口学习的成本不低。所谓几个小时的培训恐怕～～ <br/>2. 从该框架在服务端需要编写WebActions的子类可以看出，离所谓的纯粹的B和S还有点距离（WebActions子类完全不是业务方法，方法参数居然还是HttpServletRequest），这个比较好的实现楼主可参考DWR和Seam的实现 <br/>3. 楼主自行开发了大量的UI组件，这些组件应该是纯粹的JS控件。JS控件的缺点就是随着需求增加，控件的复杂度不断提高，最终可能会使得控件难以发展和维护 <br/>4. XJawa是否属于one page one application?如果不是，现在如何处理页面的navigation? <br/>5. 其他问题，客户端的性能，是否延迟加载等等 <br/>6. 其他的由于业务复杂度导致的问题(多是导致页面动态性，比如通过某种复杂的条件导致页面大面积动态变化或替换XJawa是否能胜任)? <br/><br/>从楼主实现的框架和帖子来看，有少许对服务端技术的偏见。这点我也可以理解。我的建议是多比较比较客户端技术和服务端技术在整体和局部上的细节差异和优缺点，是不是真的如自己想象的那样。 比如楼主一再强调的 <br/><br/>
<div class='quote_title'>引用</div>
<div class='quote_div'>在正真的B-UI应用中，Browser自己负责界面构造和界面跳转，Server只负责提供business logic 访问，也就是说Server上根本就不需要S-UI的Web层（虽然还是HTTP访问），没有所谓的Controler，也就是说MVC不再是真理，Spring MVC/Struts之类的Web层框架完全没有必要。 </div>
<br/><br/>其实在你的框架里并没有真正实现，而目前服务端技术其实已经完好的实现了.从我以往的经验，不要过分将自己东西绑死在某一种方式或者技术上可能更有利于框架的发展</div>
<p><br/><br/>喜欢和你这样认真细致的人讨论问题。 </p>
<p> </p>
<p>不能在短时间内理解7wxAop不是你的问题，一方面大家对“Server business”模式还比较陌生，另外7wxAop的文档也欠缺，希望通过讨论我能把它说清楚。 </p>
<p> </p>
<p>7wxAop是一个精简的框架，客户端7wx封装的js代码大约是<span style='color: #ff0000;'>3000</span>行，服务器端Aop封装的Java代码大约是<span style='color: #ff0000;'>8000</span>多行，写最简洁的代码是我的编程原则，因此代码量可以看出工作份量：<span style='color: #ff0000;'>首先它是一个Web开发的总体框架</span>，其次大头在“<span style='color: #ff0000;'>Server business</span>”(Aop)，“<span style='color: #ff0000;'>JS based UI</span>”(7wx)部分相对简单，当然从重要性来说两者相当。相比Ajax无刷新机制、Ext/dorado的丰富UI组件，7wxAop的侧重点是“<span style='color: #ff0000;'><strong>Server business</strong></span>”编程支持，7wx倒是可以被其他组件替换。 </p>
<p> </p>
<p>我确实不喜欢“Server Pages”用于业务应用,从servlet println() 到JSP、Tag、velocity、jsf。。。因为对强交互的业务应用来说，这种结构不合理。<span style='color: #ff0000;'>但对于CMS/BBS/BLOG/WIKI/社区/圈子...等等以信息服务为主的应用（不含这些东西的后台管理系统）来说，“Server Pages”是必然之选</span>，“Server business”反而不适合，这一点我看得很清楚，基于7wxAop开发的Kontent CMS,其实信息服务部分就是“Server Pages”技术。 </p>
<p> </p>
<p>关于你提的几点探讨，还是一条一条来： </p>
<p> </p>
<p>1、我个人<span style='color: #ff0000;'>喜欢用数组</span>，我想老一点的程序员（用过Apple BASIC，或更老的）都喜欢用数组。 能用数组简单完整的任务，为什么非要用Iterator或各种Collection结构？越简单的数据结构，系统开销越小，运行越快，越不容易有内存泄漏等难以排查的Bug。尤其是对于一个HTML页，其应用代码再复杂，能复杂到哪儿去，非得要用高端对象代码来提高程序可读性？  另外我说过使用7wxAop需要一定的 js 基础（如主题所说，我认为<span style='color: #ff0000;'>不会JS的Web开发者是半拉子开发者</span>），js的培训不算框架的培训，7wx远没有Ext复杂，所暴露的接口并不多，即便通读其3000多行代码，也用不了1天时间。所以7wxAop的学习开销你完全不用担心。</p>
<p> </p>
<p>2、你的意思我明白：主流的分层模型教导我们，不要将Web层的东西传递到业务层，WebActions既然用了<span style='color: #ff0000;'>HttpServletRequest</span>，WebActions就不是业务层了。我的观点是，如果你有独立的业务层（比如EJB），就把WebActions当成Web层好了；否则，<span style='color: #ff0000;'>7wxAop建议在WebActions中实现所有的Model功能</span>，那么HttpServletRequest是否玷污了Model？如果存在Web层，则是；但<strong><span style='color: #ff0000;'>7wxAop中不存在Web层</span></strong>，7wxAop的“Server Business”模式本身并不依赖于Web层的Servlet API，甚至也不需要HTTP协议 的 full implementation ，这里使用HttpServletRequest而不是诸如<span style='color: #ff0000;'>ActionReques</span><span style='color: #ff0000;'>t</span>的对象作为WebAction的参数，只是为了实现方便，也许在下一个版本的7wxAop，你就会看到一个ActionRequest（现有框架代码中的org.xjawa.system.DeepRequest类就是用于这个目的，只不过没实现，该类目前在框架中悬空没用）。所以，你说的“离所谓的纯粹的B和S还有点距离”是对的；另一方面，如果克服一下主流的分层模型教导我们的“洁癖”，以及根深根深蒂固的Web层观念，Model层使用一下HttpServletRequest也不是什么原则性的问题。</p>
<p> </p>
<p>3、你的说法“政治上正确”。7wx的组件其实不是很多，和Ext等强调OO的UI组件不同，<span style='color: #ff0000;'>7wx组件采用HTML模版来作为组件显示元素</span>，扩张相对容易。</p>
<p> </p>
<p>4、不是。7wx在框架内部使用最简单的window.open跳转页面(不鼓励也不反对用户代码直接使用window.open)。</p>
<p> </p>
<p>5、<span style='color: #ff0000;'>7wx很快</span>，界面响应比Ext快的多。下载的系统已经有很多应用功能，你自己可以体会。分页是“延迟加载”，性能自己体会，7wx翻页允许最终用户自己改变每页行数，在确实需要浏览很多条目的情况下，比“预先加载”方式更有效。</p>
<p> </p>
<p>6、使用7wxAop，业务复杂度的增长和系统复杂度的增长是线性的：在前端,增加业务只是HTML页面；在后端增加业务只是增加WebActions，不会有哪个XML文件或Java文件越滚越大。“页面动态性。。。”那段没看明白，能否具体点？</p>
<p> </p>
</div>
<p>虽然我目前对服务端组件框架更感兴趣，但也和乐于参与基于JS + HTML的客户端组件框架的讨论。因为采用何种框架完全取决于当前公司的技术导向，开发人员技能差异性，技术系好，成本和其他很多因素组成</p>
<p>也一条一条来讨论:</p>
<p>1.  对于一个成熟的JS框架，屏蔽低层的JS接口是很有必要的。JS的固有特性导致大部分开发人员很难开发出强壮的JS代码，包括是否有重复代码，是否跨浏览器，是否足够的灵活，能否做到js代码复用。客户端组件升级后，能否兼容先前的JS代码等等。所以，提供封装的APIs在我看来是一定要的 ，而且越抽象越好</p>
<p> </p>
<p>2. 废弃传统意义上的Action层应该是以后的发展方向。因为Action无非是完成一些数据输入输出，动态导航之类的功能。所以假如你的框架还要发展，我觉得很必要考  虑一下把这层去掉</p>
<p> </p>
<p>3. 客户端框架的的最重要特性就是必须要提供丰富的UI组件，组件内部可以相对复杂（不管采用JS template技术还是其他诸如HTML Template技术），但对外暴露的接口必须简洁</p>
<p> </p>
<p>4. 用window.open MS感觉有点粗，即使你开放一个封装过的JS接口用来导航，也可能遇到一些动态导航的功能无法实现。假如你将Action层废弃，那么页面流这个概念需要加强</p>
<p> </p>
<p>5. 暂时不讨论了</p>
<p> </p>
<p>6. 不使用外部配置未免也有点太极端了，你的代码里包含了很多hard-coding的包名，方法名。预示着你的业务方法不支持重构，替换（不修改源代码）</p>
<p> </p>
<p>另外，我很久以前建了一个相关的圈子和M群，有讨论意愿的朋友可以站内短信我</p>

48 楼 hax 2008-04-27  

leebai 写道

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

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

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

47 楼 hax 2008-04-27  

初步看了achun的jct，不是很看好。看上去jct比较接近传统模板，只是放到了前端。希望能看到jct更多的文档。

46 楼 icewubin 2008-04-27  

achun 写道

to leebai:
至于你举的例子，实际的需求比这个复杂的多。
举个新闻录入的例子,新闻有这个特点：
有些新闻很长，需要分页，在数据库里就是多条记录（可以放到不同的表里），比如有些软件使用的操作或者对一个复杂事情的跟进文章。
那我问你，录入这些有主记录和从记录的信息的时候，页面上是什么样一个布局，页面需要不停的刷新吗？

如果要不停刷新，那我问你，如果你不是信息的录入人员而是网站信息的审核人员这样不停的刷新页面，你烦不烦，
每次刷完了之后为了能更好的操作也许，还要附上几十条最新的待审核信息的条目，以备继续的审核操作。
所以我觉得这个需求是有的。
就算为了搜索引擎，为了点击量客户浏览的时候你可以不停刷新，但是你内部自己用呢？
自己就不是客户了么？

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

45 楼 achun 2008-04-27  

to leebai:
至于你举的例子，实际的需求比这个复杂的多。
举个新闻录入的例子,新闻有这个特点：
有些新闻很长，需要分页，在数据库里就是多条记录（可以放到不同的表里），比如有些软件使用的操作或者对一个复杂事情的跟进文章。
那我问你，录入这些有主记录和从记录的信息的时候，页面上是什么样一个布局，页面需要不停的刷新吗？

如果要不停刷新，那我问你，如果你不是信息的录入人员而是网站信息的审核人员这样不停的刷新页面，你烦不烦，
每次刷完了之后为了能更好的操作也许，还要附上几十条最新的待审核信息的条目，以备继续的审核操作。
所以我觉得这个需求是有的。
就算为了搜索引擎，为了点击量客户浏览的时候你可以不停刷新，但是你内部自己用呢？
自己就不是客户了么？

44 楼 icewubin 2008-04-27  

leebai 写道

icewubin 写道

。。。

除了上述的大方向外，目前浏览器存在主要问题还有“JS虚拟机”的问题，解释执行实在没有必要，太低效了。

呵呵，我倒没感觉js性能有问题（也许是因为喜欢用数组的原因吧:-)），现在的机器都和。。贼。。一样快，一个HTML再复杂，代码也多不到哪儿去，要做的工作也多不到哪儿去，怎么会有性能问题呢，除非使用不当。

主要是指图像显示上的各种效果，图形显示的像素级控制如EXT，具体效果比如拖动一个框并实时显示，性能的需求是无止尽的，当然前提是需求中需要这些效果。

43 楼 achun 2008-04-27  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>
<p>to achun: <br/><br/>虽然没完全明白你的描述，但直觉上认为你的<span style='color: #ff0000;'>设计有点过度</span>，至少对ajax“页面局部动态更新”这个确定的需求来说是过度设计： <br/><br/>“页面局部动态更新”所需要的数据用不着想的结构太复杂，既，不需要万能的<span style='color: #ff0000;'>DOM树模型来表达数据</span>。从我实践经验看，ajax所要获取的数据无非：<span style='color: #ff0000;'>一个简单变量</span>；<span style='color: #ff0000;'>一个由N个域构成的记录</span>；<span style='color: #ff0000;'>一个由N个记录构成的记录集</span>；<span style='color: #ff0000;'>两个记录集，其中一个的每一条，对应另一个中的M条</span>(既数据库中的父子表，例子见我上面贴子《各种ListView显示效果图》中的“BBS半版面导航”);<span style='color: #ff0000;'>上面四种数据的扁平组合</span>。 <br/><br/>一把一字改锥＋一把十字改锥，已经能对付世界上99％的螺丝；也许万能改锥更好，但太昂贵了，可靠性也值得怀疑。</p>
<p> </p>
</div>
<p><br/>你说的过度的问题，只是我描述的过度了，或者说我的想法过度了，</p>
<p>可实际使用的时候是否过度使用，这个是可以控制的呀，js模板也可以不过度的使用呀！</p>
<p>对于万能改锥太昂贵，可靠性来说，这个我不好说，毕竟我一直在研究这个，可能我觉得成本低，不昂贵，别人就不一定认同了。</p>
<p>不过我的方案，现在正在用，前台做html了同事只需要安心做html,css其他的什么都不用管，她觉得很安逸。</p>
<p>数据怎么来的，页面怎么装上去的，她几乎不用管</p>
<p>（其实页面上的变量和模板里的流程控制就是她写的，她对JS也是入门级的，很简单，都是标准的js语法，无外呼if,for），</p>
<p>等项目做完了，有时间我会仔细根她说说的，</p>
<p>当然了目前这个方案还有些应用上的问题解决的不是很好，解决的方法还不优美，不过我相信随着深入的研究，最终会安逸和优美的。</p>

42 楼 leebai 2008-04-27  

icewubin 写道

。。。

除了上述的大方向外，目前浏览器存在主要问题还有“JS虚拟机”的问题，解释执行实在没有必要，太低效了。

呵呵，我倒没感觉js性能有问题（也许是因为喜欢用数组的原因吧:-)），现在的机器都和。。贼。。一样快，一个HTML再复杂，代码也多不到哪儿去，要做的工作也多不到哪儿去，怎么会有性能问题呢，除非使用不当。

41 楼 leebai 2008-04-27  

<p>to achun: <br/><br/>虽然没完全明白你的描述，但直觉上认为你的<span style='color: #ff0000;'>设计有点过度</span>，至少对ajax“页面局部动态更新”这个确定的需求来说是过度设计： <br/><br/>“页面局部动态更新”所需要的数据用不着想的结构太复杂，既，不需要万能的<span style='color: #ff0000;'>DOM树模型来表达数据</span>。从我实践经验看，ajax所要获取的数据无非：<span style='color: #ff0000;'>一个简单变量</span>；<span style='color: #ff0000;'>一个由N个域构成的记录</span>；<span style='color: #ff0000;'>一个由N个记录构成的记录集</span>；<span style='color: #ff0000;'>两个记录集，其中一个的每一条，对应另一个中的M条</span>(既数据库中的父子表，例子见我上面贴子《各种ListView显示效果图》中的“BBS半版面导航”);<span style='color: #ff0000;'>上面四种数据的扁平组合</span>。 <br/><br/>一把一字改锥＋一把十字改锥，已经能对付世界上99％的螺丝；也许万能改锥更好，但太昂贵了，可靠性也值得怀疑。</p>
<p> </p>

40 楼 icewubin 2008-04-27  

leebai 写道

hax 写道

你的设计比我想象的更接近我理想中的方式，呵呵。而且我觉得你的设计其实离HTML组件方式很接近啊。

过奖，一切都还在探索中。

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

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

这个是关键中的关键，很有可能最后文字方面大家都差不多，但是多媒体和图形有可能就是能主导未来方向的，好比DOS到windows的过程，文字mud到图形网游，2D游戏到3D游戏的大变革。就看这个拐点何时到来，到时候又会先开始口水仗。

除了上述的大方向外，目前浏览器存在主要问题还有“JS虚拟机”的问题，解释执行实在没有必要，太低效了。

39 楼 leebai 2008-04-27  

<div class='quote_title'>hax 写道</div>
<div class='quote_div'><br/><br/>你的设计比我想象的更接近我理想中的方式，呵呵。而且我觉得你的设计其实离HTML组件方式很接近啊。 <br/></div>
<p><br/><br/>过奖，一切都还在探索中。 <br/><br/>如果新的 <span style='color: #ff0000;'>HTML Specification</span> 能包含<span style='color: #ff0000;'>treeview、listview、grid</span>。。。等<span style='color: #ff0000;'>大粒度组件</span>，web UI模式之争其实没有任何悬念，甚至RIA都不是对手（<span style='color: #ff0000;'>flex/javafx等要达到HTML/CSS同等的表达能力几乎是不可完成的任务</span>，如果达到了，就是另外一个浏览器引擎了），虽然多媒体及图形方面RIA将会保持自己的价值。 <br/><br/>在HTML升级之前，我认为最好的办法是以<span style='color: #ff0000;'>现有的，形式最接近的HTML元素</span>为<span style='color: #ff0000;'><strong>骨架</strong></span>，组合其他合适的HTML元素,通过扩充<span style='color: #ff0000;'><strong>骨架HTML元素</strong></span>的<span style='color: #ff0000;'>属性、方法、事件</span>，来构造大粒度的UI组件。目前的7wx组件已经很老了，新版本将会融合近来的一些想法，应该会有比较大的更新。</p>
<p> </p>

38 楼 icewubin 2008-04-27  

hax 写道

icewubin 写道

leebai 写道

在正真的B-UI应用中，Browser自己负责界面构造和界面跳转，Server只负责提供business logic 访问，也就是说[size=small; color: #ff0000;]Server上根本就不需要S-UI的Web层（虽然还是HTTP访问），没有所谓的Controler，也就是说MVC不再是真理，Spring MVC/Struts之类的Web层框架完全没有必要[/size]。&ldquo;server pages&rdquo;开发者理解B-UI时最大的思路陷阱就是&ldquo;Web层&rdquo;，MVC。 B-UI（Ext等界面组件+HTML+JS+ajax）是S-UI(jsp,jsf,asp,asp.net)的完全等价物，不存在什么功能jsf能做， B-UI不能做的问题。

从结构上来说，即使没有Controller层，business logic层不能直接暴露给客户端调用（由此我反对使用DWR框架），也就是说，还是要有一层Fasade，所以还是留着好，虽然名字还叫Controller但是主要职责已经变了。为什么说主要职责，是因为Controller层还是有它的用的，传统的方式比如自定义tag用来“写”（生成）JS的local数据要比发Ajax请求效率要高得多，应用场景是界面上的下拉框不需要频繁从服务端取数据，大多数情况都是取一次的，就没必要用Ajax请求。

或者这么说吧，如果页面上有10个下拉框，而且内容都不能写死，都要从服务端取，纯粹的Ajax方案在这种场景下性能反而是倒退的，因为http请求发得太多了。目前觉得还是结合传统的方式更好一点，可以一个ftl（或jsp）+一个JS文件，ftl（或jsp）中的代码可以很少，比如都是些取数据的tag。进可以完全的不用tag语法，退可以随时大量用传统语法解决变态需求。

并不能说DWR框架就一定导致business logic暴露给客户端。使用Facade和DWR并不矛盾啊。而且我认为Controller如果仅仅是为了解决网络存取效率问题，那并不能算是Facade，只能算一个Proxy。而且如果考虑HTTP支持keep-alive和pipeline的话，可能就不必考虑多个请求的问题了，那样的话又如何？——注意我并非说B端可以直接操控biz logic，但至少你这里的理由不充分。

不好意思，没有说全，这个问题我犹豫了很久，因为我不了解DWR，去年9月决定要不要上DWR的时候非常痛苦。当时北京分公司的JS第一高手推荐DWR，但是看到fins在有一个贴子说了原生Ajax设计的不应该出现DWR的框架。我看了很多DWR的用法和评论，也没有说将来一定不用。直接暴露算是一个很不好的DWR的应用，你说得对，谈不上是矛盾。

主要因为以下3点：
1.DWR还是属于服务端生成代码式的框架结构，感觉不够灵活。
2.使用配置文件的方式，我很讨厌配置文件，我认为配置就是代码，但是IDE对配置文件的支持远不如对代码的。
3.因为我们使用Hibernate，为了performance tune，我必须要精确控制对象图的导航模式，一定要非常非常灵活，最后的方式，是我自己写了个工具类来进行对象导航，生成JSON数组。DWR在这点上可能满足不了我的要求，也有可能是我不了解DWR。

keep-alive和pipeline要经过封装才能降低使用成本，目前用tag的方式一次性取数据也是偷懒的方法，架构上不优雅，但是蛮简单的，呵呵，过渡性的，我就等着有好的而且成熟的解决方案出现呢。

37 楼 achun 2008-04-27  

leebai 写道

achun 写道

哦明白了，我们说的是不同的东西。

了解讨论对方的工作背景真的很重要，很多低效的讨论是因为参与者不愿深入了解他人的工作。
其实你这jCT中的“存储”型模板，完全可以被7WX框架借用（7WX中也有类似的东西，只是功能没jCT强）。
Browser UI模型的“局部界面更新”，除了主流的“组件方式”外，确实还应该包含“模版方式”。

难得能得到一句称赞的话，有了你这句话，我才敢继续围绕我的模版方式说下去。
可以看出楼主也有要加大模版方式强壮度的想法(不是猜错了吧!)
我现在已经有了初步的使用方案，因为是初步形成，而且文字表达起来我还没有组织好。
方便的话我们可以语音聊聊，效率高省时间。
现在初步说说我的方案：
1.技巧
这个方案完全是编程的技巧，
2.就模板来说，模板就是模板不应该显示的在功能上负责DOM树的问题
3.完整的说这个方案涉及了前后台所有的变量命名规则。
4.核心：这个说来不配合项目大家是不会明白我说什么的，还是要说说。
我定义了一个表达式，这个表达式完成了绝大多数的需求。
[selectors::][jct Function][..foo function name]
临时起个名字叫3P表达式（3段表达式，千万别想别的）
解释：
selectors====DOM选择表达式，就是jQuery，prototype或者w3c标准定义的选择子
::=========定界符号，选择这个是因为不会和selectors产生冲突
jct Function====jCT解析后的对象，当然也可能式存储对象
..=========定界符号，选择这个是因为不会和selectors或jct Function产生冲突
foo function name=======用什么方法完成装配。这个根据前面的两个值的不同有多种变化。

可以看出这个表达式涉及了DOM树,表现和数据的组装,表现的具体方式（foo function name）。
5.jCT在这里的作用：
除了表现和数据的组装（解析）这个模板固有的功能外，就是jCT里面的

引用

FixDat:发生在数据Load前
当然是对数据的前期处理,例如排序,或者更改属性名称等,说白了,就是为达到这样的效果做的前期准备:写一个(类)模板,能适应不同数据的变化做的数据预处理接口.

ViewBefore:发生在数据Load后,装配到页面(视图)前
这里面有个要商榷的问题,传入什么参数呢?这直接影响到ViewBefore的作用.
我认为应传入 *视图* 对象或与 *视图* 对象相关的DOM对象.
做什么呢?当然是做表现层(视图)的前期处理.

ViewAfter:发生在装配到页面后
明白了ViewBefore的作用,这个就顺推了.
传入 *视图* 对象或与 *视图* 对象相关的DOM对象.
做什么呢?当然是做表现层(视图)的后期处理.有些DOM对象的具体值只有装配上以后才能确定下来,
比如样式对DOM结构的影响,装配上以后再分析处理要当然要轻松很多.

这三个模板设施了。
可以看出这三个设施就是配合最终表现的法宝。

现在看看我上面说的东西，她贯穿了前台页面表现中的逻辑要点。

自己都不知道我说明白没有。

36 楼 hax 2008-04-27  

leebai 写道

模版部分你基本猜对了，就时在HTML里面挖窟窿，填占位符{},没有通常模版的枚举和循环以及程序性代码。

代码部分目前的版本没你想的OO(汗)，像这样：

XfillTableWithArray(tableTemplateID,arrayData);

页面布局也不是用 container.addComponent()方式，而是直接用HTML,美工画好之后，哪个HTML元素需要成为&ldquo;组件宿主&rdquo;,就给它加一个&ldquo;id=controlName&rdquo;,然后在代码中引用controlName，这个HTML元素也就成为&ldquo;7wx组件&rdquo;。

感觉HTML比js代码更擅长布局、样式、显示定制，故不用js&ldquo;构造&rdquo;界面，只用js&ldquo;操纵&rdquo;界面。这里的思路与Ext等组件模型完全不同。

你的设计比我想象的更接近我理想中的方式，呵呵。而且我觉得你的设计其实离HTML组件方式很接近啊。

35 楼 leebai 2008-04-27  

<div class='quote_title'>hax 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'><br/>组件是王道没错，但模板在很多时候能解决组件无法解决的问题，尤其是界面显示的可定制性。举个例子： <br/><br/>7wx的ListView组件主要用于显示各种各样带翻页或不带翻页的内容条目列表，比如： <br/><br/>所有这些都是ListView组件Render出来的，界面中每个条目能显示成什么样子，是通过HTML模版定义的， 你想象，单纯的OO Grid组件模式要显示这些形式各异的列表有多困难，这也是7wx ListView与其他js Grid完全不同的地方。 <br/></div>
<br/><br/>我没看过代码，我胡乱猜测一下，大概是这样？ <br/><br/>var myList = new ListView(data, template); <br/><br/>container.addComponent(myList); <br/><br/>然后data是一个json数组，每行一个对象，对象中包含对象数据，比如每个都有filed1和field2。这就好象数据表一样。 <br/><br/>template是某种格式的模板？比如xslt？或者自定义的html模板语言，比方说： <br/>&lt;li class="xxxList"&gt; <br/>&lt;div&gt;${field1}&lt;/div&gt; <br/>&lt;div&gt;${field2}&lt;/div&gt; <br/>... <br/>&lt;/li&gt; <br/><br/>不知道是不是我猜测的那样？ <br/></div>
<p><br/><br/><br/>模版部分你基本猜对了，就时在HTML里面挖窟窿，<span style='color: #ff0000;'>填占位符{},没有通常模版的枚举和循环以及程序性代码</span>。 <br/><br/>代码部分目前的版本没你想的OO(汗)，像这样： <br/><br/><span style='color: #ff0000;'>XfillTableWithArray</span>(tableTemplateID,arrayData); <br/><br/>页面布局也不是用 container.addComponent()方式，而是直接用HTML,美工画好之后，哪个HTML元素需要成为“<span style='color: #ff0000;'>组件宿主</span>”,就给它加一个“id=controlName”,然后在代码中引用controlName，这个HTML元素也就成为“7wx组件”。 <br/><br/>感觉<span style='color: #ff0000;'>HTML比js代码更擅长布局、样式、显示定制，故不用js“构造”界面，只用js“操纵”界面</span>。这里的思路与<span style='color: #ff0000;'>Ext</span>等组件模型完全不同。 <br/><br/><br/><br/></p>
<p> </p>