首頁‎ > ‎電子期刊‎ > ‎2007年10月號‎ > ‎

Single Page Application - 下一代的Web應用程式(下)


Single Page Application

所依賴的Web技術

AjaxAsynchorous Javascript And XML, 早期Ajax被用作來傳輸單純的HTML或是XML,並且利用DOM的innerHTML屬性來更新部分HTML內容。如今Ajax在SPA中被當作重要 的傳輸媒介(Transport),無論範本資料到應用程式資料,都是利用Ajax在背景傳輸完後,再由Javascript Template來產生HTML。

JSONJavascript Simple Object Notation, 在標準的Javascript語法中,以{ }及[ ]這兩個語法,可以宣告物件與陣列,並可以使用eval函式將他轉換為Javascript物件。例如object=eval(" ({a:'b'})"),此時object物件便有一個屬性"a"其值為"b"。在SPA中,JSON被運用來作為一種資料格式,藉此取代複雜的XML, 以節省頻寬。而傳輸的JSON資料又可以快速還原為javascrip物件,又更節省程式執行的時間。

在SPA中,HTML DOM是一個最重要的元素,尤其是DIV及SPAN等Container的操作 更是。由於絕大多數的畫面都不進行任何換頁的動作,程式裡大部分都是在控制DOM及Container。而對於A (Anchor)而言,href裡的URL也沒有太大意義,多半都是在onclick裡寫javascript,或是用Javascript函式庫去 bind onclick事件。由於直接呼叫瀏覽器提供的DOM函式庫功能,會遇到像IE一樣不符合W3C規格的問題。要選用一個合適的Javascript擴充函 式庫,如Prototype.js或是jQuery,如此才不會有太多跨瀏覽器問題。

CSS在以往的Web應用程式中,多半都拿來當作畫面的修飾,布景主題或是顏色特校。但在SPA中,必須要熟悉CSS的Dimentation(長寬控制),Classification(顯示行為),Positioning(定位)。在無法換頁的狀況下, 只能靠著移動,隱藏,顯示這些方法來控制畫面的元素。如果要瞭解這些進階CSS的主題,都可以在w3school裡的教學找到。

Trimpath是Google為了SPA而開發出來的一個函式庫集合,也可以說是Rails的Javascript版。如果要撰寫下面所說第一種SPA,就必須利用到Trimpath的全部,而第二種只需要用到Trimpath Javascript Template即可。Javascript Template(JST)如同PHP的Smarty一樣,是標準的範本技術,只是採用的語言是Javascript。為了撰寫SPA,必須要好好地運用JST。

快取的機制在SPA也相當的重要,為了達到讓使用者感受到程式的反應快速,就必須應用多方面的快取。

  • View Cache:SPA中的View就是指已經顯示出來的HTML,很多常用,而不需要經常改變的HTML,就可以將放在Container(DIV或 SPAN)裡。不用的時候就隱藏,需要的時候就顯示。而另一種方式是可以用z-index將選單或是清單的Container放在最下層,而要回到這個清 單的時候就將蓋在其上的container隱藏。
  • Template Cache:一般來說JST的範本資料只要讀取一次就可以,又因為這些只是字串,可以直接就存在Hash裡。
  • Javascript Cache:在我提出的SPA實做中,有一個特性是將各個JST的「行為」程式碼分開,就如同sap.net將aspx與cs檔分開的作法一樣。而如果採用這個作法,不需要重複讀取的javascript就必須要快取。
  • Data Cache:資料快取是最難的一部份,牽扯到了快取一致性的問題。而現在在javascript中並沒有對於XML或JSON的資料快取解決方案,未來如果能夠有這樣的函式庫,就能夠更提升整體的效率。

以上說明的都是Client Side所必須要使用到的技術,而Server Side的技術多半與Service Design息息相關。

RESTRepresentational State Transfer, 他比較像是一種設計樣式(Design Pattern),而不是Web技術。在以往Web應用程式的規劃中,URL並不完全具有意義,傳輸的內容型態多半是HTML,而HTTP的各種動作也並 未完全利用。在SPA中,由於需要在不同時間傳輸各種資料,如HTML範本,JS範本,或是XML及JSON資料。此時REST的設計技巧就可以節省下很 多重複的命名,而讓程式碼整體更有意義。支援REST設計樣式的Web Framework如Ruby On Rails,讓整體設計較為簡單。

