290 | Chapter 9: Incorporating and Extending Rails
There are several reasons that useful features are rejected from Rails in favor of being
plugins. The primary reason for rejection is that the feature is too specific; it would
not be useful to most Rails developers. Alternatively, it may be contrary to the “opin-
ion” of the framework. However, features may be rejected simply because there are
many valid ways of accomplishing one goal, and it does not make sense to default to
one. Some common areas of functionality that have been repeatedly discussed and
rejected from Rails core are the following:
Engines
David Heinemeier Hansson’s rejection of high-level components in Rails is a
topic that has generated much more heat than light. Rails engines (http://rails-
engines.org) are full-stack (model, view, and controller) components that can be
incorporated into larger applications; in effect, they augment the plugin system
to structure the sharing of model, view, and controller code.
The trouble with engines comes when they are treated as high-level compo-
nents, as if dropping a content-management-system engine into an application
will accomplish 90% of the CMS functionality a particular project needs. In
many cases, the work required to integrate such a high-level component into an
existing application outweighs the benefits of not writing the component from
scratch.
In short, engines are best seen as a way to structure plugins that need control-
ler and view code, rather than a drop-in replacement for high-level features.
In this respect, engines are amazingly powerful; they allow plugins to aug-
ment an application’s models, views, controllers, helpers, and even routes and
migrations.
Internationalization and localization
There are many valid approaches to the problems of internationalization and
localization. We discuss several solutions in Chapter 8. ActiveSupport’s Multi-
Byte standardizes the low-level operations on Unicode text, but there are still
many valid ways to localize an application at the high level.
Authentication and authorization
Again, there are many application-specific ways to authorize users that authori-
zation does not belong in Rails. Authorization can range from a simple “admin”
Boolean flag on a user’s record to a complete role-based access control system,
and there are plenty of plugins available for authorization in Rails.
Similarly, there are many valid ways to authenticate users. The only authentica-
tion method in Rails proper is HTT PBasic authentication, because it is very sim-
ple. However, the most popular authentication solutions descend from the
acts_as_authenticated plugin by Rick Olson (which has its roots in Tobias
Lütke’s original Login Generator). The newer version of acts_as_authenticated
is restful_authentication, which is the same logic molded into Rails 2.0’s REST-
ful paradigm.