例如:

link_to 'Logout', session_path, :method => :delete

產生出來的是:

<a href="/session" data-method="delete" rel="nofollow">Logoout</a>

例如

link_to 'Ajax delete', person_path(person),
      :remote => true, :confirm => "Are you sure?"

產生出來的是

<a href="/people/1"  data-confirm="Are you sure?" data-method="delete"
              data-remote="true" rel="nofollow">Ajax delete</a>
# 點下去會向 Server 要求 JavaScript 內容執行

Rails3 預設還是使用 Prototype.js，要換成 jQuery 非常簡單。首先在產生 rails 專案時，可以輸入 rails your_project -J 就不會產生 Prototype.js 的檔案。

修改 /public/javascripts/rails.js 這個檔案，內容換成 http://github.com/rails/jquery-ujs/blob/master/src/rails.js 這個官方提供的 jQuery js driver。

在 Rails layout 的 HTML head 中加入:

<%= csrf_meta_tag %>
<%= javascript_include_tag "http://ajax.googleapis.com/ajax/libs/jquery/1.4.1/jquery.min.js" %>
<%= javascript_include_tag 'rails' %>

其中 csrf_mate_tag 產生的是做 CSRF 防禦的 authenticity_token，以往這也是 inline 在 HTML 中，現在則是先宣告在 HTML head 中。

另外要提醒你，如果你有使用 RJS 的話，Rails3 的 RJS 還是只會產生 prototype.js 的版本。所以如果非得用 RJS 的話，目前恐怕還是得裝以往 Rails2 用的 jRails，這好像有點蠢。也許是時候把 RJS 徹底揚棄，直接寫 jQuery 好了(?)

例如上面的 Ajax delete 例子，它的 controller 跟 js 可以這樣:

# people_controller.rb
  def destroy
    @person = Person.find(params[:id])
    @person.destroy

    respond_to do |format|
      format.html { redirect_to(people_url) }
      format.js # destroy.js.erb
    end
  end

# destroy.js.erb
jQuery("#<%= dom_id(@person)%>").remove();

1. 下載 jQuery (建議你可以考慮用 jRails 完全換掉 Prototype library)
2. 下載 facebox
3. 把 facebox js file 放到 /public/javascripts/
4. 把 facebox css file 放到 /public/styleshees/
5. 把 facebox all image files 放到 /public/facebox/
6. 設定好 layout 的 stylesheet_link_tag 和 javascript_include_tag 加入這些 js,css 檔案

facebox-render 目前放在 github，請下載後放到 vender/plugins/facebox_render

然後在你要使用的 Controller 加入以下程式碼

 include FaceboxRender

或是你直接放到 /app/controllers/application.rb 裡面也是可以。

回到 view code，當你要叫出一個 lightbox :

 facebox_link_to "Login", :url => login_url

或是你也可以用 remote_link_to, remote_form_tag 等Rails內建的 Ajax Helper，差別在於 facebox_link_to 會先秀出一個 Loading lightbox，然後再送 Ajax request。

重頭戲是 action :

def new
 # do some thing you want
 respond_to do |format|
  format.html
  format.js { render_to_facebox }
 end
end

這裡巧妙的運用了 respond_to 來處理 ajax request，預設的 render_facebox 會 render 不帶 layout 的HTML(即 new.html.erb)。當然我們也支援傳入 :action, :template, :partial 等常見的Rails參數，或是乾脆傳入 :html 也可以。

傳入 :msg 的話，會插入一段 <div class=”message”>your msg</div> 到裡面去，方便你做一些提示或警告訊息。

除了 render_facebox，也有 close_facebox 可以關掉 lightbox。也可以用 redirect_from_lightbox 重新讀取另一頁。

實際的應用非常方便，你可以在網頁中用 remote link 或是 remote form submit 叫出 facebox。在 facebox 中也還可以再放 remote link 或 remote form submit，接收處理的 action 可用 render_facebox 或關掉 close_facebox 抑或重新讀取頁面 redirect_from_facebox。

