我想知道在Web應用程序中渲染部分視圖的好方法（或推薦的方法）是什麼。在服務器上渲染部分視圖或在客戶端上發送json數據和渲染模板
我有一個需求，我需要使用AJAX將數據加載到已經呈現的頁面，有點像「加載更多...」鏈接在頁面的末尾，從服務器獲取更多信息，將其呈現在頁面的底部。
兩個選項，我擺弄目前的Ajax響應是
render template:'tmplt_name'）並通過網絡發送它，並將結果追加到頁面底部是否有其他方法可以做到這一點？如果不是，考慮到上述選項在維護，性能和可測試性方面會更好？我確信的一件事情是，JSON路由將（在大多數情況下）使用更少的帶寬，而不是通過網絡發送html。
這實際上是一個非常有趣的問題，因爲它暴露了一些有趣的設計決策。
我更喜歡渲染部分模板，因爲它使我的應用程序能夠隨時間變化。如果我需要使用圖表從<table>更改爲<div>，可以很容易地將其封裝在模板中。考慮到這一點，我幾乎將每個頁面視爲許多小模板的集合，這些小模板可能會發生變化。 Grails 2.0的默認腳手架已經轉向這種類型的方法，這是一個好主意。
問題是它們應該是客戶端模板還是服務器端是問題的關鍵。
服務器端模板使初始頁面加載時標記更清晰。即使你使用類似的ICanHazJS，你也有點兒需要在頁面中有一個空的元素（與你的模板有關），適當地設計它，然後在Javascript中使用它來更新你的信息。
缺點
通過線路優點
客戶端模板可以真正降低服務器負載，但是。他們使應用程序「less-chatty」，因爲你可以通過發送更大的JSON集合（以相同的字節數或更少的數量，將被HTML佔用一個服務器端模板方案）。他們還爲用戶提供真正快速的UI體驗，因爲點擊「更新」鏈接無需進行AJAX往返。有人說：
安東尼·艾登@aeden 12月10日回覆轉推收藏·打開 Web應用的未來：請求由函數處理，邏輯始終是異步的，HTML是從來沒有在服務器上生成。
缺點
優勢 - 響應 - 較小的信封
趨勢s似乎正在轉向客戶端模板，尤其是隨着HTML5新增功能（如<canvas>）所暴露的威力......但如果利用它們，則需要您依賴您不太熟悉的技術，並且您對Grails感到更加舒適部分，可能值得從這些開始，然後根據性能和其他問題調查對客戶端模板的重構。
第二個選項渲染部分更好，因爲如果你得到一個JSON數據，你應該只後你操縱它就像一套風格，創建元素，設定值和類似的事情按需要在javascript中獲得ajax響應，但如果渲染部分內容，則可以在該部分中設計視圖並保持就緒狀態，並使用ajax調用進行導入，因此不存在處理響應數據的責任。
我想說這取決於您在放置時通過電線發送多少數據。如果你正在實現「加載更多」功能，那麼你似乎不想花5秒鐘來加載一些東西。 Google圖像是該功能應該如此快速的一個很好的例子。如果你知道你永遠不會有這麼多的數據，那麼渲染服務器上的部分可能會更清晰，但如果你需要改變，那麼回到第一種方法是一件麻煩事。所以簡而言之，我認爲第一種方法允許更多的災難控制，只要多加載更多的時間來加載大量的數據。我認爲，儘可能在服務器上卸載服務器也是一種很好的做法，即使在開發人員的客戶端有點不方便。
這些數據大多是一些水處理樣品的簡單文本值。除非用戶需要，否則負載基本上會抓取一些與首次交互無關的互補歷史數據。爲了減輕服務器的負擔，我認爲通過對部分模板進行適當的緩存，這不應該成爲問題嗎？ – omarello 2011-12-17 19:26:22
我想你已經在用戶與頁面的第一次聯繫時呈現類似的內容，就像你打算使用「加載更多鏈接」一樣。在以相同的方式點擊「加載更多」之後加載正在加載的內容並重新使用已經爲此編寫的代碼是否沒有意義？你的問題很有趣，我想看看你的想法和其他人的想法是什麼 – jcage 2011-12-17 18:53:47
是的，在第一次互動時，我重新使用相同的模板（點2）來渲染整個頁面（與其他頁面的靜態部分）。這兩個選項都適用於我，我已經將它們用於分散的事情。我也很想看到其他人的想法。 – omarello 2011-12-17 19:15:27