細(xì)說框架風(fēng)云 JSF能否拯救WEB江湖
來源:IT168 2008-08-26 作者:袁光東
Java企業(yè)開發(fā)可以說是“復(fù)雜”的代名詞,簡化Java的開發(fā)已經(jīng)刻不容緩了.隨著JAVA EE 5,JAVA EE6的相繼發(fā)布,從老虎到野馬,版本更新如此之快,對SUN來說是史無前例的。Sun終于頂不住來自內(nèi)部改革派和外部竟?fàn)幷叩膲毫Α?磥硎窍露Q心簡化JAVA了!
在2005年底.Net 2.0的發(fā)布,我們目睹了.Net 2.0的成功。.Net 2.0由于開發(fā)簡單,開發(fā)周期短,開發(fā)成本低,中小企業(yè)紛紛轉(zhuǎn)投向.Net的懷抱。眼看JAVA EE的市場慢慢的被.Net蠶食,Sun是急在眼里,痛在心里。
JSF也隨之成為JAVA EE的規(guī)范,Java EE 6明顯加強(qiáng)對JAVA開發(fā)桌面應(yīng)用的支持,Sun也想讓JAVA在桌面開發(fā)中占有一席之地。而把JSF作為強(qiáng)制規(guī)范,是想通過JSF來繼續(xù)統(tǒng)領(lǐng)WEB 開發(fā)來固守企業(yè)應(yīng)用的市場,2007年,Sun想通過JSF來打一個翻身仗。
WEB江湖
自Java 1995年面世后,Sun靠Applet 搶占了WEB前端市場,而Flash的出現(xiàn)卻讓Applet早早退出歷史舞臺。于是Sun在1997年發(fā)布了第一個WEB服務(wù)器(Java WEB Server)及應(yīng)用的Servlet API。Servlet可以通過純Java語言來編寫企業(yè)WEB應(yīng)用,Servlet從廠商急需角度出發(fā),迅速的成為了企業(yè)應(yīng)用解決方案的標(biāo)準(zhǔn)。
雖然Servlet通過Java這種高級語言來進(jìn)行編寫,而最終是展示給用戶的。需要有良好的用戶界面。這就需要支持HTML等WEB腳本。可是Servlet卻不能良好的嵌入HTML等前端代碼,開發(fā)起來非常復(fù)雜。
終于在1998年,Sun推出了JSP。而此時,與之相似的ASP已經(jīng)發(fā)布了兩年之久。
Sun在1999年初推出JSP 1.0后,又在1999年11月推出JSP 1.1,Sun終于憑借Servlet和JSP技術(shù),迅速的占領(lǐng)了絕大部份的企業(yè)市場份額。在2002年4月,JSP發(fā)展到1.2版本。到2003年Sun推出JSP 2.0,同時推出的JSTL(JAVA 標(biāo)準(zhǔn)標(biāo)記語言)取代JSP表達(dá)式的弱點(diǎn),更進(jìn)一步簡化JSP的編寫。 JSP慢慢變成一種非常成熟的WEB技術(shù),JSP憑借其技術(shù)成熟,穩(wěn)定,及Java的強(qiáng)大功能和跨平臺能力成為WEB企業(yè)應(yīng)用的王者,占領(lǐng)了80%以上的企業(yè)應(yīng)用市場。而ASP則靠快速開發(fā),方便發(fā)布以及依靠在微軟的大樹下分食中小市場和個人用戶。
江湖混戰(zhàn),框架興起
JSP是一項(xiàng)成功的技術(shù),它功能強(qiáng)大,具有高穩(wěn)定性和可靠性。但是也就意味著他具有復(fù)雜性,難以維護(hù)。從它誕生起,人們就一直在努力尋找一種快速的WEB開發(fā)方案。
在早期,所有的業(yè)務(wù)方法,數(shù)據(jù)庫連接,訪問方法的這些代碼都充斥在JSP頁面里。開發(fā)人員既是UI設(shè)計(jì)者又是程序員。同時各種各樣的業(yè)務(wù)代碼寫進(jìn)JSP頁面中,相同的功能代碼可能需要編寫多次,代碼無法重用,如果后期因?yàn)闃I(yè)務(wù)的變動而進(jìn)行維護(hù)時,對開發(fā)人員簡直就是一場惡夢。
隨后WEB開發(fā)進(jìn)入Model 2時代,也就是MVC模式的應(yīng)用時代,MVC模式可以使模型,視圖,控制分離出來。通過Servlet與JSP的結(jié)合,由控制器Servlet控制請求,調(diào)用業(yè)務(wù)類獲得模型數(shù)據(jù),并把數(shù)據(jù)模型展示到相應(yīng)的視圖(JSP)中。這樣,業(yè)務(wù)方法已經(jīng)從JSP中分離出來,減少了邏輯代碼與JSP代碼的藕合。JSP僅僅用于顯示數(shù)據(jù)和提交用戶的請求。Servlet控制用戶的請求及調(diào)用Java類的業(yè)務(wù)方法,并對用戶的請求進(jìn)行轉(zhuǎn)發(fā)。MVC模式可使得業(yè)務(wù)方法重用,使得頁面開發(fā)人員和程序員進(jìn)行分工。一部分人專注于頁面的開發(fā),而一部份人進(jìn)行業(yè)務(wù)代碼的編寫。可以使項(xiàng)目組的人去做他最熟悉的工作。
Model2的運(yùn)用,對WEB開發(fā)帶來了一次全新的變革,但是仍然面臨著許多問題。有太多的Servlet類,一個請求對應(yīng)著一個Servlet類。頁面流程的控制全部通過硬代碼寫死在Servlet類中,每一個Servlet類都需要在WEB.XML中進(jìn)行配置,不能很好的支持國際化等。后來人們通過前端控制器模式來解決了這樣問題,就是由一個Servlet來響應(yīng)所有的請求。根據(jù)不同的請求參數(shù)來調(diào)用不同的服務(wù)方法。這樣有效的減少了Servlet類。幾乎現(xiàn)在所有的WEB框架都是采用前端控制器和MVC模式的運(yùn)用。在這樣的背景下,WEB框架應(yīng)運(yùn)而生,Struts最先面世,WEBWork等紛紛涌現(xiàn)。開發(fā)者采用框架大大的簡化了WEB應(yīng)用的開發(fā),加快了開發(fā)的速度和質(zhì)量。
Struts攪亂WEB格局
Struts采用前端控制器模式和MVC模式進(jìn)行設(shè)計(jì)。強(qiáng)制開發(fā)人員以MVC的理念來進(jìn)行WEB開發(fā),把表現(xiàn)層與業(yè)務(wù)層進(jìn)行分離。Struts提供了豐富的標(biāo)簽庫,在JSP 1.1時代,JSP頁面都是通過JSP表達(dá)式進(jìn)行編寫。雖然采用“<%%>”的JSP表達(dá)式功能非常強(qiáng)大,但是調(diào)試十分的麻煩,理解也十分的困難,一般的頁面人員幾乎無法勝任。而Struts此時提供的標(biāo)簽庫類似于HTML的標(biāo)記,對開發(fā)人員更為友好,易于理解和編寫。
Struts提供了一個頁面流程控制的功能,而不是把頁面的轉(zhuǎn)向?qū)懰涝诖a中。每個請求的頁面輸入和頁面轉(zhuǎn)發(fā)都配置在Struts-config.xml中。
Struts支持自動數(shù)據(jù)綁定,通過一個ActionForm來實(shí)現(xiàn)。把頁面的數(shù)據(jù)自動綁定成POJO對象。并支持?jǐn)?shù)據(jù)檢驗(yàn)。Struts 提供了國際化的支持,可以很容易的讓你的WEB系統(tǒng)應(yīng)用于多種語言版本的要求。
所以Struts一推出就受到了開發(fā)人員的喜愛,并迅速流行起來。Struts是目前使用最多,流行時間最長的JAVA開源 WEB框架。
盡管Struts取得了成功,但是它仍然有很多的不足。Struts線程是安全的,但對并發(fā)控制是一個問題。在JSP 2.0推出JSTL后。JSTL取代JSP表達(dá)式進(jìn)行JSP編寫,JSTL是一種類似C語言風(fēng)格的標(biāo)記語言。更為人們所熟悉,語法十分簡單,明了,功能強(qiáng)大。JSTL會自動處理NULL問題,而不是像JSP表達(dá)式和Struts標(biāo)簽?zāi)菢佑龅絅ULL值是會拋出可恨的異常。相對于優(yōu)雅的JSTL,采用Struts標(biāo)簽寫出的JSP代碼就像是天書,咒語一樣。Struts大部份標(biāo)記重復(fù)了JSTL的相似功能,有一部份與HTML重復(fù)的標(biāo)簽根本就沒有必要存在,還無端的增加了學(xué)習(xí)和開發(fā)的難度。而且Struts標(biāo)簽不能良好的處理NULL問題。
ActionForm的問題,Struts通過ActionForm來進(jìn)行數(shù)據(jù)綁定和數(shù)據(jù)校驗(yàn)。首先任何需要使用數(shù)據(jù)綁定和數(shù)據(jù)校驗(yàn)功能都必須去繼承ActionForm,而Action Form又依賴Servlet。這樣基于類繼承的藕合是沒有必要的。數(shù)據(jù)綁定應(yīng)該是原始的,就是說頁面的數(shù)值型數(shù)據(jù)應(yīng)該綁定成Java類的數(shù)值型數(shù)據(jù),日期型數(shù)據(jù)就綁定成日期數(shù)據(jù)。而Struts只能把頁面數(shù)據(jù)綁定成字符型的數(shù)據(jù)。數(shù)據(jù)校驗(yàn)應(yīng)該是具有重用性的,而Struts卻要把數(shù)據(jù)檢驗(yàn)生硬的寫在ActionForm中。
同時Struts也存在以下幾點(diǎn)致命傷:
1、Struts通過繼承具體類來進(jìn)行擴(kuò)展,那么你要自定義Struts的行為而變得困難。
2、Struts是不容易測試的,必須通過StrutsTestCase來進(jìn)行輔助測試。而不是真正意義上的單元測試。
3、Struts太面向JSP了,也就是說Struts僅支持JSP,如果我們的應(yīng)用有些視圖不是采用JSP,而另外一些視圖如采用EXCEL和PDF。那么Struts是無能為力的。
4、Struts框架對異常沒有提供一個良好的支持。
Struts也看到了自身存在的缺陷,并不斷進(jìn)行改進(jìn),隨著Struts 2的到來,會帶來一些改變的。
WEBwork是一種比Struts更易于使用,基于Command模式的開源WEB框架。WEBwork結(jié)構(gòu)十分的簡單,也提供了豐富的標(biāo)簽庫,WEBwork的攔截器也十分的優(yōu)秀。并且WEBwork是非線程的。WEBwork提供了一個IOC容器,支持國際化,并且支持多種視圖技術(shù)。可以說WEBwork是一個非常優(yōu)秀的WEB框架。但是WEBwork的開發(fā)文檔少得可憐,它的客戶端驗(yàn)證技術(shù)不太成熟,Velocity Templates技術(shù)還是太復(fù)雜,不提供對組件的封裝,而Struts的Tiles更好一點(diǎn)。采用WEBwork,必須對它的運(yùn)行機(jī)制十分了解。同時WEBwork對每個用戶交互都強(qiáng)加Command模式,而不管是否需要。所有Command 的excute方法被迫拋出Exception,你無法知道哪一命令會拋出什么類型的異常,而且WebWork的路注定是沒有歸途的。
Spring Web框架中一條黑馬
2001年Rod Johnson編寫一本書叫《J2EE設(shè)計(jì)開發(fā)編程指南》。 這本書的內(nèi)容構(gòu)成了Spring框架的雛形。接著Rod Johnson又編寫了另外一本書《J2EE without EJB》,并同時推出Spring框架。這兩本書迅速的在業(yè)界引起了轟動,為Spring的推出作了很好的鋪墊。Spring引入IOC(控制反轉(zhuǎn))的概念,采用POJO對象,AOP支持和輕量級容器來開發(fā)企業(yè)應(yīng)用,這些正是業(yè)界多年來一直苦苦尋找的解決方案。Spring一推出就紅遍了大江南北,迎來了Java企業(yè)開發(fā)的春天。
筆者認(rèn)為Spring MVC 是基于請求響應(yīng)模式最為優(yōu)秀的開源WEB框架。它來自于Spring,天生就支持IOC 和AOP,這是其它任何WEB框架無法相比的。
Spring MVC 是一個很薄的WEB框架,它清晰的分離了數(shù)據(jù)和視圖。支持多種視圖技術(shù)(JSP,XML,EXCEL, PDF…)十分方便。
Spring的優(yōu)勢
Spring MVC對于表單提交類的應(yīng)用提供了一個完整的生命周期。
Spring MVC 支持頁面數(shù)據(jù)的原生綁定為POJO對象,并可以自定義擴(kuò)展綁定器,而不是像Struts那樣只能把頁面數(shù)據(jù)自動綁定為String 類型。
Spring MVC 自定義行為變得十分容易,這得益于Spring框架良好的設(shè)計(jì),Spring MVC的控制器也是基于Command模式的。
Spring MVC 有良好的數(shù)據(jù)校驗(yàn)框架,也很容易自定義數(shù)據(jù)校驗(yàn)行為。
Spring MVC 提供了一個良好的異常處理機(jī)制,可以方便的自定義各類異常的處理行為。
Spring MVC 提供了有用的標(biāo)簽。(注意是有用的,沒有用的Spring絕不提供)
Spring MVC 支持I18N及文件上傳等。
Spring 還推出了Spring WEB Flow,用于向?qū)降腤EB應(yīng)用開發(fā)。
Rod Johnson 是一個JAVA EE專家,我更愿意稱他為一個實(shí)踐家。Rod Johnson 的經(jīng)典語錄是“不要重復(fù)發(fā)明輪子”,Spring 框架的各方面應(yīng)用都來源于長期的實(shí)踐經(jīng)驗(yàn),集百家之長,吸收其它框架的精華,正是Spring取得成功的原因。Spring MVC也是如此。Spring提供給你真實(shí)需要的,通過長期實(shí)踐證明的東西。
雖然Spring 已經(jīng)大紅大紫了,但是Spring MVC卻沒有流行起來。它出來太晚了,而Struts已經(jīng)深入人心了,Struts這么多年的表現(xiàn)一直不錯,雖然Struts并不是那么優(yōu)秀。但是它有著龐大的開發(fā)人群,關(guān)于Struts的資料是鋪天蓋地。企業(yè)很容易找到Struts開發(fā)人員,卻難以找到Spring MVC開發(fā)人員。另外一個客觀原因就是Spring太靈活了,Spring MVC也不例外,正因?yàn)镾pring MVC過于靈活,致使初學(xué)者望而生畏。Spring MVC需要進(jìn)行過多的XML配置,Spring MVC的文檔相對比較少,所以現(xiàn)在Spring MVC的使用者有限,但無論如何,Spring MVC是一個非常優(yōu)雅的WEB開發(fā)框架,花費(fèi)一點(diǎn)學(xué)習(xí)成本是值得的。
ASP.Net的成功說明了什么?
ASP.Net是一種面向組件,基于事件驅(qū)動模型的WEB開發(fā)技術(shù)。在基于請求驅(qū)動模型的WEB開發(fā)技術(shù)中(如JSP和ASP),程序代碼需要混合在HTML標(biāo)簽中。而事件驅(qū)動模型與請求驅(qū)動模型相比,在一個表單上的組件通過激活應(yīng)用程序的事件來響應(yīng)用戶的行動。開發(fā)人員通過為組件的相關(guān)事件編寫相應(yīng)的程序代碼來實(shí)現(xiàn)相關(guān)的邏輯。事件驅(qū)動模型的WEB開發(fā)技術(shù)提供了一種更為直觀的編程模式,使得WEB開發(fā)就像編寫一個VB或Java Swing桌面應(yīng)用程序一樣。用鼠標(biāo)把相應(yīng)的控件拖到頁面視圖,然后再為控件編寫相應(yīng)的事件代碼來實(shí)現(xiàn)業(yè)務(wù)邏輯。這樣,就把WEB前端開發(fā)變成了運(yùn)用高級語言進(jìn)行程序開發(fā)(在ASP.NET中采用VB..NET或C#)。面向組件和基于事件驅(qū)動模型使得WEB開發(fā)真正的回歸到了傳統(tǒng)的開發(fā)方式。大大的簡化了WEB項(xiàng)目開發(fā)的復(fù)雜度。
ASP.NET提供了豐富有WEB前端組件。因?yàn)锳SP.Net是面向組件的,和基于事件的。所以ASP.Net必須提供豐富的組件,并為這些組件定義相關(guān)的事件。讓開發(fā)人員去擴(kuò)展事件代碼來完成邏輯功能。ASP.NET 一開始就提供最實(shí)用的WEB組件,如DataGrid用于數(shù)據(jù)顯示,開發(fā)人員只需要通過設(shè)置屬性就可以實(shí)現(xiàn)自定義分頁顯示。而在以前的ASP或JSP則需要編寫大量的程序代碼才能完成。到ASP.NET 2.0時,微軟更是提供了近150多個WEB組件,如在WEB開發(fā)中經(jīng)常用到的樹形菜單組件,下拉菜單組件,文件上傳組件等。ASP.NET通過提供這些豐富而功能強(qiáng)大的組件,使得WEB應(yīng)用開發(fā)就像桌面應(yīng)開發(fā)一樣簡單。
正因?yàn)锳SP.Net帶來了一種全新的開發(fā)模式,使得以往復(fù)雜的WEB應(yīng)用開發(fā)變得簡單,讓W(xué)EB應(yīng)用更易于發(fā)布,并通過微軟的商業(yè)運(yùn)作,ASP.NET一掃ASP的陰霏,迅速的占據(jù)了大量企業(yè)市場份額。
ASP.NET的成功對我們有什么啟示呢?可以肯定面向組件、基于事件驅(qū)動模型是未來WEB開發(fā)技術(shù)的發(fā)展方向。ASP,JSP等基于請求驅(qū)動式的WEB技術(shù)必將退出歷史的舞臺。
因?yàn)橛蓮S商來提供豐富而實(shí)用的組件,大大簡化WEB前端的開發(fā)量和開發(fā)難度。把復(fù)雜的問題交由廠商或開源組織去解決。基于事件驅(qū)動模型才是真正的把UI人員和業(yè)務(wù)程序員分離開來。只有把程序代碼與HTML標(biāo)記分離,才能真正做到UI設(shè)計(jì)者與程序員分離。
面向組件,基于事件驅(qū)動的WEB框架要取得成功必須提供大量實(shí)用的WEB組件。只有提供了豐富的,功能強(qiáng)大的WEB組件,開發(fā)人員才能從WEB開發(fā)中解脫出來。否則如果每個用戶都需要去實(shí)現(xiàn)自己的組件庫,那樣的工作量也是非常龐大的。特別是針對一些小型用戶。必須要有優(yōu)秀的IDE工具配套支持,如果沒有VS 2003或VS2005開發(fā)工具,而是通過簡單的文本編輯工具來進(jìn)行ASP.Net開發(fā),很難想像ASP.Net會成功。要真正的實(shí)現(xiàn)像VB或Java Swing編寫桌面應(yīng)用程序那樣來開發(fā)WEB應(yīng)用程序,優(yōu)秀的IDE工具是必不可少的。允許你把組件從組件面板拖放到頁面上并通過屬性編輯器來定義它的外觀和行為,直接為組件的相關(guān)事件編寫事件代碼。
JSF及它的未來
Java Server Faces 簡稱JSF,是一種面向組件和事件驅(qū)動模型的WEB開發(fā)技術(shù)。JSF的誕生還要追溯到2001年。在2001年5月,Sun制定了一個用戶界面框架的規(guī)范JSR#127.
而JSF 規(guī)范的1.0到2004年3月才得以面世。直到JAVA EE 5的發(fā)布,JSF推出1.2版本并作為JAVA EE 5的一部分同時發(fā)布。歷經(jīng)5年的風(fēng)雨,JSF現(xiàn)在成為了JAVA企業(yè)應(yīng)用規(guī)范的一部份。
我在上節(jié)討論ASP.NET的成功時,已經(jīng)介紹了面向組件,基于事件驅(qū)動模型的WEB開發(fā)技術(shù)的優(yōu)勢。并從ASP.NET的成功可以看出面向組件和基于事件驅(qū)動模型是未來WEB技術(shù)的發(fā)展方向。
從技術(shù)上來看JSF是非常先進(jìn)的,提供了很多復(fù)雜的組件支持類似Spring的依賴注入功能。頁面流程控制也通過Faces-config.XML來配置,而不是寫死在代碼里。這有點(diǎn)與Struts類似。同時像SUN,Oracle,Boland,IBM等公司都為JSF提供了開發(fā)環(huán)境,Sun的Java Studio Creator2 和Oracle的Oralce Jdeveloper 10g都是免費(fèi)的JSF開發(fā)工具,像Eclipse也有相應(yīng)的插件提供對JSF的支持。JSF技術(shù)也同時得到了許多廠商的支持,如Sun的JSF WEB UI,IBM的JSF extension,Oracle的ADF Faces.還有許多開源項(xiàng)目如My Faces都提供了對JSF的支持和擴(kuò)展。
這樣看來,JSF成為了JAVA EE的標(biāo)準(zhǔn),又得到了眾多廠商和組織的支持,那么JSF應(yīng)該是前途一片光明啦?
何以見得,JSF錯過了它的最好發(fā)展時期。Sun其實(shí)很早之前就想簡化JSP的開發(fā),用一種新的技術(shù)來取代JSP。從而簡化整個WEB層的開發(fā)。于是在2001年就開始制定了JSF的規(guī)范,但是由于SUN的官僚作風(fēng)及商業(yè)推廣的失敗,JSF一直未能走向前臺。如果SUN能在2002年或2003年,在JSP最紅火的時候全力推出JSF。取名為JSP 2.0或JSP 3.0。而不是一意孤行的取名為JSF,那么現(xiàn)在JAVA的WEB開發(fā)早已經(jīng)是面向組件和基于事件驅(qū)動了。
成熟和穩(wěn)定方面:
JSP的確是一種非常成熟和穩(wěn)定的技術(shù),就是因?yàn)镴SP太成熟了,所以才導(dǎo)致了JSF的發(fā)展緩慢。世界上有太多采用JSP技術(shù)的成功案例,SUN非要把JSF變成一個新生兒,誰也不愿意去冒這個風(fēng)險。雖然采用JSP技術(shù)進(jìn)行WEB開發(fā)是復(fù)雜的,而且開發(fā)周期要長,但是它是穩(wěn)定并且成熟的WEB技術(shù)。JSP已經(jīng)占據(jù)了大量的市場份額,如果JSF要想取代JSP,那么JSF就必須有成功的案例來證明JSF能像JSP那樣可靠和穩(wěn)定。
廠商的支持方面:
廠商對JSF的支持遠(yuǎn)遠(yuǎn)不夠。從JSF1.0,到JSF1.2的發(fā)布并成為JAVA EE的標(biāo)準(zhǔn),經(jīng)歷了近五年的時間。各個廠商一直對JSF持觀望的態(tài)度,其實(shí)主要還是取決于SUN。如果SUN在早期就把JSF作為JAVA EE的標(biāo)準(zhǔn),那么現(xiàn)在JSF已經(jīng)是遍地開花了。JSF的命運(yùn)從一開始就像EJB,在實(shí)驗(yàn)室時呆了5年之久,要把它定制成一個大而全的規(guī)范是不可能的,任何技術(shù)都應(yīng)該聽取開發(fā)人員的意見,EJB的失敗已經(jīng)充分的證明了在辦公室寫出的規(guī)范并不是開發(fā)人員所需要的。
雖然IBM,Oracle等廠商現(xiàn)在都已經(jīng)提供了對JSF的支持,但是他們提供的JSF組件庫都非常有限,而且有些組件是已經(jīng)過時的組件。同ASP.NET 2.0相比,各廠商對JSF的支持遠(yuǎn)遠(yuǎn)不夠,這又怎么能夠吸引開發(fā)者和企業(yè)選擇JSF呢?同時,ASP.NET 2.0定義的頁面的生命周期要比JSF靈活及有用得多。而JSF的生命周期則顯得生硬和呆板。
我們上節(jié)說到ASP.NET的成功離不開VS 2003和VS 2005這些優(yōu)秀的IDE開發(fā)工具的支持。雖然有Sun的Java Studio Creator2 和Oracle的Oralce Jdeveloper 10g免費(fèi)支持JSF開發(fā),但它們都不是最主流的JAVA 企業(yè)應(yīng)用開發(fā)工具。而像目前最主流的ECLIPSE卻沒有很好的支持JSF的開源免費(fèi)插件。在開源的大旗下,恐怕很少有人會再去選擇收費(fèi)的開發(fā)工具吧。WEB開發(fā)只是JAVA企業(yè)應(yīng)用開發(fā)的一部份,而不是全部。希望哪一天能見到Sun或IBM這樣的商業(yè)公司來為ECLIPSE這些主流IDE開發(fā)支持JSF的插件。其實(shí)世面上還有一些專門針對JSF的開發(fā)工具,但是我們要知道,JSF僅僅是JAVA企業(yè)應(yīng)用開發(fā)的一部份,我們更需要一個成熟的集成開發(fā)環(huán)境,如重構(gòu),單元測試,甚至整個項(xiàng)目的生命周期管理。我們需要的是在一個主流的成熟的集成開發(fā)環(huán)境上提供對JSF的支持,而不是那些的專門針對JSF的單一編輯工具。
Sun商業(yè)策略方面:
SUN的商業(yè)推廣策略也是JSF能否成功的關(guān)鍵。SUN不缺技術(shù),但是缺商業(yè)推廣。JSF遲遲未能成為JAVA EE的標(biāo)準(zhǔn),延誤了JSF的推廣。把JSF取名為JSP 3.0都可能對JSF發(fā)展更為有利。很多時機(jī)被SUN一再錯過了,才讓JSF在今天顯得如此的尷尬。JSF社區(qū)的建設(shè)及該如何吸引開發(fā)人員和企業(yè)轉(zhuǎn)向JSF?SUN的商業(yè)推廣策略是至關(guān)重要的。
天將降大任于斯JSF也!!!雖然WEB開發(fā)技術(shù)注定要進(jìn)入面向組件和基于事件驅(qū)動的時代, JSF 能否拯救WEB的江湖呢?讓我們共同拭目以待吧!!
posted on 2009-03-15 02:37
圣克爾·光 閱讀(132)
評論(0) 編輯 收藏