在 WebSphere sMash 中使用 Dojo 开发 Ajax 的 Web 应用程序-1

look_w

开始之前马上下载免费的开发版 WebSphere sMash ：


更多关于 WebSphere sMash 方面的最新技术资源，请参考 及 。

本文假设您已经下载了 WebSphere sMash 并且完成了简明教程的学习，或者曾经写过简单的应用程序。您应该熟悉 Ajax 的基本原理和 Dojo 的相关使用方式。
你还需要具备以下先决条件来完成本文的示例应用程序：

• JDK 5.0 或更高版本。
• WebSphere sMash 1.0.0.4 或更高版本的命令行环境。
• 通畅的网络连接来连接 SMTP 邮件服务器。
• Firefox 3.0 用于启动 AppBuilder

AppBuilder 现在是 WebSphere sMash Developer Edition （开发者版本）的一部分，为 WebSphere sMash 应用程序提供了一个基于 Web 的开发、测试和运行环境。
你可以在命令行输入如下命令打开 AppBuilder：

1	appbuilder open

第一次运行时需要一段时间来进行自动配置，完成后将会自动打开一个浏览器窗口，你将看到 AppBuilder 的主界面。
你可以使用如下命令关闭 AppBuilder：

1	appbuilder stop

在 WebSphere sMash 中使用 Dojo 进行前端 Ajax 编程WebSphere sMash 包含了 Dojo 工具集，可以使用 Dojo 进行基于 Ajax 的 Web 前端开发。尽管 Ajax 和 Dojo 并不是 WebSphere sMash 应用所必须的，但是通过使用它们，我们可以构建用户体验更加友好的 Web 应用。
添加 Dojo 到 WebSphere sMash 的应用中通过向 WebSphere sMash 应用中添加 Dojo 依赖，我们就可以在应用中使用到 Dojo。打开 WebSphere sMash 应用的 config/ivy.xml 文件，添加如下一行。

1	<dependency org="dojo" name="dojo" rev="1+"/>

关于更多 Dojo 的信息，请看 。下面将介绍 WebSphere sMash 为 Dojo 开发提供的相关支持。
使用惯例来构建定制化 Dojo 小部件惯例是一种习惯用法，它是多年来开发所积累的最佳实践。例如，Ruby on Rails 就得益于“惯例重于配置”的特点。Dojo widget 是将 Web 应用的标准文件进行组合构建一个可以重用的组件，这些文件包括 HTML 和 JavaScript。它非常强大，适合构建复杂、可重用性高的 Web 应用。所以 WebSphere sMash 引入了一个惯例来组织这些定制的 Dojo widget，也就是你可以将这些 widget 的相关文件放在工程结构的特定目录 app/zwidgets/ 中，从而简化工具的整合。比如，这样的惯例能够帮助可视化的 Web 页面编辑器找到你的定制化 widget，并且将其加入到编辑器的工具栏中。
为了使用这样的惯例目录结构，该 WebSphere sMash 应用程序应该添加 Dojo 模块。通过添加 Dojo 模块，WebSphere sMash 应用在遇到 /zwidgets 请求时，将从 app/zwidgets/ 目录寻找相关文件。例如，如果我们需要使用该惯例目录来构建一个叫 x.MyWidget 的 Dojo widget，那么可以创建如下两个文件 :

1 2 3

app/zwidgets/x/MyWidget.js app/zwidgets/x/templates/MyWidget.html

在使用定制化的 widget 之前，需要进行 Dojo 的模块注册。 对于上面的例子，还需要添加如下一行脚本进行该定制化模块的注册。

1	dojo.registerModulePath ("x", "../zwidgets/x");

在上面的例子中，我们使用了相对路径，这样可以保证你的应用不会因为 WebSphere sMash 的 context root（关于 Context Root 的介绍，请参看  中 sMash 介绍）的改变而受到影响。
过滤 Dojo 的 preventCache 参数由于浏览器对于前端请求有不同的缓存策略，所以在使用 Ajax 调用时有可能被浏览器直接使用缓存来返回结果，从而无法得到所需要的数据。因此 Dojo 使用一种反缓存的技术来保证使用 dojo.xhr 的调用请求能够到达服务器，其办法就是在调用的 URL 中添加 dojo.preventCache 这样一个参数。例如，下面 dojo.xhrGet 方法将使调用的 URL 变成唯一，从而防止浏览器的缓存所带来的问题。

1 2 3 4 5 6 7

dojo.xhrGet( { url: "resources/person",    handleAs: "text", preventCache: true, load: function(response)     { dojo.byId('info').innerHTML = response; } } );

当 preventCache 为 true 时，Dojo 将添加该参数到请求的 URL 中，比如 dojo.preventCache=1234567890。这个参数的值是任意的，Dojo 会使用当前的时间戳来保证这个值的唯一。这样，最后发出请求的 URL 大概如下：resources/person?dojo.preventCache=1234567890。应用程序可以通过 /request/params         来访问到所请求的参数，所以如果需要获取 dojo.preventCache，可以使用 GlobalContext 的 API 来获取：

1	GlobalContex.zget ("/request/params/dojo.preventCache");

因为它只是客户端的防缓存技术，所以它基本上对于服务端没有意义。但是有时，一些 REST API 可能会对于在 URL 中提供的参数进行一些假设。比如，在 WebSphere sMash 的 Zero 资源模型的 REST API 中，使用请求的参数来进行数据查询。这样，我们就需要在服务器端进行正常业务处理之前过滤掉 dojo.preventCache 这个参数。在 zero.dojo 模块中提供了一个对于 requestBegin 的事件处理来过滤这个参数。在 zero.config 中将 /config/request/params/strip/dojo.preventCache 设置成 true 就可以开启这个功能。

1	/config/request/params/strip/dojo.preventCache = true

一般来说，这样就足够了。在开启该过滤功能情况下，使用 /request/params 来访问请求参数时，应用程序将看不到请求 URL 的 dojo.preventCache 参数。当然，该过滤器并不改变 /request/queryString 的值。在默认情况下，每个 HTTP 的请求这个过滤器都会执行。如果需要限定该过滤器在某特定 HTTP 请求上面，你可以在 zero.config 对其事件的响应条件进行配置。如下：

1 2 3 4

/config/handlers += [   { "events" : "requestBegin", "handler" :   "zero.dojo.filters.DojoPreventCacheFilter.class",    "conditions" : "/request/path =~ /resources(/.*)?"  }]