FaceboxRender 的隨附文件請見 README 。

P.S. 這篇文的英文版在 Handlino’s blog

spakit 目前放在 github，另外也包成 gem，安裝方式如下:

 gem install spakit
 cd /your_rails_app/vendor/plugin
 gem unpack spakit
 mv spakit-0.9.0 spakit

並且 rename 成 spakit。裝好之後，首先建立一個 Spakit 專用的 Layout，一個簡單的範例如下:

# /view/layouts/spakit.rhtml
<p><%= flash[:notice] %></p>
<%= yield %>

接著就可以使用 Spakit 專用的 helpers，目前有 spakit_link_to, spakit_form_for 和 spakit_form_tag 三種可以使用，用法如下:

spakit_link_to 'new person', :url => new_person_path
spakit_form_for @person, :url => people_path

如此按下連結或送出表單後，Spakit 就會送出 Ajax request(i.e. prototype’s Ajax.Updater )，然後將回傳的 HTML 結果更新到#content 區塊。

如果你想要支援 Ajax 的 Histroy Bookmarks，建議可以採用 Really Simple History(RSH) library 來處理瀏覽器的上一頁下一頁問題，這部份的範例程式附在 plugin 的 README (使用到 jquery library，好心人有空可以幫忙寫 prototype version)。

P.S. 這篇文的英文版在 Handlino’s blog

就如同 Ruby 版的 ActiveResource，Jester是一個 JavaScript Library 可以讓你操作 Rails-style resources，而且語法跟 ActiveResource 十分類似(除了new變bulid)。這樣的東西可以幹麻呢? 它(應該要)可以幫助我們輕易做出 使用 RESTful service 的 Ajax Application (please see Ajax and REST, Part 1, Part 2 )

不過，咳咳~ 它目前 1.是 synchronous 的 (作者正著手改成 asynchronous ，應該不難多 callback 參數即可)  2.用XML，如果可以支援 JSON會更棒  3. Depends on Prototype 跟 ObjTree 兩個 Library。

題外話，最近 Rails Edge 把 RESTful routing 的 semi-colon (;)  改成 forward-slash (/) 了，吱吱。

相對於 W3C DOM 跟 XMLHttpRequest，Events有更多的 Browser Wars 留下來的問題，有著 Microsoft 蓄意的不相容問題，你必須注意這些實做差異，有些解法甚至有些 tricky，而且必須 case by case，沒有泛用型的偵測法則，例如沒有簡單的 if (W3C model) {.. } else if ( Microsoft model ) { … } 可以用。

Events 可分成三種類型 1. 滑鼠事件 mouse 2. 鍵盤事件 keyboard 3. 界面事件 interface events (例如 form submit,readystatechange等)

click是唯一自動有 accessible 的mouse event，因為當鍵盤 focus 且按 Enter 時也會觸發。而其它mouse events必須手動再加對應的keyboard events，例如 mouseover 等同於 focus，mouseout等於blurred，但有些對應就難了，例如 mousemove (滑鼠移動一個1px就觸發一個事件，但要對應鍵盤就不行了)。因此在 DOM Scripting 這本書也建議(p.111)，設了 onclick 的就不要設定 onkeypress event了，因為 click 除了滑鼠，鍵盤也會有作用，多設 onkeypress 反而可能會有新麻煩。

另外一個 keyboard 的 accessability 重點是，可以被 keyboard focus 的元素只有 links,form fields,buttons 這四樣，這是個需要注意的事情，任何 keyboard-frientld event 或 script 都必須設定在這三種元素上面，例如在寫 mouseover 的鍵盤等價方案的時候，畢竟要可以被使用者按 tab 移動到，寫 event script 才有用…:p

Event-handler 註冊的四種方法:

1. inline ，例如直接在element中寫 onclick=”test()”  

