ExtJS 開發總結

 

不知不覺2008已經走到了盡頭,在這近一年中,一直不斷的嘗試用ExtJS做項目,從1.1到現在的2.2,吃了不少苦頭,也有不少收穫,總結一下,一起分享!

1. ExtJS的定位是RIA,和Prototype、jQuery等類庫的定位不同。使用ExtJS做開發,就是意味着以客戶端開發爲主,不然就不叫RIA框架了,而Prototype、jQuery等只是輔助性的客戶端框架,和ExtJS不在同一條起跑先上。如果一定要和其它的框架做比較的話,應該和Isomorphic SmartClientBackbase Enterprise Ajax之類的框架做比較,當然,和他們相比,ExtJS還是有很大的優勢的。

2. 使用ExtJS時需要解決如何服務端通信的問題。由於ExtJS只是一個客戶端的框架,和服務端技術沒有關係,也就沒有相應的服務端的適配層,因此客戶端如果要用ExtJS,則必須提供它需要的數據結構。ExtJS主要通過這幾種方式和服務端進行通信:

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

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

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

 

4. ExtJS的優點和缺點總結。經過近一年的嘗試,ExtJS的優缺點總結如下:

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

5. 使用ExtJS做應用的一些建議。多數人認爲ExtJS的腳本體積很大,不適合放到互聯網上,對於這一點,有如下建議:

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

 

總的來說,ExtJS是一個不錯的框架,它陪伴我走過了精彩的2008,也許在未來的2009,我會轉向其它的RIA技術,但是我至少會繼續關注ExtJS,同時也希望這個框架能夠頑強的生存下去。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章