憨厚生

在《Pragmatic AJAX中文問題 A Web 2.0 Primer 》中偶然看到對readyStae狀態的介紹，感覺這個介紹很實在，摘譯如下：

 0: (Uninitialized) the send( ) method has not yet been invoked. 
 1: (Loading) the send( ) method has been invoked, request in progress. 
 2: (Loaded) the send( ) method has completed, entire response received.
 3: (Interactive) the response is being parsed. 
 4: (Completed) the response has been parsed, is ready for harvesting. 

 0 － （未初始化）還沒有調用send()方法
 1 － （載入）已調用send()方法，正在發送請求
 2 － （載入完成）send()方法執行完成，已經接收到全部響應內容
 3 － （交互）正在解析響應內容
 4 － （完成）響應內容解析完成，可以在客戶端調用了

對于readyState的這五種狀態，其他書中大都語焉不詳。像《Foundations of AJAX中文問題》中，只在書中的表2-2簡單地列舉了狀態的“名稱”－－The state of the request. The five possible values are 0 = uninitialized, 1 = loading, 2 = loaded, 3 = interactive, and 4 = complete。而《Ajax in Action》中好像根本就沒有提到這5種狀態的細節。《Professional AJAX中文問題》中雖不盡人意，但還是有可取之處：

There are five possible values for readyState: 
0 (Uninitialized): The object has been created but the open() method hasn’t been called. 
1 (Loading): The open() method has been called but the request hasn’t been sent. 
2 (Loaded): The request has been sent. 
3 (Interactive). A partial response has been received. 
4 (Complete): All data has been received and the connection has been closed. 

readyState有五種可能的值：
0 (未初始化)： (XMLHttpRequest)對象已經創建，但還沒有調用open()方法。
1 (載入)：已經調用open() 方法，但尚未發送請求。
2 (載入完成)： 請求已經發送完成。
3 (交互)：可以接收到部分響應數據。
4 (完成)：已經接收到了全部數據，并且連接已經關閉。

在《Understanding AJAX中文問題: Using JavaScript to Create Rich Internet Applications》中，則用下表進行了說明：

根據以上幾本書中的關于readyState五種狀態的介紹，我認為還是《Pragmatic AJAX中文問題 A Web 2.0 Primer 》比較到位，因為它提到了對接收到的數據的解析問題，其他書中都沒有提到這一點，而這一點正是“(3)交互”階段作為一個必要的轉換過程存在于“(2)載入完成”到“(4)完成”之間的理由，也就是其任務是什么。歸結起來，我覺得比較理想的解釋方法應該以“狀態：任務（目標）+過程+表現（或特征）”表達模式來對這幾個狀態進行定義比較準確，而且讓人容易理解。現試總結如下：

概而括之，整個XMLHttpRequest對象的生命周期應該包含如下階段：
創建－初始化請求－發送請求－接收數據－解析數據－完成

在具體應用中，明確了readyState的五個狀態（XMLHttpRequest對象的生命周期各個階段）的含義，就可以消除對Ajax核心的神秘感（語焉不詳的背后要么是故弄玄虛，制造神秘感；要么就是“以其昏昏，使人昭昭”），迅速把握其實質，對減少學習中的挫折感和增強自信心都極其有益。

比如，通過如下示例：

//聲明數組
var states ＝ [“正在初始化……”,
“正在初始化請求……成功！
正在發送請求……”,
“成功！
正在接收數據……”,
“完成！
正在解析數據……”,
“完成！
”];
//回調函數內部代碼片段
if (xmlHttp.readyState==4)
{
var span = document.createElement(“span”);
span.innerHTML = states[xmlHttp.readyState];
document.body.appendChild(span);
if (xmlHttp.status == 200)
{
var xmldoc = xmlHttp.responseXML;
//其他代碼
}
//別忘記銷毀，防止內存泄漏
xmlHttp = null;
}else{
var span = document.createElement(“span”);
span.innerHTML = states[xmlHttp.readyState];
document.body.appendChild(span);
}

結果如下：

正在初始化請求……成功！
正在發送請求……成功！
正在接收數據……完成！
正在解析數據……完成！

我們很容易明白XMLHttpRequest對象在各個階段都在做什么。因此，也就很容易對Ajax的核心部分有一個真正簡單明了的理解。

本博PS：readyState一般用在異步請求時程序響應的判斷，Iframe， javaScript腳本同樣適用,參考另一篇文章：http://d-tune.javaeye.com/blog/506074

文章出處：http://www.cn-cuckoo.com/2007/07/16/the-details-for-five-states-of-readystate-9.html

