カテゴリのすべての子を取得しようとしています:

http://django-mptt.github.com/django-mptt/models.html#get-children

アップデート1:

「get() が複数のカテゴリを返しました -- 7 が返されました!ルックアップ パラメータは {} でした」というエラーが表示されるようになりました。

ありがとう

しばらくの間、私は SQL で階層を処理する最善の方法と格闘してきました。隣接リストの制限と MPTT/ネストされたセットの複雑さに不満を感じた私は、単純なnode_key/node_key/...文字列として代わりにキー パスを単純に保存することを考え始めました。3 つの手法の長所と短所をまとめることにしました。

ノードの作成/削除/移動に必要な呼び出しの数:

• 隣接性 = 1
• MPTT = 3
• パス = 1 (そのパスを含むすべてのノードで、古いノード パスを新しいノード パスに置き換えます)

ツリーを取得するために必要な呼び出しの数:

• 隣接性 = [サブレベルの数]
• MPTT = 1
• パス = 1

ノード/祖先へのパスを取得するために必要な呼び出しの数:

• 隣接性 = [スーパーレベルの数]
• MPTT = 1
• パス = 0

サブノードの数を取得するために必要な呼び出しの数:

• 隣接性 = [サブレベルの数]
• MPTT = 0 (左右の値から算出可能)
• パス = 1

ノードの深さを取得するために必要な呼び出しの数:

• 隣接性 = [スーパーレベルの数]
• MPTT = 1
• パス = 0

必須の DB フィールド:

• 隣接性 = 1 (親)
• MPTT = 3 (親、右、左)
• パス = 1 (パス)

結論

ストアド パス手法は、1 つを除くすべてのユース ケースで、他の手法と同じか、または少ない呼び出しを使用します。この分析によると、パスの保存は明らかに勝者です。言うまでもなく、実装がはるかに簡単で、人間が読めるなどです.

問題は、保存されたパスは MPTT よりも強力な手法と見なされるべきではないということです。保存されたパスがより一般的に使用される手法ではないのはなぜですか? また、特定のインスタンスで MPTT を介して保存されたパスを使用しないのはなぜですか?

また、この分析が不完全だと思われる場合は、お知らせください。

アップデート：

保存されたパス ソリューションではできなくても、MPTT ですぐに実行できることが少なくとも 2 つあります。

1. 追加のクエリなしで、各ノードのサブノード数を計算できます (上記)。
2. 特定のレベルでノードに順序を課します。他のソリューションは順不同です。

階層の保存に MPTT を使用しています。追加と削除の概念は、このModified Preorder Tree Traversalリンクで詳しく説明されています。

Modified preorder tree traversal で特定のノードとそれに関連付けられているツリーを更新するにはどうすればよいですか? 例: - TLA とその階層を TLC の下に移動したい場合。SQLスクリプトを使用して、どうすればそれを行うことができますか?

どんな助けでも大歓迎です。

ありがとう！

問題の背景：

たくさんのディレクトリ、ファイル、添付ファイル、JavaScriptを含むフォルダがあります。ActiveXによって処理され、ネストされたテーブルの後にネストされたテーブルで構成される「JSツリー」タイプの構造を生成するメインコアファイルがあります。要するに、それはひどいです。

私が直面している問題は、データベースにロードして、関連するコンテンツに状態を適用できるようにすることです。

XMLファイルの解析は私にとって必ずしも問題ではありませんが、構造が正しく流れるようにすることは問題です。ファイルは、データベース/ファイルシステムに構造を簡単に作成するのに役立つ論理的な方法でネストされていません。XMLファイルは、Structureそのノードとファイルシステム内の関連コンテンツに関する情報を少し含むノードで構成されています。

それをMPTTタイプの構造にロードすることを考えていましたが、さまざまなノードを論理的に解析して、子/親の関係で構成されるものにすることが、私がつまずいているところです。以下は、このXMLファイルのサンプルです。

ActiveXで解析されると、構造（左側のナビゲーションペイン）は標準のアウトラインまたは順序付きリストのように配置されます。

などなど。私の理解の限りでは、セクションまたはサブセクション（1.1.1.2）を示すこれらの値は、ノードのWBSタグに格納されます。Structure私がしなければならないのは、それらを解析し、それに応じた構造を作成することだと思います。それを行う方法は私が困惑しているところです。

また、Sequence親要素から離れているインデックスの子要素に関する情報を格納するためにsemするノードもあります。

私がしたいこと

私がやりたいのは、データベースエントリの束を作成して（できればMPTTで）、ナビゲーションツリーを簡単に生成できるようにします。次に、個々のファイルをすべて「スクレイピング」して、それらのコンテンツをデータベースも。どういうわけか、テーブル内に「インデックス」を作成するためにWBSノード値を解析する必要があります。

