The Even-Darker Art of Rails Engines - RailsConf
When I started talking about the idea of ‘Rails Engines’ a few years ago, everyone thought I was crazy.
Some people said it was stupid, or just plain evil. Despite that, the ability to write simple yet powerful plugins is baked into the core of Rails 2.3.
But heed the words of Uncle Ben: “With great power, comes great responsibility!”
In this session, we’ll discuss how to best take advantage of ‘engines’, in which situations engine plugins are appropriate and those where they aren’t, and how to avoid some of the common issues that can arrive when developing with engine-style plugins.
When we’re done, you’ll be in the best position to take advantage of this newly-sanctified functionality in your own projects.
Notes from the talk:
History of engines plugin:
3.5 years old - predates Rails plugin system - plugin released nov 2005
Mixed response from community to engines approach
Related plugins: appable_plugins, desert
Also related: Merb slices
Nov 2008 - DHH approves inclusion in Rails
What are engines:
Engines are plugins with an /app directory
app/controllers, /models, /helpers, /views, /metal
helper :all won't load helpers from plugins (yet) -- see ticket #1905
plugins/yourplugin/config/routes -- add rotes
Gotcha: plugin routes load first, app routes load second -- plugin routes will override app routes -- see ticket #2592, also #329
1. public assets -- copy assets to public directory. You can always copy.
2. migrations -- see #2058, also see interblah.net/plugin-migrations -- James recommends using a generator
Views just work -- you can override plugin views in app
controllers -- straight override works
plugin defines modules which can be included in controller
subclass controller -- you have access to super
Reuse most effective when it's your code, less so when form some random developer
Some things can't be extracted
Extract specific functionality
Establish clear integration points
Read the code!