# Some questions

**URL:** <https://www.ruby-forum.com/t/some-questions/147559>\
**Category:** Engines\
**Created:** [September 3, 2008, 5:26am UTC](https://www.ruby-forum.com/t/some-questions/147559 "2008-09-03T05:26:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Chris\_Griffin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/7cd45c/32.png) [@Chris\_Griffin](https://www.ruby-forum.com/u/Chris_Griffin)\
**Post date:** [September 3, 2008, 5:26am UTC](https://www.ruby-forum.com/t/some-questions/147559/1 "2008-09-03T05:26:13Z")

</div>

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

best introductions to developing an engine

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  
removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![Chris\_Griffin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/7cd45c/32.png) [@Chris\_Griffin](https://www.ruby-forum.com/u/Chris_Griffin)\
**Post date:** [September 3, 2008, 5:54am UTC](https://www.ruby-forum.com/t/some-questions/147559/2 "2008-09-03T05:54:16Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Chris\_Griffin](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/7cd45c/32.png) [@Chris\_Griffin](https://www.ruby-forum.com/u/Chris_Griffin)\
**Post date:** [September 3, 2008, 6:58am UTC](https://www.ruby-forum.com/t/some-questions/147559/3 "2008-09-03T06:58:00Z")

</div>

I kinda had in mind 2 different situations when I asked my questions.  
The first situation was a particular engines plugin substruct. The  
second situation you mentioned, building application verticals. The  
second is really the one I’m most interested in as I believe it could  
make for building sites more quickly. Thanks for your detailed response.

Best regards,  
Chris Griffin  
removed\_email\_address@domain.invalid

On Sep 2, 2008, at 8:53 PM, Rob M. wrote:

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
