呵呵，有点标题党的意思，但是如果你正在寻找UI解决方案，你一定不会白来的。

虽然没有直接开发前台界面，但是好呆也看了这么些年，碰到许多关于UI的问题：

1. UI中JS的引入与顺序，JS合并的问题
2. UI中css的引入与顺序，CSS合并的问题
3. UI中碰到性能问题时的影响范围，比如：一个树出现问题，要改动许多用到树的地方
4. 代码重复的问题，同样的内容在许多地方都有，如果要改动就要改动许多个地方
5. 整体布局调整困难的问题
6. 开发效率的问题
7. 执行效率的问题，前台响应要求速度更快
8. 集群的问题
9. 国际化的问题
10. ...

这些问题直接带来开发得是否够快，系统是否够健壮，系统是否易扩展，是否易维护等等。

为此，在Tiny框架中，我们设计了整套的UI开发方案，与具体的技术实现无关，可以兼容各种现有或未来的JS,CSS框架。同时，对于上述的问题，也都有良好的思考及解决方案，可谓是界面开发的终极解决方案。

那么，Tiny框架的UI解决方案是怎样的呢？

一、规范化，如果没有一个规范，那么所有的期许都无法落地。

Tiny中规范中认为所有共用的内容都是一个UI组件包。UI组件包，由一个Jar工程组成，UI组件名最后以Jar名为单位进行发布。UI组件包中包含了其所需的css/jss/gif/htm等等各种资源。同时有一个UI组件包描述文件，对UI组件包的结构、内容、以及对其它UI组件包的依赖关系。

比如：我们要复用JQuery，实际上非常简单，在Maven工程结构中，在resources目录中，放置所有的JQuery资源进来，然后编写一个ui组件包描述文件。UI组件包就算开发完毕了。

再看看UI组件包描述文件

<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组件包就开发好了，非常简单吧?

二、引擎支持

引擎要做内容就非常多了，这些js/css/img资源都是放在Jar包中的，在工程运行过程中，需要访问到这些文件，引擎提供了访问Jar包中文件的能力，提供了css/js文件合并，提供根据运行模式引入调试或非调试JS或CSS的能力，提供文件缓冲以提速访问，提供压缩以缩小网络传输量，等等等等。当然，这些都相当有难度，但这正是框架要解决的问题，对于程序员来说，与平时所做的内容唯一不同就是需要配置一个UI描述文件。用如此小的付出换来如此多的便捷，投入产出比还是相当高的。

三、模板化支持

我们都知道不管是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。

#@homepage()#@faq("演示列表")#@servicesItem("idea")HelloWorld#end#@servicesItem("design")四则运算#end#@servicesItem("apps")简单数据维护#end#@servicesItem("mobile")站内邮件系统#end#end
#end

运行结果如下：

可能看了有些云里雾里，但是不管怎么样，你看到了，只要写非常少的内容，就可以出来非常多的结果。

通过布局的支持，程序员不用管js，不用管css，不用管header,footer，不用管页面结构，只用管自己的那点事儿，就可以了。

国际化，可能对于小型个人网站来说，无所谓，但是对于大型企业来说是经常要用到的。TinyUI展现框架对国际化有良好支持，支持国际化资源方式国际化和国际化页面国际化两种方案。

国际化资源就很容易理解了，添加国际化资源文件，用国际化标签进行引用即可。国际化页面是指同样访问aa.page，在对其渲染时，会优先使用与访问者相同的语言的文件进行渲染，比如：存在aa.page，aa.zh_CN.page，如果非zh_CN语言的人来访问，渲染的是aa.page，zh_CN语言的人来访问，渲染的是aa.zh_CN.page。两种方式总有一款适合你。

小结：

Tiny框架的前台开发，基本上帮助你解决了所有的难题，但是对你的工作没有任何限制，你可以用你想用的任何展现框架，做任何基于脚本语言的展现。当然还远远不止这些，框架还提供了缓冲功能，只要增加一点配置，就可以设定哪些页面进行缓冲，缓冲多长时间，等等。更多的好处与便利，需要你亲身体会。