Basecamp中的大多數(shù)Ajax操作都是在處理服務器生成的JavaScript響應（SJR）。它的工作原理是這樣的：

表單通過一種XMLHttpRequest驅動的形式提交。服務器創(chuàng)建或更新模型對象。服務器生成包含了針對該模型對象的更新了的HTML模板的一個JavaScript響應?？蛻魜碓u估處理由服務器返回的JavaScript，然后會更新DOM。

這種簡單的模式有一些重要的優(yōu)勢：

1.重用模版而不影響性能

無論是第一次渲染和隨后的模版更新,你都可以重用模版.如果使用Rails,有一部分技術像郵件/信息用于這兩種情況。

如果你只返回JSON格式的信息，你得用你的模版將展示這些信息兩次(一次是服務器端的第一次回應，一次是客戶端隨后的更新)—除非你做一個單一面頁的JavaScript app,這個app的第一次回應是用JSON/客戶端生成方式。

后面那種方式會很慢，因為要等整個的Javascript庫load完并在客戶端生成好模版你才能看到效果(這是Twitter早期所用的方式，但隨后被背棄)。但至少在某些情況下這是一個合理的選擇而且不需要多個模版。

2.客戶端需要更少的計算性能

雖然嵌入HTML模板的JavaScript可能造成響應數(shù)據(jù)量比JSON格式的響應要多（盡管用gzip壓縮后幾乎可以忽略），但是這不需要客戶端去做很多的運算來更新頁面。

這意味著，從端到端的觀點出發(fā)，處理 JavaScript+HTML的響應數(shù)據(jù)的速度，應該比處理帶有客戶端模板性質的JSON數(shù)據(jù)要快，至于快多少，取決于客戶端模板的復雜程度，以及客戶端計算性能。而且這個速度應該是二倍關系，因為，服務器生成的模板可以通過緩存在多個用戶之間共享（詳見 Russian Doll緩存）。

3.容易跟蹤執(zhí)行流

使用SJR會讓跟蹤執(zhí)行流變得非常容易。請求的機制是標準化的，是會帶有輔助邏輯“l(fā)ikeform_for @post, remote: true”. 當然沒有必要對于每個動作都帶上輔助邏輯。 接著控制器會以渲染完整視圖的方式來渲染響應中的部分視圖，其中的目標只能是JavaScript 而不是完全的HTML

完整示例

1)首先使用消息模板

<h1>All messages:</h1>

<%# renders messages/_message.html.erb %>

<%= render @messages %>

2) 以Ajax方式提交表單

<% form_for @project.messages.new, remote: true do |form| %>

  ...

  <%= form.submit "Send message" %>

<% end %>

3) 服務器創(chuàng)建模型對象

class MessagesController < ActionController::Base

  def create

    @message = @project.messages.create!(message_params)

    respond_to do |format|

      format.html { redirect_to @message } # no js fallback

      format.js   # just renders messages/create.js.erb

    end

  end

end

4) 服務器產(chǎn)生內嵌入HTML的JavaScript響應

<%# renders messages/_message.html.erb %>

$('#messages').prepend('<%=j render @message %>');

$('#<%= dom_id @message %>').highlight();

最后評估響應工作是由form_for產(chǎn)生的XMLHttpRequest-powered表單來自動處理的。視圖因此由于新消息而更新，此外新消息也通過JS/CSS動畫高亮顯示。

超越RJS

當我們一開始使用SJR時我們將它和一個叫做RJS的前身一起使用，使用RJS你需要寫Ruby模板，然后再將它們轉變成JavaScript。它是Coffeescript（或Opalrb，如果你喜歡的話）的簡化版，它錯誤地讓許多人舍棄了SJR模式。

現(xiàn)在我們不使用RJS了（更迭的原因通常很簡單——優(yōu)勢不是那么大，只有極少數(shù)情況下才需要的沒有必要那么復雜），但我們卻一如既往地致力于SJR。

這并不意味著JSON數(shù)據(jù)在服務器端產(chǎn)生和視圖在客戶端形成的模式一無是處。對于我們的UI需要很高的保真度的時候，以及像日歷這樣的，有大量的視圖狀態(tài)需要維護的時候，這樣的模式還是非常合適的。當需要走這條路的時候，我們使用Sam的卓越 Eco template system (認為ERB對于CoffeeScript).

如果你的網(wǎng)絡應用都是高保真度的UI，那么走上面提到的那個路子是完全沒有問題的。只是你正在花費高價給自己購買些花哨的東西，不過這算是個問題。但是如果你的應用有點像Basecamp或者Github這樣網(wǎng)絡上的以文本為基礎的主流應用，那么你完全應該張開雙臂擁抱SJR。

河南億恩科技股份有限公司(m.1tcdy.com)始創(chuàng)于2000年，專注服務器托管租用，是國家工信部認定的綜合電信服務運營商。億恩為近五十萬的用戶提供服務器托管、服務器租用、機柜租用、云服務器、網(wǎng)站建設、網(wǎng)站托管等網(wǎng)絡基礎服務，另有網(wǎng)總管、名片俠網(wǎng)絡推廣服務，使得客戶不斷的獲得更大的收益。
服務器/云主機 24小時售后服務電話：0371-60135900
虛擬主機/智能建站 24小時售后服務電話：0371-55621053
網(wǎng)絡版權侵權舉報電話：0371-60135995
服務熱線：0371-60135900