Deviseのルーティングが微妙なのでgemを作ってみた - ぶろぐ。@はてな
Devise便利ですよね。簡単にリッチな認証機能がつくれます。 # config/routes.rb devise_for :users new_user_session GET /users/sign_in(.:format) devise/sessions#new user_session POST /users/sign_in(.:format) devise/sessions#create destroy_user_session DELETE /users/sign_out(.:format) devise/sessions#destroy user_password POST /users/password(.:format) devise/passwords#create new_user_password GET /users/password/new(.:format)
routes.rb が必要なくなる Rails gem - ぶろぐ。@はてな
Railsを使っている人からよく聞く話が、 config/routes.rb 書くのがめんどくさい・よくわからない ということです。とくにSinatraのスタイルと比べると、Railsのルーティング定義は面倒なものに思えます。 基本的にはresources推奨なので、resourcesを書くだけではあるのですが、考えてみればRailsはConvention over Configuration (CoC) を標榜しているのに、推奨のルーティング設定も書かなきゃいけないというのはちょっと変な気もします。*1 だったら、コントローラ置いとけばresourcesとみなして勝手にルーティングしてくれるようにすればいいのでは、と思ってConventional Routesというgemを作ってみました。 Conventional Routes https://github.com/tkawa/conv
RailsでのURL設計を考えてみる(5) Railsのリソースパターン - ぶろぐ。@はてな
URL設計の前段階として、とても大切なのがリソース設計です。そのWebアプリ・Webサービスで何を提供するのかが決まる部分だからです。しかし、なかなかリソースという概念が定着していないようなので、Railsで採用されているパターン*1を例に挙げて紹介してみたいと思います。 今までのシリーズ記事と重なるところもありますが、まとめということで…。 リソースとは 簡単に言うと、「URLで示されるもの」です。URLというのが“Uniform Resource Locator”の略ですからね。 http://d.hatena.ne.jp/tkawa/20110819/p1 http://d.hatena.ne.jp/tkawa/20110819 最初のものは、前回書いたブログ記事『RailsでのURL設計を考えてみる(4) スラッシュと「持っている」関係』というリソースです。 その次は、『tkawa
RailsでのfavoriteのURL設計 - ぶろぐ。@はてな
http://d.hatena.ne.jp/r7kamura/20110505/1304577667がすごいなと思って、routes.rbの書き方の例についてコメントしたのですが、自分で書いておいて後で「unfavorite」はちょっとまずいかなと思ったので、favorite（いわゆるお気に入り、スター）はどういうふうに設計すればいいのか考えてみました。 構造はよくある感じの、 tweet has_many favorites user has_many favorites 任意のツイートに任意のユーザーがお気に入りをつけられるというもの。別にツイートじゃなくても何でもOKです。 ブログのコメントにはこのように書きました。 (1) resources :tweets do member do post 'favorite' post 'unfavorite' end end ルーティングは
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
