In Ruby, redefining a class simply adds/overwrites the original class.
So, if you had an ApplicationController in your main app, and installed
an engine plugin with a controller of the same name, the methods defined
in the second class would add to the application's core controller
class. However, I think you're asking about routing, namely, if I have
a WidgetsController with a method index in my main app, and a
WidgetsController that *also* has an index method, which wins? Good
question. :-) My bet would be that the view defined in the main app
would win in a race, due to the search order for finding views. The
index method itself would be the plugin's definition, as the plugin's
WidgetsController class would be loaded second, and thus overwrite the
main apps definition. Bad juju.
In practice, you should aim for some name scoping for your controllers.
This generally happens naturally (ie, if you have an engine that
provides user management, why would you have a UsersController in your
main app?). I *think* Rails has some facility for using namespacing in
controllers and routes as well, but I haven't used it, so can't help
much there.
As for databases, the database is shared by default. You build
migrations to add whatever tables your engine needs. You can, of
course, use the normal Rails database segmentation stuff to point your
models to a second database, but I don't think that's very common. It
would require a lot of front-end work to install the plugin, which is
counter to the plugin way.
Really, engine plugins are best used internally (IMHO). I've used them
to build application verticals that I can reuse for multiple consulting
clients. Drop in the wiki engine, and now the site has wikis. As such,
I don't have collisions with naming/tables/routing. The engines are
core application resources that I install before the site is designed.
If I need to customize a certain view or whatever, I usually do it by
grabbing the request out via my app's routes.rb file, and pointing it to
/site/wiki_view or whatever, instead of /wikis/view.
Hope that helps. Perhaps someone who has done more work with making
"generic" plugins based on engines could speak more to the deconflicting
issues.
-Rob
Chris Griffin wrote:
First of all the two links to articles on building plugins to take
advantage for engines are broken.
a guide building plugins that can take advantage of the engines
plugin’s features
<http://gwyn.dezyne.net/page/writing_a_plugin_with_engines_>
best introductions to developing an engine
<http://alterlabs.com/ruby/how-to-build-a-ruby-on-rails-engine-in-depth-start-to-finish-tutorial>
My first question is how do you handle a plugin that has a controller
with the same name a your current rails app does? Second, how do you
handle the database? Do you have two separate DBs? If so how does that
work? Or is there code in the engines plugin to handle multiple DBs?
I'm interested in developing some plugins for engines so if there is
more information you can point me to that would be great.
Best regards,
Chris Griffin
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
------------------------------------------------------------------------
_______________________________________________
Engine-Users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
_______________________________________________
Engine-Users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
