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

下载了一个看了看，整个架构倒是完整，内容也够丰富。
楼主的代码好像没有把数据和表现彻底分离呀！
首先就是jsp文件的代码里面含有大量的html代码呀！
再有就是html文件代码里基本上都是独立的html+javascript function,
可是你这个还是B/S的系统呀！
没有把B/S分离呀！
就算只评价html文件，可以算做独立的B系统，可是都是独立的文件呀！这不能为整体设计带来更多的便利呀！

看的很认真啊，谢谢检查。

1、系统里jsp文件是很少的，大部分是CMS应用的模版以及BBS页面，对于向公众提供信息浏览的页面，为了对搜索引擎友好以及其他一些原因，并不适合用ajax和数据表现分离模式，这点有机会再展开论述。其他正常“后台”业务系统的页面中，100多个都是静态HTML，只有几个jsp，都是为了代码简洁，其实也完全可以用HTML实现。

2、后面html+javascript function的疑问，我没看明白。你觉得“独立的B系统”应该是怎么样子？欢迎探讨

 

to achun:

刚才看了一下你的jCT，大致知道你说的意思了，，，真是背景不同思想对不上啊:-)

我理解jCT的方式相当于客户端的jsp，一个HTML模版 ＋ 一个ajax数据 ＝＝解析＝＝》一个可显示页；

我这个框架不是你这种思路。 7WX中，一个HTML页是就一个小应用，封装的JS方法可以与服务器通讯并获取后端数据，再操纵HTML页改变其局部显示。“局部”有时是占位符号，如显示一棵树组件时；有时是一段（不是整页）HTML模版，如显示列表时。“后台数据”在这其中是完全独立的，是Server和Browser之间的唯一耦合物。

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

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

 

楼主果然很不谦虚啊，哈哈，你的方案我有空看看
个人觉得JSF用起来很费劲，在s做b端的事，如果想在s端封装b端的展现，就直接在b端用js算了，何必再增加网络流量。现在我做B-UI全部都是html和js，没有tag和<%%>用ext后就不需要struts来进行页面跳转了

spring以前从来没用过,struts用的一直是1.1的老版本。我所看到的一些开发团队，
虽然用到了spring/struts等框架，但开发过程中MVC这块还是一片混乱，很少看到代码框架清晰的案例。我个人比较排诉spring和最新的struts，估计新人的学习成本够呛

保留MVC的空架子有时候是减少风险，万一碰到特别恶心的需求还有退路。

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

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

一次请求获得多种数据, 分别把数据绑定在不同的 "数据消费者" 上.

你说的我也想过，但是没有深入，也没有看到过什么介绍，感觉自己冒然深入开发这个模块成本不低，主要是现有方式时间成本和时间成本非常低，所以暂时利用tag了。

顺便询问一句，又没有好的实践方法，能很方便（低开发时间成本）的把数据绑定在不同的“数据消费者”上呢？

我有一朋友做的AJAX项目里有用到类似的东西,

称为"数据岛"模式,

还有，LZ的项目也类似,

很多种业务被一次请求, 同时服务多个业务组件.

但数据同时也可以很灵活的通过AJAX动态的响应客户的行为,

"数据岛" 用Observe向外抛出的事件注册接口,

各各组件只要把自己关心的部分并注册监听, ＵＩ组件不用关心数据何时与为何更新的数据，实现动态的响应客户的请求的一种小方法。

不过对于长年使用JSP,Struts,JSF的团队 要转变方法与强大的思维惯性做斗争是更为麻烦的事情。