I'll cover some of your points here, and other ones on the engines
my understanding is that plugins' approach to anything
with views is to use generators.
you cant actually have view/controller code in the plugin?
That's correct, although some of the recent changes in edge rails make
it slightly easier to load views from different paths (http://
However, for Rails 1.2.x, the engines plugin provides the small amount
of patching required to load views from plugins.
- dependencies on main app / models
first, there are dependencies on the main app's user model.
Is this a problem? Your shared code simply requires some objects for
working with the user accounts that respond to a set of well-known
methods. Even if your user accounts use different tables in different
applications, this can normally be circumvented by using a common
interface (i.e. a current_account method somewhere) to access it.
Regardless, this isn't a significant problem until you start sharing
your forums with other developers whose code you cannot control.
there arent easy way to share migrations with the main app and an also
I presume you've seen the migration integration that the engines
plugin provides? This works very well as a solution for evolving the
schema required by shared plugin code.
- getting added code back into plugin
a generator is basically one-way.
This is basically the primary motivation for enhancing plugins in the
way that engines does.
- view helpers?
since plugins support -view helpers- we could rewrite the forum views
all as helper methods.
This might be possible, but it's such a departure from how you
typically develop a Rails application, is it worth pursuing? You will
also encounter problems when you try and delegate production of views
to designers if you choose this route.
- installing partials
another thing some people seem to do is have the installer copy some
partials into the main app.
That's definitely a possibility, but you'll run into the same
"generators are one-way" issue as before.
- can a plugin include a controller?
i guess it could include a library, which is a module that the
controller in the app could require...
The easiest type of non-typical code to include in a plugin is a
controller - if this is all you need, there are solutions which exist
for doing this without including the engines plugin (google is your
ally here). However, these still involve playing with some Rails-
internal functionality, only this time it's in your plugin's init.rb
file, rather than being provided by another plugin (engines). YMMV.
"engines" seem to allow most of what i need, but they dont seem to be
getting much use.
Regarding your other concerns about engines being unstable and so
on... this is only really a concern if you like developing against
edge rails, and the same concerns exist on any code that you rely on
but aren't responsible for.
If you feel like you need some of the functionality that the engines
plugin provides, take a look at it. You're certainly free to tear out
the methods that you need and discard the rest, if that feels like a