360UI 界面框架 即QUI框架與EXT比較

EXTJS框架是很是全面和成熟的，這是由於它發展的年頭久遠，而且有全世界的EXTJS愛好者爲其出謀獻策，它的組件庫尤爲是DataGrid組件無人能出其右。我在最初也考慮過使用EXTJS來作項目，學習了一段時間後最終仍是選擇放棄。放棄的理由有以下幾點：

（1）風格樣式單一。這是最讓我受不了的。一個讓用戶滿意的系統並非單純組件的堆砌，用戶對系統的評價除了可以完成相應的功能外，還涉及到界面是否美觀、導航是否合理等等。尤爲是界面美觀方面，在這個用戶體驗全面來臨的時代，一個賞心悅目的系統尤其重要。而是用EXTJS構建的系統界面都是千篇一概的，不管是藍色風格、灰色風格仍是其餘的第三方風格，看起來都是那麼的單調。例以下圖：

（2）EXTJS定位爲底層JS框架，提供的都是基礎的組件，並無提供網頁經常使用的佈局模板，全部的頁面都須要經過JS腳本動態生成佈局與組件，這致使系統開發效率很低，尤爲是對於新手。我曾經使用EXT製做一個普通的表單頁面，結果花費了我近一個小時的時間（也有多是我水平不夠，呵呵）。不過聽說3.0版本提供了可視化工具好了不少。

（3）EXTJS數據傳輸機制主要採用了AJAX+JSON模式，從長遠角度看，這種作法是合理的。但不幸的是，我所在的開發團隊仍是習慣於傳統的同步通訊方式。由於歷經多年的項目積累，咱們早已有了一套成熟的SSH框架，咱們全部項目的後臺程序都是用這套東西。若是採用EXTJS，那麼意味着須要生成JSON數據以AJAX方式傳遞，無疑會增長大量的工做量。

（4）組件很難分離。若是我想在項目中使用一兩個EXT的組件，例如window或者combox組件，那麼我也須要將整套EXT框架機制所有引入，感受太大材小用了，並且會影響總體性能。

另外我也嘗試過其餘的JS框架，發現它們的思路都與EXTJS類似，也一樣沒法知足個人須要。因而我決心本身開發一套網頁框架，由此建立了QUI框架。要說明的有如下幾點：

（1）首先我將其定位爲集成框架，它並非一個單純的JS庫，而是一套完整的企業級應用解決方案。包含了十多種導航結構的主頁，可以知足絕大部分項目的總體佈局須要。內容頁面也提供了不少類型的模板，例如表單模板、數據列表模板等等。這樣作的目的是爲了大幅度地提升系統開發效率，不須要本身去建立，直接拿過來作簡單的修改就能夠用了。

（2）QUI框架最大的亮點不在於它擁有衆多實用的組件和特效，而在於它擁有獨特的皮膚機制，能夠很方便地爲其定製皮膚。我事先已經爲每種結構都作了8-10套皮膚，之後新皮膚還會不斷增長的。效果以下：

登陸頁面皮膚效果：

（3）QUI框架另外一個讓我得意的特色是使用的方式很是簡單。在整個框架的開發過程當中我就始終在思考如何簡化使用步驟。它與EXTJS動態建立HTML元素的機制徹底不一樣，是對現有的HTML進行渲染。例如若是想要建立一個提示信息，只要在元素上寫title=」xxx」就能夠了，效果以下：

而若是想要建立一個表單，與傳統寫HTML標籤的方式沒有任何區別，框架自動會把表單元素渲染成漂亮的、功能強大的頁面。想要增長功能只要在標籤上添加屬性就能夠了，例如爲文本框標籤增長一個watermark=」xxx」的屬性，那麼文本框就具備了水印效果，以下：

一個被渲染後的表單總體效果以下：

固然，不少人已經習慣了EXTJS的開發方式，反而會以爲EXT的開發方式效率更高一些，我也沒意見，所謂蘿蔔青菜各有所愛。

（4）QUI框架只是對前臺元素進行渲染，不會改變原有的後臺機制。另外還提供了分離版本，這樣若是隻想使用裏面的一兩種組件或特效也沒必要將整套框架機制所有引入。前面提到的那兩個問題也解決了。

 

 

項目網址：www.360ui.net