Prev | Current Page 428 | Next

Brad Ediger

"Advanced Rails"

The plugin system
was designed so that Rails would not have to incorporate every feature that is
useful to someone. Refer to Chapter 3 for information on writing plugins to extend
Rails; it is only minimally more work than patching the Rails codebase.
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 ???opinion???
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://railsengines.
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 components,
as if dropping a content-management-system engine into an application
will accomplish 90% of the CMS functionality a particular project needs.


Pages:
416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440