【正文】 class User ActiveRecord::Base validates_presence_of :name validates_uniqueness_of :name attr_accessor :password_confirmation validates_confirmation_of :password validate :password_non_blank def (name, password) user = (name) if user expected_password = encrypted_password(password, ) 。在回頭關(guān)注控制器之前，再來看看完整的模型類代碼吧depot_p/app/models/require 39。在第306頁我們還會深入討論這類動態(tài)查找方法。depot_p/app/models/def (name, password) user = (name) if user expected_password = encrypted_password(password, ) if != expected_password user = nil end end userend這段代碼還使用了一個ActiveRecord小花招：方法的第一行調(diào)用了find_by_name方法，但你哪兒都找不到這么一個代碼。由于用戶輸入的密碼是明文，所以我們必須根據(jù)用戶名取出數(shù)據(jù)庫中的記錄，然后根據(jù)記錄中的salt值再對密碼做一次散列處理；如果密碼散列值與數(shù)據(jù)庫中保存的值匹配，則返回User對象。我們不打算使用標準的訪問方法，而是自己動手來實現(xiàn)訪問方法，在寫方法中生成一個新的salt值，然后用它來生成密碼散列值。如果不是需要生成散列碼，那么只要使用Ruby提供的attr_accessor聲明就行了。我們還需要寫一點代碼，確保每當明文密碼被放進User對象時，都會自動生成加密后的散列碼(后者將被存入數(shù)據(jù)庫)。如果使用在內(nèi)部使用xxx，而在外部使用xxx，那么很容易造成類型不匹配。salt/salt=是隱含屬性的“官方”接口，所以最好使用它們，而不是實例變量。depot_p/app/models/def create_new_salt = + end代碼里出現(xiàn)了一點新鮮東西：=...，以強制調(diào)用salt=方法——準確地說是“調(diào)用當前對象的salt=方法”。最后，把這個salt值放進模型對象的salt屬性中。(此外還必須引用digest/sha1庫，參見第151頁的代碼列表。這里的關(guān)鍵在于生成一個唯一的salt值，將其與密碼明文組合成為一個字符串，然后對這個字符串進行SHA1加密，得到一個40字符的字符串(其中的內(nèi)容是一個十六進制數(shù))。為了充分理解其中的奧妙，我們必須首先明白如何保存密碼。為什么？因為這個屬性并不真的存在——至少不存在于數(shù)據(jù)庫里。馬上我們就會看到這是如何發(fā)生的，現(xiàn)在只須知道：表單里有兩個密碼輸入框，其中一個是真正的密碼，另一個則用來確認密碼輸入正確。你肯定用過這樣的表單：你要首先輸入一遍密碼，然后在另一個輸入框中再輸入一遍密碼，以確保你所輸入的正是你想輸入的。我們首先檢查用戶名不能為空，并且要求用戶名是全局唯一的(也就是說，不允許數(shù)據(jù)庫中有兩個用戶起同一個用戶名)。我們還是一步步來吧，首先看看數(shù)據(jù)校驗的部分。depotrake db:migrate下面該輪到User模型類粉墨登場了。完成后我們來看看生成的遷移任務(wù)。 如果讀者想知道實現(xiàn)這一策略的其他做法，請參閱Chad Fowler 的著作Rails Recipes [Fow06]中的“身份認證”（Authentication)與“基于角色的授權(quán)”（RoleBased Authentication)兩個章節(jié)。當用戶再次登錄時，我們會對他輸入的密碼做同樣的加密處理，并將加密的結(jié)果與數(shù)據(jù)庫中保存的散列碼進行比較。 迭代F1：添加用戶Iteration F1:Adding Users 我們先來創(chuàng)建一張簡單的數(shù)據(jù)庫表，用于保存用戶名和經(jīng)過加密的密碼，以便管理之用。與客戶交流之后，我們認為并不需要給應(yīng)用程序加上一個特別復(fù)雜的安全系統(tǒng)，只需要根據(jù)用戶名和密碼識別用戶即可。不過，她還希望做一點修改：目前，任何人都可以訪問后臺管理功能，她希望再加上一個基本的用戶管理系統(tǒng)，當進入站點管理功能時要求用戶先登錄。)l 各種支付類型目前以常量的形式保存在Order類中，你能把它們移到數(shù)據(jù)庫中嗎？遷移之后能否繼續(xù)保持數(shù)據(jù)校驗工作如常？(更多提示請看。l 跟蹤購買流程，查看 save_order、add_line_items_from_cart和from_cart_item等方法。l 我們添加了數(shù)據(jù)校驗，并利用輔助方法將錯誤信息回顯給用戶。)我們做了什么What We Just Did時間不長，我們已經(jīng)干了不少事：l 我們新建了orders和line_items兩張表(以及對應(yīng)的模型類)，并將它們連接起來。顯然我們還必須提供某種發(fā)貨功能，不過這可以等到下一個迭代。 , :object = cartpage[:cart].visual_effect :blind_down if == 1page[:current_item].visual_effect :highlight, :startcolor = 88ff88 , :endcolor = 114411客戶感到很滿意。 ).each { |div| }page[:cart].replace_html :partial = 39。depot_p/app/views/store/→ (39。不過，它允許我們遍歷頁面上所有與指定的CSS selector模式匹配的元素，所以我們不妨遍歷所有id為notice的div標記。最終的解決方案有些類似于hack：只有當這個div存在時。當我們首次進入在線商店時，flash中什么都沒有，所以id叫notice的這個div也不會顯示出來：由于沒有這么一個div，RJS模板生成的JavaScript在嘗試隱藏這個div時就會出錯，剩下的腳本就不會運行了。還好，彌補的辦法很簡單：只要在選購物品之后把包含flash信息的div隱藏起來即可。 id = 1 product_id = 3 order_id = 1 quantity = 1 total_price = created_at = 20080609 13:40:40 updated_at = 20080609 13:40:40sqlite .quit 第一次成功的付款最后一點Ajax修改One Last Ajax Change在接受訂單之后，我們將用戶重定向回到首頁，并顯示一條flash信息：“Thank you for your order．”如果用戶繼續(xù)購物，并且又允許JavaScript在瀏覽器中運行，那么購物車會在頁面的邊欄里顯示，往其中放入貨品也不會重繪主頁面——也就是說，這條flash信息會一直顯示在頁面上。depot sqlite3 line db/SQLite version Enter .help for instructionssqlite select * from orders。 line 和ATTACH DATABASE db/ AS development。)!每個字段都得到了驗證如果我們填入一些數(shù)據(jù)()，再點擊Place Order按鈕，就會回到貨品列表頁面()。(如果你跟著我們一路走到這兒，又看到了“No action responded to save_order”這樣的消息，這可能是因為把save_order()方法寫在private聲明的下面了。進入付賬頁面，不填寫任何字段，直接點擊Place Order按鈕。Order類中的這個方法又會用到LineItem模型類中一個簡單的輔助方法，該方法會根據(jù)購物車中的物品新建一個訂單項。Rails已經(jīng)在has_many()和belongs_to()聲明中幫我們做好了這些工作。在save_order()方法中，我們假設(shè)Order對象已經(jīng)提供了add_line_items_from_cart()方法，所以現(xiàn)在就需要實現(xiàn)這個方法。首先，將購物車從session中刪掉，準各接受顧客的下一次購買；然后，用redirect_to_index()方法重新顯示貨品列表頁面，并在上面顯示一條提示信息。在此過程中，Order對象會執(zhí)行數(shù)據(jù)校驗(不過我們還要等會再加上數(shù)據(jù)校驗)。隨后的一行將購物車中的物品放入訂單——稍后我們會實現(xiàn)這個方法。在第3行上，我們新建了一個Order對象，并用表單數(shù)據(jù)對其進行初始化。所以，模型對象實際扮演著兩個角色：不僅負責數(shù)據(jù)庫的讀出/寫入，而且也可以是普通的、攜帶業(yè)務(wù)數(shù)據(jù)的對象。save_order這個action也會創(chuàng)建一個Order對象，并用來自表單字段的值去填充它。他想知道，為什么這不會導(dǎo)致在數(shù)據(jù)庫中保存重復(fù)的訂單數(shù)據(jù)?答案很簡單：checkout這個action只是在內(nèi)存中創(chuàng)建Order對象，然后把這個對象交給視圖模板來處理。4. 訂單成功保存之后，重新顯示貨品列表頁面，其中包含一條“已經(jīng)成功下單”的提示信息。搜集訂單詳細信息Capturing the Order Details現(xiàn)在來實現(xiàn)store控制器中的save_order()方法吧，這個方法需要：1. 搜集訂單中的數(shù)據(jù)，填入一個新的Order模型對象。depot_p/app/models/class Order ActiveRecord::Base validates_presence_of :name, :address, :, :pay_type validates_inclusion_of :pay_type, :in = {|disp, value| value} ...可以看到，我們在頁面頂端已經(jīng)調(diào)用了error_messages_for輔助方法。 有些讀者可能會覺得奇怪：為什么我們要費勁驗證付款方式?下拉列表中包含的不都是合法的值么?之所以這樣做是因為應(yīng)用程序不應(yīng)該假設(shè)數(shù)據(jù)一定來自自己創(chuàng)建的表單，沒有任何辦法可以阻止惡意用戶繞過我們的表單，直接把表單數(shù)據(jù)提交給應(yīng)用程序。此外，我們還要驗證用戶選擇的付款方式是否為合法的幾個選項之一。看起來不錯!當然了，如果點擊Place Order按鈕，映入眼簾的將是下列錯誤消息：Unknown actionNo action responded to save_order不過，在動手編寫下一個action之前，我們還是先把checkout這個action完成，給它加上數(shù)據(jù)校驗。}這個表單就基本到位了。}.depotform .submit { marginleft: 4em。 display: block。 paddingtop: 。 float: left。 padding: 1em。 background: 141 。再加上一點CSS魔法：Download depot_p/public/stylesheets//* Styles for order form */.depotform fieldset { background: efe。depot_p/app/models/class Order ActiveRecord::Base PAYMENT_TYPES = [ Displayed stored in db [ Check , check ], [ Credit card , cc ], [ Purchase order , po ] ]在這個模板中，我們把“付款方式”的數(shù)組傳給select輔助方法。我們首先假設(shè)Order模型類提供了一組可選的付款方式——在模型類中這應(yīng)該是一個數(shù)組，其中的每個元素又是一個數(shù)組：第一個元素是一個字符串，代表將在下拉列表框中顯示的文本；第二個元素是將被提交并最終存入數(shù)據(jù)庫的值 如果別的非Rails應(yīng)用也會更新Orders表，可能就需要把“支付方式”存入一張單獨的查找表，并在“訂單”中用外鍵關(guān)聯(lián)之。order39。在下列代碼中，我們用到text_field和text_area輔助方法來搜集顧客的姓名、電子信箱和居住地址。這個模板將被store控制器的checkout方法調(diào)用，位于app/views/store目錄下。不過你只需要記住，Rails需要知道每個字段的名稱和值，這樣才能將其與模型對象關(guān)聯(lián)；而form_for和各種字段層面的輔助方法(例如text_field)正是用于提供這些信息的。由于這個文本字段是在form_for的上下文環(huán)境中構(gòu)造出來的，因此它就自動地與order對象中的數(shù)據(jù)建立起關(guān)聯(lián)了。在代碼塊內(nèi)部，你可以放入普通的模板內(nèi)容(例如p標記)，同時也可以使用代碼塊的參數(shù)(也就是這里的form變量)來引用表單上下文環(huán)境。在這里，我們會生成一個HTTP POST請求，并把請求發(fā)送給控制器中的save_order方法。輔助方法會根據(jù)這一信息給字