每個人都在談論 Web 2.0,以技術上來說最有名的莫過於 AJAX,當每個人看到了不換頁的網頁,往往都會會情不自禁地說「哇!好炫的 AJAX!」 但實際上不換頁的技術不是只有 AJAX,甚至很多時候我們會考量其他因素而棄 AJAX 不用、改採其他技術。這次的 Tech Talk 就是為了讓大家對不換頁的技術有更深一層的認識、以應用在相關的工作上。
Joseph Jiang,josephj@yahoo-inc.com自從有了 Yahoo! Connection Manager 之後,想使用 AJAX 變得非常簡單,只需要三個步驟即可:
雖然 AJAX 用起來很方便,但很可惜它的致命缺點就是無法跨網域。不要懷疑、連從 tw.yahoo.com 用 AJAX 存取 tw.news.yahoo.com 都會收到 Access Deny 的訊息… 但這樣子豈不是太可惜了嗎?如果其他網域有提供一個 Service URL、恰巧是我很需要的資料,難道我就沒辦法用 AJAX 存取了嗎?
當然不是這個樣子的,我們只需要在本地端寫幾行短短的後端程式來幫我們當轉接站即可,也就是我們這邊所謂的 Proxy。( Proxy HOWTO )
在我們把 AJAX 寫的複雜一點時,會衍生出一些問題,我們可能會連續送出好幾個 Asynchrous Request,當然這些請求有可能會失敗,或者是其實你寫錯了!根本沒有送出,所以我們需要一個監控的工具。我們的美國同事 Hedger, 在他自己的網站 Hedgerwow 上有一個 Connection Watcher 的工具,專門幫你監視 AJAX 的送出、成功、與失敗。
當我們去抓遠端資料的時候,除了一般的網頁 HTML,最常見的就是 XML 的資料格式了(如 RSS 或 Web Service 的傳回值),但是若想直接用 Javascript 來處理 XML,會因為瀏覽器的不同而變得十分棘手,所以我們需要一個好的 XML Parser 來協助我們處理。我現在都是用 xmldom.js 來做 XML 的解析。(這邊還是要做個提醒,Client 端 DOM 的 Parsing 是很消耗瀏覽器資源的,最好的方式還是在 Server 端抓取資料回來時就先處理成為 HTML 或 JSON 格式)
我們必須利用一些現有的函式庫讓我們的工作馭繁為簡!Again!Hedgerwow 網站上有一個 Install Libraries on Demand,正好可以協助我們來解決這個問題。
前幾個月在 dot com 那邊有一股 JSON 的旋風,緣由可以看這一篇 Web Services + JSON = Dump Your Proxy。大意主要是說 AJAX 雖然好用、可以存取各種格式,但如果要做跨網域的存取時就必須做一個 proxy.php,若討論到安全性會更麻煩、而且有些人的 Server 上根本不允許使用 Server-Side Language, 這樣一來,我們在 developer.yahoo.net 所提供許多好用的 api (原來是 xml only) 就沒辦法被許多人所應用了... 因此,有人大力地將所有 api 服務都提供轉換為 JSON 的格式,配合我們在這邊所講的 Remote Scripting,我們就可以把 Connection Manager 給丟掉、把 Proxy 丟掉,用最 lightweighted 的方式來存取 API
上面的技術都很炫,但是不知道大家有沒有發現一個問題,當 User 利用 AJAX 或 Remote Scripting 做換頁時,他們很有可能會按「上一頁」,這時他們所得到的結果可能是一種驚訝與不悅,因為這並不是他們所期待的頁面。
YUI 在最近新增了一個上傳 (AJAX 本身沒有辦法做上傳) 的功能,雖然放在 Connection Manager 裡,但實際上是利用 Iframe 的技巧,我們也順便在這邊介紹一下
在您輸入的過程就會幫您檢查此帳號是否存在唷...
圖片替換的缺點:Cookies 不能用的時候就失效了、只能傳送少量的資訊(Cookies 最多只有 4KB 的容量)、無法存取遠端資訊、若未來對 img 做出安全性限制(僅可使用圖片格式),屆時就無法利用此方法取得資訊。
其實這是使用 HTTP 的狀態 (如 5XX 是伺服器錯誤)。利用這種技巧,連一個假的圖片都省掉了,除了 Js 的處理外,你可以用一般的方式連結、或送出表單到某一特定的網頁(Server-side Language)。這個特定的網頁有一個很重要的設定:就是必須將網頁的 Header 設為 HTTP/1.1 204 No Content(可參考:Status Code Definitions)
204 No Content 代表了網頁收到了 Request,但是不做任何的回應。所以當這樣設定了之後,瀏覽器的確會有送出的動作,但是你可以發現所在的網頁將是會靜止不動的。這樣一來,我們「製造 Request 但不重新整理網頁」的目標就達成了。這個目標的網頁,如上面的圖片替代方法,一樣會把所需的回應寫到 Cookies 中。開發者再一次,又可以在 Client 端利用 Js 取得由 Server 端所變動的 Cookies
範例:以使用者帳號取得其資訊 | Server 端程式碼 | Web 2.0 Batch File Uploader | 知識+ 編輯我的知識檔案在跳出視窗尚不會被攔截的時代,常有許多網站會利用這樣的方式來做不換頁的更新。而現在主流的瀏覽器 IE 、Firefox 預設已經會攔截跳出視窗,用這種方式來更新已經少之又少了。
我們可以利用跳出的視窗去取得伺服器端的資料,再把取得的資料寫回原本的視窗。這是一種蠻直覺的做法,剛剛提到「封鎖快顯視窗」的緣故,若這個跳出視窗的動作不是由使用者所驅動,那麼十之八九會被擋掉,功能就會因此而失效了。
輸入帳號取得使用者的 Email (ASP Code) |
自動取得伺服器上的時間(被視窗封鎖的失敗範例)
由於視窗內建的 window.alert(), window.prompt(), winfow.confirm() 外觀都是一成不變的,基於這個問題,微軟就發展出了 window.showModalDialog。showModalDialog 的中文名稱就是「對話視窗」,跟 alert(), prompt(), confirm(), 一樣,使用者必須關閉此視窗、或按下某個 button 才可以繼續下一步,也可以稱為「同步化作業」(必須等待處理完畢、不能在等待的時間作其他事情)。這是一個蠻好使用的方式,但很可惜的是 FireFox 完全不支援、而且在 IE 如果不是使用者所驅動、也一樣會有封鎖視窗的問題在。
在處理 AJAX 這類的不刷新網頁,因為這些命令都是非同步的,我們往往需要對畫面做一些處理,讓使用者知道我們的動作正在進行中。 像是 Activity Indicator 、把整頁刷淡、讓使用者無法操作等效果。
但說真的,這樣的效果要自己去做其實要處理的事情還不少,像是每次視窗的縮放我們必須動態地去偵測大小,讓 Activity Indicatior 放在正中央的位置、或者是針對刷淡的 Layer 處理大小,以免大小超過時導致 scrollbar 的出現。
感謝 Yahoo User Interface Library,最近推出了一個 Container 的 widget,可以讓我們事半功倍啊!!
Panel Widget 主要用來顯示資訊用,與使用者沒有任何的直接互動(但是你還是可以設定關閉、拖拉等行為)。這樣的東西很適合我們用來顯示剛剛所提到的 Activity Indicator, 只要把 modal 設為 true,使用者也沒辦法對後面的頁面進行互動。
剛剛我們有提到 IE Only 的 showModalDialog(),有時我們很需要像這樣的東西讓我們做一個獨立的 AJAX 新增、修改介面。現在有了 Dialog Widget 之後,不用再擔心瀏覽器支援性的問題、也不用另外做一個頁面。
有時我們只是希望顯示一個簡短的訊息,如「您確定嗎?」、使用者只選擇是跟否,雖然我們還是可以用 Dialog 來做、但其實有個更簡單的東西叫 Simple Dialog
| 刪除 | Awoo~ Awoo~ Awoo~ | Awoo~ Awoo~ Awoo~ |