レール内のSTIサブクラスのルートを処理するためのベストプラクティス
私のRailsのビューとコントローラが散らばっているredirect_to、link_toと、form_forメソッド呼び出し。ときどきlink_to、redirect_toリンクしているパスでは明示的ですが（例：）link_to 'New Person', new_person_path、多くの場合、パスは暗黙的です（例：）link_to 'Show', person。 モデルにいくつかの単一テーブル継承（STI）を追加し（たとえばEmployee < Person）、これらのすべてのメソッドがサブクラスのインスタンスで壊れます（たとえばEmployee）。railsを実行するとlink_to @person、でエラーが発生しundefined method employee_path' for #<#<Class:0x000001022bcd40>:0x0000010226d038>ます。Railsは、従業員であるオブジェクトのクラス名で定義されたルートを探しています。これらの従業員ルートは定義されておらず、従業員コントローラーもないため、アクションも定義されていません。 この質問は以前に尋ねられています： でStackOverflowの、答えはあなたの全体のコードベースでのlink_toなどのすべてのインスタンスを編集して、明示的にパスを述べることです 上のStackOverflow再び、二人が使用することをお勧めroutes.rb（親クラスにサブクラスのリソースをマッピングするためにmap.resources :employees, :controller => 'people'）。同じSOの質問の一番上の答えは、コードベースのすべてのインスタンスオブジェクトを使用して型キャストすることを示唆しています.becomes StackOverflowのもう1つの方法は、トップの答えはDo Repeat Yourselfキャンプでの方法であり、すべてのサブクラスに重複する足場を作成することを提案しています。 ここでだ同じ質問がトップの答えはちょうど間違っているように思わSO、再び（Railsの魔法だけで動作します！） Webの他の場所で、F2Andyがコード内のすべてのパスで編集することを推奨しているこのブログ投稿を見つけました。 ブログ投稿「単一テーブルの継承と論理的現実の設計でのRESTfulルート」では、上記のSOの回答番号2のように、サブクラスのリソースをスーパークラスコントローラーにマップすることをお勧めします。 Alex ReisnerがRailsでシングルテーブル継承を投稿しています。routes.rbそこlink_toではredirect_to、とからのルーティングの破損のみをキャッチし、からのルーティングの破損はキャッチしないため、での子クラスのリソースの親クラスへのマッピングに反対していform_forます。したがって、代わりに親クラスにメソッドを追加して、サブクラスがクラスのうそをつくようにすることをお勧めします。良さそうですが、彼の方法は私にエラーを与えましたundefined local variable or method `child' for #。 最もエレガントなようで、ほとんどのコンセンサスを持っている答えは、だから、（それがすべてではないことを、エレガント、またその多くのコンセンサスが）、あなたにリソースを追加することですroutes.rb。ただし、これはで機能しませんform_for。明確にする必要があります！上記の選択肢を抽出するために、私のオプションは サブクラスのリソースをスーパークラスのコントローラーにマップしますroutes.rb（サブクラスでform_forを呼び出す必要がないことを願っています） クラスを互いに嘘をつくようにレール内部メソッドをオーバーライドする オブジェクトのアクションへのパスが暗黙的または明示的に呼び出されるコード内のすべてのインスタンスを編集して、パスを変更するか、オブジェクトを型キャストします。 これらすべての相反する答えがあるため、判決が必要です。良い答えはないようです。これはレールの設計の失敗ですか？もしそうなら、それは修正される可能性のあるバグですか？または、そうでない場合は、誰かが私にこれを真っ直ぐに設定して、各オプションの長所と短所を説明し（または、それがオプションではない理由を説明して）、正しい答えと理由を教えてください。それとも私がウェブで見つけていない正しい答えはありますか？