easyUI與選擇WebUI


easyUI與選擇WebUI

作者:sagahu@163.com,2013-03-25,太原

關鍵字:easyUI, 選擇WebUI

 

一、前言

當今網上有了很多的WebUI庫,也有很多的網頁開發使用這些成套控件而得到了良好的表現與極高的生產效率,正有着很多以前缺乏Web控件積累的程序員/團隊/公司在選用並定制最合適自己的WebUI套件。本人使用easyUI為例,向大家介紹自己在選用WebUI庫時的一些感受。

 

說到WebUI庫,不得不提到這樣一種程序結構:

 

如圖,我們關注其中的UI前端與UI后端2個東西,它們是什么呢?以我的mySagasoft™ WebMIS技術架構為例,我給用戶顯示的網頁都是.html網頁,里面只有:html/css/javascript三樣成分;而在Web服務器上有着無任何界面元素的.aspx頁提供數據服務(也可用.ashx代替);當前者某個局部需要動態數據時,通過javascript/Ajax與后者通信,獲得數據來更新哪個局部。這就是說,我把UI拆分成了2層,前面顯示給用戶的純靜態網頁稱為UI前端,后面提供數據服務的稱為UI后端,中間用Ajax把2者聯系起來。其實這種程序結構早在ASP、JSP時代就已經被大牛們總結出來了。這樣有着顯著的好處:這樣便利了UI前端靜態效果的設計與UI后端數據服務的獨立實現,只需要程序員繼續修改2者的通信。特別是對於很多苦惱於ASP.NET程序員與網頁美工因服務端控件扯皮事件的軟件公司帶來了福音。

 

成套WebUI庫技術與產品的出現,給了業內把UI前端與UI后端分層的程序結構提供了強大的支持。可以發現越來越多的公司或者團隊正在或者已經選用了適合自己的套件庫,逐漸遠離微軟服務端控件的封裝,減少對許多所謂微軟新技術的迷信。

二、縱覽easyUI框架

(一)按鈕與菜單

 

鏈接按鈕,這是管理軟件頁面上使用頻率最高的;有其它樣式,可禁用/啟用。

 

這3個依次是菜單、按鈕菜單、下拉菜單。看起來很漂亮,但是如果瀏覽器禁用腳本的話,哪個效果是慘不忍睹,所以這就使得它們在使用時有局限性:絕不適合用在哪些企業網站首頁上!其實在B/S型企業管理軟件中我也不多使用。

(二)各種窗口

 

圖示是一個消息提示框,它的消息提示框分為:普通信息、錯誤、警告、問詢、確認、輸入提示、進度、右下角顯示等等,比較齊全。

 

其彈出模態對話框也很漂亮,控制也比較詳細。普通窗口與對話框類似。

(三)GRID、TREE、TREEGRID3個一樣不少

我們作數據呈現時,對於批量數據最常用、最需要的就是Grid、Tree、TreeGrid三樣,微軟開發工具多年來總是只提供很簡陋的前2者。這個控件包3者都提供了,還都比較好用。

 

這個Grid控件可用鼠標來調整列寬,下面與右面的滾動條也是ASP.NET的標准GridView沒有的。個人覺得這是當今B/S企業管理軟件GRID必須具有的!

 

顯然這個Tree比ASP.NET的標准好看,也支持單選與復選控制,如果還覺得不好用,可以用國人的自豪——zTree——代替了它。

 

太多的項目中需要TREEGRID,所以盡量避免單獨找一個與其它控件不配套的。

還有個PropertyGrid,用的不多,也不太好用,不說它了。

 

對於這一套控件包里的GRID與TREEGRID,在數據編輯時最常使用方式是:選擇一條記錄,彈出這條記錄的對話框或者跳轉到這條記錄的邊界頁面去操作,完了就單獨更新這條記錄。這種方式很簡單,這套控件支持的很好。另一種方式是直接在控件里編輯多條記錄、多個單元格的數據,然后批量提交。這種方式比前一種復雜多了,這套控件也支持,但是本人並沒有去深入的體驗,所以不能對這方面下什么結論。

