《Ajax模式与最佳实践》后5章的勘误

来源:互联网 发布:php接口编程 编辑:程序博客网 时间:2024/05/17 03:51
第7章

201页
原文:仅仅是因为传统编程习惯
改为:仅仅是因为传统的编程习惯

202页
原文:模型的用户可以选择直接操作模型或者使用辅助函数
改为:模型的用户可以选择直接操作模型或者使用辅助函数来操作模型

203页
原文:导航的状态应该使用不用的表现来进行展示
改为:导航的状态应该使用不同的表现来进行展示

204页
原文:表现变形模式可能需要关于状态标识操作的一点灵活性,而不是状态值方面的灵活性。当然,理想的解决方案是在不同的表现之间包含100%相同的状态标识
改为:表现变形模式可能需要在状态标识方面有一点灵活性,而不是在状态值方面的灵活性。当然,理想的解决方案是跨不同的表现拥有100%相同的状态标识

205页
原文:与表现相关的逻辑被用来操作状态,而不是保存状态
改为:与表现相关的逻辑被用来操作状态,而不是保持状态

206页
原文:因为状态改变是动态的,包括了状态存储的类型
改为:因为状态改变是动态的,包括了已存储状态的类型

207页
原文:W3C的CSS建议的制订者之一,公认的CSS权威
改为:Effective C++的作者

209页
原文:当状态被编辑时,表现包含了新的值又变回了图7-9
改为:当状态被编辑完之后,表现包含了新的值又变回了图7-9

原文:转换块被有效地用于将状态从一种表现转换到另一种表现
改为:转换功能被有效地用于将状态从一种表现转换到另一种表现

213页
原文:在这里的状态就是模型,包含在div子元素内
改为:在这里的状态就是模型,包含在一个div子元素内

原文:这些共同点可以是通过包含在HTML内容中的XML结构展示的一个相同状态,也可以是相同的一组方法
改为:这些共同点可以是通过包含在HTML内容中的XML结构展示的一个相同的状态,也可以是一组相同的方法

214页
原文:extractState方法获取与表现关联在一起的状态作为对象实例
改为:extractState方法获取与表现关联在一起的状态作为一个对象实例

原文:在迭代的过程中,这些实现了一种编码标准的元素对状态进行表现
改为:在迭代的过程中,从这些实现了一种编码标准的元素中提取出状态

217页
原文:通过使用用来分配方法assignState和extractState的动态扩展功能
改为:通过使用用来设置方法assignState和extractState的动态扩展功能

218页
原文:通过将通用的例程、赋值的元素、精确的调优组合在一起
改为:通过将通用的例程与分配的元素、细粒度的调优组合在一起

原文:函数的参数内容通过HTML元素的title属性来驱动。参数的内容是从span元素获取的结果
改为:ddrivetip函数的参数内容通过HTML元素的title属性来驱动。参数的内容是从一个span元素获取的内容

原文:使用XHTML元素的标识符来把数据处理的繁重工作委托给Web浏览器
改为:使用XHTML元素的标识符(译者注:即,标准的XHTML标签和属性)来把数据处理的繁重工作委托给Web浏览器

219页
原文:要转换的内容就是其他的表现,结果则是另一种转换
改为:要转换的内容就是其他的表现,结果则是另一种转换形式

原文:这些通用的标签被认为是与内容无关的,因此能够被其他未知的标签所环绕
改为:这些通用的标签能够被其他未知的标签所环绕,那些标签被认为是与内容无关的

220页
原文:xsl:text标签嵌入了<、"、<标识符
改为:xsl:text标签嵌入了<、"、>这些标识符

221页
原文:你可能已经注意到了定制的元素属性
改为:你可能已经注意到了自定义的元素属性

222页
原文:在Mozilla Firefox中加载的模式特定的页面
改为:在Mozilla Firefox中加载的模式细节的页面

223页
原文:在微软IE中加载的模式特定的页面
改为:在微软IE中加载的模式特定的页面

原文:通过使用setAttribute方法赋值对象实例的属性作为元素属性
改为:通过使用setAttribute方法赋值为一个对象实例的属性,作为元素属性

原文:通过动态赋值的属性
改为:通过动态地赋值的属性


第8章

227页
原文:一组授权用户组能够访问资源
改为:一组授权的用户能够访问资源

原文:由服务器来决定如何在已识别的用户与(cross-referenced)唯一资源之间建立交叉建立引用
改为:由服务器来决定如何在已识别的用户与唯一资源之间建立交叉引用(cross-referenced)

228页
原文:使解耦导航模型模仿持久通信模式的行为会更有意义
改为:使解耦导航模式模仿持久通信模式的行为会更有意义

