《Dojo构建Ajax应用程序》连载一

本文内容来自于本人翻译的《Dojo构建Ajax应用程序》一书，该书由机械工业出版社出版。

以下为该书封面（点击图片可以进入到china-pub上该书的页面）：

以下为该书的目录：

202第一部分Dojo指南.1a1c1ac111c111a1a1

203理解Dojo：指南2a2c2ac222c222a2a2

204使用Dojo进行客户端验证3a3c3ac333c333a3a3

205使用Dojo与服务器端协同工作4a4c4ac444c444a4a4

206使用DojocWidgets5a5c5ac555c555a5a5

207使用Dojo处理表单6a6c6ac666c666a6a6

208第二部分cDojocWidgets7a7c7ac777c777a7a7

209DojocWidgets简介8a8c8ac888c888a8a8

201DojocFormcWidgets9a9c9ac999c999a9a9

201DojocLayoutcWidgetsc..10a10c10ac101010c101010a10a10

201其他专门的DojocWidgets11a11c11ac111111c111111a11a11

201第三部分cDojo详解12a12c12ac121212c121212a12a12

201Dojo是什么？13a13c13ac131313c131313a13a13

201Dojo的技术描述14a14c14ac141414c141414a14a14

201对象与类15a15c15ac151515c151515a15a15

201String与JSON16a16c16ac161616c161616a16a16

201事件与事件处理17a17c17ac171717c171717a17a17

201AjaxcRemoting18a18c18ac181818c181818a18a18

202处理DOM19a19c19ac191919c191919a19a19

201测试与调试...20a20c20ac202020c202020a20a20

第1章 理解Dojo： 指南

耳听为虚，眼见为实。

—中国谚语

灵感来源于本章开头所引用的谚语，我相信讲解新技术最好的方式之一就是给出一个简单的示例。因此我将以一个指南作为本书的开始，该指南将使用Dojo Toolkit来增强一个基本的HTML表单。从本章开始一直到第五章——使用Dojo处理表单都将介绍该指南，同时这五章也构成了本书的第一部分——Dojo指南。

指南简介

假如你是一个Web开发者（如果你正在阅读这本书，那么对此就没什么好奇怪的了），有人建议你向站点中增加一些Ajax特性。也许提出该需求的人正是你的老板，甚至是老板的老板，但他可能连Ajax是什么都不知道，更不用说哪些特性有用了。也许你有点不太自信。想象一下，你之前的经验几乎都在服务器端，使用Java或者其他服务器端技术，你对HTML和JavaScript的经验非常有限。这就是接下来几章中你开始了解Dojo Toolkit时所处的场景。

为了进一步说明该场景，假设你已经听说过JavaScript编程语言非常强大，有很多JavaScript库和框架可以协助你充分利用其强大的功能。你已经决定使用Dojo Toolkit，因为你经常访问的一些Web站点和论坛推荐它。同时你也准备将应用中访问最频繁的一个页面“Ajax化”。

该指南将通过几个步骤向你介绍如何使用Ajax特性来更新页面。我们将采用小步前进的方式来增强该页面，每一小步都会重点说明一个具体的问题。通过这种方式，我们将会看到Ajax允许我们往Web页面中增加的各种特性，同时我们也会看到如何使用Dojo Toolkit来实现这些特性。

1.1.1 本指南的目标

本指南的首要目标就是向你展示如何使用Dojo Toolkit将一些常见的Ajax特性增加到web页面中。该指南从简单处着手。换句话说，它专注于容易实现且对可用性提升大有裨益的一些特性。它不会对Dojo特性进行面面俱到的讲解，也不会涵盖我们实现的所有特性。你可以将它当作增强Web站点的第一步。

该指南的另一个主要目标就是以最简单的方式实现一些特性。尽管Dojo的大多数特性既可以声明方式（通过HTML标记）也可以编程方式（通过JavaScript）实现，但我们首先以声明方式实现，因为大多数的服务器端Web开发者更熟悉HTML标记，相比之下，对JavaScript就差一些了。当然了，我们也会使用一些JavaScript来作为各种东西的粘合剂。

1.1.2 使用Dojo的目的

我们使用Dojo想要得到什么呢？首要的是——想让页面的可用性更好。我们在很多地方都会这样想。页面的执行应该更快点。看起来更漂亮点。操作起来更简单点。可以帮助用户准确获得其想要的信息，这就要求页面的导航更简单。但同时在用户访问Web页面时，我们不应改变其操作习惯。我们在不断增强可用性的同时不能以牺牲用户已有的体验为代价。

我们该如何改进可用性呢？Dojo对已有的HTML表单元素进行了增强，提供了额外的功能。这些增强会使当前的表单元素可用性更好。