基本概念 
資源庫（Repository） 
CVS的資源庫存儲全部的版本控制下的文件copy，通常不容許直接訪問，只能通過cvs命令，獲得一份本地copy，改動后再check in（commit）回資源庫。而資源庫通常為與工作目錄分離的。CVS通過多種方式訪問資源庫。每種方法有不同目錄表示形式。 
版本（Revision） 
每一個文件的各個版本都不相同，形如1.1, 1.2.1,一般1.1是該文件的第一個revision，后面的一個將自動增加最右面的一個整數，比如1.2, 1.3, 1.4...有時候會出現1.3.2.2，原因見后。revision總是偶數個數字。一般情況下將revision看作時CVS自己內部的一個編號，而tag則可以標志用戶的特定信息。 
標簽（Tag） 
用符號化的表示方法標志文件特定revision的信息。通常不需要對某一個孤立的文件作tag，而是對所有文件同時作一個tag，以后用戶可以僅向特定tag的文件提交或者checkout。另外一個作用是在發布軟件的時候表示哪些文件及其哪個版本是可用的；各文件不同revision可以包括在一個tag中。如果命名一個已存在的tag默認將不會覆蓋原來的； 
分支（Branch） 
當用戶修改一個branch時不會對另外的branch產生任何影響。可以在適當的時候通過合并的方法將兩個版本合起來；branch總是在當前revision后面加上一個偶數整數（從2開始，到0結束），所以branch總是奇數個數字，比如1.2后面branch為1.2.2，該分支下revision可能為1.2.2.1,1.2.2.2,... 
沖突（Conflct） 
完全是純文本的沖突，不包含邏輯上的矛盾。一般是一份文件，A做了改動，B在A提交之前也做了改動，這樣最后誰commit就會出現沖突，需要手工解決沖突再提交。 

CVS與eclipse集成開發 
  前面對CVS的歷史、功能、概論等理論知識做了介紹。下面我們將使用最流行的Java IDE Eclipse中內置的CVS工具，以一個完整開發流程，介紹實際環境中CVS的正確使用。關于CVS系統的安裝，不是本文的內容，您可以從附錄的鏈接中獲取安裝的介紹資料。 

常用的CVS控制命令 
Check Out（檢出） 
把源文件從cvs源代碼倉庫中取出，缺省的版本是最新的版本，你也可以選擇指定的版本。在每次更改源代碼之前，需要Check Out最新的版本，再起基礎之上對源代碼進行修改。將代碼目錄checkout到指定目錄下，所有文件都是read-write。 
Check In（檢入） 
把源代碼加入到cvs源代碼倉庫中，每一個添加進代碼庫中的文件的版本是 1.1。以后每次修改文件重新ci以后，此文件的版本遞增為1.2 ，1.3.……。在每次對源代碼修改之后，需要Check In，提交最新版本的源代碼。 
Synchronize with Repository(與資源庫同步，簡稱同步) 
使本地更改與資源庫同步，它會列出本地和資源庫之間不同的所有文件。 
Add to Version Control 
將新的文件加入到版本控制之中。 
Add to .cvsIgnore 
將文件設置到版本控制之外，這樣該文件或目錄中的文件的更改在CVS中不可見，即使同步也無法發現。

CVS正確使用步驟 
一、 同步（Synchronize） 
就是將本地更改與服務器同步，同步之后可以清晰的看到上一撿出（Check Out）版本之后本地、服務器上的最新改動。這是非常有用的，特別是敏捷開發，強調集體擁有代碼。有了同步功能，你可以全局把握項目的代碼，可以很方便的跟蹤公共模塊代碼的任何改動。 
具體操作：在Eclipse的資源視圖（Resource Perspective）或者Java視圖（Java Perspective）中，選中要同步的目錄，點擊右鍵選擇"Synchronize with Repository",之后它將顯示同步的視圖。如下圖： 

(圖一、CVS同步視圖) 
同步之后，它有四種Mode可以選擇，見上圖綠色框框里按鈕。從做到右分別為： 
Incoming Mode：表示修改是來自服務器，對應于更新（update）操作。 
Outgoing Mode：表示修改是來自本地，對應提交（commit）操作。 
Incoming/ Outgoing Mode：本地和服務器修改都在該模式（Mode）中顯示。 
Conflicts Mode：顯示本地和服務器修改的沖突文件。 
二、 更新（update） 
比較簡單，選擇Incoming Mode，再選中要更新的文件，右鍵選擇update操作。 
三、 解決沖突并合并(solve conflct and merge) 
如果有沖突文件，沖突文件不能更新。你必須先解決沖突再操作。選中沖突的文件，再點右鍵選擇"Open in Compare Editor"，用比較工具打開該文件。如下圖： 

（圖二、CVS比較器視圖）

比較器（Compare）視圖，左邊版本底的是本地文件（Local File），右邊是遠程服務器文件（Remote File）。使用"Select Next Change"按鈕（綠框中的第一箭頭向下按鈕），逐一查看不同點。如果不同點標識為黑色框框，則不用管它。如果是藍色框框，則需要手工調整。如上圖，不同點是藍色框框，將鼠標放到兩個不同點的中間小方框中，則凸出一個向右的按鈕，并顯示提示信息"Copy Current Change from Right to Left"，意思是將右邊服務器的不同點覆蓋到左邊的本地文件。點中此按鈕。重復這樣的操作，將所有服務器上的更改拷貝到本地。 
如果有一行代碼，本地和服務器都同時做了修改。這時，修改點則顯示紅色框框。這時，你就必須手工做正確的修改。全部修改完成，保存本地文件。 
此時，如果修改點沒有了藍色的框框，就可以開始做合并（merge）操作了。操作也很簡單，選擇該文件，點擊右鍵，選擇"Mark as merged"。 
注意：必須確保沒有藍色框框，即完全拷貝了服務器的修改才可以做合并（merge）操作，否則會覆蓋服務器上的代碼。 
四、 提交（commit） 
更新服務器代碼，解決沖突之后，首先要查看本地文件修改之后是否有錯誤。如果有，當然首先解決錯誤，再提交。