のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,894人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレ[PHPフレームワーク]Laravel

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    703 :

                  【Win10】    こんな犯罪級OS薦めんなよwww   ↓   【スパイウェア】


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



    「1910」 副島隆彦 2016年6月16日

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

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

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

    704 :

    Laravel布教あげ

    705 = :

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

    707 = :

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

    708 = :

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

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

    709 = :

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

    710 :

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

    711 = :

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

    712 = :

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

    714 :

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

    715 = :

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

    717 = :

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

    718 = :

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

    719 = :

    ASP.NETにしなよ

    720 = :

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

    721 :

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

    722 = :

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

    723 = :

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

    724 :

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

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

    726 = :

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

    727 = :

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

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

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

    729 = :

    apcならそうなる

    730 = :

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

    731 = :

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

    732 = :

    初めてlaravel使うんだけど、
    全ページ、ルーティングしなくちゃだめなの?
    静的ページが100ページくらいあるんだが。
    publicに静的ページ置こうか考えたけど、viewテンプレートは使いたいから却下。
    ちなみにver5.1。
    誰か分かる人ご教授ください。

    733 = :

    ルートパラメータ使えばいいだろ
    それでなんとかならないようなら
    そもそもフレームワークを使う意味が不明では

    734 = :

    前ページルーティングって恐ろしい思考回路だな
    そもそも使うの初めてなら、まずは他の人がどうやって似たシステム組んでるのか調べる方が良いよ
    勉強には先人の知恵に習うのが一番

    735 = :

    返信ありがとう。
    丸2日くらい検索したけど出てこないんだ。最後の砦としてここで聞いてる。

    ひとまず、ルートパラメータでやってみたけど、

    //通常のルーティングされなかったら以下実行
    //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');
    }
    }
    });

    こんなでいいのかな?
    第二階層までしか対応出来ないのがアレだけど。
    もっといい方法あったら教えてください。

    736 = :

    あんまりララベリッシュじゃないけど動くだろうからそれでいいんじゃね?
    もっといい方法といってもなあって感じ
    そもそも大量の静的ページってのが根本的に合わないわけで
    bladeテンプレを使いたいっていうからには少なくとも「ある意味」動的ではあるはずだと思うんだけど
    動的に変わる内容が何一つ整理できない(全てを個別に扱うしかない)なら
    もうそれ以上やりようがないんじゃないかと

    737 = :

    >>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', '.+');

    739 = :

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

    740 = :

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

    741 = :

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

    743 = :

    おお、すごい。とても参考になりました。ありがとう。
    若干改変(改悪かもしれない)したやつを書いておきます。

    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\/\-\_]+');

    本当助かりました。ありがとうございます。
    キレイにコード書ける人ってかっこいい。

    744 = :

    おっと、5時間かけて検証しながらレス書いてる最中に色々レスついてた。
    一応、上に書いたやつでおれの環境だと動いてる。
    若干スレチ気味で申し訳ないが、サーバーの問題なのかな?
    検証はVM環境(homestead)php5.6。

    745 = :

    CentOS6にapacheにPHP5.6の環境でもやっぱり
    スラッシュ区切りの文字列を単独のルートパラメータとして受け取ることはできないようだ
    別ルートと判断されてNot Foundになる
    HomesteadはUbuntuにNginxなんだっけ?
    ApacheとNginxの挙動の違いくさいな
    URI末尾のトレイリングスラッシュについてもApacheとNginxでは当然処理の仕方が違う
    Apacheでは.htaccessのリライトルールで末尾スラッシュなしのURIにリダイレクトされるから
    REQUEST_URIで末尾スラッシュをチェックしても無意味になる
    まあ特定環境で動けばいいわけだろうけどもし実稼働環境が開発環境と違えば
    この辺理解しておかないと慌てることになるかもだな

    746 = :

    そういうことなのか。
    何故おれはNginxでやっていたのか...実稼働はapacheなのに。
    ということで、環境をapacheに変更してやってみた。

    トレイリングスラッシュについてのリダイレクトは勝手にしてくれなくていいので、
    htaccessの該当部分を削除して、
    $_SERVER['request_uri']で、url末尾の/はとれるように。

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

    747 = :

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

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

    748 = :

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

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

    749 = :

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

    750 = :

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

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


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について