タグ

railsネスト論に関するtakeshiketaのブックマーク (16)

  • Rails勉強会@東京第38回 - railsでhogehogeを作ってみる。

    に行ってみる。 が、まあ、今回もはてブのブックマークはしない。 だって、はてブ使ってないんだもんwww で、今回、セレクトしたセッションは、「Rspec / Cucumberによるテスト by 諸橋氏」と「Rails 2.3のリリースノートを読む by 松田氏」。 で、感想。 spec / Cucumberによるテスト マイッタ、最近、テストコード書いてません... script/consoleで大概済ませてる... 客先にテスト結果を渡すような仕事したことないんで、あまり必要性がwww チーム組んで何か作る時には、嫌でも書かないといけないんでしょうが。 ちょっと、これから作り始めるプロジェクトが在るんで、それを作る時に使ってみる、ように、したい、なぁ... という訳で、Cukeのネタは、それまで待って下さい;-p >> 諸橋さん Rails 2.3のリリースノートを読む まあ、アテクシも

    Rails勉強会@東京第38回 - railsでhogehogeを作ってみる。
  • ネストしたリソースの扱い問題、再燃か?www - railsでhogehogeを作ってみる。

    忘れた頃にやってきたwww 「Foodyn CMS開発日誌 ネストしたリソースの悩ましさ」。 ご意見、有り難う御座居ます。 こんな無職趣味グラマーの為に、一言頂けますこと、厚く御礼申し上げます。 非常に興味深く、拝見しました。 で。 って、なんか、誉め殺しのようなんですがwww ちょっと、無職の趣味グラマーが、偉そうに、能書き垂れますよ;-p でも、寝つきが悪くって、煙草吸おうと思ってケータイ見たら、トラバの通知が来てたから書いてるんで、要点しか書きませんよ;-p あんまりオイラが偉そうに能書き垂れても、説得力無いしねwww みなさん(全部が当てはまるとは云いませんし、思っていませんよ)、根的なことが... モデルとコントローラを混同させて考えている コントローラはリソースでは無い(というか、少なくともRailsではなり得ない) コントローラのネストは在り得ない(集約も内包もしない。Ra

    ネストしたリソースの扱い問題、再燃か?www - railsでhogehogeを作ってみる。
  • Foodyn CMS開発日誌 - ネストしたリソースの悩ましさ

  • Merb/Railsリソース問題のまとめ - Hello, world! - s21g

    最近書いたNested Resourceに関する話題をまとめておきます。 Answer to resource, the CRUD and everything ネストしたリソースの問題の解決策を考えてみた 入れ子のリソースに関する問題について merb-genのresourceは何をしてくれるのか 外部サイトからのリンクバックもまとめ記事作成のための検索対象に含めたら、もっと便利になるかな。

  • なんか、言葉遊びの体になってきたんでツマンネぇ。 - railsでhogehogeを作ってみる。

    Answer to resource, the CRUD and everything。 まずはネストという言葉に関する定義の問題ですが、 諸橋さんが書いているように 、PostsコントローラはComments コントローラを集約(aggregates)しますが、 内包(compose)する訳ではありません。 ....僕は(多分、諸橋さんも)、コントローラがコントローラを云々とは、云ってませんよ。 Commentリソース(== Commentモデル)を、どこでハンドリングするか、ですね。 その上で、僕は、「PostのCommentなんだったら、Postの一部として扱えばいい」といっていて、諸橋さんは「Commentは結局の所CommentでしかないんだからCommentとして扱えばいい」とおっしゃっているんだと解釈していますが。 で。 ちょっと喧嘩腰に口汚い云い方をさせて頂きますが。 集約

    なんか、言葉遊びの体になってきたんでツマンネぇ。 - railsでhogehogeを作ってみる。
    takeshiketa
    takeshiketa 2009/01/21
    なにもけんか腰にならんでも。面白いのに
  • Answer to resource, the CRUD and everything - Hello, world! - s21g

    まずはネストという言葉に関する定義の問題ですが、 諸橋さんが書いているように 、PostsコントローラはComments コントローラを集約(aggregates)しますが、 内包(compose)する訳ではありません。 たとえば、管理画面に対応するAdminコントローラから、 Commentの削除や修正を行う場合に、AdminコントローラからCommentsコントローラを集約する事を考えると、その必要性が分かりやすいと思います。 PostsコントローラにCommentsを制御するコードを書いてしまう(内包してしまう)と、 Adminコントローラで同じ事をする必要が出来た場合に、 同じようなコードを書く必要が出てきます。 Don't Repeat Yourself! 結果として、メンテナンス性の悪いコードが出来上がります。 この事が、Postsコントローラの中でCommentsリソースを制

  • 他の方の考え方を知るのって、楽しいよね:-) - railsでhogehogeを作ってみる。

    お忙しい最中、いろいろとお手間をお取り頂きまして。 誠にありがとうございます。 => 問題点が分かってきた気がする えーっと。 前提として。 僕は、コントローラは、リソースをコントロールするもの"ではなく"、リクエストに対しての、アプリの振る舞いを規定するものだと思っています。 リクエストがあって、そのリクエストを解釈して、対応するリソース(モデル)を引くなり積むなりして、その戻り値をもって、レンダラを通してレスポンスを返すもの、ですね。 もちろん、その考え方が正しいのかどうかは知りませんよ?:-D という前提で。 なるほど。こういう話ですね。で、私のスタンスはリソースとして親子関係があるならそう扱うのがいいんじゃないか? というスタンスです。id:lov2muchさんとけっこう近い、ですかね? そこはバッチリ一致ですね:-) で、僕が、ホントに、Post(親リソース)とComment(子

    他の方の考え方を知るのって、楽しいよね:-) - railsでhogehogeを作ってみる。
  • Railsでページング位置を覚えておく方法 - yuumi3のお仕事日記

    RailsでScaffoldの作ったコントローラーに WillPaginate等で一覧のページングを追加したアプリを作る事がよくあると思いますが、ページングで2ページ目を表示し、そこで編集し戻ってくると一覧は1ページ目に戻ってしまいます。 編集しても2ページ目に戻ってこれるようにするのに、皆さんはどうしていますか? class TodosController < ApplicationController def index @todos = Todo.find(:all, :order => :due) end def show @todo = Todo.find(params[:id]) end def edit @todo = Todo.find(params[:id]) end def update @todo = Todo.find(params[:id]) if @todo.u

    Railsでページング位置を覚えておく方法 - yuumi3のお仕事日記
  • DHHはかく語りき。(かどうかは知らないがwww) - railsでhogehogeを作ってみる。

    いや、つうか、ね? すげえよ、Logitech diNovo Edge。 何がスゴイって、capsキー押すと、ビープ音なるんだぜ? 「A」押そうとして間違えてcaps押すたびに、怒られるんだぜ? 何このバカ仕様www まあ、そんなことは置いといて。 リンク貼ると、トラバが飛んでメールが飛んで、ウザいだろうな、ということで、敢えてリンクはしませんがwww オイラの オイラは、リソース名とコントローラ名には、直接的な相関性はないと認識しているクチなんですが...... hogehoges_controller.rbが在るからといって、hogehoge.rbモデルが存在しなければならない、訳ではないですよね? 逆もそうですし。 「それがRailsのセオリーだ」というのなら、それはそれで仕方ないのかな、とも思いますが、でも、それだと、実質上、モデルとコントローラが分離していない == MVCじゃな

    DHHはかく語りき。(かどうかは知らないがwww) - railsでhogehogeを作ってみる。
  • 問題点が分かってきた気がする - moroの日記

    うわっ この人も見ているわwww http://d.hatena.ne.jp/lov2much/20090120/1232443661 どうもです。先日はお疲れ様でした。 まとめ なんかわかりあえてきた気がする map.resorcesをネストさせて、それを使うのが好みです。 そうするとテンプレートの選択とかがむずい おまけ: 検索はindexアクションで map.resourcesの私なりの解釈は(レシピのはずなのに)Railsレシピブックにいろいろ書きましたので、ご覧いただければと思います。 題 「ネストする」と「内包する」は私のほうも使い方が曖昧でしたね。すみません。 「内包する」はあくまでCommentはPostの一部であり、Commentそれ自体では存在しえないというかシステムとして直接は扱わないというのを指す感じです。 対して「ネストする」は「集約する」と同じような意味で使っ

    問題点が分かってきた気がする - moroの日記
  • うわっ この人も見ているわwww - railsでhogehogeを作ってみる。

    という訳で、諸橋氏さんからも、レス頂いてますな。 「ネストしたリソースの扱いの話とか」。 う〜ん。 貴重なご意見ありがとうございます。 勉強になります。 が...う〜ん... という。あと読み返して思ったんですが、ネストしたリソースの扱いについての議論に対して、そのリソースはネストしていない、という主張が来てるのか。それはすれ違うなー、と思いました。 う〜ん、ネストはしていると思っていますよ。 でも、「ネストする」と「内包する」って、意味が違うんですか? いまのRailsのセオリーは、『ユーザにとって価値がある単位のエンティティの集まり』をリソースとして扱って、それをCRUDすることで大抵のことができるから、そうしようね、というものになってると思います。コントローラレイヤはCRUDを担うシンプルなものにしていこう、というのが(たぶん)基的な方向性になっています。 ああ、そうなんですね。

    うわっ この人も見ているわwww - railsでhogehogeを作ってみる。
    takeshiketa
    takeshiketa 2009/01/20
    現在持ってるRailsの機能面からの議論に傾いてる気がする
  • そりゃあ、ちょっと違うんじゃないんですかいのぉ? - railsでhogehogeを作ってみる。

    いやいや、面白いなぁ。 オイラの脳味噌が、もうちょっとレスポンスがよければ、あの場でセッション・トークに参加出来たのに、なぁwww で。 瀧内さん。それは違うんじゃないですか? => ネストしたリソースの問題の解決策を考えてみた いや、確かに、「おおっ、そういう手もありだな」、「面白いかも」とも思ったんですよ。 リクエストに対して、処理を変えるっていうのは。 でも、それって、コントローラ#アクションの役目ではなくて、ルータ(railsで云うところのconfig/routes.rb)の役目ではなくって?(お蝶夫人調で) リクエスト => config/routes.rb => リクエストに対応したアクション => hogehoges_controller.rb#action が、在るべき姿では? それに、HTTPメソッドによって処理を変えるのって、なんか、よくある「フォームの内容の有無によっ

    そりゃあ、ちょっと違うんじゃないんですかいのぉ? - railsでhogehogeを作ってみる。
  • ネストしたリソースの扱いの話とか - moroの日記

    Rails勉強会@東京の月刊Merbで瀧内さんがサンプルを示しながらMerbの使い方を説明してくれました。 で、そのときにブログのようなものを実例に使っていまして、そのCRUDの設計についてプチ議論になっています。 まとめ なんかコードを書いてみたりしたらえらい長くなったので、私の考えを簡単に要約すると とりあえずこの前提に興味があるならDHHのプレゼンを見るといいと思います map.resource使うといいよ ビューの事情なんだからAjaxとテンプレート差し替えで何とかするのがいいかと それを簡単にするプラギンが欲しい という。あと読み返して思ったんですが、ネストしたリソースの扱いについての議論に対して、そのリソースはネストしていない、という主張が来てるのか。それはすれ違うなー、と思いました。 ここから意見いろいろ データ構造としてはよくあるブログを想起していただければいいんですが、P

    ネストしたリソースの扱いの話とか - moroの日記
    takeshiketa
    takeshiketa 2009/01/20
    興味深い。参考になる。こういうアRailsプリ設計論みたいなのもっと聞きたい
  • ネストしたリソースの問題の解決策を考えてみた - Hello, world! - s21g

    ちょうどタイミング良く@maihaさんから、@yuguiさんが 近くに来てるという情報をもらったので、 @yamazさんも交えて、ネストしたリソースを扱うコントローラの問題の答えを得るべく、ミーティングをしました。 問題の定義: モデル層で Post has_many Comment な関係にある時に、 Commentのリストとコメント投稿フォームを含むPosts#show画面(典型的な例としてはブログの一記事表示画面)から、Commentを投稿した場合に、 Comments#createで受け取ると、Commentのsaveに失敗した時に、Post#showを表示したいが、redirect resource(@comment.post) すると、@comment.errorsの情報がロストしてしまう。 Posts#create_commentなどで受け取ると、Commentリソースの処理

  • 入れ子のリソースに関する問題について - Hello, world! - s21g

    蛇足感がありますが、ちょっと補足しておきます。 Rails勉強会@東京、面白かったんですが。 そもそも何が問題かというと、 Commentsコントローラが担当すべきCommentリソースの処理を、 Postsコントローラで書かなきゃいけないのが格好わるいのでなんとかしたい、という事なんです。 Child belongs_to Parent な関係にあるChildリソースを描画する時は、 多くの場合Parentの描画を伴う事になるので、 そもそもControllerの仕組みが入れ子関係を上手く扱えるようになっているとありがたいのだけど。 View上で階層関係になっているものを、フラットなControllerで処理するという事がそもそも無理があるのかもしれない。 Controller側も階層化させるか、さもなくばセッション中に言ったように、 子供のリソースはAjaxで処理するという形にするのが

    takeshiketa
    takeshiketa 2009/01/19
    そろそろRailsデザイン・ベストプラクティスみたいなものが欲しい。
  • Rails勉強会@東京、面白かったんですが。 - railsでhogehogeを作ってみる。

    敢えてはてぶに登録はしない;-p で。 Merbネタで、瀧内氏が、Merbでプロジェクトを作るネタをやって下さっていた訳ですわ。 で、まあ、よくある感じで、ブログを作る、みたいな。 まず、Postモデル作って、コントローラ作って、ビュー作って。 んじゃあ、コメント作れるようにしましょう、ってんで、Commentモデル作って、コントローラ作って、ビュー作って。 んで、Postモデルからhas_many :commentsして。 Postのshowアクションにcommentsコントローラに送信出来るフォームを作って。 で、Postオブジェクトを新規で作って、それに関連付けされたCommentオブジェクトを作って。 で、実際に、送信。 で、そこで諸橋氏と問答に入った訳ですよ。 「commentsコントローラのcreateアクションに行って、saveがfalseだったら、render(:actio

    Rails勉強会@東京、面白かったんですが。 - railsでhogehogeを作ってみる。
    takeshiketa
    takeshiketa 2009/01/19
    発端/前提が違う気がする
  • 1