本文翻译自:http://www.sitepen.com/blog/2011/09/30/dojox-app-a-single-page-application-framework/
原文作者:Colin Snover
译者:Oliver
dojox.app是一个小型的应用框架,它提供了一组类,用于管理部署在移动设备或桌面系统上的单页面应用的生命周期和行为。其主类Application用来管理应用的生命周期,并且能够方便地对其进行修改,扩展出额外的自定义功能。一个Application实例包含一些Scene对象和View对象,这些对象提供了可视的用户界面。所有的视图、场景、依赖模块、以及一些其他关于应用的信息都是默认通过一个JSON配置文件传给Application类的。
示例配置:
还有一些额外的属性,例如models, stores, id, name以及description,它们在将来可能会被用到,其具体的定义和用途还在开发中。
其用法如下:
在内部实现上,Scene借用了dijit.layout和dijit._Templeted的一些概念。Scene类的默认模板非常简单,甚至都不能称其为一个模板——它只是简单地输出当前视图中的任意内容。场景模板中的元素可以用region属性定义在哪里显示,类似于dijit.layout.BorderContainer。例如,要实现一个标签页场景的模板可能像这样(使用dojox.mobile中的组件):
原文作者:Colin Snover
译者:Oliver
dojox.app是一个小型的应用框架,它提供了一组类,用于管理部署在移动设备或桌面系统上的单页面应用的生命周期和行为。其主类Application用来管理应用的生命周期,并且能够方便地对其进行修改,扩展出额外的自定义功能。一个Application实例包含一些Scene对象和View对象,这些对象提供了可视的用户界面。所有的视图、场景、依赖模块、以及一些其他关于应用的信息都是默认通过一个JSON配置文件传给Application类的。
config.json
这个主配置文件定义了所有的模块依赖、应用行为、顶级视图和场景、以及其他所有对应用的正确运行至关重要的信息。示例配置:
{
/* 全局应用依赖 */
"dependencies": [
"dojox/mobile/Heading",
"dojo/mobile/RoundRect",
"my/custom/module"
],
/* 应用模块,将被隐式加到前面列出的依赖模块上 */
"modules": [
"dojox/app/module/history",
"my/custom/appModule"
],
/* 应用自身的html模板 */
"template": "example.html",
/* 默认加载的视图 */
"defaultView": "home",
/* 默认使用的视觉转换效果 */
"defaultTransition": "slide",
/* 视图与场景 */
"views": {
/* home是一个顶层的dojox.app.view */
"home": {
/* 用于实例化该视图的类 */
"type": "dojox.app.view",
/* 仅用于该视图的依赖模块 */
"dependencies": [
"dojox/mobile/ListItem",
"dojox/mobile/EdgeToEdgeCategory"
],
/* 该视图采用的模板 */
"template": "views/home.html"
},
/* tabscene是一个包含三个子视图的dojox.app.scene */
"tabscene": {
/* 用于实例化该场景的类 */
"type": "dojox.app.scene",
/* 该场景的模板 */
"template": "tabScene.html",
/* 该场景的默认视图 */
"defaultView": "tab1",
/* 在标签页之间转换时默认使用“翻转”动画效果 */
"defaultTransition": "flip",
/* 用于该场景的视图 */
"views": {
"tab1":{
"template": "views/tabs/tab1.html"
},
"tab2":{
"template": "views/tabs/tab2.html"
},
"tab3":{
"template": "views/tabs/tab3.html"
}
},
/* 特定于该场景的依赖模块 */
"dependencies": [
"dojox/mobile/RoundRectList",
"dojox/mobile/ListItem",
"dojox/mobile/EdgeToEdgeCategory"
]
}
}
}
配置属性描述:
dependencies | 当其作为配置文件的顶层属性出现时,这个属性定义了整个应用所需要的模块。当其作为某个场景或视图的属性出现时,则定义了哪些模块必须在该视图/场景实例化之前加载。 |
modules | 这个属性声明了哪些模块需要混入Application类来控制应用的生命周期。换句话说,每一个特定应用的Application类都是在运行时在基类Application的基础上加上这些模块动态创建出来的。 |
template | 当其作为配置的顶层属性出现时,定义了整个应用的布局模板。当作为视图或场景的属性出现时,则表示该视图或场景的模板。 |
defaultView | 这个属性定义了应用默认加载的视图。 |
defaultTransition | 当作为配置文件的顶级属性出现时,该属性定义了顶层视图/场景所使用的默认视觉转换方法。当定义在一个场景里时,仅代表该场景的默认视觉转换方法。 |
views | 这个views属性是一组嵌套的对象,定义了本应用或场景中的所有的视图和场景。这些内容将在后面详细介绍。 |
Application类
Application类本身是一个抽象类,因此从不被直接使用。它是从Scene类(详见下文)简单扩展出来的子类。dojox.app提供了一个工厂方法,以配置对象为参数,创建并自动启动整个Application实例。其用法如下:
require(["dojo/json", "dojox/app", "dojo/text!./config.json"],
function(json, makeApplication, config){
makeApplication(json.parse(config));
});
Scene类
Scene类为视图提供了一个模板化的容器。它的目的是为了能通过HTML模板来定义场景的布局,以及在场景切换时用到的一组子视图。例如,要显示一组标签页,你需要在一个Scene中为每一个标签配置一个子View。场景的模板将定义在哪里显示这个标签页控件和这些视图。在内部实现上,Scene借用了dijit.layout和dijit._Templeted的一些概念。Scene类的默认模板非常简单,甚至都不能称其为一个模板——它只是简单地输出当前视图中的任意内容。场景模板中的元素可以用region属性定义在哪里显示,类似于dijit.layout.BorderContainer。例如,要实现一个标签页场景的模板可能像这样(使用dojox.mobile中的组件):
<div style="background:#c5ccd3;" class="view mblView">
<div region="top" dojoType="dojox.mobile.Heading">
Tab Scene
</div>
<ul region="top" dojoType="dojox.mobile.TabBar"
barType="segmentedControl">
<li dojoType="dojox.mobile.TabBarButton"
icon1="images/tab-icon-16.png"
icon2="images/tab-icon-16h.png"
transitionOptions='{title:"TabScene-Tab1",
target:"tabscene,tab1",
url: "#tabscene,tab1"}' selected="true">Tab 1</li>
<li dojoType="dojox.mobile.TabBarButton"
icon1="images/tab-icon-15.png"
icon2="images/tab-icon-15h.png"
transitionOptions='{title:"TabScene-Tab2",
target:"tabscene,tab2",
url: "#tabscene,tab2"}'>Tab 2</li>
<li dojoType="dojox.mobile.TabBarButton"
icon1="images/tab-icon-10.png"
icon2="images/tab-icon-10h.png"
transitionOptions='{title:"TabScene-Tab3",
target:"tabscene,tab3",
url: "#tabscene,tab3"}'>Tab 3</li>
</ul>
</div>
上面这个模板定义了两个region="top"的区域:一个头元素以及一个标签按钮列表。它们将在渲染时放置在场景的顶部。
通常在使用BorderContainer时还需要指定一个region="center"的区域。对于Scene来说,这个“中央”区域会被自动指定为当前活动的视图(例如当前标签页)。
除了支持场景的生命周期以及渲染过程的代码外,Scene还提供了控制子视图相互之间切换的变换方法。场景既可以包含视图,也可以包含其他场景。View类
与场景类似,视图也是内容的容器。然而,视图只含有其模板内定义的内容,而不能包含其他子视图。它与场景的区别是,一个View实例无法包含其他场景或视图。小结
这三个类的设计都力求简单,只提供必要的结构和生命周期(虽然还有一些额外的核心方法和生命周期句柄会很快加上)。开发者使用dojox.app框架可以通过继承这些基类来自定义视图和场景(或者实现等价的功能),并且在应用的配置文件中定义它们。TODO
dojox.app是一个实验性的框架,其中还有一些关键组件尚在开发过程中。它的发行版预期将在Dojo2.0之前到来。目前正在开发的项目如下:
Model / Store支持 | 我们有几个Model/Store支持的实现,包括一个用于dojox.mvc的实现。然而,要为这些组件提供大家一致认可的API还有更多的工作要做。虽然MVC系统将会最先被支持,但它不会是必要组件,因为应用开发人员可以仅通过扩展View类来很好地控制视图的HTML。 |
桌面 / 移动设备分支 | dojox.app是平台无关的。但在配置文件中可以使用CSS媒体选择符和属性定义,从而支持根据用户的浏览器环境选择视图和参数。 |
智能打包系统支持 | 出于性能考虑,特别是在移动平台上,一个合适的应用打包系统是十分必要的。为此,我们没有为每一个应用采用单独的打包配置文件,而是用一个包装器工具直接基于配置文件智能地生成应用包。 |