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

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

组件是王道没错，但模板在很多时候能解决组件无法解决的问题，尤其是界面显示的可定制性。举个例子：

7wx的ListView组件主要用于显示各种各样带翻页或不带翻页的内容条目列表，比如：

 

 

所有这些都是ListView组件Render出来的，界面中每个条目能显示成什么样子，是通过HTML模版定义的， 你想象，单纯的OO Grid组件模式要显示这些形式各异的列表有多困难，这也是7wx ListView与其他js Grid完全不同的地方。

 

我感觉，大家得先定义一下这个Facade也好，Controller也好，它的具体职责是什么，和前后两端是如何配合的。否则很难说大家指的是一个相同的东西。

我没看过代码，我胡乱猜测一下，大概是这样？

var myList = new ListView(data, template);

container.addComponent(myList);

然后data是一个json数组，每行一个对象，对象中包含对象数据，比如每个都有filed1和field2。这就好象数据表一样。

template是某种格式的模板？比如xslt？或者自定义的html模板语言，比方说：
<li class="xxxList">
  <div>${field1}</div>
  <div>${field2}</div>
  ...
</li>

不知道是不是我猜测的那样？

暂且称它为 X层 吧（这个字母还真有桥梁、联接、中介的意思:-)）。

在7wxAop的Aop中，X层 做了以下工作（比较乱，先随便列出来）：

1、临时停止和恢复business访问，某些后台维护时要用。
2、对model层掩盖multipart/form-data访问（既俗称的文件上传）和普通访问的区别
3、抽取Request各种信息，记入系统设置的一个数据结构，用于系统调试和排错。
4、在线用户列表维护
5、SSO机制支持
6、错误处理
7、访问日志处理
8、business方法的访问权限控制
9、指定并动态切换Model的数据源，DB连接及释放，事务管理
10、将Model层得到的业务数据封装成前端需要的格式，并返回
11、攻击检测及访问拒绝（实现了一小部分）
12、后台桩线程，用于每日，每周，每月，每年要做的定时处理

计划要在 X 中做的还有：
1、返回数据缓存策略
2、可配置、前端可指定的返回数据格式


有兴趣的同学，可以想想 X层 还要包括哪些功能。

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

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

XfillTableWithArray(tableTemplateID,arrayData);

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

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

 

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

难得能得到一句称赞的话，有了你这句话，我才敢继续围绕我的模版方式说下去。
可以看出楼主也有要加大模版方式强壮度的想法(不是猜错了吧!)
我现在已经有了初步的使用方案，因为是初步形成，而且文字表达起来我还没有组织好。
方便的话我们可以语音聊聊，效率高省时间。
现在初步说说我的方案：
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里面的

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

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

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

不好意思，没有说全，这个问题我犹豫了很久，因为我不了解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的方式一次性取数据也是偷懒的方法，架构上不优雅，但是蛮简单的，呵呵，过渡性的，我就等着有好的而且成熟的解决方案出现呢。

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

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

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