将来symfonyに移行するならLaravelが最適です
Laravelはsymfonyのライブラリも組み込まれてるし概念もsymfonyに似ている部分があるから
symfonyの1と2とどっちに似てるのか聞いとるのだ。 それぐらいちょっとは考えろ。
去年は FuelPHP が「いま一番活発なフレームワークです(キリッ」 また来年は新しいのが出てくるのかなw
バリバリ開発者じゃないから他とのちゃんとした比較はできないけど、 使ってみて良かったところ ・デフォルトテンプレートが綺麗。「開発環境」色がない。 最初に画面見た時にヤル気出た。 ・routes.phpの多機能っぷりのお陰で自由度が高い。 「規約より設定」が好きな人向け? ・マイグレーションが楽(FuelPHP比較) ・バンドルが結構豊富、インストールも簡単。 ・アメリカ、イギリスでの支持が大きい。 googleトレンドで見ると先進国ではFuel、Kohanaあたりは完全に食っていてYiiも食いそう。 残念だったところ ・日本語ドキュメントが少ない、英語のマニュアルもボリューム足りない。 ・Laravel4で大幅に仕様が変わるらしくさらにドキュメント不足に。 趣味のwebアプリで使う分には不自由してないし、ドキュメントの少なさも調べる楽しさがあって個人的には気に入ってるよ。
>>17 EloquentっていうORMクラスを使うのが一般的みたい。 usersテーブルだったら、modelディレクトリにUserっていう継承クラスを作っておくだけで入出力ができる(もちろんテーブル名は設定可能) あとはコントローラで $users = User::where_in('id', array(1, 2, 3))->get(); とか書けば配列が帰ってくる。 この辺は本当に直感的でお手軽だと思う。 ユーザ管理なら有志のバンドルの「Sentry」っていうのを試してみたら多機能だしマニュアルが超親切で良かった。 デフォルトのAuthはちょっと非力かもしれない、ユーザごとのパーミッションとかないし。 足りない機能は自前かバンドルで補ってねっていうスタンスらしく、laravel4ではHtml、Formクラスすら拡張対応になるそうだ。 書き忘れた、フォームはViewに Form::open(); とかで作って、コントローラでは $id= Session::get('id'); という具合にセッションから受け取る感じ。 上に書いたようにLaravel4ではFormが標準から外れるから書き方が変わるみたいだけど。
書く気はあるけど三日坊主だから続ける自信はない 今後web上で見かけたらよろしくね
最初の導入も分からない奴はcakephpでも使ってろよ
>>19 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もライブラリとしては勿論使える。これは3でも4でもだが。 いままでフレームワーク使ったことなかった頃に、 Fluentクエリービルダーみて感動したのは俺だけなんだろうか。
てかPHPなんだし、問題が起きたら自分で直せばいいよ。 PNE案件とか大概そうだし。
laravelの日本語マニュアルの人と 和訳をdisった人って まだ決着ついてないのね 和訳サイトにわざわざdisられましたとか載せてて意味あるのかな 向こうもtwitterとか連絡できる手段があるんだから直接ぶつければいいのに
最近のフレームワークの中では日本語ドキュメントが整備されてて ちょっと感動したんだが何か問題があるのか
日本語ドキュメントを参照しないと言語使えないという時点でプログラマ失格。
この問題を2人で話し合って次の勉強会までには和解してもらいたいね 二人ともいい年した大人なんだからさ自分の意見を直接相手にぶつけることもできるでしょう ずるずる関係悪いままで相手が折れるのを待ってるような情けない女々しい考えは捨てるべきだ このまま引きずって双方が勉強会に参加されても場の空気が冷める場面に直面する可能性もある 前回の勉強会は実際に仲裁できるような人なんて1人もいなかった。俺もだけど 2人のために無駄に気を使わされるのも迷惑だし 解決できないならどちらとも勉強会には参加してもらいたくないのが次回も参加する俺の意見 オープンな勉強会に「(自分より知識ある|知り合いだ)から注意しにくい」とか関係ないから
KとNで呼ばせてもらうけど Kのサイトだけを読むと 一方的にNが悪いように見受けられるが Nがdisる前に KがNをdisったから NがあそこでKをdisったって見方もできる 動画を見ても、Nの「アイツをdisってやった」オーラがハンパないもんね KがNを怒らせたり嫉妬させるような出来事があったのかもしれない Nが発表する前までに何か二人の関係にギクシャクする事があったんだろうと思う
そんでKがサイトで一方的に文句たれていては火に油を祖即だけで何の解決にもならないと思うんだがなあ 何で二人で話し合えないのかね
まぁ俺もそうだが、そういう人種だから仕方ねぇよな。 現場に入ると、初手から一方的にマチガイ対応するやつもいるし。
このフレームワークってCakePHPみたいにCSSビルトインされていないの? 皆どうしてるの?一から書いている?
Twitter Bootstrap とか Foundation5 とか使うといいよ
バリデーションをなぜモデルでなくコントローラーでやるのか その辺の思想?みたいなものがわかるページない?
このモデルはこういうデータしか受け付けませんよエラー返しますよ ってのがおかしいの?なにがわからん?
>>50 Cakeから来た俺もそれ思った。「コントローラでヴァリデするんかー、へー」くらい。 何故かは深く考えたことない。 codeigniterやそこから派生したFuelやkohanaなんかもvalidationは専用のクラスを使ってコントローラーでするってかんじなのな なんでこんなことになってるか考えたら多分MVCしないで横着にコントローラだけですますとかrouterだけで済ますとかの軽量アプリを全然OKっていうところから来てるんだと思った railsでコンソールからModel.create({name:'hoge', age:30})とかやった場合にバリデーション吐き出すのは素晴らしくスマートだと思ってたし そうじゃないとおかしいだろとまで思ってたけどそもそも思想が違うんだろうな Ardentとかいうの入れればモデルでバリデーションできるらしいけどもういいや まずMVC語るのやめれ
バリデーションはコントローラーが適切でしょ モデルはないわ ケークはダメフレームワークだから参考にしちゃだめだよ〜
LaravelはComposerでパッケージをダウンロードして使うとサイズが大きくなっちゃうからいらねえよ なんでWebフレームワークで15MB前後の要領食わなきゃいけないんだ なめすぎ
LaravelでFuel並みにモジュールが扱いやすくなるプラグイン無いんかな VやらCやらがゴチャゴチャしてきて機能別に分類したいんだけどlaravel-modulesもなんか面倒くさい 設置してさっと使えるようにして欲しいわ
モデルってDBのデータを入れた入れ物だけじゃないよ
勘違いしてんだろ モデルは手続きも含むものだ そのメソッド独特の入力制限でもしたいんだろうが、 例えば同じテーブルの同じフィールドに別のバリデーションを設ける場合がそうあるのかって話だ 権限の違いなんかで制限が変わってくる場合はその権限用のバリデ付きモデル作れた方が後で見通しがしやすい >>55 が言ってる「横着」ってのはそれを面倒臭がってコントローラで済ますんじゃねぇってことでしょ 俺もFuelphpじゃモデルでバリデーションやってるで
DBのモデルのフィールドとユーザー入力が一致しないこともあるからな
ところでLaravelて本当に活発なの? 日本で使ってる人が少ないだけ?
基本的なことだったら申し訳ないですが質問。 検索条件をPOSTしてその結果を、条件入力した同じページの下部に表示させるお馴染みの処理なんですが、 Routes.phpのPOSTのところで、Redirect::toでGETへ戻すのがいいのか、 View::make('GETと同じヴュー') で ヴューを作っちゃうのか、どっちがベストプラクティスなんですかね?
return View::make(どこどこ)->with(変数名、変数) ← そのままechoできる return Redirect::to(どこどこ)->with(変数名、 変数); ← セッションに突っ込む この違いがどうにもはまるポイントなんだが。なんで同じwithで動きがちがうんですかね。
ララベル全く知らないが、そういうのは普通GETで送信してそのまま表示する GETにしておかないと、ページャーでページングして戻るボタンがウザいとか問題がある 検索処理じゃなくて、例えば掲示板の書き込みなんかの場合、POSTで送信して処理後にリダイレクトでGETし直す 必ずこうしないと行けない訳じゃないが、だいたいこう
冪等かつリソースに副作用のない安全な処理はGETがいいよね 検索は基本的にGET
>>67 >>68 ありがとう。GETで引数渡すってことは、URLの後ろにごちゃごちゃと長い検索条件をくっつけるあの方法ですよね。 確かにそれが一般的ですよね。ありがとう。 この前laravelで作ったものを納品した。 これ、覚えること多くて奥が深いよ。 フレームワークのアップデートはコマンドで一発だから楽だな。 俺は個人的に大好きだけど、大人数でやる場合には、色々と取り決めが必要になる。じゃないと後々面倒。 後、クラスを追加した後にコマンドとか打たなきゃだから、vagrant環境で開発進めていって、後で皆のファイルをマージした方が楽かもね。
FuelPHPとLaravelってどっちが勢いある?
日本だとちょっとだけlaravelのが使われてる。勢いもかな 海外だとlaravel
fuelphpは日本でしかはやってない印象 グーグルトレンド見るとひどい
ララベル4興味があって使おうかなと導入を読んでいたのですが 何らかのライブラリを追加しつつ ローカルで開発し終わったら 本番環境ではFTPでディレクトリ単位でローカルのファイルを 単にアップしたんじゃ動かない? ローカルと本番のディレクトリ名を直したりとか必要? もしくは、sshで追加したライブラリをインストールし直さなきゃ動かない?
>>76 俺がマイナーなのかな? php開発ってローカルでするものなの? サーバーにサブドメイン切って、本番、開発、デザイナー用とか作らない? 環境揃うし、なによりrsyncで複製作れる。 そういう意味で、ドメイン、ホスト名、サブドメインはどこにも設定しないので問題ない。 ただし、デザイナーの書くテンプレに絶対パスが紛れる可能性は否定できない。 蛇足: PCがWindowsでもwin-sshfsでドライブをマウントできるから。 Laravelをglobalにインストールする方法を教えてください。 アップデートを1箇所で管理したいのでプロジェクトごとにLaravelをインストールするやり方はしたくないです
>>78 composerの管理をglobalでやればいいんでないの? 適当なディレクトリにjson置いて実行するだけじゃん。 include指定がめんどくさくなるから、プロジェクトの外に置くメリットをあまり感じないけど。
そういう使い方はlaravelに用意されてない よってcomposerでglobalインストールする方法はない
>>83 そういう使い方が用意されてるFWなんてないっしょ laravelは他のFWよりcomposer分離は難しい composer.jsonのアプリ部分とベンダー部分を分離しないとダメだし artisanが敵でhookを書き換えないと正常に動かないし require,includeが複数あるから面倒だし path.baseの直下にvendorがあるとFW内で書かれているので対応しないとダメだし workbenchあたりもなにかあるかもな >>78 プロジェクト毎にlaravelは置いておいて 全composerを管理するシェルを作るとか、デプロイツール使うとかが現実的 laravelをインストールすると21MBも使う。 5プロジェクトで100MB超 大規模に向かないフレームワークのくせにサイズ多すぎなんだよ
そのサイズが問題になることはないから どうでもよい。
今日明日とLaraconやってますね 4.2は何が変わるんだろ
なんかスレの勢い全然ないね;; LaravelでCakeの出番はもうなくなったなーと思って早1年。 日本では全然ブレイクする兆しがない不思議さ Cakeより何十倍もLaravelのが出来がいいと思うのだけどねぇ
まだまだ日本語の情報少ないし、使ってるフレームワークを切り替えるのは大変だしね 2chってこういうプログラミング関連の書き込み意外と少ないし
意識低い系はCakeからRailsに移ったが 意識高い系はどこからどこに移ったんだ?
そういうことか 自己顕示欲を出せるところ増えたしな
>>96 最近だとqiitaとかかな。質問できないのが辛いが codeigniterんやめて、だいぶlaravelにもなれてきた アイデアやライブラリもたまってきたけど、だから何?って感じ ブログ書いてる暇ないし
>>97 コメント書けるでしょ Laravelに限らないけど、情報を共有しようとする姿勢の人が増えないと流行らないだろうね でも海外じゃあ十分流行ってて情報もあるから、英語できれば問題ないね 2chの方がレスポンスが早い、気がする。 有用かどうかはともかくw。
2chは聞く場 Qiitaは書く場 今まで2chで答えてた人は 自己顕示欲を出したいだけなので、書きたかっただけ
しばらくしたらStack Overflowが日本に進出する予定だから質問する場ができるよ
アソコに日本語版とか必要なんかね。 そもそも日本語情報じゃなきゃいけない場合って、込み入った内容だし、コードで会話するのがエンジニアでしょ。 アウトプットの場所はあって良いけど。
人がいないわけではなさそうなので せっかくだから質問してみる artisanコマンドの中で use Menber; と書いたらしかられた modelsをロードするには、何をおまじない書いたらいい?
>>106 いや、そういう問題じゃなく(typoはあやまるが include_path通しただけじゃだめだよね >>107 あ、include_pathもuseもなしで、いきなり使えるのか やられた! ここよりもgoogle グループで質問したほうが人はいる
>>90 日本ではPHPで開発する機会が減ってるからPHPのフレームワークネタはもう盛り上がらない ITに限らんかもしれんけど、アメリカにワンテンポ遅れて流れが来る感じだね Laravelも来年あたりから本格的に来るのかねー ところで、githubあたりでそれなりの規模のあるアプリのプロジェクトとかってないかな? 他の人が、どういうふうに書いてるのか読みたいんだけど サンプルに毛が生えたやつしか見つけきれん orz
>>112 そんなに多くの企業がRails使ってんのかな ていうか、cakeがはやったのが、信じられない (はやった理由は理解してる)
Railsは流行りにのりたくて使ってるだけの会社、個人が多い気がする
1回は使ってみるものだろ。 Rails以降のフレームワークのほとんどは、フォロワーとしてアンチとして何かしらの影響受けてるんだから。
cakeもrailsもアーリーアダプターは良いけど、レイトマジョリティは全体的に低レベルでウンザリする。 そんな中、ここの皆はLaravelのアーリーアダプター。知見を集めて一歩先んじておこう。
小規模開発ならphpで十分と思うがどうだろう?レンサバも安いし
Laravelいいなーと思ったけどちょっと遅いな…
大規模で自由度のある仕組みはリーダーの統率力に左右されそう
>>104 コードで会話。わかるわ〜。 英語のブログの文章読むの辛いがコードが書いてあると読みやすくなる >>125 $you = 'shit'; とか $var1 = 'fuck'; $var2 = 'you'; echo $var1 . ' ' . $var2; とかね GoogleのトレンドでLaravelが急上昇だと知り、マニュアルをサクっと 読んでみたのだが、何がよいのかわからなかった。 CodeIgniterから乗り換えようと思ったんだけど。 そんな僕に、Laravelの良さを教えてください。
buckbitとかでgit管理したlaravelぱねぇ 開発クローンの作成やメンテが瞬時だ (composerの実行時間は除く)
>>129 オワコンフレームワークを使い続けるのは、いつか破たんするから。 ぶっちゃけると既存のPHPフレームワークの中では一番Railsに近いからw つまりLaravelの良さはRailsの良さと直結する RailsいいけどRubyだから環境を選ぶからなぁ って人がこぞってLaravel使ってるんじゃないかな 特に海外は。
Railsクローンだけど、Railsよりシンプルでいい
Railsに近いから良いと言われても、Railsを知らないのでワカリマセン・・・ Laravelのどこがいいのでしょうか? ・・・と質問しても、なかなか一言で答えられるようなモノでは ないですよねきっと。
マジックメソッド祭りでエスパー能力が鍛えられる コードリーディングし辛すぎ泣きそう
ソースコードの読みやすさも売りの一つだと思うけどね
皆様ありがとうございました。 とりあえずお盆やすみは、Laravelマニュアルを読んで、 動かして見ます。 ありがとうございました。
PHPもLaravelも初心者です。以下、質問です。 ORMとクエリビルダーはどちらを先に覚えるべきなんでしょうか。 セオリーがもしあるなら知りたいです。特にないならクエリビルダから触ってみようと思います。
>>144 同時一択w モデルはORMで書くぺき しかしstatic関数やコントローラーではビルダーが必要 今日明日というスパンでいうなら、ORMからってこと どっかにサンプルいっぱいあるサイト知らない? 公式は見たけど、いまいち使い方がわからん。
>>152 ありがてぇ、ありがてぇ 早速見てみる。 なんだかこれ、理解するの難しいな。 解説日本語だけど、専門用語多くて、いまいちわからんw
Eloquent難しすぎワロタw 解説読んでも全然意味わからねーww
初めて入れてみたけど最初全然わからない fuelphpを入れてみてそのマニュアルからやっと構造が見えてきたけど public/index.php をアクセスするなんて推測できなかった もうちょっとなんとかならないか 一番最初だけにかなり損しているのでは?
public/index.phpにアクセスするのがそんなに変か??? 外に見せるものだけpublicに置くのは当たり前だし、普通のPHP有効なWebサーバならindex.phpがDirectoryIndexになってるだろうし。
これ、マニュアルこれでええんか? 丁寧に翻訳されてるのは嬉しいが、これだけじゃさっぱりわからん。 テンプレートに関するところなんて、これで理解できるわけ無いだろう。 http://laravel4.kore1server.com/docs/42/templates 「layoutプロパティーをコントローラーで指定すれば、指定されたビューが生成され、アクションからレスポンスが自動的にリターンされます。」 って、日本語でおkって感じなんだがw しかも、仕方なく解説サイト見ても、1つ2つ前のバージョンのものしか見つからず、 書式が変更になってて全然動かんし…。 やっぱりこういう時に活発なフォーラムが必要と痛感するわ。 >>156 全然わからないという気持ち、よくわかるよ。 最初は、F/Wはとてつもなく難しい。 さっぱり分からなくても、すこしづつやって、「動いたよバンザイ!」って気持ちを その都度その都度持ち続けられれば、そのうち使えるようになるよ。 そもそもWebアプリを開発するには、PHPの文法、HTML、Webサーバの構築、 HTTPプロトコルの理解、リダイレクトの理解、アクセス権の理解などなど多くの 知識が必要で、Winアプリの開発などとは比較にならないほど大変なのよ。 開発環境を作るだけでも大変なの。 がんばれよ〜 >>158 テンプレートのマニュアルは、これで必要にして十分だと思うけどな。 > layoutプロパティーをコントローラーで指定すれば、指定されたビューが生成され、 > アクションからレスポンスが自動的にリターンされます。 的確な解説だと思うが、F/W初心者にはわからないかもしれないね。 「日本語でおk」って気持ちはよくわかる。 文章にいちいち文句言わないで、とにかく動かしてみるのが良いと思うぞ。 いや、別に文章には文句言って無くて、 これだけだと全然テンプレートの解説になってないってことを言いたいわけよ。 Bladeテンプレートの方はたくさん書かれてんのに、この解説だけすげー投げやり。 そして試しにテストしながら動かしてんだけど、 これでは何をテストしていいやらそれすらわからんということ。 そもそもビューの使い方は「View::make」で指定するんちゃうんかい! 全然自動ちゃうやんけ! ただコントローラーにビュー指定してんのとテンプレートとなんの関係があるんだよ。 と、思ってるところ。
これってルーティングとかキャッシュされてるってことある? XAMPPでテストしてんだけど、さっきやって動かなかったやつが、急に表示されたりするんだけど… 単なるスペルミスかな?
確かに初見でこの例だけ見ると混乱するかも ビューとレスポンスの章のビューの部分を既に読んでView::makeしてreturnする普通の手法は心得てるとして http://laravel4.kore1server.com/docs/42/responses テンプレートの章では@extendsによる拡張の説明&共通レイアウトの分離の例を出してから コントローラーで継承するレイアウトを指定してcontentにテンプレートを割り当てる便利な方法もあるという流れのほうがすんなり入りそう FWの歴史を考慮すればコントローラーレイアウトが基本なのかもしれないけど 個人的にはあまり使わないんだよなあ 自動的にリターンってところの解釈の違いか? コントローラーアクション内で明示的にレスポンスをreturnせずとも レイアウトにコンテンツのテンプレート突っ込んどくだけで 後はよしなにやってくれるというだけの話なんだが
ふー、やっとブレードレイアウトも全体像がわかった。 なんでもっと分かりやすく解説してくれないんだろう。 わざと分かりにくく書いてテストさせようとしてんのかな?
このF/W使うとコーディングが楽しくなるというウリらしいけど。。。 ちょっと見た限り、メソッドの名前にクセがありすぎ。 楽しくなるどころか、とてもじゃないけど苦痛になりそうだな・・・ FuelPHPとかCodeIgniterのほうが、よっぽど素直。
将来性なんて、どんなFWも”どんぐりの背比べ”だと思う。 今はLaravelはトレンドかもしれないけど、1年後には廃れる気がしている。 FWを選ぶなら、今現在自分にとって最高と思えるFWを選ぶべきじゃないかな。
安定性でいえばzendしかないが糞めんどいからな 今アメリカじゃlaravelとphalconって大方独占してるらしいけど 両方とも新規すぎて何とも言えないね
これってルーティングをgroupでまとめてgetとか書いていく方法と、 コントローラーでrestフルに書く方法あると思うんだけど、 どっちがオススメとかある?
個人的にはコントローラーでまとめてgetIndex()とかpostProfile()とか指定するのが楽で好み ドキュメントにはImplicit Controllers(暗黙的なコントローラー)と書いてある ルーティングを一覧したい派には不評みたいだけど
ミドルウェアって、 「HTTPなんてリクエスト送ってレスポンスが返ってくるだけだし、フィルタみたいな感じで処理挟めるんだから、じゃあそれをフレームワークに依存しない共通のインタフェースで書こうよ」 ってこと?
Laravelは、Symphony兄貴にのっかてるだけだが。 PHP本体に入ることはなくても、PSRみたいな感じでまとまっていくのかな。
Eloquent が気に入った whereHas() が where (select count(*) ...) >= 1 みたいなうんこSQLになるけど この辺りは今後に期待してる
>>172 ありがとうコントローラーでまとめてやってみるわー。 1ページにまとまってるサンプル見ると、一覧性があるというけど、 そのぶんごちゃごちゃで内容把握しにくいよね。 作った本人は完全に理解してるから気にならないだろうけども。 ふー。 やっとログイン機構と、メールでの登録確認まで出来た…。 あとはユーザーページと、投稿画面、一覧表示だな。 先は長いぜ…。
投稿画面、確認画面、データベースへの書き込みまでオワター。 データベースの連動と、ログインしている場合と、してない場合の振り分けがメンドイ…。 匿名ユーザーの投稿とか実装するとメンドイのね。 みんなはデザイン抜きで、ブログシステムを作ったりするのにどれくらい時間がかかるものなの?
Webサーバ側の設定だと思うんだけど、Laravelだけで何とかできるんか?
ん?public_html/test/public みたいになってんのコレ?
確かにハウツー本って普通立てかけたり、 テーブルに置いたりして見ながら進めるから、電子書籍だとすげー使いにくいよな。 アイパットとかあるならいいが。 辞書みたいにプロパティ全部網羅とかなると、今度は検索使えるから電子書籍が断然有利だけど。
同感! リファレンスなら電子書籍のメリットがあるけど。 入門書は絶対に紙の本がいい。 電子書籍じゃ使いにくいし、読んでも頭に残らない。 CakeやFuel並の書籍は出ないかな・・・
これ、ルーティングって内部的には何をしてんだろ? 単純にApacheのRewriteみたいなことしてるだけかな?
ふー。タグ一覧の実装がやっとこできた。 データベースの設計から考えないといけないから大変だ。 って言っても、ネット上の情報探して真似するだけだけどw
これルーティングって上から順番に評価されるって普通なの? サブディレクトリ作るのにroutes.phpでグループ化して / /hoge だとエラーで /hoge / の順番に記述すると正常にできるんだけど…。
最長一致になって欲しい気持ちも判るが パフォーマンスを考えたら我慢できるレベル
あ、そうなんだ普通なんだ。 いやさ、 / /hoge/tag /hoge/category /user /user/{id} みたいな感じで書きたいじゃん。 単純に見やすいし。 それにしてもEloquentってこれ、便利なんかな? やっぱり覚えたほうがいいの? 「美しくシンプルなアクティブレコードによるデーター操作の実装です。」って言われても、 そのシンプルに書くためにモデル作って、書式覚えて、1度書いたSQL文を変換してってなると、 なんか余計な手間のほうが増えてる気がするんだが…。 っていうか、サブクエリの方法がわからん…。 そしてEloquentってそもそもなんて発音するんだよw
アクティブレコードやORMってのはオブジェクト(or モデル or エンティティ)が先に存在して それを永続化する際に保存先のRDBとインピーダンスミスマッチを起こすからその面倒を引き受けてやるよって話であって 逆にRDBやSQLありきの単なるラッパと思ってるならそりゃあ存在意義もわからんだろ ほとんど作らないだろうがオブジェクトをDBに永続化する必要のないアプリケーションだってあるわけよ
なんだー、Eloquentでサブクエリはネストするだけか。 何時間も使っちまった。 $results = Post::whereIn( 'id', Postmeta::where('meta_value', $tag)->lists('post_id') )->paginate(2); 絶対需要多いと思うだけど、なんで解説に書いといてくれないんだろ。 しかしインピーダンスミスマッチなんて言葉初めて聞いたわw SQLでデータ取ると加工が面倒だけど、そのへんの面倒を見てくれてるってわけね。
オブジェクトを単に入れ物に出し入れするがごとく DBへの透過的な永続性をORMに担ってもらうことで プログラマはオブジェクト指向プログラミングに集中できる 俺も経験あるがORM使う以前ってRDBの奴隷として調教されすぎているんだよな ORMなんてSQLも使えねえゆとり用じゃねーかwwwと馬鹿にするやつもいる もちろんライブラリが自動でやる分パフォーマンスの問題が出ることはあるから SQLやRDBの知識が要らなくなるというわけではないんだがな 暇があったら他のORMも調べてみるといい Symfony2のDoctrineの説明はわかりやすい http://docs.symfony.gr.jp/symfony2/book/doctrine.html Laravelに限ったことではないのですが・・・ Webの一覧画面、登録画面、修正画面、削除画面の遷移方法について質問です。 各々の画面遷移をPOSTでやるのかGETでやるのか、常套的な方法がありましたら 教えてください。 またエラーメッセージの画面間の引き渡しはフラッシュデータを使うのが常套手段なの でしょうか。
HTTPメソッドは冪等性と安全性によって使い分けるのが一般的 冪等というのは同じ操作を何回行っても結果が同じということ 安全というのはサーバ上のリソース(大抵DBと対応)の状態を変化させないこと ・冪等 かつ 安全 GET HEAD ・冪等 かつ 安全でない PUT DELETE ・冪等でない かつ 安全でない POST ・POST→リソース新規作成 ・GET→リソース取得 ・PUT→リソース更新 ・DELETE→リソース削除 という風にCRUDと対応付ける実装が多くLaravelの標準も同じ ※PUTとDELETEはHTMLのformが対応していないので隠しパラメータで擬似的に表現される Laravelが用意しているリソースコントローラーのアクションの命名規則とHTTPメソッドの使い分けが参考になるだろ 実際にリソースを新規作成したり更新するリクエストはPOSTや(擬似)PUTだが それらのリクエストを発するための新規作成画面(createアクション)や編集画面(editアクション)を表示するのはGETだな http://laravel4.kore1server.com/docs/controllers#resource-controllers リダイレクト云々についてはGeneratorのControllerのScafolding見てみたら? https://github.com/JeffreyWay/Laravel-4-Generators postで画面描画しないよう徹したほうがよいよ postメソッドは、エラー時もOK時もredirecrして必ずgetメソッドで画面描画 withInput()とwithError()が効率的に使えるし ブラウザの戻るボタンで戻れるウィザードにもなるから テンプレートにflashメッセージとflashエラーの描画入れとくと、いれいろ便利
>>205 、206 すばらしい回答ありがとうございました。 両回答とも、知りたい事のドンピシャの回答で、よくわかり、大いに納得しました。 ご回答をふまえて追加で質問させてください。 修正画面を表示 ↓ OKボタンが押される ↓ バリデーションエラーで修正画面を再表示 という画面遷移を考えたとき、修正画面に表示するレコードのID等を引き回す必要が出てくると思います。 このIDの引き回しは、<input type="hidden"> で引き回すのが普通なのでしょうか? (つまり修正画面に、<input type="hidden"> を入れる) それとももっとスマート?な方法があるのでしょうか? レコードのIDの値はURLに含めるほうが楽じゃない? リソースフルコントローラーの規則に合わせるなら 修正画面(edit): GET /resource_name/{id}/edit 更新(update): PUT /resource_name/{id} としておく まあIDに限らずユニークなフィールドでレコードを特定できるならなんでもいいんだけど 修正画面のformからPUTしてupdateアクションでバリデーションが通らなかったら withInput()とwithErrors()を利用してeditアクションにユーザの入力値やエラーを渡しつつリダイレクトする editアクションではInput::old()が空じゃなければそちらの値を優先して表示 探してみたらベストプラクティスの考察記事もあったよ http://qiita.com/asaokamei/items/e5070f9fad4c91e52bdc >>202 ありがとう。まずはEloquent理解してからだわw しかし今まで作ったやつEloquentに書き換えてるけど、 実際使ってみると確かに楽だわ。 クエリースコープ便利すぎワロリンコ >>208 >レコードのIDの値はURLに含めるほうが楽じゃない? こうすると、修正画面に遷移する前の画面(つまり一覧表示画面)で、修正するレコードがどれかを 判別し、そのIDをURLに入れてsubmitする、という javascript が必要になります。 修正画面にはPOSTで遷移すればjavascriptを書く必要がないのでシンプルで良いと思った次第です。 しかし、紹介していただいたベストプラクティスを見ると、バリデーションエラーになって元画面を表示 するのに、 return Redirect::back(); という方法を採っています。 この方法、シンプルですね。 やはり修正画面の表示はGETに統一し、上で書いた javascript は必要、と考えたほうがよい気がしました。 すみません訂正です。 FORMをGETでsubmitしたことがないので間違ったことを書いたかも。 GETでも javascript は必要ないですね。
普通にaタグでリンク辿ればGETになるだろ何言ってんだ
Aタグ!? そう言えばそうですね。 チェックボックスをチェックして修正ボタンをクリック、ばかり考えていましたので。 ただ、修正画面ではなく、複数選択して次の画面に遷移する画面もあると思います。 そんな時はやはりAタグではなくチェックボックスだと思います。 すると、FORMでGETメソッドですよね。 あ、GETではパラメタサイズが制限されるから、チェックボックスで複数選択のときはPOSTなのかな。
後付で条件変えられても…… 最近のGETパラメータのサイズの制限はそんなに厳しくないと思うけど
同一IPによる連投禁止って、データベースにIPと作成日を保存しておいて、 バリデーションのカスタムフィルタ作ってValidator::makeするって感じしかないのかな? そういった普通に使いそうな便利ツールまとめたライブラリとか無いのかな?
ごめん、普通にCookieでやればいいのか。 新しいこと頭に入れすぎて混乱しとるわw 失礼しやした
>>214 後付条件になってしまい、すみませんでした。 204の質問に対して205, 206の回答をいただき、 DBに保存しない処理は「GETで統一がいい」と納得しました。 しかし、画面によっては複数のチェックボックスにチェックして「修正する」ボタンを 押すような画面もあることに気づき、その結果、後付条件になってしまいました。 ご勘弁ください。 >>215 同一IPによる連投禁止は、プロキシを介してリクエストしてきたとき 実際に端末は違っていたとしても同一IPになってしまうよ。 >>218 ですよね。 っていうかCookieでも毎回消されたら意味ないけどw まあ、ただの投票ボタン付けるだけだから 厳密に規制したいわけじゃないからいいんだけどね。 ふーい、やっとこコメントへの投票と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が優っている理由を具体的に教えてください。
確かにマニュアルは分かりにくい。 昔のマニュアルにあったのが、新しいマニュアルで削除されたりしてる謎。 変なとこだけ冗長だったり、肝心のところがなかったりする。 ただ、実際書いてみると「なるほどね」って機能が多いよ。 実用的なチュートリアルも無いし、日本ではまだまだこれからって感じだね。 とにかく手を動かして、ダメなときは海外のフォーラム覗いて、 既に公開されてるソースを眺める。 今のところこれしかない。
>>230 誰それ?初めて見たが…。 一応迷惑かかるとあれだから否定しとくわ。 てかさ、サイドバーを付けたいんだけど、 これってメインのコンテンツ表示してるコントローラーでサイドバーについてもデータ渡すの? せっかくbladeのViewでインクルードしてんのに、意味なくね? sidebar.blade.php側でコントローラーのデータ読み込んだりできないのかしら? >>231 blade側でやるのは、メニューデータのforeach展開だけ メニューデータ取得は、全コントローラーで継承するベースコントローラーでしょ >誰 うん、DOSやパソ通しらなきゃどうでもいい >>232 なるほど、こういうときにベースコントローラー使うのか。 何のために継承してんだかわからずおまじないとして書いてたけど、そういうことね。 ありがとう。 ビューコンポーサー試してみたけど、利点がわからんな…。 特定のビューが呼び出されると一緒にレンダリングされるってだけでしょ。 デフォルトでroutes.phpに書くって意味もわからんし、 逆にどこに書いても良いって言われても置く場所困るわ。 分けたところで作った人しか場所がわからず見通しが異常に悪くなるし…。 っていうか、デフォルトでroutes.phpに書くってマニュアルに無いのはなんでなんだ? ホント歯抜けの多いマニュアルだよなこれ。
ふーい、なんとかサイドバーも終わった。 あとはユーザーページと ログインユーザーとゲストの表示の調整だけだ。 これでやっとコーディングやらデザインに入れる…。
バリデーションエラーになって、元画面を再表示するとき、 POSTされた入力値を再表示画面にセットしたいと思っています。 テキストボックスに再表示する方法は old() でできますが、 リストボックス、チェックボックス、ラジオボタン のセットは どのように行ったらよいのでしょうか?
>>237 ->withError()するだけじゃん getで初期値いれとくだけで何も考える必要ない >>230 のリンクみてる? 「Laravel 4 Cookbook 日本語版」って70%で止まってるけど、もう翻訳されないんだろうか? 最初に買った「Laravel4でこなすプログラム術 Getting Stuff Done」 はとても良かったんだけど DB系の機能に一切触れてなかったから次はCookbook買おうと思ったんだけど翻訳止まってるんだよね… 「Code Bright」はマニュアル程度の内容だったし…
Code Bright のP28 Composer ガオーとロードできるように・・・ なんだよコレ。。。 日本語なのに翻訳が必要じゃねーか。 ところで入門書としてのお勧め書籍を教えて!
入門書なぞない。 マニュアルと、海外gitとかでいろいろアップされてるからコード見て勉強だ
laravel関係ないけどさ、コントローラー名やらメソッド名とかって ガンガン長くなちゃうんだけど、どうしたら良いの? 意味はわかるように出来るだけ短くとか、ドヤ顔で解説してるところあるけど、 それができたらわざわざ質問しねーよとw ハイフンで区切ったり、アンダーバーで区切ったり、大文字にしたりあるけど、 なんかフレームワークによってバラバラだし、好きにしていいよってことなんかな?
20文字以内なら許容範囲と思うかなー 昔のハンガリアン記法チックな名付けしたりして 辺な短縮するよりわかり易いほうがいい。 エディタの補完機能あればタイプミスはまぁ発生しないし。 20文字超えだすと一行内に収まらないコード続出で可読性が正直落ちる…
「Controller」だけで11文字もあるんじゃん。 長くても、後で意味が分かるほうがいいと思うけど。
20文字は厳しな。 いま見てみたら25文字のファイルあった。 まあ長くてもわかるほうがいいか。どうせ自分で使うんだし。 あと面倒だとint、str、val、key、arr、とかつけるけど、 あとで見ると何だったかわからなくなる罠w こういうのって、なんかルールほしいよね。
ここもなんだかんだで伸びが早くなってきてるな。 そろそろ日本でも本格的に広まってほしい
いやーしかし覚えないといけないこと多いね。 リンク生成するだけでも一苦労だわ。 別に普通に相対URL書いてもいいけど、それだと負けた気がする不思議。 そして恐らく関数使ったほうが遅いというパラドックス…
>>250 同意。 しかも、http:// からの絶対URLだと、Webサーバの前段にロードバランサなど入れてあると ダメだったりする。 相対URLのほうが良いと思うなあ。 相対URLを取得する関数はないのかな? "{{url()}}/admin/hoge" じゃだめなん?
だめ、正しくは {{link_to('admin/hoge', 'ほげに移動')}} 理由はなんか負けた気がするからw
アプリの中なら、URL::to()とかHTML::LinkRoute()とかを使う。 これらを嚙ますだけで「遅い」とかぬかすなら、端からFWなんか使うな。
>>254 端からFWなんか使うな、なんていう前に、 URL::to()を使うメリットを語ったらどうかな。 それとも貴方は道具に弄ばれてる馬鹿ですか? CodeIgniterからのスキルの引っ越し先としてLaravelに的を絞って学習を進めてきた。 結果、あまり良さを見せなかった。。。 良いと思ったのは、Routerの機能、Bladeの簡潔さ、withInput()、withErros、old()、くらい。 Queueも良いと思ったが、自分で作ればいいやと。 特に自分の場合、過去の資産の関係からテンプレートをBladeではなくSmartyに したいため、Blade依存のwithErros、old()などは意味がなくなってしまう。 また、V3からV4で仕様がかなり変わったようだし、V5でも仕様が変わるらしいので、 長期に亘り安定的に使うのはダメだな、という印象です。 LaravelはGoogleトレンドでは高ポイントだが、それを鵜呑みにしちゃダメでした。 日本語マニュアルもダメだし、業務に採用はできないな、と思いました。
>Blade依存のwithErros、old()などは意味がなくなってしまう。 ???
>>255 リンク全てをハードコーディング。。。 アホですか。 >>251 ロードバランサやWebサーバの設定でなんとかなるでしょ 担当範囲外でいじれないって話ならご愁傷様 アプリのrootをDocumentRootにしとかないと、嵌ることがあるな。 ドキュメントに明確に書いてはいなかった気がするし、絶対に動かないわけではないので、余計に厄介。
公式ドキュメントはそもそも方針として網羅性を重視していないんじゃないの? 歯抜けと言われればそうだね〜としか ドキュメントの充実度を評価の基準の1つにするならYiiなんてどうよ? 最近出た2の翻訳はまだだけど概念の説明から細かいところまでかなり揃ってる印象
間違えた。アプリのrootじゃなくて、publicね。
それまで何を使ってきたかでLaravelの評価わかれるみたいねー 俺みたいに Rails使ってきた人には高評価 偽RailsなCakeのクソさに苦しめられてきた、やっとホンモノのRailsライクなフレームワークが来た!みたいな感じで。 逆にFuelみたいな軽量系や、CodeIgniter みたいに小さな部品を組み合わせて作る系のフレームワーク使ってた人は 微妙って感じの人が多い
>>261 , 263 このスレだけでも困ってる奴2人はいたな 大抵のフレームワークにエントリーポイントとなる1つのファイルがあるってわかってりゃ publicがDocumentRootかどうかって些細な話だと思うけど PHP初級者がFWデビューしてハマったら辛いだろうな DocumentRootがいじれない共用サーバへの設置とか >>262 Yii のマニュアルは、かなりイイ! と俺も思うよ。 codebrightの翻訳版誤字多すぎじゃない? 訂正の要望出したら直してくれるかな
>>264 >偽RailsなCakeのクソさに苦しめられてきた、やっとホンモノのRailsライクなフレームワークが来た!みたいな感じで。 わかる 最近は苦しみ通り越してダメな子ほど可愛い的な感覚すらある CakePHP3がもう1年早ければ使い続ける選択肢もあったかな ふーい。やっと今日でシステム周りが全部できた…。 1から全部作るのに1ヶ月以上もかかっちまった。もちろん片手間にだけども。 マニュアル読む ↓ コード書いてみる ↓ マニュアルにない ↓ 海外の情報調べる ↓ 自分でまとめ直してコード書く こうしたプロセスをほぼすべての段階で踏んだわw
しかし全文検索の実装がくっそ簡単でびっくりした。 ルートで検索結果ページ作って、 ビューでブレード使って検索ワード渡して、 検索するテーブルのモデル作って、 コントローラーでエロクアント使って検索してまたビューに渡して、 またブレードで表示整えると…できあがり。 おまじない抜かしたら、実質10行くらいで書けるもんね。
Laravel5って今月ホントにリリースされるの?
カスタムでクラスとかメソッド作るときに一覧が無いから バッティングしてめちゃくちゃ時間無駄にした。 最低でもエラーメッセージで「バッティングして作成できません」って表示されればいいが、 hoge model not found…。 まあ作り方も当たり前のように本家のマニュアルに無いという徹底ぶり。 こりゃ早い時点でちゃんとしたドキュメント作れば売れるでw
お、ほんまやあった。 でもくっそ見にくいな…。 しっかしこの30点くらいのマニュアルはまじでないわ。 痒いところに全然手が届かん。 やりたいことができて見ても全く解決しないから 最初からググるようになってきたわw
Laravelのあのマニュアルが網羅性は重視してないのは確かだな あれだけ見ても分からないことが多すぎた どっちかというとクイックスタート的な感じ そう考えると手につけやすく分かりやすい部類なのかもと感じる アレとAPIリストの中間にある逆引き的なのがあればとは思う レシピ集はどっかにあったけど数が少なすぎ
>どっちかというとクイックスタート的 クイックスタートにもなってないと思う。 ほんとマニュアルがクソだと思うよLaravel。 マニュアルも成果物の重要要素なのに。 残念。
あれでわからないなら無理じゃない? マニュアルで不明な引数はソースみれば判明する
Laravel recipes も見なきゃいかんよ
困ったときはソース見て大体何とかなるから良いよな。 マニュアルは英語だからよくわからんしw
バリデーションのactive_url正しく動作しないじゃん。 checkdnsrrでDNSのチェックしてるだけかこれ。 っていうかDNSで名前解決しないサイトって何なんだ? CDNかなんかでも噛ませてんのかな?
フォーム作るときlaravelのメソッド使う? それとも普通にhtml使う?どっちがいいとかあるのかな
管理画面ならメソッド、ユーザー画面ならhtml あとはデザイナーにませるから 素のhtmlでもwithInput()あるから制御できるし
一部の機能(formのhiddenとか)だけlaravelのメソッドを使うソースとか見たことあるな。
用意された関数はひたすら使う。 これがプロのフレームワーカー
ららべるをメインに扱うようになった会社増えたね。 どうやら日本でも定着しそうだ。 海外のトレンドが日本でも定着するスピードが早くなった気がする。 ただしPython、お前は別だ!
>>ららべるをメインに扱うようになった会社増えたね。 ソースは?
いや、個人的に周りの会社がってことだけどw 新規案件から指定がなければララベルってとこ増えとる
これ別に、特筆して他のフレームワークより使いやすいってこともないね。 フォーム関連は便利かなってくらい。 まあ元々フレームワーク使う人は自分で何でも作るだろうから、 導入とアップデートが楽ってのが一番のポイントなのかな?
データベースのクエリはCache::putできねーのか。 「キャッシュにアイテムを保存するのは、実に簡単です」とか余計なこと書く前に、 こういうことも書いといてほしいな。 それかエラーメッセージでそれとわかるように表示してほしいわ。 実用的なまとめ本の出版が待たれる。
情報少ないって声が多いからブログに解説書こうかとも思うけど、 5.0で豪快に変わりそうだから書く気起こらんなw 4系って、結局どれくらいの期間もったの?
Laravel4.2 始めたばかりです。 テーブルのupdateしようとしたらupdated_atがないとエラーが出たので public $timestamps = false; をモデルに書けば怒られないとのこと。 それでも怒られました、updated_atを追加して動きましたが今後は追加したくない。 キャッシュか何か残ってるのでしょうか。
エロクアントで書き込むときはupdated_atと更新用のテーブル(名前ぐぐるのめんどいw)は 必須でっせ。 自動で更新日と作成日が追加される。 rowとかでSQL書けば必要ない。
モデルじゃなくてmigrationファイルじゃなかったっけ?
なんでlaravel.jpとlaravel.tokyoがあるんですか?
新しい解説サイト(個人的にすげー見にくい)や、レシピサイトもあるやで。 あと青っぽい解説サイトもある。 全部バラバラの謎。
知らんうちにフォーラムが.tokyoのほうにあるみたいだけど 開設当初.jpのサブドメインじゃなかったっけ? わざわざ分裂させて何がしたいの? せっかく流行ってきたのに銭の臭いがしていやんな感じですわ
銭なんて大して稼げんやろ。 WordPressとかならまだしも、フレームワークじゃ。 たぶん海外のこの仕組欲しいな。あのサイトに作ってくれないかな。 まあ頼むくらいなら自分で作れるからさくっと作ろう。 って感じのエンジニア特有のコミュ症が発症した結果だと思う。
tokyoの方初めて知ったよ 問答無用でSE鳴らしたり:hoverでリンクの文字サイズ変えるとか何時の時代だよ 公式じゃなきゃLaravelのアイコン外して欲しい
>>302 わかるwいきなり音なってびっくりした後に 「Laravelは最も洗練されたPHPフレームワークです。」 の文字見つけてイラッとしたw すいません質問なのですが、http://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に変えたり試したのですがダメでした エラーメッセージを見るにアクセスが拒否されたとのことなので、どこかで設定等しなければならないのでしょうか? テンプレートの画面出を変数に取得する方法がみつからない
$output = View::make('xxx.yyy')->render(); とかじゃないのか?
>>305 やや亀だけど databaseの設定が間違ってるかも app/config/database.phpのl設定を直すか、 手っ取りばやく試したいならdefaultをsqliteにすれば良いはず >>308 ありがとうございます sqliteにしてみたら上手く行きました 5来ないね なんかごっそり変わるらしいけど、どうなんかね? ちょこっと使いやすくするためだけに、それ以上の学習コストかかるようなアップデート無いことを祈る
artisanを触っててふと思ったのですが「php artisan up」や「php artisan down」は 一体どこで設定を保持しているのでしょうか。 app/storage内を見てもそれらしきファイルが見当たらなかったので質問させていただきました。 Laravelのバージョンは4.2.16です。
>>313 ありがとうございます。 ファイルの有無で判断しているのですね。 勉強になりました 自分で作ったshapeってクラスのインスタンスをeloquentの製品モデルに持たせ、 製品モデルに座標値をsetしたらshapeのプロパティも変化し、 モデルの座標値をgetすればshapeの方から取ってくるようにしたい。 shapeを作るのはfillメソッドの中でやり、座標値の読み書きは get[座標値名]AttributeとSet[座標値名]Attributeでやってるんだけど、どうにもうまくいかないのです。 てか、うまくいくんだけどモデルをsaveすると製品のテーブルでは座標値が全部0になっちゃう。 すごく苦しんでます。どなたかお知恵を!
自己解決 どうもアクセサもしくはミューテータのあるアトリビュートは toArrayの対象に含まれないようで 自前のtoArrayを作って追加したらおkですた お騒がせスマソ
自前のtoArrayも悪くないが attributesの対象を追加したり除いたりするメソッドがあった気がする
$attributesに追加しちゃうと、対応するカラムが存在しない場合、save()とかエラーになる気がする
>>318 今回はもともと対応するカラムが「ある」ケースなんですわ そして普通にsaveするだけなら問題ない でもtoArrayを通すと消えちゃうわけ そういう意味ではこういう時ミューテータやアクセサを使うってのが そもそも不適切なんだろうけど 特定アトリビュートが変化したとき副作用を起こさせる方法を 他に思いつかないんですわ なんかいい方法あるかな? 今回はShapeクラスのオブジェクトを製品モデルのプロパティとして持たせたけど Shapeをインターフェイスで書いて製品モデルに多重継承させるのが きっとスジなんでしょうね でもPHPのインターフェイスってなんか苦手でorz
>>321 そこにも書いてあるけどappendsは 対応するカラムが「ない」時に使うものなんだよね 今回はそうじゃないのでスジ違いかなと思いつつ試してもみたけど ダメだったんですわ しかしアクセサの書き方を間違ってたせいかもしれないので また今度試してみますわ、ありがとう Eloquent::$attributes に座標を入れずに保存してたりしてね
Single Table Inheritanceの機構を標準で持って欲しい ほとんど必須だと思うんだけどなあ
5出たけど、差分のドキュメントないからさっぱりわからんな。 動画は英語だし、テンポ遅くて見てらんないし。 まあまだ、これからかな。
ハマりどころに関しての対応策とか、そういう情報もまだ少ないから様子見てる
しかし4の情報は今後減っていくんだろうなあ 悩ましいところだ
Laravel4.2からLaravel5に移行しています。 DBに関してなのですが、データベースを使用するときは use DB; をしないといけなくなったのでしょうか。 use DB; をしないと Class 'App\Http\Controllers\hoge\DB' not found と怒られてしまいます。
>>329 そのファイルの先頭で、namespace App\Http\Controllers\hoge; って書いてあるからでしょ \DB::xxx() と呼ぶか、use DB; するかかな PHP自体の名前空間の勉強も必要かもね >>330 ありがとうございます。 名前空間に関しては調べてみます。 Laravel4.2の頃は余り意識せずに済んだので少し大変です。。 Laravel4.2で動いてるのを5に移して動かしてみた 結構変わってるね、フォルダの把握とか名前空間とか(\DBのままでいいのかな) 一番ハマったのがAjax時のエラー、結果的にcsrf_token()を埋め込むだけなんだけど Laravel初心者にはキツかった
5になって、何が良くなったんですか? スピード? 可読性? 機能UP?
CentOS6で動かしてる人います? PHP5.4以上って意外とハードル高いと思うんだけど みなさんどうしてるんだろう・・・ ちなみに俺はremiを使ってるんだけど yumに自動アップデートさせてたら今日おかしくなってしまった やはり非標準レポは怖いということか それとも他に要因があるのか はぁまじ()
自己解決 NetBeansのデバッグセッションを終了してなかったので CLI含めてPHPからの出力が全てリダイレクトされてた そうするとyum updateの対象にPHP関連が含まれてる場合 (というか多分更新にPHP自身の動作が必要な場合) yumが無言で止まってしまうんですな こんなことで凄い時間を使ってしまったorz
>>337 5.4の公式サポートも今年の9月で終わるのに大変だな(´・ω・`) remi で 5.4 使ってるってことは、 remi には remi-php55 と remi-php56 っていうレポジトリが別にあるの知らないのか /etc/yum.repos.d/remi.repo.rpmnew 見れば設定が書いてあるだろうから、 /etc/yum.repos.d/remi.repo に必要なところをコピーすれば使える
全部公式のパッケージ使うのなんて、むしろ稀でしょ。 導入時は一番最新のにしといて、あとはテコでもバージョンアップしないのがプロ。
最近PHPのリリースサイクルも早いし 標準パッケージで最新版かその前のくらいに追い付けるディストロに乗り換えたい
>>341 php関連ライブラリ(具体的にはphp-seclib-*)の アップデートも削除もできないようになっちゃったんだからどうしようもない とパニクっちゃった次第ですわ PHP5.4自体の削除はできても55や56を入れようとすると依存関係で跳ねられるわけわけ 原因がバージョン云々ではなくxdebugセッションの終了し忘れにあったことは前述の通り(お粗末) まあ今回の案件の実稼働環境はイントラのwindowsサーバなので 直接関係ないんだけどね そっちはそっちでXampp(php5.6)上のLaravel4だとApacheがコケる という問題が出てたりする 環境依存っぽいしphp5.4のWampなら大丈夫だから 何とかなると踏んでるんだけど気になるっちゃーなる belongsToのリレーションを持つモデルをセッションに保存しておいて それを取り出すと ちゃんと正しいクラスのオブジェクトではあるのに リレーションが取得できない状態になるんだな $my_model = new MyModel(Session::get('my_model_name')->toArray()); 等とすれば大丈夫 これ仕様なんだろうけどバグといえるレベルなんじゃないかと ちなみに4.2
リレーションが取得できない状態というのがよく分からん
>>345 4.2で試したけど普通にリレーション取れたよ ダメな状況がわからん 名前じゃね? 4.1の頃の話だけど、モデル名にアンダーバーが使われてるリレーション貼ると取れなかったり 値をセットできなくなったりした シンプルな post 1-N comments なら相互に取れるんだけど post 1-N user_comments だと ダメになったりした
>>347 モデルをテーブルには未セーブ、つまりIDがない状態でセッションに入れるとどう? IDがないとhasOneはもちろん無理だけどbelongsToは可能 それがセッション通過後だとnullになっちゃう >>349 名前か、確かにリレーションは複合語ばっかりだからあるかも Laravel5日本語マニュアルをローカルPC にダウンロードしたいのですが、丸ごとダウンロードはできるのでしょうか?
>>349 未保存でそのままセッションに入れて別ページで取ってみたけど、問題なくbelongsTo先は取れたよ。 アンダーバー有りは試してないからそれかもね。 モデル名に複合語つかってると、前者と後者のモデルの区切りを識別できないのかね? なんかおかしな挙動になったのは覚えてる
>>351 検証ありがとう。でも名前は関係無いようだ。そして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では永久にリレーションができなくなってしまう。 結構イヤな挙動だと思いませんか? >>353 使い方が悪い > When updating a belongsTo relationship, you may use the associate method. Laravelは(というかORMのEloquentは) $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 のオブジェクトが戻されるため いかにも自動的に変わったように錯覚してしまう。
オブジェクトをセッションに保存するなら、そのオブジェクトのIDだけ保存した方がいい
>>355 丁寧にありがとう。 ・null値も「存在するプロパティ」の扱いになる ・存在確認のために参照するだけでnull値が入る というあたりがなんともモヤモヤするところではありますな。言語仕様的に。 「セッションにモデルを持って複数フォームで順次更新、最後にテーブルへ書き込み」 という流れは割と普通にやりたくなるところだと思うけど、 それはあんまりLaravelish wayではないということなのでしょう。 __wakeupをオーバーライドしてリレーションを取得させるようにすれば テーブルへの書き込み->読み出しを経た場合と挙動が近くなると思うんだけど、 そう簡単なもんでもないのかな。 というか未定義プロパティにアクセスした時にnull値をセットしてるのがマジックメソッドの中でなら、 それをやめてくれるだけでいいのか。 そうすれば少なくとも初回のキー値代入で常にリレーションはできることになる。
毎回取得してたら遅くなるから、一旦内部で保持しちゃうのかな とりあえず、後から $phone->user_id = 1; としたら、その直後に $phone->load('user'); ってすればいいなら許容範囲な仕様だと思うけどね
>>359 わかってしまえば対処は楽なんですけどね。 新規作成はnew Model(Input::all())で問題ないから、 更新もfill(Input::all())で済ませたくなる。 で、その前にリレーションを一度も参照してなければなまじ動いてしまうもんだから すっかり混乱してしまった次第。 こんなんで丸一日とか潰れちゃうんだよな・・・orz 公式ドキュメントのdynamic properties
modelとcontrollerの書き方について教えていただけませんか。 特定の条件を入力して検索機能を作る場合、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'; }
>>355 これめっちゃハマりどころじゃね? 普通きづかんだろ >>367 リレーションの仕様を理解していないだけの話だよ そもそもプロパティなんて作らん、リレーションのキャッシュが働いているだけだ 裏で何が起きてるのか理解してないと使えないような機能なら 公式ドキュメントのよっぽど目立つところにそういう説明がないと まあ普通にハマる人は出るわね 結果「使えねーフレームワーク」という評価が広まることにもなるかと 実際俺はそうなりかけてたよ
>>368 リレーションをプロパティ(PHPのプロパティでもあるしLarvelのDynamicPropertyでもある)を使って実装してる >>371 何を言いたいのか判らんけど間違ってるのはここ >>355 > プロパティ 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が入っちゃうわけ デバッガ通すと挙動が変わるってのは少なくとも開発に優しくはないと思うよ
>>373 なんで>>355 みたいな事言ってたのか判った気がするわ $relationsがキャッシュの入れ物なのに他のプロパティ監視しててもブレークする訳ないさ 一度Modelのソースを読んだ方がいいよ 話にならんな 俺は355じゃないし ソース読まないと使えないようなフレームワークなりライブラリは そもそも使う気にならんという ごくヘタレなプログラマでしかないよ Laravelの開発者もユーザーに「一度ソース読んでみたら」 なんて平気で言うような「情強」じゃないことを切に祈るわ まあでも元MSの人なんだっけ? じゃ典型的な「情強」()なんだろうなきっとw
ソース読まなくていいフレームワークを教えて欲しい あればそれを使いたい
罵り合い的なのは良くないな この問題にどう対処するかの実際のとこが知りたい ってことでざっと Eloquent/Model.php まわり読んでみたけど >>355 の解釈であってるように見えた __get をオーバライドして、メソッド setAttribute を呼び出してる。 setAttribute内で呼び出しプロパティ名をメタプログラミング的にメソッド呼び出ししてる。 hoge->user; だと user() が呼ばれるようになってる。 それがたまたま以下の様な リレーション定義だと BelongsToオブジェクトが戻されてる(Userじゃない)。 fucntion user() { return $this->belongsTo("User") }; protected な $relations って変数もあってリレーション作る度に そこに配列として格納されてるけど、 以降 hoge->user にアクセスした際は、$relations は見ずに やっぱ単にプロパティにアクセスされて 先述のBelongsToオブジェクトが戻ってるように見える。 っていうか hoge->user にアクセスした際に、その都度、 $relations の中身を戻すのって 原理的に出来るのかな? もっというとプロパティを呼んだ時に、メソッド呼び出しに置き換えられるのかなって話になるのか。 でもそれ出来るなら >>353 みたいな問題おこらんよう気も・・・ まだ検証してないけど hoge->user というプロパティ形式じゃなくて hoge->user() で必ずメソッド形式で呼ぶといいのかも 副作用があるかもしれんがw
>>379 それは大丈夫だろうなあ 検証してないけど イマイチ名前空間についてが理解できん。 書かなくても動くのと、動かないのがあるのは何でなんだぜ?
それだけ言われてもな 他の主流な言語の名前空間とだいたい同じだし
useで名前空間を指定していても 変数名にクラス名を入れてnew $class_nameなんてやるときは フルパスを入れないとダメなんだよな かなりもにょる仕様だと思った
ワイルドカードによる指定ができないのは結構痛いかも
エイリアスは登録してるんだけど、 カスタムコマンド作ったりすると、結局書かないと動かないでしょ。 どっかで他にも設定するところあるの?
動かないパターンの具体例が無いと答えられる人いないんじゃないか?
ドメインキングとかいう糞鯖だからssh使えないんだけど、sshなしじゃデプロイできないよね? 試しにディレクトリ全部ftpでアップロードしてみたけど動かなかった
ファイル全部ありゃ動くと思うがな まさかapp/storageのパーミッションを設定してないとか
>>366 すみません、凄い遅レスなんですが、返信ありがとうございます。 ドメインキングって調べたらPHPが5.3だな LaravelはPHP5.4以上が必要
5.3系のバージョンアップはもうないって意味ならそのとおりだが XPとかのサポート切れとはまた意味が違う気がする 安定しててセキュリティに問題がなく新機能が不要なら ずっとそのまま運用して別に問題ないんじゃね?
脆弱性が発見された時に、詳しい人がすぐに対応できる体制が整ってるならいいんだろうね
そもそも無料なんだから問題出たら5.4以上に移行してね、で済む話ではあるんだがな 移行にあたって互換性の問題がある?そもそも無料なんで我慢してね、って話でもあるし そもそも無料なんだからサポートってなにそれ美味しいの?って話でもある
>>394 わざわざ調べていただきありがとうございました Laravel5のスケジュール機能ってWindowsではどうなるんだ? ちょっと調べた範囲じゃcronの話しか見つからなかった
さすがにWindowsは対象外じゃね 誰かが 記述はそのままに、 Windowsのタスク機能を呼び出すようにするプラグインは書いてくれるかもだが
いやcronやタスクスケジューラから呼ばれる側の立場だろ Windowsでも日に一度より多いタスクを定義できるようだが 普通にやってできないのは痛いな あと5分置きとか可能なのかはわからん
WordPressみたいにアクセスされたのをトリガーにする擬似cronってのもあるからね。 いや、調べてないから全然わからんけど。
重い処理を夜中にやっときたい とかって需要だと アクセスされたタイミングでしか動かないのは困るな Windowsサーバなんて排除の方向なら それはそれで異論ないがね
Laravelのコマンドとして作っておけば、Windowsのタスクスケジューラ的な機能でそのコマンドを実行させるのは大した話しではないような
今更Laravel4入れるのって、出来ますか? 本やサイトやVagrantやら、みんな入れたら5になっちゃうんですが…
レン鯖のPHP古いの多いからなー 4.1 まででないと動かないとこ多いよな・・・ムカつくぜ でも 普通に composer.json で Laravelのバージョン指定すればいいだけじゃね
>>406 タスクをひとつずつ登録するんじゃ楽しくないわけよ 5分ごとのcron一つ作ればあとはLaravel側で済む ってのが売りだからさ じゃあその一つをWindowsのタスクに登録すればいいんじゃないの
>>410 すまん、少なくとも7以降ならできるようだな お騒がせしたわ消えるわ Laravelを基礎から覚えたいんですが、書籍がないんですよね・・・ 電子書籍は内容的に今一つだし・・・ 流行るのかなLaravel・・・
技術系フォーラムで話題になった回数ナンバーワン っていう記事を見て使い始めたけど 使いこなせない人が質問してる回数ナンバーワン ってことじゃないのかと思い始めた
その先がないんだよな API見てもインターフェースだけで動作内容が書いてないし
とりあえずなんか作りながら必要になった情報探してく感じでやってるから、あんま不便に感じたことないな。 困ったらドキュメントとかソース見ればいいし。
laravelは他のフレームワークと比べてどこか優れていて、 流行っているんですか?
凄く手抜きができそうな印象を与えてくれるところかな 実際には手抜きするために従わなきゃならないルールが多くて結構大変な印象 まあ慣れたら楽になるんだろうけど
フォームとか、クッキーとか、セッションとか、認証とか、バリデーションとか、エラー処理とか その辺全部簡単に実装できる。 ルーティングもページングも簡単だし。 だけど>>421 が言うように手抜きの方法を覚えるのがめんどう。 「1から実装するよりは簡単だろ」と言われそうだけど、 慣れてる処理なんかは1から書いたほうが楽なことが多々ある。 特にブレードテンプレートなんかは地雷。 でも全体的に使いやすいよ。 慣れると何でもカスタマイズできるし。 bladeの中でもちゃんとデバッガが動いてくれりゃいいんだけどな まあViewには極力ロジックを書かないのがBest Practiceだから筋違いなんだけどさ 継承とかセクションの書き方も最初は厄介なものがあるけど ちゃんと使うと凄い楽できるよね
>フォームとか、クッキーとか、セッションとか、認証とか、バリデーションとか、エラー処理とか >その辺全部簡単に実装できる。 ほとんどのフレームワークなら全部簡単に実装できそうだけど。。。 Ver5から、フォームは非標準になったようですね。
公式ドキュメントを一括ダウンロードしたいです。 できれば日本語版がいいです。 URLや方法がありましたら教えてください。
いろんなやり方でできるのはいいけど 用途や規模によってどれが望ましいとかおすすめしないとか ある程度ドキュメントに指針がほしいわ コントローラールートが楽だからってんで使い始めたけど どうにも痒いところに手が届かずイライラするばかり で、いろいろ検索したら「可読性を下げるだけ、使うな」の大合唱 そのうちなくなるかも、とか書かれてる始末 そんなもん初めから実装すんなっつーのよ
>>431 そんなことをいちいちドキュメントに書かれたら、ドキュメントの 質が落ちると思うぞ。 いろんな方法から最適なものを選択する力がないなら、チュートリアル 通りに開発を進めるのが無難だろう。 Laravelで書かれたお手本的なコードが欲しいね RailsはGithubに山ほどあったからすげえ助かった
新しい公式ドキュメント見難いよー なんでサイドバーやめちゃったんだ スマホで見てる奴なんてほとんどいないだろ…。 むしろもっとサイドバーにメニューたくさん表示してほしいくらいなのに。 アコーディオン式にすらなってないとかかんべんしてくれ
同意! 目次は隠れたり折りたたまれたりしないで、ページの上か左にフツーに表示して欲しい。
laravel5への以降を試してる {{ Form::open() }} で画面に生<form>タグ表示されるだがw 何がおまじないが足りない?
>>439 あう、速攻で自己解決www もっとドキュメント読み込まないと 重いだろうなぁというのはリクエストのたびに処理するファイル数やマジックメソッドの嵐で分かるが 具体的にどんくらい遅かった? 気になる
5ではブートアップが劇的に早くなってるよな てか4でもデバッグモードやめれば早いんだが 5では常時compiled.phpを作るようになった デバッグfalseでも重いってんなら知らん
俺も、チュートリアルやってみて、クソ重いから止めた。 Eloquentなんて、重すぎて使い物にならない。 納品後に「応答遅すぎだ」なんて言われたら、対応できないもんな。
ちゃんとデバックモード切って、キャッシュ使えば早いよ。 むしろ他のどんなフレームワークより早いくらいだけど。
そのベンチ、ありえないくらいlaravelだけおそいよ メモリ512とか少ない環境でやってるんじゃないのかねー 会社の環境で動かすとfuelphpとかと大して変わらないんだけどな
PhalconってPHPじゃなくCで書いてあるんだな そら速いわけだ あのDAOみたいなORMはちょっと使う気にならんが
つまりLaravelはメモリを大量消費するからコストがかかるってことか それなりに良い環境で動かせない場合はLaravelは勧められないな
Unread × 2 = So unreadable!! 2倍(Double)の読みにくさを!
lumenキタなー 待ち望んでいたフレームワークだ 早速slimから移行しよ
>>455 試してみた? ある程度感触がつかめたらインプレよろ 直でLaravel使うのに比べて どんなメリットがあるのかいまいちわからん 独自仕様独自仕様で困るけど、 ぐぐると即効で解決策見つかるのがすごいな。 日本語の解説はほとんどないけどw
>>456 laravelと比べてのメリットとなると軽いことぐらいなんじゃね? phpを使う理由が知りたい。 複雑で覚えにくくて初心者が扱いにくい言語という印象。
言語論争はさすがにスレ違いやな 10年以上争い続けてるスレがあったはずだからそっちでやるといい
技評のムックって内容いいの? Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク!] (Software Design plus)
正直Laravelになんの魅力も感じない。 クソ遅いし。
phpを今さら否定しても始まらん。 世界中の名だたるwebサービスで使われてる。 それをいうならJavaScriptなんて糞の極みだが、こうなったら使わざるをえない。 農家がコメを作るのに水田作るのと一緒だ。 めんどくさいが実りのためには作るしかない。 本は気になってるけど、出すの遅かったな。 もうだいたいの使い方覚えちゃったよw
おっさんは自分が仕切っていると勘違いしてるんだろう。 確かにXSSについては早く直したほうがいいのだろうけど、 他人の記事の正誤表について上から偉そうに言う暇があったら、 自分のサイトのCSSのズレなおせ。
>>461 いろんなブログとかの評判曰く中級者向けって感じ。 他のフレームワークとか使ってた人がなんとなくを把握するにはいいかもだけど、 俺のようなド素人にはあんまり良くなかった。 全体的に見辛いし、サンプルのコードもバグあるし なんで一冊目がエキスパート育成なんだろうな? 普通こういうのは入門編とか、初めての…とか、初心者向けとかが一番売れんのに。
初心者向けは公式サイトので十分だからじゃね? アレ良く出来てるよ
デバッグモードで動かしてるんじゃ? よほどアクセスがないサービスでないと問題になることないだろ
ケーキ?ララベル?ケーキ?ララベル? う〜〜〜、あーーりーん!!
Laravelエキスパート養成読本って本が、本屋にあったので立ち読みした。 著者には悪いが、Webのマニュアル読んだほうが100倍マシ! と思った。
久々にlaravel使うが laravel3の頃からEloquentの処理内容はあまり変わってないんだな・・・ viewcomposerは使ったほうがいいぞ
Lumenでかすぎ。 DLして使う前に削除した。 あんなにでかいと、フレームワーク絡みのトラブルの時、 追っていくのしんどいだろうが。
lumenの存在意義はベンチ用ぐらいじゃないのかね 開発では自前で全て用意する系じゃなきゃ使えないし そもそもFWの挙動が追いやすいとかならCIとか使うべき CI3は知らないが、CI2は実装すかすかで追いやすかったぞ
っていうかわざわざフレームワーク自体のソース見なきゃいけないほど独自の実装してない。 フレームワークによくあるオーソドックスをバランスよく組み合わせてるだけ。 そんなところが海外で人気の理由なんだろうけど。 ただManualが糞だから初心者には何のこと言ってるのか理解するのが困難。
公式マニュアルは最初から全部読まないとダメなのが面倒。
Lumenの競合相手が、Slim、Phalconだとすると、 全く優っているところがない。
★マインドコントロールの手法★ ・沢山の人が偏った意見を一貫して支持する 偏った意見でも、集団の中でその意見が信じられていれば、自分の考え方は間違っているのか、等と思わせる手法 ・不利な質問をさせなくしたり、不利な質問には答えない、スルーする 誰にも質問や反論をさせないことにより、誰もが皆、疑いなど無いんだと信じ込ませる手法 偏った思想や考え方に染まっていたり、常識が通じない人間は、頭が悪いフリをしているカルト工作員の可能性が高い 靖国参拝、皇族、国旗国歌、神社神道を嫌うカルト 10人に一人はカルトか外国人 「ガスライティング」で検索を!
POSTパラメータのバリデーションって コントローラーでやっていいの?
Railsから来るとアレはビビるよな でもPOSTされたデータ自体はモデルと=ってわけじゃないからコントローラーでやるってのもアリかなと思った POST値のバリデーションとモデルのバリデーションは別ってのも合理的っちゃ合理的 ただ 書く場所がバラバラになるのはイヤだから 結局 モデルにバリデーションルールのリストを書くようにしちゃったけどね
え、ララベルはコントローラーでやる前提じゃないの? withErrorsやら$validator->messages使ってViewにエラーメッセージ渡すってのが 公式の使い方でしょ。
Form Request Validation てのもある
じゃあもうJavaScriptでバリデーションすりゃいいじゃん
ローカルproxyでtrapして、値書き換えられるとか 考えすぎなの? 普通がわからん。
Auth::user()->とかで、どこからでもログイン情報が取り出せるのってどういう仕組みなの?俺みたいなバカでも分かるように誰か解説してくれ
設定ファイルとモデルで予めデータベースへのアクセスを定義してるから 自分で使えるようにpostやらcommentなんてモデル作れば同じように使えるで
postやcommentってモデル作ると¥postや¥commentでどこからでもアクセス出来るのな。 例えば$ret=¥post::createと$ret->fillの間で¥post::whereとかやってもいいの?
Collectionのlistsメソッドの返り値が いつの間にかCollectionになってないか? ドキュメントによればArrayのはずで 以前は確かにArrayだったと思うんだが
blade側に渡した配列の検証方法ってありますか? 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 みたいな感じで取れる。
laravel-debugbar 入れれば見れた気がする
>501さん ありがとう。 1. $templateを定義して、¥View::makeの戻り値をcontentsに値を代入している理由 2. ¥View::makeを使う理由 がわかりません。 contensにブレードが生成したhtmlが入ってるよということでしょうか?
>502さん レスありがとうございます! debugbar入れてみた。 IDE使ってるからこういうブラウザに機能追加されるようなデバッグツールの使い道がよくわからん。 クエリビルダだと実行されたクエリがわからないので、それが気軽にみられるようになるとこは気に入った。 Debug::info();で出力するってことでしょうか?
>>503 意味は使ってみたらわかる。 まずやってみるよろし。 上の例ではtemplate.blade.phpで{{@$content}}って書けばあとは作成したビューで値が取れる。 View::makeでビューの作成と、ビューに渡す配列を同時に設定してんだね。楽だね。 つまり「ビュー名.blade.php」で@foreach($results as $val)とかすればいいってことだね。 あ、テンプレートを作る理由はもちろん各パーツのモジュール化が楽だから。 ヘッダーとか、フッターとか、ビュー作るごとにわざわざ付けるの面倒でしょ。 全部テンプレート経由で設定しとけば、変更も楽よ。
>505,506さん すごい! テンプレート作る理由の解説、滅茶苦茶分かりやすくて涙出そうです。 ありがとうございます。 ただやってみたのですがうまくはいきませんでした。 環境はlaravel5で、上記例の$this->layout->content = View::make(…とするとプロパティがないようでエラーが発生します。 予めtemplate.blade.phpに何か仕込んでおく必要があるのでしょうか?
ごめん、5はまだ試してないんだw PostController.phpを作る。 class PostController extends BaseController { // http://example.com/post public $layout = 'template'; // これtemplate.blade.php public function getIndex($id) // getでhttp://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,」ね
$results = モデル名::all()->where(条件)->pagenation(1ページ表示件数); として取得したオブジェクトをビューで表示すると @foreach($results as $val) {{$val->カラム名}} ・・・表示できない(値がnullになっている) {{$val['origin']['カラム名']}} ・・・表示できる {{$val->created_at}} ・・・表示できる @endforeach {{$results->render()}} ・・・表示できる という結果になりテーブルの値がビューに渡せません。 created_atはcarbonという仕組みのおかげで表示できているだけのようです。 例えばコントローラ側を$results = モデル名::all()->where(条件)->pagination(1ページ表示件数)->toArray(); とすれば普通に連想配列で値は取れますが @foreach($results as $val) {{$val['カラム名']}} ・・・表示できる {{$val->created_at}} ・・・表示できない @endforeach {{$results->render()}} ・・・エラーが発生してしまう 今度はページネーションが使えなくなってしまいます。 どうやるのが正解なのでしょうか?
>>504 普通にViewsタブ内の各ビューをクリックすれば、そのビューの持ってる変数見られるでしょ 質問の続き(510)を先に書き込んでしまいました。すみません。。。 >508さん 完全に理解できました!ありがとうございます。 用途としては画面共通で使う検索条件のプルダウン用配列なんかをtemplateで読み込んでおくような使い方でいいのでしょうか?
>511さん ありがとうございます。 私の環境だと配列を渡すと配列名しか見えません。
用途は思いつく限りなんでもいいんじゃない? 上で書いたとおりヘッダーやフッターを設定しとくのが一般的だろうけども。 例えば特定の画面で、メニューバーの表示非表示をコントロールしたいとかの場合は $this->layout->menubar = View::make('menubar', array('flag' => 'true')); みたいにすればフラグも渡せるし。 まあなんていうか、自由w
度々すみません。 510の件まだ解決できず悩んでいます。 ビューに渡したコレクションからアロー演算子でテーブルの値を取得し、さらにrender()でpaginationを生成するにはどのようにしたらよいのでしょうか。 2ちゃんねるの皆さんのお知恵をかしてください。環境はlaravel5です。
>>510 最初の$val->カラム名で値が取れないのがおかしい その$valが何なのかもう少し調べてみばいいんじゃないかな get_class関数でそれがどのクラスのオブジェクトなのか調べたり、単純に中身を表示させたりとかさ 中身はdd関数で表示できたかな pagenationのところ、paginateじゃないの?変わったの? モデルはこんなかんじで $results = Post::orderBy('id', 'desc')->paginate(10); ビューは {{$results->links()}} ってな感じでできない?
>516さん ありがとうございます。$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']['カラム名'] }}とすることで値が取得できました。 難しい。。。
>517さん ありがとうございます! links()はlaravel5からrender()になったようです。 とはいえ同様のことをやっているように思うのですが うまくいきません。。
本当にその方法で値が取れないなら、モデルか、データベースの設計が間違ってる。 例えばPostというモデルを作る場合は、こんなかんじだよ。 class Post extends Eloquent { protected $guarded = []; // 複数のカラムからデータを取得するため protected $table = 'posts'; } protected $table = 'posts'は省略可能だけど、自動でモデル名+sになるから注意。 データベースについてはちゃんとモデル名に対応したテーブルがあること、 配列で返って来るだけの複数の投稿があることを確認かなぁ。 っていうか$val['original']ってのがさっぱりわからん。 たぶんどっかで凡ミスしてる。
>>518 > ブレード側で{{ $val->カラム名 }}とした場合は値は取得できず > {{ $val['original']['カラム名'] }}とすることで値が取得できました。 モデルにおかしなミューテーターを書いてるだけのように見えるが >>523 ごめん >>522 はミューテーターじゃなくてアクセサーだ original 経由で正しい値が読み取れるのなら アクセサーかアクセサーを呼び出すどこかに問題があるんじゃないかとね 518です。 >520、521、522さん ありがとうございます!! 原因が判明しました。どうやらモデルにカラムと同名のプロパティを定義したことが原因だったようです。 ガード、ミューテタがヒントになりました。
検証するときは考えられる最も単純な記述で値が取れるか調べるといいよ。 「ここはあってるはず」ってのが一番の天敵。
っていうか、ミューテーターとかアクセサーとか初めて聞いた。 一般的に使われる言葉なの?
使われてるんじゃね? アクセサーのことを ゲッター/セッターの両方をさす場合(rubyとかrubyとかrubyとか)もあるから、 少しややこしいけど。
やっぱり5.1からEloquentとIlluminate¥SupportのCollectionのlistsメソッドは arrayじゃなくCollectionを返すようになったんだな しかしQueryBuilderのlistsはarrayのままという謎仕様 こういうのホントやめてほしいんだがな
そういう時はプルリクかイシュー書いてみんなで良くしていこうよ
laravl取り入れてる人や会社はレベルが高くて丁寧なイメージあるね。 海外でも活発に情報がやりとりされてるし。 あんま素人が手を出しにくいってのもあるかもしれんけども。
ねーよそんなイメージ。 てかララベルを業務に採用している会社なんてあるんかw
すまんな、ここ数年俺が納品した会社はlaravel運用だ
Laravelの賞味期限は、あと何年くらいかな・・・
CodeIgniterをずっと使ってきましたが、ちょっとだけ新しいフレームワーク に興味を持ち始めました。 Laravelって良いですか? 10年以上運用保守するシステムにも安心して使えますか? CodeIgniterから乗り換えた方、Laravelの良さを教えてください。
今回の長期保証でも2年とかじゃね? WordPressみたいなもんだよ。ころころ更新される。 良さはコンポーサーとか、restfulなモデルとか、OAuthとか、新しい技術をどんどん取り入れること。 だから長期運用が目的なら向かないだろうね。 ちなみに10年同じバージョンで運用保守可能なフレームワークなんてないから。 CentOSですら無理じゃね?w
getメソッドとpostメソッドを別に扱う点だな。 最初は戸惑うだろし、混在したコードを書いてしましがちだが、徹底して分離するべし。 もうcodeIgniterには戻れん。
煮詰まってて意見が欲しいです。 laravel5に使ってます。 publicディレクトリ配下に実ディレクトリを配置したいです。 例えば、下みたいに特定のディレクトリ(今回は、pc)だけに聞く外部ファイルを置きたいです。 /laravel/public/pc/common/hoge.css デフォルトだと、実ディレクトリがあれば、アクセス時に403になってしまいます。 nginxのtry_grepでディレクトリしていしてないからかなと思ったのですが、そもそも指定されてる。 publicディレクトリのパーミッションも755 外部ファイルと、アクセスするディレクトリを完全に分けてしまう事も考えましたが、 HTMLが出来上がってしまったので、できれば現状のフォルダ構成を保ちたい。 何か良い方法は無いでしょうか?
特定のディレクトリ(今回は、pc)だけに聞く外部ファイルを置きたいです ↑ これの意味が何回読んでもわからんw 聞くが「効く」でも「きく」でもさっぱりわからん 内部でpublic以下のファイルを指定したいだけなら、そんな関数が用意されてるでしょ。
>>544 ありがとう。そして申し訳ない。 >特定のディレクトリ(今回は、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」を置きました。 この状態で、http:// (ドメイン)/pc/にアクセスると403になってしまう状態です。 >内部でpublic以下のファイルを指定したいだけなら、そんな関数が用意されてるでしょ。 assets関数を使えばできるし、使わなくても可能なのは確認しました。 悩んでいることは、設置したディレクトリ配下のページにアクセスすると403になってしまう事です。 >スタイルファイルは相対パスで読めるように、public配下に「common.css」と「pc/common.css」を置きました。 「common.css」と「pc/pc.css」ですね。失礼しました。
そもそもなぜに相対を使う? 普通に/common.cssと/pc/pc.cssを読むのではダメなの? てかファイル名違うならフォルダ分ける意味もなくないか?
public_path(pc/pc.css) これじゃあかんの? これで403なるならnginxだっけ?のリライトらへんが間違ってる。 もしかして、public配下のディレクトリにページを作って、アクセスしてんの? それなら、そもそもLaravelを勘違いしてる
指摘ありがとう。 初歩的な事なのですが、画像やcssやjsはpublic配下以外の場所に置くのでしょうか? publicがlaravelのドキュメントルートだと思って、public配下にファイルを置いてます。 話を聞いていて、今のhtmlの組み方がlaravelに合ってないんじゃないかと思えてきました。 他の人はどうやっているのだろう…?。 マークアッパーから上がって来るhtmlはLaravelの事なんか考えていないでしょうし。 >>547 >普通に/common.cssと/pc/pc.cssを読むのではダメなの? 相対から絶対に変えるのは可能です。それで、cssを読むことは出来ました。 外部ファイルは設置して読めるのですが、/pc/にviewを作って(rootファイルに「/pc/」アクセス時の振舞を設定して)、「/pc/」にアクセスが出来ません。 >てかファイル名違うならフォルダ分ける意味もなくないか? 分けたのは、あくまで個人の主義です。 HTMLを組むときに、個別のディレクトリしか使わないものを一色多にしてしまうと(自分は)管理しずらいです。 また、外部ファイル読み込み用のディレクトリを別途用意(例えば、pc/pc.cssではなく、common/pc/pc.css)にするでも良いかと思ったのですが、 この問題がある事は予想していなかったので自分の調査不足です。 >>548 >public_path(pc/pc.css)これじゃあかんの? なるほど。publicディレクトリのパスを取得する関数ですね。 ただ、今抱えている問題と少し違うかもしれません。 cssのパスの通し方に困っているわけではないのです。rootファイルのルーティング(?)で迷ってます。 pubilicディレクトリ内に実ディレクトリを作ってしまうと、そのディレクトリ配下にルーティングすると403になることを解決したいです。 >もしかして、public配下のディレクトリにページを作って、アクセスしてんの? それは「publicディレクトリ配下に静的ページを置いてるか?」という事であってますか? それなら、やってません。viewかcontorollerでしか、表示を作ってないです。 >>549 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に置くべきじゃない またviewファイルをLaravelのルーティング経由で読ませようとしたってダメ .blade.phpは上に書いたように「phpじゃない」んだからな viewはあくまでもresource/views(のサブディレクトリでもいい)に置いて Viewクラスなりview()関数に専用のドット記法でパスを渡す必要がある
>>543 > nginxのtry_grepでディレクトリしていしてないからかなと思ったのですが、そもそも指定されてる。 もしかして: try_files というか nginx の設定の問題であって Laravel は関係ないよね >>550 >>551 >publicはあくまでも通常のサイトルートであって >そこにはwebサーバ(NginX)が直接処理できる形のファイルを置く 具体的にはcssやjsだな 了解です。public配下にファイルを置く事自体は問題ないのですね? ただ、自作phpやhtmlを置くlaravelの動作に影響があるかもしれないから辞めた方が良い。 ということですかね。 >またviewファイルをLaravelのルーティング経由で読ませようとしたってダメ .blade.phpは上に書いたように「phpじゃない」んだからな 説明不足で申し訳ない。viewのテンプレートを吐かせる関数を噛ませて表示をしています。 別に、「(laravelの記述ルールを無視して)viewのファイルをインクルードしたけど失敗する。」 「PHPライブラリを作ってpublicに配下に置いたけどけど使えない。」 と言っているわけではありません。 >>552 >もしかして: try_files すみません。try_filesの間違いです。 >というか nginx の設定の問題であって Laravel は関係ないよね それも、そうだと思います。 何か話の取っ掛かりになればと思い書きました。蛇足だったかもしれません。 今やりたいこと(publicディレクトリ配下に実ディレクトリを設置できるようにする方法)を調べると、 nginxの設定を変える方法しか見つからなかったので試した事を共有したかっただけです。 laravelだけで実装する方法があるのであれば、ぜひお聞きしたいです。 >viewのテンプレートを吐かせる関数を噛ませて表示をしています。 ここがわからない 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 / みたいにしとけば、普通動くと思うんだけど。
>>553 > laravelだけで実装する方法があるのであれば、ぜひお聞きしたいです。 だから Laravel は関係ないと言ってるじゃないw > nginxのtry_grepでディレクトリしていしてないからかなと思ったのですが、そもそも指定されてる。 try_files にディレクトリを列挙しちゃってるから index.php にフォールバックできてないでしょ? >>554 pctop.blade.phpというviewファイルを作って、rootes.phpにView::make('pctop')と書いて読んでいます。 噛ませた関数というのが「View::make」です。 >>556 >public_path(pc/pc.css)でパスが取れるけど、アクセスすると403になるってこと? >それともpublic/pc/ディレクトリそのものにアクセスしたいってこと? 前者の事をやろうと思っています。 nginxのコンフィグに、「$uri/」が無いから403ではじかれていると思い、書いていただいたコード同じ設定をするつもりでした。 ただ、今使っている環境のnginxコンフィグにはすでに書いていました。参考程度の話ですが、homesteadで構築した環境です。 >>557 読解力が無くて申し訳ない。てっきり、今の話はnginxの話だからスレちがいだよ?と言われてると思って、laravelに話をもどそうと思ってました。 >try_files にディレクトリを列挙しちゃってるから index.php にフォールバックできてないでしょ? 理解力が無くて申し訳ないです。 それは、優先順位の設定に問題があり、分岐処理をするはずのindex.phpに遷移する前に、 本来lravelが取らないindex.php以外のファイルにアクセスしてるんじゃないか? と言っていますか? >>558 そうそう nginx の try_files ディレクティブの説明を読もう 検索条件のPOSTパラメータをフォームに復元したいのにできません。 具体的には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にしたほうがいい ページネーションの際の検索条件保持もより簡単だと思うが
なんでリダイレクトで検索ページ作ろうと思ったんか、その発想が不思議だw 普通にgetでurlにパラメータ渡して、$keyword = Input::get('keyword')で取れる。
>562、563さん レスありがとうございます! それでは検索でGetを利用し描画時にフォームの内容を復元するには、ビューにどのように値を渡し、どうやって取り出せばよいのでしょうか? 検索条件が多いため簡潔な書き方にしたいです。 562さんの説明のお陰でリダイレクトの仕組みは分かったのですが、いつwithやwithInputを使うのかが分かりません。 ご教授頂けないでしょうか。。
565さん ありがとうございます。 英語が苦手でstackoverflowとか海外の掲示板に辿り着くと 解決可能なことがわかるくらいで なんとなく分かったような分からないような感じで 試行錯誤してるうちで出来てしまうことご多いです。 それって先人の知恵を生かしてるとはいえませんね。。 これから努力してみます。 ページネーションが生成するurlにパラメータを付けられるんですか!勉強になります! 画面からのリクエストをテンプレートに渡す方法ですが、フォーム一つずつでInput::get()で取り出すのではなく、Input::all()を渡してよしなに処理してくれるような方法はないでしょうか?
565さん 教えて頂いた方法で解決できました。 ありがとうございました! □コントローラー @$変数=Input::get('パラメータの名前')としてフォームの入力をコントローラーで受けとる AView::make('ビュー名')->with('パラメータ名'=>$変数)->with(次のパラメータ)->with(次のパラメータ)としてフォームの値をビューに渡す □ビュー B<input type='' value={{ $変数名 }}>としてフォームの値を復元 C$ページネーションの変数->appends(['パラメータ名'=>$変数,次のパラメータ])->render() としました。 パラメータが増減したときに@〜C全てに修正が必要なことが不安ですがやりたいことはなんとか実現することができました。
「laravel カスタムエラーページ」でググろう
本番環境と開発環境を分けるのに、.env ファイル以外で設定する 方法はありますか? ホスト名で自動判別したいんです。
初めてLaravelを勉強してるのですが オートロードってどういうことでしょうか?
laravel new hoge これで作られるプロジェクト内にvendor入れられる設計が気持ち悪すぎ
V4からV5になって、ディレクトリ構造が変わったりモデルが なくなったり。 こんな大きな変更があったら怖くて使えないよ。
たしかにごっそり変わったよね。 4からだから、他のバージョン知らないけど、 バージョンアップのたびにこんなんだと確かに使う気しない。 毎回こんな互換性一切ない感じでアップデートしてるんだろうか?
5.0から5.1ですら 結構コード書き換えが必要なレベルの変更あったからなあ 5.1は一応ロングタームサポートで 2年だか3年は仕様を固定するというが 裏返せばその次はまた 変える気満々ってことかと勘ぐってしまう
変える気満々か・・・ そうだろうな。 Laravelの開発体制って、個人または少数人でクローズドな開発してるの?
2年だか3年は仕様を固定するだと??? その先はまた変更??? 世の中に公開した仕様は、普通下位互換性を考慮するだろ。
使うのも自由使わないのも自由 文句があるならフォークして自力でメンテすりゃいい
laravelを触り始めたばかりなのですが laravelの場合、 同一サービスで、ユーザーサイト、管理者サイト、代理店サイト等を作る場合 その数に応じてプロジェクトを複数個作るのが一般的でしょうか それともviewやcontroller直下にuser,admin,agent等のフォルダを作って Routeで切り分けていくのでしょうか アドバイスもらえると助かります。
同じサービスなら、プロジェクト一緒の方がいいでしょ。 viewsとかcontrollersの下は、好きな方針で整理すればいいと思うよ。
>>583 アドバイスありがとうございます。助かります。 ララベル本評判どうなの? 既に特に問題なくサイト構築できるんだけど、買ってみる価値あるかな?
ないと思う。ドキュメント十分揃ってるし、ドキュメント以上を求めるならgithubでLaravelプロジェクト見て回ったほうがずっと勉強になる
年明けに本でるしボリュームも今でてるやつは少ないから買うタイミングとしては微妙。
>>588 >年明けに本でるし のソース教えてもらえる? 転職の際に必ず思い出してください。 下記の条件が全て当てはまる会社にご注意下さい。 ・IT系 in 東京 ・転職会議で2.5点 ・転職会議の「その他>2ch情報」の欄で過去の労基2chスレが表示される
お、いろいろ情報が。 来年はじめに出るなら、それ買うか。 できれば正月の暇な時間に読みたかったけど、しゃーないなw
PCに大量のファイルをダウンロードしたくないので dreamweaverを使いたいのですが、 dreamweaverで SublimeTextやPHPStormみたいに ide helperのようなコード補完は出来ないのでしょうか
>>594 正月休みの入門なら最近みつけたブログがいいかも 今日も更新あったし、ソースもgitで手に入る つ larajapan >>596 覗いてみたが、全然コンテンツないぞ。 更新止まっちゃってるけど、ララ帳超えるくらいじゃないとな。 >>597 Feedlyで新着通知があったから話題にだしたんだが 最新の記事が今年の11月22日なのに、これで更新止まっちゃってるなんて宣う低能のいうことなんか聞くことないよ 最新記事しか見てないんだろ コンテンツの量もそれなりにあるし
更新止まってるっていうのはララ帳の話。 site:検索でインデックスされてるページの量を見る限り、 www.larajapan.com → 27ページ laravel10.wordpress.com → 321ページ と、10倍以上の開きがある。 つうか、たかだか27ページ(インデックスページ含む)で、 「コンテンツの量もそれなりにあるし」って、 一体何のステマだよ。
何をそんなに反発してんだか ステマだと仮定しても何が悪いの? ブログが書籍原稿で、読者が無料校正協力者になること? 書籍ってもう10年以上前から成り立ってないよ MS-DOSの頃は俺なんかでも稼がせてもらったけどさ。文章かける技術者ってだけで需要があった時代 技術書なんて今、初版3000あるかな? もう初版刷り部数まるごと印税くれる出版社もないんじゃね? 知らんけど
単純に有益な情報を紹介する人=神 それ以外=ゴミ ほっとくよろし
>>597 だが、確かにオレがケチ付けちゃってるな、これは。 すまんかった。 「新刊の代わりに正月休みに読めるもの」を>>597 が勧めてたとして、 いや、それには分量が違いすぎない? と思ったんで書き込んだ。 もちろんLaravelの新しい入門サイトが出てくるのは大歓迎だよ。 もしlarajapanの著者が俺の書き込みを見て不快に感じたのであれば、申し訳ない。 4500円はけっこう高いね。 と思ったら450ページもあるな。 技術書としてはこんなもんじゃね?
Bladeテンプレートの @forelse($arr as $key => $value) // @empty // @endforelse みたいな時の@emptyの使いどころがいまいちわからない
Webサービス開発ってなんですぐ飽きるんだろうな 一番JS書いてるときが楽しいとか異常だろ
Laravelなら簡単すぎるからだろそりゃ JSめんどいわ、俺は嫌い Angularでも使えばいいんだろうけど 細い部分は結局手で書くから 覚えることが増えるだけになりそうな気が
fuelとは別物だけど比べるとすると diコンテナフル活用 フレームワークのテストがきちんとある 疎結合にしやすいからテストコードが書きやすい dbとか他のコンポーネントは好きなライブラリに入れ替えok ファサードはfuelっぽく見えるけどstaticじゃないから そもそもが全く違う
オレオレフレームワーク使ってたんだけどさ、 いっちょ最新の勉強するか!って上に出てた本買って読んでみたけど。 なるほどわからん。ということしか分からなかった。 俺には無理だわ。 フレームワークの初級でおすすめないですか?
なにがわからんのか、わからんのでアドバイスしようが無いw 上の本でわからないと、Laravelは向かないかもね。 日本語の解説本は全然でてないから。 俺は公式ドキュメント見ながら勉強したけど、最初結構つまずいた。 だけど、わからん単語、一つ一つググって読み進めればわかるべ 全くわからんなら、まずはCakePHPでもやったら。 初心者向けの本も腐るほどある
ラクするためのものなんだから 結果的にラクできなきゃ覚える労力が無駄なだけ 本を読んでもさっぱりわからんのでは 楽できそうかどうかの判断もできんだろうに
もうちょい続けてみます。 知らない単語がでると、苦手意識があるのがいけないですね。 5.2はこの書き方が非推奨になりました。とかサンプルに書いてあって、は?もう??公式見ないとダメか?で、 公式見て更に分かんなくなって、あかん状態でした。 まずは一通り読んで触ってから決めたいと思います。 とりあえずオレオレフレームワークはフレームワークと呼べないレベルでした。。
laravelはわりと仕様が変わりまくるから、そういう意味では使いにくいかもね
そういった非推奨になりましたとか、例外もありますってのは、技術書には良くある。 そんなもんは全体から見れば些細なことだ。 まずは全体を俯瞰するようにザーッと読み進める。 で、2回目、3回目に読みなおすときに気になったら調べ直したらいいんだよ。
今だと Slimとかがいいんじゃないかな コンパクトで勉強のために最初にやるには もっと大規模なフレームワーク勉強したいっていうならCodeigniterが 初見にはとっかかりやすいって聞いたことあるようなないような てかLaravelのドキュメントでわからないってy
PHPってのはもともと良くも悪くも緩い言語で 俺なんかもそこが好きなクチなんだが あまりにも普及しすぎてここ何年かは 「もうちょっとキチンと集団行動のことなんかも 考えてくれないと困りますねー」 みたいな空気になってる気がする Java的なスーツ着てタイムカード押してみたいな雰囲気ね 言語仕様そのものもそっち方面の拡充が著しい 典型的には引数の型指定がスカラー型でもできるようになったり まともなクロージャーが使えるようになったり Laravelはまさにそういう過渡期に発展してきたわけで 空気の変化をもろに受けてるように思う 最初の頃はPSR?どうでもええやんー 名前空間?ユーザーは気にせんでもよろしおまんがなー みたいな感じだったのが どこに出しても恥ずかしくないくらいに「キチンと」してきてる でもそこが古いタイプの(なんでもアドリブでこなしてきたような) PHPプログラマーには馴染みにくい要因なのかなと思ったりもする まあ他のフレームワークもそのへんの事情は同じなんだろうけどさ 超長文失礼
Laravel5.1からのディレクトリ構造は好きだね PSR-4とclassmapのいい感じの使い具合がプログラマの妙だね
. . 板違い(?)の上に、話をさえぎってしまいゴメンナサイ!(*_ _)人 でも、この板のユーザーさんにも有意義な告知かと思うのでカキコませてください。 ★ 謝礼は十分いたします ★ アメブロなどのサイト制作ができる方!! アメブロなどを使用してのサイト制作のできる方を早急に求めています! 私はリケジョやPC女子からはほど遠く、サイト作成にはまったく疎いのでとても不自由しています…(> <;) そこで私に代わりサイトを作成してくださる方を求めてこの場をお借りしました。 ■サイトの内容… アダルト系、違法性、その他公序良俗に反するものではありませんのでご安心ください。 ■サイト制作の仕様ベース… アメーバブログで十分です。願わくばwordpressなどのブログ形式のサイトを希望します。 それに準ずるもので使い慣れたものがあれば別のものでも構いません。 ■条件はありません… 技術さえお持ちでしたら、学歴・職歴等は一切問いません。 フリーター、ニート、高齢ニート、コミュニケーション障害をお持ちの方、引きこもりの方、中年失業者、長期無職等、歓迎! ■作業形態… 作業は在宅でやって頂くことになりますので、時間の指定は一切ありません。別のお仕事の傍らに…でもOKです。 ■詳細をお知りになりたい方は… 下記メールアドレスまでご連絡ください。詳しく書いた返信文を差し上げます。 ※真剣な告知です。冷やかしはご遠慮ください。 井 上 inoue1952w★gmail.com 迷惑メール対策のため@部分を★にしてあります。 実際に送信する際には★を@マークに変えてください。 . .
Laravelというかフレームワーク自体が俺は好きじゃない どんどんコード肥大化していって何が何やらわからなくなる それで別サービスにわけてAPI使ってなんたらとかもウザい といってもフレームワークを使わず 素のコードでも嫌い 見てられない 結局何がいいたいのかというと プログラミングなんて嫌いだってことだ
1から作るのが嫌いだから、Laravel使って楽するんだろうに。 俺だってプログラミングするよりも、美人なねーちゃんと酒飲んでる方が好きだよ
使うことによって 「いかに楽した気になれるか」 という自己満足の部分が大きいな その点Laravelはいい線行ってると思うわ
でも結局そのフレームワークを理解してる者じゃないとメンテできないというジレンマ
フレームワークと言わずそもそも言語ってそういうもんやろ 文法そのものは全部Cベースで基本同じ 違うのは関数群や標準ライブラリ、環境の類 JSやるなら嫌でもDOMやCSSのことは知らにゃならんし PHPなら山ほどある(しかもまるで統一感のない)関数群のリファレンスが必須 少なくともLaravelなら読むのはグンと楽になるだろ 実際にメンテするのは慣れてる人じゃないと 確かに結構大変だと思うけどな
なんにせよ、どこの馬の骨が書いたかわからん絡まったコードを紐解く作業よりは、 Laravelの書式を覚えるほうがずっと楽
Microsoftこそこの世の正義と信じてるような人種は フリーのフレームワークなんぞ馬の骨と本気で思ってたりするから怖い そしてLaravelの開発者が元.NET開発メンバーと知ると手のひらを返したりする まあそんな連中はそもそもPHPを使わんがw
C#っぽい部分が割とある。ただ、それの実現にマジックメソッド使ってるせいでIDEの補完がお察しという印象。 言語機能の差があるからなあ。
海外に比べてなぜかくそ盛り上がってない。 たしかにLaravelじゃなきゃいけいない理由はないんだけども 日本は新しい技術を取り入れる柔軟性がないのかもね。 とかく学習コスト、ランニングコストを気にして現状維持でガラパゴス化する。 気がついたときにはiPhoneみたいな黒船に全部かっさらわれるという連鎖。 アメリカのエンジニアの倍くらい働いて、半分程度しか給料もらえないから、 そんな余裕もないのかもしれんね
勤務中に新しいフレームワークの勉強なんぞしてたら怒られるしな 片手間に学べるほど学習曲線の緩やかなものでもない ガラパゴスなプログラマにとっちゃね
laravelを選択する人って公式ドキュメント読んで大体使えるから書籍あんま必要としてないんじゃないの…
Googleは勤務時間の10%で、必ず業務外のことしないといけないんだっけ? 割合は忘れたけど、そんな制度があったはず。 一方そのころ日本では焼きそばを作らせていた
バージョンアップ早い割に大規模な変更多いし日本語の情報も無いからガチでやってない奴はきついと思う
まあしかしここんところはそんな激しい変更も必要ないじゃん そんでちゃんと使えるようになると万能感ハンパないわ 一人でいきあたりばったりにやってるからDIやテストは活用してないけど 一人でもそのへんきちんとしたほうが本当はいいんだろうな
いや、5になったときに、ごっそり変わったけど。 でもしばらくはサポートするらしいから、書籍化とか、勉強するなら今だよね
ディレクトリ構造とかど派手に変わったりして面を食らうけど ガイドに従うだけであっさり移行できたんで 追従が大変という印象がほとんどないや >>640 laravel-ide-helper入れても警告だらけになるのは嫌よね 実装上変え辛い部分だろうし、6辺りで対応してもらえるといいな 5になったのなんて随分前じゃんw 最近ってのは5.1とか5.2の話ね
なんていうかララベルって響はいいよな。 なんか、ピクニックみたいな楽しいリズムがあるよ。 コードイグネイターやら、ケークなんて響よりずっと良い。
クエリビルダーで質問なんですが、 ...->union($users)->where('id','1'); というように書いてunionで結合した後にその結果を 条件で抽出したいのですが、 投げられているSQL文を見るとなぜかwhere('id','1')されてから union($users)されています。 これはクエリビルダーの仕様なのでしょうか?
順序は関係ないだろうな Laravel的なやり方からするとそういう場合 クロージャの中にUnionを入れることになりそうだが 実際selectにクロージャを入れられるかどうかは知らない
Schema::create('profiles', function (Blueprint $table) { $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されていませんよね? このへんの詳細がドキュメントなどに載っていなかったので質問させていただきました。
guardedプロパティは初期設定がワイルドカードだからノーガード戦法するなら空配列で上書きかな。まあ存在しないカラムに値を代入されたらアウトなので、これだけだと入力チェック必須だよね。 Modelのブート時とかにDB参照して自動的にカラム名持ってくるのはできなくもないかな? 初期設定の値からして、guardedプロパティをワイルドカード、fillableプロパティを最小限で使うのが暗黙的な推奨。 その上で利用の都度、値を1つずつ代入するか、Model::fillable()メソッドを呼び出してfillableを上書き・複数代入できるフィールド名を明示的に指定するかが安全。 と言っても利便性と安全性はトレードオフなので、 1つのモデルに対して複数の新規登録、更新アクションがない場合はfillableプロパティ直指定で済ませる、といったところ。 たまにfillable指定し忘れてキーってなるのは安全のためと思って我慢
ありがとうございます。 とりあえずはfillableでいこうかと思います。
Schema::create('profiles', function (Blueprint $table) { $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が挿入されるようなシステムにしたいです。
public static function boot() { parent::boot(); self::created(function($user) { $profile = new Profile(); $user->profile()->save($profile); }); } このコードぶっこんだら出来ました。失礼しました。
そういうのはstorageでやるんだろうなあ 実際のファイルの物理的な場所は 下位のドライバに任せるという発想
5.2のmake:authでviewに {!! csrf_field() !!}と書かれていたのですが 結局は!マーク無しと変わらないんですかね? どちらが正しいのでしょうか?
うんうんadminと分けやすくなってほんとうれしいよ
んなもん、ユーザーIDで分ければいままでだって簡単やん
PHPカンファレンス 未だにCakePHPerのがずっと多くて暗澹たる思いになった 海外から完全に取り残されてる感じ 一流なハズの人たちがそれまでの資産もあって Laravelになかなか移りたがらない 日本発なサービスがあんまない、あってもパチンコの市場くったソシャゲばっかりなのは こういう保守性もあるんじゃないかと思ってしまった
Cakeに比べてLaravel使うメリットって何なの?
世界的ですもんね 乗るしかない このビッグウェーブに
<input type="text" name="name" value="{{ old('name') or $user->name }}"> orで三項演算子になるはずが、なぜか1と表示されてしまう(データベースに存在しているのに) {{ old('name') ? old('name') : $user->name }} こっちは正常に動作 教えてドラえもん
>>672 デザイナーあがりの自称エンジニアでも作れるかと >>674 or は論理演算子よ 評価対象の値をそのまま使いたい時は a ?: b >>674 は bladeのor記法のことを言ってるんだろう。 {{ 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」は >>676 の言う通り論理演算子。 old(’name’)がnullだろうがなんだろうが右辺がtrueなので結果はtrue。 echoで暗黙的にtrueが1に変換されて出力される。 と、いうかoldの第二引数にデフォルト値渡せるから value="{{ old(’name', $user->name) }} とするとプリティー。 >>675 CakePHPよりLaravelの方が簡単なの? フレンドシップ機能を作るのはポリモーフィック一択ですか?
5.1と5.2も結構違いあるよなぁ。 5.2はLTSじゃないから、すぐに保守されなくるし。
1度覚えた知識でずっと使えるって前提がもう通用しないのかもしれんね。 新しく作るときは、ドキュメントを斜め読みして、勘所を理解する。 そういった知識より、知恵みたいなのが求められるのかも。 その点、Laravelは音速で日本語化してくれる神がいるから心強い。 LaravelでWebサービスを一から作れる人は、そんなの慣れっこかもしれんけど。 初心者向きではないね。
マルチ認証まちこがれてたんで5.2 そうでないなら手を出すべきじゃない
laravelはソース読むのが楽しい オレオレ作ってみたくなる
一部のバリデーションルールを、追加でなく、置き換えるにはどうしたらいい? alpha_numやemailが使えないので
>>686 あ、速攻で自己解決したった publicじゃなくprotectで定義すりゃいいだけか symfonyと比べていいところ、悪いところを教えて欲しいです どっち使うか迷ってます
結局はcomposerでコンポーネント管理してるだけで 別にフレームワーク間の違いなんて気持ち違うぐらいだろ
日本だと今一盛り上がってないけど、 cakeを勢いで超える日は来るの?
>>688 機能面で言えばSymfonyなんだろうが、 YMLとアノテーションの重厚長大な作りが疲れるんだよね 手間に合わないというか現実的じゃないというか… それがLaravelに移行した理由 resourceコントローラーのupdateメソットでカスタムリクエストを利用しているのですが、 rulesのuniqueにどう除外idを引き渡せば良いのか分かりません teamsテーブルのチーム名(name)を更新する構造です。 public function rules() { return [ 'name' => 'required|unique:teams,name,'.$teams.'|max:20', ]; } putでteams\{$teams}に渡していますので、$teamsを参照できると思ったのですが どうにもLaravel5では対応していない模様です。 どなたか教えて下さい...
ルールの定義にRequestで渡した文字列を使いたいということ? 発想の根本が間違ってる気がするが・・・
>>693 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; } スマホで書いたからタイポしてたらすまそ >>695 まちがえた unique:user,email,{user_id},user_id policyクラスでどうしてもfalseしか返ってきません。 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を返したいです。
もしかしてresourceコントローラーだと $router->model('user', 'App\User'); が使えない?
authorizeForUserはblade側で操作できんのか?
【Win10】 こんな犯罪級OS薦めんなよwww ↓ 【スパイウェア】 この使用許諾契約書には書かれています ”最後にあなたのコンテンツを含む個人データ(例えばあなたの電子メールの内容や―プライベート通信やプライベートフォルダ内のファイル)にアクセスし―開示し保全します” 開示する ここ重要だよ 契約がなければ通常 高度な違法行為になりうることです それはあなたが自分の意思としてこの契約書に同意したのです VIDEO 「1910」 副島隆彦 2016年6月16日 大阪市や大阪府のバスの運転手が年収1000万円は許せない、600万円まで落とすと。 なぜなら、普通の労働者たちが年収400万円でようやく働いているのに、何でバスの運転手が1000万円ももらえるんだと。 このものすごくすばらしい主張があった。 これを言われると日本の民主党や共産党は非常に困るんです。 が、先ほど言ったように、金持ちたちの財産を相続税で国家が奪い取る、これを正面から本気でやったらほんとに橋下はたたき潰されました。 労働組合を押さえつけるまでは安倍晋三たちも大好きだからよかったんだけど、 自分たち自民党体制の、金持ちと地主階級、経営者を大事にするという自民党の基本骨格があるわけです。 5.3正規リリース来たのか Vue.jsとの統合がどうなってるのかは気になるな
Laravelは好きなのに最近のフロントエンドへの干渉がどんどん強くなる流れは嫌いだわ ElixierにしろVue.jsにしろデフォでpackage.jsonに入れる必要性が理解できない フロントエンド開発に任せるべき範疇だろ
この細かい互換性とか気にせず、ばっさり切り捨てる感じ嫌いじゃない Vue.jsってObjective-C初めて見たときみたいにひょぇぇぇ〜ってなるから、まだみたくないな
いやなんだかんだ言ってフロントエンドの開発負荷ってデカいから そこが組み込まれるのはありがたいわ アングラーとか覚えるのと自分でゴリゴリ書くのと どっちが早いか迷って後者を選んで泥沼化したりもしたし フロントのコードにもLaravelなりのベストプラクティスを提示してほしいと思ってた
4.2のdocsだとtemplatesで508の書き方が紹介されてるけど、 5.0からは@yield使ってるから今はこっちが主流でいいのか。
vuejs は付近のライブラリ含めてドキュメントが日本語化されてる。あとはコンポーネント的な概念を理解するのと、fluxは恐らく導入不可避になるので、fluxの概念になれるだけ。あとは開発環境さえ整っていればめちゃ楽です。 小から中規模まで、少人数で構築するSEO気にしないWebアプリケーション構築するなら充分対応できます。実装としてはLaravel関係ないけど、pagekitの実装が参考になるかと。 まぁ、ただ日本自体SPA前提の案件てなかなかないよね。
ハイブリッドアプリとかデスクトップアプリケーションならjsにもいろいろ選択肢あって楽しいんだけどな。 ただサーバサイドエンジニアがフロントエンドもガッツリ攻めていくのはかなりの体力がいる
大昔ならAccessでやったような業務アプリの案件を 流石に今からAccessでやる選択はないし じゃあVBとかVCにMSSQLでやんのかつったらそれもまた(Windows自体の将来性に疑問符) ということでいっそWebアプリでっていうのはごく自然な流れだと思うんだけど 実際やるとフロントエンドが大変すぎて死ぬよね Access並みの手軽さでサーバサイドとデータバインドできるUIコンポネが一揃セットになってれば 一気に広まる可能性あると思うんだけどな HTMLやFormのファセットをオプション化した流れはその逆のようにも思われる
バックエンドがUIのデータバインディングまで面倒見るとか勘弁してくれ 2年経たずに手の付けられない負の遺産となる
Windowsはビジネスユースなら今後もなくならんやろ
最近の施策で.net案件のプロプラ不安は全部解消されたな。全力注いでるのが分かる あとは受け入れられるかどうかと、キャッチアップが遅すぎる>>715 みたいな老害のプライドをいかに刺激しないように説得するか。現場の手腕次第だな… バカほど声が大きいからな ふむ 嫌味を返すなら全力注いでる=なりふり構わず生き残りに必死 ってところだけど 確かに現状のASP.NETは十分選択肢になりそうだな サードパーティ製の業務アプリ向けUIコンポネなんかも 歴史が長いだけあってそこそこ整備されてるようだ 業務用ならゲイツプラットフォームという根拠のない思い込みも(発注側に)根強くある こうなるとこの分野へのLaravelの浸透は難しいかもな
ReactだったりVuejsだったり、現状でもサーバーサイドレンダリングできるけど現実的ではない。 Vueも2.0でSSR対応できるみたいだけど、実用では使えないと思う。まだ1、2年かかる気がするし、時が経てば経つほどSEO目的のSSRは考えなくても良くなるだろうし。 今後バックエンドでは、いかに使いやすいAPIを作るかってとこが注視されていくんではないかと。 そこの領分がきっちり別れるようになると、バックエンドもフロントエンドも幸せにはなると思うね。理想論かもしれないけど。
>>717 今更のレスだがjQueryでBootstrapな基礎はもう変わらないんじゃね? それこそASP.NETも(フロントはC#捨てて)そうなってるみたいだし APCでキャッシュしてるんだけど、教えて ・コンソールでphp artisan cache:clearとか、自作コマンドでCache::forget呼んでもキャッシュが削除できない。同じキーで取得はできる ・routes.php内で同じソースを実行すると取得も削除もできる これって何が原因だろ?console経由だと読み込まないconfigとか実行ユーザの違いとか?
>>724 apc.phpでキャッシュクリアできるかどうか試す。 できた場合→apc.phpで実行しているコードをコピペ。 できない場合→わからん。 初めてlaravel使うんだけど、 全ページ、ルーティングしなくちゃだめなの? 静的ページが100ページくらいあるんだが。 publicに静的ページ置こうか考えたけど、viewテンプレートは使いたいから却下。 ちなみにver5.1。 誰か分かる人ご教授ください。
ルートパラメータ使えばいいだろ それでなんとかならないようなら そもそもフレームワークを使う意味が不明では
前ページルーティングって恐ろしい思考回路だな そもそも使うの初めてなら、まずは他の人がどうやって似たシステム組んでるのか調べる方が良いよ 勉強には先人の知恵に習うのが一番
返信ありがとう。 丸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'); } } }); こんなでいいのかな? 第二階層までしか対応出来ないのがアレだけど。 もっといい方法あったら教えてください。
あんまりララベリッシュじゃないけど動くだろうからそれでいいんじゃね? もっといい方法といってもなあって感じ そもそも大量の静的ページってのが根本的に合わないわけで bladeテンプレを使いたいっていうからには少なくとも「ある意味」動的ではあるはずだと思うんだけど 動的に変わる内容が何一つ整理できない(全てを個別に扱うしかない)なら もうそれ以上やりようがないんじゃないかと
>>732 こんなんでどう?最後のスラッシュが$_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ミリも関係ない話でもあるが
>>736 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\/\-\_]+'); 本当助かりました。ありがとうございます。 キレイにコード書ける人ってかっこいい。
おっと、5時間かけて検証しながらレス書いてる最中に色々レスついてた。 一応、上に書いたやつでおれの環境だと動いてる。 若干スレチ気味で申し訳ないが、サーバーの問題なのかな? 検証は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だからトレイリングスラッシュはちゃんと残るようになった
REQUEST_URIはサーバによって違うよ デフォルトで定義されているものを変更することもある 使わなくて済むなら、使わないほうがいい
>>746 いやそこはいいんだよ /param1/param2 のようなURLを Route::get('/{url?}', function($url = null) { return $url; }); のような形で受けられるかということ 俺がやるとどの環境でもNotFoundHttpExceptionになる >>745 がやるとparam1/param2が返るらしい >>745 んなこと言われてもなw そもそもルーティングされてくれないんだからどうしようもないわけだが >>747 homesteadでも試したけど取れたわ。 > Route::get('/{url?}', function($url = null) { return $url; }); > のような形で受けられるかということ ->where('url','.+')が足りないとかそういう問題ではないよね? >>748 いやそれですわorz whereで条件を「緩める」という発想が一切なかったようでそこ目に入ってなかった そういう仕掛けだったのね・・・お騒がせしますた laravelで作ったアプリを複数のapサーバでバランシングする予定なんだけど、apサーバ自体にはcomposerとか必要ないよな? なんか入れないでもファイルコピーだけで動くっぽいんだけど。
物を壊したら弁償するのは理解できても風評被害を食らわせてもやった側に何の罪もない された側が悪いという考え方のカスはおかしい。
物を壊してもそこまで怒らせるような行動を普段からしてるほうが悪い という考え方の人もいますよ うちの嫁ですけどね
>>750 vendorもまるっとコピーするなら不要 まあしかしデプロイ先でもアップデートとかできるようになってるほうがいいわな 転送もgitでやるほうが何かと都合がいいし そう考えると鯖それぞれに一通り環境は作っておいたほうが良さそう
>>755 ポリシーの違いだよ 君のやり方以外も許容しなよ eloquentなんか使わんでもクエリービルダーだけで何とかなるで。
アーティ=サンからmigration作った時にmigrationファイルが自動的に日付+テーブル名になるのマジやめて欲しいんだけど何とかならんの? テーブル定義したいのにクソファイル名のせいでファイル探すっていう無駄な工程が発生しよるんだが。 ターミナルからだと一発補完も出来ねえし。
アーティさんって誰だと思ったらArtisanのことかw マイグレーションファイルを探すのに手間取った経験は全くないんだが どうやったらそんなに苦労できるんだ?
>>762 作ったファイル開くまでに何回キー叩かせるんだよ。 ディレクトリのシンボリックリンク貼ってても10回近くキー叩くぞ。むしろアーティ=サンからファイル作ったら即vimで開いてほしいわ。 どうでもいいがArtisan=職人な 普通カタカナではアーティザンと書くと思う で、ファイル選択はGUIでエディタ使えば済む話なんだよなあ みんながSublime使ってるわけじゃないのはわかるけど 今どきvimやemacsでもないだろと
職人なんだからニンジャっぽくアーティ=サンって呼ぶのは実際礼儀正しいだろ。 ワイはlaravel始めてから間もないからよく分からんのやけど、composerって環境にあんまり依存しないんか? 現在のlaravelアプリの開発環境はほぼデプロイ用のAPサーバと同じにしてて、それってなんでかっていうとlaravelで編集したファイルをrsyncでそのまま転送してるからなんだ。 これが動作環境違うとコケる可能性があるってんならアーティ=サンはローカルじゃ叩けない。
× 叩く ○ オジギ よく考えたらアーティ=サン自体はcomposerとは関係ないな。試しにローカルでphpバージョンとか合わせずにやってみるわ。
そりゃスゴイフルイ・シンキングってもんだ むしろjsonさえあればどこでもサクッと環境を揃えられるのが composerなりnpmなりbowerの強み(の一つ)でしょうに マイグレーションも同じ目的 だからこそ実行順を保証するための日時が ファイル名末尾ではなく先頭に必要なわけで あとrsyncじゃなくgit使ったほうがいいぞ 同時に複数箇所を並行して修正とか「ここ一旦変えたものを見たい」とか絶対言われることのない仕事なら別だが 少なくとも.envが上書きされないように変な工夫とかしなくて済むし gitプラグイン入れればSublimeの中からコミット&プッシュできるし 何かと捗るぞ
>>766 動作要求さえ満たしていればphpのバージョンによる問題は経験したことがないな とはいえ確か5.6以上とかだからほぼ最新に限るという意味だが >>767 そりゃgitは使っておるが。pushした時にpost-updateでrsyncで配布するで。 流石にAPサーバ沢山あるのに全部のAPサーバのディレクトリにgitレポジトリは使わんやろ。ステージ環境までやな、gitは。 そこからpushして撒く感じや。 なるほど ローカルに環境は作ってないの? Appファイルは開発サーバ上で直接変更し デバッグもリモートでやってるわけ? あとこれは純粋な興味からだけど DBも各サーバに持ってレプリケーションしてるの?
protected $repository; /** * @return void */ public function __construct(TeamRepository $repository) { $this->repository = $repository; } コントローラーだとこんな感じに使えるけど、 これをTestクラスでも使う場合はどうすればいんだ constructで依存注入してもダメだし、ただインスタンス化してもcontainerがどうとかでダメだった
andersao/l5-repositoryってのがあるけど それ入れりゃ済むって話でもない?
$this->repository = $this->app->make(TeamRepository::class); 思いっきりマニュアルに書いてました
GitHubで色々Laravelのサンプルアプリ漁ってみたんだけど どれも1つのModelに対して1つのリポジトリーなんだよね やっぱりそういう原則が在って、何か理由でもあるのかな? 1つのModelに複数リポジトリー作らないと、 Classが肥大化するし単一責務じゃないんと思うんだけど
多分サンプルだとCRUDのRが2,3で事足りるのしかないんじゃないかね。それこそEloquentそのまま使えばいいじゃんレベルの よく使うメソッドだけリポジトリにして、 複雑なクエリは1クエリ1クラスにするってのはたまにやる Eloquent ORMでリポジトリパターンってなんかもやもやするんだよなあ
どこ読んでもDBに書き込んだりするのコントローラーの中でやってるけどモデルの中にメソッド作ってコントローラーから呼び出しすのって駄目?
>>777 普通にいいのか ありがとう ブログとかの解説読んだだけでサイト作ってたらコントローラー肥大化して困ってたから今度からそう書きます laravelのautuミドルウェアでログインしてたらjsonで「ログインしてる」って情報返してログインしてなかったら同じくjsonで情報返すようにしたいんですが、どこをいじればいいのでしょうか。 なんか実体はillminateだかのディレクトリの中にいるみたいですけどそこを弄るのは違うし……
>>780 何てことはない、Auth::check()を使えば良かっただけでした。 laravelで作ったWEBサービスのandroidアプリを作成する場合、 アプリはあくまでViewの役割で、laravelのapiを作成+利用という感じがベストプラクティスですか?
>>782 ベストかどうか分からないけどそんな感じのを作ったことはある アプリ側からデータ取るのに必要な情報をpostで受けとり、結果はjson形式で返す 皆はバリデーションの共有はどうやってますか? 自分はrequest側でもview側でも共有化するために config('validations.maxlength.user.name')みたいにやっています
laravelのhelperで一つ一つfunction_existsでチェックしてるけど 何の意味があるんだこれ
>>785 同名関数を定義しておくと差し替え可能なので拡張出来る namespaceに置かないんだから当たり前のこと
laradockにsupervisor導入したいんだけど どこのコンテナにインストールすればいいの
workspaceのdockerfileにsupervisorを自分で記述するだけで大丈夫でした
laravel5.3でnpm install実行しようとしたらこんなエラー出て進めない Unsupported platform for [email protected] : wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) npmは3.10.9、nodeは7.1.0 適当にぐぐったらnpm3.10.8以降がダメらしく3.10.7にダウングレードしろって書かれてるな
ajaxの処理中にセッションの中身使いたい時どうすればいいんだ・・・
別ドメインの場合の話かの? そんならLaravel無関係じゃぞい 同一ドメインなら普通にセッション取れるはず
>>794 $request->session()->all() Session::all() のどちらを行っても何も入ってないからてっきり特殊なことしないといけないのかと 自己解決しました。 post先のURLをapi.phpに登録してたのが原因でした。
なるほど 5.3でAPI用のルート定義が分かれたんだったか そしてAPI側とはセッションが繋がらんと 理に適ってるようでもあり不便でもあり
api.phpのルートはstatelessってドキュメントに明記してあるな まあ本来いろんなところからサービスを請け負うためのもんだから 自分とこ専用のサービスなら自分のルートでやれってことなんだろう・・・か
>>791 なんかひでえな。 ポンコツmac以外お呼びでないと。 ユーザーアイコンのアップロードで一時的にstorageディレクトリに保存→キューでリサイズ このパターンで行こうかなと思ってるんだけど storageに一時的に保存するのってバッドプラクティスにならない?
そこに置くのが一番バッドじゃない気がするがのう そこがバッドならどこに置けばグッドだと?
storage保存で無事キューイングも動作しました。 ありがとうございます!
複数ユーザーが使うならファイル名のバッティングには注意な どこに置こうと共通する常識の類だが念のため
しっかしまあ、ルーティングからデザインまで全部やると大変ね 楽になったとは言えフレームワークの学習コストもあるし 結局は、なんだかんだ既存のCMSに無いこと実装するわけだし
チラ裏容赦 collectionを継承すると色々使えてメソッドチェーンでサラサラ書けてステキ とか思って多用してたんだけど except()なんかが返すのは「新規インスタンス」なんだよね 生のcollectionを直接使うならそれでなんの問題もないけど 継承した子クラスが追加のプロパティを持ってて値が入ってる場合 それらはみんな消えてしまうわけだ 新規インスタンスだから当然なんだけど 結構そのことを忘れてバグを作り込んでしまうんだよな いや俺がヘボいだけなんですけどね 新規インスタンスじゃなくクローンを返してくれてもいいのにと思った次第 パフォーマンスを考慮しての仕様なのかね
>>810 状態を持っていないものに無理やり状態を持たせる設計を見直すか、 破壊的なメソッドを自分で追加するかどっちかだな >>811 とりあえずレス感謝れす 趣旨がよくわからんけどCollectionは抽象クラスではないね except()等のチェイナブルメソッドは具体的にはreturn new static($items);みたくなっているから たとえばCollectionを継承してFiltersというクラスを作ったとして $filters->except('filter1')はもちろんFiltersクラスのインスタンスを返す Collectionではなくてね しかしFiltersに例えばurlKeyというプロパティを持たせ、初期値以外の値を入れておいて echo $filters->except('filter1')->url(); なんてやったとしましょう url()の中で自分のurlKeyを見るとそれはもう空っぽなわけ 伝わるかなこの残念な感じ >>812 まあそうなんだけどね 継承して拡張することで状態を持たせたいという発想は許されないのかなと あと必ずしも破壊的である必要はなくて return new staticの代わりに $new_instance = clone $this; $new_instance->items = $new_items; return $new_instance; みたいになってりゃいいんじゃねと思うけど itemsがprotectedだからセッターを作る必要があって そうなると隠蔽性が壊れるっていう話なのかなと思ったりしないでもないでもない
>>813 責務を増やす事は簡単 その分テストは複雑になる これは宜しくない だから専門を新しく作ればいい $urls = new URLのリスト作る奴($filters, 'urlKey'); assert($urls->url() == $url); >>815 プロパティとしてCollectionを持って未実装メソッドはそいつに受け渡す形ってことね マジックメソッドとか気分的にあんまり使いたくないけどありだよね >>816 それがベストプラクティスって奴なのかな 今回のケースに限るとフィルタ(要するに絞り込み)の種類がやたら多い上に クエリパラメータの書き方が統一されておらず(既存サイトの書き換えです) 複数フィルタをまとめて扱うもの(いわゆる詳細検索)もあったりして やはり各フィルタのクラスがクエリパラメータ生成を受け持つべきと判断した次第なんだけど 失敗だったかもしれないなあ とりあえずCollectionにラッパーかぶせてチェイナブルメソッドがクローンを返すようにしてみたよ 30個ものメソッドをオーバーライドするんじゃ譲渡のほうがマシじゃんという話もあるがw まあ一回作っときゃ今後のストレスが減るかなと パフォーマンスや動作には今のところ問題なさそうですわ ほんとチラ裏な話が続いて申し訳ないw HasManyのEagerLoadingでlimit設定設定したいのですが Post::with(['comments'=>function($query) { return $query->limit(5); }]) ->get(); これだと1つのポストあたり5件じゃなく、全てのポストから5件を取得してしまいます。 解決策はないですかね?
eager loadingがどういうSQLに展開されるか調べてみそ 無理だとわかるから
ドキュメント読んでもイマイチ分からないんですけど laravel passportの主な実用例というのはどういったものでなんでしょう
質問の意図がよくわからんが とりあえずoAuthがどういうものかはわかってるのかな それがわかれば実用例も自ずとわかりそうなものだが
項目も細かくわけないでいいよね。 ドキュメントなんだから、いちいちページ変えるのも面倒だし、一覧性も高い方がいい。
日本語版はなんで本家のレイアウト変えてるんだろう メニュー無いのが不便で仕方ないから本家見てる
laravelのIDEはphpstormじゃないときつい感じか? netbeansはbladeの記述にのに対応してなくてダルいんだが…
なんで秀丸派おらんの? おれは全然不便してないけど。作業効率そんなに変わるもの?
秀丸ってWindows専用じゃん しかも4000円もするし
書くのはSublimeでデバッグはNetBeansだな Sublimeから直接XDebugが使えるみたいだけどまだ試したことはない
おれもSublimeTextだわ 秀丸を長年カスタマイズしてきた猛者ならわからんが、おれは気持ちよさが全然違う 実作業時間の話ではない
Sublimeは入れただけでよくわからなくてあんまり試してないけど、Atom使ってるけど適当に補完が効きまくるしキャメルケース?でも補完してくれるからかなり気持ちいいね user_first_name_kanaみたいなやつがufnkaとかで補完できる
どうでもいいがそれはスネークケースだな キャメルケースならuserFirstNameKana 先頭も大文字のはなんていうんだっけか
アッパーキャメルケースとかだった気がする。 まあその辺、いい加減全ての言語で統一してほしいよな
プログラム用途ならエディタなんて多くて一日一回、へたすりゃ週に一度しか起動しないぞ Sublime開きっぱなしだ
ずっと仕事してるわけでもないからな 家でエロい動画見てるとき職場から電話があって・・・ みたいなときすぐ立ち上がるほうが ストレスがなくていいわ
エロ動画みるのにエディタを閉じる必要あるのか? 仮想画面で切り替えた方がいざというときよくない?
>>846 そもそも会社以外じゃエディタなんぞ開かんっつってんの よっぽどの緊急事態に対処するとき以外はね っていうか、なんで自宅限定になってんだ?w Laravelをどんなエディタで編集してるかってことだろ
いろんなエディタを使い分けるのってそれ自体ストレスなんだから 利用ケースを制限するファクターは全てマイナス要因に決まってるだろ 特定プラットフォームでしか動かないなんてのと同じだ
>>850 ほんとこれ Xcode、Eclipse、Visual Studio、Atom、Xamarin Studio 泣きそう 配列のバリデーションで、 'item.*.price' => 'numeric' エラーメッセージに、配列の何番目がエラーを起こしたか表示したいんですが、 どのようにすれば出来ますか? 下記のように書くと 価格とは分かるんですが、何番目の価格なのかが表示されず 困っております。 resources\lang\ja\validation.php 'attributes' => [ 'item.*.price' => '価格', ],
俺も2秒位で思いついたけど、 ひょっとしたらウルトラテクニックがあるのかと思って黙ってた
配列のバリデーションしたら、何番目か知りたいと思うんですが ウルトラテクニック扱いなんですかねぇ・・・ :Index :Key とかで何番目か取れても良さそうなもんだと思ったんですが。
そもそも、配列でのバリデーションにこだわるってことは 要素の数が変わるフォームなんでしょ? だったら番号出ても意味なくない? 無駄に入ってない項目とか、間違った項目とか調べるくらいなら、 素直に一つ一つ項目ごとに変数に入れて検査すりゃいいんじゃね?
5.3→5.4にしたらバリデーションのnumericの動きが変わった。 5.3は未入力だnumericチェックされてなかったのに、 5.4は未入力でも数値入力しろって言われるようになった。
まあ本来のバリデーションの用途考えれば未入力もエラーになるべきだよね
>>850 まあねぇ。 Android: AndroidStudio Java: NetBeans PHP/Python: VSCode PHPStormでも、補完できない・警告でまくりでストレスあるわな。 Laravelだと特に。 AtomやVSCodeでもcomposerの参照くらいできるpluginはあるし。 どっちがいいとか一概に言えないな。
PHPStorm に laravelのプラグイン入れてもダメ?
Laravelイマイチはやってないから、人に説明すんのがめんどくせぇ
自作フレームワーク+Smartyでシステムを作り稼働中です。 このシステムのフレームワークをLaravelに変更し、HTMLテンプレートは 現状のまま(BladeではなくSmartyテンプレート)にしたいと思っています。 Laravel + Smarty だと、開発効率・可読性・メンテし易さなど、デメリット大きい でしょうか? とくに画面遷移の部分(バリデーションエラー時にPOSTデータを再表示するなど) が気になっています。 教えてください。 お願いします。
素直にbladeにすべき ちな、smarty→bladeの置換プロジェクトを進行中 開発中もデザイナーの更新がすすむので、直接書き直すのではなく、面倒でも置換スクリプトを書いてるよ もちろん汎用性はない
> 素直にbladeにすべき 何故でしょうか? 理由を具体的に教えてもらえませんか?
>>876 フレームワーク使って楽しようってのに わざわざややこしいことするなら そもそもフレームワークいらないじゃん LaravelはあんまりBladeに依存してないと思うけどな テンプレートエンジンの入れ替えは効くんじゃね? Smarty側の事情を知らんから迂闊なことは言えんけど
再表示なんかは当たり前だけど、普通に実装してるよ。 そのためのフレームワークなんだから。 ログインも、ユーザー管理も、データベースへの書き込みも全部用意されてる。 独自の実装にしたい場合を除いてLaravel使ったほうが楽
あ、Smarty使ってか…。 ごめん、やった事ないからそれは知らんw Bladeならできるよ。置き換えるのも大した手間じゃないでしょ
bladeの場合、value="{{ old('name', '初期値') }}" と書いて、コントローラーでの値設定をすべてすっとばすの ので、postメソッドでのエラーは、元のgetメソッドに return back()->withInput()->withError($this->errors); で返すだけの構造となる だから、blade使わないならコントローラーの構造がまったく別物になるよ もちろん、フォーム部品を全部コントローラーで用意するなら、smartyでもlaravel的構造を維持できるけどね そこまでやる価値はないと、俺らは判断した
それはむしろoldヘルパー(とRequestファサード)のおかげではないの? テンプレート内でグローバルなfunctionさえ呼べればいいような
ああそうか 既存のテンプレートは一切変更しないという前提だと無理だね デザイナーさんが絶賛書き換え中のプロジェクトならなおさら でも一気に切り替える前提なら フォームのinputのvalueだけ書き換えちゃえば済む話かなと
フォーム部品を全部コントローラーで用意するのは大した手間ではない気がします。 というか、その方が考え方がスッキリしていて良い気がします。 テンプレート内でグローバルなfunctionを呼んで表示する値を取得するのは、 ビューからロジックを呼ぶことになり、あまり綺麗ではないような・・・ Bladeを使う人はold()を使いまくっているだろうから反対されそうですが。
ビューからロジックを呼ぶってのは <?= Request::has('name') ? Request::input('name') : '' ?> みたいに書くことを言うんじゃねーの? HTMLしか知らないデザイナーのオネーサンが書いたページにも 最小限の手間で入れられる、さらには 「こう書けばええんやで」と教えれば オネーサン自身でも何とかなるレベルのシンプルさになることが重要なのであって そういう意味ではコントローラでコンポーネントを組み立てるなんて考え方のほうが よっぽどビューとロジックの混合でありバッドプラクティスなんじゃないかと
でもキッチュでポップなコンテンツだと、 センセーショナルなグローバリズムの観点から言うとロジックがカジュアルだから コンパイルのためのリソースがオーバードーズするよな
Laravelを書いてるとビュー=HTMLテンプレート脳になるので忘れがちだけど、ビューにもビューロジックがあるわけで。少し複雑になったときにどこに置くかはたしかに迷うことあるな ヘルパ関数か、横着してモデルにくっつけるか、プレゼンター使うか、フォームだったらフォーム専用のオブジェクト作るかなど
(ビジネス)ロジックとビュー(ロジック)の混合 言いたいことはわかるけど言葉は正しく使ってくれよな
ドメインロジックとか言うんだよな 普通はコントローラに置くな、モデルに持たせろっていう話になる ビューに書くなんてもってのほか
いずれにせよvalue="{{ old('name') }}"をロジックと呼ぶのがそもそも間違いだな もし問題にするとしたらグローバルな関数名を使いすぎというところだろうが そこはLaravel(特にv5以降)の思想のうちってことになるんじゃないかな 「タイピング量を減らす」っていう明確な思想 名前空間の導入でクラス名全般のタイプ量が増えたことに対する対策 グローバルとは言っても関数は変数と違ってユーザーによる汚染は不可能だし 定義時に存在チェックもしてるんだから 関数名がかぶってもそのヘルパーが使えなくなるだけなので 自己責任の範囲と言えるだろうよ 使いたくなけりゃ無視できるという意味でね
ただのヘルパーさんでしたか それは失礼いたしました。
>>887 バットプラクティスだと思う デザインをbootstrapに変えるとか、何かしらプラグインで拡張するとか デザイナーからの要望でチェックボックスとかの出力要素をいちいち変える? 関数名とその関数が書かれているファイル名とを何らかの形で関連付けるルールが必要になるだろうな それをやるなら現状のままその名前空間に一個ダミークラス(Fnとか)を置いて そのメソッドとしてぶら下げることにすれば ほとんど同じ感覚で使えそうだが
bladeのタイポエラーのとき、strage/framework/viewsのキャッシュファイルで位置を調べるけど、 デザイナーさんは(権限あっても)サーバー覗く技量ないよね laravel.logとキャッシュファイルからエラー箇所を教えてくれるツールとか、 ないのかしらん?
>>899 そういうの欲しいと切実に思ってたけど デバッグが必要なほどのロジックをビューに置くな という戒めと思うことにした EloquentにDBに存在してる変数以外を持たせるのって間違った設計? save時に全部insertしようとしてエラーになるけど、対処方法がわからないよ・・。
意味がよくわからんが普通にプロパティを追加して使ってるぞ もしかして$attributesに直接キーを追加してるのかな?
>>902 そういうことか! 変数定義しないで直接ぶっこんでたのがいけなかった ありがとう。 どちらかと言えばfillableを推奨してるしfillableの方が
つかそれやる意味ある? 普通にクラスプロパティでええやん
デザイナー様には、ThymeleafのようなHTMLフレンドリーなのがいいだろうね。
今日jsonを吐き出させようとしてわかった toJson()を使うならアトリビュート追加する意味があるんだな
>>887 今時デザイナーにhtmlいじらすなよ cssだけでいいだろ 逆に効率悪くなるぞ laravel.jp って更新止まってる? リンク切れだらけだけど
唐突だがEloquentのCollectionのmergeメソッドには超要注意ですよおまいら 加える対象の配列に入ってるモデルはidを持ってることが前提になってて もしidのないモデルの配列を加えてしまうと元のCollectionまで要素が一個になっちゃう もちろん普通のEloquentモデルはidを持ってるわけだが DBから取得せずnewで作ったモデルを mergeで追加しようなんてことは絶対考えちゃダメ いいか、絶対だぞ 俺みたいになりたくたかったらな! orz
>>913 要素が全部消えるの?説明がよくわからん。 なお加えるのが空の配列でもだめ こっちの方が怖いかもしれないな
あー、なるほど。引数に渡したCollectionに複数要素が入ってても、IDがなければ一番最後の要素しか残らないってことか。
いやちょっと待って整理する mergeの引数はコレクションじゃなくて配列なんだよね 元のコレクションに入ってるモデルにidがないことが前提だな、多分 それだと元のコレクションも要素一個になる 引数の配列に入ってるモデルにだけidがない場合は 元のコレクションは無事で済みそうだ 試してないけど
ソースを読めばモデルのgetKey()メソッド(id取得)でキーイングしていて まあ当然といえば当たり前の挙動なんだな でも$query->get()したコレクションをmapメソッドで中身を別の新規モデルにして・・・なんてやって 元がEloquentのCollectionであることを意識せずにいてひどい目にあった次第 ちなみに普通のCollectionではなんの問題もないから いったんcollect($collection->all())なんてやって変換すれば大丈夫
なるほど。まぁMapとListの区別がないPHPらしい挙動ではある。
しかしmap()は普通のCollectionを返すはずなんだよな・・・ 俺のケースでなんでEloquent\Collectionのままだったのかよくわからなくなってしまった まあもう問題は解決したからいいんだけど そう考えるとあまり普通には起こらないはずの現象ではあるな mapにしてもfilterにしても結果はEloquentではなくIlluminate\SupportのCollectionだから
Laravelけっこういいのになんでこんなに過疎ってるん?
Laravelは他のフレームワークと比較してライブラリとかプラグインを作りやすいと思うけどPackagistとかで公開してる人いる?
そもそもフレームワークなんて語ることないんじゃね? 質問くらいなもんでしょ
不満でもあればぐちぐち書き込めるけどそれも特にないw
質問ですが、 ・CRUD処理の Create(レコード追加)と Update(レコード更新)のアクションに おいて、それぞれ「保存(Save)」のメソッドを定義するときに、 これらは同一でいいんですか?分けたほうがいいんですか?
通常は新規時にinsert、更新時にupdateクエリを走らせる、 そんでinsert時は大抵idは未指定でDBの自動生成に任せるはず ラッパーのupsert関数を用意するなら同一に出来るけど、 結局内部ではidの有無で切り替える処理になると思う
モデルのsave()使うだけでダメな理由あるんだっけ?
ないと思う むしろupdateを使うとイベントが発火しないから よほど大量の更新じゃない限りsaveでいいんじゃないかと
html を出力する際に、ブラウザがレンダリングするのに不要な改行やスペースを削除する機能はあるのでしょうか? Twig でいう spaceless のような機能のことです 詳しい方どうか教えてください
Laravel Html Minify とかで検索するといくつか見つかるね。textareaとかpre、scriptタグのこと考えるとあんまりおすすめできないけど。 gzip圧縮しちゃったほうがよくない?
white-spaceをpreにしてる事はあんま無いとは思うけどそのHTML次第だからなんとも言えない
LaravelってsymfonyのFormみたいなのないの? 使うならSymfonyのフォーム入れて使えってことか
最近laravel勉強し始めたんですが サーバエラーが起こった場合のエラー内容がわかりづらくて困ってます コードの何処かに打ち間違いとかがあった時に どこでエラーになっているのかとかがすごくわかりづらいんですが 皆さんどうやって見分けてますか? コツなどあれば教えてください
ごめん不親切だったわ logger使ってログファイルをtail -fするだけでも大分捗るぞ
>>939 productionモードでやってない?devにすると行数まで出てたような。 例えばEloquentモデルで持前のメソッド名を間違えたときに フレームワーク内でのエラーになっちゃうからね マジックメソッドの弊害
持前じゃない、自前ね なんでこんなのが変換候補に出てくるんだ・・・
でも、スタックトレースにはどっかに自分の書いたコードのファイル名と行数が書かれてるわけだから、どこで間違えたのかを見つけるのはそこまで難しくもなくない?
やっぱ慣れるしか無いんですね メソッド名を1文字間違えてたときとか原因わかるまで結構時間かかってしまったんですが とりあえず頑張ってみます
>>948 そういうのはLinterの出番 「PHPMD」でググると幸せになれるかもしれない 逆にマジックメソッドは正しくlintできるんだろうか スコープとかミューテータとか そのままの名前のメソッドは存在しないわけだけど
APIのルーティングはどこに書けばいいですか? あと普通のルーティングと書き方って何か違いますか? 同じところに書くと何かまずいですか?
最新版ならapi.php ただしweb.phpのルートとはセッションが繋がらないので要注意 単にajaxの受け口など自サイト専用のapiなら web.php側に書くほうがなにかと楽だと思う 多分ベストプラクティスからは外れるんだろうけど
モデルのリレーションで複数キーの場合どうやんの? いちいちジョインするの面倒っすわ
>>954 複合キーでJOINする必要があるってこと? 366 :nobodyさん 2017/05/29(月) 16:07:39.16 ID:6v4UcGhE 今回の民法改正、ソフトウェア受託開発の場合、(検収後ではなく)バグ発見後1年瑕疵担保責任があるということで、地獄かよ、と思ったが、 元々問題が起きがちな受託案件がビジネス的に成立しなくなることで強制的に業界再編につながるなら良いことかもと思うようになった。 一部で地獄を見ても。 https://twitter.com/yukihiro_matz/status/869061879389343744 367 :nobodyさん 2017/05/29(月) 16:28:06.55 ID:6v4UcGhE ニュース - 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大:ITpro http://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 >>378 >>379>>375 客が瑕疵担保責任法の法改正を知ってくると思うから、今後5年無償保証をお願いされるだろう 営業がそれでも仕事を取ってこれるか?たぶん無理だろう。無限の直していたら赤字になる。 こういう保守に弱い言語、ころころ仕様が変わる言語は仕事として発生しなくなってくる。 これは変わり目だ。お前らも早く逃げたほうがいいぞ。RubyやPHPなど動的言語は確実に廃れる。 保守に強い言語のみ生き残れる。 普通リリース後はバージョン固定だよな 「バージョン○○まで面倒見る。それ以降は知らね」と契約するもんだ
ポイント1:修補や損害賠償、契約解除の期限がなくなる 従来あった「瑕疵担保期間は引き渡しから1年」という考えはなくなる。 条文にある通り、注文者は成果物が契約の目的に適合しないことを発見したら、 その「発見したときから1年以内」ならさまざまな請求ができる。発見が10年後なら、 11年後まで請求可能なのだ。 もっとも、現実のユーザーとベンダーの関係でも、たとえ契約書に「瑕疵担保責任期間は納品から1年と」明記されていても、 「2年目以降は不具合の修正に対応しない」と主張するベンダーはまれだ。多くの場合は、納品から何年たっても、 バグが見つかればユーザーのところに飛んで行き、無償で改修するだろう。
>>959 ライバル社とのコンペで負けるな。ライバル社は無償保証を提案してくるだろうから >>962 それはバージョンアップしない前提だろ そりゃバグが出ればメンテするわな laravelの「イベント」ってどういう意味なんでしょうか? 調べてもよくわかりません どなたかわかりやすく解説してくれませんでしょうか?
何かが起きたときに自動で何か処理したいとする その「きっかけ」となる何かのことをイベントと言う 一般的にね LaravelというかEloquentのイベントはデータ作成や更新といった「きっかけ」で 何らかの処理を自動で行わせるために使う 会員が最低一つはメルマガを購読するとしたら 会員モデルのcreatedイベントにメルマガ購読モデルの作成を仕込んでおけば あとは会員を作成するだけでいいというわけ というかプログラムのどこで作成しても必ずメルマガ購読データも作られるようになる まあ処理し忘れを防ぐ機能とも言える マメな人なら必要ないとも言えるかもしれん
>>963 >そりゃバグが出ればメンテするわな 当たり前だ!ただでやれ。金は出さないよ。法律改正されたし、 アップデートごとにバグが出たら、何十年も無限無償でよろしく! バックれたら瑕疵担保責任法で訴えるからな! わかったか! >>965 なるほど 最初はイベントなんか使わなくても対象の箇所に適当なメソッドを挟めばいいんでは?と思ってたんですが もっと深い箇所に埋め込みたい場合はイベントの方がいいんですね ありがとうございました うむ 深いところ、というよりはデータ自身に付随させる という考え方のほうがいいかも Laravelというかこの手のフレームワーク全般に言えることでもある ミューテータとかもそんな感じでしょ めんどくさい処理はデータモデルに任せて表では楽しようという
>>968 なるほど! 大変わかりやすい解説ありがとうございました! Laravel使ってるんですが 正直使いづらくて何がいいのかさっぱりわかりません ルーティングは機能ごとに毎回追加しないといけないし nameスペースもいちいち追加するのがめんどくさいし 吐き出されるエラー内容もわかりにくいし ドキュメントも充実してないし こんなフレームワーク使うよりは Codeigniterの方が使いやすくていいと思うんですがどうでしょうか?
>>970 数人かそれ以下のPGで制作する場合は Symfonyやその派生の巨大フレームワークは 却ってボトルネックとなると思う。 PG兼SE1人の制作環境では修行しているような気分になるはずだ。 しかし多数のPGを使って制作する場合は リーダーが外枠(フレームワーク内のフレームワーク)をきっちり準備すれば スムーズに事が運ぶと思われる。 俺は大人数での制作に関わる気は毛頭ないから CodeIgniterの高速性を取るし(最近はCodeIgniterすら使わない) Symfony系の巨大フレームワークは壮大な無駄にしか見えない。 ドキュメントが充実していないというのは誤解のような気がする。 Symfony系のフレームワークは色々な団体・個人が開発したソースの集合体であり どこかが一括してドキュメントに責任を負っているわけではないのだろう。 Symfony系が粗大ゴミにしか見えない者にとってはどうでも良いことだが。 Laravelの良さはコマンド一つでサクサク環境作れることじゃない? SQLインジェクション対策とか、ログイン関係のセキュリティ対策も完備しているし、 コマンドも自分で簡単に追加できるし、普通にフレームワークとしての機能は完備してる 解説は確かに昔少なかったけど、解説本も出たんだから買えば解決 ただ、公式の解説や、本体を翻訳してくれてる有志が居るし恵まれてる方でしょ
Laravelで数少ない不満はhasOne :throughを頑なに拒み続ける事
Laravelのどこがドキュメント恵まれてないんだ? CodeIgniterの方が負の遺産抱えすぎて悲惨だろw 未だにアンダースコア区切りでやってんのかよ
ApacheできないけどLaravelできますか? PHPは割りと理解している(.so 関係, peclモジュールとかは怪しいレベル) Composerはギリ Railsはできる。 JavaScriptは結構得意。(jQery, Reactいける。) MySQLも使い慣れている(スキーマとかGRANTもできる)
Apacheできないってどういう意味だろ 設定できないってことかね
Laravel使うようになって初めてcomposer使うようになって、未だによくわかってないけど問題ない Apacheの設定もいじるのはDocumentRootぐらいだと思う、/以外にLaravel設置しようとしたら大変かもしれないが
vagrantさえ動かせれば何も考えんで済むよね windowsだとなにかとトラブって動かせたことがないが まあxampp入れれば環境はすぐできる
>>980 そうそう、xampp頼みで Apacheは勉強不足なんだわ。 vagrant本気でやってみようかな? Dockerは勉強したんだけどね、誰かが構築済みのやつを拝借してしまえばいいわけだ。 つまりxamppの代わりをvagrantにやらせるってことでしょ? >>981 違うよ。 xamppはwindows版apacheとmysqlとphpなどのセット。 vagrantはvirtualboxやvmwareでlinuxの環境を簡単に作るためのツール。 サーバの設定は自分でやらないといけない。 xamppみたいにボタン押せばとりあえず使えるといったシロモノじゃない。 それでも俺はvagrant+virtualboxをすすめる。 PGでもサーバの知識は必須なので、今のうちにやっといた方がいいよ。 LaravelにはHomesteadがあるから サーバの知識何もいらんよ
生涯Laravelならそれでもいいかもだけどそうも行かないだろうし 機会を見てサーバの知識は持っておいたほうが良いとは思うけどね
もちろんそうだ vagrantさえ動けば何も考えんでいいと書いたのは homesteadがあるから、という話だよ vagrantを動かした上で色々設定の必要ありというのは ことlaravelに関する限り当てはまらないということ
どのos imageを使うかにもよるが、サーバの知識無しではしんどいよ。 サラのimageだったらphpから入れる必要あるしね。 けっこう面倒。 でもやる価値はある。
とりあえずLaravelやりたいだけならxamppでいいべ。 作ってからアップロードするときにでもサバの勉強すりゃいいし。 なんでもかんでも手を出すと、結局何もできないことになる。
symfonyのBundleみたいにひとまとまりの汎用パッケージにするのってどうやるの?
コントローラからビューに渡すときにグローバル関数使ったり、設計が滑稽過ぎるだろ… 誰だこんな変なフレームワーク流行らせたやつ
ヘルパ関数が嫌ならViewのファクトリを注入すればいいだけだが
>>994 フレームワーク側でそんな設計にしてるのが間抜けだって言ってるのがわからない? >>994 そうやって自分ルールを増やして可読性を下げたりしないためのフレームワークなのに Viewファサードを使うか、viewヘルパ関数を使うか、Viewファサードの移譲先のクラス\Illuminate\View\Factoryを直接使うか、フレームワーク側では複数の選択肢が用意されているので どれを使うかは利用者が決める必要がある 複数人で開発するならその辺りの規約を決めておかないとカオスになるよなー Laravelの思想的には記述量が短いファサードやヘルパ関数が推奨なんだろうけどおっしゃるとおり設計はお察し
Laravel5.4.25使ってるんだが、bootstrapのdatetimepickerの導入方法を分かりやすく教えてくれないか…。 英語の記事は見つかってその通りにやってるつもりなんだが、そもそもjQueryが読み込めてないのか「$ is not defined」とかでエラーが出て進まない。 そもそもLaravelMixだっけ?あれで導入しなきゃいかんの?
>>999 知らんけど「$」を「jQuery」に書き直してもダメ? lud20221026112446ca
このスレへの固定リンク: http://5chb.net/r/php/1358215310/ ヒント: 5chスレのurlに
http ://xxxx.5ch
b .net/xxxx のように
b を入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「[PHPフレームワーク]LaravelYouTube動画>2本 」 を見た人も見ています:・【PHPフレームワーク】Laravel【ID強制】 ・【PHP】Laravel【フレームワーク】 Part.10 ・【PHP】Laravel【フレームワーク】 Part.5 ・【PHP】Laravel【フレームワーク】 Part.3 ・【PHP】Laravel【フレームワーク】 ・【PHP】Laravel【フレームワーク】 Part.5 ・【PHP】Laravel【フレームワーク】 Part.6 ・【PHP】Laravel【フレームワーク】 Part.2 ・【PHP】Laravel【フレームワーク】 Part.12 ・【PHP】Laravel【フレームワーク】 Part.13 ・【PHP】Laravel【フレームワーク】 Part.11 ・【PHP】Laravel【フレームワーク】 Part.4 ・Webフレームワーク比較 MVC Rails Node.js Laravel ・【PHP】フレームワーク Akelos ・2ch有志がPHPフレームワークを作るスレ ・symfony PHPフレームワークpart2 ・NTT製Javaフレームワーク 「Macchinetta(マキネッタ)」公開へ ・【PHP】フレームワークPharonスレ ・【PHP】フレームワークMapleに舌鼓 ・【PHP】Phalcon【フレームワーク】 ・【PHP】[フレームワーク] kohanaスレ ・【TRF】TravelFlex part.3【エスポワールで世界旅行】 ・Javaの鉄板フレームワークとは ・javaのフレームワーク ・【IT】JavaScriptテストフレームワーク、「Jest」が急成長中 ・自作フレームワーク発表会【PHP】 ・【PHP】フレームワーク CakePHP 17ホール目【v3α】 ・【IT】google謹製のクロスプラットフォームなアプリ開発フレームワーク「flutter」待望のβリリース ・【PHP】フレームワーク CakePHP 19ホール目【v3.3】 ・【Python】Webフレームワーク Djangoスレ Part3 ・【Python】Webフレームワーク Djangoスレ Part2 ・【Perlフレームワーク】Catalystを語る人 ・【競泳】池江璃花子、パワーストーンの天然ウラン鉱石(北朝鮮産)を肌身離さず持ち歩く「放射線が血流に良いんです」 ★2 [Time Traveler★] ・フレームワークってなんですか? ・UIフレームワークライブラリ ・モバイルアプリ開発フレームワーク ・【RIA】Sencha Ext JS 4【フレームワーク】 ・【言語不問】最もいいフレームワークって結局何? ・「ライブラリ」「フレームワーク」「API」「SDK」 ・【青海】ソフトバンクフレームワークス【東扇島】? ・プログラマに聞きたいんだけど「フレームワーク」と「ライブラリ」って別物なの? ・プログラミングに詳しいやつ、「フレームワーク」「ライブラリ」「モジュール」って何が違うの? ・俺たちのapache struts2が今度はぴあで情報流出させSIer御用達フレームワークとしての貫禄を見せつける ・プログラマに聞きたいんだけど「ライブラリ」「フレームワーク」「API」「SDK」 って全部同じなの? ・ぶっちゃけ始めるのにいいフレームワークって何 ・結局PHPのフレームワークってどれがいいの? ・【Python】Python Webフレームワーク総合スレ ・【IT】今最強のフレームワークって「React」で良いのか?どこでも使ってるよな ・【話題】ココイチとアズールレーンのコラボを見た人が激怒 「食欲失せた」「風俗雑誌みたい」「ピンクだらけで入りにくい」 #さくら [Time Traveler★] ・Dr.Motte / Rave The Planet【ラブパレード】 ・円高?円安?part4059 Raven of the Inner Palace ・【Blackmagic Design】 DaVinci Resolve Studio Part4 【カラーグレーディング】 ・フレームアームズ・ガール FRAME ARMS GIRL 40体目 ・フレームアームズ・ガール FRAME ARMS GIRL 43体目 ・【コトブキヤ】フレームアームズ-FRAMEARMS- part41 ・【コトブキヤ】フレームアームズ-FRAMEARMS- part61 ・【コトブキヤ】フレームアームズ-FRAMEARMS- part64 ・【コトブキヤ】フレームアームズ-FRAMEARMS- part69 ・【コトブキヤ】フレームアームズ-FRAMEARMS- part69
12:54:14 up 11 days, 22:02, 7 users, load average: 8.69, 8.45, 8.13
in 0.062759876251221 sec
@0.062759876251221@0b7 on 120202