0

何かに頭を悩ませている。基本的に、私はグループのグループのグループのグループのグループを含む新しいプロジェクトを開始しています...そうですね。

いずれにせよ、アプリケーション全体である程度「普遍的」な唯一のモデルは、ユーザーの概念です (ユーザーは 1 人が持つ権限を決定するものであるため)。問題は、他のグループを「所有」できるグループがある場合に発生します。たとえば、「国家」支部が所有する「州」支部が所有する「市」支部を持つことができます。また、各支部は、その下にあるすべてのグループに対する権限を持つときに、独自のユーザーを持つことができます。 .

ただし、1 つのグループが別のグループによって所有 (または使用) されることが保証されているわけではないため、個別に管理する必要があります。この性質のものを処理するための方法論がどうなるかを完全に概念化することはできません。おそらくある種のacts_as_nestedセットアップを使用できるということですが、それでさえ手に負えなくなるのではないかと心配しています。また、グループ自体に関する限り、ある種の継承モデルを使用する必要がありますか (多くのプロパティを共有する可能性が高いことを考えると)。

おそらく、グループごとに個別の MVC セットアップを作成する必要がありますが、ユーザーの関連付けなどの問題はまだあります。誰か提案を提供できますか?

一番

4

1 に答える 1

0

自己参照するグループ テーブルを作成できます。これにより、すべてのグループ データが 1 つのテーブルに保持され、魔法は関連付けによって行われます。

Ryan Bates は、あなたの状況に合わせて微調整できると思われる Railscast を持っています。たとえば、友情ではなく、所有権などを持っています。

編集：片親だけが役に立ちます。プラグインのacts_as_treeは、当面のタスクで機能する可能性が高いようです。Ryan Bates はたまたまそのプラグインのrailscasts エピソードを持っています。

目的

1: グループが子、親を持つことを許可する解決策: act_as_tree

2: グループが潜在的に独立したり、独立したままになったりできるようにします。 解決策：acts_as_tree。parent_id を削除するだけで、グループは独自のルート ノードになります。

3: 階層を強制します (たとえば、都市は親として別の都市を持つことはできません)。 解決策：これは、カスタム検証を介して行う必要がある可能性があります

4: ユーザーの権利の継承。私は、この特定の目標が最も困難であると予想していました。もちろん、あなたのアプリケーションにとって「権利」が何を意味するのか、すべてを知っているわけではありませんが、いくつかの仮定を立てます...私が間違っているところはあなたが埋めてください。ユーザーとグループ (および可能性のある「権利」テーブル) の間の関連付けを取得したら、解決策: current_group の current_user に権限を適用する必要があるかどうかを判断するには、a) 所有権を確認し、そうでない場合は b) 回答が得られるかルートに到達するまで current_group.ancestors を横方向に移動します。

楽しいプロジェクトのようですね。幸運を祈ります！

于 2011-05-20T04:18:46.910 に答える