参考として、メモを残しておきます。
たぶん、皆引っかかるところは同じだと思います。
ちなみにここを見て勉強していた時に思ったことです。
https://www.tuyano.com/index2?id=4536003
■まず、PHPという言語がおかしい
perlもだいぶ変で、ちょっと複雑になると非常に使いにくかったので、五十歩百歩といえばそのとおり。
変態なところ
・TRUE==”0.0″だったりする件。勝手に型変換するので、意図しないものが一致と判断されてしまう。型変換無しで比較するには「===」が必要
・配列と連想配列がごっちゃ。混ぜて使うこともできるという、非常に気持ち悪い仕様。
・配列を代入すると、要素まで全部コピーされる。他の言語では配列って参照渡しなのに。
・オブジェクトを作った後に、クラス内のメソッドhogeをコールする時に「hoge()」とするのがだめ。わざわざ「$this->hoge()」と書かないといけない。なにそれ！？
■そもそもフレームワークというものに馴染みがない
プログラミング言語で一からガリガリ書いていくスタイルに馴染んでいるので、フレームワークという概念そのものがなかなか受け入れがたい。
ライブラリを使う場合でも、ライブラリは部品として使っているだけでアプリケーション全体は自分で組んでいた。
しかし、フレームワークとなると、アプリケーション全体がお仕着せになって、その中の一部分だけを書くという行為になる。
発想の転換がだいぶ必要。
■composerってなに？
PHPをインストールしてcakephpをインストールするのかと思ったら、PHPをインストールした後はcomposerというパッケージ管理ソフトもどきを入れて、composerからcakephpのプロジェクトを作る形にするらしい。
composerはプロジェクトを作成する時にそのプロジェクトに必要なライブラリ群を勝手に集めてプロジェクトの雛形を作ってくれるソフトウェア。
プロジェクトごとにライブラリをかき集めてくるだけなので、環境を汚さないのはすばらしい。
■cakePHPは2系統と3系統がある
言語もバージョンで挙動が変わるように、フレームワークもバージョンで挙動が違う。
特に、2系と3系でだいぶ違うらしい。
フォルダ構成なども変わっているようで、勉強する時にどちらで勉強するべきか悩む。
■プロジェクトを作ると勝手にファイルがたくさんできる
自分でファイルを一つ作って、その中にプログラムを書いていく……というオールドスタイルに慣れているため、最初からファイルがたくさんできるので焦る。
実用上、全てのファイルのことを完全に理解する必要はないらしい。
しかし、本能的に「プロジェクトの中にあるファイルは理解しないといけない」と思ってしまうので、最初の時点で気が重くなる。
こういう完璧主義がフレームワーク嫌いの原点かもしれない。
■MVCモデルについて
データベースへのアクセスを司るModelクラス
データを制御するControllクラス
画面の表示を司るViewクラス
この３つを組み合わせて一つの画面を作る。
そこまではわかる。
しかし、画面の表示用にデータを集計する処理はどこに書くんだろうか。
Controllに書いても良い気がするし、Viewに書いても良い気がするし、データベースから取ってきたところで処理をするということでModelに書いても良い気がする。
そのへんは作成者が自由に選んで良いのか、それともそういったところまで作法があるのか。
そのへんがよくわからない。
追記→
Viewはデフォルトのクラスを使うので、プログラムを書くのはModelかControll。
そしてModelはデータベースの定義的なことしか書かないので、実質的に処理は全てコントロールに書く。
整理できた。
■mySQLの設定ではまったこと
Windows環境でMySQLをインストールしてる環境。
そこで、App.phpにDBのhostとして「localhost」という名前を登録してもうまく動かなかった。
「127.0.0.1」と書いて初めてアクセスできた。
なぜ、localhostが通らなかったのか……
■autoRenderってなに
自分のコントロールクラスを作って、その中からHTMLコードを吐き出すサンプルプログラムの中で、
「$this->autoRender = false」
という設定をしていた。
なにかと思ったら、これをすると自動描画が無効になるらしい。
これを無効にしないと、ViewやModelを使おうとしてエラーになるらしい。
（このサンプルはコントロールクラスだけしか作っていないので）
■URL名（アクション名）が滅茶苦茶気持ち悪い
「HelloController.php」というControllクラスのファイルを置くと、特に設定ファイルの編集など必要なく、
「http://127.0.0.1:8765/Hello」
というアドレスでそのコントローラが呼ばれるようになる。
「Hello」というファイルを置いているわけではなく、「HelloController」というファイルを置いているのに、「Hello」というアドレスでアクセスできる気持ち悪さ。
中身の処理的には「リクエストで「/Hello」と来たら後ろに「Controller」を連結してHelloControllerを呼ぼう」とやっているだけで不思議なことはなにもない。
しかし、なにか気持ち悪い。
Controllerクラスの名前が「Hello.php」とかだったらこんな気持ち悪くなかった。
■不思議なURL形状
Controllerクラスの中に複数のアクションを定義できる。
例えば、「HelloController」とクラスの中に、「index」アクションと「hoge」アクションと「moge」アクションを作ったとする。
すると、
「http://127.0.0.1:8765/Hello/hoge」
「http://127.0.0.1:8765/Hello/moge」
「http://127.0.0.1:8765/Hello/index」
※↑「http://127.0.0.1:8765/Hello」と同じ
の３つのURLでアクセスできるようになる。
ここまではいい。
クラスの中にアクションという階層構造になっているので、それをディレクトリ構造にマッピングするのも理解できる。
しかし、パラメータのとり方が不思議すぎる。
CGI時代の考え方だと、例えばメールアドレスをパラメータに入れようとすると、
「http://127.0.0.1:8765/Hello/moge?mail=hoge@hoge.jp」
とかになりそうなものだ。
しかし、実際は
「http://127.0.0.1:8765/Hello/moge/hoge@hoge.jp」
という不思議なとり方をする。
アクション名の後に、ディレクトリの表記でパラメータを書いていく。
複数のパラメータがあるときは
「http://127.0.0.1:8765/Hello/moge/パラメータ1/パラメータ2/」
と更に深いディレクトリの表示になる。
URLの表記上綺麗なのはわかるけど、すごく不思議な感覚を覚える。
※なお、URL最後に「/」を入れても入れなくても同じ挙動をする模様。そこらへんはありがたい。
■Viewクラスの意味がわかりにくい件
HelloControllerというのを作ったら、ビューとして「HelloView」というクラスを作らないといけないかと思ったのだが、いらないらしい。
コントロールクラスで「index」とか「moge」とかいうアクションを作ったように、ビュークラスでも「index」や「moge」というアクションを作って、その中で表示に必要なコードを書く必要があるような気がする。
しかし、実際にはそんな必要はないようだ。
ビュークラスはデフォルトのビュークラスをそのまま使うだけでよく、継承してカスタマイズをする必要がないらしい。
そして、コントロールから変数を渡してビューの表示内容を変えたい場合でも、
テンプレートファイルの中に変数名を表示するコードを書いておけばいい。
この辺りはデフォルトのビュークラスがやってくれるので、自前のビュークラスを作る必要がない。
「ビュークラスは自前で作る必要がない」というところがポイント。
■データベースとの連携
データベースにテーブルを作るときに、複数形の名前にする必要がある。
なんかこれがすごく気持ち悪いんだけど。
例えば「person」というテーブルを作ってはいけなくて、「persons」というテーブルを作る必要がある。
また、テーブルの中の「id」と「name」という項目は特別扱いされている模様。
※「id」プライマリーキーとして認識される。
※「name」レコードのタイトルとして認識される。
その後に、cakephp側では
「cake bake model persons」
と打つと対応するモデルのクラスファイルを生成してくれる。
データベースの情報を読み取って、勝手に「これはテキスト」「これはNULLは駄目」とかバリデーション用のプログラムを勝手に生成する。すごい。
「Person.php」テーブルのレコードに対応するクラス
「PersonsTable.php」テーブルに対応するクラス
■フォーム関係
フォーム系は自分で書くのではなく、勝手にフォームのHTMLコードを吐いてくれるメソッドを使う。
何も指定しないとフォームをSUBMITすると現在のURLに再度飛ぶかたちになるし、指定すれば別のURLに飛ぶことも可能。
なお、ページに「直接アクセスした場合」と「フォーム経由でアクセスした場合」の判断は「GET」か「POST」で区別する。
また、ただ単にフォームを作ると、（当たり前だが）各項目が空白である。
フォームを作る際にデータベースから読んだ連想配列を指定すると、各項目にその値が入っているフォームを作れる。
その場合、「_method」というフィールドに「PUT」という文字が代入される。
これにより、Controller側で初期値が空白のフォームから飛んできたか初期値が入ったフォームから飛んできたか判断できる。
■データベース関係
personsというテーブルがあるとすると、そのコントロールクラスから
「$a = $this->Persons->find()」
で検索できる。
さらに、条件を数珠つなぎで指定できる。
「$ra = $this->Persons->find()->where([“name like “=>’%hoge%’])->limit(3)」
この形を見ると、find()がデータベースを全部取得して連想配列を返し、その後にフィルターで絞り込んでいるように見えるけど、そうではないらしい。
じつはこの＄aの状態ではまだクエリーを作っているだけ。
だから、こんな指定の仕方ができる。
この$raに対して、foreachしたりすると、初めてSQLが発行されてデータベースにアクセスされる模様。
隠蔽されていて優雅と言えば優雅かもしれないが、なんというか非常にわかりにくい。
明示的にSQLアクセスしていないので、理解していないと嵌りそう。
なお、データベースの項目に合わせてメソッドが勝手に作られるといういたれりつくせりな仕様。
例えば、「mail」というフィールドがあると、「findByMail」というメソッドが作られて、それでその項目を文字列一致で検索できる。
ここはすごいよな～
■最終的にbake最強
bakeというコマンドがあって、上の方でモデルを生成させているが、実はもっとすごい。
まず、データベースでテーブルを定義しておいて、
「cake bake all テーブル名」
と打つだけで、そのテーブルのCRUD操作（作成・表示・更新・削除）ができる用に
・Controller
・テンプレートファイル(.ctp)
・Model
を作ってくれる。
データベースの設計さえしておけば、そのデータベースを読み書きするためのものが全部出来てしまう。
ここからレイアウトとかいじっていけばいいということなので、物凄く楽。
これはすごいわー。
■結論
cakePHPは理解すればなかなか効率がいいフレームワークっぽい。
とくにbake最強すぎる。
データベースの設計さえしてしまえばとりあえず動く物が作れるというのはいい。
ただ、PHPという言語そのものは微妙だよね、という点は変わらず。
■メモ
リンクを張った勉強サイトには書いてなかった（or読み飛ばした）けど大事なことについて。
◯データベース
・主キーは「id」である必要がある
・他のテーブルから参照するキーは「~_id」である必要がある。
◯名前の対応
※めっちゃややこしい。
・Controller
UserNamesController
・Model
Table:UserNamesTable
Entity:UserName
・データベースのテーブル名
user_names