Contributing to Rails | 291Complex scaffolding
Scaffolding is another misunderstood issue in Rails. Like high-level compo-
nents, scaffolding can be overapplied. Developers who see scaffolding as a sub-
stitute for writing complex application code will be disappointed.
Still, there are many valid uses for simple CRUD features, especially on an applica-
tion’s administrative interface. Streamlined (http://streamlinedframework.org)isa
way to quickly build CRUD interfaces on top of Rails. Additionally, AjaxScaffold
(http://www.ajaxscaffold.com/) is a scaffolding system with a richer interface than
the built-in Rails scaffolds.
There is another reason for starting a feature as a plugin, though. Plugins are often a
testing ground for experimental or risky features before they are rolled into the main
distribution. As an example, the RESTful features of Rails 2.0 were a plugin,simply_
restful, before they were pulled into Rails trunk.
Contributing Patches
There is a new process for contributing Rails bug reports and patches, to help deal
with the large volume of tickets and contributed patches. The process is as follows:
Write a patch
Bug reports are always welcome, but patches get more attention. Fixing prob-
lems that you experience, even if they are problems with Rails itself, has some
advantages. It gives you greater familiarity with the Rails source, which is very
well written. It also helps you verify and prove that the problems you are experi-
encing are actually problems with Rails.
Most patches should include tests. Especially for bugfixes, test-driven develop-
ment is a good philosophy to use. A test-driven methodology would incorporate
the following basic steps:
- Before writing any application code, write a test that verifies the correct
functionality. Run the test; it should fail. - Write code to fix the bug until the test passes.
- Verify that all other tests pass, not just the test in question.
Most areas of Rails are well-tested; however, there are some components (such
as the generators and CGI processing code) that are not very easy to test. When
writing nontrivial patches for those areas, the burden of proof is higher to ensure
that there are no regressions of other functionality.
The basic procedure to create a patch against Rails is simple:
1.svn up to grab the latest version of Rails. - Make the appropriate changes to the source.
- Runrake to ensure all of the tests pass.