2. traditional model，例如 x.onclick= test 

3. W3C model ，例如 x.addEventListener(‘click’,test,false) 或移除 x.removeEventListener(‘click’,test,false)

4. Microsoft model，例如 x.attachEvent(‘onclick’,test) 或移除 x.detachEvent(‘onclick’,test)

要為後兩者做一個跨瀏覽器的解法並不難，object detection 一下即可。

法一是 JavaScript亂入，不要用。

法二 traditional model 的問題是，無法連續為 x 掛載不同的事件，例如 x.onclick = test; x.onclick = test2 就只剩下 test2 了。因此需要再寫一個 function 包起來，如 x.onclick = function () { test(); test2(); }，比較不彈性一點，但如果你可以完整掌握 page 到底有哪些 script，作者建議你可以用 traditional model。

法三法四比較先進(?)是用 事件掛載的方式，讓各個 script 都不會互相影響到。不過有趣的是竟然無法得知 x 已經掛載多少 event handlers，而如果不知道掛載了什麼，就無法移除。

接著是 W3C model 和 Microsoft model 的兩個重大差異，Microsoft model 不支援 event capturing，只有 bubbling(請參考 O3noBLOG  addEventListener的第三個參數 ) 。另外就是 Microsoft model  把 event-handler function 當成一般 global function 來處理，也就是如果你用法四 attachEvent 來註冊事件時， event handler裡面的 this 指的是 window 而非發生事件的 object。(作者推薦 Dean Edward’s solution 可以fix)

event bubbling 能有什麼功效? 你可以非常有效率的只設定一個event handler到一個HTML element，然後就可以處理那個element裡面一整群的element，因為它會 bubbling 上去觸發。例如作者的 Usable Forms 的範例中，有132個 form fields，他不想每個都給他加上 event hander，這時就可以利用 event bubbling 在 document 加上 click event 即可，觸發任一個field都會 bubbling 上去到 document，然後在 event handler 中再來根據被觸發的 element 來決定做什麼動作。

在 event handler中，瀏覽器會自動產生一個 event object，W3C model 是根據第一個參數，Microsoft 則總是window.event，因此程式是

document.onclick = handleEvent;
function handleEvent(e) {
var evt = e || window.event;
var evtTarget = evt.target || evt.srcElement;
}

這個 event object 包含了觸發這個事件的 event type (即mouseover 或 keypress 等等)、觸發的 target element ( W3C叫 target, Microsoft叫 srcElement)、觸發時的滑鼠位置(跨瀏覽器處理很複雜，作者不建議去用。而且大部分的情況可以改用你觸發的element的相對位置來解決，第九章會詳述)、觸發時按下的滑鼠button跟鍵盤button 等等資訊。

注意到觸發事件的element跟 當初被定義 event handler 的 element 並不一定相同 (因為event bubbling)，因此 target element 並不一定等於 this。在 traditional跟W3C model中，this 指被定義event handler的 element。但如前所述，微軟的 this 指成 window，也就是如果你有用微軟 attachEvent 這個 this 等於沒什麼用。

看樣子用 evtTarget 好像比較好? 不過瀏覽器對於到底是 “哪個element” 觸發也有不同看法!! 所以尤其是碰到 mouseover,mouseout 你必須特別check抓到的 element是你要的。

所以結論是到底用那種啦? (跨平台 event 果然難搞) 如果你不用Microsoft model的 addEvent的話，而且要被觸發的element跟被定義的element是同一個的話 (不玩event bubbling)，那作者推薦用 this 吧。

注意到在DOM Scripting那本書中，Event-handler 完全使用 traditional model 法，也沒有用 event bubbling 進階手法，因此他的 this 一律就是 target element。

最後提一下 Yahoo! UI Library: Event，裡面的 Automatic Event Object Browser Abstraction 跟 Automatic Scope Correction 就是修正那兩個問題。

