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