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

 

评论

94 楼 leebai 2008-05-23  

<div class='quote_title'>zqrain 写道</div>
<div class='quote_div'>谁说支持JSF是对Javascript有恐惧？！ <br/><br/>（1）谁告诉我你用JSF就可以完全不写Javascript？ <br/>（2）按你的逻辑是不是用ruby的人就是对Java的恐惧？！（可能这个比喻还不够恰当，因为至少Java EE和ruby有比较好的可比性）。 <br/>是不是用Spring的人就是对EJB的恐惧？！ <br/>使用JS框架的人是不是对手写JS的恐惧？！ <br/>是不是使用java这种高级语言就是对汇编的恐惧？！ <br/><br/><strong>只知其一，不知其二的时候，最好是先把自己不清楚的东西先搞透彻！</strong> <br/><br/><strong>另外，需要强调的是，支持JSF跟反对Javascript根本就风牛马不相及！</strong> <br/><br/>JSF的初衷是提供大粒度的组件，早期的实现版本根本就和JS框架没有任何竞争关系；目前rich client的JSF实现，同样是提供大粒度组件，甚至有些框架本身就提供了很强大的JS lib供browser端程序员使用，那些JS库的功能非常类似你们熟悉的EXT，DOJO等框架。 <br/><br/><br/><br/><br/></div>
<p> </p>
<p>我的原话是： <span style='color: #888888;'>很多人质疑以JavaScript为中心的UI开发，其实是对html/JavaScript的恐惧</span></p>
<p>对看帖不认真、逻辑不清楚的朋友，我建议：先认真看贴，再仔细整理并表达自己的思路，否则各说各话，讨论没有意义。</p>

93 楼 xzs 2008-05-21  

zqrain 写道

谁说支持JSF是对Javascript有恐惧？！

（1）谁告诉我你用JSF就可以完全不写Javascript？
（2）按你的逻辑是不是用ruby的人就是对Java的恐惧？！（可能这个比喻还不够恰当，因为至少Java EE和ruby有比较好的可比性）。
是不是用Spring的人就是对EJB的恐惧？！
使用JS框架的人是不是对手写JS的恐惧？！
是不是使用java这种高级语言就是对汇编的恐惧？！

只知其一，不知其二的时候，最好是先把自己不清楚的东西先搞透彻！

另外，需要强调的是，支持JSF跟反对Javascript根本就风牛马不相及！

JSF的初衷是提供大粒度的组件，早期的实现版本根本就和JS框架没有任何竞争关系；目前rich client的JSF实现，同样是提供大粒度组件，甚至有些框架本身就提供了很强大的JS lib供browser端程序员使用，那些JS库的功能非常类似你们熟悉的EXT，DOJO等框架。

fins和leebai就要出来了，等着看好戏

92 楼 maku 2008-05-21  

对 js + html 恐惧？
java不知比它们复杂多少倍，你们学没学？其实大家之所以学不好js，基本都是因为没把它当回事，js不简单，但也绝不像java一样复杂。

对 EXT等框架 恐惧？
没有它们之前大家就没写过客户端代码吗？

91 楼 zqrain 2008-05-21  

更可气的是，为什么很多人认为支持JSF的人就对JS和JS框架没有深入研究？！

笑话！如果对JS没有深入研究，人家怎么开发rich client的JSF组件？！

难道一个不熟悉Javascript的Java天才可以通过意念或者超能力，让他的程序可以在browser端发送Ajax请求？！

90 楼 zqrain 2008-05-21  

谁说支持JSF是对Javascript有恐惧？！

（1）谁告诉我你用JSF就可以完全不写Javascript？
（2）按你的逻辑是不是用ruby的人就是对Java的恐惧？！（可能这个比喻还不够恰当，因为至少Java EE和ruby有比较好的可比性）。
是不是用Spring的人就是对EJB的恐惧？！
使用JS框架的人是不是对手写JS的恐惧？！
是不是使用java这种高级语言就是对汇编的恐惧？！

