1

Rails Single Table Inheritance パターンを介して基本クラス「Entity」から派生した「Person」と「Group」の 2 つのクラスがあります。このパターンは私のコードの多くを乾燥させました。

エンティティ自体には関係がありませんが (has_many など)、Person と Group には固有の関係があります。

コードを簡略化するプロセスを続けると、個人またはグループ オブジェクトへの変更は /entities/:id に対して PUT され、更新アクションがトリガーされます。

問題に入ります: Rails は attr_accessible と、クラスが params[:entity] オブジェクトを構築するために必要なリレーションを使用します。PUT する可能性のある特定のもの (Group 固有の operator_attributes など) は Group にのみ表示され、Entity には表示されないため、Rails はこれらを params[:entity] に含めません。

params[:entity] を作成するための Rails ロジックを書き直すことなく、エンティティ コントローラを使用しながら、この問題を回避するにはどうすればよいでしょうか?

4

2 に答える 2

0

私はこの同じ問題に直面しました。サブクラス化されたモデルの動作が大きく異なるため、シン モデルに合わせてシン コントローラーを作成することになりました。それぞれに異なる検証要件がありました。一般的な Entity オブジェクトを作成してtype、PUT. 適切な種類のオブジェクトを作成する必要がありました。

明らかに、それはあなたが望むほど DRY ではなく、私にとってもそうではありませんでした. しかし、私の場合は、エントリを表示して基本的なレポートを作成できるように、管理パネルでエンティティ コントローラ/モデルを引き続き使用しています。ユーザー側では、それらは分離されており、エンティティは保護されています。それらは、さまざまなコンテキストで、さまざまなロジックとビューで使用されます。したがって、サブクラス化されたモデルごとに個別のコントローラーとビューを使用することは、最終的には正しい決定でした。

STI が私のために行う主なことは、データベースとモデルを DRY することです。継承されたモデルが同じように動作して表示される場合、それ以上に DRY アップが容易になります。これが何らかの形で役立つことを願っています。

于 2012-11-07T23:25:02.863 に答える
0

EntityController の wrap_parameters を無効にし、クライアント側の元の PUT 要求でルート エンティティ キーを作成することで、これを回避しました。

メソッド「attribute_names」がモデルに存在する場合、それが呼び出されるため、基本エンティティモデルは .constantize() または他のメソッドを使用して、適切に何をすべきかを判断できると思います。

最善の解決策は、wrap_parameters が params ハッシュをプログラムで再初期化することです。これはほとんど可能のようです: wrap_parameters を変更できますが、params を再処理する方法がわかりません。

参照: http://edgeapi.rubyonrails.org/classes/ActionController/ParamsWrapper.html#method-i-process_action

于 2012-11-08T01:10:09.490 に答える