[PHPフレームワーク]Laravel

Laravelはシンプルでプログラミングが楽しくなるPHPフレームワークです。

■公式サイト
http://laravel.com/

■ライセンス
MIT License

■公式ドキュメント
http://laravel.com/docs

■ドキュメントの和訳
http://laravel.kore1server.com/

■動作確認したPHPのバージョン
5.3, 5.4

>>152
ありがてぇ、ありがてぇ
早速見てみる。

なんだかこれ、理解するの難しいな。
解説日本語だけど、専門用語多くて、いまいちわからんｗ

Eloquent難しすぎワロタｗ
解説読んでも全然意味わからねーｗｗ

初めて入れてみたけど最初全然わからない
fuelphpを入れてみてそのマニュアルからやっと構造が見えてきたけど
public/index.php をアクセスするなんて推測できなかった
もうちょっとなんとかならないか
一番最初だけにかなり損しているのでは？

public/index.phpにアクセスするのがそんなに変か？？？
外に見せるものだけpublicに置くのは当たり前だし、普通のPHP有効なWebサーバならindex.phpがDirectoryIndexになってるだろうし。

これ、マニュアルこれでええんか？
丁寧に翻訳されてるのは嬉しいが、これだけじゃさっぱりわからん。

テンプレートに関するところなんて、これで理解できるわけ無いだろう。
http://laravel4.kore1server.com/docs/42/templates
「layoutプロパティーをコントローラーで指定すれば、指定されたビューが生成され、アクションからレスポンスが自動的にリターンされます。」
って、日本語でおｋって感じなんだがｗ

しかも、仕方なく解説サイト見ても、1つ2つ前のバージョンのものしか見つからず、
書式が変更になってて全然動かんし…。
やっぱりこういう時に活発なフォーラムが必要と痛感するわ。

>>156
全然わからないという気持ち、よくわかるよ。
最初は、Ｆ／Ｗはとてつもなく難しい。

さっぱり分からなくても、すこしづつやって、「動いたよバンザイ！」って気持ちを
その都度その都度持ち続けられれば、そのうち使えるようになるよ。


そもそもWebアプリを開発するには、PHPの文法、HTML、Webサーバの構築、
HTTPプロトコルの理解、リダイレクトの理解、アクセス権の理解などなど多くの
知識が必要で、Winアプリの開発などとは比較にならないほど大変なのよ。
開発環境を作るだけでも大変なの。

がんばれよ〜

>>158
テンプレートのマニュアルは、これで必要にして十分だと思うけどな。


> layoutプロパティーをコントローラーで指定すれば、指定されたビューが生成され、
> アクションからレスポンスが自動的にリターンされます。

的確な解説だと思うが、F/W初心者にはわからないかもしれないね。
「日本語でおｋ」って気持ちはよくわかる。

文章にいちいち文句言わないで、とにかく動かしてみるのが良いと思うぞ。

いや、別に文章には文句言って無くて、
これだけだと全然テンプレートの解説になってないってことを言いたいわけよ。

Bladeテンプレートの方はたくさん書かれてんのに、この解説だけすげー投げやり。
そして試しにテストしながら動かしてんだけど、
これでは何をテストしていいやらそれすらわからんということ。

そもそもビューの使い方は「View::make」で指定するんちゃうんかい！
全然自動ちゃうやんけ！
ただコントローラーにビュー指定してんのとテンプレートとなんの関係があるんだよ。
と、思ってるところ。

英語聴けるなら、laracastとか。

これってルーティングとかキャッシュされてるってことある？
XAMPPでテストしてんだけど、さっきやって動かなかったやつが、急に表示されたりするんだけど…
単なるスペルミスかな？

確かに初見でこの例だけ見ると混乱するかも

ビューとレスポンスの章のビューの部分を既に読んでView::makeしてreturnする普通の手法は心得てるとして
http://laravel4.kore1server.com/docs/42/responses
テンプレートの章では@extendsによる拡張の説明＆共通レイアウトの分離の例を出してから
コントローラーで継承するレイアウトを指定してcontentにテンプレートを割り当てる便利な方法もあるという流れのほうがすんなり入りそう

FWの歴史を考慮すればコントローラーレイアウトが基本なのかもしれないけど
個人的にはあまり使わないんだよなあ

自動的にリターンってところの解釈の違いか？
コントローラーアクション内で明示的にレスポンスをreturnせずとも
レイアウトにコンテンツのテンプレート突っ込んどくだけで
後はよしなにやってくれるというだけの話なんだが

ふー、やっとブレードレイアウトも全体像がわかった。
なんでもっと分かりやすく解説してくれないんだろう。
わざと分かりにくく書いてテストさせようとしてんのかな？

このＦ／Ｗ使うとコーディングが楽しくなるというウリらしいけど。。。

ちょっと見た限り、メソッドの名前にクセがありすぎ。
楽しくなるどころか、とてもじゃないけど苦痛になりそうだな・・・

FuelPHPとかCodeIgniterのほうが、よっぽど素直。

将来性としてはどう？

将来性なんて、どんなＦＷも”どんぐりの背比べ”だと思う。

今はLaravelはトレンドかもしれないけど、１年後には廃れる気がしている。

ＦＷを選ぶなら、今現在自分にとって最高と思えるＦＷを選ぶべきじゃないかな。

