もしかしてresourceコントローラーだと
$router->model('user', 'App\User');
が使えない？

authorizeForUserはblade側で操作できんのか？

　　　　　　　　 　　　　　【Ｗｉｎ１０】　　　　こんな犯罪級ＯＳ薦めんなよｗｗｗ　　　↓　　　【スパイウェア】


この使用許諾契約書には書かれています
”最後にあなたのコンテンツを含む個人データ（例えばあなたの電子メールの内容や―プライベート通信やプライベートフォルダ内のファイル）にアクセスし―開示し保全します”
開示する　ここ重要だよ
契約がなければ通常　高度な違法行為になりうることです　それはあなたが自分の意思としてこの契約書に同意したのです
http://www.youtube.com/watch?v=ZBwEmgdqB1c



「１９１０」　副島隆彦　２０１６年６月１６日

大阪市や大阪府のバスの運転手が年収1000万円は許せない、600万円まで落とすと。
なぜなら、普通の労働者たちが年収400万円でようやく働いているのに、何でバスの運転手が1000万円ももらえるんだと。

このものすごくすばらしい主張があった。
これを言われると日本の民主党や共産党は非常に困るんです。
が、先ほど言ったように、金持ちたちの財産を相続税で国家が奪い取る、これを正面から本気でやったらほんとに橋下はたたき潰されました。

労働組合を押さえつけるまでは安倍晋三たちも大好きだからよかったんだけど、
自分たち自民党体制の、金持ちと地主階級、経営者を大事にするという自民党の基本骨格があるわけです。

Laravel布教あげ

アップデートあったのか不安になる勢いだな

5.3正規リリース来たのか
Vue.jsとの統合がどうなってるのかは気になるな

Laravelは好きなのに最近のフロントエンドへの干渉がどんどん強くなる流れは嫌いだわ
ElixierにしろVue.jsにしろデフォでpackage.jsonに入れる必要性が理解できない
フロントエンド開発に任せるべき範疇だろ

この細かい互換性とか気にせず、ばっさり切り捨てる感じ嫌いじゃない

Vue.jsってObjective-C初めて見たときみたいにひょぇぇぇ～ってなるから、まだみたくないな

いやなんだかんだ言ってフロントエンドの開発負荷ってデカいから
そこが組み込まれるのはありがたいわ
アングラーとか覚えるのと自分でゴリゴリ書くのと
どっちが早いか迷って後者を選んで泥沼化したりもしたし
フロントのコードにもLaravelなりのベストプラクティスを提示してほしいと思ってた

好き嫌いはっきり別れてるのがまた面白い

好きもの憂きもの定々と別れしことげにいとをかし

>>510 みたいな書き方って今でもする？

4.2のdocsだとtemplatesで508の書き方が紹介されてるけど、
5.0からは@yield使ってるから今はこっちが主流でいいのか。

Vuejs なんて学習コストめちゃくちゃ低いだろ

そうなの？なんかめんどくさそう

ハイブリッドアプリとかデスクトップアプリケーションならjsにもいろいろ選択肢あって楽しいんだけどな。
ただサーバサイドエンジニアがフロントエンドもガッツリ攻めていくのはかなりの体力がいる

大昔ならAccessでやったような業務アプリの案件を
流石に今からAccessでやる選択はないし
じゃあVBとかVCにMSSQLでやんのかつったらそれもまた（Windows自体の将来性に疑問符）
ということでいっそWebアプリでっていうのはごく自然な流れだと思うんだけど
実際やるとフロントエンドが大変すぎて死ぬよね
Access並みの手軽さでサーバサイドとデータバインドできるUIコンポネが一揃セットになってれば
一気に広まる可能性あると思うんだけどな
HTMLやFormのファセットをオプション化した流れはその逆のようにも思われる

ASP.NETにしなよ

バックエンドがUIのデータバインディングまで面倒見るとか勘弁してくれ
2年経たずに手の付けられない負の遺産となる

Windowsはビジネスユースなら今後もなくならんやろ

最近の施策で.net案件のプロプラ不安は全部解消されたな。全力注いでるのが分かる
あとは受け入れられるかどうかと、キャッチアップが遅すぎる>>718みたいな老害のプライドをいかに刺激しないように説得するか。現場の手腕次第だな…
バカほど声が大きいからな

ふむ
嫌味を返すなら全力注いでる=なりふり構わず生き残りに必死
ってところだけど
確かに現状のASP.NETは十分選択肢になりそうだな
サードパーティ製の業務アプリ向けUIコンポネなんかも
歴史が長いだけあってそこそこ整備されてるようだ
業務用ならゲイツプラットフォームという根拠のない思い込みも（発注側に）根強くある
こうなるとこの分野へのLaravelの浸透は難しいかもな

