夢想不只是做夢想一想

不知不覺2008已經(jīng)走到了盡頭，在這近一年中，一直不斷的嘗試用ExtJS做項目，從1.1到現(xiàn)在的2.2，吃了不少苦頭，也有不少收獲，總結(jié)一下，一起分享！

1. ExtJS的定位是RIA，和Prototype、jQuery等類庫的定位不同。使用ExtJS做開發(fā)，就是意味著以客戶端開發(fā)為主，不然就不叫RIA框架了，而Prototype、jQuery等只是輔助性的客戶端框架，和ExtJS不在同一條起跑先上。如果一定要和其它的框架做比較的話，應(yīng)該和Isomorphic SmartClient、Backbase Enterprise Ajax之類的框架做比較，當(dāng)然，和他們相比，ExtJS還是有很大的優(yōu)勢的。

2. 使用ExtJS時需要解決如何服務(wù)端通信的問題。由于ExtJS只是一個客戶端的框架，和服務(wù)端技術(shù)沒有關(guān)系，也就沒有相應(yīng)的服務(wù)端的適配層，因此客戶端如果要用ExtJS，則必須提供它需要的數(shù)據(jù)結(jié)構(gòu)。ExtJS主要通過這幾種方式和服務(wù)端進(jìn)行通信：

• Ext.Ajax.request 做普通的異步請求，服務(wù)端可以根據(jù)實際情況返回JSON形式數(shù)據(jù)或者HTML片段；
• Ext.tree.TreeLoader 加載樹形結(jié)構(gòu)，服務(wù)端必須返回JSON形式數(shù)據(jù)，而且要符合Ext.tree.TreeNode的配置要求，否則自己做轉(zhuǎn)換；
• Ext.data.Store及其派生類 加載表格形式的數(shù)據(jù)，服務(wù)端可以根據(jù)實際情況返回JSON形式數(shù)據(jù)或者XML形式數(shù)據(jù)，如果沒有特殊要求，推薦返回JSON格式的數(shù)據(jù)；
• Ext.Element.update 局部更新，這個方法最總還是要調(diào)用Ext.Ajax.request方法，之所以把它單獨列出來，是因為這種方式比較容易被忽視，但是在某些情況下還是挺 有用的，比如調(diào)用Ext.Panel.body.update()對某個Ext.Panel的內(nèi)容進(jìn)行局部更新，如果使用這種方式，那么服務(wù)端只能相應(yīng)的 返回HTML片段了；

3. 使用ExtJS時的注意事項。ExtJS和其它的輔助性類庫(Prototype、jQuery等)相比顯得非常龐大，讓很多很多初學(xué)者望而卻步。經(jīng)過近一年的學(xué)和用，對于ExtJS的使用，我總結(jié)了一下幾個注意事項：

• 盡量使用ExtJS的方言。 ExtJS提供了很多有用的方法，解決客戶端JavaScript常見的開發(fā)任務(wù)，常見的有查詢HTMLDom，創(chuàng)建HTML元素，為HTML元素注冊事件響應(yīng)函數(shù)等，這些大可以全部使用ExtJS提供的方法，使自己代碼構(gòu)建與ExtJS之上，舉幾個例子：
  • 查詢ID為container的DIV下所有的checkbox，可以使用：Ext.fly(‘container’).select(‘input[type=checkbox]’);
  • 在ID為container的DIV內(nèi)創(chuàng)建一個按鈕，可以使用：Ext.fly(‘container’).createChild({ tag: ‘input’, type: ‘button’});
  • 為ID為container的DIV的click事件注冊處理函數(shù)，使用：Ext.fly(‘container’).on(‘click’, handlerFn, scope);
• ExtJS的自定義事件很好用，可以實現(xiàn)一對多的通知，而且任何自定義事件都可以中途停止，只要有一個處理函數(shù)返回false。
• Store合并成一個文件 用ExtJS顯示數(shù)據(jù)，自然就需要用到Ext.data.Store及其派生出來的類，可以考慮所有的Store合并到一個文件，這樣對重用有很大的幫助。
• 腳本文件管理 盡可能的每個模塊做成一個類，一個類一個文件，類似與Java或C# 的文件處理方法，每個文件注明其作用，依賴的文件等，如果太多的話可以考慮寫一個配置文件，通過讀配置文件來輸出腳本到客戶端。
• 調(diào)試和部署分別加載Debug和Release版本的腳本 ExtJS附帶的例子中沒有使用完整Debug版本的例子，所以很多人找不到完整的Debug版本的引用順序，通過對Source文件夾下的ext.jsb文件進(jìn)行分析，就可以得到正確的加載順序，如下：
  • Debug
    1. /ext-path/source/core/ext.js
    2. /ext-path/source/adapter/ext-base.js
    3. /ext-path/ext-all-debug.js
  • Release
    1. /ext-path/adapter/ext/ext-base.js
    2. /ext-path/ext-all.js