私は、解決策が私が予想しているよりも単純であることを望んでいます。提案、正しい方向の製品をいただければ幸いです。

これを管理するためにCakePHP内でTreeBehaviorを使用することを計画していましたが、ファイルを処理するために必ずしもそれを使用する必要はありません。

モデルの外部キーであるモデルにdjango -mpttを使用しています。CategoryProject

Categoryを使用して管理者を設定するのは簡単で、カテゴリMPTTModelAdminを選択するための優れたネストされたドロップダウンを備えていparentます。

Category今、私は管理者に素敵なネストされたドロップダウンを含めたいと思っていますProjectが、標準admin.ModelAdminにはこの機能が含まれておらず、サブクラス化が機能MPTTModelAdminしていないようです:

プロジェクトには「親」という名前のフィールドがありません

非 MPTT 管理ツールでネストされたドロップダウンを模倣することは可能ですか?

このDjango ブログ アプリカテゴリ システムを django-mptt に渡します。

私が抱えている問題は、_get_online_category方法についてです。このメソッドを使用すると、 を持つカテゴリのみを取得できますEntry。

エントリを持つカテゴリを持つカテゴリも持つように変更するにはどうすればよいですか?

例えば ​​：

私は持っていてSpain > Malaga、マラガはEntry前の方法で手に入れました。私は両方を手に入れたいのですMalagaが、手に入れません。Spain

2 番目の質問:

親カテゴリからすべてのエントリを取得する方法は?

たとえば、スペインからマラガの投稿を取得しますか?

スペインでは空の結果が返されます。

私はmpttオブジェクトを持ってい$pages ます

その構造はhttp://pastebin.com/CSGenz7yのようになります

ナビゲーションメニューをレンダリングする必要があります。次のコードを使用します。

次の出力が得られます: http://pastebin.com/MDMM2FcD

しかし、私はすべての子供ul liが親liの中にいる必要があります: http://pastebin.com/JteBPGqb

私は半日を過ごしましたが、何もありませんでした。何かアイデアはありますか?

次の場合view：

comments_extra_data_listMPTTツリーの各ノードのデータを表示するためにテンプレートに渡すにはどうすればよいですか？

次のように tree_id フィールドをオーバーライドします。

与えられた:

「モノ」の最初の親を作成しているときに、オブジェクトが最初に保存されたときに割り当てられたthing_idでtree_idを開始したいと思います。

次に、後で作成される「Thing」オブジェクトには、先に作成された最初の親の thing_id を渡したいと思います。

つまり、tree のすべてのノードは、最初の祖先の objectId(thing_id) を tree_id として持ちます。

出来ますか？

「モノ」オブジェクトの作成中に値を渡すにはどうすればよいですか?

編集：

したがって、私のニーズに対する解決策は単に Thing.objects.get(pk=thing_id).get_descendants() のようです

データベース駆動型の任意にネストされたテンプレート コンテキストが必要な状況に何度も遭遇しました。このコンテンツは常に非常に単純ですが、構造は大きく異なります。

過去に、私はウェブサイトの小さなセクションのモデルを作成しましたが、モデルの数が増えるとすぐに維持するのが少し悪夢になり、編集可能なコンテンツの小さな領域ごとに同じことを繰り返し始めました。管理者は、特定の部分ごとにインラインでいっぱいになります。

これを解決するために、単純な DB 駆動のコンテキスト モデルを作成したいと思います。おそらく、django の admin のような小さなフレームワークを作成して、特定の目的のためにデフォルトの構造を生成します。

私の現在のモデルは基本的に次のようになります。

このモデルから、任意の深さの Python 辞書を簡単に作成できます。問題は、子ノードのリストとディクショナリをどのように最もよく区別するかです。子としての単一のディクショナリ、子としての値のリスト、または子としてのディクショナリのリストです。

type子供たちが強要される余分なフィールド？

子キーで決定しますか?

• すべての子が同じキーを共有している場合、それはリストです。キーを無視します。
• 子が 1 つ以上ある場合、それは辞書です。
• 子がない場合は文字列です。

助言がありますか？

PS: 私がピクルを使わない唯一の理由は、最初からこのデータの編集を処理するために管理者を使用していて、FileField. 真実は、私はストレージをあまり深く調べていないということです. 基本的に、ここでの私の動機は、役に立つものをすばやく作成することです。このシステムは、すべての子を強制的に辞書項目にすると、約 5 分の「骨のストック」で機能し、Web サイトの管理者が編集可能なランダムな領域を作成する際の問題を解決します。