Railsをかじったことがある人がFuelPHPのプロジェクトをざっと把握しようとしたときのメモ
急遽FuelPHPのコードを読む必要に駆られたので、てきとうすぎるから詳しい人から怒られるかな、と思いつつ、
http://fuelphp.jp/docs/1.7/index.html
を読みながらざっとメモしました。1.8まで出ているのですが、バージョンが1.7なのは読むべきコードが1.7だったからです。
書くためじゃなくて、読むためのメモなのでインストールについては、
http://fuelphp.jp/docs/1.7/installation/instructions.html
などを見て済ませています。。
あと、まだRails触り始めて、10ヶ月くらいの初心者なのでRailsの方もかじったことがある程度で、以下の意見はRails派代表とかそういうわけじゃないですし、用語も若干怪しいです。
内容
- FuelPHPについて
- コントローラについて
- ビューについて
- テンプレート
- コンテンツ
- テンプレートを使わない設定
- モデルについて
- モデルクラスの基本
- Model_Clud
- Orm
- 最終的にどの手順で見ていくと手っ取り早そうか
FuelPHPについて
Railsと比較してみたFuelPHPについての印象
Railsが設定より規約に基づいて設計されているのに対し、FuelPHPは規約より設定に基づいて設計されている、のが特徴らしいです。
たとえば、
ファイルの拡張子に対してどのMIMEタイプを割り振るのかなんて言うことも、
データベースから日付を取り出すとき、どの形式で取り出すかといったことも全部coreディレクトリにはいったFuelPHPの本体のコードに書いてあります。
この辺、Railsでは、そう言う機能使いたいなら対応するgem入れといてね。
RailsやRailsの利用者は詳細なんて(基本的には)意識しないよ、シンプルな記述で処理の流れを書くことに集中してね、
といっている感じがあるのと結構対照的でした。
ビューモデルというRailsのヘルパのような立ち位置のクラスがありますが、
基本的にRailsのMVCで馴染んでいるなら、ぱっとプロジェクトの全体像を把握する程度ならあまり変わらない印象で、正直助かります。
MVCの基本が同じというのもあるのですが、公式の、そしてそれが有志によって翻訳されているドキュメントの構成がとても丁寧で分かりやすい印象を受けました。
一対一対応ではじめるFuelPHPみたいで、既存のプロジェクトに参加するのであれば、順にドキュメントを読んでいけば、チュートリアルは要らないのではないかと思うくらい。
ruby界隈のRailsをはじめとしたイケイケなフレームワークには結構マニュアルやチュートリアルがマッチョイズムで、
Aという事柄を説明するけど、せっかくだから、どうせ後で要るしBもCもDも入れとくね!
というノリのドキュメントやチュートリアルが割と多い印象があります。
チュートリアルのチュートリアルを探すようなことが結構あったことを思うと、本当にありがたかったです。
並べときゃいいってもんじゃねえんだよ(ブーメラン)
もちろん、oilとかcomposerとかいわゆる初心者いじらなくていいよという部分はドキュメントがついていないので、
そこは自分で頑張る必要がありますが、今回はWebAPIを叩いたらどのテンプレートやJSONが返ってくるか把握したい程度なので、まあ。
この記事で紹介する部分のディレクトリの構成
FuelPHPのディレクトリの全体の構成はググってください。
この記事で紹介する部分のディレクトリの構成は以下のようになっています。
コントローラについて
コントローラクラスの基本
一番最初にコントローラを持ってきたのは、なるべくコードを読み込まずにプロジェクトの概要を把握するにはモデル名(モデルを通してDBを触るのでなければ、テーブル名)の一覧とWebAPIのアドレス一覧表を見るのが手っ取り早そうだからです。
そして、FuelPHPでは、WebAPIのルーティングはコントローラのクラス名と、メソッド名を通して行われます。
たとえば、
というクラスが、app/classes/controller/sample.phpに定義されていたとすると、
localhost:3000/sample/index.php
# localhost:3000の部分は起動設定によります。
ないし
localhost:3000/sample
というurlを打ち込むと、Controller_Sampleクラスのaction_index()メソッドがurlに対応するアクションのメソッドとして呼び出されます。
GETリクエストに応答するアクションをurlに即して定義していきたい場合は、action_xxx()メソッドを使用し、POSTやPUTなどRESTなHTTPメソッドを使用したい場合は、コントローラのクラスを作成する際にController_Restクラスを継承して以下のようにHTTPメソッド名からはじまる名前のメソッドを使います。
GET,POST,PUT,PATCH,DELETEに対応しています。
また、before()やafter()といったコールバックメソッドを設定することができ、その中の1つのrouter($method, $params)で上記のクラス名、メソッド名に依らないルーティングをさせることもできるっちゃできるらしいです。
名前空間等を使ってコントローラを階層化させたい場合のディレクトリ構造はRailsとほぼ同じでした。
ベースコントローラ
Railsではログイン確認処理等コントローラに共有させたいコールバックやメソッドがあった場合、ApplicationControllerを用意して、その名前空間であったり、プロジェクトのコントローラはみんなApplicationControllerのクラスを継承しましょう、という話になっていました。
fuel phpではそういったコントローラをベースコントローラと言います。
before_filterメソッドの変わりにbefore()メソッドの中に各アクションを呼びだす前に共通してやらせたい処理を書いていきます。
Railsでは同じディレクトリ・名前空間にApplicationControllerを用意することが多いですが、fuel phpではベースコントローラと、ベースコントローラを継承する他のコントローラのファイルの位置とクラス名は基本的に以下のように違う階層にするので注意します。
ビューを返すコントローラ
.htmlや.php拡張子で書かれたビュー(アクションごとのビューをコンテンツとよびます)を返すアクションを扱うコントローラはController_Templateクラスを継承する必要があります。
Controller_Templateクラスを継承すると、ページのタイトルを指定したり、ページのコンテンツを指定したりする、$this->templateプロパティなどが使用可能になります。
とりあえずこれだけ把握しておかないとどうにもなりません。
API用のコントローラ
API用のコントローラは、Controller_Restクラスを継承して書きます。
そうすることで、POSTやDELETEなどのHTTPメソッドを利用したアクションの定義が行えるというのは一度書きましたが、APIに対して結果のJSON(など。形式は自分で指定できる)の出力の形式を指定する場合は、このクラスを継承することで使える、$this->responseプロパティに書けばいいようです。
じゃあ、実際書いたらどうなるかというと、たとえば、
と書いたら、このアクションにリクエストを投げた場合、
というJSONが返ってきます。
routes.php
app/config/routes.phpでも以下のようにルーティングが行えます。
が、どちらかというと、基本的にはコントローラのクラス名+メソッド名を見てルーティングを行い、404やroot、aboutページなど特別なアドレスの場合だけを扱っている印象です。
ビューについて
FuelPHPのビューはapp/viewsディレクトリ以下にはいっています。classesにはいません。
テンプレート
Railsでいうプロジェクトのページ全体で使う構成を決めるビュー、application.html.erbなど、はFuelPHPではテンプレートと言うみたいです。
デフォルトではfuel/app/views/template.phpを使います。
下手に説明するより見たら分かる感じになっていたので、とりあえず載せておきます。
コントローラごとに使用するテンプレートを変更したい場合は、コントローラのクラス内で、
とそのコントローラで使用したいテンプレート名(拡張子のぞく)を宣言します。
コンテンツ
テンプレートのファイルで、
のところに挿入される、各アクションに対応するビューのファイルです。
Controller_Templateを継承したコントローラのアクションの中で、
のようにコンテンツを指定すると、
の部分にapp/views/sample/index.phpまたはapp/views/sample/index.htmlの内容が挿入されます。
テンプレートを使わない設定
全画面を使う特別なコンテンツを使いたいといった時に、テンプレートを使わないようにするには、以下のようにResponseオブジェクトを新しく生成したものを返せばいいらしいです。
モデルについて
モデルクラスの基本
もちろんモデルのコードも読む必要がありますが、実はモデルのメソッドは、DBと接続する部分自体は、
であったり、
であったりするので割とRailsとも似ていて助かります。
あえていえば、基本的にはモデルのクラスにはすべてModel_というprefixがついているので長ったらしく見えるかもしれないくらいです。
Model_のprefixは、そのモデルのクラスを使用するコントローラ内で、
のようにuse修飾子で宣言すると取ることが出来ます。
むしろ、取られていた場合に、use修飾子を探すような気もします。
Model_Clud
のようにDBヘ送るSQLの生成を簡易化してくれるメソッドを与えてくれるクラスです。
さらに洗練されたormというものもあるみたいです。
ただし、Model_Cludを継承したクラスでは接続先のデータベースやテーブル名、列の名前を設定する必要があります。
Model_Crud - クラス - FuelPHP ドキュメント
Orm
ormパッケージが使われている場合、$_many_manyプロパティや$_belong_toプロパティを利用することで、RailsのActiveRecordにおけるアソシエーション(has_many,belongs_to)のように、一体多、多対多対応をするモデルにおいて、対応を結びつけるキーや対応するモデルを記述することが出来ます。
ActiveRecordのアソシエーションとの違いは、片方のクラスに記述すればよいことです。
そういうわけで、書くのは楽なのですが、見返す時はそのクラスだけ見ても他のクラスとどう関連しているのか分からないことがあります。
まあ、それくらい全部読めよ、と言われればそりゃそうですが。
Introduction - Relations - Orm Package - FuelPHP Documentation
最終的にどの手順で見ていくと手っ取り早そうか
- app/classes/controller内のクラスのクラス名とメソッド名を確認
- app/classes/models内のクラス名と定数群を確認
- app/classes/controller内のベースコントローラのクラスを特にチェック
- app/views以下のディレクトリ構成を把握し、template.phpという名前のファイルは特によくチェック
- あとは必要に応じて地道にまとめる
さんざん書いておいて、これかい。
アプリケーションの構成はルーティング見れば分かると言ってたけど、
DB見た方がどんなアプリケーションか分かりやすい説もあり、モデルが先でもどっちでもいい気がしてきました。
さて、まとめたし、頑張りますか……。