あ、そうなんだ普通なんだ。

いやさ、

/
/hoge/tag
/hoge/category
/user
/user/{id}

みたいな感じで書きたいじゃん。
単純に見やすいし。

それにしてもEloquentってこれ、便利なんかな？
やっぱり覚えたほうがいいの？

「美しくシンプルなアクティブレコードによるデーター操作の実装です。」って言われても、
そのシンプルに書くためにモデル作って、書式覚えて、1度書いたSQL文を変換してってなると、
なんか余計な手間のほうが増えてる気がするんだが…。
っていうか、サブクエリの方法がわからん…。
そしてEloquentってそもそもなんて発音するんだよｗ

アクティブレコードやORMってのはオブジェクト（or モデル or エンティティ）が先に存在して
それを永続化する際に保存先のRDBとインピーダンスミスマッチを起こすからその面倒を引き受けてやるよって話であって
逆にRDBやSQLありきの単なるラッパと思ってるならそりゃあ存在意義もわからんだろ

ほとんど作らないだろうがオブジェクトをDBに永続化する必要のないアプリケーションだってあるわけよ

なんだー、Eloquentでサブクエリはネストするだけか。
何時間も使っちまった。

$results = Post::whereIn(
'id',
Postmeta::where('meta_value', $tag)->lists('post_id')
)->paginate(2);

絶対需要多いと思うだけど、なんで解説に書いといてくれないんだろ。

しかしインピーダンスミスマッチなんて言葉初めて聞いたわｗ
SQLでデータ取ると加工が面倒だけど、そのへんの面倒を見てくれてるってわけね。

オブジェクトを単に入れ物に出し入れするがごとく
DBへの透過的な永続性をORMに担ってもらうことで
プログラマはオブジェクト指向プログラミングに集中できる

俺も経験あるがORM使う以前ってRDBの奴隷として調教されすぎているんだよな
ORMなんてSQLも使えねえゆとり用じゃねーかｗｗｗと馬鹿にするやつもいる
もちろんライブラリが自動でやる分パフォーマンスの問題が出ることはあるから
SQLやRDBの知識が要らなくなるというわけではないんだがな


暇があったら他のORMも調べてみるといい
Symfony2のDoctrineの説明はわかりやすい
http://docs.symfony.gr.jp/symfony2/book/doctrine.html

5.0もう翻訳できとるやん。
神かな？

Laravelに限ったことではないのですが・・・
Webの一覧画面、登録画面、修正画面、削除画面の遷移方法について質問です。

各々の画面遷移をPOSTでやるのかGETでやるのか、常套的な方法がありましたら
教えてください。
またエラーメッセージの画面間の引き渡しはフラッシュデータを使うのが常套手段なの
でしょうか。

HTTPメソッドは冪等性と安全性によって使い分けるのが一般的
冪等というのは同じ操作を何回行っても結果が同じということ
安全というのはサーバ上のリソース（大抵DBと対応）の状態を変化させないこと

・冪等 かつ 安全　　　　　　　　　GET　HEAD
・冪等 かつ 安全でない　　　　　PUT　DELETE
・冪等でない かつ 安全でない　POST

・POST→リソース新規作成
・GET→リソース取得
・PUT→リソース更新
・DELETE→リソース削除
という風にCRUDと対応付ける実装が多くLaravelの標準も同じ
※PUTとDELETEはHTMLのformが対応していないので隠しパラメータで擬似的に表現される

Laravelが用意しているリソースコントローラーのアクションの命名規則とHTTPメソッドの使い分けが参考になるだろ
実際にリソースを新規作成したり更新するリクエストはPOSTや（擬似）PUTだが
それらのリクエストを発するための新規作成画面（createアクション）や編集画面（editアクション）を表示するのはGETだな
http://laravel4.kore1server.com/docs/controllers#resource-controllers

リダイレクト云々についてはGeneratorのControllerのScafolding見てみたら？
http://github.com/JeffreyWay/Laravel-4-Generators

postで画面描画しないよう徹したほうがよいよ

postメソッドは、エラー時もOK時もredirecrして必ずgetメソッドで画面描画

withInput()とwithError()が効率的に使えるし
ブラウザの戻るボタンで戻れるウィザードにもなるから

テンプレートにflashメッセージとflashエラーの描画入れとくと、いれいろ便利

>>207、206
すばらしい回答ありがとうございました。
両回答とも、知りたい事のドンピシャの回答で、よくわかり、大いに納得しました。


ご回答をふまえて追加で質問させてください。

修正画面を表示
　　　↓
OKボタンが押される
　　　↓
バリデーションエラーで修正画面を再表示


という画面遷移を考えたとき、修正画面に表示するレコードのID等を引き回す必要が出てくると思います。
このIDの引き回しは、<input type="hidden"> で引き回すのが普通なのでしょうか？
（つまり修正画面に、<input type="hidden"> を入れる）

それとももっとスマート？な方法があるのでしょうか？