只知其一，不知其二的时候，最好是先把自己不清楚的东西先搞透彻！

另外，需要强调的是，支持JSF跟反对Javascript根本就风牛马不相及！

JSF的初衷是提供大粒度的组件，早期的实现版本根本就和JS框架没有任何竞争关系；目前rich client的JSF实现，同样是提供大粒度组件，甚至有些框架本身就提供了很强大的JS lib供browser端程序员使用，那些JS库的功能非常类似你们熟悉的EXT，DOJO等框架。

89 楼 talangniao 2008-05-15  

7wx有
{"@getQuestion",
"",
"question:=SELECT pwprompt FROM " + dbSchema + ".USERS where id='{_id}'" },
说明的API吗  需要学习

88 楼 leebai 2008-05-06  

achun 写道

to leebai:
都说了是笑谈(意思是开玩笑的说,不是笑谈你)了.毕竟JAVA你现在还用的火热,
我关心的是:
你希望什么样的（实际点的,不是理想中的,目前的技术可实现的）开发环境呢？

汉语词汇真是意涵丰富啊。。。


我希望的开发环境（就ajax架构来说）：

服务器端，eclipse足够了，还有富余（我现在用3.1原装eclipse，连myeclipse我都觉多余，，，我以前用IBM VisualAge for Java（eclipse之源）也是足够好用）；

客户端，在页面制作工具的基础上，加大粒度组件，可视化设计，js能单步调试。够了。

87 楼 netfishx 2008-05-06  

j2ee开发效率不怎么样
现在说这话貌似不应该被拍了吧

86 楼 achun 2008-05-06  

to leebai:
都说了是笑谈(意思是开玩笑的说,不是笑谈你)了.毕竟JAVA你现在还用的火热,
我关心的是:
你希望什么样的（实际点的,不是理想中的,目前的技术可实现的）开发环境呢？

85 楼 leebai 2008-05-05  

<div class='quote_title'>achun 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>to xzs: <br/><br/>org.xjawa下的user、fileview、dbview也是具体应用，可供参考。 <br/><br/>to yyliuliang: <br/><br/>有道理，Java开发效率上确实有负众望。</div>
<br/>笑谈： <br/>Java开发效率上确实有负众望的话你都能说出来，晕。佩服你。 <br/>正题： <br/>那问一句，你希望什么样的（实际点的,不是理想中的,目前的技术可实现的）开发环境呢？</div>
<p><br/><br/>你联系一下yyliuliang的原帖，，，，我说 j2ee的开发效率不如ASP.NET，有问题吗？</p>
<p> </p>

84 楼 achun 2008-05-05  

leebai 写道

to xzs:

org.xjawa下的user、fileview、dbview也是具体应用，可供参考。

to yyliuliang:

有道理，Java开发效率上确实有负众望。

笑谈：
Java开发效率上确实有负众望的话你都能说出来，晕。佩服你。
正题：
那问一句，你希望什么样的（实际点的,不是理想中的,目前的技术可实现的）开发环境呢？

83 楼 leebai 2008-05-05  

to xzs:

org.xjawa下的user、fileview、dbview也是具体应用，可供参考。

to yyliuliang:

有道理，Java开发效率上确实有负众望。

82 楼 yyliuliang 2008-05-04  

各位可以好好参考参考ASP.NET AJAX服务器端和客户端框架两者分别的实现
跳出JAVA吧 

81 楼 xzs 2008-05-04  

<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>com.*的东西，都是具体应用，不属于框架
<p>论坛那个js错误，看提示是因为7wx.js导入有问题，你查查commonjs下是不是有文件被保存过（改过），7wx要求所有文件都是utf-8编码。</p>
</div>
<p><br/>很不幸我没有改动任何文件，直接解压出来运行的，曾经跑得很好。在这里不讨论这个问题了，有什么关于框架的bug问题我会帖到xjawa论坛，希望楼主留意，该框架的思想我已经明白，感谢你！！</p>
<p>对于具体应用，如果也能够开放源码的话，也许会让新手上手得更快！愚见！</p>