ReactだったりVuejsだったり、現状でもサーバーサイドレンダリングできるけど現実的ではない。
Vueも2.0でSSR対応できるみたいだけど、実用では使えないと思う。まだ1、2年かかる気がするし、時が経てば経つほどSEO目的のSSRは考えなくても良くなるだろうし。

今後バックエンドでは、いかに使いやすいAPIを作るかってとこが注視されていくんではないかと。
そこの領分がきっちり別れるようになると、バックエンドもフロントエンドも幸せにはなると思うね。理想論かもしれないけど。

GraphQLってどうなんじゃろ

>>720
今更のレスだがjQueryでBootstrapな基礎はもう変わらないんじゃね？
それこそASP.NETも（フロントはC#捨てて）そうなってるみたいだし

APCでキャッシュしてるんだけど、教えて

・コンソールでphp artisan cache:clearとか、自作コマンドでCache::forget呼んでもキャッシュが削除できない。同じキーで取得はできる
・routes.php内で同じソースを実行すると取得も削除もできる

これって何が原因だろ？console経由だと読み込まないconfigとか実行ユーザの違いとか？

>>727
apc.phpでキャッシュクリアできるかどうか試す。
できた場合→apc.phpで実行しているコードをコピペ。
できない場合→わからん。

apcならそうなる

>>727
> 同じソース
というのが幻想

>>727
> 実行ユーザの違い
でしょ

初めてlaravel使うんだけど、
全ページ、ルーティングしなくちゃだめなの？
静的ページが１００ページくらいあるんだが。
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テンプレを使いたいっていうからには少なくとも「ある意味」動的ではあるはずだと思うんだけど
動的に変わる内容が何一つ整理できない（全てを個別に扱うしかない）なら
もうそれ以上やりようがないんじゃないかと

>>735
こんなんでどう？最後のスラッシュが$_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', '.+');

よー考えたらexplode,implodeじゃなくてreplaceでいいな。どうせ最後にスラッシュつかないんだし

つかそれで$urlにスラッシュ含めた残りのURL入ってくるか？
5.1で試したが2階層以上あるとエラーになるぞ

ついでに言えばREQUEST_URIも俺の環境では最後のスラッシュが削除されるようだ
そういうWebサーバの仕様に依存しそうなコーディングはいかがなものかと
Laravelとは1ミリも関係ない話でもあるが

>>739
5.1だと入らないのか。5.2だと入るからいけるのかと思ったわ

いや5.3でダメだから既存の5.1環境で試してやっぱりダメだったんだが・・・
パラメータ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。

CentOS6にapacheに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末尾の/はとれるように。

こちらの環境ではスラッシュ区切りの文字列でも一つのルートパラメータとして、
受け取ってくれてるんだけどなー。
何が原因かわからないと、何かモヤモヤするね。

HomesteadのNginxでも試してみたが
やっぱり複数スラッシュを含むURLはそのままエラーになるぞ
他にも/{url1}/{url2?}とかのルートが定義されてて
そっちが動いてるんじゃないだろうね？
こっちがおかしいとしたらどうおかしいのかさっぱりわからん
本当にどうでもいいことなんだが原因がわからんとイラつくわ

ちなみにNginxだからトレイリングスラッシュはちゃんと残るようになった

create-projectで新規に作ったから、他のルート定義はしてない。

やりたいことは実現できてるんだけど、
なんで出来たり出来なかったりするのか気になるから、
そっちの環境でも出来るようにしてみて欲しい。わがままな話だけど。
俺の方がおかしいのかもしれんし、再現性あるかも知りたいし。
環境はlaravelのver5.1.45
英語だけど、一応同じようなことやってるの発見した。
http://laracasts.com/discuss/channels/code-review/dynamic-uri-segments-in-laravel-5

REQUEST_URIはサーバによって違うよ
デフォルトで定義されているものを変更することもある
使わなくて済むなら、使わないほうがいい

>>749
いやそこはいいんだよ
/param1/param2
のようなURLを
Route::get('/{url?}', function($url = null) { return $url; });
のような形で受けられるかということ
俺がやるとどの環境でもNotFoundHttpExceptionになる
>>748がやるとparam1/param2が返るらしい

>>748
んなこと言われてもなw
そもそもルーティングされてくれないんだからどうしようもないわけだが