http://www.open-open.com/lib/view/open1350386395227.htmljavascript
http://www.ibm.com/developerworks/cn/web/1210_wangzh_extjsmvc/index.htmlcss
Ext JS 4 简介html
Ext JS 4 目前是 Sencha 的产品,4.x 的正式版本号是 4.0.7。Ext JS 4 提供商业版本,但若是您的项目是开源的,则能够无偿使用 Ext JS 4。Ext JS 的论坛目前很是活跃;Ext JS 还在不但地升级改进,据 Sencha 官方统计,使用 Ext JS 的开发者数目在一百万以上。前端
Ext JS 4 与以前版本的比较java
渲染效率提升程序员
全部类都通过调优,包括最影响渲染效率的布局引擎重写。web
命名空间算法
命名空间是 Ext JS 4 的 MVC 的基础,自此 Ext JS 类能按做用域分开存放了。.NET 或 Java 开发者应该熟悉命名空间带来的好处:命名空间让全类名映射到类文件路径变得很容易,将类按做用域分文件夹存放使得类更容易管理。以 MVC 为例,Ext JS 类将按做用域:模型、视图和控制器分为三类,分别存放于对应文件夹中。数据库
按需加载类设计模式
清单 1. 按需加载类的例子
1 |
Ext.define( 'MyNamespace.Cat' , { |
2 |
requires: [ 'MyNamespace.BabyCat' ], |
3 |
giveBirth: function () { |
4 |
// 实例化 BabyCat 以前,必须加载 BabyCat 的类定义。经过设置“requires”属性,能实现类的按需加载 |
5 |
return new MyNamespace.BabyCat(); |
6 |
} |
7 |
}); |
这 个特性实际上是基于全新设计的类系统的,详见下面的小结。不一样于先前版本:即便用到 Ext JS 框架中不多一部分单元,Ext JS 也会加载全部的框架,按需加载只加载须要的类。所以按需加载类为 JS 优化和减小内存消耗提供了一个有效途径。Sencha 为此还提供了 SDK 工具对 JS 代码进行 Minify,在部署前运行 minify 对 JS 代码最小化后,将获得一个最小 JS 集合。
全新的类系统 因为篇幅的限制,具体请参阅官方文档 Class System,其中详细描述了怎样用 Ext JS 4 的方式定义类,以及错误处理和调试
MVC 架构 用 Ext JS 4 以前的版本写大的客户端应用,您会发现愈来愈“难”,您会发现有四难:难写、难读、难维护、难扩展。随着愈来愈多的功能添加进来,代码愈来愈失控,一个 JS 文件几千行可能很广泛了,固然也不排除代码组织得很好易于扩展的状况,但这些都须要开发者付出额外的开发代价去组织本身的架构。从 Ext JS 4 开始有了本身的 MVC 架构,开发者没必要再付出这种额外的代价也能写出漂亮的代码。Ext JS 4 对 MVC 有本身的定义,如下定义来自 Sencha 官网的文档:
Model
:一组字段的集合以及它们对应的数据(例如:“User”类 model 有“username”和“password”字段),经过 data 包 (store,proxy 等 )Model 能序列化本身,并能经过关联关系从一个 Model 导航到另外一个 Model。Model 的工做原理相似 Ext JS 3 中的 Record 类,一般结合 Store 为表格控件或其它控件提供显示数据。
View
:任意组件,如 Grid, Tree 和 Panel 都是视图。
Controllers
:在这里写全部的逻辑代码:如渲染视图、实例化模型、加载并初始化其它控制器等。
MVC 的概念很简单,但实际项目中运用 MVC 模式将代码组织起来会不会没那么简单?答案在后面的章节“介绍开发 Ext JS4 的利器 : Sencha Architect 2”中,该章节会详细介绍怎样用该工具开发 MVC 模式的 Ext JS 程序。
为何要运用 MVC 架构
MVC 的概念
MVC 是一种成熟的软件设计模式。MVC 模式的目的是实现一种动态的程序设计,使后续对程序的修改和扩展简化,而且使程序某一部分的重复利用成为可能。除此以外,此模式经过对复杂度的简化,使程 序结构更加直观。软件系统经过对自身基本部份分离的同时也赋予了各个基本部分应有的功能。专业人员能够经过自身的专长分组:
控制器 Controller - 负责转发请求,对请求进行处理。
视图 View - 界面设计人员进行图形界面设计。
模型 Model - 程序员编写程序应有的功能(实现算法等等)、数据库专家进行数据管理和数据库设计 ( 能够实现具体的功能 )。
MVC 模式的特色:
重用性
Ext JS 4 中,数据模型、视图组件和存储组件能重复使用,使用时只需将它们的名称做为引用添加到特定的 controller 中。
职能分离
模型、视图、控制器以及存储之间的职能分离,使得每一个 JS 文件的职能单一化、最小化。开发人员只须要引用这些必需的职能单元便可构建新的功能。
职责清晰
因为每个 JS 单元文件的职责清晰,不一样类型的“职责”被划分为不一样的组件。在集成开发工具中,开发人员很容易利用这些组件构建本身的应用。
复杂性
运用 MVC 模式时有必定的复杂性,由于开发者须要付出额外的努力去学习 Ext JS 4 的 MVC 框架,但在大型项目中这个付出是值得的。另外 Sencha 提供了相应的集成开发工具 Sencha Architect 协助基于 MVC 框架的开发,必定程度上减轻了因运用 MVC 模式带给开发者的压力。
运用 MVC 之前:
代码组织凌乱
上面的小结中提到 Ext JS 4 以前的代码一般会碰到四“难”,除此以外,代码很难管理,因为没有分离出相似控制器单元,致使“拷贝、粘贴”过多,应用逻辑代码支离破碎,给调试和测试带来不少不便。
缺少总体逻辑
因为视图等“静态”代码和事件监听代码混杂在一块儿,代码功能职责混乱,不少本应做为公用的代码也一块儿被混进去,致使可扩展性几乎全无,所以为新功能编写新的代码也变得愈来愈不容易,修改代码更是容易出错。
运用 MVC 之后:
01 |
<html> |
02 |
<head> |
03 |
<meta http-equiv= "Content-Type" content= "text/html; charset=utf-8" /> |
04 |
<title>Demo</title> |
05 |
<link rel= "stylesheet" type= "text/css" |
06 |
href= "http://extjs.cachefly.net/ext-4.0.2a/resources/css/ext-all.css" /> |
07 |
<script type= "text/javascript" |
08 |
src= "http://extjs.cachefly.net/ext-4.0.2a/ext-all-debug.js" ></script> |
09 |
<link rel= "stylesheet" type= "text/css" href= "style.css" /> |
10 |
<script type= "text/javascript" src= "demo.js" ></script> |
11 |
</head> |
12 |
<body></body> |
13 |
</html> |
整个工程仅此一个 HTML 文件 , 供十一行,其中 demo.js 是工程的启动文件,里面包含了全部 UI widget 的构建,后面会具体介绍。
JavaScript 脚本都按职责存放在不一样的 JS 文件中。
不一样的 JS 文件按 MVC 目录命名约定"controller"、"store"、"view"、"model"分类存放。
整个工程里只有一个 HTML 文件,并且只做为入口文件,里面不写任何脚本。请看下面入口文件的例子。
总体逻辑更加条理
入口定义在 Ext.application({...}) 中,这是 Ext JS 4 为开发 MVC 应用新增的函数,咱们能够在里面引入初始时所需的 controller、view 或 model,在 launch 函数中编写初始代码,和之前在 Ext.onReady() 中同样。由于 Ext 引擎会在 Ext.application({...}) 函数执行时建立一个全局 application 实例并能在 controller 中被引用获得 (this.application.*),因此咱们也能够在 application 中定义一些公共函数,甚至注册一些事件,方便其它 controller 调用。
"model"文件夹中只有模型相关的类定义,每一个模型定义必须包含字段,还能定义字段校验规则,不一样模型之间的关联,以及数据代理 ( 链接服务器存取数据 )。好比雇员\部门对应两类模型,体现为两个类文件"Employee"和"Department"。
"view"文件夹中定义了全部的 widget,每个 widget 对应一个类文件。view 的代码属于静态代码,后面将提到怎样用工具自动生成。
"controller"文件夹中的控制器按管理范围的不一样划分为不一样的类文件,其中每个控制逻辑都包括初始化、组件事件监听以及引 用等。好比,导航菜单的控制器会包含对主页面菜单按钮的动做监听”click“,并在该事件中负责建立相应的子页面;而子页面对应的控制器只负责该页面中 的组件的行为,如提交按钮的点击等。另外控制器自己能被动态加载,在下文的例子中咱们还能够看到,不一样的控制器被加载的时机和顺序是由用户行为(如点击某 按钮)控制的。其实这个特性是基于依赖于 Ext JS 4 的动态加载类的新特性的。详见"按需加载类"一节。
因而可知,运用 MVC 后 HTML 里再也不直接写 JS 了,JS 按逻辑、职责分门别类存于不一样的目录,对应到不一样的文件中。
开发 Ext JS4 的利器:Sencha Architect
Sencha Architect 是 Sencha 公司出品的一款辅助 ExtJS 开发的商业 IDE 软件,能帮助 ExtJS 开发人员更加专一于核心 JS 代码的开发,从而大大减小花费在编写界面、组织代码等反复性的工做上的时间。笔者写做时的工具版本是 2.0.0 Build 412,此工具最大的特色是能帮助用户管理符合 MVC 模式的代码。例如,视图类代码能经过拖放组件结合属性设置的方式彻底自动生成,不用写手一行代码。其它如 Model、Store 和 Controller 的代码能经过属性设置,方法、事件设置自动生成。理想状况下,一个熟练的 ExtJS 开发者在使用 Sencha Architect 时,百分之九十以上的时间会花在 controller 的实现和自定义组件(包括 override 一些组件)的开发。这一点也不夸张,由于在 Sencha Architect 中开发界面实在过轻松了。感兴趣的朋友能够从官网下载 Sencha Architect 的 30 天试用版尝尝鲜。
主要特性有 :
自动生成 view 代码
经过拖放组件的方式生成复杂视图。
图 2. 视图设计
代码模式和设计模式切换
设计好的视图,能方便切换到代码模式下预览,拷贝或导出。
图 3. 模式切换
属性设置面板
图 4. 属性面板
项目导航面板
图 5. 导航面板
下面的示例程序是一个很是实用的集表单提交,表格应用和图表显示的综合运用的例子。因为篇幅限制,本文只列举主要的 JS 单元,感兴趣的朋友请到本文末尾处下载完整的示例程序。
入口代码
本示例使用了默认的 appFolder:app, 实际中用户能够覆盖此属性,使用符合项目要求的路径名。我在项目中倾向于 appFolder 中的全部类由 Sencha Architect 工具维护,经过配置 mvn,在 compile 时将 appFolder 中生成的类拷贝到 webApp 中。手工维护的 JS 文件放在独立的命名空间中(称其为扩展空间吧),并在入口中声明,这样能被 application 引用并加载,同时在扩展空间的类也能 require 到 application 对应命名空间中的类,这样作的好处是,您能将 override 的代码移出来放到扩展空间中,另外还能放一些项目中用到的插件。
清单 3. 入口代码
01 |
/* 动态加载依赖的前提 */ |
02 |
Ext.Loader.setConfig({ |
03 |
enabled: true , |
04 |
paths: { |
05 |
'Extention' : 'js' // 设置一个扩展命名空间,区分工具生成的代码 |
06 |
} |
07 |
}); |
08 |
09 |
Ext.application({ |
10 |
requires: [ |
11 |
'Extention.RandomGen' // 加载扩展命名空间中的类 |
12 |
], |
13 |
14 |
views: [ |
15 |
'MyViewport' |
16 |
], |
17 |
autoCreateViewport: true , |
18 |
name: 'MyApp' , |
19 |
controllers: [ |
20 |
// 引用初始页面时,所须要的最小 controller 集合, |
21 |
// 其它的由主菜单按钮触发动态加载 |
22 |
'AppLaunchCtrl' |
23 |
], |
24 |
/* 如下函数仅示意用户能在 application 中定义本身的全局函数,具体实现请下载代码后查看 */ |
25 |
findTab: function (tabPanel, record) {}, |
26 |
activateTab: function (tabPanel, targetTab) {}, |
27 |
widget: function (tabPanel, controllerName, widgetName, record, cfg) {} |
28 |
}); |
主菜单控制器
控制主菜单中三个按钮的点击事件,以及它们的状态:如按下和浮起。
表单子页面控制器
表单提交相关,本示例中,点击提交按钮后将弹出一个“Save”提示框。
表格子页面控制器
经过查询按钮控制表格的 store 从新加载新数据。
图表子页面控制器
经过下拉选择框控制图表的刷新。
清单 4. 图表子页面控制器代码
Ext.define('MyApp.controller.ChartCtrl', { extend: 'Ext.app.Controller', stores: [ 'MyChartStore', 'LatestMonths' ], refs: [ { ref: 'tabPanel', selector: '#tabPanel' }, { ref: 'latestMon', selector: '#comboLatest' } ], /* 请参看 init 中的事件绑定 */ onComboboxSelect: function(combo, records, options) { console.log('onComboboxSelect'); this.getMyChartStoreStore().load(); return false; }, init: function(application) { // 绑定月份下拉框的 select 事件 this.control({ "#comboLatest": { select: this.onComboboxSelect } }); /* 绑定 store 的 load 事件,完成动态数据效果(演示) 实际中项目不须要这样, 应在 store 上定义 proxy 从服务器拿数据 */ this.getMyChartStoreStore().on( { 'load' : function(me, operation, eOpts) { me.loadData(generateData(8)); } } ); // 初始化月份下拉框的值为”1“ this.getLatestMon().setValue('1'); // 为图表加载数据,此处显示调用, // 是由于此 store 属性 autoLoad 定义 false this.getMyChartStoreStore().load(); } }); |
项目中的主要问题和解决办法
关于 Sencha Architect 代码的管理
此工具能生成几乎全部必须的代码,但对于手工编写的部分 JS 代码,本文推荐在 webApp 下创建独立的目录,并在入口文件中定义对应的路径到命名空间的映射。
用编译工具如 mvn 将生成目录拷贝到 webApp 中。
关于 Controller
划分好 controller 的范围和生命周期。
划分好页面功能区,而后肯定须要哪些 controller; 区分哪些是动态的,好比一个子窗口或新页签,对应 controller 的加载时机也应该是动态的。
将须要动态加载的 Controller 从入口文件定义中移除。
这样作的一个显而易见的好处是,避免初始页面"过载";另外能避免因 init()调用太早致使事件绑定失败,缘由也显而易见:须要绑定事件的组件尚未被建立出来。
关于 store 多实例
设置过 storeId 的 store 将在 storeManager 中注册为单例;有时这是个限制,好比想在多个 view 实例中拥有独立的 store 时,Sencha Architect 目前没有好的办法。办法有二,一是 override view,让每一个 view 在 create 时拥有本身的 store;二是在 Model 中设置 proxy( 固然这时得移除 store 中的 proxy)。第二种方法来自 Sencha 的技术支持,但我还没试过。
关于 TreePanel 对属性设置的要求 我在使用 Sencha Architect 的时候碰到过这个问题,Architect 能显示热数据,即属性设置好后,设计器能实时将数据做为预览显示出来;我一开始就碰到树不能显示的问题,接着是显示了又没法展开下级。
设置好 store 的 proxy 中的 idProperty、root 属性。
我一开始设置错了 root(设置了一个不存在的 field),后来查了好久,找到了这个位置 , 问题解决。中间还怀疑是工具的 bug :-)。 瞧,一个很不起眼的地方,但很打击士气。
设置好树节点所用到的 Model 中的 idProperty 属性。
这个属性决定点击树的节点往下钻取时往服务器传递的参数。
总结
Ext JS 从 4.0 之后有了很大的变化,特别是增长了对 MVC 开发模式的支持,给 Ext JS 开发注入了新的活力,也极大地方便了大型 WEB 项目的开发。本文经过对使用 MVC 先后的比较,透过一个很实用的 MVC 实例,演示了运用 Ext JS4 MVC 开发 Web 前端比用之前的版本要简单不少;文章最后,本人根据本身在开发过程当中的经历提出了一些常见的困难以及解决办法。但愿读者能从中获得一些启发和帮助。