symfony1.1でsfGuardPluginを使う。パート１

ならべて.comは、symfonyで開発された仕組みですが、1.0を使用しています。先日、ブログに貼り付けることができるウィジェットをリリースしており、もちろん開発は続けているのですが、現在その他に、別の仕組みを開発しており、そこでは、1.1を採用することにしました。symfony自体に関しては、もちろん根本にある使い方は変わっていないのですが、それなりに苦労しましたので、久しぶりにPHPネタでブログを書いてみます。

コードをできるだけ書かないことは、よりシンプルな開発となり、また、それがバグを減らすことなり重要ですよね。そこで、今回の開発では、アドミンジェネレータやプラグインを採用しようと決めました。プラグインでは、symfonyの開発者でもあるFabienさんのsfGuardPluginを使用しました。インストールできない人は、マニュアルを読んでください。

しかし、実際にsymfonyを使用して開発している方に話を聞いたのですが、実際のアプリとして作り込むには、sfGuardPluginは使いにくいので、アプリの作り方として勉強するならいいという話でした。今から書こうとする内容としては、いきなりこんなことを言うなんて凹んでしまいますが、そこは、よりコードを書かないようにゴリ押しで進めてみました。

さて、sfGuardPluginでは、ユーザの持つ情報をsf_guard_userテーブルに保存し、sfGuardUserというモデルで管理しています。このモデルのyamlスキーマは以下のようになっています。

sfGuardPluginに付いてくるsfGuardUserモジュールによって、sf_guard_userだけのCRUDは可能です。しかし、ユーザの属性には、もっといろいろな情報を持たせて、同時に登録したり、修正したいですよね？例えば、メールアドレスだったり、住所だったり、生年月日だったり、と。こういうときにあるのが、sf_guard_user_profileテーブルです。自分のスキーマファイルにsf_guard_user_profileを好きなカラムで指定することができます。そうすると、アクションクラスの中で$this->user->getProfile()と、持ってくることができます。つまり、テーブルが二つになって、1対1のリレーションで構成を作ってくれます。個人的にはこの1対1のリレーションが嫌いなのですが、プラグインの中を変更することは嫌ですので、このsf_guard_user_profileを使用しようと思います。しかし、やはり1対1のためか、アドミンジェネレータや、1.1から変更のあったフォーム周りを使用しようとすると結構大変でした。というわけで、ゴリ押しです。

さて、今開発しているものをそのまま持ってきてしまうと、説明がややこしくなったり、権利関係で問題になりそうですので、簡略化したモデルを使用しましょう。例えば、次のようなものです。

準備は整いました。というわけで、ようやく本題。今回のsfGuardPluginネタは、二つのポストに分けて書こうと思います。前半のこのポストでは、symfony1.1のsfGuardPluginを、アドミンジェネレータを使用する方法について書きます。後半の次のポスト（予定）では、同様の環境をアドミンジェネレータではなく、symfony1.1から採用された新しいフォームクラスを使用する方法について書きます。

symfonyのアドミンジェネレータは非常に優れていますね。私は初めて使用したときは、単なるCRUDをやってくれるだけなのかな、とバカにしていたのですが、設定ファイルであるgenerator.ymlを編集したり、パーシャルを使用したりすることによって、とても柔軟に仕組みを作ることができるようになっています。しかも、コードをあまり書くことなくに、です。いやぁ、素晴らすぃ。

さて、今回の仕組みの目的は、sf_guard_userでは、格納できる情報が少ないので、sf_guard_user_profileを使用して格納できる情報を増やして、かつ、アドミンジェネレータで一つのモジュールで管理することです。

アドミンジェネレータでは、一つのモデルに対して一つのモジュールを管理する際には、とても有効に使うことができるのですが、複数のモデルを一つのモジュールで編集するには、苦労します。というか、そもそも、複数のモデルを一つのページで編集をさせるという設計がイマイチな感じがしますが、このsf_guard_user_profileを使用する以上は、しょうがないです。ということで、ゴリ押しです。

さて、プロジェクトやアプリケーションを作ったりするのは、ここでは説明しません。それらで躓いている人は、マニュアルを読んでください。もしくは20万円くらいで私が教えます。backendというアプリケーションがすでにあるということで、話を進めていきます。

さきほどのsf_guard_user_profileがある状態で propel:build-allをすると、lib/model/以下にsfGuardUserProfile(Peer|).php等のモデルクラスのファイルができていると思います。それを確認して、アドミンジェネレータを使用してみましょう。確認ですが、実際にアドミンジェネレーターで使用するモデルは、sfGuardUserProfileで、sfGuardUserではありません。