原文:你可能回想起这种问题已经以其他方式解决过了
改为:你可能会想到这种问题可能已经以其他方式解决过了

232页
原文:在此期间之内客户端和服务器两者之间能够进行通信
改为:在此期间之内客户端和服务器两者之间不能够进行通信

原文:因为当客户端等待来自服务器响应的同时
改为:因为当客户端等待来自服务器的响应的同时

234页
原文:任何的访问全局状态资源的客户端将接收相似的资源表现
改为:任何的访问全局状态资源的客户端将接收到相似的资源表现

237页
原文:属性callDelay、index、instances和instanceCount与需要解决的问题有关
改为:属性callDelay、index、instances和instanceCount与它们需要解决的问题有关

241页
原文:然而,我们已经使用过实现了IHttpHandler接口的ASP.NET处理器(handler)
改为:然而,也可以使用实现了IHttpHandler接口的ASP.NET处理器(handler)

原文:这里的思想是使用单一的处理器响应来处理服务器端资源
改为:这里的思想是使用单一的处理器负责处理一个服务器端资源

244页
原文:这样ASP.NET或JSP的页面能够处理实际的请求
改为:这样一个ASP.NET或JSP的页面能够处理实际的请求

原文:因为我们正在讨论的重定向是在置换模式中所概述过的那个重定向
改为:因为我们正在讨论的重定向是在置换模式中所描述过的那个重定向

251页
原文:如果用户标识(_user)已经存在于用户列表(_users)中,版本号(_version)将会递增,
改为:如果用户标识(_user)已经存在于用户列表(_users)中,什么也不会发生;如果用户不存在,版本号(_version)将会递增,

252页
原文:唯一标识也可以是一个提供的标识
改为:唯一标识也可以是一个提要(feed)的标识

253页
原文:URL必须是唯一的,问题在于如何确定基于全局资源
改为:URL必须是唯一的,这可能是一个问题,因为我们起初并不知道这个URL。问题在于如何确定基于全局资源

254页
原文:它在服务器上调用了一种方法,生成了一个URL
改为:它在服务器上调用了一个方法,生成了一个URL

255页
原文:假设发送电子邮件向用户询问更新的细节这样一种场景
改为:假设发送电子邮件给用户,请求他更新细节的这样一种场景

257页
原文:属性_userIdentifier和_state是只读的
改为:属性_userIdentifier和_version是只读的

原文:相反的,每次setState方法被调用时
改为:然而,每次setState方法被调用时

261页
原文:用户的标识无法与用户的认证信息相关联
改为:用户的标识不能与用户的认证信息相关联

原文:用户认证可能与管理员确认某个特定URL的情况相同
改为:用户认证信息可能与在管理员确认某个特定URL时的情况相同(译者注:即,不能使用用户的认证信息来作为唯一的标识,因为用户的认证信息会被使用在多个场合)

262页
原文:这种方式也带来了一个问题,为什么不使用状态呢?
改为:这带来了一个问题,为什么不使用状态呢?


第9章

265页
原文:或者要求让从特定的机场起飞
改为:或者要求从特定的机场起飞

267页
原文:我们偏离Web和HTTP协议最初被设计的意图
改为:我们偏离了Web和HTTP协议最初被设计的意图

268页
原文:因为可以应用表现变形模式将静态表现转换为可编辑表现
改为:因为可以应用表现变形模式将一个静态表现转换为一个可编辑表现

275页
原文:这些信息能够唯一地标识窗口并且用来将HTML页面采用链接在一起
改为:这些信息能够唯一地标识窗口并且用来将HTML页面链接在一起

原文:并且完美地适合于唯一确定的单独HTML窗口
改为:并且完美地适合于唯一地确定单独的HTML窗口

279页
原文:HTTP POST期待数据在它被获取之前发送
改为:HTTP POST期待在获取到数据之前,先发送数据

280页
原文:但是这种实现使用了HTTP服务器中已经存在的装饰器模式工具
改为:但是是通过使用HTTP服务器中已经存在的装饰器模式工具来实现的

283页
原文:因为这个过程要求在HTML页面注入HTML表单发送的过程
改为:因为这个过程要求在HTML页面注入HTML表单发送的过程(HTML form-posting process)

288页
原文:因为获取了状态,服务器有能力来确定状态标识符
改为:因为获取到了状态,服务器有能力来确定状态标识符

291页
原文:当调用了一段使用了HTTP GET技术的脚本时
改为:当调用了一段使用了HTTP GET技术的脚本时(译者注:即页面中的loadState方法)

原文:服务器上通常的模式实现模式没有尝试对这些状态做出解析
改为:服务器上通用的模式实现没有尝试对这些状态做出解析

原文:这些状态在服务器端通过使用HTTP处理程序进行处理
改为:这些状态在服务器端通过使用HTTP处理器(handler)进行处理