80 楼 leebai 2008-05-04  

<div class='quote_title'>xzs 写道</div>
<div class='quote_div'><strong/><br/>可是一旦系统做大了怎么办？向何处扩展？用ＯＯ重写？再集群分布？ <br/><br/></div>
<div class='quote_title'><br/></div>
<div class='quote_div'><br/><br/>可否讲解一下sys_core.js中的这些代码的作用，我初学js，不懂,谢谢！！ </div>
<div class='quote_div'><br/><br/>BTW:com.xjawa下的那些代码为何不开源？<span style='color: #ff0000;'>最新消息：旺财勇士同学开发的 Ext-js 到 7wxAop 的接口 ExtAop 已经完成，请点击查看演示程序 </span>就演示程序吗？能下载不？ <br/><br/><br/><br/><br/></div>
<p> </p>
<p> 目前框架是不支持集群（主要是内嵌的Jetty版本不支持），太大的系统用这个不合适。但和MVC架构的应用相比，7wxAop的集群改造要容易一些：Aop代码的session 中，只放了用户名、用户角色等几个字符串数据，不像很多MVC程序的session使用那么乱。</p>
<p>sys_core.js中的那些代码，主要用来抹平IE浏览器和FF浏览器的DHTML API差异（其实就是扩充FF的HTML操作能力），这样其他js 代码就不需要分别为IE、FF各写一套。</p>
<p>com.*的东西，都是具体应用，不属于框架。<span style='color: #ff0000;'>旺财勇士</span><span style='color: #000000;'>的的ExtAop，一直没放到网上，你可以自己向他要（旺财是我们的一个历史客户，不是员工），网站上有他的msn和邮件。</span></p>
<p>论坛那个js错误，看提示是因为7wx.js导入有问题，你查查commonjs下是不是有文件被保存过（改过），7wx要求所有文件都是utf-8编码。</p>

79 楼 xzs 2008-05-04  

leebai 写道

7wxAop的Model(WebActions)开发确实对OO对象的输出（转换成前端js数据）支持比较弱，好在大部分企业业务系统的后台数据都时RDBMS，7wxAop的SQLHTTP+AutoAction对关系表的处理和输出还是很简单，因此绝大部分Action的编程非常简洁。我将找时间另发个帖子谈谈SQLHTTP（AutoSQL）的设计思想。

很期待，说实话，我是被你和s79从jdon论坛钩过来的，看了你们在那里的帖子，PF,PF.我就不客气了，把那里的主导思想copy过来问一下，用你的7mx开发软件，非常适合小中型系统，而且数据面向关系，可是一旦系统做大了怎么办？向何处扩展？用ＯＯ重写？再集群分布？

leebai 写道

彻底分离是有问题，有时还很严重，比如，你就碰上了(&ldquo;进不了论坛&rdquo;)[img]../../../../../../images/smiles/icon_biggrin.gif" alt="[/img]。如果Web客户端有足够强大和稳定的组件（大厂商能做而不愿做），就不会出现你碰到的问题。

看你的页面低下有个脚本错误，双击打开，看看是什么原因。

似乎在leebai的文档中看到过，用这个框架出问题时大不了界面上某些小角落显示不出来，呵呵，可我现在呢？直接白屏了，哈哈！！

可否讲解一下sys_core.js中的这些代码的作用，我初学js，不懂,谢谢！！

