360UI 界面框架 即QUI框架与EXT比较

Posted 2020-11-11 漠漠颜

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