實驗實驗再實驗

我現在發現我有一個習慣，不是故意這樣做，只是很自然就這樣做，
所以才會是「發現」而不是「發明」之類的...

就是每次寫新東西時，總是會嘗試一些之前沒用過或沒做過的事。
像是這次就是我第一次正式使用 map.resources, 之前只有試過味道而已。
用到現在我發覺，這東西確實很不錯，雖然偶爾會造成一點小麻煩。

例如以往，也許啦，我不是很清楚是否真的是這樣。就是把 GET 和 POST 混著用。
像是認定 /search?id=123&page=2 跟 /search with POST id=123 page=2 相等。
使用 map.resource 之後，這樣就完全是兩回事了 =_=b

這是在另外一個 project 裡面碰到的問題。本來預期那邊要 GET 過來，
結果他卻是 POST 過來 @_@ 然後就產生神秘的錯誤訊息。因為根本就沒有預期
會有這個動作。

GET => show action
POST => create action

錯誤訊息是什麼我有點忘了，反正就是追到一堆 library 裡面，看到都昏了。
最後才忽然發覺對方根本是 POST 過來的... 所以我完全看錯邊了。

去除掉這點麻煩的話，以獨立 project 來看，map.resource 我覺得還是好的。
原本自己寫 routes 的話，實在太麻煩了。不寫都用預設 routes 的話，
一來有時候 url 會變得很複雜，二來會有種 url 跟 action 綁死的感覺。
久而久之，action 與 url 就會變得有一點點混亂，失去系統。

map.resource 可以強迫 action 與 url 仍然按照某個規則去運作。

不過我還是不知道這跟 active resource 有什麼關係耶？
還是 active resource 是拿來讓 website 與 website 溝通的東西？
這樣的話我短時間內大概也沒辦法測試這個功能，因為這通常會需要很多
customize 的東西，這樣自己重新發明一套說不定還比較快。

就像我後來加在 ludy 裡面的 has many thumbnails...
我拿他再放到其他 project 中，結果發現他可 customize 的地方太多，
小專案裡用他根本就是畫蛇添足，增加使用麻煩 @_@
早知道就直接用 attachment_fu 了...
has many thumbnails 從 http 上 fetch image 根本就太多餘了啊 囧
雖然說也不是一定要用，只是會增加使用上的複雜度，因為要避開那些東西...

總之，map.resource 搭配 named routes, controller 裡面可以變得
更簡潔乾淨了。例如這個：

  def create
    signup = Signup.new params[:user], params[:avatar]

    if signup.save
      flash[:info] = Lang.tr[:signup_success]
      redirect_to theme_url(signup.user.theme_id)

    else
      flash[:info] = signup.errors.map{ |error|
        [Lang.tr[error.first], error.last].join
      }.join("<br />\n")
      flash[:user] = signup.user.attributes
      redirect_to signup_url
    end
  end

signup 是假的 model, 拿來操作 user 和 avatar 的 model.
對他呼叫 save 會先儲存 user, 然後儲存 avatar.
後者儲存失敗的話，砍掉剛剛存好的 user, 因為用不到了。
至於要先存 user 的原因，是 avatar 裡面需要 user_id.
這個 id 要事後再補的話非常麻煩，因為他也跟路徑有關。
這次的 project 只是小東西，我想先這樣應該夠了。

signup.errors 則是 merge user 和 avatar 的 errors,
不過改成 hash 的格式，不然不好操作資料。
我原本差點寫成：

if user.save
  if avatar.save
    ...
  else
    user.destroy
    ...
  end
else
  ...
end

好險即時煞車了，不然就要迷路在 if 中囉。
還有這次大量地使用了 attr_accessor 當作假的 table column,
很多 validation 是針對這些假的值去操作的，最後再存到 column 中。

總之，實驗最後覺得不好用，不妥當的方式，最後就不會再用。
覺得不錯，或是可以再精進的方式，就會拿到下一個 project 裡面用。
雖然也要小心這件事：

37. 04.29 寫程式的思想與習慣

這麼做的原因，與其說是求進步，其實我覺得不如說是我沒辦法一直做相同的事吧...
剛開始做時，還真的是一看到報名表格就倒胃 orz
說到這，另一個我現在覺得是最佳解的東西，就是把 user 填寫失敗的資料，
存到 flash 裡面！我不知道一般是怎麼做的，不過我試了好多方法，
發現這樣做好像是最簡單的。當然，只存 hash, 不是要把整個 object 存進去。

還有 login 與 redirect 的關係，我也發覺是存到 flash 最好。
用 refer, get, back 什麼的，常常都會有小問題... redmine 好像是根本沒做。

*

機器人的工作一點都不好玩啊，寫出個機器人還差不多。