【ACCESS精品源码栏目提醒】:网学会员为需要ACCESS精品源码的朋友们搜集整理了关于部门引入ExtJS前台框架的评估报告 - 其它资料相关资料,希望对各位网友有所帮助!
关于部门引入 ExtJS 前台框架的评估
报告 孙权 2010-11-7 引 --- 第一只“出海”的 YUI-Ext 只是作者 Jack 打算对基于 BSD 协议的 YahooUI库进行自定义的扩展,但后来一度风头盖过其父辈 YUI,足以说明大家对它的热情,很多人把它投入项目人并不十分了解它。
分析人士打了一比喻:就好比尚未谋面, 并不了解一个人的家庭、教育、品行等背景,只因为他有一副精致漂亮的外观,就对其陷入了疯狂的倾慕之中。
因此分析人士建议,在投入项目前,要认真仔细地了解 EXT 的内在原理和与其他 Ajax 库不同地方。
真正接触到 ExtJS 框架是从去年在吉林 BSS4.0 上线时,看到他们固网的社区系统,被其炫丽的界面深深吸引,进入系统后没感觉到是浏览器打开的普通 HTML 页面,分明就是一套风格独特而统一的桌面软件。
出于好奇,之后也下载了官方的类库和
源码包尝试体验了一把,感觉技术是 JavaScript,但理念和思想却汲取了众家之长,几乎将前端 html及 css 要完成的活都交由 JavaScript 来完成了,而且借用了很多 Java 等面向对象语言的特点,将前端的 JS 和 Ajax 玩转到了极致。
犹如开创了一套独特编码风格和界面风格的语言。
通过近几天的体验和查阅网络上的资料,发现项目中引入 ExtJS 确实是需要一番斟酌的事情。
其优缺点并存,业界在关于其取舍上,伴随其版本升级成长也没有停止过争。
由于没有真实的 ExtJS 项目的实施经历,仅凭着对前端技术一点了解,在以下几个方面做了一些思考和分析:一、 ExtJS 运行机制 结合 电信类软件开发流程,看其充当的角色(角色定位) ExtJs 初期仅是对 Yahoo UI 的对话框扩展,后来逐渐有了自己的特色,深受程序员的喜爱。
发展至今,Ext 除 YUI 外还支持 Jquery、Prototype 等的多种 JS 底层库,让大家自由地选择。
开发理念脱胎、成型于 Yahoo 组件库 YUI 和 Java 平台上 Swing 两者,并为开发者屏蔽了大量跨浏览器方面的处理。
支持多平台下的主流浏览器 InternetExplorer 6 FireFox 1.5 PC Mac Safari2、Opera9。
在使用的厂家包括 IBM、Adobe、Cisco 和更多。
与其他面向组件的服务器端框架不同,ExtJS 是基于纯客户端的前台组件框架。
通过参考 Java Swing 映射组件、布局管理的机制来组织可视化组件,而这一切都由 JS 来完成,最终解析成 html 和 css 等,达到丰富的界面表达效果对 html 已有的组件进行了模拟美化、属性增强和补充扩展。
比如 html 没有提供树型控制组件、多选下拉选项框、日期选择组件、文本编辑域、定制信息警示框等。
还增加了很多常用的功能组件,比如:二维表格动态展示面板、各种图表生成组件、下载进度条组件等。
同时,利用 Ajax 请求,由后端数据源或应用程序准备特定格式的文本型数据,如:json、xml 等,达到响应客户端事件、与后台数据交互、异常处理等目的。
下图
演示了ExtJS 在工作流程中所处的位置: APP Server Browser Ajax request Interface HTML getpost Class CSS Controller DataBase Bean Filter DAO … … Text or Binary response jsonhtml
xml JavaScript ExtJS 由于其封装性的特点,屏蔽了不同浏览器的差异,形成了比较独立的 UI 组件模型。
css无论从 UI 界面、 样式的应用上,还是前端表单校验上,还是与后台交互方式上,ExtJS都作了充分的努力。
相对来说,ExtJS 要比开发者直接针对 DOM、W3C 对象模型开发 UI 组件轻松也给大型 B/S 架构系统的富媒体表现提供了可能。
综上知悉,ExtJS 是一个与后台技术无关的前端 Ajax 框架!使用 ExtJS,就代表了 fully Ajax,应该说是比较惯切了 Ajax 的思想,完全适合以数据为中心的电信类的软件应用。
二、 ExtJS 项目欣赏 结合 电信类软件项目特点,看其用户接受度(市场预测) ExtJS 框架自发布之日,就给软件开发者带了很多惊喜。
经过几年的发展和积累,ExtJS 已涵盖美国、日本、中国、法国、德国等全球范围的用户,深受开发者的追捧。
我收集了一些用 ExtJS 框架开发的不同行业的管理软件截图,以供参考与学习: 1. 吉林网通市场营销系统(内部称固网社区系统)2. 广西联通彩信内容营销专用群发平台3. 自动化办公系统4. 人力资源管理系统5. 教学管理系统6. 房产中介管理系统7. 国外某 ERP 系统8. 图书
管理系统 9. 网络硬盘管理系统 对于开源项目或小型应用,很多人在一些花哨的功能关心的多一些,比如一些控件,炫丽的界面皮肤等,觉得能够完成某些
常用功能就可以了,而在稳定性方面和性能方面的考虑一般不够充分。
但企业级应用是个严肃的问题,特别是一些核心系统和竞争激烈的商业产品。
比如电信类项目:“综合营销管理系统”,从客户管理、营销管理、渠道管理、系统管理到报表管理等,麻雀虽小五脏俱全。
虽然可以有强大的服务器、充足的
网络带宽、容易说服去升级的客户端机器、Oracle 数据库等硬件资源的支持,但如果作为独立推广的项目,为了赢得市场,被公司乃至市场认可,在炫丽的外观、简便直观的操作、出色的性能、良好的用户体验等方面确实都需要做一些准备。
ExtJS 就是在 B/S 架构系统越来越流行、旧有的开发模式效率低下、死板的 UI 界面和组件难于满足应用的背景下催生的。
通过上面的案例截图,我们也可以看到,ExtJS 在很多领域都得到了普及和应用。
其外形酷似视窗界面的操作系统,令人叫绝!堪比 C/S 架构
软件的表现,其在灵活性和丰富度上的表现也是不言而喻。
但 ExtJS 毕竟只是基于 JS 也就是依赖于浏览器的框架,它的缺陷也有很多。
比如它必定是以无状态的 http 网络协议为传输渠道,是以服务器端产生数据配合为前提,体积过大的预加载类库,客户端浏览器因依赖 JS 来维护数据包括布局及组件的数据会产生内存溢出等常见故障。
当然如果有稳定的网络环境,不会被开发人员滥用的 Ajax 请求,加上数据的缓存优化,充分的客户端异常处理,合理的
系统架构等,那么我想由 ExtJS 开发的系统,给人的第一印象,以及在人性化和易用性等方面都会博得高分,从而赢得市场的认可。
三、 ExtJS 风格特色 结合 电信类软件系统架构,看其前后台整合(技术分析) 通过一段时间的学习和开发体验,在技术上,我在五个方面分析如下: 1.在语法上,先看看 JavaScript:JavaScript 最初是受 Java 启发而开始设计的,而且设计的目的之一就是“看上去像 Java2”,因此语法上有很多类似之处,许多名称和命名规范也借自
Java。
但是实际上,JavaScript 的主要设计原则源自 Self 和 Scheme3,它与 Java 本质上是不同的。
它与 Java 名称上的近似,是当时网景公司为了营销考虑与Sun 公司达成协议的结果。
其实从本质上讲 JavaScript 更像是一门函数式编程语言.而非面向对象的语言。
语法非常自由,同样的功能可能不同
程序员写出来的代码完全不同。
我们可将 ExtJS 当作一种类 JS 的 Ajax 应用的新语言来理解。
ExtJS 完全由JavaScript 封装发展而成。
我们都知道,在复杂关系模型和大量数据组织的时候,面向对象的概念引入带来了很多便利。
所以 ExtJS 从语法上尝试改变并发展了 JavaScript。
模拟了很多 Java 等面向对象语言的特点,提出了 class、package、extend、private、exception、listener、namespace 等。
所以相比于 JS,ExtJS 在代码组织、团队开发、规范统一编码风格上提供了可能。
2.在应用场景中,它模拟了一些视窗界面操作系统的优点,还发展了很多数据表现的能力。
项目开发实施的过程中,开发人员需要对 JS 有深刻的理解,对 HTML 的 dom 结构有所了解。
相对而言,弱化了一些 CSS 方面要求。
甚至要有一些美工基础才能将用户带到某一场景中体验快感,而不是体验乏味。
3.在 UI 组件和布局上,它提供了丰富的成熟的基础控件和多种布局
方案。
在电信类B/S 架构的系统中完全够用了。
和上面提到的一样,我们已经被 ExtJS 框住,虽然有 ExtJSDesigner 这样的可视化布局开发工具,但是开发人员还是必须对它的“直系祖辈”表示好感,还要对一些“传统封建旧有的思想”表示反抗,否则 ExtJS 还是不太好驾驭的。
比如:我们使用的 WADE2 框架,是由基于后端标签,面向组件的 Java 框架 Tapestry发展而来。
并且大量使用了 iframe 用来放置独立的页面,一层套一层,来支持页面级的标签化窗口,用 iframe 来临时存储数据,甚至用它来实现布局!实践证明,在客户端硬件升级迅速,价格低廉的今天,这一技术在使用的过程并没有想像的可怕,还挺顺畅,而且它还变相地做到了模块独立开发。
但是,在使用 ExtJS 框架时,这种 iframe 是万万不能多用和烂用的,想像一下,一个 iframe 就相当于一个新开的浏览器进程,每一个 iframe 都有一份独立的内存空间,如果 ExtJS 要引用 10 个 iframe 页面,其中都要引入 ExtJS 类库,一个就要吃掉你几百 K甚至几 M 的内存。
那将不堪设想。
解决办法就是 DIV,也就是使用 ExtJS 的 TabPanel,它的原理是使用一个大的页面,共享一份内存,而将代码解释成 DIV 插入 html 的 DIV 中。
但是,这又有一个问题,如果一个系统有 1 千个功能点,是不是要将 1000 个功能点所涉及到的 JS 代码都放在一个文件中?是不是 ExtJS 要在同一个页面把这 1 千个功能点的 JS 代码都要加载进来?当然不可以!所以这就需要改变以往的思维方式,想办法组织代码(不组织好了,一个地方出错,整个页面都出不来了),想办法动态加载 JS 代码(非必须的不要加载)。
所以,这也带来了一些学习成本和维护成本的增加。
4.在工作机制上,上面也提到了,ExtJS 等于是将 html、css 以及后端的像 JSP 标签完成的任务都承担了下来。
将与后台
通信的数据格式都统一好了,与后台技术无关,尽情地在浏览器上玩吧,所以极易整合。
5.在天生的缺陷上,必须做到避重就轻,保持良好心态,积极面对,合理权衡。
两害相权取其轻嘛。
由于我对 ExtJS 的理解还只是停久在见过几个系统,看过一些 example和视频教程,不成系统地搭建了一个布局模型而已,也没有真正的大型实施经历,不太好对部门是否引入 ExtJS 进行断言。
所以特此找到一篇关于 ExtJS 是否适合企业级开发的讨论供参考
学习: 《ExtJS 是否适合企业级开发》 企业级 Web App 的设计和开发是一件很困难的事情,我们衡量一个技术架构是否合适通常会从以下几个方面来考虑,按照优先级,他们是:1、必须开源而且是商业友好的。
2、技术已经非常稳定,并且有大量的成功案例。
3、
文档资源必须非常丰富,社区活跃度要高。
4、性能和兼容性一定要好,适用于所有主流的应用环境。
5、易学易用。
可以说,与外面的世界相比,我们经常是慢一拍的。
也许大家很难相信,我们直到现在仍然在使用 Struts1.1 JDK1.4,仍然在支持着 IE6 2600。
事实上,作为大型的企业级 Web App,一套架构用上 3、5 年不变是太正常不过的事。
上百人的开发团队,每一次技术革新都好像是一场革命。
因此,从这个角度上来看,Ajax 相对于企业级 Web App 来讲,的确还稍嫌年轻。
熟悉 Ajax 设计模式的开发人员寥寥无几,XHR 任何未知的安全漏洞和兼容性问题,对于我们来说都是致命的隐患。
因为我们的系统承载的不是一些无关紧要的内容,而是客户的敏感信息。
UI 设计最重要的一点要求就是,要尊重用户的数据,数据的损失是我们任何人都承担不起的。
因此,对于 Ext,我个人非常欣赏这个优秀的 UI 组件库,一方面是源于它优秀的架构设计(毋庸置疑,Ext 是目前架构设计最接近操作系统 UI 架构设计的一套纯 JS 组件库) ,它不仅充分利用了CSS 的先天技术优势(可以分层,任意设置 Padding,不用再使用蹩脚的九宫格来
设计 Border 样式) ,而且完美的将操作系统 UI 架构设计方式改用 JS 来实现,使得我甚至没法将它拆分做到按需加载(很可能一个 Dialog 就会用到所有的 Widgets,这还能怎么拆呢?我需要的是 Ext-All) ,没法拆分,正说明了 Ext 架构的优秀和完美。
另一方面,Ext 优异的性能使我感叹一套纯 JS 的组件竟然有如此高的响应速度,甚至可以媲美本地 UI 库的响应速度,经过实际测试,Ext 的 Grid 竟然可以在 10s 之内显示出 6500 条记录,这么好的性能是它吸引我的另一个重要原因。
再看 Ext 的 API 和 Demo,丰富而规范,社区活跃度又非常的高,我很欣喜,要知道,作为企业级 WebAPP,有了 Tag 这一层的解耦,最容易也是最常革新的就是表现层用户界面。
如果引入了 Ext,系统的可用性和易用性将有大幅提升,Ext 的外观就是按照 Theme 的思想设计开发的,这一点也为我们的产品客户化能力打下了坚实的基础。
此后,我们又详细的测试了 Ext Selector 的性能(
查询的效率是最影响整体性能的部分——就好像SQL,性能优化往往集中于此) ,发现其优异的性能和兼容性更是其它 JS 库望尘莫及的。
我们的选型还差最后一步,那就是,挑系统中典型页面做开发,看看实际应用起来到底怎么样。
意料中的,问题接踵而至。
首先,新表现层架构的出发点有两条:首先,我们要保证其对于用户来讲是人本的,用户使用我们的软件完成日常
工作应该更加愉快而高效。
其次,我们要保证其对于开发人员来讲是人本的,开发人员不需要了解我们引入了 Ext 这个 lib,甚至开发人员都不需要了解 JS,CSS 和 HTML,他们只需要按照规格说明书使用基础开发平台提供的 UI 库中的控件和组件就可以了。
问题一:Ext 优秀的控件和丰富的交互方式已经完全的满足了我们第一个目标,那就是,对用户来讲是人本的,那么对于开发人员呢?首先,我们看看 Ext 的 Grid,基本上就是 4 种数据获取方式:From mark,Array,JSON,XML。
首先看看 Array,肯定不行(给你一组 Array,鬼才知道里面的数据都代表什么)。
再看 XML,还是不行,为什么不行?性能和兼容性问题。
再看 JSON,貌似是我们最佳的选择,还是不行,为什么不行?用 JSON,就意味着抛弃 Struts1.1(2.0 或许可以) ,改动太大,成本和风险都不是我们可以承担的。
貌似就剩下了个 From mark,不用也得用了。
类似的问题也出现在其他的 Widgets 上,归根结底,问题的核心源于 Ext 完全的 Ajax 化,这一设计方向与我们相距甚远,这是引发矛盾的主要原因。
这让我们陷入两难的境地,用 Ext 的话,势必要用异步系统的设计方式来重新构建整个应用,对设计和开发人员的要求太高,工作量太大,而且,一旦错误的使用,造成的后果往往都非常严重并难以解决(例如数据同步和并发处理等问题) 。
如果不用 Ext 的异步,那还不如干脆不用 Ext。
用异步不行,不用异步还是不行,这是第一个
问题。
问题二:Ext 优秀的架构使得 Ext 的封装达到了前所未有的高度,用 Swing 来描述界面也不过如此,Ext 通常的开发方式是,一个
HTML 文件对应一个 JS,JS 负责初始化 HTML。
那么好,我们这个JS 要怎么开发呢?为了保证其对于开发人员是人本的,我们只能用 JSP tag 再进行一次封装?难道只封几行 js 脚本么?那还要这样的 Tag 干吗。
如果不封装,让开发人员都来学习 Extjs?同样不可行。
纵使开发人员人人会写 Js,Ext 为了显示做出的各类逻辑在 JS 中一目了然,把 JS 写在
JSP 中会暴露,并且违背我们的开发规范(HTML 中不能出现 JS 代码,国外的用户尤其重视这类安全问题) 。
那就只能引入外部 JS 文件了,引入外部文件的话,如此大量的 JS 文件是我们无法接受的,并且,非常不利于维护和升级(如果 Ext 心血来潮大量修改 API,我就死定了,因为我们的系统有近 3000 的 。
用 Ext 就没法封 Tag,不封 Tag 还没法用 Ext,这是第二个问题。
JSP 页面) 问题三:Ext 的体积对于我们而言太过庞大,很有可能竞争对手会针对这一点对我们造成致命一击。
用户大多不是很了解技术,他们提供的性能指标要求很多也是根本无法实现的,因此,性能的差异会让我们在竞争中败下阵来。
通过极限
压缩的 Ext 仍然有 109kb,并且无法按需加载,这是第三个问题。
问题四:Ext 的控件太过丰富,丰富到让我们欣喜若狂,从而迷失了方向,我们一边看着绚丽的demo 一边说:“layout 可以用在某某地方,Messagebox 可以用在某某地方,这个也有用,那个也很强”,的确,Ext 所有的 Widgets 我们都会用得上,并且会发挥他们最大的作用。
直到慢慢冷静下来,我们苦笑,如果果真如此,这还是 Web App 么?我们把这样复杂的应用构建在 Web 上,为的是什么?为的就是 Web 的灵活和开放。
我们不仅要保证应用在宽带环境的可用性,也要使其在窄带环境下同样可用。
不仅要保证应用在 PC 上完美运行,也要考虑其在 PDA 和手机上运行的可行性。
我们握在手中的利剑是开放和灵活,放弃了这一点,也就意味着放弃了 Web。
我们在 Ext 的优秀面前迷失了方向,甚至忘记了“根据需求来选择技术而不是根据技术来决定需求”这一最基本的设计原则,这是第四个问题。
冷静下来,我们发现,其实自己需要的只是所见即所得的客户端校验,只是 Grid 的 Lock Header功能,只是想用 Iframe 来代替恼人的 window.open,一些基本的 DD 和 Ajax 支持,仅此而已。
一个 Mootools 就足以满足我们所有的需求,尘埃落定,我们终于完成了 JS 基础库选型。
对于广大 UI 设计师和前端架构师,我想发表一些拙见来给各位提个醒。
永远不要在技术面前迷失了方向,只有最适合应用的技术,而没有最适合技术的应用,切记! 更多讨论: http://www.javaeye.com/topic/90148 http://www.javaeye.com/topic/133373 http://www.javaeye.com/topic/139323四、 ExtJS 发展现状 结合 电信类软件应用需求,看其投入和产出(成本评估) 1998 年前后,允许客户端脚本发送 HTTP 请求XMLHTTP的第一个组件由 Outlook WebAccess 小组写成。
该组件原属于微软 Exchange Server,并且迅速地成为了 InternetExplorer 4.0 的一部分。
2005 年初,许多事件使得 Ajax 被大众所接受。
Google 在它著名的交互应用程序中使用了异步通讯,如 Google 讨论组、Google 地图、Google
搜索建议、Gmail 等。
我想,与 JQuery 等框架产生的背景和年份几乎相同,也是正因为从一个小小的 Ajax 概念流行,点燃了大家的灵感吧。
回顾一下 ExtJS 的发展历程: 1、在 2006 年初 ,Jack Slocum杰克斯洛克姆 就一套公用设施扩建为 YahooUser Interface YUI 库而工作。
这些扩展很快组织成一个独立的库代码并以“yul-extquot的名义下发布。
2、 在 2006 年秋天Jack 发行了版本为 0.33 的 yui-ext而最终被证明为最后版本的代码,根据这名字(下开放
源代码 DSB 许可)。
在年底之前,这个库已大受欢迎 名字被简化为 Ext,反映了它作为一个框架的成熟和独立。
该公司成立于 2007 年初,Ext 现在为双执照,使用 LGPL 和一个商业执照。
3、在 2007 年 4 月 1 日,发布 1.0 正式版。
4、官方在 2009 年 4 月 14-16 日的首次 Ext Conference 中发布了 Ext 的 3.0 RC 版本。
5、2009 年 5 月 4 日,Ext 的 3.0 版本发布。
6、2010 年 1 月 8 日,ExtJS 已发展涵盖美国、日本、中国、法国、德国等全球范围的用户,发布版本为 Ext-3.2.0 7、2010 年 6 月 15 日,当开发者访问著名的 JavaScript 库 ExtJS 网站,会发现自己被重导向到另一个不熟悉的网址和界面 sencha。
原来,ExtJS 项目已经与触摸屏代码 后两个项目的创始人 David Kaneda 和 Dmitry库项目 jQTouch 和 SVG 处理库 Raphael 合并,Baranovskiy 也将加入 ExtJS。
此举是 ExtJS 为了应对 HTML5 等新趋势,加强丰富图形和触摸屏功能的重要举措。
每一个大版本的改进,都给前台开发提供了无尽的遐想。
然而我们电信类软件的应用,基本也是代表着前沿技术的推动者。
当下电信行业间的激励竞争中,我们的客户为了抢占市场,也是不惜代价寻觅能够为自己增收并且提高效率的系统软件。
客户如此,又何况我们呢:) 所以我在写这份报告的第一时间,就对投入到新技术中去的成本问题,分阶段做了一下简单的成本投入级别评估: 研发人员学习及培训成本(高) UI 设计、组件封装及架构成本(高) 前后台整合开发成本(中) 沟通成本(低) 测试与实施成本(低) 客户培训成本(低) 维护与扩展升级成本(低) 同行竞争与业务竞标成本(低) 由此可以看出引入 ExtJS 框架,前期的投入将会相对要高。
不过好在前期的投入是集中性的。
一次性投入,长期获益。
这种倒金字塔式的成本投入.