第一章 前言
Ruby on Rails 是個更易於開發，配置，和管理Web應用程序的框架。當然，所有的Web框架都會這麼說。但Rails與它們的區別是什麼呢？我們可以從技術做些回答。
一種途徑是查看它的體系。過去，很多開發者已遷到MVC體系來開發Web應用程序。他們發現MVC可幫助它們更清晰地構造它們應用程序。(我們在下一章更祥細地討論MVC。)Java框架如Tapestry和Structs就是基於MVC的。Rails也是個MVC框架。當你在Rails內開發時，你的每個代碼，應用程序的每個部分都遵循標准的方式。也就是說，你在一個被事先准備好的框架內開始的。
回答這個問題的另一個途徑是看程序語言。Rails應用程序是由模塊化的，面向對象的腳本語言Ruby寫成的。Ruby相當簡練—你可自動地，清晰地用Ruby代碼來表達你的思想。這讓程序更易寫並在日後也可以容易地閱讀。
Ruby也有與Lisp代碼類似的程序風格。它可容易地創建像表達式一樣的方法。有些人使用元程序，但我們只關心對我們有用的部分。它使我們的程序簡短並更易於閱讀。它也允許我們完成在外部配置文件內的代碼的任務。可更方便地看到運行的工作情況。下面代碼為個工程定義了模塊類。現在不要關心細節。相反，只要想下面代碼行表達的信息就可以了。
class Project < ActiveRecord::Base
belongs_to :portfolio
has_one :project_manager
has_many :milestones
has_and_belongs_to_many :categorIEs
validates_presence_of :name, :description
validates_acceptance_of:non_disclosure_agreement
validates_uniqueness_of :key
end
或者我們可以思考地觀察它。Rails的設計由一組關鍵的概念來驅動著：DRY與配置約定(Convention over configuration)。DRV—系統內每個部分應該只在一個地方被表達。Rails使用強大的Ruby開始自己的生命。你會發現在Rails應用程序中少有重復；你在一個地方說你需要什麼—這個地方通常由MVC體系來暗示。
配置約定也是至關重要的。它意味著Rails能判斷出你的應用程序交織在一起的每個部分的缺省值。下面是約定，並且你可以用比使用XML配置的，典型的Java Web應用程序更少的代碼來寫一個Rails應用程序。如果你想覆寫這些約定，Rails也可很容易地做到。
我們也要提一下Rails包括完整的支持Web服務的材料，接受郵件，AJax(高級交互式Web應用程序)，完整的單元測試框架(包括對mock對象的透明支持)，和對開發，測試，生產環境的隔離。
或者我們談論Rails具有的代碼產生器。它們產生Ruby代碼框架，然後由你填充應用程序的邏輯部分。
最後，Rails的區別是源於它的起源—Rails是被精選出來的商業應用程序。它傾向於創建一個框架的最好途徑是找到特定應用程序的中心主題，然後在平常的代碼基礎內使用它們。當你開發你的Rails應用程序時，你是在現有的一個很不錯的應用程序上開始的。
但是有關Rails的有些事情描述起來很困難。不會知道原因，只是感覺到這是對的。當然，你必須接受我們說話，直到你可以自己寫一些Rails應用程序之前(應該是下個45分種或更多…)。這就是本書能談的所有東西。
-----------------------------------------------------------------------------------
Dave喜歡Rails的十個主要原因
------------------------------------------------------------------------------------------
1. 可敏捷地進行Web開發。
2. 可以創建干淨，整潔的Web頁面。
3. 只關注於創建應用程序，而不是框架的什麼東西。
4. 方便地管理應用程序的增長。
5. 可更大限度地滿足客戶的要求。
6. 內建的測試容易使用。
7. 立即反應：在浏覽器上可編輯代碼，及時刷新所有的更改。
8. 元程序(Metaprogramming)意味著我可以在真正的高級別上編程。
9. 代碼產生器可讓我們事半功倍。
10. 不需要XML!
-------------------------------------------------------------------------------
1.1 Rails 是敏捷的
本書的標題是Agile Web Development with Rails。那麼你可能會驚訝，我們沒有明確地將Rails代碼區分成X,Y,和Z部分。
這是因為兩者即簡單又微秒。Rails構造的一部分就是敏捷。
讓我們看看在Agile Manifesto網頁上，有一組四個參數的狀態值，就是下面敏捷開發的好處。
1、單獨地和交互式的處理過程及工具。
2、開發軟件有全面的，廣泛的文檔。
3、合約協議上的消費者合作。
4、Responding to change over following a plan
Rails的所有部分都是單獨的和可交互的。沒有笨重的工具集，沒有復雜的配置，也沒有難懂的程序。只有少數開發者，它們喜愛的編輯器，和一組Ruby代碼。這會產生這樣的透明度，開發者做的事情會立即被反射，並使用戶看到所做的事情。這是根本的交互式過程。
Rails的文檔無可指責。Rails使它可輕易地為你代碼創建Html文檔。但是Rails開發處理並不受文檔驅動。在Rails的工程中，你幾乎找不到500頁以上說明書。相反，你會發現一組用戶和開發者會共同地探究它們的需要，以及對這個需要的可能的處理方式。你也會發現開發者和用戶會變得對解決它們曾試著解決的問題更有經驗。你可以在開發周期內找到早期的軟件框架。這個軟件可能粗糙但實用，它讓用戶一接觸它就知道你拿來的是什麼。
Rails以這種方式鼓勵消費者協作。當消費者看到Rails工程如何快速地響應修改時，他們開始相信我們可以完成他們想要的東西，而不只是它們要求的東西。Confrontations are replaced by “What if?” sessions.
That’s all tIEd back to the idea of being able to respond to change. The strong, almost obsessive, way that Rails honors the DRY principle means that changes to Rails applications impact a lot less code than the same changes would in other frameworks. And since Rails applications are written in Ruby, where concepts can be expressed accurately and concisely, changes tend to be localized and easy to write. The deep emphasis on both unit and functional testing, along with support for test fixtures and mock objects, gives developers the safety net they need when making those changes. With a good set of tests in place, changes are less nerve-wracking.
Rather than constantly trying to tIE Rails processes to the agile principles, we’ve decided to let the framework speak for itself. 就像在此書讀到的那樣，在你腦中想像以這種方式開發你自己的Web應用程序：與你的客戶工作在一起，並共同決定應該優先解決的問題。然後，你回過頭來看參考資料，看Rails的基礎結構如何可使你快速地解決你客戶的問題。
One last point about agility and Rails: although it’s probably unprofessional to mention this, think how much fun the coding will be.
1.2 尋找你自己的學習方式
本書比我們想像的要厚一些。回過頭看看，它比我們曾寫的兩本書要清晰得多：一個教程和一個Rails的細節指南。
本書的前兩部分是對Rails背後概念的一些介紹，並還有個例子—我們構建了一個簡單的在線商店。如果你想更多地感覺Rails程序，可從個地方開始。事實上，大多數人更喜歡依照書上來構建應用程序。如果你不想輸入所有東西，你可以下載源碼。
本書173頁開始的第三部分，是Rails的所有工具和函數的細節。在哪裡你可以找到Rails各種組成的用法以及如何有效地，安全地配置你的Rails應用程序。
依據這種方式，你會看到我們采用的各種約定。
活動代碼：
我們提供大多數完整的代碼片斷，你可下載並運行的例子。如果列出代碼可下載，我們會在頁邊緣標記它。
class SayController < ApplicationController
end
Turn to the cross-reference starting on page 512, look up the corresponding number, and you’ll find the name of the file containing that piece of code. If you’re reading the PDF version of this book, and if your PDF vIEwer supports hyperlinks, you can click on the marker in the margin and the code should appear in a browser window. Some browsers (such as Safari) will mistakenly try to interpret some of the templates as Html. If this happens, vIEw the source of the page to see the real source code.
Ruby 提示：
雖然你需要知道用於寫Rails應用程序的Ruby，我們認識到，讀這本書的很多將同時即學Ruby也學Rails。467頁的附錄A是對Ruby語言的個簡短介紹。當我們第一次使用特定的Ruby結構時，我們將交叉引用附錄內的東西。例如，這一段包含了使用:name，一個Ruby符號的理由。按頁邊緣的指示你可以469頁找到有關符號說明。如果你不了解Ruby，或者如果你需要一個快速參考，你可能想在接觸更多的特性之前讀467頁附錄A。那兒有本書的大量代碼…
David 說...
現在和以後你會經常遇到David說…注釋。David HeinemeIEr Hansson會給你一些Rails的具體特征的解說—基本原理，技巧，推薦，等等。
Joe 問...
Joe, 是個虛構的開發者，有時候會提出文章內我們談到東西的一些問題，我們會試著回答這些問題。
本書不是Rails的參考手冊。我們在文章中通過例子顯示它的大多數模型和方法，但我們不能在上百頁中列出API。我們這麼做的理由是—你安裝Rails時，你就在哪兒得到了文檔，它生成文檔比本書的更詳細。如果你使用RubyGems(我們推薦你用它)來安裝Rails，簡單地啟動Gem文檔服務(使用命令gem_server)，然後你就可以通過在浏覽器中輸入http://localhost:8808來訪問Rails的API了。
Rails 的版本
本書的文檔是Rails1.0，它是在2005年中旬才可用的。盡管本書第一次開印是2005年六月。為了更及時，本書的API多用於Rails1.0。代碼在0.13和1.0上測試過。
1.3 感謝
This book turned out to be a massive undertaking. It would never have happened without an enormous amount of help from the Ruby and the Rails communitIEs. It’s hard to list everyone who contributed, so if you helped out but your name doesn’t appear here, please know that it’s a simple oversight.
This book had an incredible group of revIEwers—between them, they generated over 6 megabytes of comments. So, heartfelt thanks to
Alan Francis, Amy Hoy, Andreas Schwarz, Ben Galbraith, Bill Katz,
Carl
Dion Almaer, Duane Johnson, Erik Hatcher, Glenn Vanderburg,
Gunther Schmidl, Henri ter Steeg, James Duncan Davidson,
Johannes Brodwall, John Harechmak, John Johnson, Justin Forder,
Justin Gehtland, Kim ShrIEr, Krishna
Marcel Molina Jr., Michael Koziarski, Mike Clark, Miles K. Forrest,
Raymond Brigleb, Robert Rasmussen, Ryan Lowe, Sam Stephenson,
Scott Barron, Stefan Arentz, Steven Baker, Stian Gryt?yr,
Tait Stevens, Thomas Fuchs, Tom Moertel, and Will Schenk.
Rails was evolving as the book was coming together. As a result, the good folks in the Rails core team spent many hours answering Dave’s questions and generally sympathizing. (They also spent many hours tormenting me by changing stuff I’d just documented, but we won’t go into that here.) A big thank you to
Jamis Buck (minam), Jeremy Kemper (bitsweat),
Marcel Molina Jr, (noradio), Nicholas Seckar (Ulysses),
Sam Stephenson (sam), Scott Barron (htonl),
Thomas Fuchs (madrobby), and Tobias Lütke (xal).
Nathan Colgate Clark responded to a plea on the Rails mailing list and produced the wonderful image we use for the David Says... boxes.
Justin Forder did a great job of fixing up Dave’s anemic style sheets for the Depot application.
Thousands of people participated in the beta program for this book. Thank you all for taking the chance. Hundreds of these people took time to enter comments and errata on what they read. This book is better for it.
Last, but by no means least, we’d like to thank the folks who contributed the specialized chapters to the book: Leon Breedt, Mike Clark, Thomas Fuchs, and Andreas Schwarz.
From Dave Thomas
My family hasn’t seen me for the last eight months. For their patience, support, and love, I’m forever grateful. Thank you JulIEt, Zachary, and Henry.