我们可以通过如下两种方式来改进性能：让系统运行的更快或者是让系统看起来运行的更快。让一个过程看起来运行的更快的理想方式就是在其运行的同时用户可以做一些其他事情而不是在那干等着。Ajax使用了非常棒的机制来支持该技术。我们将使用Dojo让页面向服务器端发送异步请求，同时用户的操作可以继续而不被打断。对用户来说，该页面看起来运行的更快、响应也更快了。

我们可以在用户输入数据时就进行验证，以此来改进数据验证过程。Dojo可以将小部分验证请求发送到服务器端而无需提交整个表单。如果合适的话，我们甚至想采用桌面应用那种数据验证方式——根据用户的按键进行验证。

我们还希望这些特性容易实现。我们想利用对于HTML的开发经验，在使用JavaScript时，让编程模型保持一致而强大。我们希望相比于完全由我们自己来开发功能，所需编写的代码量更少。代码少意味着出错的机会小。当你学习Dojo时，你会发现你所掌握的内容对你进一步探索Dojo会大有裨益。当事情变得复杂时，你可以使用工具以辅助调试。简言之，Dojo提供了非常棒的编程环境，绝对值得你期待。

最后，你可以看到我们会一直惊讶于Dojo带给我们的好处，而这些好处不需要任何额外的工作就可以得到。例如，我们会看到增加的任何特性都可以在各种浏览器中以一致的方式呈现出来。同时我们还会看到用来支持Web的易用性（Accessibility）及国际化（Internationalization）标准的一些可视化元素。

我们已经给Dojo带上了高帽。我们要求不少，但却不想费太多劲。Dojo真的行吗？这需要我们去探索。我们首先以一个页面作为增强的基础，通过该页面确定好我们希望解决的各种问题。

1.2 一个标准的HTML数据输入表单

首先从我们的应用中选出一个页面作为Dojo增强的目标（图1.1）。该页面来自于一个假想的客户服务应用，该应用面向全国的电报公司，它允许客户创建帐号并请求服务。该指南对于我们“业务”操作的定义很含糊，因为你可能会猜到，该表单就是用来突出很多业务应用都会拥有的一些特定类型的功能。因此如果你能先将怀疑放在一边的话，那就让我们来检查一下该表单。

该页面的设计很一般——几乎一点设计都没有。它仅使用了一点样式，就这点样式也是很简单的。你的页面肯定比它强多了，但我们使用该简单设计以让示例保持足够的简单。

让我们将表单中的每个字段都过一遍，然后看看有没有可用性问题。接下来会谈到Dojo是如何解决这些问题的。

1.2.1 First与Last Name

第一个数据输入字段用来保存客户的first name。这足够直接，但我们已经有问题了。该字段的标签内容是：“First / Last Name:”，同时紧跟两个文本输入框。尽管用户可能明白该页面需要什么，但对于屏幕阅读器（有视觉障碍的人用其读取屏幕上的内容）来说还是困难些。

你可能会从可用性角度提出质疑：这让人感到不明就里。页面上的其他标签都仅指一个单独的文本框，而该标签却指两个。当将一个名字分为两部分时，last name就应该放在first name前吗？没有其他方式吗？问的好，但我们现在暂且不进行回答。记住，我们现在仅仅是找出问题。在后面的章节中将给出解决方案。

现在让我们看看这些字段的HTML标记。

<label for="firstName">First / Last Name: </label>

<input type="text" id="firstName" name="firstName" />

<input type="text" id="lastName" name="lastName" />

你以前可能没用过<label>标记，但它却可以让伤残人士更方便地访问你的站点。当标签不在输入字段前时，该标记将有助于屏幕阅读器，例如当标签位于不同的单元格中时。当使用级联样式表（CSS）时还可以轻松地将一个单独的样式增加到所有的标签上。另一个问题就是这两个字段中只有一个拥有<label>标记。

First name和last name字段都是必填的。但在这个标准的表单中并没有使用JavaScript，那我们如何做到这一点呢？并没有满足该要求的HTML标记或者是属性存在，因此我们准备将这个验证交给服务器端处理。这意味着用户只有在提交表单并收到来自服务器端的错误消息后才能知道哪些字段是必填的。

该如何显示错误消息呢？假如用户已经输入了一些表单数据，然后按下了“提交”按钮。接下来浏览器就会向服务器端发出一个请求，然后服务器就会对数据进行验证并将带有错误消息的表单返回给浏览器。我们希望服务器还会将用户已经输入的数据也返回来，这样用户就无需重新输入了。错误页面通常在页面上方显示所有错误消息。带有错误消息的页面看起来如图1.2所示。

1.2.2 用户名

我们的应用允许用户登录并管理自己的帐号，因此我们要求每个用户都要创建一个用户名。我们应该为用户提供一些指导以帮助其创建合适的名字，但这需要往页面中增加大量的文本，因此我们决定不这样做了。该表单就简简单单的要求一个用户名并提供一个文本输入框而已。

完成该功能的HTML标记非常类似于“First / Last Name:”字段，就一个<label>和<input type="text">标记，如下所示。