レコードのIDの値はURLに含めるほうが楽じゃない？
リソースフルコントローラーの規則に合わせるなら

修正画面(edit)：　GET /resource_name/{id}/edit
更新（update）：　 PUT /resource_name/{id}

としておく　まあIDに限らずユニークなフィールドでレコードを特定できるならなんでもいいんだけど

修正画面のformからPUTしてupdateアクションでバリデーションが通らなかったら
withInput()とwithErrors()を利用してeditアクションにユーザの入力値やエラーを渡しつつリダイレクトする
editアクションではInput::old()が空じゃなければそちらの値を優先して表示

探してみたらベストプラクティスの考察記事もあったよ
http://qiita.com/asaokamei/items/e5070f9fad4c91e52bdc

>>204
ありがとう。まずはEloquent理解してからだわｗ

しかし今まで作ったやつEloquentに書き換えてるけど、
実際使ってみると確かに楽だわ。
クエリースコープ便利すぎワロリンコ

>>210

＞レコードのIDの値はURLに含めるほうが楽じゃない？

こうすると、修正画面に遷移する前の画面（つまり一覧表示画面）で、修正するレコードがどれかを
判別し、そのＩＤをURLに入れてsubmitする、という javascript が必要になります。
修正画面にはPOSTで遷移すればjavascriptを書く必要がないのでシンプルで良いと思った次第です。

しかし、紹介していただいたベストプラクティスを見ると、バリデーションエラーになって元画面を表示
するのに、
　　return Redirect::back();
という方法を採っています。
この方法、シンプルですね。
やはり修正画面の表示はGETに統一し、上で書いた javascript は必要、と考えたほうがよい気がしました。

すみません訂正です。

FORMをGETでsubmitしたことがないので間違ったことを書いたかも。
GETでも javascript は必要ないですね。

普通にaタグでリンク辿ればGETになるだろ何言ってんだ

Aタグ！？
そう言えばそうですね。
チェックボックスをチェックして修正ボタンをクリック、ばかり考えていましたので。

ただ、修正画面ではなく、複数選択して次の画面に遷移する画面もあると思います。
そんな時はやはりAタグではなくチェックボックスだと思います。
すると、FORMでGETメソッドですよね。

あ、GETではパラメタサイズが制限されるから、チェックボックスで複数選択のときはPOSTなのかな。

後付で条件変えられても……
最近のGETパラメータのサイズの制限はそんなに厳しくないと思うけど

同一IPによる連投禁止って、データベースにIPと作成日を保存しておいて、
バリデーションのカスタムフィルタ作ってValidator::makeするって感じしかないのかな？

そういった普通に使いそうな便利ツールまとめたライブラリとか無いのかな？

ごめん、普通にCookieでやればいいのか。
新しいこと頭に入れすぎて混乱しとるわｗ
失礼しやした

>>216
後付条件になってしまい、すみませんでした。

204の質問に対して205, 206の回答をいただき、
DBに保存しない処理は「GETで統一がいい」と納得しました。
しかし、画面によっては複数のチェックボックスにチェックして「修正する」ボタンを
押すような画面もあることに気づき、その結果、後付条件になってしまいました。

ご勘弁ください。

>>217
同一IPによる連投禁止は、プロキシを介してリクエストしてきたとき
実際に端末は違っていたとしても同一IPになってしまうよ。

>>220
ですよね。
っていうかCookieでも毎回消されたら意味ないけどｗ

まあ、ただの投票ボタン付けるだけだから
厳密に規制したいわけじゃないからいいんだけどね。

ふーい、やっとこコメントへの投票とCookieによる連投規制でけた。
カスタムバリデーションへ複数のパラメータを渡すにはカンマ区切りな。
いい子はテストにでるから忘れるなよ。

'meta_key' => 'custom_validation:parameter1,parameter2'

いちいちマニュアルになくて試しながらだからくっそ時間かかるわー

マニュアルになくて試しながら、だよな。

俺もメールで戸惑った。
簡単なメール送信でさえ、わからなくて悩んだよ。

今日はカスタムコマンドを使って
cornでキャッシュ作成と、データベースの更新とメンテまでできた。

カスタムコマンドは引数使わない場合はモードを
InputArgument::REQUIREDではなくてInputArgument::OPTIONALな。
これもテスト出るぞ。

日記乙

本屋に行ってきたんだが
Fuel > Cake >> zend みたいな感じで陳列されてた。
LaravelってCakeぐらいは越えられる？

Laravelが人気ありそうなので学習しはじめましたが、人気がある理由がわかりません。

FuelPHPやYiiのほうが、オンラインマニュアルの質が格段に高い。
ふつうのWebサービスを作るにはFuelPHPやYiiで十分だろうし、学習コストを考えると、
FuelPHPなどのほうがよさそうに思いました。
仕事で使うには、学習コストって重要ですよね。

世界的に見てFuelPHPよりLaravelがトレンドのようですが、Laraveが優っている
理由はなんなんでしょうか？
単に宣伝が上手かっただけとか？

