2010-01-27 59 views
3

我有一個django視圖,並且這個視圖返回一個表格,它是通過ajax調用異步填充的。誰應該格式化我的數據以供顯示?

從設計的角度來看,其中一個我應該遵循:

  1. Django的視圖,通過AJAX調用,返回表中的作爲JSON響應的內容,包含HTML標記爲每個小區。 javascript回調處理程序獲取內容,並將它們打成表格單元格。
  2. 通過ajax調用的django視圖返回有關應該放入表中的純數據,並再次作爲json響應。異步JavaScript回調將獲取數據,使用適當的標記對其進行格式化,然後將其放入表中。

換句話說,誰應該對單元格內容的標記格式負責?視圖還是javascript?

我會試着說第一個,因爲視圖已經返回標記的內容。如果它返回包含標記內容的json,則沒有太大區別。

我想聽聽你的觀點。

+1

好像你有一個平局: 2:2和一個人未定;-) – Boldewyn 2010-01-27 08:45:08

回答

1

在諸如Django的MVP系統中,View決定應該顯示哪些數據,並且Presenter決定如何顯示它。因此,JavaScript應該執行大部分格式化操作,除非證明難以實現。

+0

如果模板仍然用於格式化服務器端返回的AJAX數據(事實上,可能是用於最初生成表的相同模板,如某些答案所建議的) ,那麼即使返回HTML,ISTM的表示邏輯仍然在正確的位置。在這種情況下,在JS中進行格式化會更困難,更容易出錯,速度更慢,而且DRY更少。 – 2010-01-27 15:29:31

1

這是一個很好的練習Unabstrusive的JavaScript,也被一些人稱爲Hijax

所以,你首先有一個標準的頁面,呈現表與頁面的其餘一起,與表中特定Django模板塊。

一旦你有了這個,你可以在「如果不是ajax」中包含django模板的extends部分,所以你只需要在ajax響應中獲得所需的表部分,你可以在客戶端加載所需的表格部分到所需的div 。

在服務器上維護標記一次,而在客戶端維護一次標記,這在javascript中是沒有必要和多餘的。

因此,我更喜歡服務器重寫的第一個選項,而客戶端只加載呈現的html。

3

如果您正在填充整個表格,則可以將表格放在其自己的模板中,並通過ajax/json返回表格的html。

你需要編輯原始模板中包含的表模板:

{% include "myapp/_table.html" %} 

並在視圖,返回渲染模板作爲JSON變量,你的JavaScript將在替補:

return { 'table': render_to_string("myapp/_table.html", context) } 

這種方法非常好,您總是希望更新整個表格,並且表格的渲染不需要完整的上下文。我不確定性能如何,但它是更新頁面部分的一種乾淨方式,因爲您只需定義一次表格。

+0

這不完全可能。我逐漸更新表格,說實話。 – 2010-01-27 16:23:20

+0

嗯,我想這取決於你在說多少標記。我更喜歡在將數據發送給用戶之前將其格式化,但這取決於您正在進行的格式化。我認爲這個普遍的問題不能也不應該用單一的答案來回答。 我的'django-adjax'應用程序中的方法是將數據格式化爲模型。要麼按原樣提供值,要麼提供正確值的方法被引用。這對我來說已經足夠了,但我不必處理你的具體要求:-) – 2010-01-28 08:51:52

1

我以前遇到過這幾次,我通常選擇後者,視圖返回純JSON。

但是,您選擇的方法肯定要取決於幾個因素,其中之一是目標設備(及其CPU /網絡限制)。純JSON通常會導致更小的有效負載,因此可能對移動設備而言是最佳的。

同時公開您的內容的HTML和JSON版本也是有意義的。如果您希望爲您的網站創建一個非常輕量級的API,這特別有用。

最後,您可以使用庫如John Resig的micro-templatingClosure Templates來簡化客戶端HTML生成。

2

它取決於(經常)。

如果要求只有在這裏,現在的數據,這將是更容易,更容易出錯就讓它呈現在服務器端用同一套模板已經呈現的標準視圖。

但是,如果您可以考慮使用情況,那麼在其他地方(如自動完成字段)需要數據的情況下,最好讓JavaScript執行此操作並創建乾淨且可重用的JSON導出。

這些選項添加到所有其他答案,最後由您來決定。

0

我會去的第一選擇,正弦波它爲用戶的更多優點:立即載入網頁(不等待異步調用),無需(例如,用於移動設備)JS