<label for="userName">User Name: </label>

<input type="text" id="userName" name="userName" size="20" />

我们通过设定size=”20”属性已经增加了一点儿客户端验证，以保证用户无法输入超过20个字符的名字。

该字段的一个问题也出现在验证上。用户可能想创建一个易记的简短用户名，但这也是其他用户的想法，这样该用户名就很有可能已经被使用了。那么我们该如何通知用户呢？请注意，直到用户提交页面时才能进行验证。服务器会检查用户名以确认是否已被使用了，如果被使用了，就会返回一个页面来重新显示表单并给出错误消息（同时还有其他字段的错误消息）。如果能给用户一些建议就更好了，这样他就不会再次输入已被使用了的用户名了。该建议应该基于用户想要注册的那个用户名。

1.2.3 Email地址

我们想通过Email与用户交流，因此需要一个Email地址。可以使用一个简单的文本输入框来存放用户输入的Email地址。

其HTML标记显示如下，它与页面上的其他文本字段也很类似。

<label for="email">Email: </label>

<input type="text" id="email" name="email" size="45" />

我们又一次通过设定字段的size属性来进行客户端验证。但有没有办法验证Email地址的有效性呢？我们可以使用两类验证。首先，Email地址的格式正确么？例如，是否包含“@”符号？是否以TLD如“.com”结尾？其次，它是一个真实的Email地址么？不幸的是，如果不实际创建并发送一个Email是没法验证后者的。尽管向用户发送一个密码并让他自己来验证用户名是一个好主意，但这已经超出了我们讨论的范围了。因此我们仅仅确认该Email地址的格式正确就行了。

1.2.4 地址

我们需要用户家庭地址的首行，同时使用一个文本框保存它。

其HTML与上面的字段都很类似。

<label for="address">Address: </label>

<input type="text" id="address" name="address"/>

该字段应该包含客户账单地址的首行，因此我们需要确保用户填写了该项。它是一个必填字段，但我们还是通过服务器端进行验证。

1.2.5 州

我们将用户所在的州作为其账单地址的一部分。因为州名有限，所以可以使用<SELECT>来提供州名的一个下拉列表，用户可以选择其中一个。下图显示了使用下拉列表的州名示例。

HTML提供了<SELECT>表单元素，它能提供一系列值的列表。下面展示了创建该字段所需的一些标记片段。

<select name="state" >

<option value="AL">Alabama</option>

<option value="AK">Alaska</option>

<option value="AS">American Samoa</option>

<option value="AZ">Arizona</option>

... additional state values not shown ...

</select>

由于州名有限，所以它们的值都可以列出来。对于这个字段，验证不是问题，问题在于行为。我住在伊利诺斯州（Illinois），经常网购，所以我常常要输入账单地址。当从表单中选择州名时，我首先会敲一个“i”，接下来“Idaho”就会跳出来，因为它是第一个以“i”开头的州名。这太棒了——尽管我不住在爱达荷州（Idaho）。接下来我敲一个“l”（小写的“L”），“Louisiana”又会跳出来。现在很多有成就的人都住在路易斯安那州（Louisiana），但我不是。问题在于<SELECT>标记将我的输入解释为两种不同的情况——每种都是一个单词的首字母，它没有将其当作一个单词的前两个字母。当我敲“il”时，我想看到所有以“il”开头的州名，只有Illinois符合这种情况。不幸的是，这不是<SELECT>标记的工作方式——当我敲“l”时，它显示的是“Louisiana”，这是因为它觉得我又一次敲了一个州名的首字母。

该问题并不是无法解决。有些浏览器就会按照我们期望的方式工作（将整个“il”当作州名的前两个字母），但我们想让页面在各种浏览器中都有一致的行为。

1.2.4 城市

这是需要的另一个字段。我们使用一个文本框存储用户的输入值。

其HTML与其他的文本字段一样。

<label for="city">City: </label>

<input id="city" name="city"/>

基本的HTML表单不会对该字段进行任何验证。但我们能否向用户提供一个城市的下拉列表呢，就像选择州名那样？每个州只有确定数量的城市，但其数量倒不少。整个美国大约有30,000多个城市。因此简单的在页面中列出这些值会增加页面的大小，使其加载速度变慢。另外列出所有城市也不太对头；我们需要列出用户所选择的州下的城市。这就需要我们使用一些JavaScript逻辑来进行处理，但在这个简单的表单中我们尽量避免使用JavaScript。

下拉列表的可用性也是一个问题。由于城市数量太多，导致很多城市都以相同的字母开头。敲入城市的首字母只会让用户看到一个长长的列表的开头。用户不得不向下拉动以寻找正确的值——这也太无聊了吧。

1.2.7 邮政编码

邮政编码是账单地址所需的最后一个字段。我们使用一个文本框来存储用户的输入。

其HTML