293页
原文:状态导航模式通过使用TriggerFilter类
改为:状态导航模式通过使用TriggerFilter类实现

296页
原文:这里的思想是过滤器管理状态的获取并且保存调用
改为:这里的思想是过滤器管理对于状态的获取和保存的调用

原文:并且被传递给isTrigger和runFilter过程
改为:并且被传递给isTrigger和runFilter例程

299页
原文:接着使用方法copyState将旧状态拷贝到新状态
改为:使用方法copyState将旧状态拷贝到新状态

301页
原文:也可以执行内存拷贝
改为:也可以执行in-place(译者注,这里保留原文是因为很难翻译)拷贝

原文:使得管理和积聚状态,以及通过一个进程使用这些状态来执行单个的事务变得更加简单
改为:使得管理和积聚状态,并且通过一个过程(process)使用这些状态来执行单个的事务变得更加简单


第10章

303页
原文:状态导航模式提供了导航HTML内容的基础设施,当从一部分内容导航到另一部分内容时,状态维持不变。
改为:无限数据模式的目的是以一种适时的方式管理和显示表面上无限的数据。

304页
原文:这些场景的列举如下
改为:这些场景列举如下

原文:无限数据模式用来从一个表面上无限的数据集中及时地展现数据
改为:无限数据模式用来从一个表面上无限的数据集中适时地展现数据

308页
原文:这个实现想要展示的是一种及时地显示表面上无限数据的能力
改为:这个实现想要展示的是一种适时地显示表面上无限的数据的能力

309页
原文:而是应用的一种“有了更好”的特征
改为:而是应用的一种“有了更好”的功能

321页
原文:接收结果(黑体小标题)
改为:获取结果

323页
原文:例如,类型xs:int是Number的schema定义
改为:例如,类型xs:string是Number的schema定义

324页
“为了在Java中得到相同的效果”下面的代码需要将“partial”去掉,Java并不支持partial class

329页
原文:这里用到的同步机制是一台监视器
改为:这里用到的同步机制是一个监视器

330页
原文:当GetResultWait方法执行了Monitor.Wait时
改为:当GetResultWait方法执行了Monitor.Enter时


第11章

334页
原文:但是这并不意味着一个应该下载并运行一个2MB大小的JavaScript文件
改为:但是这并不意味着应该下载并运行一个2MB大小的JavaScript文件

344页
原文:这意味着在请求和响应的结构中有一个有效值,而且在响应的结构中有一个默认值
改为:这意味着在请求或响应的结构中有一个有效的值,而且在响应的结构中有一个默认的值

349页
代码中的:
“译者注:原文此处代码有误,应该是queryIdentifier,而不是transactionIdentifier”
译者注这句话应该删除,同时前面代码中的queryIdentifier改为transactionIdentifier
非常抱歉,这里其实是译者翻译时的理解有误。

353页
原文:控制器将会在本地客户端上执行迭代,并通过使用getIdentifier方法来查询本地客户端
改为:控制器将会对本地客户端进行迭代,使用getIdentifier方法来查询本地客户端

354页
原文:另一种方法就是实现一个建造器模式
改为:另一种方法就是实现一个创建器模式

原文:为本地客户端实现构造器模式的一个例子如下
改为:为本地客户端实现创建器模式的一个例子如下

原文:方法在本地客户端实例化之后将默认的配置分配给Amazon.com或者Google的本地客户端
改为:方法在本地客户端被实例化时将默认的配置设置给Amazon.com或者Google的本地客户端

原文:但是这些字符串将会被转换成一些类型,assignConfiguration方法将会引用这些类型
改为:但是这些字符串也可以被转换为一些类型,assignConfiguration方法能够引用这些类型

357页
原文:并使得请求信息可获得
改为:并使得请求的信息可以获得

358页
原文:最佳的方式是每个本地客户都独自等待
改为:最佳的方式是每个本地客户端都独自等待

363页
原文:每个会话都与一个AsynchronousParent实例相关联,它使用一个cookie来收集所有的结果
改为:一个AsynchronousParent实例与一个会话相关联,这个会话是一个cookie,用来收集所有的结果

原文:当使用HTTP GET请求时,持久通信模式只需要一个成功信息作为结果
改为:当使用HTTP POST请求(译者注:原文中此处有误,GET应为POST)时,持久通信模式只需要一个成功信息作为结果

364页
原文:客户端需要处理它这个标识
改为:客户端需要处理这个标识

原文:这里所概述的架构的想法就是模拟Java Servlet或ASP.NET处理器的重定向基础架构
改为:这里所描述的架构的想法就是模拟Java Servlet或ASP.NET处理器的重定向基础架构


原创粉丝点击