(待續，第八章 DOM 第九章 CSS 第十章 Ajax ) 

相關書評

• ppk on JavaScript (Book review)
• Digital Web Magazine – ppk on JavaScript

前兩章 Purpose 跟 Context 非常非常精采，作者就像說故事一樣娓娓道來，全貌性把 JavaScript 的來龍去脈講了一遍，Realazy有做了書摘( JavaScript的目的、背景一、背景二、背景三 )，我就不多詳述了。

第三章 Browsers 瀏覽器議題。各家瀏覽器介紹，以及常見的瀏覽器問題 1.瀏覽器不支援某些JavaScript功能 2.合法的規格解釋差異，但此種情況較少 3.瀏覽器故意有所差異，例如 IE用 srcElement 而其他符合標準的用 target，但通常只是名字不同而已，很容易處理 4.瀏覽器bug

作者花很多篇幅強調處理瀏覽器問題的最好方法就是 object detection，而千萬不要用 browser detection。例如他最得意的 DOM 支援檢查 :

var W3CDOM = document.createElement && document.getElementsByTagName; 

最後介紹一些簡單的 debug 方法: alert,confirm,error console 等

第四章 Preparation，即正式coding前的準備工作。先強調 HTML 跟 CSS 結構的重要、三種 Hooks 方式 1.ID 2. class 3.Custom attributes，其中需要特別注意的是客製屬性沒有辦法通過 valid (X)HTML 測驗，例如作者認為寫成 class=”validation=required numeric” 程式不好寫，而若只是寫 class=”required numeric” 則沒有語義，所以作者寧願寫成 validation=”required numeric”。這個議題可以參考作者的這篇 JavaScript Triggers。

接著介紹 initialization function 的常見任務跟載入 JavaScript 的問題。有 1.設定 event handlers 2.決定 vistor 狀態，如 cookies 3. 設定會存取的資源 4.產生HTML內容，例如基於 accessibility 的考量，如果有某些內容不能沒有 JavaScript 支援，那一開始就應該用 JavaScript來產生 5.建立方便存取的關聯變數 6.修改文件結構，例如為了 usability 暫時拿掉某些內容。

然後是 include JavaScript 的用法，最後探討 initialization 的載入問題，我們知道下載HTML時是依序載入執行，所以include JavaScript 時，HTML頁面還沒載入，這會讓DOM發生錯誤，所以得用 window.onload 的 event 來處理，進而使用 addEventSimple()/removeEventsimple() 之類的機制。另外一個常見問題就是網頁 image很多的時候，載入太久造成 load event會 delay 太久，而此時使用者趕著點還沒有 initialization 的頁面(例如還沒設定onclick event) 就糟啦。

第五章  JavaScript Core，即ECMAScript。注意到 Javascript 有很多部分還是由W3C來標準。這章又回頭從 hello world 開始講 syntax,data type,control structures,function,object。嗯，感覺很多講的太基本囉，會唸這本書的人應該都有程式設計經驗了吧，而有些特別的東西因為無關 Core 所以只能點到為止(例如 event propagation, W3C DOM nodeList不算是array)，詳細則需要延到後面章節。

有趣的是我現在才知道 JavaScript 的 object 可以看成 associative arrays 來使用，即 dot notation 可以改用 square bracket 來使用，例如 object.property 跟 object['property'] 是一樣的、object.method() 跟 object['method']() 也是一樣，而用 array 的好處是可以彈性選擇要執行的 function (把 square bracket裡改成用變數)。

第六章則是跟瀏覽器相關的 object，統稱 Browser Object Model，這部份夾在 Core 跟 DOM 之間，只有 de facto Netscape 3 standard，而沒有正式標準。主要的東西是 (global) window object，探討 Cross-window communication: 如何處理 window.open 新開的視窗跟原視窗 opener。另外就是 Cookie, Location,History, document object……等既不是DOM又不是Core的東西。