安定性でいえばzendしかないが糞めんどいからな
今アメリカじゃlaravelとphalconって大方独占してるらしいけど
両方とも新規すぎて何とも言えないね

これってルーティングをgroupでまとめてgetとか書いていく方法と、
コントローラーでrestフルに書く方法あると思うんだけど、
どっちがオススメとかある？

個人的にはコントローラーでまとめてgetIndex()とかpostProfile()とか指定するのが楽で好み
ドキュメントにはImplicit Controllers（暗黙的なコントローラー）と書いてある
ルーティングを一覧したい派には不評みたいだけど

そういやLaravel5ではルートをアノテーションで指定できるようになるんだってね
https://laracasts.com/discuss/channels/general-discussion/route-annotation-in-laravel-5
before filterもミドルウェアに置き換わってるし色々試さないと

賛否分かれそうな感じだ

ミドルウェアって、
「HTTPなんてリクエスト送ってレスポンスが返ってくるだけだし、フィルタみたいな感じで処理挟めるんだから、じゃあそれをフレームワークに依存しない共通のインタフェースで書こうよ」
ってこと？

Laravelは、Symphony兄貴にのっかてるだけだが。
PHP本体に入ることはなくても、PSRみたいな感じでまとまっていくのかな。

Eloquent が気に入った
whereHas() が where (select count(*) ...) >= 1 みたいなうんこSQLになるけど
この辺りは今後に期待してる

>>172
ありがとうコントローラーでまとめてやってみるわー。
1ページにまとまってるサンプル見ると、一覧性があるというけど、
そのぶんごちゃごちゃで内容把握しにくいよね。
作った本人は完全に理解してるから気にならないだろうけども。

ふー。
やっとログイン機構と、メールでの登録確認まで出来た…。

あとはユーザーページと、投稿画面、一覧表示だな。
先は長いぜ…。

投稿画面、確認画面、データベースへの書き込みまでオワター。
データベースの連動と、ログインしている場合と、してない場合の振り分けがメンドイ…。
匿名ユーザーの投稿とか実装するとメンドイのね。

みんなはデザイン抜きで、ブログシステムを作ったりするのにどれくらい時間がかかるものなの？

htdocsの下に、testフォルダを作成し、そこにLaravelをインストールしました。

で、ブラウザで、http://localhost/test にアクセスしましたが何も表示されません。

http://localhost/test/public とすると表示されます。


http://localhost/test で表示できるようにするには、どうしたらよいのでしょうか？
設定不足？　日本語マニュアルには記載がないようですけど・・・

app/config/app.php設定した？

Webサーバ側の設定だと思うんだけど、Laravelだけで何とかできるんか？

ん？public_html/test/public みたいになってんのコレ？

Laravelの入門書の出版予定ってある？

なんか既に何冊も出てなかったっけ？

電子書籍がたくさん出てる

"Laravel 電子書籍" で検索

なんで電子書籍なんだよー

確かにハウツー本って普通立てかけたり、
テーブルに置いたりして見ながら進めるから、電子書籍だとすげー使いにくいよな。
アイパットとかあるならいいが。

辞書みたいにプロパティ全部網羅とかなると、今度は検索使えるから電子書籍が断然有利だけど。

同感！

リファレンスなら電子書籍のメリットがあるけど。
入門書は絶対に紙の本がいい。
電子書籍じゃ使いにくいし、読んでも頭に残らない。

CakeやFuel並の書籍は出ないかな・・・

これ、ルーティングって内部的には何をしてんだろ？
単純にApacheのRewriteみたいなことしてるだけかな？

なんと答えていいやら。

ふー。タグ一覧の実装がやっとこできた。
データベースの設計から考えないといけないから大変だ。

って言っても、ネット上の情報探して真似するだけだけどｗ

日記乙！

これルーティングって上から順番に評価されるって普通なの？

サブディレクトリ作るのにroutes.phpでグループ化して

/
/hoge

だとエラーで

/hoge
/

の順番に記述すると正常にできるんだけど…。

普通です

上から順に実行って普通やんか

最長一致になって欲しい気持ちも判るが
パフォーマンスを考えたら我慢できるレベル

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

いやさ、

/
/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でやるのか、常套的な方法がありましたら
教えてください。
またエラーメッセージの画面間の引き渡しはフラッシュデータを使うのが常套手段なの
でしょうか。

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

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

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

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

レコードの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

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

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

すみません訂正です。

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

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

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

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

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

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

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

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

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

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

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

ご勘弁ください。

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

>>218
ですよね。
っていうか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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>230 のリンクみてる？

->withInput() な

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

>>241
なにそれかわいい

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

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

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

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

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

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

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

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

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

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

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

ここもなんだかんだで伸びが早くなってきてるな。
そろそろ日本でも本格的に広まってほしい

いやーしかし覚えないといけないこと多いね。
リンク生成するだけでも一苦労だわ。
別に普通に相対URL書いてもいいけど、それだと負けた気がする不思議。
そして恐らく関数使ったほうが遅いというパラドックス…

>>250
同意。

しかも、http://からの絶対URLだと、Webサーバの前段にロードバランサなど入れてあると
ダメだったりする。

相対URLのほうが良いと思うなあ。
相対URLを取得する関数はないのかな？

"{{url()}}/admin/hoge" じゃだめなん？