Rails code reuse: plugins (and engines)

Rails
1

------ reusable code in rails

Like many other companies I’m sure, we have a bunch of rails code for
building social networks. and we’re doing lots of projects that are very
similar.

i was wondering what rails options have been succesful for other
people for code re-use across projects.

my understanding is that plugins’ approach to anything
with views is to use generators.
you cant actually have view/controller code in the plugin?

the problem with generators is that then you cant re-use any
modifications to the generated code - theyre basically one-way.
but this maybe OK, if a lot of the actual code is still in the plugin.

  • concrete example: forum
    a good specific thing we need to do: a forums
    if we move this into a plugin…

  • dependencies on main app / models
    first, there are dependencies on the main app’s user model.

  • migrations
    there arent easy way to share migrations with the main app and an also
    evolving plugin.
    this could possibly be solved in the plug-in installer having its own
    mini-migrations.

  • getting added code back into plugin
    but, lets say we add a function to the forum. eg we want to show the
    “status” of any poster.
    eg are they a level1, or level5 person.
    this is basically a modify of the view, plus reading some data from
    the user model: user.status
    not much controller code.

if we modify the BBS view after the code was generated,
then no code goes back into the plugin for re-use/sharing.
a generator is basically one-way.

  • view helpers?
    since plugins support -view helpers- we could rewrite the forum views
    all as helper methods.
    these could then maybe be passed parameters? eg render_forum
    (:with_status) would be in the generated view for the app.

  • installing partials
    another thing some people seem to do is have the installer copy some
    partials into the main app.
    this is just as set in stone as generators really. eg:
    http://svn.nanorails.com/plugins/bookmarkit/install.rb

  • 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…

  • non abstract plugins
    basically for abstract functions (like a swf renderer, or AR/ acts_as
    extensions) the plugin approach works well.
    but not sure how much it will save us on these very view-oriented
    items.
    it may end up being a lot of work to make the plugin, and then its
    basically just a fancy way to cut and paste the code.
    how much code will actually be in the plugin, vs. what is generated?

“engines” seem to allow most of what i need, but they dont seem to be
getting much use.
they depend lot of rails internals, and it seems they aren’t the safest
way to go

  • every time rails changes, all engines break. if the developer stopped
    maintaining engines, i doubt we’d be able to go in and keep things
    working…and so be stuck without.
    there are very few ppl using engines vs. plugins.
    http://www.railslodge.com/plugins/category/6

i think this is a problem for rails. now components are in limbo, there
isnt an obvious way to reuse/subclass view-related functionality.

Any thoughts appreciated.

/dc

2

I’ll cover some of your points here, and other ones on the engines
mailing list.

On Aug 5, 10:38 pm, D-- C-- [email protected] wrote:

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://
interblah.net - start).
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.

  • migrations
    there arent easy way to share migrations with the main app and an also
    evolving plugin.

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
safer approach :slight_smile:

  • James