2011-02-25 56 views
2

我正在重建一個網站,其中包含許多用戶貢獻的內容(帖子,圖片,事件等)。該內容屬於部分內容(音樂,商店等);即正常的CMS。django:CMS的遞歸/樹狀URL映射?

我希望每個內容都從基本內容對象(多表繼承)繼承。這意味着所有的內容可以很容易地查詢和整潔和可擴展的(並且無需重新編寫所有的基本的東西像「CREATED_BY」,「標題」,「塞」等)

ContentObj 
    > Blog Post obj 
    > Event Post obj 
    > Podcast Post obj 
    > ... etc. 

漂亮straightfoward。

當涉及到組織,各種內容的OBJ /型號應該被分配到部分的選項(即播客物體進入下「音樂」)。另外,一個部分應該能夠將自己分配給父節('Words> Blog> General>')。再次,這是CMS中一個非常標準的理念。

理想情況下,我想這樣的一個完全通用的解決方案來組織(就像我有一個通用的解決方案,內容)。我正在考慮樹狀結構,其中每個節點都是節或內容對象模型。

root 
    > section1 
     > subsection 1 > contentobj1 
     > subsection 2 > contentobj2 
    > section2 
     > contentobj3 

    > contentobj4 

這個通用設置的目標是擁有一個非常乾淨的URL方案和模板系統。你只需要兩個或三個模板。您根據用戶請求的網址填充頁面,並且永遠不需要對/ blog//等URL進行硬編碼。

我無法理解如何在數據庫驅動的應用程序中編寫此結構樹。有一個可以分配內容模型的模型部分很容易。但是當涉及到小節時,它有點棘手。此外,如何抽象URL方案,使一個部分可以有多少小節指向一個內容對象,而不需要實際對URL進行硬編碼?

基本上我想要寫的結構/骨架,其中內容和組織是獨立的,和URL /模板方案,並完全獨立於實際的內容。以前我也有一個博客,應用,事件,應用程序,但我肯定應該有一個管理部分等

回答

4

用於實現內容的應用程序,管理該網站的所有內容,也許一個組織應用在你的模型樹,結帳trees and graphs section on django packages。我已經使用並建議Django的MPTT

在一個側面說明,你爲什麼不看看。它是一個非常靈活並且有很多擴展點來集成自己的應用程序的偉大應用程序。

+0

我從來沒有看過mptt,但是在閱讀本文時立即想到了treebeard ...... – meshantz 2011-02-25 17:54:09

+0

我沒有機會使用treebeard,因爲我已經在項目中使用過樹木mptt。 – zsquare 2011-02-25 18:02:11

+0

他們都看起來像他們會做樹形結構的業務,即部分 – 2011-02-25 19:43:42

1

我喜歡這個問題。這是自從離開plone-land後,我在腦後滲入的東西(並不是我不會時不時地回到那裏)。

我肯定會從一些樹型應用程序(如zsquare建議)開始,並構建一個基本模型,利用通用外鍵來鏈接您所討論的各種內容類型 - 事件,文章,類別等。

從那裏,我會深入到管理員看看它是如何與動態URL生成交易,並從那裏,利用樹包提供建立我的內容樹的URL的功能。

+0

是的,在硬編碼的方式下放置了一個CMS,我試圖找出這個想法。經過深思熟慮,我認爲這應該很容易與分層的東西。我將看看管理員的東西。這是讓我感受到的遞歸URL – 2011-02-25 19:46:46