UI開發的終極解決方案

呵呵，有點標題黨的意思，可是若是你正在尋找UI解決方案，你必定不會白來的。  雖然沒有直接開發前臺界面，可是好呆也看了這麼些年，碰到許多關於UI的問題： 

• UI中JS的引入與順序，JS合併的問題
• UI中css的引入與順序，CSS合併的問題
• UI中碰到性能問題時的影響範圍，好比：一個樹出現問題，要改動許多用到樹的地方
• 代碼重複的問題，一樣的內容在許多地方都有，若是要改動就要改動許多個地方
• 總體佈局調整困難的問題
• 開發效率的問題
• 執行效率的問題，前臺響應要求速度更快
• 集羣的問題
• 國際化的問題
• ...

這些問題直接帶來開發得是否夠快，系統是否夠健壯，系統是否易擴展，是否易維護等等。 
爲此，在Tiny框架中，咱們設計了整套的UI開發方案，與具體的技術實現無關，能夠兼容各類現有或將來的JS,CSS框架。同時，對於上述的問題，也都有良好的思考及解決方案，可謂是界面開發的終極解決方案。 
那麼，Tiny框架的UI解決方案是怎樣的呢？ 
1、規範化，若是沒有一個規範，那麼全部的期許都沒法落地。 
Tiny中規範中認爲全部共用的內容都是一個UI組件包。UI組件包，由一個Jar工程組成，UI組件名最後以Jar名爲單位進行發佈。UI組件包中包含了其所需的css/jss/gif/htm等等各類資源。同時有一個UI組件包描述文件，對UI組件包的結構、內容、以及對其它UI組件包的依賴關係。 
好比：咱們要複用JQuery，實際上很是簡單，在Maven工程結構中，在resources目錄中，放置全部的JQuery資源進來，而後編寫一個ui組件包描述文件。UI組件包就算開發完畢了。 
 

090443_cEg9_1245989.jpg (9.32 KB, 下載次數: 0)

下載附件

2015-5-27 21:03 上傳

 

  
再看看UI組件包描述文件 

1 2 3 4 5 6

<ui-components>     <ui-component name="Jquery" order="99">         <js-resource>/jquery/js/jquery-1.9.1.min.js</js-resource>         <js-debug-resource>/jquery/js/jquery-1.9.1.js</js-debug-resource>     </ui-component> < /ui-components>

UI組件名描述信息，包含UI組件名名稱，這裏是JQuery，引入順序，這裏指定是99，固然，在大多數狀況下，你都不須要指定它。這裏指定了調試和非調試模式下引入的JS。這樣，在實際運行時，能夠根據運行模式來統一進行引入，而這個過程再也不須要程序員干預。  OK，mvn install以後，第一個UI組件包就開發好了，很是簡單吧? 
2、引擎支持 
引擎要作內容就很是多了，這些js/css/img資源都是放在Jar包中的，在工程運行過程當中，須要訪問到這些文件，引擎提供了訪問Jar包中文件的能力，提供了css/js文件合併，提供根據運行模式引入調試或非調試JS或CSS的能力，提供文件緩衝以提速訪問，提供壓縮以縮小網絡傳輸量，等等等等。固然，這些都至關有難度，但這正是框架要解決的問題，對於程序員來講，與平時所作的內容惟一不一樣就是須要配置一個UI描述文件。用如此小的付出換來如此多的便捷，投入產出比仍是至關高的。 
3、模板化支持 
咱們都知道不論是html,xml,wml等等，實際上都是文本內容，都是一些標記語言。所以，均可以經過一些模板語言來進行生成，咱們常說的asp,aspx,jsp,php等等，實際上均可以認爲是模板語言。 
Tiny框架由於提供了良好的模塊化組織方式，展示層的內容也是能夠放在jar包中的，所以，再也不推薦使用jsp做爲展示層(在某些容器如：tomcat,jetty，也是能夠放入的，可是在Weblogic,Websphere等容器下，因爲其沒有遵循接口編程規範，而是使用了類型強轉，因此沒法進行處理)。另外，因爲jsp自身的特殊性，實際上它最後是以Servlet形式存在，因此可控性稍差，雖然經過處理能夠對其進行控制，可是投入產出比不高。因此，Tiny框架並不排斥，使用jsp，可是隻能放在war中使用。帶來的問題就是展示層沒法模塊化。（關於模板化的相關問題不在此說明，參見相關博文）。 
所以Tiny推薦採用模板語言,如：Velocity,FreeMaker等做爲展示層。Tiny內部實現複用了Velocity，可是實際上並無限制，你徹底能夠用其它模板語言作一樣的事情。 
Tiny的模板體系組織方式以下： 

