Single Page Application

所依賴的Web技術

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

JSON為Javascript 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息息相關。

REST為Representational 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可能又是另一次的泡沫化，這個熱潮怎樣開始的，又怎樣消退的，也是相當明顯。網路上對於各種新技術名詞的炒作，將不同應用層次的技術，全部攪和在一 起說明或稱做是最終解決方案，也模糊了使用者的眼睛。那麼，在這個時代，到底還有什麼可以相信，可以學習的？

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