(四)窗口上的小控件也很齊全

這套控件包支持非常方便的拖動、改變尺寸、進度條、搜索框、分頁、動態加載等等,還有靈活的日期時間選擇框,真是精致、齊全、匠心獨具!

(五)齊全的組合下拉框

  

在微軟的開發工具里歷來沒有這些下拉框控件:ComboGrid、ComboTree、ComboTreeGrid等等。但是實際開發中這些都需要,這套控件包就提供了前2者,好像能配置出第3種,記不清了。但是沒有這些的控件包你必須另外再配!

(六)不錯的布局實現

 

這是其缺省的主界面布局,特別適合B/S型企業管理軟件。它把頁面分成上、下、左、右、中5塊,可選自己的布局方式。其實每一區域都是一個相對獨立的“面板”,支持鼠標拖動調整尺寸與隱藏/顯示。支持在“面板”內布局。支持選項卡式布局,雖然這樣很費資源。

 

套件包里還提供了一個很不錯的手風琴式菜單控件。

 

從圖上可以看出,這個“面板”支持很多詳細的控制,如隱藏/顯示/最大化/最小化等,非常具有實用性。

 

(七)可選的Form元素

 

自從有了Ajax,動態頁面編程時對Form的以來就逐漸弱化,甚至可以不用Form。雖然如此,這套控件包還是提供了這方面的一些功能。

 

本人就不太使用Form,這一方面我主要使用其數據驗證,更確切點說,是使用其友好的數據不合法提示!

(八)HTTP請求與數據綁定

當前大多數JQuery標准控件具有通過url直接請求后端服務的機制,這樣可以在URL后面附帶上少量簡單數據。而這套控件在此基礎上支持定義post/get方式,支持請求中附帶參數。我認為很有必要支持帶參數的POST請求,這樣才能附帶較大數據量,也提高了安全性。

 

大多數JQuery標准控件通過url請求返回的json數據而直接綁定到了控件上。這種情況下,后端數據格式與前端控件要求的數據格式之間的轉換,只能是放在后端,理論上會增加后端的負載。但實際應用中,難免需要把數據格式轉換工作放在客戶端瀏覽器javascript里,就是說不希望直接綁定,是后端數據反饋回本地進行處理后再綁定到控件上。例如,后端返回bool值1/0要在前端用checkbox顯示,或者彌補一些服務端對象/Json轉換在日期時間類型上的不足,或者就是為了把計算負載轉移到客戶端等情況。總結就是數據返回與綁定之間允許再插入干預操作。這套控件在這一點上就做的比較好。例如DataGrid控件除了url/參數直接請求/綁定方式,還有后期綁定數據的方法,參看下面的代碼:

 

function loadPage(pageNumber, pageSize) {

  addCookie("RolePageSize", pageSize, 7);

  var where = getWhere();

  var url = "../MisBaseV2_Behind/RoleManager.aspx";

  var data = { "ReqKey": "GetListPage", "pageSize": pageSize, "pageIndex": pageNumber,

    "where": where, "orderBy": "Id asc"

  };

  $.ajax({

    type: "POST", url: url, data: data, dataType: "json",

    success: function (result) {

      if (!handleMyAjaxResult(result))

        return;

      var chk0 = "<input type='checkbox' disabled='disabled' />";

      var chk1 = "<input type='checkbox' disabled='disabled' checked='checked' />";

      $.each(result.Data.rows, function (i, roleData) {

        roleData.IsAdmin = roleData.IsAdmin > 0 ? chk1 : chk0;

        roleData.IsSystemic = roleData.IsSystemic > 0 ? chk1 : chk0;

      });

      $("#table1").datagrid("loadData", result.Data);

    }

  });

}

上面代碼里,把請求返回的數據處理后,再綁定給table1。這顯然不是通過url請求/響應的直接綁定。

(九)支持切換與定制Theme

這個套件缺省有3套Theme,雖然支持定制Theme與動態切換,筆者現在還沒有學會。如果與其它WebUI控件混用,會非常需要統一的Theme,所以這一點就是非常必要了。所以我說,如果公司/團隊選擇它來做自己的產品架構時,一定要追求這一點。

