[RoR]Agile Web Development with Rails 3rd depot疑難雜癥
depot項(xiàng)目任務(wù)E check out一章很長(zhǎng),最后playtime中有兩個(gè)題。
(1)在checkout.html.erb頁面不應(yīng)該還有 [checkout] 按鈕
(2)把payment_type字段分離成一個(gè)表。
第一個(gè)相對(duì)簡(jiǎn)單一點(diǎn),最省事兒的辦法是,設(shè)置一個(gè)標(biāo)志字段,然后在layout/store.html.erb中判斷一下。
第二個(gè)就比較復(fù)雜,
(1) generate migration, 重建數(shù)據(jù)表,修改數(shù)據(jù)表
(2) generate model PaymentType ,修改Order,添加一對(duì)一的映射關(guān)系。
(3) 修改store_controller,在checkout中加入@payment_types的取得方法,將對(duì)應(yīng)的view中select部分的靜態(tài)數(shù)組改成這個(gè)@payment_types。
(4)因?yàn)檫@個(gè)payment_type比較特殊,在order里頭并不保存type的id,而是保存name(就是縮寫),所以編碼的時(shí)候需要注意字段的對(duì)應(yīng)關(guān)系。不過注意一下的話,問題不大。
結(jié)果,第二個(gè)跑出來有問題,在checkout頁面輸入訂單信息并選擇支付方式,全通過,則沒問題,數(shù)據(jù)庫里也都正確。但是一旦有任何輸入為空或不合預(yù)期,則報(bào)錯(cuò):



傻了……
因?yàn)閷?duì)payment_type的獲取方法也不是很肯定,所以一開始懷疑問題出在表結(jié)構(gòu)映射關(guān)系上,反復(fù)檢驗(yàn)后沒發(fā)現(xiàn)問題。
然后懷疑頁面?zhèn)鲄栴},參數(shù)傳不到這種rp問題……加之之前有幾處rails版本區(qū)別,覺得對(duì)rails的一些約定還是不太了解。
然后試著修改頁面,將checkout view的select那一段


改成







頁面倒是不會(huì)出錯(cuò)了,不過心里總留了一個(gè)疙瘩,而且事實(shí)上每次出錯(cuò)后都會(huì)從PaymentTypes::STATIC_TPYES中取支付類型,也不符合playtime的初衷。這說明某些情況下@pay_types的確是nil了,但是反過來,為啥呢?
忽然一下想起,要是@pay_types為空的話,第一個(gè)去按鈕的任務(wù)也應(yīng)該不成功,檢查了一下,的確如此。
但checkout頁面確確實(shí)實(shí)的顯示出來了,說明checkout view被調(diào)用了,然而參數(shù)是空的。這是我想到看看checkout之后有些什么操作——
checkout提交到save_order,成功則重定向到Index,而失敗則render到checkout頁面。
注意到這里的render。render和redirect_to都會(huì)根據(jù)checkout.html.erb的內(nèi)容進(jìn)行布局,而二者的區(qū)別在于,redirect_to會(huì)重定向到action對(duì)應(yīng)的函數(shù)中重新執(zhí)行,而render則不會(huì)。具體在這里區(qū)別就是render不會(huì)執(zhí)行checkout里關(guān)于獲取
@pay_type的那一段邏輯,從而導(dǎo)致@pay_type為空,自然呈現(xiàn)出來的html中@pay_type就會(huì)出錯(cuò)。
在save_order里面加上生成@pay_types的初始化方法,刷新之后問題解決。
問題應(yīng)該是找到了,但不知道是不是最好的解決辦法。因?yàn)閟ave_order和checkout中存在代碼重復(fù),可以考慮重構(gòu)一下。
posted on 2008-11-03 17:04 bacon 閱讀(1410) 評(píng)論(0) 編輯 收藏