Rails%203%20In%20Action

A brief history of engines
as Devise, a commenting engine, or even a forum engine. If there’s ever been a need to
have the same features across an application, this is what engines were made for.
By installing an engine as a gem or plugin and then mounting it at a specific route
in the config/routes.rb file of your application, you gain access to its features. Each
engine will be different, so be sure to consult the README or other documentation
that comes with it in order to figure out exactly how it works.
We’ll begin by discussing the history of engines and why they’re now a major part
of the core ecosystem, as it’s helpful to know the reasons why they weren’t available in
releases earlier than 2.3.
In this chapter we’ll go through a little bit of the history of engines, why engines
are useful, and how they work, and then you’ll develop one of your own. At the end of
the chapter, you’ll integrate the engine with the Ticketee application you have developed
earlier in the book.
17.1 A brief history of engines
On November 1, 2005, James Adam begun work on what would become the engines
plugin. 5 Starting off crudely, engines eventually evolved into something much more
useful, serving as the inspiration for the functionality within the Rails core today.
There was a lot of controversy surrounding engines, 6 and James spent a lot of his time
defending the decision to develop them. Since then, however, the community has
grown to accept the idea of engines.
One of the major problems of having this engines plugin live outside of the core
framework was that there wasn’t a clearly defined place where it could hook into Rails
code. Rails could potentially change and break the engines plugin, which would prevent
people from upgrading to the latest version of Rails until the engines plugin was
updated.
It was decided during the development process of Rails 3 that engines should be a
core feature, and so a large chunk of work has gone into getting them right. By having
them in core, it means that there is a clearly defined public API for engines and when
newer versions of Rails come out, there’s an almost-zero 7 possibility of things breaking.
Part of this work was added to Rails 2.3, and very basic engines were possible back
then, 8 but things such as copying migrations and assets were not supported. Additionally,
there was no way of running the Rails generator and so files had to be generated
in a real application and then copied over.
Since then, engines have been dramatically improved. Rather than having to copy
over migrations manually, there’s a specific Rake task to do that. There is no need to
5 http://github.com/lazyatom/engines.
6 http://glu.ttono.us/articles/2006/08/30/guide-things-you-shouldnt-be-doing-in-rails and http://article
.gmane.org/gmane.comp.lang.ruby.rails/29166 to name two such criticisms.
7 In programming, the chances of things breaking over time approaches zero, but never truly reaches it.
8 A good demonstration of engines in Rails 2.3 can be seen on Railscast #149: http://railscasts.com/episodes/
149-rails-engines.
469