UI開發(fā)的終極解決方案

呵呵，有點標題黨的意思，但是如果你正在尋找UI解決方案，你一定不會白來的。  雖然沒有直接開發(fā)前臺界面，但是好呆也看了這么些年，碰到許多關(guān)于UI的問題：

• UI中JS的引入與順序，JS合并的問題
• UI中css的引入與順序，CSS合并的問題
• UI中碰到性能問題時的影響范圍，比如：一個樹出現(xiàn)問題，要改動許多用到樹的地方
• 代碼重復(fù)的問題，同樣的內(nèi)容在許多地方都有，如果要改動就要改動許多個地方
• 整體布局調(diào)整困難的問題
• 開發(fā)效率的問題
• 執(zhí)行效率的問題，前臺響應(yīng)要求速度更快
• 集群的問題
• 國際化的問題
• ...
  

這些問題直接帶來開發(fā)得是否夠快，系統(tǒng)是否夠健壯，系統(tǒng)是否易擴展，是否易維護等等。
為此，在Tiny框架中，我們設(shè)計了整套的UI開發(fā)方案，與具體的技術(shù)實現(xiàn)無關(guān)，可以兼容各種現(xiàn)有或未來的JS,CSS框架。同時，對于上述的問題，也都有良好的思考及解決方案，可謂是界面開發(fā)的終極解決方案。
那么，Tiny框架的UI解決方案是怎樣的呢？
一、規(guī)范化，如果沒有一個規(guī)范，那么所有的期許都無法落地。
Tiny中規(guī)范中認為所有共用的內(nèi)容都是一個UI組件包。UI組件包，由一個Jar工程組成，UI組件名最后以Jar名為單位進行發(fā)布。UI組件包中包含了其所需的css/jss/gif/htm等等各種資源。同時有一個UI組件包描述文件，對UI組件包的結(jié)構(gòu)、內(nèi)容、以及對其它UI組件包的依賴關(guān)系。
比如：我們要復(fù)用JQuery，實際上非常簡單，在Maven工程結(jié)構(gòu)中，在resources目錄中，放置所有的JQuery資源進來，然后編寫一個ui組件包描述文件。UI組件包就算開發(fā)完畢了。
 
再看看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，當(dāng)然，在大多數(shù)情況下，你都不需要指定它。這里指定了調(diào)試和非調(diào)試模式下引入的JS。這樣，在實際運行時，可以根據(jù)運行模式來統(tǒng)一進行引入，而這個過程不再需要程序員干預(yù)。  OK，mvn install之后，第一個UI組件包就開發(fā)好了，非常簡單吧?
二、引擎支持
引擎要做內(nèi)容就非常多了，這些js/css/img資源都是放在Jar包中的，在工程運行過程中，需要訪問到這些文件，引擎提供了訪問Jar包中文件的能力，提供了css/js文件合并，提供根據(jù)運行模式引入調(diào)試或非調(diào)試JS或CSS的能力，提供文件緩沖以提速訪問，提供壓縮以縮小網(wǎng)絡(luò)傳輸量，等等等等。當(dāng)然，這些都相當(dāng)有難度，但這正是框架要解決的問題，對于程序員來說，與平時所做的內(nèi)容唯一不同就是需要配置一個UI描述文件。用如此小的付出換來如此多的便捷，投入產(chǎn)出比還是相當(dāng)高的。
三、模板化支持
我們都知道不管是html,xml,wml等等，實際上都是文本內(nèi)容，都是一些標記語言。因此，都可以通過一些模板語言來進行生成，我們常說的asp,aspx,jsp,php等等，實際上都可以認為是模板語言。
Tiny框架因為提供了良好的模塊化組織方式，展現(xiàn)層的內(nèi)容也是可以放在jar包中的，因此，不再推薦使用jsp作為展現(xiàn)層(在某些容器如：tomcat,jetty，也是可以放入的，但是在Weblogic,Websphere等容器下，由于其沒有遵循接口編程規(guī)范，而是使用了類型強轉(zhuǎn)，所以無法進行處理)。另外，由于jsp自身的特殊性，實際上它最后是以Servlet形式存在，所以可控性稍差，雖然通過處理可以對其進行控制，但是投入產(chǎn)出比不高。所以，Tiny框架并不排斥，使用jsp，但是只能放在war中使用。帶來的問題就是展現(xiàn)層無法模塊化。（關(guān)于模板化的相關(guān)問題不在此說明，參見相關(guān)博文）。
因此Tiny推薦采用模板語言,如：Velocity,FreeMaker等作為展現(xiàn)層。Tiny內(nèi)部實現(xiàn)復(fù)用了Velocity，但是實際上并沒有限制，你完全可以用其它模板語言做同樣的事情。
Tiny的模板體系組織方式如下：

• 支持多層文件結(jié)構(gòu)
• 布局文件統(tǒng)一用.layout擴展名結(jié)尾
• 頁面文件統(tǒng)一用.page擴展名結(jié)構(gòu)
• 只有.page文件可以被外部訪問，訪問方式有兩種.page或.pagelet
  

Tiny的模板渲染方式為：
如果訪問aa.pagelet，則會讀取aa.page中的文件內(nèi)容，并用velocity引擎進行渲染后輸出
如果訪問aa.page，則會讀取aa.page中的文件內(nèi)容，并用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，如果存在，則渲染。
通過上面的渲染機制，程序員有可能只寫了非常少的內(nèi)容，但是通過分層布局渲染，最后出來的效果也會非常豐富多彩。
這樣說說，可能很難理解，我們來看個例子，程序?qū)懙睦邮牵篸emo.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") 簡單數(shù)據(jù)維護 #end #@servicesItem("mobile") 站內(nèi)郵件系統(tǒng) #end #end #end

運行結(jié)果如下：    
可能看了有些云里霧里，但是不管怎么樣，你看到了，只要寫非常少的內(nèi)容，就可以出來非常多的結(jié)果。
通過布局的支持，程序員不用管js，不用管css，不用管header,footer，不用管頁面結(jié)構(gòu)，只用管自己的那點事兒，就可以了。
國際化，可能對于小型個人網(wǎng)站來說，無所謂，但是對于大型企業(yè)來說是經(jīng)常要用到的。TinyUI展現(xiàn)框架對國際化有良好支持，支持國際化資源方式國際化和國際化頁面國際化兩種方案。
國際化資源就很容易理解了，添加國際化資源文件，用國際化標簽進行引用即可。國際化頁面是指同樣訪問aa.page，在對其渲染時，會優(yōu)先使用與訪問者相同的語言的文件進行渲染，比如：存在aa.page，aa.zh_CN.page，如果非zh_CN語言的人來訪問，渲染的是aa.page，zh_CN語言的人來訪問，渲染的是aa.zh_CN.page。兩種方式總有一款適合你。
小結(jié)：
Tiny框架的前臺開發(fā)，基本上幫助你解決了所有的難題，但是對你的工作沒有任何限制，你可以用你想用的任何展現(xiàn)框架，做任何基于腳本語言的展現(xiàn)。當(dāng)然還遠遠不止這些，框架還提供了緩沖功能，只要增加一點配置，就可以設(shè)定哪些頁面進行緩沖，緩沖多長時間，等等。更多的好處與便利，需要你親身體會。