上传一个简单的Ajax范例，适合入门学习。
范例内容：无刷新的显示NBLOG的日志标题和内容。
点击查看
再附上一个xmlhttp的类，7K大小，可以适合多浏览器。
点击保存
一、使用Ajax的主要原因
1、通过适当的Ajax应用达到更好的用户体验;
2、把以前的一些服务器负担的工作转嫁到客户端，利于客户端闲置的处理能力来处理，减轻服务器和带宽的负担，从而达到节约ISP的空间及带宽租用成本的目的。
二、引用
Ajax这个概念的最早提出者Jesse James Garrett认为:
Ajax是Asynchronous javascript and XML的缩写。
Ajax并不是一门新的语言或技术,它实际上是几项技术按一定的方式组合在一在同共的协作中发挥各自的作用,它包括:
·使用XHTML和CSS标准化呈现;
·使用DOM实现动态显示和交互;
·使用XML和XSLT进行数据交换与处理;
·使用XMLHttpRequest进行异步数据读取;
·最后用javascript绑定和处理所有数据;
Ajax的工作原理相当于在用户和服务器之间加了—个中间层,使用户操作与服务器响应异步化。并不是所有的用户请求都提交给服务器,像—些数据验证和数据处理等都交给Ajax引擎自己来做,只有确定需要从服务器读取新数据时再由Ajax引擎代为向服务器提交请求。
图2-1
图2-2
三、概述
虽然Garrent列出了7条Ajax的构成技术，但个人认为，所谓的Ajax其核心只有javascript、XMLHTTPRequest和DOM，如果所用数据格式为XML的话，还可以再加上XML这一项(Ajax从服务器端返回的数据可以是XML格式，也可以是文本等其他格式)。
在旧的交互方式中,由用户触发一个HTTP请求到服务器,服务器对其进行处理后再返回一个新的HTHL页到客户端,每当服务器处理客户端提交的请求时,客户都只能空闲等待,并且哪怕只是一次很小的交互、只需从服务器端得到很简单的一个数据,都要返回一个完整的HTML页,而用户每次都要浪费时间和带宽去重新读取整个页面。
而使用Ajax后用户从感觉上几乎所有的操作都会很快响应没有页面重载(白屏)的等待。
1、XMLHTTPRequest
Ajax的一个最大的特点是无需刷新页面便可向服务器传输或读写数据(又称无刷新更新页面),这一特点主要得益于XMLHTTP组件XMLHTTPRequest对象。这样就可以向再发桌面应用程序只同服务器进行数据层面的交换,而不用每次都刷新界面也不用每次将数据处理的工作提交给服务器来做,这样即减轻了服务器的负担又加快了响应速度、缩短了用户等候时间。
最早应用XMLHTTP的是微软,IE(IE5以上)通过允许开发人员在Web页面内部使用XMLHTTP ActiveX组件扩展自身的功能,开发人员可以不用从当前的Web页面导航而直接传输数据到服务器上或者从服务器取数据。这个功能是很重要的,因为它帮助减少了无状态连接的痛苦,它还可以排除下载冗余HTML的需要,从而提高进程的速度。Mozilla(Mozilla1.0以上及NetScape7以上)做出的回应是创建它自己的继承XML代理类:XMLHttpRequest类。Konqueror (和Safari v1.2,同样也是基于KHTML的浏览器)也支持XMLHttpRequest对象,而Opera也将在其v7.6x+以后的版本中支持XMLHttpRequest对象。对于大多数情况，XMLHttpRequest对象和XMLHTTP组件很相似,方法和属性也类似,只是有一小部分属性不支持。
XMLHttpRequest的应用:
·XMLHttpRequest对象在JS中的应用
var xmlhttp = new XMLHttpRequest();
·微软的XMLHTTP组件在JS中的应用
var xmlhttp = new ActiveXObject(Microsoft.XMLHTTP);
var xmlhttp = new ActiveXObject(Msxml2.XMLHTTP);
XMLHttpRequest 对象方法
/**
* Cross-browser XMLHttpRequest instantiation.
*/
if (typeof XMLHttpRequest == ’undefined’) {
XMLHttpRequest = function () {
var msxmls = [’MSXML
for (var i=0; i < msxmls.length; i++) {
try {
return new ActiveXObject(msxmls[i]+’.XMLHTTP’)
} catch (e) { }
}
throw new Error("No XML component installed!")
}
}
function createXMLHttpRequest() {
try {
// Attempt to create it "the Mozilla way"
if (window.XMLHttpRequest) {
return new XMLHttpRequest();
}
// Guess not - now the IE way
if (window.ActiveXObject) {
return new ActiveXObject(getXMLPrefix() + ".XmlHttp");
}
}
catch (ex) {}
return false;
};
XMLHttpRequest 对象方法
|
方法 |
描述 |
|
abort() |
停止当前请求 |
|
getAllResponseHeaders() |
作为字符串返问完整的headers |
|
getResponseHeader("headerLabel") |
作为字符串返问单个的header标签 |
|
open("method","URL"[,asyncFlag[,"userName"[, "password"]]]) |
设置未决的请求的目标 URL, 方法, 和其他参数 |
|
send(content) |
发送请求 |
|
setRequestHeader("label", "value") |
设置header并和请求一起发送 |
XMLHttpRequest 对象属性
|
属性 |
描述 |
|
onreadystatechange |
状态改变的事件触发器 |
|
readyState |
对象状态(integer): |
|
responseText |
服务器进程返回数据的文本版本 |
|
responseXML |
服务器进程返回数据的兼容DOM的XML文档对象 |
|
status |
服务器返回的状态码, 如:404 = "文件末找到" 、200 ="成功" |
|
statusText |
服务器返回的状态文本信息 |
2、javascript
javascript是一在浏览器中大量使用的编程语言，，他以前一直被贬低为一门糟糕的语言(他确实在使用上比较枯燥)，以在常被用来作一些用来炫耀的小玩意和恶作剧或是单调琐碎的表单验证。但事实是，他是一门真正的编程语言，有着自已的标准并在各种浏览器中被广泛支持。
3、DOM
Document Object Model。
DOM是给 HTML 和 XML 文件使用的一组 API。它提供了文件的结构表述，让你可以改变其中的內容及可见物。其本质是建立网页与 Script 或程序语言沟通的桥梁。
所有WEB开发人员可操作及建立文件的属性、方法及事件都以对象来展现(例如，document 就代表“文件本身“这个对像，table 对象则代表 HTML 的表格对象等等)。这些对象可以由当今大多数的浏览器以 Script 来取用。
一个用HTML或XHTML构建的网页也可以看作是一组结构化的数据，这些数据被封在DOM(Document Object Model)中，DOM提供了网页中各个对象的读写的支持。
4、XML
可扩展的标记语言(Extensible Markup Language)具有一种开放的、可扩展的、可自描述的语言结构，它已经成为网上数据和文档传输的标准。它是用来描述数据结构的一种语言，就正如他的名字一样。他使对某些结构化数据的定义更加容易，并且可以通过他和其他应用程序交换数据。
5、综合
Jesse James Garrett提到的Ajax引擎，实际上是一个比较复杂的javascript应用程序，用来处理用户请求，读写服务器和更改DOM内容。
javascript的Ajax引擎读取信息，并且互动地重写DOM，这使网页能无缝化重构，也就是在页面已经下载完毕后改变页面内容，这是我们一直在通过javascript和DOM在广泛使用的方法，但要使网页真正动态起来，不仅要内部的互动，还需要从外部获取数据，在以前，我们是让用户来输入数据并通过DOM来改变网页内容的，但现在，XMLHTTPRequest，可以让我们在不重载页面的情况下读写服务器上的数据，使用户的输入达到最少。
基于XML的网络通讯也并不是新事物，实际上FLASH和JAVA Applet都有不错的表现，现在这种富交互在网页上也可用了，基于标准化的并被广泛支持和技术，并且不需要插件或下载小程序。
Ajax是传统WEB应用程序的一个转变。以前是服务器每次生成HTML页面并返回给客户端(浏览器)。在大多数网站中，很多页面中至少90%都是一样的，比如:结构、格式、页头、页尾、广告等，所不同的只是一小部分的内容，但每次服务器都会生成所有的页面再返回给客户端，这无形之中是一种浪费，不管是对于用户的时间、带宽、CPU耗用，还是对于ISP的高价租用的带宽和空间来说。如果按一页来算，只能几K或是几十K可能并不起眼，但像SINA每天要生成几百万个页面的大ISP来说，可以说是损失巨大的。而AJAX可以所为客户端和服务器的中间层，来处理客户端的请求，并根据需要向服务器端发送请求，用什么就取什么、用多少就取多少，就不会有数据的冗余和浪费，减少了数据下载总量，而且更新页面时不用重载全部内容，只更新需要更新的那部分即可，相对于纯后台处理并重载的方式缩短了用户等待时间，也把对资源的浪费降到最低，基于标准化的并被广泛支持和技术，并且不需要插件或下载小程序，所以Ajax对于用户和ISP来说是双盈的。
Ajax使WEB中的界面与应用分离(也可以说是数据与呈现分离)，而在以前两者是没有清晰的界限的，数据与呈现分离的分离，有利于分工合作、减少非技术人员对页面的修改造成的WEB应用程序错误、提高效率、也更加适用于现在的发布系统。也可以把以前的一些服务器负担的工作转嫁到客户端，利于客户端闲置的处理能力来处理。
四、应用
Ajax理念的出现，揭开了无刷新更新页面时代的序幕，并有代替传统web开发中采用form(表单)递交方式更新web页面的趋势，可以算是一个里程碑。但Ajax都不是适用于所有地方的，它的适用范围是由它的特性所决定的。
举个应用的例子，是关于级联菜单方面的Ajax应用。
我们以前的对级联菜单的处理是这样的:
为了避免每次对菜单的操作引起的重载页面，不采用每次调用后台的方式，而是一次性将级联菜单的所有数据全部读取出来并写入数组，然后根据用户的操作用javascript来控制它的子集项目的呈现，这样虽然解决了操作响应速度、不重载页面以及避免向服务器频繁发送请求的问题，但是如果用户不对菜单进行操作或只对菜单中的一部分进行操作的话，那读取的数据中的一部分就会成为冗余数据而浪费用户的资源，特别是在菜单结构复杂、数据量大的情况下(比如菜单有很多级、每一级菜又有上百个项目)，这种弊端就更为突出。
如果在此案中应用Ajax后，结果就会有所改观:
在初始化页面时我们只读出它的第一级的所有数据并显示，在用户操作一级菜单其中一项时，会通过Ajax向后台请求当前一级项目所属的二级子菜单的所有数据，如果再继续请求已经呈现的二级菜单中的一项时，再向后面请求所操作二级菜单项对应的所有三级菜单的所有数据，以此类推……这样，用什么就取什么、用多少就取多少，就不会有数据的冗余和浪费，减少了数据下载总量，而且更新页面时不用重载全部内容，只更新需要更新的那部分即可，相对于后台处理并重载的方式缩短了用户等待时间，也把对资源的浪费降到最低。
此外，Ajax由于可以调用外部数据，也可以实现数据聚合的功能(当然要有相应授权)，比如微软刚刚在
总之，Ajax适用于交互较多，频繁读数据，数据分类良好的WEB应用。
五、Ajax的优势
1、减轻服务器的负担。因为Ajax的根本理念是“按需取数据”，所以最大可能在减少了冗余请求和响影对服务器造成的负担;
2、无刷新更新页面，减少用户实际和心理等待时间;
首先，“按需取数据”的模式减少了数据的实际读取量，打个很形象的比方，如果说重载的方式是从一个终点回到原点再到另一个终点的话，那么Ajax就是以一个终点为基点到达另一个终点;
图5-1
图5-2
其次，即使要读取比较大的数据，也不用像RELOAD一样出现白屏的情况，由于Ajax是用XMLHTTP发送请求得到服务端应答数据，在不重新载入整个页面的情况下用javascript操作DOM最终更新页面的，所以在读取数据的过程中，用户所面对的也不是白屏，而是原来的页面状态(或者可以加一个LOADING的提示框让用户了解数据读取的状态)，只有当接收到全部数据后才更新相应部分的内容，而这种更新也是瞬间的，用户几乎感觉不到。总之用户是很敏感的，他们能感觉到你对他们的体贴，虽然不太可能立竿见影的效果，但会在用户的心中一点一滴的积累他们对网站的依赖。
3、更好的用户体验;
4、也可以把以前的一些服务器负担的工作转嫁到客户端，利于客户端闲置的处理能力来处理，减轻服务器和带宽的负担，节约空间和带宽租用成本;
5、Ajax由于可以调用外部数据;
6、基于标准化的并被广泛支持和技术，并且不需要插件或下载小程序;
7、Ajax使WEB中的界面与应用分离(也可以说是数据与呈现分离);
8、对于用户和ISP来说是双盈的。
六、Ajax的问题
1、一些手持设备(如手机、PDA等)现在还不能很好的支持Ajax;
2、用javascript作的Ajax引擎，javascript的兼容性和DeBug都是让人头痛的事;
3、Ajax的无刷新重载，由于页面的变化没有刷新重载那么明显，所以容易给用户带来困扰――用户不太清楚现在的数据是新的还是已经更新过的;现有的解决有:在相关位置提示、数据更新的区域设计得比较明显、数据更新后给用户提示等;
4、对流媒体的支持没有FLASH、Java Applet好;
七、结束语
更好的Ajax应用，需要更多的客户端的开发，和对当前的WEB应用理念的思考，而且良好的用户体验，来源于为处处用户考虑的理念，而不单纯是某种技术。
**********************************************************************************************
Ajax Q&A
March 13, 2005: Since we first published Jesse’s essay, we’ve received an enormous amount of correspondence from readers with questions about Ajax. In this Q&A, Jesse responds to some of the most common queries.
Q. Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google’s Ajax applications?
A. Neither Adaptive Path nor Google invented Ajax. Google’s recent products are simply the highest-profile examples of Ajax applications. Adaptive Path was not involved in the development of Google’s Ajax applications, but we have been doing Ajax work for some of our other clients.
Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it?
A. Ajax isn’t something you can download. It’s an approach — a way of thinking about the architecture of web applications using certain technologies. Neither the Ajax name nor the approach are proprietary to Adaptive Path.
Q. Is Ajax just another name for XMLHttpRequest?
A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.
Q. Why did you feel the need to give this a name?
A. I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approach with clients.
Q. Techniques for asynchronous server communication have been around for years. What makes Ajax a “new” approach?
A. What’s new is the prominent use of these techniques in real-world applications to change the fundamental interaction model of the Web. Ajax is taking hold now because these technologies and the industry’s understanding of how to deploy them most effectively have taken time to develop.
Q. Is Ajax a technology platform or is it an architectural style?
A. It’s both. Ajax is a set of technologies being used together in a particular way.
Q. What kinds of applications is Ajax best suited for?
A. We don’t know yet. Because this is a relatively new approach, our understanding of where Ajax can best be applied is still in its infancy. Sometimes the traditional web application model is the most appropriate solution to a problem.
Q. Does this mean Adaptive Path is anti-Flash?
A. Not at all. Macromedia is an Adaptive Path client, and we’ve long been supporters of Flash technology. As Ajax matures, we expect that sometimes Ajax will be the better solution to a particular problem, and sometimes Flash will be the better solution. We’re also interested in exploring ways the technologies can be mixed (as in the case of Flickr, which uses both).
Q. Does Ajax have significant accessibility or browser compatibility limitations? Do Ajax applications break the back button? Is Ajax compatible with REST? Are there security considerations with Ajax development? Can Ajax applications be made to work for users who have JavaScript turned off?
A. The answer to all of these questions is “maybe”. Many developers are already working on ways to address these concerns. We think there’s more work to be done to determine all the limitations of Ajax, and we expect the Ajax development community to uncover more issues like these along the way.
Q. Some of the Google examples you cite don’t use XML at all. Do I have to use XML and/or XSLT in an Ajax application?
A. No. XML is the most fully-developed means of getting data in and out of an Ajax client, but there’s no reason you couldn’t accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data for interchange.
Q. Are Ajax applications easier to develop than traditional web applications?
A. Not necessarily. Ajax applications inevitably involve running complex JavaScript code on the client. Making that complex code efficient and bug-free is not a task to be taken lightly, and better development tools and frameworks will be needed to help us meet that challenge.
Q. Do Ajax applications always deliver a better experience than traditional web applications?
A. Not necessarily. Ajax gives interaction designers more flexibility. However, the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it.
