■公式サイト
ttp://laravel.com/ ■ライセンス
MIT License
■公式ドキュメント
ttp://laravel.com/docs ■ドキュメントの和訳
ttp://laravel.kore1server.com/ ■動作確認したPHPのバージョン
5.3, 5.4
A. まずは使ってみろ
それぐらいちょっとは考えろ。
自己紹介乙
また来年は新しいのが出てくるのかなｗ
俺は好きなんだけどな。
使ってみて良かったところ
・デフォルトテンプレートが綺麗。「開発環境」色がない。
最初に画面見た時にヤル気出た。
・routes.phpの多機能っぷりのお陰で自由度が高い。
「規約より設定」が好きな人向け？
・マイグレーションが楽(FuelPHP比較)
・バンドルが結構豊富、インストールも簡単。
・アメリカ、イギリスでの支持が大きい。
googleトレンドで見ると先進国ではFuel、Kohanaあたりは完全に食っていてYiiも食いそう。
残念だったところ
・日本語ドキュメントが少ない、英語のマニュアルもボリューム足りない。
・Laravel4で大幅に仕様が変わるらしくさらにドキュメント不足に。
趣味のwebアプリで使う分には不自由してないし、ドキュメントの少なさも調べる楽しさがあって個人的には気に入ってるよ。
EloquentっていうORMクラスを使うのが一般的みたい。
usersテーブルだったら、modelディレクトリにUserっていう継承クラスを作っておくだけで入出力ができる(もちろんテーブル名は設定可能)
あとはコントローラで
$users = User::where_in('id', array(1, 2, 3))->get();
とか書けば配列が帰ってくる。
この辺は本当に直感的でお手軽だと思う。
ユーザ管理なら有志のバンドルの「Sentry」っていうのを試してみたら多機能だしマニュアルが超親切で良かった。
デフォルトのAuthはちょっと非力かもしれない、ユーザごとのパーミッションとかないし。
足りない機能は自前かバンドルで補ってねっていうスタンスらしく、laravel4ではHtml、Formクラスすら拡張対応になるそうだ。
Form::open();
とかで作って、コントローラでは
$id= Session::get('id');
という具合にセッションから受け取る感じ。
上に書いたようにLaravel4ではFormが標準から外れるから書き方が変わるみたいだけど。
今後web上で見かけたらよろしくね
FromはInput::get('id')だろ。
で、バリデーションは
$rules = array('id' => 'required|integer|exists:user');
$validator = Validator::make(Input::only(array_keys($rules), $rules));
if ($validator->fail()) {
}
こんな感じ。正直もうちょっと待ってLaravel4から始める方が良い気がする。
ちなみにComposerもライブラリとしては勿論使える。これは３でも４でもだが。
Fluentクエリービルダーみて感動したのは俺だけなんだろうか。
ttp://forums.laravel.io/viewtopic.php?id=6671 ttp://stackoverflow.com/questions/15836443/laravel-how-to-route-to-public-file ttp://net.tutsplus.com/tutorials/php/building-web-applications-from-scratch-with-laravel/ $ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
- Installing meido/html (v1.1.2)
Downloading: connection...
Could not fetch
ttp://nodeload.github.com/meido/html/zip/v1.1.2, enter your Git Hub credentials to access private repos
ttps://github.com/settings/applications/new ttps://github.com/patricktalmadge/bootstrapper/blob/master/composer.json うーんまだ3使ってるひと多そうなのと composer まだ時期尚早なん
じゃないかとかその辺でごちゃごちゃしそうな予感がする…
ttp://stackoverflow.com/questions/14192750/getting-class-html-not-found-error-in-laravel-4 ttp://stackoverflow.com/questions/12448912/apache-mod-rewrite-for-laravel ttps://github.com/languages/PHP/most_watched ttp://www.goldinteractive.ch/intro 今月の下旬にlaravel4リリースとかそんなかんじだけど
まだ先は長そうな印象だった
でもwatch数はすごいな。
ttp://togetter.com/li/508012 まだ時期尚早なん？
PNE案件とか大概そうだし。
和訳をdisった人って
まだ決着ついてないのね
和訳サイトにわざわざdisられましたとか載せてて意味あるのかな
向こうもtwitterとか連絡できる手段があるんだから直接ぶつければいいのに
ちょっと感動したんだが何か問題があるのか
ttp://kore1server.com/149 ttps://www.youtube.com/watch?v=SjGtzBHEvlE#6m22s 二人ともいい年した大人なんだからさ自分の意見を直接相手にぶつけることもできるでしょう
ずるずる関係悪いままで相手が折れるのを待ってるような情けない女々しい考えは捨てるべきだ
このまま引きずって双方が勉強会に参加されても場の空気が冷める場面に直面する可能性もある
前回の勉強会は実際に仲裁できるような人なんて1人もいなかった。俺もだけど
2人のために無駄に気を使わされるのも迷惑だし
解決できないならどちらとも勉強会には参加してもらいたくないのが次回も参加する俺の意見
オープンな勉強会に「(自分より知識ある|知り合いだ)から注意しにくい」とか関係ないから
Kのサイトだけを読むと 一方的にNが悪いように見受けられるが
Nがdisる前に KがNをdisったから NがあそこでKをdisったって見方もできる
動画を見ても、Nの「アイツをdisってやった」オーラがハンパないもんね
KがNを怒らせたり嫉妬させるような出来事があったのかもしれない
Nが発表する前までに何か二人の関係にギクシャクする事があったんだろうと思う
何で二人で話し合えないのかね
現場に入ると、初手から一方的にマチガイ対応するやつもいるし。
○キチガイ
どのへんが問題なの？
何分辺り？
皆どうしてるの？一から書いている？
その辺の思想？みたいなものがわかるページない？
ってのがおかしいの？なにがわからん？
ありがとう！
Cakeから来た俺もそれ思った。「コントローラでヴァリデするんかー、へー」くらい。
何故かは深く考えたことない。
なんでこんなことになってるか考えたら多分MVCしないで横着にコントローラだけですますとかrouterだけで済ますとかの軽量アプリを全然OKっていうところから来てるんだと思った
railsでコンソールからModel.create({name:'hoge', age:30})とかやった場合にバリデーション吐き出すのは素晴らしくスマートだと思ってたし
そうじゃないとおかしいだろとまで思ってたけどそもそも思想が違うんだろうな
Ardentとかいうの入れればモデルでバリデーションできるらしいけどもういいや
まずMVC語るのやめれ
モデルはないわ
ケークはダメフレームワークだから参考にしちゃだめだよ～
なんでWebフレームワークで15MB前後の要領食わなきゃいけないんだ
なめすぎ
VやらCやらがゴチャゴチャしてきて機能別に分類したいんだけどlaravel-modulesもなんか面倒くさい
設置してさっと使えるようにして欲しいわ
モデルは手続きも含むものだ
そのメソッド独特の入力制限でもしたいんだろうが、
例えば同じテーブルの同じフィールドに別のバリデーションを設ける場合がそうあるのかって話だ
権限の違いなんかで制限が変わってくる場合はその権限用のバリデ付きモデル作れた方が後で見通しがしやすい
が言ってる「横着」ってのはそれを面倒臭がってコントローラで済ますんじゃねぇってことでしょ
日本で使ってる人が少ないだけ？
検索条件をPOSTしてその結果を、条件入力した同じページの下部に表示させるお馴染みの処理なんですが、
Routes.phpのPOSTのところで、Redirect::toでGETへ戻すのがいいのか、 View::make('GETと同じヴュー') で
ヴューを作っちゃうのか、どっちがベストプラクティスなんですかね？
return Redirect::to（どこどこ）->with(変数名、 変数); ← セッションに突っ込む
この違いがどうにもはまるポイントなんだが。なんで同じwithで動きがちがうんですかね。
GETにしておかないと、ページャーでページングして戻るボタンがウザいとか問題がある
検索処理じゃなくて、例えば掲示板の書き込みなんかの場合、POSTで送信して処理後にリダイレクトでGETし直す
必ずこうしないと行けない訳じゃないが、だいたいこう
検索は基本的にGET
ありがとう。GETで引数渡すってことは、URLの後ろにごちゃごちゃと長い検索条件をくっつけるあの方法ですよね。
確かにそれが一般的ですよね。ありがとう。
これ、覚えること多くて奥が深いよ。
フレームワークのアップデートはコマンドで一発だから楽だな。
俺は個人的に大好きだけど、大人数でやる場合には、色々と取り決めが必要になる。じゃないと後々面倒。
後、クラスを追加した後にコマンドとか打たなきゃだから、vagrant環境で開発進めていって、後で皆のファイルをマージした方が楽かもね。
海外だとlaravel
グーグルトレンド見るとひどい
何らかのライブラリを追加しつつ
ローカルで開発し終わったら
本番環境ではFTPでディレクトリ単位でローカルのファイルを
単にアップしたんじゃ動かない？
ローカルと本番のディレクトリ名を直したりとか必要？
もしくは、sshで追加したライブラリをインストールし直さなきゃ動かない？
俺がマイナーなのかな？
php開発ってローカルでするものなの？
サーバーにサブドメイン切って、本番、開発、デザイナー用とか作らない？
環境揃うし、なによりrsyncで複製作れる。
そういう意味で、ドメイン、ホスト名、サブドメインはどこにも設定しないので問題ない。
ただし、デザイナーの書くテンプレに絶対パスが紛れる可能性は否定できない。
蛇足: PCがWindowsでもwin-sshfsでドライブをマウントできるから。
アップデートを1箇所で管理したいのでプロジェクトごとにLaravelをインストールするやり方はしたくないです
composerの管理をglobalでやればいいんでないの？
試したの？
include指定がめんどくさくなるから、プロジェクトの外に置くメリットをあまり感じないけど。
よってcomposerでglobalインストールする方法はない
そういう使い方が用意されてるFWなんてないっしょ
composer.jsonのアプリ部分とベンダー部分を分離しないとダメだし
artisanが敵でhookを書き換えないと正常に動かないし
require,includeが複数あるから面倒だし
path.baseの直下にvendorがあるとFW内で書かれているので対応しないとダメだし
workbenchあたりもなにかあるかもな
プロジェクト毎にlaravelは置いておいて
全composerを管理するシェルを作るとか、デプロイツール使うとかが現実的
5プロジェクトで100MB超
大規模に向かないフレームワークのくせにサイズ多すぎなんだよ
どうでもよい。
4.2は何が変わるんだろ
LaravelでCakeの出番はもうなくなったなーと思って早１年。
日本では全然ブレイクする兆しがない不思議さ
Cakeより何十倍もLaravelのが出来がいいと思うのだけどねぇ
2chってこういうプログラミング関連の書き込み意外と少ないし
それが健全だと思うわ
意識高い系はどこからどこに移ったんだ？
自己顕示欲を出せるところ増えたしな
最近だとqiitaとかかな。質問できないのが辛いが
アイデアやライブラリもたまってきたけど、だから何？って感じ
ブログ書いてる暇ないし
コメント書けるでしょ
Laravelに限らないけど、情報を共有しようとする姿勢の人が増えないと流行らないだろうね
でも海外じゃあ十分流行ってて情報もあるから、英語できれば問題ないね
有用かどうかはともかくｗ。
Qiitaは書く場
今まで2chで答えてた人は
自己顕示欲を出したいだけなので、書きたかっただけ
そもそも日本語情報じゃなきゃいけない場合って、込み入った内容だし、コードで会話するのがエンジニアでしょ。
アウトプットの場所はあって良いけど。
コードで会話ｶｺｲｲ!
せっかくだから質問してみる
artisanコマンドの中で
use Menber;
と書いたらしかられた
modelsをロードするには、何をおまじない書いたらいい？
Menber
いや、そういう問題じゃなく(typoはあやまるが
include_path通しただけじゃだめだよね
あ、include_pathもuseもなしで、いきなり使えるのか
やられた！
日本ではPHPで開発する機会が減ってるからPHPのフレームワークネタはもう盛り上がらない
なんで減ったの？
cake→railsって流れ
Laravelも来年あたりから本格的に来るのかねー
ところで、githubあたりでそれなりの規模のあるアプリのプロジェクトとかってないかな？
他の人が、どういうふうに書いてるのか読みたいんだけど サンプルに毛が生えたやつしか見つけきれん orz
そんなに多くの企業がRails使ってんのかな
（はやった理由は理解してる）
Rails以降のフレームワークのほとんどは、フォロワーとしてアンチとして何かしらの影響受けてるんだから。
そんな中、ここの皆はLaravelのアーリーアダプター。知見を集めて一歩先んじておこう。
コードで会話。わかるわ～。
英語のブログの文章読むの辛いがコードが書いてあると読みやすくなる
$you = 'shit';
とか
$var1 = 'fuck';
$var2 = 'you';
echo $var1 . ' ' . $var2;
とかね
読んでみたのだが、何がよいのかわからなかった。
CodeIgniterから乗り換えようと思ったんだけど。
そんな僕に、Laravelの良さを教えてください。
開発クローンの作成やメンテが瞬時だ
（composerの実行時間は除く）
ｵﾜｺﾝフレームワークを使い続けるのは、いつか破たんするから。
つまりLaravelの良さはRailsの良さと直結する
RailsいいけどRubyだから環境を選ぶからなぁ って人がこぞってLaravel使ってるんじゃないかな 特に海外は。
Laravelのどこがいいのでしょうか？
・・・と質問しても、なかなか一言で答えられるようなモノでは
ないですよねきっと。
コードリーディングし辛すぎ泣きそう
とりあえずお盆やすみは、Laravelマニュアルを読んで、
動かして見ます。
ありがとうございました。
PhpStormってやっぱいいの？
ORMとクエリビルダーはどちらを先に覚えるべきなんでしょうか。
セオリーがもしあるなら知りたいです。特にないならクエリビルダから触ってみようと思います。
同時一択w
モデルはORMで書くぺき
しかしstatic関数やコントローラーではビルダーが必要
今日明日というスパンでいうなら、ORMからってこと
ttp://bigchinpo.blogspot.jp/2014/08/php.html laravel/framework - Packagist
ttps://packagist.org/packages/laravel/framework 公式は見たけど、いまいち使い方がわからん。
サンプルというか tips ならここがまとまってる。
Laravel Recipes日本語版
ttp://recipes.laravel.jp/ あとは Stack Overflow とか？
ありがてぇ、ありがてぇ
早速見てみる。
解説日本語だけど、専門用語多くて、いまいちわからんｗ
解説読んでも全然意味わからねーｗｗ
fuelphpを入れてみてそのマニュアルからやっと構造が見えてきたけど
public/index.php をアクセスするなんて推測できなかった
もうちょっとなんとかならないか
一番最初だけにかなり損しているのでは？
外に見せるものだけpublicに置くのは当たり前だし、普通のPHP有効なWebサーバならindex.phpがDirectoryIndexになってるだろうし。
丁寧に翻訳されてるのは嬉しいが、これだけじゃさっぱりわからん。
テンプレートに関するところなんて、これで理解できるわけ無いだろう。
ttp://laravel4.kore1server.com/docs/42/templates 「layoutプロパティーをコントローラーで指定すれば、指定されたビューが生成され、アクションからレスポンスが自動的にリターンされます。」
って、日本語でおｋって感じなんだがｗ
しかも、仕方なく解説サイト見ても、1つ2つ前のバージョンのものしか見つからず、
書式が変更になってて全然動かんし…。
やっぱりこういう時に活発なフォーラムが必要と痛感するわ。
全然わからないという気持ち、よくわかるよ。
最初は、Ｆ／Ｗはとてつもなく難しい。
さっぱり分からなくても、すこしづつやって、「動いたよバンザイ！」って気持ちを
その都度その都度持ち続けられれば、そのうち使えるようになるよ。
そもそもWebアプリを開発するには、PHPの文法、HTML、Webサーバの構築、
HTTPプロトコルの理解、リダイレクトの理解、アクセス権の理解などなど多くの
知識が必要で、Winアプリの開発などとは比較にならないほど大変なのよ。
開発環境を作るだけでも大変なの。
がんばれよ～
テンプレートのマニュアルは、これで必要にして十分だと思うけどな。
> layoutプロパティーをコントローラーで指定すれば、指定されたビューが生成され、
> アクションからレスポンスが自動的にリターンされます。
的確な解説だと思うが、F/W初心者にはわからないかもしれないね。
「日本語でおｋ」って気持ちはよくわかる。
文章にいちいち文句言わないで、とにかく動かしてみるのが良いと思うぞ。
これだけだと全然テンプレートの解説になってないってことを言いたいわけよ。
Bladeテンプレートの方はたくさん書かれてんのに、この解説だけすげー投げやり。
そして試しにテストしながら動かしてんだけど、
これでは何をテストしていいやらそれすらわからんということ。
そもそもビューの使い方は「View::make」で指定するんちゃうんかい！
全然自動ちゃうやんけ！
ただコントローラーにビュー指定してんのとテンプレートとなんの関係があるんだよ。
と、思ってるところ。
XAMPPでテストしてんだけど、さっきやって動かなかったやつが、急に表示されたりするんだけど…
単なるスペルミスかな？
ビューとレスポンスの章のビューの部分を既に読んでView::makeしてreturnする普通の手法は心得てるとして
ttp://laravel4.kore1server.com/docs/42/responses テンプレートの章では@extendsによる拡張の説明＆共通レイアウトの分離の例を出してから
コントローラーで継承するレイアウトを指定してcontentにテンプレートを割り当てる便利な方法もあるという流れのほうがすんなり入りそう
FWの歴史を考慮すればコントローラーレイアウトが基本なのかもしれないけど
個人的にはあまり使わないんだよなあ
コントローラーアクション内で明示的にレスポンスをreturnせずとも
レイアウトにコンテンツのテンプレート突っ込んどくだけで
後はよしなにやってくれるというだけの話なんだが
なんでもっと分かりやすく解説してくれないんだろう。
わざと分かりにくく書いてテストさせようとしてんのかな？
ちょっと見た限り、メソッドの名前にクセがありすぎ。
楽しくなるどころか、とてもじゃないけど苦痛になりそうだな・・・
FuelPHPとかCodeIgniterのほうが、よっぽど素直。
今はLaravelはトレンドかもしれないけど、１年後には廃れる気がしている。
ＦＷを選ぶなら、今現在自分にとって最高と思えるＦＷを選ぶべきじゃないかな。
今アメリカじゃlaravelとphalconって大方独占してるらしいけど
両方とも新規すぎて何とも言えないね
コントローラーでrestフルに書く方法あると思うんだけど、
どっちがオススメとかある？
ドキュメントにはImplicit Controllers（暗黙的なコントローラー）と書いてある
ルーティングを一覧したい派には不評みたいだけど
ttps://laracasts.com/discuss/channels/general-discussion/route-annotation-in-laravel-5 before filterもミドルウェアに置き換わってるし色々試さないと
賛否分かれそうな感じだ
「HTTPなんてリクエスト送ってレスポンスが返ってくるだけだし、フィルタみたいな感じで処理挟めるんだから、じゃあそれをフレームワークに依存しない共通のインタフェースで書こうよ」
ってこと？
PHP本体に入ることはなくても、PSRみたいな感じでまとまっていくのかな。
whereHas() が where (select count(*) ...) >= 1 みたいなうんこSQLになるけど
この辺りは今後に期待してる
ありがとうコントローラーでまとめてやってみるわー。
1ページにまとまってるサンプル見ると、一覧性があるというけど、
そのぶんごちゃごちゃで内容把握しにくいよね。
作った本人は完全に理解してるから気にならないだろうけども。
やっとログイン機構と、メールでの登録確認まで出来た…。
あとはユーザーページと、投稿画面、一覧表示だな。
先は長いぜ…。
データベースの連動と、ログインしている場合と、してない場合の振り分けがメンドイ…。
匿名ユーザーの投稿とか実装するとメンドイのね。
みんなはデザイン抜きで、ブログシステムを作ったりするのにどれくらい時間がかかるものなの？
で、ブラウザで、
ttp://localhost/test にアクセスしましたが何も表示されません。 ttp://localhost/test/public とすると表示されます。 ttp://localhost/test で表示できるようにするには、どうしたらよいのでしょうか？ 設定不足？ 日本語マニュアルには記載がないようですけど・・・
テーブルに置いたりして見ながら進めるから、電子書籍だとすげー使いにくいよな。
アイパットとかあるならいいが。
辞書みたいにプロパティ全部網羅とかなると、今度は検索使えるから電子書籍が断然有利だけど。
リファレンスなら電子書籍のメリットがあるけど。
入門書は絶対に紙の本がいい。
電子書籍じゃ使いにくいし、読んでも頭に残らない。
CakeやFuel並の書籍は出ないかな・・・
単純にApacheのRewriteみたいなことしてるだけかな？
データベースの設計から考えないといけないから大変だ。
って言っても、ネット上の情報探して真似するだけだけどｗ
サブディレクトリ作るのにroutes.phpでグループ化して
/
/hoge
だとエラーで
/hoge
/
の順番に記述すると正常にできるんだけど…。
パフォーマンスを考えたら我慢できるレベル
いやさ、
/
/hoge/tag
/hoge/category
/user
/user/{id}
みたいな感じで書きたいじゃん。
単純に見やすいし。
それにしてもEloquentってこれ、便利なんかな？
やっぱり覚えたほうがいいの？
「美しくシンプルなアクティブレコードによるデーター操作の実装です。」って言われても、
そのシンプルに書くためにモデル作って、書式覚えて、1度書いたSQL文を変換してってなると、
なんか余計な手間のほうが増えてる気がするんだが…。
っていうか、サブクエリの方法がわからん…。
そしてEloquentってそもそもなんて発音するんだよｗ
それを永続化する際に保存先のRDBとインピーダンスミスマッチを起こすからその面倒を引き受けてやるよって話であって
逆にRDBやSQLありきの単なるラッパと思ってるならそりゃあ存在意義もわからんだろ
ほとんど作らないだろうがオブジェクトをDBに永続化する必要のないアプリケーションだってあるわけよ
何時間も使っちまった。
$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の説明はわかりやすい
ttp://docs.symfony.gr.jp/symfony2/book/doctrine.html 神かな？
Webの一覧画面、登録画面、修正画面、削除画面の遷移方法について質問です。
各々の画面遷移をPOSTでやるのかGETでやるのか、常套的な方法がありましたら
教えてください。
またエラーメッセージの画面間の引き渡しはフラッシュデータを使うのが常套手段なの
でしょうか。
冪等というのは同じ操作を何回行っても結果が同じということ
安全というのはサーバ上のリソース（大抵DBと対応）の状態を変化させないこと
・冪等 かつ 安全 GET HEAD
・冪等 かつ 安全でない PUT DELETE
・冪等でない かつ 安全でない POST
・POST→リソース新規作成
・GET→リソース取得
・PUT→リソース更新
・DELETE→リソース削除
という風にCRUDと対応付ける実装が多くLaravelの標準も同じ
※PUTとDELETEはHTMLのformが対応していないので隠しパラメータで擬似的に表現される
Laravelが用意しているリソースコントローラーのアクションの命名規則とHTTPメソッドの使い分けが参考になるだろ
実際にリソースを新規作成したり更新するリクエストはPOSTや（擬似）PUTだが
それらのリクエストを発するための新規作成画面（createアクション）や編集画面（editアクション）を表示するのはGETだな
ttp://laravel4.kore1server.com/docs/controllers#resource-controllers リダイレクト云々についてはGeneratorのControllerのScafolding見てみたら？
ttps://github.com/JeffreyWay/Laravel-4-Generators postメソッドは、エラー時もOK時もredirecrして必ずgetメソッドで画面描画
withInput()とwithError()が効率的に使えるし
ブラウザの戻るボタンで戻れるウィザードにもなるから
テンプレートにflashメッセージとflashエラーの描画入れとくと、いれいろ便利
すばらしい回答ありがとうございました。
両回答とも、知りたい事のドンピシャの回答で、よくわかり、大いに納得しました。
ご回答をふまえて追加で質問させてください。
修正画面を表示
↓
OKボタンが押される
↓
バリデーションエラーで修正画面を再表示
という画面遷移を考えたとき、修正画面に表示するレコードのID等を引き回す必要が出てくると思います。
このIDの引き回しは、<input type="hidden"> で引き回すのが普通なのでしょうか？
（つまり修正画面に、<input type="hidden"> を入れる）
それとももっとスマート？な方法があるのでしょうか？
リソースフルコントローラーの規則に合わせるなら
修正画面(edit)： GET /resource_name/{id}/edit
更新（update）： PUT /resource_name/{id}
としておく まあIDに限らずユニークなフィールドでレコードを特定できるならなんでもいいんだけど
修正画面のformからPUTしてupdateアクションでバリデーションが通らなかったら
withInput()とwithErrors()を利用してeditアクションにユーザの入力値やエラーを渡しつつリダイレクトする
editアクションではInput::old()が空じゃなければそちらの値を優先して表示
探してみたらベストプラクティスの考察記事もあったよ
ttp://qiita.com/asaokamei/items/e5070f9fad4c91e52bdc ありがとう。まずはEloquent理解してからだわｗ
しかし今まで作ったやつEloquentに書き換えてるけど、
実際使ってみると確かに楽だわ。
クエリースコープ便利すぎワロリンコ
＞レコードのIDの値はURLに含めるほうが楽じゃない？
こうすると、修正画面に遷移する前の画面（つまり一覧表示画面）で、修正するレコードがどれかを
判別し、そのＩＤをURLに入れてsubmitする、という javascript が必要になります。
修正画面にはPOSTで遷移すればjavascriptを書く必要がないのでシンプルで良いと思った次第です。
しかし、紹介していただいたベストプラクティスを見ると、バリデーションエラーになって元画面を表示
するのに、
return Redirect::back();
という方法を採っています。
この方法、シンプルですね。
やはり修正画面の表示はGETに統一し、上で書いた javascript は必要、と考えたほうがよい気がしました。
FORMをGETでsubmitしたことがないので間違ったことを書いたかも。
GETでも javascript は必要ないですね。
そう言えばそうですね。
チェックボックスをチェックして修正ボタンをクリック、ばかり考えていましたので。
ただ、修正画面ではなく、複数選択して次の画面に遷移する画面もあると思います。
そんな時はやはりAタグではなくチェックボックスだと思います。
すると、FORMでGETメソッドですよね。
あ、GETではパラメタサイズが制限されるから、チェックボックスで複数選択のときはPOSTなのかな。
最近のGETパラメータのサイズの制限はそんなに厳しくないと思うけど
バリデーションのカスタムフィルタ作ってValidator::makeするって感じしかないのかな？
そういった普通に使いそうな便利ツールまとめたライブラリとか無いのかな？
新しいこと頭に入れすぎて混乱しとるわｗ
失礼しやした
後付条件になってしまい、すみませんでした。
204の質問に対して205, 206の回答をいただき、
DBに保存しない処理は「GETで統一がいい」と納得しました。
しかし、画面によっては複数のチェックボックスにチェックして「修正する」ボタンを
押すような画面もあることに気づき、その結果、後付条件になってしまいました。
ご勘弁ください。
同一IPによる連投禁止は、プロキシを介してリクエストしてきたとき
実際に端末は違っていたとしても同一IPになってしまうよ。
ですよね。
っていうかCookieでも毎回消されたら意味ないけどｗ
まあ、ただの投票ボタン付けるだけだから
厳密に規制したいわけじゃないからいいんだけどね。
カスタムバリデーションへ複数のパラメータを渡すにはカンマ区切りな。
いい子はテストにでるから忘れるなよ。
'meta_key' => 'custom_validation:parameter1,parameter2'
いちいちマニュアルになくて試しながらだからくっそ時間かかるわー
俺もメールで戸惑った。
簡単なメール送信でさえ、わからなくて悩んだよ。
cornでキャッシュ作成と、データベースの更新とメンテまでできた。
カスタムコマンドは引数使わない場合はモードを
InputArgument::REQUIREDではなくてInputArgument::OPTIONALな。
これもテスト出るぞ。
Fuel > Cake >> zend みたいな感じで陳列されてた。
LaravelってCakeぐらいは越えられる？
FuelPHPやYiiのほうが、オンラインマニュアルの質が格段に高い。
ふつうのWebサービスを作るにはFuelPHPやYiiで十分だろうし、学習コストを考えると、
FuelPHPなどのほうがよさそうに思いました。
仕事で使うには、学習コストって重要ですよね。
世界的に見てFuelPHPよりLaravelがトレンドのようですが、Laraveが優っている
理由はなんなんでしょうか？
単に宣伝が上手かっただけとか？
フィルター中の比較演算子を!==に変更してください。
ttp://laravel4.kore1server.com/docs 昔のマニュアルにあったのが、新しいマニュアルで削除されたりしてる謎。
変なとこだけ冗長だったり、肝心のところがなかったりする。
ただ、実際書いてみると「なるほどね」って機能が多いよ。
実用的なチュートリアルも無いし、日本ではまだまだこれからって感じだね。
とにかく手を動かして、ダメなときは海外のフォーラム覗いて、
既に公開されてるソースを眺める。
今のところこれしかない。
絶対ここの常駐者だな...
ttp://www.rapidexp.com/wordpress/category/laravel/ てか、まだ現役だってことにビックしたw
誰それ？初めて見たが…。
一応迷惑かかるとあれだから否定しとくわ。
てかさ、サイドバーを付けたいんだけど、
これってメインのコンテンツ表示してるコントローラーでサイドバーについてもデータ渡すの？
せっかくbladeのViewでインクルードしてんのに、意味なくね？
sidebar.blade.php側でコントローラーのデータ読み込んだりできないのかしら？
blade側でやるのは、メニューデータのforeach展開だけ
メニューデータ取得は、全コントローラーで継承するベースコントローラーでしょ
>誰
うん、DOSやパソ通しらなきゃどうでもいい
なるほど、こういうときにベースコントローラー使うのか。
何のために継承してんだかわからずおまじないとして書いてたけど、そういうことね。
ありがとう。
特定のビューが呼び出されると一緒にレンダリングされるってだけでしょ。
デフォルトでroutes.phpに書くって意味もわからんし、
逆にどこに書いても良いって言われても置く場所困るわ。
分けたところで作った人しか場所がわからず見通しが異常に悪くなるし…。
っていうか、デフォルトでroutes.phpに書くってマニュアルに無いのはなんでなんだ？
ホント歯抜けの多いマニュアルだよなこれ。
あとはユーザーページと
ログインユーザーとゲストの表示の調整だけだ。
これでやっとコーディングやらデザインに入れる…。
POSTされた入力値を再表示画面にセットしたいと思っています。
テキストボックスに再表示する方法は old() でできますが、
リストボックス、チェックボックス、ラジオボタン のセットは
どのように行ったらよいのでしょうか？
->withError()するだけじゃん
getで初期値いれとくだけで何も考える必要ない
のリンクみてる？
最初に買った「Laravel4でこなすプログラム術 Getting Stuff Done」 はとても良かったんだけど
DB系の機能に一切触れてなかったから次はCookbook買おうと思ったんだけど翻訳止まってるんだよね…
「Code Bright」はマニュアル程度の内容だったし…
Composer ガオーとロードできるように・・・
なんだよコレ。。。
日本語なのに翻訳が必要じゃねーか。
ところで入門書としてのお勧め書籍を教えて！
なにそれかわいい
マニュアルと、海外gitとかでいろいろアップされてるからコード見て勉強だ
ガンガン長くなちゃうんだけど、どうしたら良いの？
意味はわかるように出来るだけ短くとか、ドヤ顔で解説してるところあるけど、
それができたらわざわざ質問しねーよとｗ
ハイフンで区切ったり、アンダーバーで区切ったり、大文字にしたりあるけど、
なんかフレームワークによってバラバラだし、好きにしていいよってことなんかな？
昔のハンガリアン記法チックな名付けしたりして 辺な短縮するよりわかり易いほうがいい。
エディタの補完機能あればタイプミスはまぁ発生しないし。
20文字超えだすと一行内に収まらないコード続出で可読性が正直落ちる…
長くても、後で意味が分かるほうがいいと思うけど。
いま見てみたら25文字のファイルあった。
まあ長くてもわかるほうがいいか。どうせ自分で使うんだし。
あと面倒だとint、str、val、key、arr、とかつけるけど、
あとで見ると何だったかわからなくなる罠ｗ
こういうのって、なんかルールほしいよね。
そろそろ日本でも本格的に広まってほしい
リンク生成するだけでも一苦労だわ。
別に普通に相対URL書いてもいいけど、それだと負けた気がする不思議。
そして恐らく関数使ったほうが遅いというパラドックス…
同意。
しかも、http://からの絶対URLだと、Webサーバの前段にロードバランサなど入れてあると
ダメだったりする。
相対URLのほうが良いと思うなあ。
相対URLを取得する関数はないのかな？
{{link_to('admin/hoge', 'ほげに移動')}}
理由はなんか負けた気がするからｗ
これらを嚙ますだけで「遅い」とかぬかすなら、端からFWなんか使うな。
端からFWなんか使うな、なんていう前に、
URL::to()を使うメリットを語ったらどうかな。
それとも貴方は道具に弄ばれてる馬鹿ですか？
結果、あまり良さを見せなかった。。。
良いと思ったのは、Routerの機能、Bladeの簡潔さ、withInput()、withErros、old()、くらい。
Queueも良いと思ったが、自分で作ればいいやと。
特に自分の場合、過去の資産の関係からテンプレートをBladeではなくSmartyに
したいため、Blade依存のwithErros、old()などは意味がなくなってしまう。
また、V3からV4で仕様がかなり変わったようだし、V5でも仕様が変わるらしいので、
長期に亘り安定的に使うのはダメだな、という印象です。
LaravelはGoogleトレンドでは高ポイントだが、それを鵜呑みにしちゃダメでした。
日本語マニュアルもダメだし、業務に採用はできないな、と思いました。
？？？
リンク全てをハードコーディング。。。
アホですか。
ロードバランサやWebサーバの設定でなんとかなるでしょ
担当範囲外でいじれないって話ならご愁傷様
ドキュメントに明確に書いてはいなかった気がするし、絶対に動かないわけではないので、余計に厄介。
歯抜けと言われればそうだね～としか
ドキュメントの充実度を評価の基準の１つにするならYiiなんてどうよ？
最近出た2の翻訳はまだだけど概念の説明から細かいところまでかなり揃ってる印象
俺みたいに Rails使ってきた人には高評価
偽RailsなCakeのクソさに苦しめられてきた、やっとホンモノのRailsライクなフレームワークが来た！みたいな感じで。
逆にFuelみたいな軽量系や、CodeIgniter みたいに小さな部品を組み合わせて作る系のフレームワーク使ってた人は
微妙って感じの人が多い
このスレだけでも困ってる奴２人はいたな
大抵のフレームワークにエントリーポイントとなる１つのファイルがあるってわかってりゃ
publicがDocumentRootかどうかって些細な話だと思うけど
PHP初級者がFWデビューしてハマったら辛いだろうな
DocumentRootがいじれない共用サーバへの設置とか
Yii のマニュアルは、かなりイイ！ と俺も思うよ。
訂正の要望出したら直してくれるかな
>偽RailsなCakeのクソさに苦しめられてきた、やっとホンモノのRailsライクなフレームワークが来た！みたいな感じで。
わかる 最近は苦しみ通り越してダメな子ほど可愛い的な感覚すらある
CakePHP3がもう１年早ければ使い続ける選択肢もあったかな
1から全部作るのに1ヶ月以上もかかっちまった。もちろん片手間にだけども。
マニュアル読む
↓
コード書いてみる
↓
マニュアルにない
↓
海外の情報調べる
↓
自分でまとめ直してコード書く
こうしたプロセスをほぼすべての段階で踏んだわｗ
ルートで検索結果ページ作って、
ビューでブレード使って検索ワード渡して、
検索するテーブルのモデル作って、
コントローラーでエロクアント使って検索してまたビューに渡して、
またブレードで表示整えると…できあがり。
おまじない抜かしたら、実質10行くらいで書けるもんね。
バッティングしてめちゃくちゃ時間無駄にした。
最低でもエラーメッセージで「バッティングして作成できません」って表示されればいいが、
hoge model not found…。
まあ作り方も当たり前のように本家のマニュアルに無いという徹底ぶり。
こりゃ早い時点でちゃんとしたドキュメント作れば売れるでｗ
でもくっそ見にくいな…。
しっかしこの30点くらいのマニュアルはまじでないわ。
痒いところに全然手が届かん。
やりたいことができて見ても全く解決しないから
最初からググるようになってきたわｗ
あれだけ見ても分からないことが多すぎた
どっちかというとクイックスタート的な感じ
そう考えると手につけやすく分かりやすい部類なのかもと感じる
アレとAPIリストの中間にある逆引き的なのがあればとは思う
レシピ集はどっかにあったけど数が少なすぎ
クイックスタートにもなってないと思う。
ほんとマニュアルがクソだと思うよLaravel。
マニュアルも成果物の重要要素なのに。
残念。
マニュアルで不明な引数はソースみれば判明する
ttps://github.com/laravel/docs お前等のコントリビュート待ってるぜ！
マニュアルは英語だからよくわからんしｗ
checkdnsrrでDNSのチェックしてるだけかこれ。
っていうかDNSで名前解決しないサイトって何なんだ？
CDNかなんかでも噛ませてんのかな？
それとも普通にhtml使う？どっちがいいとかあるのかな
あとはデザイナーにませるから
素のhtmlでもwithInput()あるから制御できるし
これがプロのフレームワーカー
どうやら日本でも定着しそうだ。
海外のトレンドが日本でも定着するスピードが早くなった気がする。
ただしPython、お前は別だ！
ソースは？
新規案件から指定がなければララベルってとこ増えとる
フォーム関連は便利かなってくらい。
まあ元々フレームワーク使う人は自分で何でも作るだろうから、
導入とアップデートが楽ってのが一番のポイントなのかな？
同意。
ところで5.0はまだかな？
「キャッシュにアイテムを保存するのは、実に簡単です」とか余計なこと書く前に、
こういうことも書いといてほしいな。
それかエラーメッセージでそれとわかるように表示してほしいわ。
実用的なまとめ本の出版が待たれる。
5.0で豪快に変わりそうだから書く気起こらんなｗ
4系って、結局どれくらいの期間もったの？
テーブルのupdateしようとしたらupdated_atがないとエラーが出たので
public $timestamps = false; をモデルに書けば怒られないとのこと。
それでも怒られました、updated_atを追加して動きましたが今後は追加したくない。
キャッシュか何か残ってるのでしょうか。
必須でっせ。
自動で更新日と作成日が追加される。
rowとかでSQL書けば必要ない。
あと青っぽい解説サイトもある。
全部バラバラの謎。
開設当初.jpのサブドメインじゃなかったっけ？
わざわざ分裂させて何がしたいの？
せっかく流行ってきたのに銭の臭いがしていやんな感じですわ
WordPressとかならまだしも、フレームワークじゃ。
たぶん海外のこの仕組欲しいな。あのサイトに作ってくれないかな。
まあ頼むくらいなら自分で作れるからさくっと作ろう。
って感じのエンジニア特有のコミュ症が発症した結果だと思う。
問答無用でSE鳴らしたり:hoverでリンクの文字サイズ変えるとか何時の時代だよ
公式じゃなきゃLaravelのアイコン外して欲しい
わかるｗいきなり音なってびっくりした後に
「Laravelは最も洗練されたPHPフレームワークです。」 の文字見つけてイラッとしたｗ
ttp://readouble.com/laravel/4/2/0/ja/quick.htmlの手順どおりに php artisan migrateを実行すると下記のようなエラーがでてしまいます
[PDOException]
SQLSTATE[42000] [1044] Access denied for user ''@'localhost' to database 'f
orge'
環境が行けないのかと思いmampからhomesteadに変えたり試したのですがダメでした
エラーメッセージを見るにアクセスが拒否されたとのことなので、どこかで設定等しなければならないのでしょうか？
とかじゃないのか？
やや亀だけど
databaseの設定が間違ってるかも
app/config/database.phpのl設定を直すか、
手っ取りばやく試したいならdefaultをsqliteにすれば良いはず
ありがとうございます
sqliteにしてみたら上手く行きました
なんかごっそり変わるらしいけど、どうなんかね？
ちょこっと使いやすくするためだけに、それ以上の学習コストかかるようなアップデート無いことを祈る
一体どこで設定を保持しているのでしょうか。
app/storage内を見てもそれらしきファイルが見当たらなかったので質問させていただきました。
Laravelのバージョンは4.2.16です。
ttps://github.com/laravel/framework/blob/4.2/src/Illuminate/Foundation/Console/UpCommand.php#L26 ttps://github.com/laravel/framework/blob/4.2/src/Illuminate/Foundation/Application.php#L878 このへん見ると、app/storage/meta/down ってファイルがあるかどうかで判断してるな
ありがとうございます。
ファイルの有無で判断しているのですね。 勉強になりました
製品モデルに座標値をsetしたらshapeのプロパティも変化し、
モデルの座標値をgetすればshapeの方から取ってくるようにしたい。
shapeを作るのはfillメソッドの中でやり、座標値の読み書きは
get[座標値名]AttributeとSet[座標値名]Attributeでやってるんだけど、どうにもうまくいかないのです。
てか、うまくいくんだけどモデルをsaveすると製品のテーブルでは座標値が全部0になっちゃう。
すごく苦しんでます。どなたかお知恵を！
どうもアクセサもしくはミューテータのあるアトリビュートは
toArrayの対象に含まれないようで
自前のtoArrayを作って追加したらおkですた
お騒がせｽﾏｿ
今回はもともと対応するカラムが「ある」ケースなんですわ
そして普通にsaveするだけなら問題ない
でもtoArrayを通すと消えちゃうわけ
そういう意味ではこういう時ミューテータやアクセサを使うってのが
そもそも不適切なんだろうけど
特定アトリビュートが変化したとき副作用を起こさせる方法を
他に思いつかないんですわ
なんかいい方法あるかな？
Shapeをインターフェイスで書いて製品モデルに多重継承させるのが
きっとスジなんでしょうね
でもPHPのインターフェイスってなんか苦手でorz
ttp://laravel.com/docs/4.2/eloquent の一番下にそんなような事が書いてある ソースコードだと、
ttps://github.com/laravel/framework/blob/4.2/src/Illuminate/Database/Eloquent/Model.php#L2296 あたりかな
そこにも書いてあるけどappendsは
対応するカラムが「ない」時に使うものなんだよね
今回はそうじゃないのでスジ違いかなと思いつつ試してもみたけど
ダメだったんですわ
しかしアクセサの書き方を間違ってたせいかもしれないので
また今度試してみますわ、ありがとう
ほとんど必須だと思うんだけどなあ
動画は英語だし、テンポ遅くて見てらんないし。
まあまだ、これからかな。
悩ましいところだ
DBに関してなのですが、データベースを使用するときは use DB; をしないといけなくなったのでしょうか。
use DB; をしないと
Class 'App\Http\Controllers\hoge\DB' not found
と怒られてしまいます。
そのファイルの先頭で、namespace App\Http\Controllers\hoge; って書いてあるからでしょ
\DB::xxx() と呼ぶか、use DB; するかかな
PHP自体の名前空間の勉強も必要かもね
ありがとうございます。
名前空間に関しては調べてみます。
Laravel4.2の頃は余り意識せずに済んだので少し大変です。。
結構変わってるね、フォルダの把握とか名前空間とか(\DBのままでいいのかな)
一番ハマったのがAjax時のエラー、結果的にcsrf_token()を埋め込むだけなんだけど
Laravel初心者にはキツかった
スピード？
可読性？
機能UP？
PHP5.4以上って意外とハードル高いと思うんだけど
みなさんどうしてるんだろう・・・
ちなみに俺はremiを使ってるんだけど
yumに自動アップデートさせてたら今日おかしくなってしまった
やはり非標準レポは怖いということか
それとも他に要因があるのか
はぁまじ（）
NetBeansのデバッグセッションを終了してなかったので
CLI含めてPHPからの出力が全てリダイレクトされてた
そうするとyum updateの対象にPHP関連が含まれてる場合
（というか多分更新にPHP自身の動作が必要な場合）
yumが無言で止まってしまうんですな
こんなことで凄い時間を使ってしまったorz
5.4の公式サポートも今年の９月で終わるのに大変だな(´・ω・｀)
remi には remi-php55 と remi-php56 っていうレポジトリが別にあるの知らないのか
/etc/yum.repos.d/remi.repo.rpmnew 見れば設定が書いてあるだろうから、
/etc/yum.repos.d/remi.repo に必要なところをコピーすれば使える
導入時は一番最新のにしといて、あとはテコでもバージョンアップしないのがプロ。
標準パッケージで最新版かその前のくらいに追い付けるディストロに乗り換えたい
php関連ライブラリ（具体的にはphp-seclib-*）の
アップデートも削除もできないようになっちゃったんだからどうしようもない
とパニクっちゃった次第ですわ
PHP5.4自体の削除はできても55や56を入れようとすると依存関係で跳ねられるわけわけ
原因がバージョン云々ではなくxdebugセッションの終了し忘れにあったことは前述の通り（お粗末）
まあ今回の案件の実稼働環境はイントラのwindowsサーバなので
直接関係ないんだけどね
そっちはそっちでXampp（php5.6）上のLaravel4だとApacheがコケる
という問題が出てたりする
環境依存っぽいしphp5.4のWampなら大丈夫だから
何とかなると踏んでるんだけど気になるっちゃーなる
それを取り出すと
ちゃんと正しいクラスのオブジェクトではあるのに
リレーションが取得できない状態になるんだな
$my_model = new MyModel(Session::get('my_model_name')->toArray());
等とすれば大丈夫
これ仕様なんだろうけどバグといえるレベルなんじゃないかと
ちなみに4.2
4.2で試したけど普通にリレーション取れたよ
ダメな状況がわからん
4.1の頃の話だけど、モデル名にアンダーバーが使われてるリレーション貼ると取れなかったり
値をセットできなくなったりした
シンプルな post 1-N comments なら相互に取れるんだけど
post 1-N user_comments だと ダメになったりした
モデルをテーブルには未セーブ、つまりIDがない状態でセッションに入れるとどう？
IDがないとhasOneはもちろん無理だけどbelongsToは可能
それがセッション通過後だとnullになっちゃう
名前か、確かにリレーションは複合語ばっかりだからあるかも
にダウンロードしたいのですが、丸ごとダウンロードはできるのでしょうか？
未保存でそのままセッションに入れて別ページで取ってみたけど、問題なくbelongsTo先は取れたよ。
アンダーバー有りは試してないからそれかもね。
なんかおかしな挙動になったのは覚えてる
検証ありがとう。でも名前は関係無いようだ。そしてSessionも直接は無関係っぽい。
やっとちょっと整理できた気がするのでまとめます。長文容赦。
例としてUserとPhoneの関係。普通にPhone::userがbelongsTo('User')とします。
[ケース1]
$phone = new Phone();
$phone->user_id = 1;
$user = $phone->user;
return $user;
[ケース2]
$phone = new Phone();
$dummy = $phone->user;
$phone->user_id = 1;
$user = $phone->user;
return $user;
ケース1との違いは2行目が増えているだけ。もちろん$dummyにはnullが入ります。
で、結果はケース1だと普通に$userの内容が出力され、ケース2はnullが返ります。
つまり一度でも空っぽのリレーションを参照してしまうと、その後はキーの値を代入してもリレーションが作られない。
もちろん代入じゃなくてfillでも同じです。
fillや代入じゃなくてちゃんとassociateすれば大丈夫。
普通はfillの後saveして遷移するから、テーブルからの再取得時にリレーションができてめでたしとなるわけだけど、
セッションで引き継いでしまうとキーの代入やfillでは永久にリレーションができなくなってしまう。
結構イヤな挙動だと思いませんか？
使い方が悪い
> When updating a belongsTo relationship, you may use the associate method.
$phone->user とか未定義のプロパティにアクセスした際に走る __get, __set をオーバーロードして
Laravelのあの魔化不思議な動きを実装してる
具体的には、$phone->user とした時点で以下の動作が走る
プロパティ user の存在をチェック (PHPの動き)
- userプロパティが存在したら そのまま userプロパティの内容を戻す これはPHPの言語仕様でオーバーロードとかは一切できない
- userプロパティが存在しなかったら __get マジックメソッドが走る
で マジックメソッドはLaravel側でオーバーロードされていて 以下の処理をしている
- リレーションの有無をチェック
- リレーションが存在したら user_id の存在を確認する
- user_id も存在しなかったら userプロパティに null をセットした上で、そのnull を戻す
- user_id が存在して値が入っていたら select * from user where user_id = 1 が走った上で
userプロパティには userオブジェクトが格納し、その上でuserオブジェクトを戻す
キモは すでに存在するいプロパティにアクセスした時に効かせられるフックはPHPに存在しない って話。
ケース2では、すでに一度 $dummy = $phone->user; でアクセスし、この時点でuserプロパティが 内容null で作られてしまってる。
user_id をいじったら user の内容も連動して変わるってのは錯覚だって話なのよね。
初回だけマジックメソッドの効果でそう動いてるように見えるから混乱する。
user, user_id が共にセットされた後、つまりプロパティが作られた後は user_id を変えただけでは userの内容は自動的には変わらない。
さっき言ったように、すでに存在するプロパティにアクセスした時に効かせられるフックはPHPに存在しないから。
だから
$user = User::find(2);
$phone->user = $user;
とした後に、 $phone->user_id = 1; としても $phone->user の内容は自動的には変わらないし変えることも出来ない。
ただ、saveとか一旦すると user_id の値がDBに保存されて、次 またuser を再取得するときは user_id 1 のオブジェクトが戻されるため
いかにも自動的に変わったように錯覚してしまう。
丁寧にありがとう。
・null値も「存在するプロパティ」の扱いになる
・存在確認のために参照するだけでnull値が入る
というあたりがなんともモヤモヤするところではありますな。言語仕様的に。
「セッションにモデルを持って複数フォームで順次更新、最後にテーブルへ書き込み」
という流れは割と普通にやりたくなるところだと思うけど、
それはあんまりLaravelish wayではないということなのでしょう。
__wakeupをオーバーライドしてリレーションを取得させるようにすれば
テーブルへの書き込み->読み出しを経た場合と挙動が近くなると思うんだけど、
そう簡単なもんでもないのかな。
それをやめてくれるだけでいいのか。
そうすれば少なくとも初回のキー値代入で常にリレーションはできることになる。
とりあえず、後から
$phone->user_id = 1;
としたら、その直後に
$phone->load('user');
ってすればいいなら許容範囲な仕様だと思うけどね
わかってしまえば対処は楽なんですけどね。
新規作成はnew Model(Input::all())で問題ないから、
更新もfill(Input::all())で済ませたくなる。
で、その前にリレーションを一度も参照してなければなまじ動いてしまうもんだから
すっかり混乱してしまった次第。
こんなんで丸一日とか潰れちゃうんだよな・・・orz
特定の条件を入力して検索機能を作る場合、zendだとmodelにwhere文からfetchまでを書いてreturnすると思うのですが、
larabelではコントローラーで条件を書くのでしょうか？
↓こんな感じであってますか？
class Controroller extends BaseController {
public function anyIndex()
{
$query = new Model;
$query = query->leftJoin('sample', 'sample', '=', 'sample');
$query = query->where('sample', '=', 'sample');
$query->get();
}
}
class Model extends Eloquent {
protected $table = 'sample';
}
現役通せ
プログラマ
別に唯一正しいやり方はないし簡単なクエリーならControllerで組み立てても問題ない
Eloquentの使い方についてはドキュメント読んだほうがいい
ttp://readouble.com/laravel/5/0/dev/ja/eloquent.html 複雑なクエリーをテストしたかったり他のアクションで再利用したかったり
コードを整理したりしたいならクエリースコープ使えばいいんじゃない
ttp://readouble.com/laravel/5/0/dev/ja/eloquent.html#query-scopes class SearchController extends BaseController {
public function getIndex()
{
$condition1 = Input::get('hoge');
$condition2 = Input::get('fuga');
//入力値チェックなどしてから
$models = Model::search($condition1, $condition2)->get();
}
}
class Model extends Eloquent {
public function scopeSearch($query, $condition1, $condition2)
{
return $query->whereHoge($condition1)->whereFuga($condtion2);
}
}
ORMはオブジェクトありきで裏のRDBの存在をあまり意識しないで済むようにするための道具
SQLに近いコードが書きたいならクエリービルダーのほうが向いてるかもね
ttp://laravel.com/docs/5.0/queries これめっちゃハマりどころじゃね？
普通きづかんだろ
リレーションの仕様を理解していないだけの話だよ
そもそもプロパティなんて作らん、リレーションのキャッシュが働いているだけだ
公式ドキュメントのよっぽど目立つところにそういう説明がないと
まあ普通にハマる人は出るわね
結果「使えねーフレームワーク」という評価が広まることにもなるかと
実際俺はそうなりかけてたよ
暇な奴は
ttps://github.com/laravel/docs にPR出してくれ リレーションをプロパティ(PHPのプロパティでもあるしLarvelのDynamicPropertyでもある)を使って実装してる
何を言いたいのか判らんけど間違ってるのはここ
> プロパティ user の存在をチェック (PHPの動き)
> - userプロパティが存在したら そのまま userプロパティの内容を戻す これはPHPの言語仕様でオーバーロードとかは一切できない
> - user_id が存在して値が入っていたら select * from user where user_id = 1 が走った上で
> userプロパティには userオブジェクトが格納し、その上でuserオブジェクトを戻す
>
> キモは すでに存在するいプロパティにアクセスした時に効かせられるフックはPHPに存在しない って話。
> ケース2では、すでに一度 $dummy = $phone->user; でアクセスし、この時点でuserプロパティが 内容null で作られてしまってる。
「未設定リレーションを参照するとnull値が設定されて
その後はキー値を代入してもリレーションは取得されない」
という挙動が言語仕様的に不可避じゃないなら
ぜひとも解消してほしいところかな
原状、リレーションのプロパティがいつ設定されるのか見ようとして
デバッガでウォッチしてるといつまでもできないんだよね
ウォッチも参照だから先にnullが入っちゃうわけ
デバッガ通すと挙動が変わるってのは少なくとも開発に優しくはないと思うよ
なんでみたいな事言ってたのか判った気がするわ
$relationsがキャッシュの入れ物なのに他のプロパティ監視しててもブレークする訳ないさ
一度Modelのソースを読んだ方がいいよ
俺は355じゃないし
ソース読まないと使えないようなフレームワークなりライブラリは
そもそも使う気にならんという
ごくヘタレなプログラマでしかないよ
Laravelの開発者もユーザーに「一度ソース読んでみたら」
なんて平気で言うような「情強」じゃないことを切に祈るわ
まあでも元MSの人なんだっけ？
じゃ典型的な「情強」（）なんだろうなきっとw
あればそれを使いたい
この問題にどう対処するかの実際のとこが知りたい
ってことでざっと Eloquent/Model.php まわり読んでみたけど
の解釈であってるように見えた
__get をオーバライドして、メソッド setAttribute を呼び出してる。
setAttribute内で呼び出しプロパティ名をメタプログラミング的にメソッド呼び出ししてる。
hoge->user; だと user() が呼ばれるようになってる。
それがたまたま以下の様な リレーション定義だと BelongsToオブジェクトが戻されてる(Userじゃない)。
fucntion user() { return $this->belongsTo("User") };
protected な $relations って変数もあってリレーション作る度に そこに配列として格納されてるけど、
以降 hoge->user にアクセスした際は、$relations は見ずに やっぱ単にプロパティにアクセスされて
先述のBelongsToオブジェクトが戻ってるように見える。
っていうか hoge->user にアクセスした際に、その都度、 $relations の中身を戻すのって
原理的に出来るのかな？
もっというとプロパティを呼んだ時に、メソッド呼び出しに置き換えられるのかなって話になるのか。
でもそれ出来るなら みたいな問題おこらんよう気も・・・
hoge->user というプロパティ形式じゃなくて
hoge->user() で必ずメソッド形式で呼ぶといいのかも
副作用があるかもしれんがｗ
それは大丈夫だろうなあ
検証してないけど
書かなくても動くのと、動かないのがあるのは何でなんだぜ？
他の主流な言語の名前空間とだいたい同じだし
変数名にクラス名を入れてnew $class_nameなんてやるときは
フルパスを入れないとダメなんだよな
かなりもにょる仕様だと思った
ttps://pornel.net/phpns もしかしてエイリアスが定義されているかどうかって話？
ttps://github.com/laravel/laravel/blob/master/config/app.php#L163-L194 カスタムコマンド作ったりすると、結局書かないと動かないでしょ。
どっかで他にも設定するところあるの？
試しにディレクトリ全部ftpでアップロードしてみたけど動かなかった
herokuを使ってみます
まさかapp/storageのパーミッションを設定してないとか
すみません、凄い遅レスなんですが、返信ありがとうございます。
LaravelはPHP5.4以上が必要
XPとかのサポート切れとはまた意味が違う気がする
安定しててセキュリティに問題がなく新機能が不要なら
ずっとそのまま運用して別に問題ないんじゃね？
移行にあたって互換性の問題がある？そもそも無料なんで我慢してね、って話でもあるし
そもそも無料なんだからサポートってなにそれ美味しいの？って話でもある
わざわざ調べていただきありがとうございました
ちょっと調べた範囲じゃcronの話しか見つからなかった
誰かが 記述はそのままに、 Windowsのタスク機能を呼び出すようにするプラグインは書いてくれるかもだが
Windowsでも日に一度より多いタスクを定義できるようだが
普通にやってできないのは痛いな
あと5分置きとか可能なのかはわからん
いや、調べてないから全然わからんけど。
とかって需要だと
アクセスされたタイミングでしか動かないのは困るな
Windowsサーバなんて排除の方向なら
それはそれで異論ないがね
本やサイトやVagrantやら、みんな入れたら5になっちゃうんですが…
4.1 まででないと動かないとこ多いよな・・・ムカつくぜ
でも 普通に composer.json で Laravelのバージョン指定すればいいだけじゃね
タスクをひとつずつ登録するんじゃ楽しくないわけよ
5分ごとのcron一つ作ればあとはLaravel側で済む
ってのが売りだからさ
って話
すまん、少なくとも7以降ならできるようだな
お騒がせしたわ消えるわ
電子書籍は内容的に今一つだし・・・
流行るのかなLaravel・・・
っていう記事を見て使い始めたけど
使いこなせない人が質問してる回数ナンバーワン
ってことじゃないのかと思い始めた
API見てもインターフェースだけで動作内容が書いてないし
困ったらドキュメントとかソース見ればいいし。
俺なんかはブログ形式のサンプルをgitから探してソース読み読み勉強した。
手取り足取り解説して欲しいけど、まあそれは書籍になってからって感じだね。
これとか
ttps://github.com/ytake/Tutorial.Laravel4 流行っているんですか？
実際には手抜きするために従わなきゃならないルールが多くて結構大変な印象
まあ慣れたら楽になるんだろうけど
その辺全部簡単に実装できる。
ルーティングもページングも簡単だし。
だけどが言うように手抜きの方法を覚えるのがめんどう。
「1から実装するよりは簡単だろ」と言われそうだけど、
慣れてる処理なんかは1から書いたほうが楽なことが多々ある。
特にブレードテンプレートなんかは地雷。
でも全体的に使いやすいよ。
慣れると何でもカスタマイズできるし。
まあViewには極力ロジックを書かないのがBest Practiceだから筋違いなんだけどさ
継承とかセクションの書き方も最初は厄介なものがあるけど
ちゃんと使うと凄い楽できるよね
参考になるレスありがとうございます
助かります
＞その辺全部簡単に実装できる。
ほとんどのフレームワークなら全部簡単に実装できそうだけど。。。
Ver5から、フォームは非標準になったようですね。
できれば日本語版がいいです。
URLや方法がありましたら教えてください。
用途や規模によってどれが望ましいとかおすすめしないとか
ある程度ドキュメントに指針がほしいわ
コントローラールートが楽だからってんで使い始めたけど
どうにも痒いところに手が届かずイライラするばかり
で、いろいろ検索したら「可読性を下げるだけ、使うな」の大合唱
そのうちなくなるかも、とか書かれてる始末
そんなもん初めから実装すんなっつーのよ
そんなことをいちいちドキュメントに書かれたら、ドキュメントの
質が落ちると思うぞ。
いろんな方法から最適なものを選択する力がないなら、チュートリアル
通りに開発を進めるのが無難だろう。
RailsはGithubに山ほどあったからすげえ助かった
なんでサイドバーやめちゃったんだ
スマホで見てる奴なんてほとんどいないだろ…。
むしろもっとサイドバーにメニューたくさん表示してほしいくらいなのに。
アコーディオン式にすらなってないとかかんべんしてくれ
もしかして: ブラウザの幅狭すぎ
目次は隠れたり折りたたまれたりしないで、ページの上か左にフツーに表示して欲しい。
{{ Form::open() }} で画面に生<form>タグ表示されるだがw
何がおまじないが足りない？
あう、速攻で自己解決www
もっとドキュメント読み込まないと
具体的にどんくらい遅かった？ 気になる
てか4でもデバッグモードやめれば早いんだが
5では常時compiled.phpを作るようになった
デバッグfalseでも重いってんなら知らん
Eloquentなんて、重すぎて使い物にならない。
納品後に「応答遅すぎだ」なんて言われたら、対応できないもんな。
むしろ他のどんなフレームワークより早いくらいだけど。
「2015年最新PHPフレームワーク（9つ）のベンチマーク」
ttp://blog.a-way-out.net/blog/2015/03/26/php-framework-benchmark/ メモリ512とか少ない環境でやってるんじゃないのかねー
会社の環境で動かすとfuelphpとかと大して変わらないんだけどな
そら速いわけだ
あのDAOみたいなORMはちょっと使う気にならんが
それなりに良い環境で動かせない場合はLaravelは勧められないな
２倍(Double)の読みにくさを！
待ち望んでいたフレームワークだ
早速slimから移行しよ
試してみた？
ある程度感触がつかめたらインプレよろ
直でLaravel使うのに比べて
どんなメリットがあるのかいまいちわからん
ぐぐると即効で解決策見つかるのがすごいな。
日本語の解説はほとんどないけどｗ
laravelと比べてのメリットとなると軽いことぐらいなんじゃね？
複雑で覚えにくくて初心者が扱いにくい言語という印象。
１０年以上争い続けてるスレがあったはずだからそっちでやるといい
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
クソ遅いし。
もう休めよ
世界中の名だたるwebサービスで使われてる。
それをいうならJavaScriptなんて糞の極みだが、こうなったら使わざるをえない。
農家がコメを作るのに水田作るのと一緒だ。
めんどくさいが実りのためには作るしかない。
本は気になってるけど、出すの遅かったな。
もうだいたいの使い方覚えちゃったよｗ
確かにXSSについては早く直したほうがいいのだろうけど、
他人の記事の正誤表について上から偉そうに言う暇があったら、
自分のサイトのCSSのズレなおせ。
いろんなブログとかの評判曰く中級者向けって感じ。
他のフレームワークとか使ってた人がなんとなくを把握するにはいいかもだけど、
俺のようなド素人にはあんまり良くなかった。
全体的に見辛いし、サンプルのコードもバグあるし
普通こういうのは入門編とか、初めての…とか、初心者向けとかが一番売れんのに。
何か解決策ない？
実際使ってるかも怪しい
う～～～、あーーりーん！！
4とかわならい？
著者には悪いが、Ｗｅｂのマニュアル読んだほうが１００倍マシ！ と思った。
laravel3の頃からEloquentの処理内容はあまり変わってないんだな・・・
viewcomposerは使ったほうがいいぞ
DLして使う前に削除した。
あんなにでかいと、フレームワーク絡みのトラブルの時、
追っていくのしんどいだろうが。
開発では自前で全て用意する系じゃなきゃ使えないし
そもそもFWの挙動が追いやすいとかならCIとか使うべき
CI3は知らないが、CI2は実装すかすかで追いやすかったぞ
フレームワークによくあるオーソドックスをバランスよく組み合わせてるだけ。
そんなところが海外で人気の理由なんだろうけど。
ただManualが糞だから初心者には何のこと言ってるのか理解するのが困難。
全く優っているところがない。
・沢山の人が偏った意見を一貫して支持する
偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法
・不利な質問をさせなくしたり、不利な質問には答えない、スルーする
誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法
偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い
靖国参拝、皇族、国旗国歌、神社神道を嫌うカルト
10人に一人はカルトか外国人
「ガスライティング」で検索を！
コントローラーでやっていいの？
でもPOSTされたデータ自体はモデルと＝ってわけじゃないからコントローラーでやるってのもアリかなと思った
POST値のバリデーションとモデルのバリデーションは別ってのも合理的っちゃ合理的
ただ 書く場所がバラバラになるのはイヤだから 結局 モデルにバリデーションルールのリストを書くようにしちゃったけどね
withErrorsやら$validator->messages使ってViewにエラーメッセージ渡すってのが
公式の使い方でしょ。
考えすぎなの？ 普通がわからん。
自分で使えるようにpostやらcommentなんてモデル作れば同じように使えるで
例えば$ret=￥post::createと$ret->fillの間で￥post::whereとかやってもいいの？
いつの間にかCollectionになってないか？
ドキュメントによればArrayのはずで
以前は確かにArrayだったと思うんだが
return view('ビュー名')->with(compact('配列名'));
という感じでmodelからbladeに配列を渡してるんだけど、幾つかのカラムの値が渡らないんです。
説明下手ですいません。
コントローラでmodelから取得した配列をbladeに渡しています。
public $layout = 'template';
こんな風に渡すといいよ
$this->layout->content = View::make('ビュー名', array('results' => $results, 'arg2' => $arg2));
この場合$resultsが配列の場合は
@foreach($results as $val)
ごにょごにょ
@endforeach
みたいな感じで取れる。
ありがとう。
１. $templateを定義して、￥View::makeの戻り値をcontentsに値を代入している理由
２. ￥View::makeを使う理由
がわかりません。
contensにブレードが生成したhtmlが入ってるよということでしょうか？
レスありがとうございます！
debugbar入れてみた。
IDE使ってるからこういうブラウザに機能追加されるようなデバッグツールの使い道がよくわからん。
クエリビルダだと実行されたクエリがわからないので、それが気軽にみられるようになるとこは気に入った。
Debug::info();で出力するってことでしょうか？
意味は使ってみたらわかる。
まずやってみるよろし。
上の例ではtemplate.blade.phpで{{@$content}}って書けばあとは作成したビューで値が取れる。
View::makeでビューの作成と、ビューに渡す配列を同時に設定してんだね。楽だね。
つまり「ビュー名.blade.php」で@foreach($results as $val)とかすればいいってことだね。
ヘッダーとか、フッターとか、ビュー作るごとにわざわざ付けるの面倒でしょ。
全部テンプレート経由で設定しとけば、変更も楽よ。
すごい！
テンプレート作る理由の解説、滅茶苦茶分かりやすくて涙出そうです。
ありがとうございます。
ただやってみたのですがうまくはいきませんでした。
環境はlaravel5で、上記例の$this->layout->content = View::make(…とするとプロパティがないようでエラーが発生します。
予めtemplate.blade.phpに何か仕込んでおく必要があるのでしょうか？
PostController.phpを作る。
class PostController extends BaseController { //
ttp://example.com/post public $layout = 'template'; // これtemplate.blade.php
public function getIndex($id) // getで
ttp://example.com/post/<id>でアクセスした場合 {
$results = Post::where('id', $id)->get(); // 適当にPostモデルで定義したデータベースから値取得
$hoge = "hoge"; // 解説のために、こんなパラメータも追加
$this->layout->content = View::make('post', array( // ここでpost.blade.php
'results' => $resultsCashe,
'hoge' => $hoge
));
}
template.blade.php作る。
//なんか適当にヘッダーとか
{{@$content}}
//サイドバーとかフッターとか
post.blade.php作る。
@foreach($results as $val)
e($val->post_title); //例えば投稿のタイトルとか出力
@endforeach
全体こんな感じ
「'results' => $resultsCashe,」じゃなくて
「'results' => $results,」ね
として取得したオブジェクトをビューで表示すると
@foreach($results as $val)
{{$val->カラム名}} ・・・表示できない(値がnullになっている)
{{$val['origin']['カラム名']}} ・・・表示できる
{{$val->created_at}} ・・・表示できる
@endforeach
{{$results->render()}} ・・・表示できる
という結果になりテーブルの値がビューに渡せません。
created_atはcarbonという仕組みのおかげで表示できているだけのようです。
例えばコントローラ側を$results = モデル名::all()->where(条件)->pagination(１ページ表示件数)->toArray();
とすれば普通に連想配列で値は取れますが
@foreach($results as $val)
{{$val['カラム名']}} ・・・表示できる
{{$val->created_at}} ・・・表示できない
@endforeach
{{$results->render()}} ・・・エラーが発生してしまう
今度はページネーションが使えなくなってしまいます。
どうやるのが正解なのでしょうか？
普通にViewsタブ内の各ビューをクリックすれば、そのビューの持ってる変数見られるでしょ
>508さん
完全に理解できました！ありがとうございます。
用途としては画面共通で使う検索条件のプルダウン用配列なんかをtemplateで読み込んでおくような使い方でいいのでしょうか？
ありがとうございます。
私の環境だと配列を渡すと配列名しか見えません。
上で書いたとおりヘッダーやフッターを設定しとくのが一般的だろうけども。
例えば特定の画面で、メニューバーの表示非表示をコントロールしたいとかの場合は
$this->layout->menubar = View::make('menubar', array('flag' => 'ｔｒｕｅ'));
みたいにすればフラグも渡せるし。
まあなんていうか、自由ｗ
510の件まだ解決できず悩んでいます。
ビューに渡したコレクションからアロー演算子でテーブルの値を取得し、さらにrender()でpaginationを生成するにはどのようにしたらよいのでしょうか。
2ちゃんねるの皆さんのお知恵をかしてください。環境はlaravel5です。
最初の$val->カラム名で値が取れないのがおかしい
その$valが何なのかもう少し調べてみばいいんじゃないかな
get_class関数でそれがどのクラスのオブジェクトなのか調べたり、単純に中身を表示させたりとかさ
中身はdd関数で表示できたかな
モデルはこんなかんじで
$results = Post::orderBy('id', 'desc')->paginate(10);
ビューは
{{$results->links()}}
ってな感じでできない？
ありがとうございます。$valの型について調べてみました。
$results1 = モデル名::orderby('created_at','desc')->paginate(PER_PAGE);
$results2 = モデル名::all();
$results3 = モデル名::all()->paginate(PER_PAGE);
$results4 = モデル名::all()->forPage(1,PER_PAGE);
とした場合、それぞれの型は下記の通りでした。
$results1 ・・・ Illuminate\Pagination\LengthAwarePaginator
$results2 ・・・ Illuminate\Database\Eloquent\Collection
$results3 ・・・ staticメソッドが無いというエラー
$results4 ・・・ Illuminate\Database\Eloquent\Collection
さらに$result1,$result2,$result4をコントローラで
foreach($resultN as $val)した時の$valの型は
$results1 ・・・ App\モデル名
$results2 ・・・ App\モデル名
$results3 ・・・ -
$results4 ・・・ App\モデル名
となり、$val->カラム名では値が取得できませんでした。
ブレード側で{{ $val->カラム名 }}とした場合は値は取得できず
{{ $val['original']['カラム名'] }}とすることで値が取得できました。
難しい。。。
ありがとうございます！
links()はlaravel5からrender()になったようです。
とはいえ同様のことをやっているように思うのですが
うまくいきません。。
例えばPostというモデルを作る場合は、こんなかんじだよ。
class Post extends Eloquent {
protected $guarded = []; // 複数のカラムからデータを取得するため
protected $table = 'posts';
}
protected $table = 'posts'は省略可能だけど、自動でモデル名+sになるから注意。
データベースについてはちゃんとモデル名に対応したテーブルがあること、
配列で返って来るだけの複数の投稿があることを確認かなぁ。
っていうか$val['original']ってのがさっぱりわからん。
たぶんどっかで凡ミスしてる。
> ブレード側で{{ $val->カラム名 }}とした場合は値は取得できず
> {{ $val['original']['カラム名'] }}とすることで値が取得できました。
モデルにおかしなミューテーターを書いてるだけのように見えるが
ごめん はミューテーターじゃなくてアクセサーだ
original 経由で正しい値が読み取れるのなら
アクセサーかアクセサーを呼び出すどこかに問題があるんじゃないかとね
>520、521、522さん
ありがとうございます！！
原因が判明しました。どうやらモデルにカラムと同名のプロパティを定義したことが原因だったようです。
ガード、ミューテタがヒントになりました。
「ここはあってるはず」ってのが一番の天敵。
アドバイスありがとうございます。
一般的に使われる言葉なの？
アクセサーのことを
ゲッター/セッターの両方をさす場合（rubyとかrubyとかrubyとか）もあるから、
少しややこしいけど。
arrayじゃなくCollectionを返すようになったんだな
しかしQueryBuilderのlistsはarrayのままという謎仕様
こういうのホントやめてほしいんだがな
海外でも活発に情報がやりとりされてるし。
あんま素人が手を出しにくいってのもあるかもしれんけども。
てかララベルを業務に採用している会社なんてあるんかｗ
に興味を持ち始めました。
Laravelって良いですか？
10年以上運用保守するシステムにも安心して使えますか？
CodeIgniterから乗り換えた方、Laravelの良さを教えてください。
WordPressみたいなもんだよ。ころころ更新される。
良さはコンポーサーとか、restfulなモデルとか、OAuthとか、新しい技術をどんどん取り入れること。
だから長期運用が目的なら向かないだろうね。
ちなみに10年同じバージョンで運用保守可能なフレームワークなんてないから。
CentOSですら無理じゃね？ｗ
最初は戸惑うだろし、混在したコードを書いてしましがちだが、徹底して分離するべし。
もうcodeIgniterには戻れん。
ttp://hello.2ch.net/test/read.cgi/lic/1437239772/l50
laravel5に使ってます。
publicディレクトリ配下に実ディレクトリを配置したいです。
例えば、下みたいに特定のディレクトリ（今回は、pc）だけに聞く外部ファイルを置きたいです。
/laravel/public/pc/common/hoge.css
デフォルトだと、実ディレクトリがあれば、アクセス時に403になってしまいます。
nginxのtry_grepでディレクトリしていしてないからかなと思ったのですが、そもそも指定されてる。
publicディレクトリのパーミッションも755
外部ファイルと、アクセスするディレクトリを完全に分けてしまう事も考えましたが、
HTMLが出来上がってしまったので、できれば現状のフォルダ構成を保ちたい。
何か良い方法は無いでしょうか？
↑
これの意味が何回読んでもわからんｗ
聞くが「効く」でも「きく」でもさっぱりわからん
内部でpublic以下のファイルを指定したいだけなら、そんな関数が用意されてるでしょ。
ありがとう。そして申し訳ない。
>特定のディレクトリ（今回は、pc）だけに聞く外部ファイルを置きたいです
外部ファイルはcssだと思って聞いてほしいです。
全てのページ用と、特定のページ用のcssを用意していて、
pcディレクトリだけ使いたいcssは、同じ階層のディレクトリにcssファイルをおきたいです。
例えば、
/index.html はcommon.css(共通)だけ。
/pc/index.htmlはcommon.cssとpc.css(特定)を読み込む。
ということをしたいです。
こういう場合、下みたいなファイル構成でhtmlを書く事があると思います。
/index.html
/common.css
/pc/index.html
/pc/pc.css
これをlaravelでもやりたかったので、
rootファイルには、
「/」、「/pc/」にアクセスされた時に個別のviewを見に行くように処理を書き、
スタイルファイルは相対パスで読めるように、public配下に「common.css」と「pc/common.css」を置きました。
この状態で、
ttp://(ドメイン)/pc/にアクセスると４０３になってしまう状態です。 >内部でpublic以下のファイルを指定したいだけなら、そんな関数が用意されてるでしょ。
assets関数を使えばできるし、使わなくても可能なのは確認しました。
悩んでいることは、設置したディレクトリ配下のページにアクセスすると４０３になってしまう事です。
「common.css」と「pc/pc.css」ですね。失礼しました。
普通に/common.cssと/pc/pc.cssを読むのではダメなの？
てかファイル名違うならフォルダ分ける意味もなくないか？
これじゃあかんの？
これで403なるならnginxだっけ？のリライトらへんが間違ってる。
もしかして、public配下のディレクトリにページを作って、アクセスしてんの？
それなら、そもそもLaravelを勘違いしてる
初歩的な事なのですが、画像やcssやjsはpublic配下以外の場所に置くのでしょうか？
publicがlaravelのドキュメントルートだと思って、public配下にファイルを置いてます。
話を聞いていて、今のhtmlの組み方がlaravelに合ってないんじゃないかと思えてきました。
他の人はどうやっているのだろう…？。
マークアッパーから上がって来るhtmlはLaravelの事なんか考えていないでしょうし。
>普通に/common.cssと/pc/pc.cssを読むのではダメなの？
相対から絶対に変えるのは可能です。それで、cssを読むことは出来ました。
外部ファイルは設置して読めるのですが、/pc/にviewを作って（rootファイルに「/pc/」アクセス時の振舞を設定して）、「/pc/」にアクセスが出来ません。
>てかファイル名違うならフォルダ分ける意味もなくないか？
分けたのは、あくまで個人の主義です。
HTMLを組むときに、個別のディレクトリしか使わないものを一色多にしてしまうと（自分は）管理しずらいです。
また、外部ファイル読み込み用のディレクトリを別途用意（例えば、pc/pc.cssではなく、common/pc/pc.css）にするでも良いかと思ったのですが、
この問題がある事は予想していなかったので自分の調査不足です。
>public_path(pc/pc.css)これじゃあかんの？
なるほど。publicディレクトリのパスを取得する関数ですね。
ただ、今抱えている問題と少し違うかもしれません。
cssのパスの通し方に困っているわけではないのです。rootファイルのルーティング（？）で迷ってます。
pubilicディレクトリ内に実ディレクトリを作ってしまうと、そのディレクトリ配下にルーティングすると403になることを解決したいです。
>もしかして、public配下のディレクトリにページを作って、アクセスしてんの？
それは「publicディレクトリ配下に静的ページを置いてるか？」という事であってますか？
それなら、やってません。viewかcontorollerでしか、表示を作ってないです。
viewはhtmlを作るためのテンプレートであって
htmlそのものじゃない
Laravelのbladeエンジンがviewファイルを読み取って
それを変換した結果のphpプログラムがwebサーバに渡され
そのphpが（普通と同じように）htmlを吐き出すわけ
publicはあくまでも通常のサイトルートであって
そこにはwebサーバ（NginX）が直接処理できる形のファイルを置く
具体的にはcssやjsだな
もちろんphpもwebサーバが処理できるファイルではあるが
publicにindex.php以外のphpファイルを置くのは
Laravelのルーティングとぶつかるからやらない方がいい
またblade.phpは拡張子こそphpでも
webサーバが処理できる正規のphpではないので
いかなる意味でもpublicに置くべきじゃない
.blade.phpは上に書いたように「phpじゃない」んだからな
viewはあくまでもresource/views（のサブディレクトリでもいい）に置いて
Viewクラスなりview()関数に専用のドット記法でパスを渡す必要がある
> nginxのtry_grepでディレクトリしていしてないからかなと思ったのですが、そもそも指定されてる。
もしかして: try_files
というか nginx の設定の問題であって Laravel は関係ないよね
>publicはあくまでも通常のサイトルートであって
>そこにはwebサーバ（NginX）が直接処理できる形のファイルを置く
具体的にはcssやjsだな
了解です。public配下にファイルを置く事自体は問題ないのですね？
ただ、自作phpやhtmlを置くlaravelの動作に影響があるかもしれないから辞めた方が良い。
ということですかね。
>またviewファイルをLaravelのルーティング経由で読ませようとしたってダメ
.blade.phpは上に書いたように「phpじゃない」んだからな
説明不足で申し訳ない。viewのテンプレートを吐かせる関数を噛ませて表示をしています。
別に、「（laravelの記述ルールを無視して）viewのファイルをインクルードしたけど失敗する。」
「PHPライブラリを作ってpublicに配下に置いたけどけど使えない。」
と言っているわけではありません。
>もしかして: try_files
すみません。try_filesの間違いです。
>というか nginx の設定の問題であって Laravel は関係ないよね
それも、そうだと思います。
何か話の取っ掛かりになればと思い書きました。蛇足だったかもしれません。
今やりたいこと（publicディレクトリ配下に実ディレクトリを設置できるようにする方法）を調べると、
nginxの設定を変える方法しか見つからなかったので試した事を共有したかっただけです。
laravelだけで実装する方法があるのであれば、ぜひお聞きしたいです。
ここがわからない
bladeを直接書くんじゃなくて
ある関数の出力がbladeの文法に従ったテンプレートになってるわけ？
具体的にどうやってviewを返してるの？
return view(some_function());とか
return view('pc/some_view.php/');
みたいなことをやろうとしている？
それとも
return some_function();
で、some_function()の返り値がbladeテンプレートとか？
ちなみにどれも動かないからね
>viewのテンプレートを吐かせる関数を噛ませて
みたいなことをしなくて済ませるための「テンプレートエンジン」なんだから
多分すごく無駄な労力を費やしてるんだろうな
>今やりたいこと（publicディレクトリ配下に実ディレクトリを設置できるようにする方法）を調べると、
ってのが何を指してるのか、全くもって理解できん。
public_path(pc/pc.css)でパスが取れるけど、アクセスすると403になるってこと？
それともpublic/pc/ディレクトリそのものにアクセスしたいってこと？
例えばnginxでServerディレクティブにこんなかんじで書いて、
root /var/www/html/laravel/public;
ファイルが存在しない場合はこんなかんじでphpを実行。
location / {
try_files $uri $uri/ /index.php$is_args$args;
} # location /
みたいにしとけば、普通動くと思うんだけど。
> laravelだけで実装する方法があるのであれば、ぜひお聞きしたいです。
だから Laravel は関係ないと言ってるじゃないｗ
> nginxのtry_grepでディレクトリしていしてないからかなと思ったのですが、そもそも指定されてる。
try_files にディレクトリを列挙しちゃってるから
index.php にフォールバックできてないでしょ？
pctop.blade.phpというviewファイルを作って、rootes.phpにView::make('pctop')と書いて読んでいます。
噛ませた関数というのが「View::make」です。
>public_path(pc/pc.css)でパスが取れるけど、アクセスすると403になるってこと？
>それともpublic/pc/ディレクトリそのものにアクセスしたいってこと？
前者の事をやろうと思っています。
nginxのコンフィグに、「$uri/」が無いから403ではじかれていると思い、書いていただいたコード同じ設定をするつもりでした。
ただ、今使っている環境のnginxコンフィグにはすでに書いていました。参考程度の話ですが、homesteadで構築した環境です。
読解力が無くて申し訳ない。てっきり、今の話はnginxの話だからスレちがいだよ？と言われてると思って、laravelに話をもどそうと思ってました。
>try_files にディレクトリを列挙しちゃってるから index.php にフォールバックできてないでしょ？
理解力が無くて申し訳ないです。
それは、優先順位の設定に問題があり、分岐処理をするはずのindex.phpに遷移する前に、
本来lravelが取らないindex.php以外のファイルにアクセスしてるんじゃないか？
と言っていますか？
そうそう
nginx の try_files ディレクティブの説明を読もう
具体的にはwithInput()がView::makeだと使えません。Redirect::toは使え、blade側でInput::old()で取得できました。
しかし今度はRedirect::toだとページネーションで次ページ移動すると検索条件がクリアされてしまいます。
バージョンはlaravel5です。
リダイレクトは302や301のステータスコードでHTTPレスポンスを一度返し
、クライアントからもう一度新しいHTTPリクエストが来るようにするもの。
その際、
ステートレスなHTTPではリクエストをまたいで状態（今回は入力）を保存できないので、セッションに一度格納し、次のリクエストで取り出せるようにする。
Laravelでそのセッションへの一時保存を簡単に実現するのがwithやwithInputの役割。セッションに保存した古い入力を取り出すのがInput::old()なわけ
対してView::make()はテンプレートを用いてレスポンスのbodyを作成するだけなので、リクエストをまたがない。そのリクエストの入力を取得するならInput::all()でも何でもいいし、
わけあって次以降のリクエストに入力を渡したいならwithInputではなく、明示的にセッションに保存すればいい
検索はサーバのリソースに変更を加えないのが普通だと思うので、クエリストリングが長すぎてIEの上限に引っかかるなどの特段の理由がないならGETにしたほうがいい
ページネーションの際の検索条件保持もより簡単だと思うが
普通にgetでurlにパラメータ渡して、$keyword = Input::get('keyword')で取れる。
レスありがとうございます！
それでは検索でGetを利用し描画時にフォームの内容を復元するには、ビューにどのように値を渡し、どうやって取り出せばよいのでしょうか？
検索条件が多いため簡潔な書き方にしたいです。
562さんの説明のお陰でリダイレクトの仕組みは分かったのですが、いつwithやwithInputを使うのかが分かりません。
ご教授頂けないでしょうか。。
まずはセオリーとしてどのように先人が作っているのか調べるべき。
特に検索なんて、誰でも実装するもんなんだし。
googleでlaravel searchでググって出たページ
ttp://stackoverflow.com/questions/19612180/creating-search-functionality-with-laravel-4 これみたいにして、$q = Input::get('myInputField');の$qをView::make()でビューに渡してもいいし、
テンプレート使ってれば$this->layout->keyword = $qみたいにしてもいいし。
ビュー側でurlも簡単にできる
{{$results->appends(array('keyword' => 検索ワード))->links()}}
ありがとうございます。
英語が苦手でstackoverflowとか海外の掲示板に辿り着くと
解決可能なことがわかるくらいで
なんとなく分かったような分からないような感じで
試行錯誤してるうちで出来てしまうことご多いです。
それって先人の知恵を生かしてるとはいえませんね。。
これから努力してみます。
ページネーションが生成するurlにパラメータを付けられるんですか！勉強になります！
画面からのリクエストをテンプレートに渡す方法ですが、フォーム一つずつでInput::get()で取り出すのではなく、Input::all()を渡してよしなに処理してくれるような方法はないでしょうか？
教えて頂いた方法で解決できました。
ありがとうございました！
□コントローラー
①$変数=Input::get('パラメータの名前')としてフォームの入力をコントローラーで受けとる
②View::make('ビュー名')->with('パラメータ名'=>$変数)->with(次のパラメータ)->with(次のパラメータ)としてフォームの値をビューに渡す
□ビュー
③<input type='' value={{ $変数名 }}>としてフォームの値を復元
④$ページネーションの変数->appends(['パラメータ名'=>$変数,次のパラメータ])->render()
としました。
パラメータが増減したときに①～④全てに修正が必要なことが不安ですがやりたいことはなんとか実現することができました。
Whoops, looks like something went wrongというメッセージをカスタマイズしたいのですが出来なくて困っています。
Googleで検索すると全く同じことをしたい人がいて、解決したようなのですが英語で書かれていて読めません。
ttps://laracasts.com/discuss/channels/laravel/change-whoops-looks-like-something-went-wrong-page どうも、resources/views/errors/{404,500}.blade.phpを作るといいというように書いてあるようなのですが、試してもエラーメッセージは変わりません。どうしてでしょうか。。。
出来ました！ありがとうございます！
方法はありますか？
ホスト名で自動判別したいんです。
オートロードってどういうことでしょうか?
こういう事
ttp://php.net/manual/ja/language.oop5.autoload.php これで作られるプロジェクト内にvendor入れられる設計が気持ち悪すぎ
なくなったり。
こんな大きな変更があったら怖くて使えないよ。
4からだから、他のバージョン知らないけど、
バージョンアップのたびにこんなんだと確かに使う気しない。
毎回こんな互換性一切ない感じでアップデートしてるんだろうか？
結構コード書き換えが必要なレベルの変更あったからなあ
5.1は一応ロングタームサポートで
2年だか3年は仕様を固定するというが
裏返せばその次はまた
変える気満々ってことかと勘ぐってしまう
そうだろうな。
Laravelの開発体制って、個人または少数人でクローズドな開発してるの？
その先はまた変更？？？
世の中に公開した仕様は、普通下位互換性を考慮するだろ。
文句があるならフォークして自力でメンテすりゃいい
laravelの場合、
同一サービスで、ユーザーサイト、管理者サイト、代理店サイト等を作る場合
その数に応じてプロジェクトを複数個作るのが一般的でしょうか
それともviewやcontroller直下にuser,admin,agent等のフォルダを作って
Routeで切り分けていくのでしょうか
アドバイスもらえると助かります。
viewsとかcontrollersの下は、好きな方針で整理すればいいと思うよ。
アドバイスありがとうございます。助かります。
既に特に問題なくサイト構築できるんだけど、買ってみる価値あるかな？
>年明けに本でるし
のソース教えてもらえる？
出版社: インプレス
発売日： 2016/1/8
ttp://www.amazon.co.jp/dp/4844339451 おお、早速ありがとう！
これは期待。
下記の条件が全て当てはまる会社にご注意下さい。
・IT系 in 東京
・転職会議で2.5点
・転職会議の「その他>2ch情報」の欄で過去の労基2chスレが表示される
来年はじめに出るなら、それ買うか。
できれば正月の暇な時間に読みたかったけど、しゃーないなｗ
dreamweaverを使いたいのですが、
dreamweaverで
SublimeTextやPHPStormみたいに
ide helperのようなコード補完は出来ないのでしょうか
正月休みの入門なら最近みつけたブログがいいかも
今日も更新あったし、ソースもgitで手に入る
つ larajapan
覗いてみたが、全然コンテンツないぞ。
更新止まっちゃってるけど、ララ帳超えるくらいじゃないとな。
Feedlyで新着通知があったから話題にだしたんだが
最新記事しか見てないんだろ
コンテンツの量もそれなりにあるし
site:検索でインデックスされてるページの量を見る限り、
www.larajapan.com → 27ページ
laravel10.wordpress.com → 321ページ
と、10倍以上の開きがある。
つうか、たかだか27ページ（インデックスページ含む）で、
「コンテンツの量もそれなりにあるし」って、
一体何のステマだよ。
ステマだと仮定しても何が悪いの？
ブログが書籍原稿で、読者が無料校正協力者になること？
書籍ってもう10年以上前から成り立ってないよ
MS-DOSの頃は俺なんかでも稼がせてもらったけどさ。文章かける技術者ってだけで需要があった時代
技術書なんて今、初版3000あるかな？
もう初版刷り部数まるごと印税くれる出版社もないんじゃね？ 知らんけど
それ以外＝ゴミ
ほっとくよろし
すまんかった。
「新刊の代わりに正月休みに読めるもの」をが勧めてたとして、
いや、それには分量が違いすぎない？ と思ったんで書き込んだ。
もちろんLaravelの新しい入門サイトが出てくるのは大歓迎だよ。
もしlarajapanの著者が俺の書き込みを見て不快に感じたのであれば、申し訳ない。
○ が勧めてたとして
今日発売か
見てこよう
と思ったら450ページもあるな。
技術書としてはこんなもんじゃね？
@forelse($arr as $key => $value)
//
@empty
//
@endforelse
みたいな時の@emptyの使いどころがいまいちわからない
一番JS書いてるときが楽しいとか異常だろ
JSめんどいわ、俺は嫌い
Angularでも使えばいいんだろうけど
細い部分は結局手で書くから
覚えることが増えるだけになりそうな気が
diコンテナフル活用
フレームワークのテストがきちんとある
疎結合にしやすいからテストコードが書きやすい
dbとか他のコンポーネントは好きなライブラリに入れ替えok
ファサードはfuelっぽく見えるけどstaticじゃないから
そもそもが全く違う
いっちょ最新の勉強するか！って上に出てた本買って読んでみたけど。
なるほどわからん。ということしか分からなかった。
俺には無理だわ。
フレームワークの初級でおすすめないですか？
上の本でわからないと、Laravelは向かないかもね。
日本語の解説本は全然でてないから。
俺は公式ドキュメント見ながら勉強したけど、最初結構つまずいた。
だけど、わからん単語、一つ一つググって読み進めればわかるべ
全くわからんなら、まずはCakePHPでもやったら。
初心者向けの本も腐るほどある
結果的にラクできなきゃ覚える労力が無駄なだけ
本を読んでもさっぱりわからんのでは
楽できそうかどうかの判断もできんだろうに
知らない単語がでると、苦手意識があるのがいけないですね。
5.2はこの書き方が非推奨になりました。とかサンプルに書いてあって、は？もう？？公式見ないとダメか？で、
公式見て更に分かんなくなって、あかん状態でした。
まずは一通り読んで触ってから決めたいと思います。
とりあえずオレオレフレームワークはフレームワークと呼べないレベルでした。。
そんなもんは全体から見れば些細なことだ。
まずは全体を俯瞰するようにザーッと読み進める。
で、2回目、3回目に読みなおすときに気になったら調べ直したらいいんだよ。
Slimとかがいいんじゃないかな
コンパクトで勉強のために最初にやるには
もっと大規模なフレームワーク勉強したいっていうならCodeigniterが
初見にはとっかかりやすいって聞いたことあるようなないような
てかLaravelのドキュメントでわからないってy
俺なんかもそこが好きなクチなんだが
あまりにも普及しすぎてここ何年かは
「もうちょっとキチンと集団行動のことなんかも
考えてくれないと困りますねー」
みたいな空気になってる気がする
Java的なスーツ着てタイムカード押してみたいな雰囲気ね
言語仕様そのものもそっち方面の拡充が著しい
典型的には引数の型指定がスカラー型でもできるようになったり
まともなクロージャーが使えるようになったり
Laravelはまさにそういう過渡期に発展してきたわけで
空気の変化をもろに受けてるように思う
最初の頃はPSR？どうでもええやんー
名前空間？ユーザーは気にせんでもよろしおまんがなー
みたいな感じだったのが
どこに出しても恥ずかしくないくらいに「キチンと」してきてる
でもそこが古いタイプの(なんでもアドリブでこなしてきたような)
PHPプログラマーには馴染みにくい要因なのかなと思ったりもする
まあ他のフレームワークもそのへんの事情は同じなんだろうけどさ
超長文失礼
PSR-4とclassmapのいい感じの使い具合がプログラマの妙だね
.
板違い（？）の上に、話をさえぎってしまいゴメンナサイ！(*_ _)人
でも、この板のユーザーさんにも有意義な告知かと思うのでカキコませてください。
★ 謝礼は十分いたします ★ アメブロなどのサイト制作ができる方！！
アメブロなどを使用してのサイト制作のできる方を早急に求めています！
私はリケジョやPC女子からはほど遠く、サイト作成にはまったく疎いのでとても不自由しています…(> <；)
そこで私に代わりサイトを作成してくださる方を求めてこの場をお借りしました。
■サイトの内容…
アダルト系、違法性、その他公序良俗に反するものではありませんのでご安心ください。
■サイト制作の仕様ベース…
アメーバブログで十分です。願わくばwordpressなどのブログ形式のサイトを希望します。
それに準ずるもので使い慣れたものがあれば別のものでも構いません。
■条件はありません…
技術さえお持ちでしたら、学歴・職歴等は一切問いません。
フリーター、ニート、高齢ニート、コミュニケーション障害をお持ちの方、引きこもりの方、中年失業者、長期無職等、歓迎！
■作業形態…
作業は在宅でやって頂くことになりますので、時間の指定は一切ありません。別のお仕事の傍らに…でもOKです。
■詳細をお知りになりたい方は…
下記メールアドレスまでご連絡ください。詳しく書いた返信文を差し上げます。
※真剣な告知です。冷やかしはご遠慮ください。
井 上
inoue1952w★gmail.com
迷惑メール対策のため＠部分を★にしてあります。
実際に送信する際には★を＠マークに変えてください。
.
.
どんどんコード肥大化していって何が何やらわからなくなる
それで別サービスにわけてAPI使ってなんたらとかもウザい
といってもフレームワークを使わず
素のコードでも嫌い
見てられない
結局何がいいたいのかというと
プログラミングなんて嫌いだってことだ
俺だってプログラミングするよりも、美人なねーちゃんと酒飲んでる方が好きだよ
「いかに楽した気になれるか」
という自己満足の部分が大きいな
その点Laravelはいい線行ってると思うわ
文法そのものは全部Cベースで基本同じ
違うのは関数群や標準ライブラリ、環境の類
JSやるなら嫌でもDOMやCSSのことは知らにゃならんし
PHPなら山ほどある(しかもまるで統一感のない)関数群のリファレンスが必須
少なくともLaravelなら読むのはグンと楽になるだろ
実際にメンテするのは慣れてる人じゃないと
確かに結構大変だと思うけどな
Laravelの書式を覚えるほうがずっと楽
フリーのフレームワークなんぞ馬の骨と本気で思ってたりするから怖い
そしてLaravelの開発者が元.NET開発メンバーと知ると手のひらを返したりする
まあそんな連中はそもそもPHPを使わんがw
言語機能の差があるからなあ。
たしかにLaravelじゃなきゃいけいない理由はないんだけども
日本は新しい技術を取り入れる柔軟性がないのかもね。
とかく学習コスト、ランニングコストを気にして現状維持でガラパゴス化する。
気がついたときにはiPhoneみたいな黒船に全部かっさらわれるという連鎖。
アメリカのエンジニアの倍くらい働いて、半分程度しか給料もらえないから、
そんな余裕もないのかもしれんね
片手間に学べるほど学習曲線の緩やかなものでもない
ガラパゴスなプログラマにとっちゃね
割合は忘れたけど、そんな制度があったはず。
一方そのころ日本では焼きそばを作らせていた
そんでちゃんと使えるようになると万能感ハンパないわ
一人でいきあたりばったりにやってるからDIやテストは活用してないけど
一人でもそのへんきちんとしたほうが本当はいいんだろうな
でもしばらくはサポートするらしいから、書籍化とか、勉強するなら今だよね
ガイドに従うだけであっさり移行できたんで
追従が大変という印象がほとんどないや
laravel-ide-helper入れても警告だらけになるのは嫌よね
実装上変え辛い部分だろうし、6辺りで対応してもらえるといいな
最近ってのは5.1とか5.2の話ね
なんか、ピクニックみたいな楽しいリズムがあるよ。
コードイグネイターやら、ケークなんて響よりずっと良い。
...->union($users)->where('id','1');
というように書いてunionで結合した後にその結果を
条件で抽出したいのですが、
投げられているSQL文を見るとなぜかwhere('id','1')されてから
union($users)されています。
これはクエリビルダーの仕様なのでしょうか？
Laravel的なやり方からするとそういう場合
クロージャの中にUnionを入れることになりそうだが
実際selectにクロージャを入れられるかどうかは知らない
$table->increments('id');
$table->integer('user_id')->index();
$table->foreign('user_id')
->references('id')
->on('users')
->onDelete('cascade');
$table->string('mouse');
$table->string('keyboard');
$table->timestamps();
});
こんな感じのプロフィールを作成しようと考えています。
protected $fillableの場合は、mouseとkeyboardだけで良いと思いますが、
protected $guardedの場合は、どれを指定しておけばよいのでしょうか？
（mouseやkeyboard以外にも追加するとき、いちいちfillableに追加するのが面倒なので）
timestampsなどは自動的にguardedされていませんよね？
このへんの詳細がドキュメントなどに載っていなかったので質問させていただきました。
Modelのブート時とかにDB参照して自動的にカラム名持ってくるのはできなくもないかな？
初期設定の値からして、guardedプロパティをワイルドカード、fillableプロパティを最小限で使うのが暗黙的な推奨。
その上で利用の都度、値を1つずつ代入するか、Model::fillable()メソッドを呼び出してfillableを上書き・複数代入できるフィールド名を明示的に指定するかが安全。
と言っても利便性と安全性はトレードオフなので、
1つのモデルに対して複数の新規登録、更新アクションがない場合はfillableプロパティ直指定で済ませる、といったところ。
たまにfillable指定し忘れてキーってなるのは安全のためと思って我慢
とりあえずはfillableでいこうかと思います。
$table->increments('id');
$table->integer('user_id') ->unsigned();
$table->string('mouse') ->nullable();
$table->string('keyboard') ->nullable();
$table->timestamps();
$table->foreign('user_id')
->references('id')
->on('users')
->onDelete('cascade');
});
上記のprofilesテーブルに、ユーザー登録時に同時作成（mouseとkeyboardはnull）するにはどうすればよいでしょうか？
profile用のフォームなどは用意せず、ただ単にregisterでユーザー登録された際に、user_idとtimestampsが挿入されるようなシステムにしたいです。
{
parent::boot();
self::created(function($user)
{
$profile = new Profile();
$user->profile()->save($profile);
});
}
このコードぶっこんだら出来ました。失礼しました。
実際のファイルの物理的な場所は
下位のドライバに任せるという発想
結局は！マーク無しと変わらないんですかね？
どちらが正しいのでしょうか？
ないとエスケープする
海外から完全に取り残されてる感じ
一流なハズの人たちがそれまでの資産もあって Laravelになかなか移りたがらない
日本発なサービスがあんまない、あってもパチンコの市場くったソシャゲばっかりなのは
こういう保守性もあるんじゃないかと思ってしまった
乗るしかない このビッグウェーブに
orで三項演算子になるはずが、なぜか1と表示されてしまう（データベースに存在しているのに）
{{ old('name') ? old('name') : $user->name }}
こっちは正常に動作
教えてドラえもん
デザイナーあがりの自称エンジニアでも作れるかと
or は論理演算子よ
評価対象の値をそのまま使いたい時は a ?: b
{{ isset($name) ? $name : 'Default' }}
は
{{ $name or 'Default' }}
のように書ける。
逆に言うとorの左辺はisset()に噛ますことのできる変数じゃないとダメ。
storage/framework/views下にbladeが吐き出したphpファイルがあるから見てみるといい。
{{ $name or 'Default' }}
の場合
<?php echo e(isset($name) ? $name : 'Default'); ?>
に変換されるけど
{{ old('name') or 'Default' }}
の場合
<?php echo e(old('name') or 'Default'); ?>
に変換される。
変換されたあとの「or」は の言う通り論理演算子。
old(’name’)がnullだろうがなんだろうが右辺がtrueなので結果はtrue。 echoで暗黙的にtrueが1に変換されて出力される。
と、いうかoldの第二引数にデフォルト値渡せるから
value="{{ old(’name', $user->name) }}
とするとプリティー。
ありがとうございます、感謝感激です。
CakePHPよりLaravelの方が簡単なの？
5.2はLTSじゃないから、すぐに保守されなくるし。
新しく作るときは、ドキュメントを斜め読みして、勘所を理解する。
そういった知識より、知恵みたいなのが求められるのかも。
その点、Laravelは音速で日本語化してくれる神がいるから心強い。
LaravelでWebサービスを一から作れる人は、そんなの慣れっこかもしれんけど。
初心者向きではないね。
そうでないなら手を出すべきじゃない
オレオレ作ってみたくなる
alpha_numやemailが使えないので
あ、速攻で自己解決したった
publicじゃなくprotectで定義すりゃいいだけか
どっち使うか迷ってます
別にフレームワーク間の違いなんて気持ち違うぐらいだろ
cakeを勢いで超える日は来るの？
機能面で言えばSymfonyなんだろうが、
YMLとアノテーションの重厚長大な作りが疲れるんだよね
手間に合わないというか現実的じゃないというか…
それがLaravelに移行した理由
rulesのuniqueにどう除外idを引き渡せば良いのか分かりません
teamsテーブルのチーム名(name)を更新する構造です。
public function rules()
{
return [
'name' => 'required|unique:teams,name,'.$teams.'|max:20',
];
}
putでteams\{$teams}に渡していますので、$teamsを参照できると思ったのですが
どうにもLaravel5では対応していない模様です。
どなたか教えて下さい...
発想の根本が間違ってる気がするが・・・
BasseCotrollerでrules定義を置換してるな
unique:user,email,{email},user_id
とか書けるように
↓なの作っておくといろいろ使える
/**
* 文字列中の {id} を$model->id で置換
*/
protected function replaceKey($str, $model)
{
if (preg_match_all('/\{([^}]+)\}/', $str, $matches, PREG_SET_ORDER))
{
foreach($matches as $m)
{
if (isset($model->{$m[1]})
{
$str = str_replace($m[0], $model->{$m[1]}, $str);
}
}
}
return $str;
}
スマホで書いたからタイポしてたらすまそ
まちがえた
unique:user,email,{user_id},user_id
policyのcreateメソッドには必ず第二引数の設定が必要なのでしょうか？
ダミーとして第二引数にBook $bookを入れて単純にtrueを返すだけにすれば、認可は成功しました。
//BookPolicy
public function create(User $user)
{
$book_count = $user->books()->count();
if ($book_count <= 3)
{
return true;
}
return false;
}
//book controller
public function create()
{
$this->authorize('create');
return view('book.create');
}
ログイン中のユーザーの本の数をリレーションでcountして、そして3冊以下ならtrueを返したいです。
$router->model('user', 'App\User');
が使えない？
この使用許諾契約書には書かれています
”最後にあなたのコンテンツを含む個人データ（例えばあなたの電子メールの内容や―プライベート通信やプライベートフォルダ内のファイル）にアクセスし―開示し保全します”
開示する ここ重要だよ
契約がなければ通常 高度な違法行為になりうることです それはあなたが自分の意思としてこの契約書に同意したのです
ttps://www.youtube.com/watch?v=ZBwEmgdqB1c 「１９１０」 副島隆彦 ２０１６年６月１６日
大阪市や大阪府のバスの運転手が年収1000万円は許せない、600万円まで落とすと。
なぜなら、普通の労働者たちが年収400万円でようやく働いているのに、何でバスの運転手が1000万円ももらえるんだと。
このものすごくすばらしい主張があった。
これを言われると日本の民主党や共産党は非常に困るんです。
が、先ほど言ったように、金持ちたちの財産を相続税で国家が奪い取る、これを正面から本気でやったらほんとに橋下はたたき潰されました。
労働組合を押さえつけるまでは安倍晋三たちも大好きだからよかったんだけど、
自分たち自民党体制の、金持ちと地主階級、経営者を大事にするという自民党の基本骨格があるわけです。
Vue.jsとの統合がどうなってるのかは気になるな
ElixierにしろVue.jsにしろデフォでpackage.jsonに入れる必要性が理解できない
フロントエンド開発に任せるべき範疇だろ
Vue.jsってObjective-C初めて見たときみたいにひょぇぇぇ～ってなるから、まだみたくないな
そこが組み込まれるのはありがたいわ
アングラーとか覚えるのと自分でゴリゴリ書くのと
どっちが早いか迷って後者を選んで泥沼化したりもしたし
フロントのコードにもLaravelなりのベストプラクティスを提示してほしいと思ってた
5.0からは@yield使ってるから今はこっちが主流でいいのか。
小から中規模まで、少人数で構築するSEO気にしないWebアプリケーション構築するなら充分対応できます。実装としてはLaravel関係ないけど、pagekitの実装が参考になるかと。
まぁ、ただ日本自体SPA前提の案件てなかなかないよね。
ただサーバサイドエンジニアがフロントエンドもガッツリ攻めていくのはかなりの体力がいる
流石に今からAccessでやる選択はないし
じゃあVBとかVCにMSSQLでやんのかつったらそれもまた（Windows自体の将来性に疑問符）
ということでいっそWebアプリでっていうのはごく自然な流れだと思うんだけど
実際やるとフロントエンドが大変すぎて死ぬよね
Access並みの手軽さでサーバサイドとデータバインドできるUIコンポネが一揃セットになってれば
一気に広まる可能性あると思うんだけどな
HTMLやFormのファセットをオプション化した流れはその逆のようにも思われる
2年経たずに手の付けられない負の遺産となる
あとは受け入れられるかどうかと、キャッチアップが遅すぎるみたいな老害のプライドをいかに刺激しないように説得するか。現場の手腕次第だな…
バカほど声が大きいからな
嫌味を返すなら全力注いでる=なりふり構わず生き残りに必死
ってところだけど
確かに現状のASP.NETは十分選択肢になりそうだな
サードパーティ製の業務アプリ向けUIコンポネなんかも
歴史が長いだけあってそこそこ整備されてるようだ
業務用ならゲイツプラットフォームという根拠のない思い込みも（発注側に）根強くある
こうなるとこの分野へのLaravelの浸透は難しいかもな
Vueも2.0でSSR対応できるみたいだけど、実用では使えないと思う。まだ1、2年かかる気がするし、時が経てば経つほどSEO目的のSSRは考えなくても良くなるだろうし。
今後バックエンドでは、いかに使いやすいAPIを作るかってとこが注視されていくんではないかと。
そこの領分がきっちり別れるようになると、バックエンドもフロントエンドも幸せにはなると思うね。理想論かもしれないけど。
今更のレスだがjQueryでBootstrapな基礎はもう変わらないんじゃね？
それこそASP.NETも（フロントはC#捨てて）そうなってるみたいだし
・コンソールでphp artisan cache:clearとか、自作コマンドでCache::forget呼んでもキャッシュが削除できない。同じキーで取得はできる
・routes.php内で同じソースを実行すると取得も削除もできる
これって何が原因だろ？console経由だと読み込まないconfigとか実行ユーザの違いとか？
apc.phpでキャッシュクリアできるかどうか試す。
できた場合→apc.phpで実行しているコードをコピペ。
できない場合→わからん。
> 同じソース
というのが幻想
> 実行ユーザの違い
でしょ
全ページ、ルーティングしなくちゃだめなの？
静的ページが１００ページくらいあるんだが。
publicに静的ページ置こうか考えたけど、viewテンプレートは使いたいから却下。
ちなみにver5.1。
誰か分かる人ご教授ください。
それでなんとかならないようなら
そもそもフレームワークを使う意味が不明では
そもそも使うの初めてなら、まずは他の人がどうやって似たシステム組んでるのか調べる方が良いよ
勉強には先人の知恵に習うのが一番
丸２日くらい検索したけど出てこないんだ。最後の砦としてここで聞いてる。
ひとまず、ルートパラメータでやってみたけど、
//通常のルーティングされなかったら以下実行
//static html
Route::get('/{url1?}/{url2?}', function ($url1 = null, $url2 = null) {
//home
if (!$url1 && !$url2) {
return view('welcome');
}
if (!$url2) {
return view($url1 . '.index');
} else {
if (view()->exists($url1 . '.' . $url2)) {
return view($url1 . '.' . $url2);
} else {
return view($url1 . '.' . $url2 .'.index');
}
}
});
こんなでいいのかな？
第二階層までしか対応出来ないのがアレだけど。
もっといい方法あったら教えてください。
もっといい方法といってもなあって感じ
そもそも大量の静的ページってのが根本的に合わないわけで
bladeテンプレを使いたいっていうからには少なくとも「ある意味」動的ではあるはずだと思うんだけど
動的に変わる内容が何一つ整理できない（全てを個別に扱うしかない）なら
もうそれ以上やりようがないんじゃないかと
こんなんでどう？最後のスラッシュが$_SERVERからしか取れないのが残念なところだが。
Route::get('/{url?}', function($url=null){
if(is_null($url))
{
return view('welcome');
}else{
$segments = explode('/', $url);
$path = implode('.', $segments);
if(ends_with($_SERVER['REQUEST_URI'], '/'))
{
$path .= '.index';
}
return view($path);
}
})->where('url', '.+');
5.1で試したが2階層以上あるとエラーになるぞ
そういうWebサーバの仕様に依存しそうなコーディングはいかがなものかと
Laravelとは1ミリも関係ない話でもあるが
5.1だと入らないのか。5.2だと入るからいけるのかと思ったわ
パラメータ2つ以上だと普通にNotFoundHttpExceptionになる
なおPHP7のXampp
若干改変（改悪かもしれない）したやつを書いておきます。
Route::get('{url?}', function($url=null){
// '/{url?}'としたとしても、htt://hoge.com/でアクセスした場合、
// 何故か$urlにスラッシュが入るので。いっそのこと{url?}で受け取り
// 普通に比較に変更
if ($url === '/') {
return view('welcome');
}
// replaceで。
$path = str_replace('/', '.', $url);
if(ends_with($_SERVER['REQUEST_URI'], '/')){
$path .= '.index';
}
if (view()->exists($path)) {
return view($path);
}
// 番兵的な。
//through all
abort(404);
// 一応、普通のURLで使うやつだけにしときます。
})->where('url', '[a-z0-9\/\-\_]+');
本当助かりました。ありがとうございます。
キレイにコード書ける人ってかっこいい。
一応、上に書いたやつでおれの環境だと動いてる。
若干スレチ気味で申し訳ないが、サーバーの問題なのかな？
検証はVM環境（homestead）php5.6。
スラッシュ区切りの文字列を単独のルートパラメータとして受け取ることはできないようだ
別ルートと判断されてNot Foundになる
HomesteadはUbuntuにNginxなんだっけ？
ApacheとNginxの挙動の違いくさいな
URI末尾のトレイリングスラッシュについてもApacheとNginxでは当然処理の仕方が違う
Apacheでは.htaccessのリライトルールで末尾スラッシュなしのURIにリダイレクトされるから
REQUEST_URIで末尾スラッシュをチェックしても無意味になる
まあ特定環境で動けばいいわけだろうけどもし実稼働環境が開発環境と違えば
この辺理解しておかないと慌てることになるかもだな
何故おれはNginxでやっていたのか...実稼働はapacheなのに。
ということで、環境をapacheに変更してやってみた。
トレイリングスラッシュについてのリダイレクトは勝手にしてくれなくていいので、
htaccessの該当部分を削除して、
$_SERVER['request_uri']で、url末尾の/はとれるように。
こちらの環境ではスラッシュ区切りの文字列でも一つのルートパラメータとして、
受け取ってくれてるんだけどなー。
何が原因かわからないと、何かモヤモヤするね。
やっぱり複数スラッシュを含むURLはそのままエラーになるぞ
他にも/{url1}/{url2?}とかのルートが定義されてて
そっちが動いてるんじゃないだろうね？
こっちがおかしいとしたらどうおかしいのかさっぱりわからん
本当にどうでもいいことなんだが原因がわからんとイラつくわ
ちなみにNginxだからトレイリングスラッシュはちゃんと残るようになった
やりたいことは実現できてるんだけど、
なんで出来たり出来なかったりするのか気になるから、
そっちの環境でも出来るようにしてみて欲しい。わがままな話だけど。
俺の方がおかしいのかもしれんし、再現性あるかも知りたいし。
環境はlaravelのver5.1.45
英語だけど、一応同じようなことやってるの発見した。
ttps://laracasts.com/discuss/channels/code-review/dynamic-uri-segments-in-laravel-5 デフォルトで定義されているものを変更することもある
使わなくて済むなら、使わないほうがいい
いやそこはいいんだよ
/param1/param2
のようなURLを
Route::get('/{url?}', function($url = null) { return $url; });
のような形で受けられるかということ
俺がやるとどの環境でもNotFoundHttpExceptionになる
がやるとparam1/param2が返るらしい
んなこと言われてもなw
そもそもルーティングされてくれないんだからどうしようもないわけだが
homesteadでも試したけど取れたわ。
> Route::get('/{url?}', function($url = null) { return $url; });
> のような形で受けられるかということ
->where('url','.+')が足りないとかそういう問題ではないよね？
いやそれですわorz
whereで条件を「緩める」という発想が一切なかったようでそこ目に入ってなかった
そういう仕掛けだったのね・・・お騒がせしますた
という考え方の人もいますよ
うちの嫁ですけどね
vendorもまるっとコピーするなら不要
転送もgitでやるほうが何かと都合がいいし
そう考えると鯖それぞれに一通り環境は作っておいたほうが良さそう
ポリシーの違いだよ
君のやり方以外も許容しなよ
ttps://github.com/andersao/l5-repository Laravelにリポジトリパターン導入しようと思ってるんだけど
PresenterとかCriteriaの概念がイマイチ分からない
ggってもここらへん詳しく解説してるサイトとかないし、ベストプラクティスが全く分からない
誰か教えてください
テーブル定義したいのにクソファイル名のせいでファイル探すっていう無駄な工程が発生しよるんだが。
ターミナルからだと一発補完も出来ねえし。
マイグレーションファイルを探すのに手間取った経験は全くないんだが
どうやったらそんなに苦労できるんだ？
作ったファイル開くまでに何回キー叩かせるんだよ。
ディレクトリのシンボリックリンク貼ってても10回近くキー叩くぞ。むしろアーティ=サンからファイル作ったら即vimで開いてほしいわ。
普通カタカナではアーティザンと書くと思う
で、ファイル選択はGUIでエディタ使えば済む話なんだよなあ
みんながSublime使ってるわけじゃないのはわかるけど
今どきvimやemacsでもないだろと
ワイはlaravel始めてから間もないからよく分からんのやけど、composerって環境にあんまり依存しないんか？
現在のlaravelアプリの開発環境はほぼデプロイ用のAPサーバと同じにしてて、それってなんでかっていうとlaravelで編集したファイルをrsyncでそのまま転送してるからなんだ。
これが動作環境違うとコケる可能性があるってんならアーティ=サンはローカルじゃ叩けない。
○ オジギ
よく考えたらアーティ=サン自体はcomposerとは関係ないな。試しにローカルでphpバージョンとか合わせずにやってみるわ。
むしろjsonさえあればどこでもサクッと環境を揃えられるのが
composerなりnpmなりbowerの強み（の一つ）でしょうに
マイグレーションも同じ目的
だからこそ実行順を保証するための日時が
ファイル名末尾ではなく先頭に必要なわけで
あとrsyncじゃなくgit使ったほうがいいぞ
同時に複数箇所を並行して修正とか「ここ一旦変えたものを見たい」とか絶対言われることのない仕事なら別だが
少なくとも.envが上書きされないように変な工夫とかしなくて済むし
gitプラグイン入れればSublimeの中からコミット&プッシュできるし
何かと捗るぞ
動作要求さえ満たしていればphpのバージョンによる問題は経験したことがないな
とはいえ確か5.6以上とかだからほぼ最新に限るという意味だが
そりゃgitは使っておるが。pushした時にpost-updateでrsyncで配布するで。
流石にAPサーバ沢山あるのに全部のAPサーバのディレクトリにgitレポジトリは使わんやろ。ステージ環境までやな、gitは。
そこからpushして撒く感じや。
ローカルに環境は作ってないの？
Appファイルは開発サーバ上で直接変更し
デバッグもリモートでやってるわけ？
あとこれは純粋な興味からだけど
DBも各サーバに持ってレプリケーションしてるの？
/**
* @return void
*/
public function __construct(TeamRepository $repository)
{
$this->repository = $repository;
}
コントローラーだとこんな感じに使えるけど、
これをTesｔクラスでも使う場合はどうすればいんだ
constructで依存注入してもダメだし、ただインスタンス化してもcontainerがどうとかでダメだった
それ入れりゃ済むって話でもない？
思いっきりマニュアルに書いてました
どれも1つのModelに対して1つのリポジトリーなんだよね
やっぱりそういう原則が在って、何か理由でもあるのかな？
1つのModelに複数リポジトリー作らないと、
Classが肥大化するし単一責務じゃないんと思うんだけど
よく使うメソッドだけリポジトリにして、
複雑なクエリは1クエリ1クラスにするってのはたまにやる
Eloquent ORMでリポジトリパターンってなんかもやもやするんだよなあ
全然いいでしょ
普通にやってるぞ
普通にいいのか
ありがとう
ブログとかの解説読んだだけでサイト作ってたらコントローラー肥大化して困ってたから今度からそう書きます
なんか実体はillminateだかのディレクトリの中にいるみたいですけどそこを弄るのは違うし……
json返すroute作る
何てことはない、Auth::check()を使えば良かっただけでした。
アプリはあくまでViewの役割で、laravelのapiを作成＋利用という感じがベストプラクティスですか？
ベストかどうか分からないけどそんな感じのを作ったことはある
アプリ側からデータ取るのに必要な情報をpostで受けとり、結果はjson形式で返す
自分はrequest側でもview側でも共有化するために
config('validations.maxlength.user.name')みたいにやっています
何の意味があるんだこれ
同名関数を定義しておくと差し替え可能なので拡張出来る
どこのコンテナにインストールすればいいの
Unsupported platform for fsevents@1.0.15: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npmは3.10.9、nodeは7.1.0
そんならLaravel無関係じゃぞい
同一ドメインなら普通にセッション取れるはず
$request->session()->all()
Session::all()
のどちらを行っても何も入ってないからてっきり特殊なことしないといけないのかと
post先のURLをapi.phpに登録してたのが原因でした。
5.3でAPI用のルート定義が分かれたんだったか
そしてAPI側とはセッションが繋がらんと
理に適ってるようでもあり不便でもあり
不便だす
まあ本来いろんなところからサービスを請け負うためのもんだから
自分とこ専用のサービスなら自分のルートでやれってことなんだろう・・・か
なんかひでえな。
ポンコツmac以外お呼びでないと。
このパターンで行こうかなと思ってるんだけど
storageに一時的に保存するのってバッドプラクティスにならない？
そこがバッドならどこに置けばグッドだと？
ありがとうございます！
どこに置こうと共通する常識の類だが念のため
楽になったとは言えフレームワークの学習コストもあるし
結局は、なんだかんだ既存のCMSに無いこと実装するわけだし
collectionを継承すると色々使えてメソッドチェーンでサラサラ書けてステキ
とか思って多用してたんだけど
except()なんかが返すのは「新規インスタンス」なんだよね
生のcollectionを直接使うならそれでなんの問題もないけど
継承した子クラスが追加のプロパティを持ってて値が入ってる場合
それらはみんな消えてしまうわけだ
新規インスタンスだから当然なんだけど
結構そのことを忘れてバグを作り込んでしまうんだよな
いや俺がヘボいだけなんですけどね
新規インスタンスじゃなくクローンを返してくれてもいいのにと思った次第
パフォーマンスを考慮しての仕様なのかね
状態を持っていないものに無理やり状態を持たせる設計を見直すか、
破壊的なメソッドを自分で追加するかどっちかだな
とりあえずレス感謝れす
趣旨がよくわからんけどCollectionは抽象クラスではないね
except()等のチェイナブルメソッドは具体的にはreturn new static($items);みたくなっているから
たとえばCollectionを継承してFiltersというクラスを作ったとして
$filters->except('filter1')はもちろんFiltersクラスのインスタンスを返す
Collectionではなくてね
しかしFiltersに例えばurlKeyというプロパティを持たせ、初期値以外の値を入れておいて
echo $filters->except('filter1')->url();
なんてやったとしましょう
url()の中で自分のurlKeyを見るとそれはもう空っぽなわけ
伝わるかなこの残念な感じ
まあそうなんだけどね
継承して拡張することで状態を持たせたいという発想は許されないのかなと
return new staticの代わりに
$new_instance = clone $this;
$new_instance->items = $new_items;
return $new_instance;
みたいになってりゃいいんじゃねと思うけど
itemsがprotectedだからセッターを作る必要があって
そうなると隠蔽性が壊れるっていう話なのかなと思ったりしないでもないでもない
責務を増やす事は簡単
その分テストは複雑になる
これは宜しくない
だから専門を新しく作ればいい
$urls = new URLのリスト作る奴($filters, 'urlKey');
assert($urls->url() == $url);
プロパティとしてCollectionを持って未実装メソッドはそいつに受け渡す形ってことね
マジックメソッドとか気分的にあんまり使いたくないけどありだよね
それがベストプラクティスって奴なのかな
今回のケースに限るとフィルタ（要するに絞り込み）の種類がやたら多い上に
クエリパラメータの書き方が統一されておらず（既存サイトの書き換えです）
複数フィルタをまとめて扱うもの（いわゆる詳細検索）もあったりして
やはり各フィルタのクラスがクエリパラメータ生成を受け持つべきと判断した次第なんだけど
失敗だったかもしれないなあ
とりあえずCollectionにラッパーかぶせてチェイナブルメソッドがクローンを返すようにしてみたよ
30個ものメソッドをオーバーライドするんじゃ譲渡のほうがマシじゃんという話もあるがｗ
まあ一回作っときゃ今後のストレスが減るかなと
パフォーマンスや動作には今のところ問題なさそうですわ
ほんとチラ裏な話が続いて申し訳ないｗ
Post::with(['comments'=>function($query) {
return $query->limit(5);
}])
->get();
これだと1つのポストあたり5件じゃなく、全てのポストから5件を取得してしまいます。
解決策はないですかね？
ない
> ない
いや、なんかあんでしょ
無理だとわかるから
laravel passportの主な実用例というのはどういったものでなんでしょう
とりあえずoAuthがどういうものかはわかってるのかな
それがわかれば実用例も自ずとわかりそうなものだが
ttps://chrome.google.com/webstore/detail/%E3%81%AF%E3%81%A6%E3%81%AAng/mbgdnfmdelffjdhkdggilmphfdihnmcj?hl=ja サイドバー隠れなくていいよ
ドキュメントなんだから、いちいちページ変えるのも面倒だし、一覧性も高い方がいい。
メニュー無いのが不便で仕方ないから本家見てる
netbeansはbladeの記述にのに対応してなくてダルいんだが…
この辺使ってみてどれが良かったか教えて
5 BEST CODE EDITORS AND IDE FOR LARAVEL
ttps://www.dunebook.com/5-best-ide-laravel-ide-with-laravel-ide-helper/ 1 - sublime text
2 - Atom
3 - Php Storm
4 - Netbeans
5 - Codelobster
Laravel blade snippets and syntax highlight support for Visual Studio Code.
ttps://marketplace.visualstudio.com/items?itemName=onecentlin.laravel-blade おれは全然不便してないけど。作業効率そんなに変わるもの？
しかも4000円もするし
Sublimeから直接XDebugが使えるみたいだけどまだ試したことはない
秀丸を長年カスタマイズしてきた猛者ならわからんが、おれは気持ちよさが全然違う
実作業時間の話ではない
user_first_name_kanaみたいなやつがufnkaとかで補完できる
キャメルケースならuserFirstNameKana
先頭も大文字のはなんていうんだっけか
まあその辺、いい加減全ての言語で統一してほしいよな
環境によりそうだけど
おまえは許された
Sublime開きっぱなしだ
家でエロい動画見てるとき職場から電話があって・・・
みたいなときすぐ立ち上がるほうが
ストレスがなくていいわ
仮想画面で切り替えた方がいざというときよくない？
そもそも会社以外じゃエディタなんぞ開かんっつってんの
よっぽどの緊急事態に対処するとき以外はね
Laravelをどんなエディタで編集してるかってことだろ
利用ケースを制限するファクターは全てマイナス要因に決まってるだろ
特定プラットフォームでしか動かないなんてのと同じだ
ほんとこれ
Xcode、Eclipse、Visual Studio、Atom、Xamarin Studio
泣きそう
エラーメッセージに、配列の何番目がエラーを起こしたか表示したいんですが、
どのようにすれば出来ますか？
下記のように書くと 価格とは分かるんですが、何番目の価格なのかが表示されず
困っております。
resources\lang\ja\validation.php
'attributes' => [
'item.*.price' => '価格',
],
item.0.price ～
ひょっとしたらウルトラテクニックがあるのかと思って黙ってた
ウルトラテクニック扱いなんですかねぇ・・・
:Index
:Key
とかで何番目か取れても良さそうなもんだと思ったんですが。
要素の数が変わるフォームなんでしょ？
だったら番号出ても意味なくない？
無駄に入ってない項目とか、間違った項目とか調べるくらいなら、
素直に一つ一つ項目ごとに変数に入れて検査すりゃいいんじゃね？
5.3は未入力だnumericチェックされてなかったのに、
5.4は未入力でも数値入力しろって言われるようになった。
まあねぇ。
Android: AndroidStudio
Java: NetBeans
PHP/Python: VSCode
PHPもNetBeansでいいだろ
Laravelだと特に。
AtomやVSCodeでもcomposerの参照くらいできるpluginはあるし。
どっちがいいとか一概に言えないな。
ttps://mayonez.jp/1374 このシステムのフレームワークをLaravelに変更し、HTMLテンプレートは
現状のまま（BladeではなくSmartyテンプレート）にしたいと思っています。
Laravel + Smarty だと、開発効率・可読性・メンテし易さなど、デメリット大きい
でしょうか？
とくに画面遷移の部分（バリデーションエラー時にPOSTデータを再表示するなど）
が気になっています。
教えてください。
お願いします。
ちな、smarty→bladeの置換プロジェクトを進行中
開発中もデザイナーの更新がすすむので、直接書き直すのではなく、面倒でも置換スクリプトを書いてるよ
もちろん汎用性はない
何故でしょうか？
理由を具体的に教えてもらえませんか？
フレームワーク使って楽しようってのに
わざわざややこしいことするなら
そもそもフレームワークいらないじゃん
テンプレートエンジンの入れ替えは効くんじゃね？
Smarty側の事情を知らんから迂闊なことは言えんけど
そのためのフレームワークなんだから。
ログインも、ユーザー管理も、データベースへの書き込みも全部用意されてる。
独自の実装にしたい場合を除いてLaravel使ったほうが楽
ごめん、やった事ないからそれは知らんｗ
Bladeならできるよ。置き換えるのも大した手間じゃないでしょ
ので、postメソッドでのエラーは、元のgetメソッドに return back()->withInput()->withError($this->errors); で返すだけの構造となる
だから、blade使わないならコントローラーの構造がまったく別物になるよ
もちろん、フォーム部品を全部コントローラーで用意するなら、smartyでもlaravel的構造を維持できるけどね
そこまでやる価値はないと、俺らは判断した
テンプレート内でグローバルなfunctionさえ呼べればいいような
既存のテンプレートは一切変更しないという前提だと無理だね
デザイナーさんが絶賛書き換え中のプロジェクトならなおさら
でも一気に切り替える前提なら
フォームのinputのvalueだけ書き換えちゃえば済む話かなと
というか、その方が考え方がスッキリしていて良い気がします。
テンプレート内でグローバルなfunctionを呼んで表示する値を取得するのは、
ビューからロジックを呼ぶことになり、あまり綺麗ではないような・・・
Bladeを使う人はold()を使いまくっているだろうから反対されそうですが。
<?= Request::has('name') ? Request::input('name') : '' ?>
みたいに書くことを言うんじゃねーの？
HTMLしか知らないデザイナーのオネーサンが書いたページにも
最小限の手間で入れられる、さらには
「こう書けばええんやで」と教えれば
オネーサン自身でも何とかなるレベルのシンプルさになることが重要なのであって
そういう意味ではコントローラでコンポーネントを組み立てるなんて考え方のほうが
よっぽどビューとロジックの混合でありバッドプラクティスなんじゃないかと
センセーショナルなグローバリズムの観点から言うとロジックがカジュアルだから
コンパイルのためのリソースがオーバードーズするよな
ヘルパ関数か、横着してモデルにくっつけるか、プレゼンター使うか、フォームだったらフォーム専用のオブジェクト作るかなど
言いたいことはわかるけど言葉は正しく使ってくれよな
普通はコントローラに置くな、モデルに持たせろっていう話になる
ビューに書くなんてもってのほか
もし問題にするとしたらグローバルな関数名を使いすぎというところだろうが
そこはLaravel(特にv5以降)の思想のうちってことになるんじゃないかな
「タイピング量を減らす」っていう明確な思想
名前空間の導入でクラス名全般のタイプ量が増えたことに対する対策
グローバルとは言っても関数は変数と違ってユーザーによる汚染は不可能だし
定義時に存在チェックもしてるんだから
関数名がかぶってもそのヘルパーが使えなくなるだけなので
自己責任の範囲と言えるだろうよ
使いたくなけりゃ無視できるという意味でね
それは失礼いたしました。
バットプラクティスだと思う
デザインをbootstrapに変えるとか、何かしらプラグインで拡張するとか
デザイナーからの要望でチェックボックスとかの出力要素をいちいち変える？
それをやるなら現状のままその名前空間に一個ダミークラス（Fnとか）を置いて
そのメソッドとしてぶら下げることにすれば
ほとんど同じ感覚で使えそうだが
デザイナーさんは（権限あっても）サーバー覗く技量ないよね
laravel.logとキャッシュファイルからエラー箇所を教えてくれるツールとか、
ないのかしらん？
そういうの欲しいと切実に思ってたけど
デバッグが必要なほどのロジックをビューに置くな
という戒めと思うことにした
save時に全部insertしようとしてエラーになるけど、対処方法がわからないよ・・。
もしかして$attributesに直接キーを追加してるのかな？
そういうことか！
変数定義しないで直接ぶっこんでたのがいけなかった
ありがとう。
普通にクラスプロパティでええやん
toJson()を使うならアトリビュート追加する意味があるんだな
今時デザイナーにhtmlいじらすなよ
cssだけでいいだろ
逆に効率悪くなるぞ
俺もそういう環境で仕事したいわ
って更新止まってる？
リンク切れだらけだけど
加える対象の配列に入ってるモデルはidを持ってることが前提になってて
もしidのないモデルの配列を加えてしまうと元のCollectionまで要素が一個になっちゃう
もちろん普通のEloquentモデルはidを持ってるわけだが
DBから取得せずnewで作ったモデルを
mergeで追加しようなんてことは絶対考えちゃダメ
いいか、絶対だぞ
俺みたいになりたくたかったらな！
orz
要素が全部消えるの？説明がよくわからん。
うん
一個だけになって残りは消える
こっちの方が怖いかもしれないな
mergeの引数はコレクションじゃなくて配列なんだよね
元のコレクションに入ってるモデルにidがないことが前提だな、多分
それだと元のコレクションも要素一個になる
引数の配列に入ってるモデルにだけidがない場合は
元のコレクションは無事で済みそうだ
試してないけど
まあ当然といえば当たり前の挙動なんだな
でも$query->get()したコレクションをmapメソッドで中身を別の新規モデルにして・・・なんてやって
元がEloquentのCollectionであることを意識せずにいてひどい目にあった次第
ちなみに普通のCollectionではなんの問題もないから
いったんcollect($collection->all())なんてやって変換すれば大丈夫
俺のケースでなんでEloquent\Collectionのままだったのかよくわからなくなってしまった
まあもう問題は解決したからいいんだけど
そう考えるとあまり普通には起こらないはずの現象ではあるな
mapにしてもfilterにしても結果はEloquentではなくIlluminate\SupportのCollectionだから
質問くらいなもんでしょ
・CRUD処理の Create(レコード追加)と Update(レコード更新)のアクションに
おいて、それぞれ「保存(Save)」のメソッドを定義するときに、
これらは同一でいいんですか？分けたほうがいいんですか？
そんでinsert時は大抵idは未指定でDBの自動生成に任せるはず
ラッパーのupsert関数を用意するなら同一に出来るけど、
結局内部ではidの有無で切り替える処理になると思う
むしろupdateを使うとイベントが発火しないから
よほど大量の更新じゃない限りsaveでいいんじゃないかと
Twig でいう spaceless のような機能のことです
詳しい方どうか教えてください
gzip圧縮しちゃったほうがよくない？
使うならSymfonyのフォーム入れて使えってことか
この程度のは楽とは言わない
サーバエラーが起こった場合のエラー内容がわかりづらくて困ってます
コードの何処かに打ち間違いとかがあった時に
どこでエラーになっているのかとかがすごくわかりづらいんですが
皆さんどうやって見分けてますか？
コツなどあれば教えてください
logger使ってログファイルをtail -fするだけでも大分捗るぞ
RequestがFormじゃないの？
productionモードでやってない？devにすると行数まで出てたような。
フレームワーク内でのエラーになっちゃうからね
マジックメソッドの弊害
なんでこんなのが変換候補に出てくるんだ・・・
慣れればね
メソッド名を1文字間違えてたときとか原因わかるまで結構時間かかってしまったんですが
とりあえず頑張ってみます
そういうのはLinterの出番
「PHPMD」でググると幸せになれるかもしれない
スコープとかミューテータとか
そのままの名前のメソッドは存在しないわけだけど
あと普通のルーティングと書き方って何か違いますか？
同じところに書くと何かまずいですか？
ただしweb.phpのルートとはセッションが繋がらないので要注意
単にajaxの受け口など自サイト専用のapiなら
web.php側に書くほうがなにかと楽だと思う
多分ベストプラクティスからは外れるんだろうけど
ありがとうございます！
いちいちジョインするの面倒っすわ
複合キーでJOINする必要があるってこと？
そうっす
今回の民法改正、ソフトウェア受託開発の場合、(検収後ではなく)バグ発見後１年瑕疵担保責任があるということで、地獄かよ、と思ったが、
元々問題が起きがちな受託案件がビジネス的に成立しなくなることで強制的に業界再編につながるなら良いことかもと思うようになった。
一部で地獄を見ても。
ttp://https://twitter.com/yukihiro_matz/status/869061879389343744">ttps://twitter.com/yukihiro_matz/status/869061879389343744 367 :nobodyさん 2017/05/29(月) 16:28:06.55 ID:6v4UcGhE
ニュース - 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大：ITpro
ttp://b.hatena.ne.jp/entry/itpro.nikkeibp.co.jp/atcl/news/17/052601508/ 372 :nobodyさん2017/05/29(月) 19:10:37.12 ID:???
Railsでシステム作って納品する
↓
Railsはマイナー、メジャーのアップデートが半年以内に必ずある
↓
客がアップデートする。アップデートによるエラーやバグ、動作の不具合に気づく
↓
気づいてから1年以内に通知すれば、5年間無料保証ゲット
↓
つまりRailsがアップデートするたびに、無償の修正作業を発生するということかな
376 :nobodyさん2017/05/30(火) 09:20:20.09 ID:L5po86sS
客が瑕疵担保責任法の法改正を知ってくると思うから、今後5年無償保証をお願いされるだろう
営業がそれでも仕事を取ってこれるか？たぶん無理だろう。無限の直していたら赤字になる。
こういう保守に弱い言語、ころころ仕様が変わる言語は仕事として発生しなくなってくる。
これは変わり目だ。お前らも早く逃げたほうがいいぞ。RubyやPHPなど動的言語は確実に廃れる。
保守に強い言語のみ生き残れる。
「バージョン○○まで面倒見る。それ以降は知らね」と契約するもんだ
瑕疵担保責任のポイント
民法改正で事実上期限が「無制限」になった
バグや設計のミスなどは、瑕疵担保責任
納品物に不具合があれば損害賠償を請求される可能性もある
ttp://www.atmarkit.co.jp/ait/articles/1706/26/news014.html ttp://itpro.nikkeibp.co.jp/atcl/news/17/052601508/?rt=nocnt 改正法では欠陥に気付いてから1年以内にITベンダーに通知すれば、
通知後5年以内は修正や報酬の減額などを求められるとしている
全ベンダーが泣いた民法改正案を解説しよう その1
ttp://www.atmarkit.co.jp/ait/articles/1609/14/news009.html ttp://www.atmarkit.co.jp/ait/articles/1609/14/news009_2.html ttp://www.atmarkit.co.jp/ait/articles/1609/14/news009_3.html 従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。
条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、
その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、
11年後まで請求可能なのだ。
もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、
「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、
バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。
ライバル社とのコンペで負けるな。ライバル社は無償保証を提案してくるだろうから
それはバージョンアップしない前提だろ
そりゃバグが出ればメンテするわな
調べてもよくわかりません
どなたかわかりやすく解説してくれませんでしょうか？
その「きっかけ」となる何かのことをイベントと言う
一般的にね
LaravelというかEloquentのイベントはデータ作成や更新といった「きっかけ」で
何らかの処理を自動で行わせるために使う
会員が最低一つはメルマガを購読するとしたら
会員モデルのcreatedイベントにメルマガ購読モデルの作成を仕込んでおけば
あとは会員を作成するだけでいいというわけ
というかプログラムのどこで作成しても必ずメルマガ購読データも作られるようになる
まあ処理し忘れを防ぐ機能とも言える
マメな人なら必要ないとも言えるかもしれん
>そりゃバグが出ればメンテするわな
当たり前だ！ただでやれ。金は出さないよ。法律改正されたし、
アップデートごとにバグが出たら、何十年も無限無償でよろしく！
バックれたら瑕疵担保責任法で訴えるからな！
わかったか！
なるほど
最初はイベントなんか使わなくても対象の箇所に適当なメソッドを挟めばいいんでは？と思ってたんですが
もっと深い箇所に埋め込みたい場合はイベントの方がいいんですね
ありがとうございました
深いところ、というよりはデータ自身に付随させる
という考え方のほうがいいかも
Laravelというかこの手のフレームワーク全般に言えることでもある
ミューテータとかもそんな感じでしょ
めんどくさい処理はデータモデルに任せて表では楽しようという
なるほど！
大変わかりやすい解説ありがとうございました！
正直使いづらくて何がいいのかさっぱりわかりません
ルーティングは機能ごとに毎回追加しないといけないし
nameスペースもいちいち追加するのがめんどくさいし
吐き出されるエラー内容もわかりにくいし
ドキュメントも充実してないし
こんなフレームワーク使うよりは
Codeigniterの方が使いやすくていいと思うんですがどうでしょうか？
数人かそれ以下のPGで制作する場合は
Symfonyやその派生の巨大フレームワークは
却ってボトルネックとなると思う。
PG兼SE1人の制作環境では修行しているような気分になるはずだ。
しかし多数のPGを使って制作する場合は
リーダーが外枠（フレームワーク内のフレームワーク）をきっちり準備すれば
スムーズに事が運ぶと思われる。
俺は大人数での制作に関わる気は毛頭ないから
CodeIgniterの高速性を取るし（最近はCodeIgniterすら使わない）
Symfony系の巨大フレームワークは壮大な無駄にしか見えない。
ドキュメントが充実していないというのは誤解のような気がする。
Symfony系のフレームワークは色々な団体・個人が開発したソースの集合体であり
どこかが一括してドキュメントに責任を負っているわけではないのだろう。
Symfony系が粗大ゴミにしか見えない者にとってはどうでも良いことだが。
SQLインジェクション対策とか、ログイン関係のセキュリティ対策も完備しているし、
コマンドも自分で簡単に追加できるし、普通にフレームワークとしての機能は完備してる
解説は確かに昔少なかったけど、解説本も出たんだから買えば解決
ただ、公式の解説や、本体を翻訳してくれてる有志が居るし恵まれてる方でしょ
CodeIgniterの方が負の遺産抱えすぎて悲惨だろｗ
未だにアンダースコア区切りでやってんのかよ
PHPは割りと理解している(.so 関係, peclモジュールとかは怪しいレベル)
Composerはギリ
Railsはできる。
JavaScriptは結構得意。(jQery, Reactいける。)
MySQLも使い慣れている(スキーマとかGRANTもできる)
設定できないってことかね
Apacheの設定もいじるのはDocumentRootぐらいだと思う、/以外にLaravel設置しようとしたら大変かもしれないが
windowsだとなにかとトラブって動かせたことがないが
まあxampp入れれば環境はすぐできる
そうそう、xampp頼みで Apacheは勉強不足なんだわ。
vagrant本気でやってみようかな？
Dockerは勉強したんだけどね、誰かが構築済みのやつを拝借してしまえばいいわけだ。
つまりxamppの代わりをvagrantにやらせるってことでしょ？
違うよ。
xamppはwindows版apacheとmysqlとphpなどのセット。
vagrantはvirtualboxやvmwareでlinuxの環境を簡単に作るためのツール。
サーバの設定は自分でやらないといけない。
xamppみたいにボタン押せばとりあえず使えるといったシロモノじゃない。
それでも俺はvagrant+virtualboxをすすめる。
PGでもサーバの知識は必須なので、今のうちにやっといた方がいいよ。
サーバの知識何もいらんよ
機会を見てサーバの知識は持っておいたほうが良いとは思うけどね
vagrantさえ動けば何も考えんでいいと書いたのは
homesteadがあるから、という話だよ
vagrantを動かした上で色々設定の必要ありというのは
ことlaravelに関する限り当てはまらないということ
サラのimageだったらphpから入れる必要あるしね。
けっこう面倒。
でもやる価値はある。
作ってからアップロードするときにでもサバの勉強すりゃいいし。
なんでもかんでも手を出すと、結局何もできないことになる。
