HMVC(Hierarchic Model View Controller)とその柔軟な構造について読んだことがあります。
この写真を見てください:
http://techportal.inviqa.com/wp-content/uploads/2010/02/MVC-HMVC.png
Rails3プラグインがRails3のHMVCへの答えなのだろうか?
HMVC(Hierarchic Model View Controller)とその柔軟な構造について読んだことがあります。
この写真を見てください:
http://techportal.inviqa.com/wp-content/uploads/2010/02/MVC-HMVC.png
Rails3プラグインがRails3のHMVCへの答えなのだろうか?
Toby の回答に対するコメントに基づいて、MVC アプリを新しいアプリ内のコンポーネントとして使用できるようにしたいと考えているようです。Rails エンジン ( http://rails-engines.orgを参照) は、この機能を提供します。エンジンの宝石をインストールし、アプリをベンダー/プラグインに配置するだけで、そのモデル/ビュー/コントローラーにすべてアクセスできます。
これは、新しいアプリのコントローラーが他のコントローラーに委譲する HMVC に実際には準拠していません。しかし、トビーのように、私はその利点を理解していません。
エンジン アプローチの優れている点は、モデルのバージョンを新しいアプリの app/model フォルダーに追加するだけで、プラグイン内の任意のモデルをオーバーライドできることです (ビューとコントローラーにも同じことが当てはまります)。
アプリ/ビュー/レイアウトをオーバーライドして、認証アプリ/プラグインに、それが含まれているアプリケーションと同じルック アンド フィールを与えました。
Rails 3 では、Railtie がエンジンの代わりになり、公式にサポートされています (そして実際に使用されています - Action Mailer は Railtie プラグインです。私自身はまだ使用していません)。
http://edgeapi.rubyonrails.org/classes/Rails/Railtie.htmlで確認してください。
それについての素晴らしい記事もここにあります http://www.igvita.com/2010/08/04/rails-3-internals-railtie-creating-plugins/
Rails には長い間プラグインがありました。
チェーンに沿って要求オブジェクトを渡して、コントローラーが別のコントローラーにディスパッチできなかった技術的な理由があるとは思えません。そうすることで何が得られるかはわかりません。図はスパゲッティのように見えます。
私にとっては、MVC の誤用です。コントローラーのチェーンを作成するよりも、ロジックを下位レベルのモデルとクラスにプッシュし、this ロジックの前に単一のコントローラーを作成する方が、はるかに簡単で保守しやすいことをお勧めします。
Rails 3 のブログ投稿で、DHHは Cellsプロジェクトについて言及しました。使っていませんが、チェックしてみます。
カートの例は、そのような機能がアプリケーション コードをクリーンアップする方法をよく示しています。データを取得するコードは、コントローラーのどこかに配置する必要があります。すべてのアクションまたはフィルター前。セルははるかに優れたソリューションのようです。
この rubyonrails-talk の投稿をご覧ください: https://groups.google.com/forum/#!topic/rubyonrails-talk/0c4TT7UOGCw