• 支持多層文件結構
• 佈局文件統一用.layout擴展名結尾
• 頁面文件統一用.page擴展名結構
• 只有.page文件能夠被外部訪問，訪問方式有兩種.page或.pagelet

Tiny的模板渲染方式爲： 
若是訪問aa.pagelet，則會讀取aa.page中的文件內容，並用velocity引擎進行渲染後輸出 
若是訪問aa.page，則會讀取aa.page中的文件內容，並用velocity引擎進行渲染，可是此時會作佈局渲染 
好比：aa.page所中的路徑是/a/b/c/aa.page，佈局的渲染過程以下： 
查找/a/b/c/aa.layout是否存在？若是存在，則渲染，不然查找/a/b/c/default.layout，若是存在，則渲染。 

查找/a/b/aa.layout是否存在？若是存在，則渲染，不然查找/a/b/default.layout，若是存在，則渲染。 
查找/a/aa.layout是否存在？若是存在，則渲染，不然查找/a/default.layout，若是存在，則渲染。 
查找/aa.layout是否存在？若是存在，則渲染，不然查找/default.layout，若是存在，則渲染。 
經過上面的渲染機制，程序員有可能只寫了很是少的內容，可是經過分層佈局渲染，最後出來的效果也會很是豐富多彩。 
這樣說說，可能很難理解，咱們來看個例子，程序寫的例子是：demo.page。 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

#@homepage() #@faq("演示列表") #@servicesItem("idea") HelloWorld #end #@servicesItem("design") 四則運算 #end #@servicesItem("apps") 簡單數據維護 #end #@servicesItem("mobile") 站內郵件系統 #end #end #end

運行結果以下：    

094317_1z8J_1245989.jpg (82.58 KB, 下載次數: 0)

下載附件

2015-5-27 21:03 上傳

 

  可能看了有些雲裏霧裏，可是無論怎麼樣，你看到了，只要寫很是少的內容，就能夠出來很是多的結果。 經過佈局的支持，程序員不用管js，不用管css，不用管header,footer，不用管頁面結構，只用管本身的那點事兒，就能夠了。 國際化，可能對於小型我的網站來講，無所謂，可是對於大型企業來講是常常要用到的。TinyUI展示框架對國際化有良好支持，支持國際化資源方式國際化和國際化頁面國際化兩種方案。 國際化資源就很容易理解了，添加國際化資源文件，用國際化標籤進行引用便可。國際化頁面是指一樣訪問aa.page，在對其渲染時，會優先使用與訪問者相同的語言的文件進行渲染，好比：存在aa.page，aa.zh_CN.page，若是非zh_CN語言的人來訪問，渲染的是aa.page，zh_CN語言的人來訪問，渲染的是aa.zh_CN.page。兩種方式總有一款適合你。 小結： Tiny框架的前臺開發，基本上幫助你解決了全部的難題，可是對你的工做沒有任何限制，你能夠用你想用的任何展示框架，作任何基於腳本語言的展示。固然還遠遠不止這些，框架還提供了緩衝功能，只要增長一點配置，就能夠設定哪些頁面進行緩衝，緩衝多長時間，等等。更多的好處與便利，須要你親身體會。