AJAX模式与最佳实践
第三章 内容分块模式
3.1 目的
内容分块模式使得增量地建立HTML页面成为可能，因此允许分布式的HTML页面逻辑部分存在，并且用户能决定加载内容的时间和逻辑。
3.2 动机
在Web设计早期阶段，HTML内容设计者创建的是一些不完整的文档，通过文档链接使它们完整。完整的文档是文档结构树中所有页面的总和。
思考下边的例子：利用Web，你可以把大量杂志中的文章粘贴到一起，不用以一种连续的方式来完成一本书的内容。但不想杂志那样，需要你一页接一页的翻看；Web允许你点击链接跳转到不同内容。随着时间推移，Web站点已从分布的Web结构转变成有严格层次的独立结构。
图3-1描述了一个严格层次的独立的Web站点例子。
在图3-1中，Web站点被分成两个区域：蓝色背景的导航区域和棕色背景的内容区域。当用户点击导航链接的时候，内容就会随之改变。但问题是整个页面被重新加载，即使用户只关心棕色背景的内容区域。一种不是很好的解决方式就是使用HTML frame，那么导航区域是一个frame，内容区域是一个frame。当点击导航区域的链接时，就只有内容区域frame被更改。然而，尽管frame可以解决独立加载内容的问题，但从导航和用户接口来看是有问题的。因此Web站点渐渐不使用frame了。
理想情况下，网站开发者想要的只是改变需要更新的内容，而不需要更新的不需要改动。毕竟，不涉及的内容仍然一样起作用。
|
目标内容 |
|
导航栏 |
图3-1严格层状结构的Web站点
3.3 适用性
在以下情况下使用内容分快模式：
l 由于网站的特性，无法知道HTML页面真正的样子。如图3-1，有一个蓝色背景的导航区域和一个棕色背景的内容区域。每一个区域的内容都是未知的，但存放内容的区域是已知的。
l 要下载的内容量太大并且用户等候过长时间。例如，进行一次搜索，将找到的所有元素收集起来成为结果集，这样做法不好，因为用户需要等很长时间。一种更好的方式是显示当前找到的内容同时继续搜索。
l 要显示的内容是不相关的。雅虎、MSN和Excite都是并行显示不相关内容的门户应用。如果内容生成为一个单独的HTML页面，那么服务端逻辑就不得不包含大量的判定数据块以确认内容是否需要加载。一种更好的方法是考虑将内容的每一块作为一个分离的片断，然后单独加载。
3.4 关联模式
内容分块模式是任何Ajax应用的核心模式，甚至可以认为内容分块模式是绝配Ajax应用的。即便如此，区别并定义内容分块模式概念仍然很必要。内容分块模式的独特性在于它总是遵照同一过程：产生事件，请求，响应和分块注入。书中其他模式也很相似，但与之相反的是如发送一个请求，并不是得到一个及时的响应（例如，持久通信模式）。
3.5 架构
内容分块模式的架构相对简单些。客户端访问URL，服务器端返回由客户端接收和处理的内容。内容分块模式的实现一般按照如下步骤：
1．点击“按钮”或加载HTML页面后，生成相应的事件；
2．事件调用一个方法，这个方法负责创建要发送请求给服务器的URL；
3．服务器端接收到请求并联合请求内容作为响应返回给客户端；
4．客户端收到回复，并且将其注入到HTML页面中。
3.5.1 在Web应用中的执行顺序
如前面图3-1，Web站点的严格分层结构并不是很糟。至于HTML，这种严格其结果是一步到位的生成内容，这种方式会导致很多问题。传统应用正如图 3-2那样没有此种方式的功能。
图3-2传统客户端应用
在图3-2中，RealPlayer是一个将新的HTML类型技术和传统界面元素混合的传统客户端应用例子。点击“Burn Your CD”按钮，RealPlayer就播放CD，但不会影响此应用上半部分正在播放的广告。与广告关联的逻辑和播放CD关联的逻辑是独立的。不同逻辑片断发生在同一个窗口中。
图3-3把图3-1的Web应用分成了多个不同的逻辑片断。
|
<Get Content 2 #>
|
|
<Get Content 1 #>
|
图3-3Web站点体系结构
如图3-3，原始HTML页面中存在多个链接，如到例子中博客和文章等内容的链接。例子中的内容有两个执行模块：Get Navagition和Get Content（1，2）。用于产生Get Content1的逻辑和用于产生Get Content2的逻辑是不同的。在生成HTML页面时，当执行Get Content1和Get Content2任何一个，Get Navagition的逻辑都要执行。这意味着逻辑Get Navagition会被执行多次，每次都产生相同的数据。一些读者可能会认为Get Navagition产生的是不同的数据（如：打开不同的文件夹），但实际上是以不同格式方式存在的相同数据。简而言之，应该避免产生内在的数据冗余。
解决方案是使用分散逻辑，从而通过类似图3-4的架构来生成HTML页面。
|
<Get Content 2 #>
|
|
<Get Content 1 #>
|
图3-4改进的Web站点结构
在图3-4中，HTML页面是多个服务端逻辑片断结合的结果。当HTML页面主要的轮廓加载后，XMLHttpRequest对象会重新获得Get Navigation、Get Content 1和Get Content 2等内容块。什么时候如何获得单个的内容块依赖于内容块产生的事件和链接。每一个内容块是需要XMLHttpRequest类型对象处理的单独请求。
这里主张的架构有以下优势：
l 客户端仅仅下载必须的内容，不必再获得已经没有用的内容块；
l 结构被分成不同的代码块，能够在不同环境下动态组合；
l 结构类似一个传统的客户端，在客户端只适合于操纵事件的那些元素；
l 因为对于获得内容数据块的父HTML页面来说，生成的代码块代表页面外观，所以整个外观看起来不会受到影响。
如图3-4解释了内容分块模式名字的由来：一个单独的HTML页面是许多内容块的累加，这些内容块被单独引用和加载。
3.5.2 定义内容块中的内容
XMLHttpRequest对象引用的内容块可以是任何客户端和服务器端能理解的形式。无论服务器端发送什么都必须是客户端能理解的。如图3-4，由于数据块被直接注入到HTML页面中，所以内容数据块将会存在HTML中，尽管HTML不是服务器端收发内容的唯一格式。
本章中涉及了以下格式：
l HTML：服务器端直接发送HTML到客户端。接收到的HTML不需要处理，直接注入到HTML页面中。这是一个盲目的处理方法，因为客户端不知道HTML做了什么，只知道将其注入到HTML的某段代码中。直接注入HTML是一种非常安全和简单的内容构建方式。客户端不需要做任何处理，仅仅需要知道HTML内容的目的区域。如果需要处理，接收到的内容（如果是符合XML）将会作为一个有效的实例对象模型。使用实例对象模型，就能手动操作接收到的HTML内容了。建议发送到客户端的HTML内容应该符合XHTML（实现特定XML规范的HTML）格式或至少符合XML格式。
l 图片：由于图片是二进制格式的，且XMLHttpRequest对象不能处理二进制数据，所以直接发送图片是不可能的。特别是图片的引用都是被作为HTML标签注入到HTML文档中的，导致加载远程图片。如果数据以Base64格式进行编码和解码，二进制数据就可以下载和引用了。然而，不推荐直接操作二进制数据，因为使用此方式后会产生更多问题，比使用此方式解决的问题还要多。
l JavaScript：服务器端能够发送JavaScript到客户端，客户端利用JavaScript中eval语句执行JavaScript；并且为了更进一步的处理，客户端能够发送持久的JavaScript对象给服务器。执行任意JavaScript的第一感觉就是安全问题。这不是很特别的问题，因为所有浏览器中JavaScript引擎都具有一样的起源和沙箱机制。如果JavaScript引擎中存在bug，发送任意要执行的JavaScript会产生安全问题。如果需要动态执行和增加在加载HTML初始化页面时没有被加载的客户端逻辑，发送JavaScript是适合的。在客户端没有意识到的情况下，这是一个增强客户端功能的有效方法。举个例子，HTML表单元素的验证。由于不同的用户有不同的确认方式，把所有确认方式都发送到客户端是不想要的。解决方案就是让用户决定需要展现的HTML表单元素，并且动态下载作为内容块的表单元素验证方式。但预先警告，发送的JavaScript数据块会使应用系统对黑客开放。因此在使用此技术前请仔细考虑。
l XML：使用XML收发是首选方式。在客户端能够使用XML对象模型进行转换和解析XML；或者使用可扩展的表单语言转换库，把XML转换成其他对象，如HTML。首选XML的原因：XML是一项众所周知的技术，且操纵XML的工具具有说明详细、运行稳定等优点。XML是一项非常好的已确定的技术，使用此种技术，你不需要写额外的代码就能进行搜索、分段、分块、持久和验证。由于方括号和其他XML字符记号，所以有些人认为XML很繁重。然而优势是当服务器端应用产生XML时，能够被基于Web浏览器和非GUI浏览器的客户端处理。如何解析XML和处理什么信息完全依赖于客户端，只要客户端能够解析XML即可。使用XML应该灵活。贯穿全书，XML被广泛使用且被作为首要的数据交换格式。
还有其他的数据交换格式，如JavaScript对象注解（JSON）1。然而，选择其他格式时，建议多考虑一下使用它们产生的后果。然而对我们当前的设计，有的并不适合。关于其它数据交换格式，对于我来说，它们不能提供一个像处理、查找、验证和产生XML的一样的强大开发环境。例如，使用XPath I不需要解析整个XML文档，就可搜索XML中的特定元素。也承认在某些情况下，XML的性能不如JSON。对于很多读者，并不关心XML的差异，确定他们不需要这些，JSON可能会是更好的技术。然而在本书的其他章节模式内，并没有包括其他技术，如JSON。
既然已经了解了此结构，后面你将会看到一些实现此结构的实例。