(待續，最後的四章更深入技術議題，包括Events,DOM,CSS跟Ajax)

話說最近開始改唸 JavaScript了，Ruby&Rails 又只好先放著囉。

值得推薦的AJAX入門好書(2006/3月出版)，循序漸進交代出Javascript、DOM跟Ajax。範例程式碼清楚好讀，網頁設計觀念正確。講完用 XMLHttpRequest 的最原始用法之後，就開始教如何運用 Prototype 跟 Dojo，畢竟實在不需要用 raw Javascript 啊。之後的例子主要也是用 Prototype。講 Ajax 如何正確使用的觀念講的不錯(第七章)，其他有用的議題(如JSON)也都包含在內，是本既入門內容又豐富的書。

話說這本書放要讀清單放好久了，真的拿起來認真看，沒幾天也就看完了，還蠻好唸的… :p

大致的內容是這樣:

1. 簡介 Ajax
2. Google Maps 範例 (作者想說明這只是 standard HTML and JavaScript 而已)，我倒覺得這章有點累贅不必要 :p
3. XMLHttpRequest 的基本用法
4. XMLHttpRequest 加上 Javascript DOM 操作
5. Ajax Framework
   作者把 Ajax Framework 分成三種層次
    1.Ajaxian Web Frameworks(如Rails,Tapestry,ASP.NET)
    2.UI Toolkit (如Dojo,Backbase)
    3.Remoting Toolkit (如DWR,JSON-RPC)
   接下來介紹 Prototype 跟 Dojo 的 Ajax 用法
6. Ajax UI, Part 1: Prototype,Script,aculo,us 跟 Dojo 的 DOM 操作跟特效用法
7. Ajax UI, Part 2 : 告訴你什麼時候用Ajax。先給你一些 Ajax Patterns 範例(Server-side Validation、載入畫面,載入完特效,Autocomplete等)，接下來做一些議題討論 (回上一頁、Bookmarking、GET is for getting,POST is for Doing 等設計注意事項)。
8. Debugging 工具介紹
9. Degradable Ajax : 要先決定degrade的程度跟支援的範圍。
   先從 without Ajax 開始做! 然後再 Ajaxifying。使用 HTML 當作 Ajax 格式並搭配 partials template是比較容易做好 Degradble Ajax，至於 Web-Services-Driven Ajax (用XML或JSON格式) 則可能要分兩個版本或直接說sorry!，因為client side太rich了。
10. JSON 跟 JSON-RPC 介紹 
    JSON比XML格式更容易處理而且parsing又快，值得注意的是JSON還有獨到優點就是可以跨 server拿資料。
    see The AJAX response: XML, HTML, or JSON? 跟 JSON and Yahoo!’s JavaScript APIs
    JSON-RPC 則是拿 Rails 的 orbjson 來示範。
11. Server-side Framework Integration 簡介
    作者又分成三種
     1.有Visual Tool Support，view 使用 components 機制，如ASP.NET,JSF toolkit for JAVA
     2.Custom tag libraries(Helpers)，如RoR產生Javascript code
     3.ORB-like Remoting，直接在client-side 用JavaScript呼叫Server端的function，如JSON-RPC,DWR,PHP的Sajax等
12. Ajax with PHP : 介紹 Sajax 跟 XOAD
13. Ajax with Rails: 幾個Ajax helpers介紹，最後提一下RJS
14. DWR with Spring(Java) : 略
15. ASP.NET and Atlas : 略
16. Ajax的未來
    1. 介紹E4X(ECMAScript for XML)，一種parse XML的方式，直接讀出成 object 格式 (有點像JSON在做的事，只是對象是XML)。既有XML標準格式的好處，又有JSON一樣的方便性。
    2. 介紹畫圖的 Canvas 跟 SVG (找到這篇投影片比較差異 )
    3. 瀏覽器端的 Local Storage 能力，標準可靠的 offline storage API，目前 Dojo 有在實作。
    4. Flash Apollo : 讓 Flash 不限於在瀏覽器，Adobe 要用 Web 技術進軍桌面應用 (see這篇訪問文，看起來蠻有吸引力的)。
    5. Compiled Javascript 提供 JIT Javascript compilation environment 加強執行速度
    6. WHATWG 將主導了下一世代的 web standards