if(window.HTMLElement) {
	HTMLElement.prototype.__defineGetter__(
		"outerHTML", 
		function(){
			var str = "<" + this.tagName.toUpperCase(); 
			for (var i=0; i<this.attributes.length;i++) {
				var attr = this.attributes[i];

				str += " ";
				str += attr.nodeName + "=" + '"' + attr.nodeValue + '"';
			}
			str += ">" + this.innerHTML + "</"+this.tagName.toUpperCase()+">";
			return str;
		}
	);


	HTMLElement.prototype.__defineSetter__(
		"outerHTML", 
		function(s){
			var range = this.ownerDocument.createRange();
			range.setStartBefore(this);
			var fragment = range.createContextualFragment(s);
			//alert(fragment);
			this.parentNode.replaceChild(fragment, this);
		}
	);



	HTMLElement.prototype.__defineGetter__(
		"parentElement", 
		function(){
			return this.parentNode;
		}
	);

	HTMLElement.prototype.__defineGetter__(
		"children", 
		function(){
			return this.childNodes;
		}
	);
	
	CSSStyleSheet.prototype.__defineGetter__(
		"rules", 
		function(){
			return this.cssRules;
		}
	);

	CSSStyleSheet.prototype.getRuleByName = function(name){
		var rules = this.cssRules;
		name = name.toLowerCase();
		for(var i=0; i<rules.length;i++){
			if(rules[i].selectorText == name)
				return rules[i];
		}
		return null;
	}

	HTMLSelectElement.prototype.add = function(opt){
		this.appendChild(opt);
	};

	KeyboardEvent.prototype.__defineGetter__(
		"srcElement", 
		function(){
			return this.target;
		}
	);

	KeyboardEvent.prototype.__defineSetter__(
		"returnValue", 
		function(b){
			if(!b){this.preventDefault();}
		}
	);

	//IE中args固定用self，即dialogArguments固定为opener ，以兼容
	//对IE，对话页中在<html>标签中用style指定宽高，window.resize不可用，默认resizale=no；
	//对firefox，上面三项刚好相反，firefox还会忆用户上次的resize
	Window.prototype.showModalDialog = function(url, args , features){
		if(features==null || features.length==0)
			features = "modal=yes";
		else{
			features = features.replace(/\:/g,"=");//IE use :
			features = features.replace(/\;/g,",");//IE use ;
			features = features.replace(/scroll/g,"scrollbars");
			features = features.replace(/dialogWidth/g,"width");
			features = features.replace(/dialogHeight/g,"height");
			features += ",modal=yes";
		}
		//if(features.indexOf("width")<0)features += ",width=0";//如不指定width，resizale=no不管用???

		//alert(features);
		url = encodeURI(url);
		window.open(url, "" , features );
		return "ok";
	};


	Window.prototype.__defineGetter__(
		"dialogArguments",
		function (){
			return this.opener;
		}
	)

BTW:com.xjawa下的那些代码为何不开源？最新消息：旺财勇士同学开发的 Ext-js 到 7wxAop 的接口 ExtAop 已经完成，请点击查看演示程序 就演示程序吗？能下载不？

78 楼 leebai 2008-05-04  

achun 写道

是不是惊天大阴谋,我其实不关心,
我不会因为他们是大厂家,就把他们的方案和思路当令箭.
我只遵守:
我是程序员
要的是自己的代码
要的是自己思路的体现
说句不好听的,前台框架真的建立起来了,后台开发平台会趋向什么语言呢?
肯定是两个方向:
1.简单易上手,易部署的动态语言
php,lua,javascript(别小看这个,照样能做后台服务器程序就是执行效率太低),perl(毕竟linux支持的很好)...java就不在此列了
2.可生产本地机器代码的程序
c/c++/d/Haskell(GHC)
还会产生另外一个影响,就是语言的多样性发展,一枝(或2,3枝)独秀的局面将彻底打破.
另外数数计算机语言历史上经典的流行,有多少是由大长家独立原发的?
c/pascal/lua/d(还没有流行)/Perl/Python(由研究机构发起)/basic.......
你就查吧,这些有灵魂的语言都不是大长家原发的,
大长家原发什么呢?
delphi 自创的VCL
.net   做平台了(完全是竞争逼的)
java   虚拟机(这个仅仅算卖点),还是做他的平台,最近才逼得有开源的趋向.
大厂家考虑的只有一个,就是卖的是产品,不是语言,羊的门.入我的门吧,受我包护,当然也受我约束.
可以预见的未来是,每个程序员都可以随时自定义一门语言,并且遵循某种协议在不同语言间交互协同工作.
但这个局面绝对不是靠大厂家来完成的.
看看IBM的发展道路,IBM是做什么的?
不是产品是服务,IBM才是有眼光和更高层次战略的公司.

没错，前后台分开之后的最大好处，就是：程序员不再被某种语言或技术或架构或服务器绑死，想换哪端（B or S）就换哪端。

77 楼 leebai 2008-05-04  

<div class='quote_title'>xzs 写道</div>
<div class='quote_div'>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'>Ajax框架的核心是浏览器和服务器之间的异步通讯，通常的Ajax程序使用非W3C标准的 XMLHttpRequest 作为通讯组件，7wxAop没有用XMLHttpRequest，而是采用简单的IFrame。从7wxAop的实践看，封装良好的IFrame通讯机制比XMLHttpRequest更好用，也更易用。</div>
<br/>有没有哪个高手告诉我，这段话是否有地方存在问题？何为封装良好的IFrame？ <br/><br/>
<div class='quote_title'>leebai 写道</div>
<div class='quote_div'><br/>
<div class='quote_title'>引用</div>
<div class='quote_div'>7，S和B端全部传送的是数据，B端调用的是S端的服务，是否可以把S端完全改造为OO的?业务流程变为B（ajax）--&gt;应用服务---&gt;领域服务---&gt;DAO等基础设施服务。</div>
<br/>完全可以。我提倡的就是 View(就是你说的B（ajax）)&lt;－－&gt; Model编程，7wx调用后台Model(WebActions)的方法,就是一种RPC，和dwr是类似的，但比dwr简单。 <br/></div>
<br/>把后端用OO替换，话说起简单，做做看？一个数据对象在jpa,spring里全部ＯＯ，可到表现层必须一个个肢解然后sendXX到脚本代码里面，别扭吗？特别是模型聚合模型时，难想象。还有业务层提供的ＯＯ数据是否还能够使用7xm的tree和list？不能使用的话就自己重写脚本画界面吧，form就不用说了，已经被多业务层阻挡。 <br/><br/>to leebai: <br/>请教一下你的数据页面，当一个表单target到某个内嵌框架IFRAME(buffer)的时候，你是如何做到通过buffer.name的方式获取后台数据的，在你的代码中我没有找到类似new buffer()；buffer.add(var name)之类的代码。每个数据页面中都会出现XcurBuffer=window，为何不直接写死在sys_core.js中？</div>
<p><br/><br/>7wxAop对IFrame的封装就很“良好”啊，因为你感觉不到IFrame的存在：要做的只是callServer()，然后在回调函数中，从buffer里取返回数据。s79理解的对。IFrame比XHR好的另外一点就是，带文件上传的请求和普通请求可以做到编程没有差别，一样的方式处理。</p>
<p> </p>
<p>buffer是在页面引用7wx.js时框架自动附加的iframe，所以你看不到“new buffer()；”之类的代码。除了buffer之外，还有一个备用的buffer0，用于buffer的请求还没返回时，发出另外的一个请求（特殊场合下有这需求）。XcurBuffer=window就时为了区分这两个不同的buffer。</p>
<p> </p>
<p>7wxAop的Model(WebActions)开发确实对OO对象的输出（转换成前端js数据）支持比较弱，好在大部分企业业务系统的后台数据都时RDBMS，7wxAop的SQLHTTP+AutoAction对关系表的处理和输出还是很简单，因此绝大部分Action的编程非常简洁。我将找时间另发个帖子谈谈SQLHTTP（AutoSQL）的设计思想。</p>
<p> </p>
<p> </p>

76 楼 leebai 2008-05-04  

<div class='quote_title'>xzs 写道</div>
<div class='quote_div'>
<div class='quote_title'>引用</div>
<div class='quote_div'>不就是HTML在Server端还是在Client端生成的区别而已吗。</div>
<br/>本质如此，可演化出了一种程序思想！ <br/>
<div class='quote_title'>引用</div>
<div class='quote_div'>B端和S端彻底分开，分别有自己的框架，“UI层与系统其他层面的东西的唯一联系应该是"数据" ，UI层应该是在后台系统不变的情况下可切换的”，这种架构策略完全可行，而且实际代码上也比JSF/asp.net等“server page”变种优雅</div>
<br/>彻底分离是否存在某些严重的问题？如果没有问题，那么这样的框架应该早百年就流行了。不过看到下面这段话把我吓一跳！！ <br/>leebai: <br/>
<div class='quote_title'>引用</div>
<div class='quote_div'>我认为，不管是哪种粗粒度界面组件实现，最好都由浏览器厂家联合来做，做出标准、通用、有持久生命力的界面组件。微软推出.net的时候，粗看简介我还以为是理想中的界面层技术，细看代码原来还是“服务器动态页面”，后来SUN的JSF也这么学，我们公司一个项目组现在在用的SAP的webDypro也是，因此我都有点怀疑:业界大佬们之所以不愿意在客户端组件上下功夫，之所以不想变革目前的Web应用架构，不是因为他们没看到技术需求，而是因为，他们的根本利益在于利润丰厚的各种服务器端产品；Web开发之所以搞得这么复杂，里面说不定有什么惊天大阴谋；或者说，这些业界大佬们睁一只眼闭一只眼地看着广大Web开发者累得死去活来，看着Web独立开发商和集成商一个个倒下去，却背过身去窃笑着点着大把的钞票----扯远了:)，这问题有空发个专贴，反正做了6年IBM独立开发商就给我这种感觉。</div>
<br/><span style='font-size: medium;'><span style='color: #0000ff;'>惊天大阴谋</span></span>，高手果然就是高手 <br/>下载的xjawa.zip第一天跑得很欢，可正当准备研究它的时候出问题了，主页可以打开，但进不了论坛： <br/></div>
<p>彻底分离是有问题，有时还很严重，比如，你就碰上了(“进不了论坛”)<img src='../../../../../../images/smiles/icon_biggrin.gif' alt=''/>。如果Web客户端有足够强大和稳定的组件（大厂商能做而不愿做），就不会出现你碰到的问题。</p>
<p>看你的页面低下有个脚本错误，双击打开，看看是什么原因。</p>
<p> </p>