SPA的架構

SPA就分類而言,算是RIA的一種,只是不採用任何的sandbox而已。典型的SPA是不需要任何的後端的Web Service或是Offline Database,只需要一個htm檔或是一個網頁就能夠運作,如微軟的HyperText Application(HTA)就是,但還是缺乏完善的資料儲存能力。

第一種SPA程式,如同著名的Google Reader離線版,具有一個離線資料庫與一個同步管理程式,在有網路連線的時候,會將資料同步回線上的資料庫。這個最大的優點就是完全利用了 Client的CPU資源,使用者雖然看見的是網頁,但卻是在使用在本機執行的獨立應用程式,因此速度是相當流暢。比起一般的動態網頁,這樣子的使用體驗 更能夠顛覆一般人對於「網頁」的看法,而逐漸瞭解何謂Web應用程式。另一個例子是使用Trimpath函式庫撰寫成的NextAction,是一個多功 能的ToDo List。

另一種就是較簡單的SPA,不具有離線瀏覽的能力,但是承襲了使用javascript的高效能。必須提及的是Server Side並不是採用XML,而是可以快速轉換為Javascript物件的JSON,來當作Web Service。如此Server Side的語言只需要具備能夠快速將物件serialize成JSON的能力即可。

Rails與SPA

這個小節所要說明的是相當技術性的部分,無法說明的太詳細,有興趣的讀者可以寫mail一起討論。為了簡化觀念,我使用Sequence Diagram來說明Rails要如何應用在SPA上:

  • URLRequester是一個javascript函式,主要的工作就是以REST方式對一個URL進行不同Content-Type的Request,並且將回傳的資料產生HTML,並填到container裡顯示出來。
  • HTTPRequest在這裡作為進行Ajax呼叫的傳輸媒介。
  • RailsController表示伺服器端對應至特定URL的程式,在這裡也必須使用REST方式來回應。也因此如果要求content- type為HTML的時候就傳JST範本,要求JSON的時候就傳資料,要求javascript的時候就傳javascript文件。
  • RailsModel代表伺服器端的資料庫,在要求資料的時候,勢必定要連資料庫來取得資料的。而回傳的時候,就將ruby物件serialize成JSON。

  1. Client呼叫URLRequester函式,例如http://servername/controller/action/id。
  2. HTTPRequest送出一個要求,並指定Content-Type為HTML。
  3. RailsController接到指定的URL,並執行controller#action。我將JST寫在rhtml裡面,JST基本上也 是html,不過是範本的標籤換成{}而已。因為REST設計方式會因為指定的content-type回傳對應的型態,此時直接將內容的JST文件傳 回。
  4. 在前面我有提及快取的重要性,所以這裡就快取住這個JST,下次要求同樣的內容就可以直接使用而不用重複傳輸。
  5. 對於同一個URL,使用HTTPRequest送出要求,並指定Content-Type為JSON。
  6. 因為REST的特性,這次會執行到content-type為JSON時的程式碼,接著就可以照一般方式使用Rails Model讀取資料庫。
  7. Model傳回的Ruby物件,當然就要轉換成JSON回傳。而在ruby中相當簡單地便是呼叫to_json就可以轉換了。
  8. 回傳的JSON,併和剛剛快取的JST,使用trimpath javascript template函式庫產生成HTML,並更新至container裡。
  9. 在這裡我採用行為javascript程式碼與範本分離的方式,所以還是以HTTPRequest再次傳送要求,並將Content-Type指定為Javascript。
  10. 同樣地根據要求的content-type,會回傳javascript文件。
  11. 快取,並呼叫eval執行回傳的javascript。
  12. 將container顯示在想要放置的畫面區域。

結論

許多人都在說Web 2.0可能又是另一次的泡沫化,這個熱潮怎樣開始的,又怎樣消退的,也是相當明顯。網路上對於各種新技術名詞的炒作,將不同應用層次的技術,全部攪和在一 起說明或稱做是最終解決方案,也模糊了使用者的眼睛。那麼,在這個時代,到底還有什麼可以相信,可以學習的?

唯一能夠做的就是重新審視這些技術,瞭解因果。就可以知道哪些作法是適合用在自己現在的專案,那些是本質相同的,哪些是跨大其詞的。根本的觀念正確,就不需要擔心這些延伸的技術是否會有誤解或誤用。

Comments