軟體設計層次的Ajax書，很認真的思考 Single Page Application。前三章引入Design Patterns、重構的概念到Javascript，將 Web Page提升到應用程式的層次。四五章很精采地分析架構，包括不同層次的MVC觀點，以及各種框架的大局觀跟分類，其中關於Ajax如何交換資料提供了很好的思考，以下是我的筆記(Rails是我加的，書上沒有):

內容中心的互動 (content)

• Server 傳回 HTML 片段，Client 在特定位置更新顯示。
• 簡單直覺，撰寫容易。
• 功能有限，畫面上的變化只限於固定矩形區域，無法進行複雜的DOM操作。
• Rails使用Prototype加上配套的 Ajax helper 即可達成。

腳本中心的互動 (scripting)

• Server 傳回 Javascript 片段，Client 直接執行。
• 功能彈性大，可自由操作DOM，多處更新。
• Rails 支援在 Remote Javascript Template (RJS)，使用Ruby語法撰寫Javascript，傳給Client執行，減少撰寫raw Javascript。

資料中心的互動 (data)

• Server 傳回 XML 或 JSON 資料，Client 的 Javascript 解析處理(或使用XSLT)。
• XML的解析較麻煩，現在流行用JSON(JavaScript Object Notation)。
• 上述兩種架構與Client相依，但資料中心即Web Service(REST)架構，具可重複使用性(可供別的前端使用)。
• Rails支援 XML Template跟JSON。
• 因為剖析資料的負擔完全放在 Client 端，所以 Client 端的Javascript程式或XSLT工程較大。

第六章 使用者體驗 實作了一個通知框架，第七章講安全性，第八章講效能及記憶體洩漏(memory leak)問題。剩下後半本則是一章一案例。

另一篇書評 : Relevance Review #5: Ajax in Action

註: 之前寫的 ajax 傳送格式比較 : XML, HTML, or JSON?

首先把yui下載回來，把要用的 .js 檔集中放到 /public/javascripts/yui/ 下，css (/yui/build/container/assets/container.css) 放到 /public/stylesheets/yui/ 下。

程式碼我就不轉貼了，我依樣畫葫蘆的範例在這裡 yui1，重點是按下Save時它用 Prototype 的 Ajax.Request() 呼叫 RJS Response，而不是用 YUI 的 Connection Manager，作者還加寫了一篇 Prototype vs YUI Connection Manager: Dialog continued…，給了 YUI Connection Manager的處理版本(好多行哩)，作者是認為 Rails 的開發者比較熟Prototype，所以這裡就用Prototype版本來做囉。

我個人是不太喜歡混雜用(怕有衝突?)，所以如果要完全拔掉 Prototype，RJS應該可以改用 RJS minus R! 直接寫 YUI Javascript code。

RJS是很棒的玩意，這殺手級的功能讓你寫AJAX response超簡單，只用Ruby即可。但是很明顯的它是個會漏的抽象層(leaky abstraction，事實上根據抽象滲漏法則，所有重大的抽象機制在某種程式上都是有漏洞的)，一但開始漏而要寫raw Javascript時，在RJS中就要用page.call 之類的，但這就看起來比較醜陋，尤其是有Javascript條件式或raw Javascript很多的時候。另外就是RJS完全依賴Prototype跟Scriptaculous，如果你要改用別的Javascript framework時，Ruby版的RJS就不太有用了。

