あなたは本当に隔離されたエンジンを意味していると思います。Engine rdocの「isolated」を参照してください。マウント可能であるが分離されていないエンジンを作成できます。つまり、本質的には、独自のルーティングを持っていることを意味しますが、それ以外は、昔ながらの非分離エンジンと同じです。
しかし、これらの理由から、エンジンを孤立したものとして書くのをやめました。ホスト アプリから実際に完全に分離されたエンジンが必要になることはめったにありません。通常、ホスト アプリにアクセスさせたいビュー テンプレート (具体的にはレイアウトではない場合) があります (そして、同じ名前を付けるだけで独自のローカル テンプレートでオーバーライドできるようにしますが、ロード パスの前にあるホスト アプリ)、および/またはホスト アプリにアクセスしてメソッドごとにオーバーライドできるようにするヘルパー メソッド、および/またはホスト アプリで利用したいアセットなど。はい、それらをコピーするジェネレーターを作成できますが、ホストアプリでそれらを「フリーズ」し、前方互換性の問題になる可能性があります。
したがって、個人的には、分離されたエンジンは、解決するよりも多くの問題を引き起こすことがわかっています。「通常の」エンジンを使用するだけで、適切な方法で分離する必要がある部分 (たとえば、モジュールの名前空間コントローラー) を DIY で分離します。
ルーティング/マウント可能についても同じです。私は Rails の「マウント可能な」エンジンを使用していませんが、自動的に読み込まれる独自の engine/config/routes.rb を使用して、エンジンが自動的にホスト アプリにルートを追加することもありません。代わりに、(マウントできない) エンジンに、ホスト アプリが独自の routes.rb に配置できるメソッドを提供させます (ルーティング オブジェクトは引数として渡されます)。このメソッドを呼び出すと、エンジンに必要なルーティングがアプリに追加されます。このメソッドは、引数をとってカスタマイズすることができます (一部のルートのみを追加し、他のルートは追加しない、カスタム ルーティング名前空間を使用するなど)。
Rails 3 は、必要なすべてのビルディング ブロックを「プレーンな」エンジンで提供し、希望する方法でアプリと正確に統合できると思います。これらの選択肢の束を修正するマウント可能/分離のより高いレベルの抽象化は、特定のユースケースにのみ適合するものになります。完全に分離されたサブシステムであるエンジンが本当に必要な場合は、もちろんです。Rails だけでなく任意の Rack アプリで動作するエンジンを作成する必要がある場合は、基本的に完全に分離されたサブシステムとして実行する必要があります (これが、devise が現在の場所に行き着く方法です)。それをするために。しかし、それは実際には「これから一般的にエンジンを行うための最良の方法」の未来ではないと信じるようになりました.
あなたがやろうとしていることについては、エンジンを分離することは逆効果になると思います。孤立しないようにします。しかし、エンジンを必要な種類の分離とルーティング (不要な種類ではなく) だけで動作させる方法について理解する必要があります。 .