Laravelを触ってみて FuelやYiiのがいいと思うのは 君の知性に問題があるとしか言いようがないよ

Laraveが優っている理由を具体的に教えてください。

１１月１１日午前８時頃、バージョン４のCSRFフィルターに関する脆弱性が公表されました。
フィルター中の比較演算子を!==に変更してください。
http://laravel4.kore1server.com/docs

確かにマニュアルは分かりにくい。
昔のマニュアルにあったのが、新しいマニュアルで削除されたりしてる謎。
変なとこだけ冗長だったり、肝心のところがなかったりする。

ただ、実際書いてみると「なるほどね」って機能が多いよ。

実用的なチュートリアルも無いし、日本ではまだまだこれからって感じだね。

とにかく手を動かして、ダメなときは海外のフォーラム覗いて、
既に公開されてるソースを眺める。
今のところこれしかない。

> 実用的なチュートリアル

絶対ここの常駐者だな...

http://www.rapidexp.com/wordpress/category/laravel/

てか、まだ現役だってことにビックしたw

>>232
誰それ？初めて見たが…。
一応迷惑かかるとあれだから否定しとくわ。

てかさ、サイドバーを付けたいんだけど、
これってメインのコンテンツ表示してるコントローラーでサイドバーについてもデータ渡すの？
せっかくbladeのViewでインクルードしてんのに、意味なくね？

sidebar.blade.php側でコントローラーのデータ読み込んだりできないのかしら？

>>233
blade側でやるのは、メニューデータのforeach展開だけ

メニューデータ取得は、全コントローラーで継承するベースコントローラーでしょ

>誰
うん、DOSやパソ通しらなきゃどうでもいい

>>234
なるほど、こういうときにベースコントローラー使うのか。
何のために継承してんだかわからずおまじないとして書いてたけど、そういうことね。
ありがとう。

ビューコンポーサー派はおらんのかえ

ビューコンポーサー試してみたけど、利点がわからんな…。
特定のビューが呼び出されると一緒にレンダリングされるってだけでしょ。

デフォルトでroutes.phpに書くって意味もわからんし、
逆にどこに書いても良いって言われても置く場所困るわ。
分けたところで作った人しか場所がわからず見通しが異常に悪くなるし…。

っていうか、デフォルトでroutes.phpに書くってマニュアルに無いのはなんでなんだ？
ホント歯抜けの多いマニュアルだよなこれ。

ふーい、なんとかサイドバーも終わった。
あとはユーザーページと
ログインユーザーとゲストの表示の調整だけだ。

これでやっとコーディングやらデザインに入れる…。

バリデーションエラーになって、元画面を再表示するとき、
POSTされた入力値を再表示画面にセットしたいと思っています。

テキストボックスに再表示する方法は old() でできますが、
リストボックス、チェックボックス、ラジオボタン のセットは
どのように行ったらよいのでしょうか？

>>239
->withError()するだけじゃん
getで初期値いれとくだけで何も考える必要ない

>>232 のリンクみてる？

->withInput() な

「Laravel 4 Cookbook 日本語版」って70％で止まってるけど、もう翻訳されないんだろうか？
最初に買った「Laravel4でこなすプログラム術 Getting Stuff Done」 はとても良かったんだけど
DB系の機能に一切触れてなかったから次はCookbook買おうと思ったんだけど翻訳止まってるんだよね…
「Code Bright」はマニュアル程度の内容だったし…

Code Bright のP28

　　Composer ガオーとロードできるように・・・

なんだよコレ。。。
日本語なのに翻訳が必要じゃねーか。



ところで入門書としてのお勧め書籍を教えて！

>>243
なにそれかわいい

入門書なぞない。
マニュアルと、海外gitとかでいろいろアップされてるからコード見て勉強だ

laravel関係ないけどさ、コントローラー名やらメソッド名とかって
ガンガン長くなちゃうんだけど、どうしたら良いの？

意味はわかるように出来るだけ短くとか、ドヤ顔で解説してるところあるけど、
それができたらわざわざ質問しねーよとｗ

ハイフンで区切ったり、アンダーバーで区切ったり、大文字にしたりあるけど、
なんかフレームワークによってバラバラだし、好きにしていいよってことなんかな？

20文字以内なら許容範囲と思うかなー
昔のハンガリアン記法チックな名付けしたりして 辺な短縮するよりわかり易いほうがいい。
エディタの補完機能あればタイプミスはまぁ発生しないし。
20文字超えだすと一行内に収まらないコード続出で可読性が正直落ちる…

「Controller」だけで11文字もあるんじゃん。

長くても、後で意味が分かるほうがいいと思うけど。

testとかめちゃくちゃ長くなるよね。

20文字は厳しな。
いま見てみたら25文字のファイルあった。

まあ長くてもわかるほうがいいか。どうせ自分で使うんだし。

あと面倒だとint、str、val、key、arr、とかつけるけど、
あとで見ると何だったかわからなくなる罠ｗ
こういうのって、なんかルールほしいよね。