我工作在Django一個大的社交網絡應用程序，我希望使用某些前端組件很多次，並經常其他自定義組件，其中可能包含更小的子組件（ad infinitum）。所有這些組件通常都是動態生成的。我試圖找出構建Django框架的最佳方法，這樣我的組件便於維護並具有清晰的編程接口。在很大程度上依賴全球環境似乎與此相反，但是，我認爲通過在視圖中一次完成所有事情來避免冗餘查詢具有優勢。Django的：用這樣的方式自定義組件包含設計的功能實現一個嵌套的，可重用的組件設計
自定義包含模板標籤似乎是一個不錯的選擇實現的組件，但我不知道，也高度嵌套模板標籤可能會導致性能問題，還是解析架構避免這種情況？在視圖層面使它自我記錄的最好方法是什麼？呈現主頁面模板，自定義標記和所有內容需要什麼上下文？我將它想象成一個小小的噩夢，試圖正確維護代碼來設置模板上下文。最後，維護這些組件的CSS的最佳方法是什麼？
隨意推薦其他建議的方法來創建嵌套組件設計。
這是一個有趣的問題。理想情況下，您應該在渲染之前從數據庫中提取所有組件。但是看層次結構，製作模板標籤是有道理的。這些模板標籤將提取適當的數據。爲了解決這個問題，假設數據庫查詢由於搜索局部性而被緩存。
的解決方案，我到目前爲止在決定是使用一個包含標籤庫作爲我的一套可重用的組件繼續前進。我儘可能地堅持在我的視圖代碼中設置所有查詢，並在我的上下文中預先設置傳遞它們 - 沒有在模板或標記庫代碼中生成新查詢的函數。包含模板包含項目的所有標記，並且樣式進入主站點樣式表，使我的類儘可能通用且可重用，遵循SMACSS的指導原則。我只是按照DRY的要求將組件重構爲包含標籤。
我開始了我的包含標籤功能明確採取由標籤模板中使用的參數，使得：
頁面模板
<div>{% my_tag param1 param2 %}</div>
標籤庫
@register.inclusion_tag('myapp/tagtemplates/my_tag.html')
def my_tag(param1, param2):
return {'param1': param1, 'param2': param2}
my_tag.html
<div>Blah: {{ param1 }}</div>
<div>Blip: {{ param2 }}</div>
...顯然該視圖設置了上下文。
但我決定改用了takes_context參數，以避免明確的標籤庫定義參數。太多的重複在文檔中沒有足夠的回報。到目前爲止，我的組件非常簡單，通過檢查標籤模板，依賴關係非常清晰。我擔心這對複雜的嵌套組件來說可能是不可接受的，但我總是可以讓我的標記庫函數在需要的地方變得冗長。
從維護的角度來看，我並不完全滿意這種設置。我不喜歡，我將不得不手動追蹤不再需要的上下文數據。我不喜歡這樣一個事實，即我的CSS類將不得不被仔細命名以避免衝突。
我仍然接受新的解決方案，因爲我不確定我確定的是否是最佳做法。
對我來說，這似乎是一個非常普遍的問題，這就是爲什麼我發現它有點奇怪，既沒有手冊，也沒有找到任何資源，也沒有我直接收到的答案（直到你的答案），直接解決構建組件級和可維護模塊化架構的問題。也許人們並沒有真正使用Django。但即使是這樣，我仍然期望在任何MVC框架中都存在基本問題。 – acjay