とすると、userモジュールが生成されて、デフォルトのCRUDができるようになりますね。画面のキャプチャを取ろうと思いましたが、面倒なので、想像で補ってください。生成されたgenerator.ymlは、次のようになっていますね。

そして、このgenerator.ymlをどんどん編集していきましょう。編集の仕方は、この辺を参照してください。

さて、アドミンジェネレータで生成された編集画面ですが、Userやら、Nameやら、Birthdayやら、Created atやら、Updated atの項目がありますが、このままでは、使えないです。というわけで、次のことをするとしましょう。

1. ラベルを日本語化する
2. created_at, updated_at, user_idとかがいらないので消す
3. その代わり、sf_guard_userのusername, passowrd, is_activeを編集できるようする

ラベルを日本語化する

fieldsの項目が増えただけです。編集可能なフィールドは、nameとbirthdayだけにしましょう。というわけで、その二つだけラベルをセットしました。

created_at, updated_at, user_idとかいらないので消す

とりあえず、sfGuardUserProfileで編集可能なフィールドは、nameとbirthdayだけですので、シンプルですね。

sf_guard_userのusername, passowrd, is_activeを編集できるようする

ユーザの情報では、usernameとpasswordを編集したいですよね？ついでに、is_activeも編集できるようにしましょう。つまり、有効ユーザか否かという項目です。さらにusernameは、メールアドレスの格納場所としましょう。本当はメールアドレスはemailとかmail_address等のフィールドとしたいところですが、しょうがないので、usernameをメールアドレスとして扱います。

まず、generator.ymlを修正してみます。

fieldsのemail_address, password, is_activeにラベルを足しました。listの表示にemail_address, is_activeを足しました。editの編集表示にemail_address, is_activeを足しました。

さて、このままではエラーが出てしまいます。つまり、email_address, password, is_activeを持ってこれないのですね。私もここで少しはまってしまったのですが、アドミンジェネレータの生成するキャッシュファイルを見て、sfGuardUserProfileモデルのクラスに、usernameやpassword、is_activeのアクセサを作成すればいいことがわかりました。
中で、object_input_tagなどを使用しており、そこでゲッターメソッドを呼んでいましたので、実装します。

さらに、sfGuardUserProfileのインスタンスを保存する際に、ついでに、それに紐付けられたsfGuardUserのインスタンスも変更されたusername, password, is_activeを持って編集すればいいのだと理解しました。そして、それをsfGuardUserProfileモデルのクラスに実装します。

usernameは、メールアドレスとして使用するため、ちょっとだけかぶせてあります。

getPasswordが空文字列を返していますが、それはsfGuardPluginを使用するとデフォルトでは、復元できない形になってしまってしまうからです。管理者がパスワードが見れないという点ではいいのですが、どうするかは悩ましいところですね。平文で入れる方法もあるのですが、少々トリッキーなので、また別の機会に取り上げます。かもしれません。

はい。少々長いコードですね。最初の目的のコードを書かないようにするという目的からは少し反していますが、自分で組んだらもっと書かないといけないので、許してください。

これで、エラーがなく、編集が可能になりました。しかし、今度はメールアドレス、パスワード、有効ユーザの項目がdisabledになってしまっています。symfonyの中を見ると、sfCrudGenerator.class.phpで、CreoleTypesで見ているようです。そこで、disabledにされてしまっているので、簡単にはできなさそうでした。ということで、パーシャルの使用でゴリ押しします。userモジュールのactions, configなどのディレクトリのある階層にtemplatesディレクトリを作成して、_email_address.php, _password.php, _is_active.phpを作成します。
そして、それぞれのファイルに次のように書きます。
_email_address.php

_password.php

_is_active.php

そして、generator.ymlでのeditの項目を、今作成したパーシャルで置き換えます。最終的に generator.ymlは以下のようになります。

これで、とりあえず完了です。sfGuardUserProfileを保存すると、sfGuardUserもそのトランザクション中で保存されます。もう一ひねりしたいところは、パスワードの編集なのですが、これは、作成する仕組みが管理者がパスワードが見えるべきか否か、といった議論になってしまいますので、それぞれのアプリで応用してみてください。

また、sfGuardPluginの方に付いてくるモジュールでは、permissionやgroup roleに関しても登録できるようになっていますが、力尽きましたので、いつか書くかもしれません。ここで書いたように基本は、同じです。かぶせて保存です。

さて、全然関係ないですが、symfonyのコーディングスタンダードには、ちょっと好きになれません。生成されるソースコードがスペース2つだったり、if文やwhile文にも中括弧が次の行にあったりすると、嫌で嫌でしょうがないです。クラスやメソッドの始まりなら次の行から中括弧があっていいんですけどね。

しかし、パート２まで書けるかな。疲れてきた。次の方がややこいし。