2016-06-14 9 views
2

私が取り組んでいるアプリケーション用のレールエンジンを作成しています。メインアプリケーションからのレールマウント可能なエンジン使用のdbスキーマ

基本的には、アプリケーションが2つのセクションに分かれています:privateサイトはすべての管理機能の生活や公共サイト(エンジン)のメインアプリケーションである

  1. プライベート
  2. 公開

プライベートアプリからモデルにアクセスできるはずです。

それは私の逆のように聞こえるが、これは仕様が要求するものである。

私は、一般的に次のようなあなたのメインアプリでエンジンモデルにアクセスします知っている:

は、EngineName ::モデル

私はエンジン内部のメインアプリケーションにアクセスする方法は?

例:

プライベートユーザーがfoo.bar/videos/newと新しい動画を作成するために行くだろう。

公開ユーザーはfoo.bar/public/videosにアクセスして、同じ動画にアクセスできます。

+0

機能をプライベートセクションとパブリックセクションに分割するのは理にかなっていますが、このような状況ではなぜエンジンパターンを使用する必要がありますか? – declan

+1

私はそれは良い質問だと思いますが、あなたは不必要なハードルを飛び越えているようです。 "スペック"を満足させるだけでなく、このようにして本当に何を達成しようとしていますか?仕様はプログラマによって書かれましたか? –

+0

通常は、別の場所で再利用したいので、機能をエンジンにパッケージ化します。エンジンにホストアプリケーションからのコードへの呼び出しが含まれている場合は、再利用できません。その場合、私はあなたがエンジンとしてそれを書くことから得ようとしている利益について興味があります。パブリックとプライベートの間に明確な線を描きたい場合は、[ネームスペースを使用する方が簡単かもしれません](http://guides.rubyonrails.org/routing.html#controller-namespaces-and-routing) – declan

答えて

1

これをテストしただけで、問題なくエンジン内部のホストアプリケーションからコードを参照できました。

# In the main application 
# lib/test_library.rb 
TestLibrary 
    def self.say_something 
    "Hello! I am defined in the host application, not the Engine." 
    end 
end 

# Then, inside the engine 
# app/views/your_engine_name/some_resource/index.html.erb 
<%= TestLibrary.say_something %> 

これはエンジンテンプレートで正常に印刷されます。したがって、Videoモデルをお持ちの場合は、コントローラがアプリケーションの一部だった場合と同様に、エンジン内部のコントローラで参照することができます。

これは、エンジンパターンがお客様の要件に最も適しているかどうかはわかりません。

このように書くことは、エンジンコードを他の場所で再利用できないことを意味します。再使用が気にかけない場合は、おそらくエンジンは必要以上に重いソリューションです。 namespaceの使用を検討することもできます。

+0

ありがとうございました。はい、私はネームスペースがもっと理にかなっていることに完全に同意しますが、私のチームリーダーはこの方法でやりたいと思っています。 – sump

関連する問題