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.
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 /
Hope that helps. Perhaps someone who has done more work with making
“generic” plugins based on engines could speak more to the