因此如果你已經很熟 Javascript 跟 Prototype，或是你想改用別的 Javascript framework，可能就比較想直接用 Javascript 來寫 AJAX response，因此Dan Webb提出一個新選擇(新實驗?)  RJS Minus R (沒有Ruby的RJS!)，MinusR 把 .rjs 改成寫 Javascript (用Erb內嵌Ruby code)，主要就是給你一個 js helper 自動呼叫 to_json 來轉換 Ruby 資料。

討論串在爭論說應該要用另外 extension 副檔名表示這種 pure Javascript，因為這個 plugin 目前更改了 .rjs 的定義，造成本來用ruby寫的 .rjs template 不能用了。這部份該怎麼實作解決似乎還沒有定論。

DHH的回應說的很好，這是一個很好的實驗讓我們好好省思RJS，RJS不是萬靈丹，就像Rails的Active Record本身也是個會洩漏SQL抽象層，重點是如何讓80%的工作可以超簡單達成，and 另外的20%有彈性手動來變花樣。

另一篇介紹文: RJS templates without the R!

註: 目前的stable Rails版本不行跑這個 plugin，必須裝EdgeRails(開發中的Rails版本)，請執行 rake rails:freeze:edge 安裝 (要有subversion)。另外 EdgeRails 只用於該 rails application，而不是整個升級系統 library 的Rails版本。

不過這不代表 Firefox 以後不用加裝Flash，雖然 ActionScript 與 Javascript 都是依循 ECMAscript 標準規格所實作出來的語言(core language完全相同)，但是因為執行環境不同，加上的extentions也不相同(Flash的DOM和網頁的DOM不一樣)，因此 Flash 的程式(swf)還是要在 Flash Player 裡執行。

所以廖長輩的公式應該改成 Flash Player = Tamarin + Flash-specific DOM

Mozilla 的好處是得到一個效率高的 scripting engine，Adobe 則藉由 open source 吸引開放原始碼社群做 scripting engine 最佳化(把手放開，專心去做其他更重要的事情)，以及讓大家了解 Javascript 與 Actionscript 在語法上的共通性，藉此吸引人們使用 Flash或Flex。

想了解更多的話，請看 d.CAT 的這兩篇文章 What Tamarin really means ? 和 adobe team up with firefox – tamarin project。

Update(2007/4/6) : lazy Guy 提出了更深入的觀察跟看法。

Comet 這個名詞是由 Alex Russell (Dojo的開發者) 今年五月所提出，比較熟知的名稱有 HTTP_Streaming、Server Push。讓 Client 瀏覽器與 Server 建立長時間的連線，因此Server可以想傳就傳資料給 Client，不需要 Client 先送 request，Server 才能送資料。

Ajax的作法要更新網頁只有當使用者觸發事件(mouseover或click等)或是利用 Periodic_Refresh 週期更新，Periodic的問題在於不管是否有沒有真的新資訊，就固定幾秒鐘連線，增加不必要的連線與頻寬浪費，不過 Periodic Refresh 仍是現在最普遍沒有問題的作法，符合現存的Web架構。

Comet Demo

• Lightstreamer : 即時財經訊息，真是超炫的… :p
• Meebo : Web IM

幾個困難的地方 

• Server 的 scalable 能力! 長時間的連線讓Server負擔大增，現有 web server 的設計並不合用。
• 瀏覽器支援，需用一些 trick，因為在 IE 中沒下載完不能用。所以要用 iframe 或 flash (另開socket) 才能跨平台。see IFrame + Script Tags = Portable Comet
• 可以達到雙向 full duplex 嗎? see Two-Way Web: Can You Stream In Both Directions? 有些討論。

實務上，還不是很成熟可以使用，跑起來問題可能會很多，Client不是網頁標準作法，Server也沒有簡單的支援。定位上我覺得可以作為Ajax的延伸，若配套支援ok，Server部署沒有問題，也許會取代 Ajax 需要 period refresh 的部份，達到更好的使用者體驗。