# Rails code reuse: plugins (and engines) **URL:** \ **Category:** Rails\ **Created:** [August 5, 2007, 11:38pm UTC](https://www.ruby-forum.com/t/rails-code-reuse-plugins-and-engines/111320 "2007-08-05T23:38:21Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![d3ntaku2](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/ce73a5/32.png) [@d3ntaku2](https://www.ruby-forum.com/u/d3ntaku2)\ **Post date:** [August 5, 2007, 11:38pm UTC](https://www.ruby-forum.com/t/rails-code-reuse-plugins-and-engines/111320/1 "2007-08-05T23:38:21Z")
------ 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](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](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 ---
**Author:** ![d3ntaku2](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/ce73a5/32.png) [@d3ntaku2](https://www.ruby-forum.com/u/d3ntaku2)\ **Post date:** [August 6, 2007, 12:04pm UTC](https://www.ruby-forum.com/t/rails-code-reuse-plugins-and-engines/111320/2 "2007-08-06T12:04:44Z")
I’ll cover some of your points here, and other ones on the engines mailing list. On Aug 5, 10:38 pm, D-- C-- [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://interblah.net/2007/2/5/more-plugin-power-goes-into-rails-core)). 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 🙂 - James