• 對Script進(jìn)行壓縮 對項目中有大量的JavaScript的話，對其進(jìn)行壓縮是很有必要的，這里我推薦的是ExtJS的論壇提供的JS Builder，可以通過配置文件來對Script和CSS進(jìn)行壓縮，據(jù)說ExtJS就是用這個工具進(jìn)行壓縮的，不過有一個缺點，就是不支持UTF-8編碼。

4. ExtJS的優(yōu)點和缺點總結(jié)。經(jīng)過近一年的嘗試，ExtJS的優(yōu)缺點總結(jié)如下：

• 優(yōu)點
  • 一致的類庫 這點在1.1版本時還不是很完善，但是到了2.0以后，ExtJS內(nèi)部經(jīng)過了翻天覆地的變化，特別是UI組件，有統(tǒng)一的基類，給人的感覺很像是一個運(yùn)行在瀏覽器上的運(yùn)行時框架，這一點只有在對ExtJS熟練了之后才能體會到。
  •  托管頁面呈現(xiàn) ExtJS在發(fā)展到2.0之后，不僅UI類庫一致了，而且渲染方式也是統(tǒng)一的，用官方的話說，是Managed Rendering，這一點使得UI的擴(kuò)展也比較一致，有利于以后的維護(hù)與發(fā)展。
  • 相對豐富的文檔和示例 毫無疑問，剛剛接觸到ExtJS的人多數(shù)都是被它附帶的例子和開發(fā)文檔吸引過去的，它的文檔做的確實不錯。
  • 華麗而成熟的界面 ExtJS在2.0之后的界面真的是沒得說，不僅華麗，而且相對很成熟。
• 缺點
  • 沒有合適的開發(fā)利器 毫無疑問，一個好的開發(fā)工具可以大大的提高編碼的速度，但是對于ExtJS，始終沒有一個完美的開發(fā)工具，可以推薦的有Aptana Studio， Spket IDE，和Spket 提供的提示文件，但是都是各有優(yōu)缺點，都不完美，只能一邊看SDK一邊寫代碼。
  • 沒有界面設(shè)計工具 雖然有人提供了一個在線的界面設(shè)計工具，但是和Visual Studio提供的ASP.Net設(shè)計工具來說，真的可以說是天壤之別。因此，只能一邊預(yù)覽，一邊寫代碼。
  • 文檔不全 雖然ExtJS提供的文檔很豐富，但是還是跟不上源代碼的更新速度，所以，經(jīng)常要通過看源代碼，調(diào)試才能真正解決問題。
  • 不能編譯 這一點可以說是JavaScript的缺點（如果能編譯，就不叫JavaScript了），在實際的開發(fā)中，經(jīng)常會敲錯一些代碼，比如大小寫錯誤等，不能通過編譯得到反饋，只能在運(yùn)行時排錯，導(dǎo)致開發(fā)的效率比較低下。

5. 使用ExtJS做應(yīng)用的一些建議。多數(shù)人認(rèn)為ExtJS的腳本體積很大，不適合放到互聯(lián)網(wǎng)上，對于這一點，有如下建議：

1. 部署到互聯(lián)網(wǎng)上的Web應(yīng)用一定要加載Release版本的ExtJS
2. 可以考慮只加載必須的組件，build目錄下腳本文件都是壓縮過的，如果項目中用到的ExtJS的組件不是很多，可以只加載用到的
3. 考慮使用IIS的文件壓縮功能
4. 使用Google的Gears，把所有的靜態(tài)文件做客戶端緩存
5. 使用ADOBE的AIR，把腳本打包到客戶端運(yùn)行

總的來說，ExtJS是一個不錯的框架，它陪伴我走過了精彩的2008，也許在未來的2009，我會轉(zhuǎn)向其它的RIA技術(shù)，但是我至少會繼續(xù)關(guān)注ExtJS，同時也希望這個框架能夠頑強(qiáng)的生存下去。

PS，共享一些學(xué)習(xí)資料：

• ExtJS 2.0 簡介 （推薦反復(fù)閱讀，細(xì)細(xì)體會）
• ExtJS的用戶擴(kuò)展合集 （推薦常去看看）
• 如何用ExtJS構(gòu)建大型應(yīng)用 （可以說是做ExtJS開發(fā)的指導(dǎo)思想）
• ExtJS 2.0 類庫的腦圖 （可以加深對ExtJS類庫的繼承關(guān)系的理解）