Rails%203%20In%20Action

470 CHAPTER 17 Engines
copy over assets from an engine into a Rails application any more either; they are
served through the functionality of the Sprockets gem.
Finally, this ancient engine implementation didn’t enforce namespacing of the
controllers or models. This could potentially lead to conflicts between engines and
the application code, where the application code would override an engine’s code. If
the application has a model called Forum at app/models/forum.rb, and the engine has
the same model at the same location (relative to its root), the application’s model will
take precedence. Namespacing is something that you’ll see has almost a zealot level of
impact in the work that is done with engines today. It’s absolutely important to keep
the application and engine’s code separate so that they do not conflict.
So today, we’ve now got engines as a core part of Rails 3.1, and they’re better, and
they’re here to stay. Let’s see why they’re useful.
17.2 Why engines are useful
Engines allow Rails programmers to share common code between applications in an
extremely easy fashion. It’s entirely possible to use more than one engine in an application,
and many people do. Engines are generally provided as gems, and so they are
managed like every other gem your application uses: by using Bundler.
In previous (before 3.0) versions of Rails, we have seen that people had to use the
engines plugin. 9 This was sometimes problematic, because whenever a new Rails version
was released it could potentially break the compatibility of the plugin. By having
this feature within Rails itself, this issue is fixed.
Alternatively, people could use generators. These would often generate controllers,
models, and views in the application itself, which would allow people to change
the code exceptionally easily. When new versions of these generators were released
with changes to the previously generated code, however, there was no clean way to
keep the changes.
One final, very hacky way, would be to copy over the controllers, models, or views
into the application manually from a directory, which runs into the same problems as
described, as well as making it difficult to know if you got it right or not.
With an engine, all the code is kept separate from the application and must be
explicitly overridden in the application if that’s what is needed. When a new version of
an engine is released, it will only alter the code of the engine and not the application,
making the upgrade process as easy as changing a version number in a Gemfile.
Even the routes for an engine are kept separate, being placed in the engine’s
config/routes.rb file rather than the application’s. This allows you to namespace the
engine’s routes so that they don’t conflict with the application.
The whole point of engines is to separate out chunks of functionality, and to be
able to share it without it crashing into the code that already exists.
Let’s generate your own engine and have a look at its parts.
9 http://github.com/lazyatom/engines.