(十)比較成熟

我實際使用過,覺得這套控件比其它同類產品要成熟、可靠些。

 

與LigerUI相比,后者好像是模仿前者,而且網上反映BUG多多,更糟的是原作者早停止更新了,所以后者的應用只能停留於一些jQuery高手。easyUI的官網一直在持續更新。

 

看到一套基於ExtJS的開源套件——FineUI,沒親自用過。只是有這樣的顧慮:聽說ExtJS是收費的;聽說ExtJS的性能不如jQuery;當前JS框架排名最靠前的是jQuery,應用最廣,而ExtJS則次一些,其投資價值小很多吧?

 

(十一)郁悶的代碼半開源

這套控件包最大的遺憾就是:它的代碼是半開源的,對於實際使用時需要做必要的修改是非常困難的,這就是其最大的弊病。也許有經濟實力的團隊/公司購買源代碼可以解決這個問題。

 

第二個弱點就是它們主要適於非禁用JS腳本的場合,特別是慎用那些在禁用JS腳本時界面會變的很悲慘的控件。

三、總結WebUI選擇標准

我總結選擇WebUI包的標准,大概如下:

 

(1)開源代碼,最好免費:開源才能在必要的情況下方便地修改,這一點是非常必要的。如果不開源的話,那就非常需要購買到其源代碼,並且有能力作必要的修改。不免費資源,那是少數的有錢人的選擇。

 

(2)功能齊全,並且方便與其它外加控件不排斥:一套控件包,本身包含的功能需要比較齊全,在實際應用中基本夠用,很少需要再找其它插件。如果確實需要用到了其它另外的插件,也不應該發生技術排斥問題。

 

(3)必要的支持POST請求方式:需要具有HTTP請求的控件,必須支持可附帶參數的POST請求方式,就是為了滿足二點:一是發送較大數據量,二是數據安全要求。

 

(4)數據綁定必須靈活,可以處理后再綁定:絕對不能指望后端反饋回的數據格式在任何情況下都滿足前端控件要求,必須允許在數據返回與綁定之間插入必要的處理。

 

(5)可修改皮膚樣式,支持動態切換Theme:只有這樣才能為應用系統實現統一的界面風格,實現本WebUI包與可能需要的外擴插件界面風格的統一。

 

(6)足夠成熟、穩定:不應該在實際應用中發現BUG多多,給項目工作增加太多的負載。

四、如何執行WebUI選擇工作

軟件公司/團隊需要構建自己的組建庫,需要建設、選擇自己的WebUI庫,為此我闡述了自己的WebUI選擇標准,接下來就需要考慮如何具體的安排、部署執行這項工作,並且規划好達標的標准。

 

如果是公司的話,那人手多啊。第一步工作:可以安排1~3個熟悉javascript、jQuery、前端設計的技術老手,大約使用1-2周的時間(象easyUI需要的時間就這么多),參考網上資料,編寫一本技術手冊。當然,技術手冊就是從純技術角度去說明問題,而且要與通用技術資料有所卻別,就是要注重標准使用中比較關鍵的地方,或者缺陷,或者適用場合。第二步工作是:結合自己公司的產品系統架構,試驗、總結在界面層應用的規律,編寫界面模版與代碼模版。第三步工作是:把在產品系統架構中使用的方法,就是前面總結的界面模版與代碼模版,編寫進本公司產品架構教學手冊中去。顯然后面第二、三步工作比第一步更加趨近實際應用,也更加費勁了!

 

如果是個人的話,那么只能先做讀書筆記,特別注意記錄關鍵點、缺陷與使用場合;下一步試驗、總結自己的界面模版與代碼模版了。

五、一些參考資源

easyUI官網:http://www.jeasyui.com/

http://www.easyui.org.cn/

FineUI:http://fineui.com/,一套基於ExtJS的開源WebUI套件。

國產樹控件:http://www.ztree.me/v3/main.php#_zTreeInfo

中國jQuery插件網:

開源中國社區jQuery:http://www.oschina.net/p/jquerypp

慧都控件網:http://www.evget.com/

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM