既然你已经对Ajax产生了兴趣,还要知道重要的一点,即什么时候应该使用Ajax技术,而什么时候不该用。首先,不要害怕在应用中尝试新的方法。我们相信,几乎每个Web应用都能从Ajax技术中获益,只不过不要矫枉过正,过于离谱就行了。从验证开始就很合适,但是不要限制你的主动性。你当然可以使用Ajax提交数据,但也许不能把它作为提交数据的主要方法。
其次,惟一会影响你应用Ajax的就是浏览器问题。如果大量用户(或者特别重要的用户)还在使用比较旧的浏览器,如IE 5、Safari 1.2或Mozilla 1.0之前的版本,Ajax技术就不能奏效。如果这是一些很重要的用户,你就要使用针对目标用户的跨浏览器的方法,而放弃Ajax,或者开发一个可以妥善降级的网站。浏览器支持可能不是一个重要因素,因为Netscape Navigator 4在市场上的份额很小。不过,还是应该查看Web日志,看看你的应用适用什么技术。
如前所述,验证和表单填写就非常适合采用Ajax实现。还可以使用DOM的“拖”技术建立真正动态的网站,如Google的个性化主页(见图1-9)。

图1-9 Google的个性化主页
可以看到,Ajax为Web应用开发提供了新的机会。你不会再因为以往的专用技术或技术折中方案而受到妨碍。利用Ajax,胖客户与瘦客户之间的界限不再分明,真正的赢家则是你的用户。
既然对在哪里使用Ajax已经有所认识,下面再来谈谈应用Ajax的一些设计考虑。许多原则与Web应用的原则并无不同,不过还是有必要强调一下。要尽力减少客户和服务器之间的通信量。如果应用得当,Ajax会使你的应用响应更快,但是如果每次用户从一个域移到另一个域时你都来回传递超量的数据,用户肯定不会满意。如果有疑问,按标准约定行事。如果大多数应用都那么做,可能你也应该那么做。如果还有问题,可以看看Web桌面应用的有关标准。为此已经建立了一些模式,而且以后还会有更多的模式(www.ajaxpatterns.org)。
在刚开始使用Ajax时,你的用户可能不清楚应用的工作机理的。多年来我们一直在告诉用户:Web是以某种(同步)方式工作的,而Ajax则增加了异步组件,可能与之背道而驰。简单地说,不要让用户觉得奇怪。当用户用跳格键离开最后一个域时,如果以前的应用(没有使用Ajax的应用)没有保存表单,那么使用Ajax之后的应用也不要保存表单。
实现Ajax时最重要的问题是要力求简单,完全从用户出发,要尽量“傻瓜化”。要把用户放在心上,不要去做“简历驱动的设计”[4]。如果只是想让新老板接受你,并因此在应用中使用Ajax,这是不合适的;如果使用Ajax能让你的用户有更丰富的体验,那就义无反顾地使用Ajax吧。但是别忘了,你会做,并不意味着你应该做。要理智一些,先考虑你的用户才对。
我们后面还会更多地谈到安全,但是这里需要先说明一点,Ajax有一些安全考虑。记住,可以在浏览器中查看源代码,这说明任何人都能知道你是怎么创建小部件的。建立XHR对象时必须包含统一资源定位符(uniform resource locators,URL),所以可能会有恶意用户修改你的网站,运行他们自己的代码。谨慎地使用Ajax可以降低这种风险。
RSS订阅






收 藏
推 荐