75 楼 achun 2008-05-04  

是不是惊天大阴谋,我其实不关心,
我不会因为他们是大厂家,就把他们的方案和思路当令箭.
我只遵守:
我是程序员
要的是自己的代码
要的是自己思路的体现
说句不好听的,前台框架真的建立起来了,后台开发平台会趋向什么语言呢?
肯定是两个方向:
1.简单易上手,易部署的动态语言
php,lua,javascript(别小看这个,照样能做后台服务器程序就是执行效率太低),perl(毕竟linux支持的很好)...java就不在此列了
2.可生产本地机器代码的程序
c/c++/d/Haskell(GHC)
还会产生另外一个影响,就是语言的多样性发展,一枝(或2,3枝)独秀的局面将彻底打破.
另外数数计算机语言历史上经典的流行,有多少是由大长家独立原发的?
c/pascal/lua/d(还没有流行)/Perl/Python(由研究机构发起)/basic.......
你就查吧,这些有灵魂的语言都不是大长家原发的,
大长家原发什么呢?
delphi 自创的VCL
.net   做平台了(完全是竞争逼的)
java   虚拟机(这个仅仅算卖点),还是做他的平台,最近才逼得有开源的趋向.
大厂家考虑的只有一个,就是卖的是产品,不是语言,羊的门.入我的门吧,受我包护,当然也受我约束.
可以预见的未来是,每个程序员都可以随时自定义一门语言,并且遵循某种协议在不同语言间交互协同工作.
但这个局面绝对不是靠大厂家来完成的.
看看IBM的发展道路,IBM是做什么的?
不是产品是服务,IBM才是有眼光和更高层次战略的公司.