2011-07-27 14 views
0

在django中,我應該通常選擇哪個,爲什麼?Django:我應該有複雜的模板變量名稱還是複雜的視圖

  • 長模板變量名,通過儘可能少的「根對象」(如要求)儘可能:

    {% if request.current_page.get_children.0.get_absolute_url %}

  • 或傳遞一個地獄很多不同的「根對象」,並保持模板變量名稱簡單:

    {% if first_child_url %}

  • 在MI某處ddle,例如,經過children

    {% if children.0.get_absolute_url %}

    或通過first_child

    {% if first_child.get_absolute_url %}

第一種方法的優點是鬆耦合的,因爲我不需要每次我需要時間來改變視圖使用另一個變量;第二種方法的優點是模板更簡單,更清潔。

如果我使用不允許添加額外上下文變量的通用視圖(或第三方視圖)(因此添加上下文變量的唯一方法是編寫中間件或上下文處理器),這會改變什麼嗎?

+0

您可以在通用視圖中添加額外的上下文(至少在Django 1.3中)。看看[這裏](https://docs.djangoproject.com/en/1.3/ref/generic-views/)找到變量extra_context,你可以在其中添加任何東西。 – Hassek

+0

@Hassek:我正在使用[django-cms](https://www.django-cms.org/),他的觀點不允許我傳遞extra_context,我可能會錯過某些內容,但我沒有看到任何內容通過其他方式將額外的上下文變量傳遞給除中間件和上下文處理器之外的django-cms頁面。 –

+0

哦,這改變了規則。根本沒有使用django-cms:p – Hassek

回答

2

目前對此沒有正確的答案,但我可以給你一件事要考慮:

1)在模板會靜靜地失敗,這就是爲什麼我通常儘量避免像

東西拼寫錯誤的變量名
{% if request.current_page.get_children.0.get_absolute_url %} 

2)與此相反的是,在一個視圖中的任何問題,將立即引發異常和明顯調試

first_child_url = request.current_page.get_children[0].get_absolute_url 

3)我有時會做,當個e情況需要它,將快捷方法添加到模型中,該模型允許我從模板中調用方法,但仍然保留方程python一側的複雜性。所有這一切說,如果你不能添加額外的上下文,並需要使用模板標籤(如你的評論中提到的那樣),我認爲最好的,如果你去複雜的模板選項。 我只在使用自定義模板標籤時纔是做某件事的唯一方式,而不是作爲快捷方式。

希望這會有所幫助....

2

如果您是唯一的開發人員,那麼這主要是品味的問題。但是,如果編寫視圖的編碼不是編寫模板的編碼,那麼配合視圖和模板之間定義良好的「合同」會更容易。

我傾向於將視圖的參數視爲模板,就像我對API接口的想法一樣。我的網站邏輯可以改變,但只要我尊重傳遞給模板的數據結構,我不需要重寫任何內容 - 而在一個組中工作時,這是至關重要的。