GANCHIKU.com » symfony

Symfony2 クックブックの主観的なおさらい Symfony Advent Calender 2011 JP –14日目

shin — Wed, 14 Dec 2011 08:14:09 +0000

Symfony Advent Calendar の14日目です！昨日は、@bakorerさんのPHPFog + Symfony2 でステージング環境を作る方法：Symfony Advent Calender 2011 JP – 13日目でした。

先日、東京のVoyage Groupさんで発表したLTの内容を、より詰めてまとめたいと思います。
Symfony勉強のLTでも話をしましたが、10月末よりSymfony Cookbookの翻訳を進めて、現時点では全記事が翻訳されています。クックブックと言っても、実際に役に立つ記事、これはあまり使わないだろ、という記事があると思います。そんなことをまとめて、主観的に感想とオススメ度を書いていこうと思います。主観なのでツッコミどころはあると思いますが、まぁそこは教えてくださいな。実際は、全部ここで書ききれないので、24日までに間に合えば、後のAdvent Calendarでまた出てくるかもしれないです。

では。

git 上で、Symfony2 プロジェクトを作成し、管理する方法

Symfony2 Standard Edition(http://symfony.com/download)で、without vendorをダウンロードする。
.gitignoreファイルに追加する。
/web/bundles/
/app/bootstrap*
/app/cache/*
/app/logs/*
/vendor/
/app/config/parameters.yml
/app/config/parameters.yml.distを作っておけば、チェックアウトしてきて、コピーしてカスタマイズすれば、簡単にプロジェクトを始められる。
git init
git add .
git commit -m “Initial commit”
php bin/vendors install
Symfony2では、バックではgitを使ってライブラリを管理しているが、全てdepsとdeps.lockで特定のバージョンとidを管理しており、bin/vendorsでバージョンの整合性を見た方が良い。git submoduleでもできなくはないが、deps等を一纏めにしているため、bin/vendorsコマンドを使う方が良い。

感想：

最近の開発プロジェクトでは、Gitなどの採用は必須だと思われるので、プロジェクトの始め方として紹介してあるこの記事は非常に役に立つ。Symfony2では、depsとdeps.lockを使用して、いろいろなライブラリのバージョンの整合性を保っているのも特筆する点か。

オススメ度：☆☆☆

エラーページのカスタマイズ方法

エラーページをカスタマイズする方法は２つあり、この記事では異なるエラーページのテンプレートを編集してカスタマイズを行う。
app/Resources/TwigBundle/views/Exception/error.html.twigなどを作り、デフォルトのエラーページをオーバーライドする。デフォルトのエラーページのテンプレートは、vendor/symfony/src/SymfonyBundle/TwigBundle/views/Exception以下にあるので、これを参考にして作るのが良い。

エラーページのテンプレートが採用される順序

１．フォーマット(html, xml, jsonなど)とステータスコード(404, 501など)の両方がマッチするテンプレートを探して、あれば使用する。

２．フォーマット(html, xml,jsonなど)のみにマッチするテンプレートを探して、あれば使用する。

３．error.html.twigを使用する。

デバッグページもexception.html.twigなどをカスタマイズすることで変更することができる。

感想：

実際のアプリケーションでは、エラーページのカスタマイズは必須なので、知っていて良い内容だ。一度読めば、だいたいやり方はわかると思われる。基本的には、デフォルトのエラーページをコピーしてカスタマイズすることになりそう。

オススメ度：☆☆☆

ルートで常に HTTPS を強制させる方法

routing.ymlに requirementsで_schemeをhttpsと指定することでHTTPS通信を強制することが可能。

感想：

HTTPSを使用するサービスは作ったことがないので、今のところ私自身には役に立つことはないが、実際に使えば便利そうだ。なお、この記事は、ymlで指定してあるが、アノテーションで指定することもできる。その際には、以下のようにすれば良い。

* @Route("/demo/secured", requirements={"_scheme"="https"})

オススメ度：☆

ルートパラメターに “/” 文字を使えるようにする方法

ルートのrequirementsでパラメターの正規表現パターンを変更する。
デフォルトは、[^/]+ になっているので、例えば、”.+”とすれば、全ての文字を受け付けることができる。

感想：

たまにあるはまりどころであるが、そもそもルートパラメターに “/” を使わないといけない状況になることはあるのかな。逆に、数値だけとか、さらに厳しくする際にはこの正規表現を適宜変更すれば良いということがわかった。この辺はsymfony1と同じか。なお、この記事は、ymlで指定してあるが、アノテーションで指定することもできる。その際には、以下のようにすれば良い。

  * @Route("/hello/{name}", requirements={"name"=".+"})

オススメ度：☆

Assetの管理にどうやってAsseticを使うか?

アセット

Asseticを使用すれば、CSS、JavaScript、画像を最適化することができる。CSS, JavaScriptは元が複数のディレクトリに分散していても、１ファイルにまとめて出力することができる。

フィルター

フィルターを使用すれば、アセットファイルが出力する前にyuicompressorなどの実行結果を返すことができる。

AssetのURLを指定する

デフォルトは、Asseticが自動的にファイル名を決めるが、outputパラメターを使用して指定することも可能である。

出力のキャッシュ

プロダクション環境では、 php app/console assetic:dumpで予め静的にファイルを置いておくと良い。

感想：

Assetic素晴らしい！symfony1系では、@hidenorigotoから教えてもらったnpAssetsOptimizerPluginを使用していたが、それよりも柔軟な指定ができるのが良い。

オススメ度：☆☆☆☆☆

YUI Compressorを使ってJavascriptやStylesheetのサイズを圧縮するには?

・YUI Compressorのjarファイルをダウンロードして適当な場所に置いておく。あとはconfg.ymlで指定してフィルターとして出力する。

・フィルタ名の前に ? を付けると、デバッグ時にフィルターを無効にすることができる。

感想：

転送量を減らすために、JavaScriptとStylesheetの圧縮は、必要な機能であるが、実際にAssetic無しでやろうと思えば面倒なので非常に助かる。ただ、前の記事を呼んでおけば、この記事は必要ないのではないか、と思う。フィルタ名の前に ? を付けるというのは一応知っていてもいいかもしれない。

オススメ度：☆☆

Twigの関数で画像の最適化にAsseticをどうやって使うか?

jpegoptim をフィルターとして使用すれば、JPEGファイルを最適化することができる。

jpegoptimのオプションとして、EXIFデータを削除したり、最適化クオリティを下げることが可能。

また、twigを使用していれば、シンタックスシュガーとしてjpegoptimヘルパー関数を使用することもできる。

キャッシュの生成ディレクトリもoutputパラメターを使用して指定することができる。

感想：

jpegoptim素晴らしい。つか、知らんかった。これがあれば、アップロードされたファイルもオリジナルはウェブから見えないところに置いておいて、キャッシュをウェブから見えるところに出力すれば良いな。同様のサイズ変更などもあれば、クライアントやサムネイルも簡単にできそう。というか、普通に考えれそうな機能であるので、既にある？

オススメ度：☆☆☆

特定の拡張子に Assetic フィルターを適用するには？

Asseticフィルターには、CoffeeScriptのフィルターがあり、出力直前にJavaScriptにコンパイルすることができる。

さらに、複数のCoffeeScriptファイルを１つJavaScriptとしてコンパイルして、圧縮して出力することができる。

CoffeeScriptファイル、JavaScriptファイルが両方が混じっているときには、拡張子に基づいて、特定のフィルターを指定することができる。そうすれば、結果、1つのJavaScriptファイルとして出力される。

感想：

CoffeeScriptを書いたことはないが、JSと混同したときなどに便利そう。あったら便利だろうが、たぶん使うことはないかな。

オススメ度：☆

Doctrine でファイルアップロードを扱う方法

この記事では一般的なファイルアップロードの例を紹介している。まず最初のステップとして、仮想的なfileフィールドを使用し、バリデーション後に実行されるuploadメソッドで、ファイルを実際のファイル保存先へ移動し、保存先をpathとしてデータベースに保存している。

しかし、エンティティ保存時の問題とファイル移動の問題の対処をアトミックにするために、ライフサイクルコールバックを使用した例を次に挙げている。

(@ORM\HasLifecycleCallbacks)を使用して、PrePersist, PreUpdate, PostPersist, PostUpdate, PostRemove などでファイル移動等の処理を書いて、レコードの保存に合わせていること。

また、同様にファイル名もidにすることができる。

感想：

この記事は、実際のアプリケーションを作る際に参考になる。特にフックの使い方とファイルアップロードをする際のプラクティスとして読んでおくことをお勧めする。

オススメ度：☆☆☆☆

Doctrine エクステンション: Timestampable: Sluggable, Translatable, など

Doctrineエクステンションの話で実際はそれぞれのドキュメントを参照すること。

感想：

特になし。

オススメ度：☆

イベントリスナーとサブスクライバーを登録する

サービスとしてリスナーとサブスクライバーを別クラスに指定することができる。特定のイベントのフックをそのサービスに登録させる方法を説明している。

感想：

便利と言えば、便利だが多用すると複雑になってしまいそうである。記事にあるように保存時に検索インデックスを作成するといった用途以外に思いつかない。また、実際には、サブスクライバーの話はこの記事には書いていないのでは。。。

オススメ度：☆

Doctrine の DBAL レイヤーの使用方法

Doctrine DBALは、PDOの抽象レイヤーで、Doctrine ORMはDoctrine DBALのさらなる抽象レイヤーである。DBALを使うことでSQLをRDBMSに依存せずに使用することができる。

感想：

通常は、ORMを使用していればいいと思われるが、ORMにすることによってメモリが大量に消費されていたり、パフォーマンスの問題を解決する際にはDBALを直接叩いた方が速くなるので、知っていてもいい内容である。というか、アプリケーションによっては、あえてORMを使わないという選択もありかもしれない。

オススメ度：☆☆☆

既にあるデータベースからエンティティを生成する方法

・Doctrineにデータベースの内部を調べさせて、メタデータを作成することができる。次のコマンドでスキーマに書き出す。
php app/console doctrine:mapping:convert xml ./src/Acme/BlogBundle/Resources/config/doctrine/metadata/orm --from-database --force
・メタデータからエンティティクラスを作成することができる。次のコマンドでアノテーションマッピングをしたエンティティクラスを生成する
php app/console doctrine:mapping:import AcmeBlogBundle annotation
・次のコマンドでゲッターとセッターをエンティティクラスに追加する。
php app/console doctrine:generate:entities AcmeBlogBundle

感想：

最初にデータベースを作ってある場合には参考になる。データベースの設計で、ツールを使い生のSQLを吐く仕組み等に便利そう。
オススメ度:：☆☆☆

複数のエンティティマネージャと連携する方法

コンフィギュレーションで、doctrineのentity_managersを複数指定することができ、コントローラ等がそれぞれ呼び出すことができる。

感想：

実際はNoteにも書いてあるように、ほとんどのケースでは、複数のエンティティマネージャを使用することはないと思われる。もし使われるとすれば、既に動いているプロジェクトで使用しているデータベースを参照するときくらいか。

オススメ度:：☆

カスタム DQL 関数の登録方法

Doctrineの話でSymfony2からは直接は関係ないが、カスタムDQLをコンフィギュレーションで指定することができる。

感想：

特に無し

オススメ度:：☆

フォームのレンダリングのカスタマイズ方法

フォームレンダリングの基本

・各フィールドのラベル、エラー、ウィジェットを出力する際：
{{ form_label(form.age) }}
{{ form_errors(form.age) }}
{{ form_widget(form.age) }}
・各フィールドをまとめて出力する際：
{{ form_row(form.age) }}
・フォーム全体を出力する際：
{{ form_widget(form) }}

フォームテーマ

form_widgetなどのブロックはオーバーライドすることができる。FrameworkBundle/Resources/views/Formを参考にする。

フォームのテーマ化

・フォームと同じテンプレートの中でブロックをオーバーライドすることができる。
・もしくは、別テンプレートでブロックをオーバーライドし、同テンプレートファイルを form_themeタグを使用して適用させることができる(twigの場合)。

ベースフォームブロックを使用(twig)

・ useタグを使って、form_widgetを別名(例えば、base_form_widget)とすることで、元のform_widgetを装飾することができる。

アプリケーション全体でカスタマイズ

コンフィギュレーションでtwig:form:resourcesを変更して、アプリケーション全体のフォームのテーマを変更することができる。

感想：

この記事はフォームフィールドのデザインをスマートにする際に必須の記事である。クックブックというよりガイドブックに入っていてもおかしくない内容である。

オススメ度：☆☆☆☆☆

フォームイベントを使用してフォームを動的に生成する方法

新規のときと編集のときに出力するフォームフィールドが異なるときにこの記事の内容が役に立つ。新規のときと編集のときで出力したり、しなかったりするフィールドをフォームイベントで動的に見て、設定する。
・具体的には、フォームクラスで直接フィールドをaddするのではなく、addEventSubscriberでサブスクライバを指定させて、フォームフィールドを出力するかどうかを判断させている。

感想：

ここもちょっと難しいが、実際に必要となることが多いと思われる。例えば、新規ではパスワードやメールアドレスを入力させるが、編集では、パスワードのフィールドやメールアドレスのフィールドは、変更できないようにする、といったことがしばしばある。フォームを２つ作ればいいという話もあるが、同じフォームフィールドを扱う可能性がある以上、この記事を参考にした方が良いと思う。

オススメ度：☆☆☆

フォームのコレクションを埋め込む方法

ManyToManyのリレーションのあるテーブルを使用する際に、１つのフォームを表示で従属するテーブルのフォームを埋め込むことができる。実際に埋め込むには、フォームビルダーにaddする際に、指定するフィールドタイプにcollectionを使用する。

感想：

この記事はまだ完成はしていない。タグを新規に追加する方法や削除する方法がないので、今後の充実に期待。

オススメ度：☆☆

カスタムフォームフィールドタイプの作成方法

未執筆

感想：

執筆者求む！

新しい環境を作成して、使いこなす方法

dev環境、prod環境、test環境の他に異なる環境を作る方法をこの記事で説明している。この記事では、benchmark環境を実際に作成して説明している。

感想：

実際に新しく環境を作ることはあまり無いと思われるが、豆知識として知っておいてもいいと思う。symfony1では、ステージング環境を作成とかあったが、実際には個人的にあまり使わなかった。

オススメ度：☆

サービスコンテナで外部パラメターをセットする方法

・Symfony は、 SYMFONY__ の接頭辞が付いたあらゆる環境変数をサービスコンテナのパラメターとしてセットすることができる。Apacheで、SetEnvするなどしておけば、特定のデータベースのパラメターを接続設定ファイルで読むことができる。

感想：

ウェブからのみの場合は確かにApacheでの指定でいいが、Symfony2を使う上で、コンソールからの指定も必要である。もちろん環境変数を指定することができるが、複数の場所（Apacheの設定とシェル環境変数）に分散されてしまい、より良い解決方法があった方がいいと思う。

オススメ度：☆☆

バンドルの構造とベストプラクティス

この記事では、バンドルを作る上で必要な情報を学ぶことができる。

バンドル名の命名の規則

バンドルのディレクトリ構造

バンドルに追加するクラスやリソースの内容

感想：

この記事は、ガイドブックにあってもいい内容だ。命名規則、バンドルのディレクトリ構造や、必要なクラスやリソースをどのように配置するかを学ぶことができる。実際にアプリケーションを作ると言えば、バンドルを作るという作業になるので、この記事で書かれたことを参考にしてバンドルを作るのが良い。

オススメ度：☆☆☆☆

バンドルの継承を使って既存のバンドルのパーツを上書きする方法

オープンソースで公開されているバンドルなどは、そのまま使えるものもあるが、いくつか自分用にカスタマイズしたいときなどがある。そういった際には、継承を使ってコントローラやテンプレートなどのリソースファイルをオーバーライドできる。

準備として、バンドルにgetParent()メソッドで継承したバンドル名を指定する。

コントローラでは、parent:メソッド名で継承元のメソッドを実行できるし、かぶせることが可能。そのまま取り替えることも可能。

その他リソースは、バンドル内の同じ構造の場所にファイルを置けば、特に変更する必要なく、継承できる。

感想：

確かにバンドルは独立したものであるが、継承を使うことによって再利用が可能になり、その方法を学ぶことができるので、知っておいた方がいい内容である。

オススメ度：☆☆☆☆

バンドルのクラスや設定などの情報をオーバーライドする方法

未執筆。

感想：

執筆者待つ。

メールの送信方法

SwiftMailerライブラリを使用してメールを送信する方法を説明してある。

SwiftMailerを使用するには、コンフィギュレーションでtransport, username, password, host, port, encrypition, auth_mode, spool, delivery_address, disabled_delivery を指定することができる。

設定がうまく行っていれば、実際のメール送信は、実際に送る内容だけに注力することができる。

メールの本文は、renderView()メソッドを使用して作成することができる。

感想：

未だ現状のSwiftMailerはデフォルトのままでは、日本語のISO-2022-JPを正しく扱うことができない。私が修正してプルリクエストを投げた内容のものもあるが、修正してフォークして、日本語圏のみで共有した方がいいかも、と思っている。

オススメ度：☆☆

Gmail を使用してメールを送信する方法

特に開発環境などでは、SMTPを使用するよりもgmailを使用して行った方がメール送信が簡単になる。
コンフィギュレーションにtransportにgmailをしていして、username, passwordにそのGmailのユーザ名、パスワードを入力しておけば、このまま使うことができる。

感想：

メール送信のテストは意外に面倒なのであれば、Gmailを簡単に指定することができれば、開発も速く進むような気がする。しかもコンフィギュレーションに書くだけなので、非常に手軽。

オススメ度：☆☆☆☆

開発中におけるメール送信の扱い方

開発中は、実際の送信先のメールアドレスに送信することはしないため、次の２つの方法が用意されている。

１．メール送信を無効にする
２．特定のメールアドレスに送信する。
２の方法を使えば、実際にメールが送られるのかどうかをテストできるので、便利である。また、これもコンフィギュレーションに書くだけなので手軽。

メールの送信内容はウェブデバッグツールバーで見ることができ、config_dev.ymlでintercept_redirectsをtrueに指定すれば、リダイレクト前のメールを見ることができる。

感想：

これは、痒い所に手の届く記事。特に実際のコードに触れることなく、dev環境では、特定のメールアドレスに送ることができるようになった。また、symfony1でもウェブでバッグツールバーで送信内容を見ることができたが、その後にリダイレクトした際には、見ることができなかったが、これが改善された点も特筆すべき点か。

オススメ度：☆☆☆☆

メールをスプールする方法

スプールする方法もコンフィギュレーションに書くだけで、簡単に行うことができ、あとは、コンソールから次のコマンドを実行すれば良い。
php app/console swiftmailer:spool:send

感想：

スプールすることによって、メールの送信に負荷をかけなくても良くなった。実際は、メール送信に関しては、特に負荷はかかるような処理ではないと思うのだけど、携帯アドレスに送る際とかには、短時間に送りすぎると拒否されてしまうかもしれないので、オプションも見ておくと良さそうだ。

オススメ度：☆☆

ファンクショナルテストで HTTP 認証をシミュレートする方法

HTTP認証に必要なユーザ名とパスワードを、テスト全体として、または、各リクエストごとに指定することができる。

感想：

まだリリース前の段階や、内部のみに公開の場合にベーシック認証をかけておきテストをするのが便利そうだが、あまり用途はないかもしれない。

オススメ度：☆

複数のクライアントのインタラクションをテストする方法

件名のまま。チャットシステムのような複数クライアントがおり、即時で反映されるかどうかを見るときに使うことができる。

感想：

あまり用途は思い浮かばないが、知っておいてもいいかもしれない。

オススメ度：☆

ファンクショナルテストでプロファイラを使用する方法

一般的なファンクショナルでは、レスポンスのみをテストするのみで良いが、本番サーバのパフォーマンス等をテストする際に、プロファイラの値を調べることもできる。
プロファイラを使えば、クエリーの数、処理時間を調べることができ、チューニングに必要なものを洗い出すことが可能となる。

感想：

実際には、これは必要ないと思う。これはテストというよりもチューニングに関することなので。しかし、プロファイラの値をコンソールから見て調べることができれば、ボトルネックとなっている場所を探すことができるだろう。

オススメ度：☆

Doctrine のリポジトリクラスをテストする方法

Doctrineのリポジトリクラスをテストするには、エンティティ、エンティティマネージャ、データベース接続などを準備しておく必要がある。

Unitテスト

DoctrineTestsをオートーローダのネームスペースで指定する

Unitテストは、DoctrineTests内のOrmTestCaseを継承する

Unitテスト内のsetUpでAnnotationReaderをセットアップしてエンティティをパースしたり、エンティティマネージャを取得したりする。

QueryBuilderオブジェクトのクエリーの各パーツをテストする

ファンクショナルテスト

セットアップでデータベース接続を取得しておく。

コントローラでエンティティを取得するのと同じようにテストする

感想：

Unitテストは、セットアップが少々面倒くさい。もう少し楽にできるようになった方がいいと思う。個人的には、ここはUnitテストではなく、ファンクショナルテストのみでほとんどカバーできると思う。

オススメ度:：☆☆☆

PHP をテンプレートエンジンとして使う

コンフィギュレーションで、templatingのenginesにphpを追加することでPHPをテンプレートエンジンとして使うことができるようになる。

Twigのときと同じように親のテンプレートを継承することができる。

Twigのブロックと同じようにPHPでは、スロットとして親のテンプレートに子で指定したテンプレートを埋め込むことができる。

Twigのときと同じように、別テンプレートや別コントローラを取り込むことができる。

テンプレートヘルパもあり、テンプレートエンジンとして、基本的なことがほとんどできる。

感想：

Twigが強力なテンプレートエンジンなため、PHPを直接テンプレートエンジンに採用するメリットはあまりないと思うのだが、オプションとして知っていてもいい内容か。

オススメ度：☆

変数を全てのテンプレートへ注入する(グローバル値)

APIのキーなどをグローバルの設定値としてコンフィギュレーションとして書いておくことができる。

感想：

環境変数でSYMFONY__を指定すれば、外部パラメターをセットすることができるので、同様のことが可能だし、その方が実装が綺麗になると思う。

オススメ度：☆

ロギングで Monolog を使用する方法

Symfony2はデフォルトでMonologを使用している。

Monologのほとんどの設定は、コンフィギュレーションでハンドラを追加することでロギングが有効になる。

フォーマッタを変更することができる。

感想：

この記事の内容は全ては試していないが、基本的なログの取得はここに書いてある内容で可能。ログメッセージの装飾は今後調査をする。
オススメ度：☆☆

エラーメールを送る Monolog の設定方法

コンフィギュレーションで、指定すれば特定のアクションレベルでメールを送信することができる。500番台のエラーが起きたときなどに、管理者にメールを飛ばしてバグの調査をするときなどに役に立つ。
また、メールを飛ばし、かつ、ログに書きこむことも可能。

感想：

symfony1系でもエラーのイベントをリッスンしてメールを投げるといったことができたが、Symfony2ではコンフィギュレーションで、完結できるのが良い。

オススメ度：☆☆☆☆

カスタムデータコレクタの作成方法

Symfony2のプロファイラで得られるデータを集める方法もカスタマイズすることができる。

Symfony\\Component\\HttpKernel\\DataCollector\\DataCollectorInterface を実装する。

サービスにdata_collectorタグを付けて登録する。

ウェブプロファイラテンプレートを作成する。

感想：

普通の用途では、プロファイラを拡張することはほとんどないのでは。。。

オススメ度：☆

symfony1ユーザのためのSymfony2

symfony1とSymfony2は別物だが、symfony1の哲学は、Symfony2に受け継がれているものも多いため、symfony1をマスターしていれば、それほど学習コストは高くはない。

ディレクトリ構造

app/

Symfony2でのapp/ ディレクトリは、モジュールやライブラリファイルを置くところではなく、コンフィギュレーションや他のリソース（テンプレートや翻訳ファイル）を置くところになる。

src/

実際のコードを置く場所。Symfony2でのアプリケーションのコードは全てバンドルの中になり、バンドルがsrc/ 以下に置かれる。symfony1では、schema.yml、モデルファイル、フォームファイル等がプロジェクト内で共有されていたため、分散されていたが、Symfony2では、個々のバンドルとして独立されている。symfony1で、独自にplugins/ディレクトリに自分のアプリケーションを入れるなどしていれば、Symfony2のバンドルとよく似たものになる。

vendor/

symfony1のlib/vendorと概念は同じだが、入っているライブラリが異なる。

web/

フロントコントローラが置かれる。後にコンソールコマンド（php app/console assets:install web）を使って、個々のバンドル内のResources/publicディレクトリの複製orシンボリックリンクがweb/bundlesに作られる。

オートローディング

symfony1では、プロジェクト全体のPHPクラスファイルを１つの巨大な配列にキャッシュしていたので、変更があった際にキャッシュクリアが必要であったが、Symfony2では、UniversalClassLoaderを使用し、namespaceで管理しており、変更があってもキャッシュをクリアする必要がない。

コンソール

php symfonyコマンドから php app/consoleコマンドへ変更。

アプリケーション

symfony1では、frontend, backendのようにアプリケーションを分けていたが、Symfony2では別プロジェクトを作り、プロジェクト間でバンドルを共有することになる。

バンドルとプラグイン

symfony1では、config/ProjectConfiguration.class.phpでプラグインを有効にし、Symfony2では、app/AppKernel.phpでバンドルを有効にする。

ルーティングとコンフィギュレーション

symfony1では、プラグイン内のrouting.ymlとapp.ymlは自動的にロードされる。Symfony2では、routing.ymlもconfig.phpも、各バンドルの設定をインポートしてロードする。なお、symfony1のapp.ymlのような設定をするには、config.php にparametersキーで、指定すると良い。

感想：

実際は、Symfony2で遊びプロジェクトでも作ってみないといけないが、その後でこの記事を読めば、まぁ理解はできると思う。アプリケーションを分けない、というのはsymfony1系の人にとっては理解しにくいのかもしれない。あとバンドルの仕組みはプロジェクトと独立していて優れているとよくよく思う。

オススメ度：☆☆☆

まだレビューしきれていない記事は以下の通りです。サービス系は、セキュリティ系は鬼門だなぁ。

コントローラをサービスとして定義する方法
 データトランスフォーマの使用
 カスタムバリデーション制約の作成方法
 サービスを作成するファクトリの使用方法
 親サービスと共通の依存(dependency)をマネージする方法
 スコープの使用方法
 PdoSessionStorage を使用してデータベースにセッションを格納する方法
 セマンティックコンフィギュレーションを通してバンドルを設定する方法
 “Remember Me” ログイン機能の追加方法
 IPアドレスのブラックリストの独自 Voter の実装方法
 アクセス制御リスト(ACLs)
高度な ACL のコンセプト
 異なる URL で HTTPS や HTTP を強制化させる方法
 フォームログインをカスタマイズする方法
 アプリケーション内でサービスやメソッドをセキュアにする方法
 データベースからセキュリティユーザをロードする方法(エンティティプロバイダ)
カスタムユーザプロバイダの作成方法
 カスタム認証プロバイダの作成方法
 Varnish を使ってウェブサイトを高速化する方法
 クラスのオートローディングの方法
 ファイルの探し方
 コンソール/コマンドラインツールとしてのコマンドの作成方法
 デバッグするための開発環境に最適化する方
 Symfony2 コントローラで SOAP ウェブサービスを作成する方法
 継承無しでクラスを拡張する方法
 継承無しでメソッドの挙動をカスタマイズする方法
 新しいリクエストのフォーマットとマイムタイプの登録方法

今後は、これらのまだレビューしていないものを見ていくと共に、実際に手で動かしてちゃんと使えるか、翻訳された言葉がおかしくないか（実際、今回レビューしていた中でいくつかおかしい翻訳も発見している）、を見ていきます。

今回の「オススメ度」というのは、完全に主観です。ただ、☆が５つあるのは、確実に知っておいた方がいい内容です。４つもぜひ読んでおいてください。１つ２つは、暇だったりビンゴなネタであったらやってみてください。

実際のところ、私は翻訳をしながら、Symfony2自体の理解、Githubの使い方の理解を深めてきました。GitHubデビューをするのに、翻訳が一番簡単な方法じゃないかなぁ、と最近思っています。変にTOEICの勉強するくらいなら、Symfonyの翻訳をして英語も技術も身につけた方が、実際役に立ちます。いや、本当に。

明日のSymfony Advent Calendar 2011 -15日目は、@makotokagaさんです。

symfonyの中級者向けチュートリアルができましたね

shin — Wed, 02 Dec 2009 06:02:04 +0000

それと、symfony1.4系(LTS版)が出ましたね。今から新しいプロジェクトをする人は、1.4系で作ってください。そして、リリースに合わせて中級者向けチュートリアルが出ましたよ。

More with symfony

さてさて、今回のチュートリアルで関わった著者、翻訳者、査読者の皆さん、お疲れさまでした。Fabienも書いていることなのですが、この本ってすごいんですね。中身ももちろんですが、Fabienが9月に思い立った「中級者向けの本を書く」ということを、12月1日までに実現してしまうのですから。しかも、5つの言語での翻訳版も同時に。

翻訳版も同時ということは、翻訳する時間も用意しておかないといけないのですね。なんというアジャイルなコミュニティなんだろう、と思いましたよ。日本語翻訳チームも同様で、symfonyをバリバリ使っているユーザの方が参加して、一気に進めることができました。本当にphp conferenceで会った人たちと、その場で話を始めたんですね。そして、その後にakkyが企画したsymfony meetupで一気に翻訳チームが結成されたのですね。やっぱり勢いだよ。勢い。

また、Fabienの人柄にも注目ですね。Fabienが「中級者向けの本をコミュニティベースで書きたい」と言ったことに対して、それに貢献をしてくれる人たち。著者、翻訳者、査読者の人が喜んでこの一大プロジェクトを成し遂げました。symfonyを本当に好きじゃないとこれはできないです。やっぱり愛だよ。愛。

そして、今回のチュートリアルを書いているメンバーは、バリバリsymfonyを使っている人たちで、言ってみれば、symfony userのオールスターなんですね。統一性が欠けるというものと、それぞれの著者の面白みが読めるということは、ある程度トレードオフだと思うのですが、後者の利点が大きすぎます。それに、全部独立していますし。ということで、統一性は個々の章で、ということでお願いします。まだ私も全部読んだわけではないのですが、超おすすめです。特に自分がメインで訳したコンフィグハンドラーの章は、お気に入りです。

そして、私個人としては、こうやって多くの人が関わって作る書籍やプロジェクトのダイナミズムというものを感じました。新しい本の書き方として、おもしろいプラクティスですよね。まぁ、その半面、私みたいな初めて訳をする人の文章があるなど、荒削りな面もありますが、そこは、適宜直していくということで、堪忍してください。

さて、中身ですが、symfonyを使っていろいろカスタマイズをしたい人向けなんですね。なので、かなり突っ込んだ内容が書かれています。全くもって、初心者向きではないです。でも、実際にアプリを書こうと思ったら、初心者用のチュートリアルだけでは無理がありますよね。そのための本です。

チュートリアルの中身などの技術的な興味もあるのですが、個人的には、コミュニティベースで、さらにオープンソースだと、こういう成果を上げることができるという経営的な興味もそそられる活動でした。無償が必ずしもいいとは思いませんし、フリーにしないといけないということではありません。ただ、このような組織形態だからこそ可能となったアジャイル性は、もっと注目されてもいいと思います。

本当にお疲れさまでした。私の初めての翻訳参加になりました。私の力もコミュニティに還元ができてうれしく思います。

関連する日本語翻訳者の方が以下のように喜びを書いています。

admin generatorでrelationしているtableもfilterする

shin — Mon, 23 Nov 2009 08:40:19 +0000

はじめに

filterって名前が紛らわしいですね。Form Filterなのか、Filter Chainなのかで全然違いますし。今回は、Form Filterに関してです。

Form Filter使っていますか？私はまったく使っていませんでしたw 使うのは、admin generatorで使うときのみでした。generator.ymlを編集して、filterさせたいフィールドだけ選択させたりくらいだけで、なかなか内部まで見れていませんでした。今でも、内部まで見ていないです。。。

しかし、ちょっと拡張してみると便利だということに気づきました。というわけで、これでもっとfilterを使おうかな、という気分になりました。今回は、propelベースで話をします。遊びプロジェクトは、doctrineで書いていたりするのですが、まだ、本番用でdoctrineを使えていないです。なんというか、doctrineで書くと、メソッドチェーンで書くことができるので、行数とか少なくて済むのですね。調子に乗ってactionに全部書いてしまって、modelにどうやって書こうか、悩んでしまうのですね。

問題

さて、デフォルトのadmin generatorの一覧画面には、右端に検索ボックスが出てきますよね。admin generatorの際に指定したmodelに関する検索です。なかなか便利だなー、とは思っていました。しかし、modelと一対なので、JOINしたりさせようとするとちょっと面倒なんですよね。一つのテーブルだけを検索できてもあまり使えないと思うので、JOINさせてfilterさせたいじゃないですか。

方法

いろんな方法が考えられるのですが、一番簡単な方法だと私が思っているのは、FormfFilterを拡張して、リレーションしたいテーブルのmodelに対応するFilterFormをmergeFormします。マジでmergeです。そして、そのFormFilterクラスのbuildCriteriaメソッドも拡張して、mergeしてあげたFilterFormでfilterしたいフィールドを追加してあげます。

準備1

つーか、簡単すぎてソースコードいらないね。。。それ用にアプリ書くの面倒ですし、プロダクトのコードそのまま持ってきたくないですし。。。と言いつつ、ここでテストアプリを作りながら、書いていくことにします。今回のは、symfony.1.2系で、propelです。すいません。
まず、schema.ymlを追加してみましょう。

propel:
  item:
    id:
    category_id:
    name:
      type: varchar(32)
      required: true
    description:
      type: longvarchar
      required: true
    created_at:
    updated_at:

  category:
    id:
    name:
      type: varchar(32)
      required: true
　　is_special:
      type: boolean

data/fixtures/fixture.yml

Category:

  category_:
    name: category_name_
    is_special: 


Item:

  item_:
    name: item_name_
    description: "test description"
    category_id: category_

そして、build-all-loadして、model, form, filterも作って、データベースにも突っ込んでおきましょう。ついでに、テストデータも入れておきましょう。なお、最初にdatabases.ymlなどを編集して、データベースは接続できるようにしておいてください。

$ ./symforny propel:build-all

そして、applicationを作ります。

$ ./symfony generate:app backend

で、moduleは、admin generatorで作ってしまいます。

$ ./symfony propel:generate-admin backend Item

生成されたモジュールを見ようとすると、「toStringを実装しろ」と怒られるので、実装してnameでも返してあげます。

class Category extends BaseCategory
{
  public function __toString()
  {
    return $this->name;
  }
}

さて、これで準備ができました。上の画像のようになりますね。fixtureでテストデータの作り方とかが、もしかしたら参考になる人がいるかもしれないですね。つまり、forしたり、randしている内容はチェックしてみてください。改行コードを入れないといけないのが、ちょっと嫌ですが。

準備2

と言いつつ、まだ準備です。次に、一覧として表示したいものを選びます。created_atとか表示しなくてもいいじゃないですか。それに、descriptionが長いときもあるので、表示させないように削ってしまいましょう。代わりにcategoryの情報が欲しいですね。is_specialというフィールドがcategoryにありますが、これを表示したいと思いますので、listに追加してあげましょう。

まず、そのためには、モデルのItemクラスに、getHogehogeを追加してあげましょう。今回は、getCategoryNameとgetCategoryIsSpecialメソッドを追加して、admin moduleからそのまま持ってくるようにしました。

class Item extends BaseItem
{
  public function getCategoryName()
  {
    if (!is_null($this->getCategory())) {
      return $this->getCategory()->getName();
    }
    return null;
  }
  public function getCategoryIsSpecial()
  {
    if (!is_null($this->getCategory())) {
      return $this->getCategory()->getIsSpecial();
    }
    return null;
  }
}

あとは、itemモジュールのgenerator.ymlを修正しましょう。

generator:
  class: sfPropelGenerator
  param:
    model_class:           Item
    theme:                 admin
    non_verbose_templates: true
    with_show:             false
    singular:              ~
    plural:                ~
    route_prefix:          item
    with_propel_route:     1

    config:
      actions: ~
      fields:  ~
      list:
        peer_method: doSelectJoinCategory
        display: [ name, category_name, category_is_special, updated_at ]
      filter:  ~
      form:    ~
      edit:    ~
      new:     ~

これでとりあえず表示したいフィールドはできました。さらに、peer_methodを変更しないとクエリーを実行しすぎなので、joinするものに変えてあげました。
ようやく準備ができたかな。labelも変えてあげたいところですが、面倒なのでry

ソースコード

さて、ようやく今回のネタです。
lib/filter/ItemFormFilter.class.php

class ItemFormFilter extends BaseItemFormFilter
{
  public function configure()
  {
    $this->mergeForm(new CategoryFormFilter());
  }

  public function buildCriteria(array $values)
  {
    $criteria = parent::buildCriteria($values);
    $criteria->addJoin(ItemPeer::CATEGORY_ID, CategoryPeer::ID);
    if (isset($values['is_special'])) {
      $criteria->add(CategoryPeer::IS_SPECIAL, $values['is_special']);
    }
    return $criteria;
  }
}

そして、apps/backend/modules/item/config/generator.yml

generator:
  class: sfPropelGenerator
  param:
    model_class:           Item
    theme:                 admin
    non_verbose_templates: true
    with_show:             false
    singular:              ~
    plural:                ~
    route_prefix:          item
    with_propel_route:     1

    config:
      actions: ~
      fields:  ~
      list:
        peer_method: doSelectJoinCategory
        display: [ name, category_name, category_is_special, updated_at ]
      filter:
        display: [ name, category_id, is_special ]
      form:    ~
      edit:    ~
      new:     ~

なんてこったい。今回の本ネタが一番短いな。。。まぁ、いいや。

結果上のような見た目になりましたね。実際、SQL文を見ると以下のようになっていると思います。

SELECT item.ID, item.CATEGORY_ID, item.NAME, item.DESCRIPTION, item.CREATED_AT, item.UPDATED_AT, category.ID, category.NAME, category.IS_SPECIAL FROM `item` LEFT JOIN category ON (item.CATEGORY_ID=category.ID) WHERE category.IS_SPECIAL=1 AND item.CATEGORY_ID=category.ID LIMIT 20

これで、完成です。

解説

FormFilterを拡張して、追加したいフィールドを持っているFormFilterをmergeしてあげます。これで、admin generatorを指定してあげると、filterの場所には、全フィールドが出てきますね？

そこで、filterを拡張したいモジュールのgenerator.ymlのfiltersを修正します。ここで、relationしているtableでfilterしたフィールドも追加してしまいます。もちろん対応するフィールドがFormFilterにないとエラーが出ます。前にmergeをしていましたので、実際はフィールドがFormFIlterにあることになります。

これでできたらうれしいのですが、実際は、もう少しだけ修正する必要があります。つまり、検索条件を加えるといったことです。そこで、またFormFilterに戻って、buildCriteriaをオーバーライドして、Criteriaに指定したいテーブルをJOINして、ついでに、条件を加えてあげましょう。

まとめ

admin generatorでmodelをまたいでfilterを追加する方法を説明しました。

方法としては、admin generatorで使用するFilterFormを拡張して、relationしているtableもfilterの項目に追加するようにしました。実際は、FilterFormを拡張して、追加したいFilterFormをmergeし、Criteriaを作成する際に、mergeしたFilterFormの値も追加して作成するために、buildCriteriaメソッドをオーバーライドしてみました。admin generatorが自動生成するactionなどははいじっていません。

さて、今回の実装は、具体的な実装の話でした。つまり、アプリレベルの開発の話です。どこまで抽象化するというのは、いつも悩みの種で、抽象化しすぎると複雑になるし、実際いらないということもよくあります。YAGNIです。YAGNI。抽象的にやろうと思えば、もっと複雑になるし、その辺は、DbFilterプラグインとかがよろしくやってくれそうなことを前に読んだ気もするけど、どうなんでしょうね。時間があれば使ってみます。

まぁ、今回のような話は、それぞれのアプリの仕様によることが多いので、具体的に実装してしまいましょう。

今後のちょっとした発展系としては、ヘッダの行をクリックするとソートできるようにしたらいいですね。同じような要領なので、がんばればできるでしょう。こちらは、actionを上書きしないといけないのかもしれません。

うーん。一番時間がかかってしまうのが、準備段階というのも考えものですね。。。

conditionalBasicSecurityFilterってのもアリかな

shin — Fri, 30 Oct 2009 18:34:32 +0000

はじめに

conditionalシリーズをもう少し考えてみました。今回はキャッシュではなくて、securityFilterです。

symfonyでは、settings.ymlを用いて、ユーザがログインしていないときに呼び出すアクションを指定することができます。その際に使用するのが、login_moduleとlogin_actionです。

また、ログインはしているが、権限がない(Credentialがない)ときに呼び出すアクションも指定することができます。その際に使用するのが、secure_module, secure_actionです。この二つとsecurity.ymlを使うことによって、is_secureなアクションにログインしていないユーザがアクセスした際に指定したログイン画面を出すことが可能となります。

今回は、この２つを拡張してみることにします。つまり、ユーザがログインしていないときに呼び出すアクションをもう少し条件を付けて、特定のページには違うlogin_actionを渡すようなことです。

問題

確かにsymfonyではlogin_module、login_actionで指定することができるのいいのですが、もっと細かに指定したいときってどうしたらいいんだろうという話を、先日耳にしました。今まで私はそんな需要がなかったので、考えたことはなかったのですが、「私だったらこうやるかな」という方法をいきなり午前1時より作り始めてしまいましたので、その勢いでブログにも書いていますw
secureの方の動作は確認していないのでアレなのですが、loginの方は確認しましたので、これで対応することができたと思います。実装環境は相変わらずsymfony1.3-ALPHA2なのですが、たぶんsymfony1.2系でも動くと思います。

方法

login_module, login_actionなどの指定が実際どこで呼ばれているかを調査しますと、sfBasicSecurityFilter.class.phpの中で使われています。このsfBasicSecurityFilterは、filters.ymlに書かれているsecurityのデフォルトとして使われるfilterです。このsfBasicSecurityFilterを読んでみると、login_module, login_actionは固定値としてsfConfig::get(‘sf_login_module’)のように使われていますので、簡単には変更することができないようになっています。というわけでこれではダメなので、考えてみました。

さて、symfonyのプラグインの中で一番ダウンロードが多いのがsfGuardPluginなのですが、そこでfilterのsecurityFilterを書き換えますよね？securityFilterは変更可能なのですね。というわけで、同様に、今回指定したconditionalBasicSecurityFilterというものをsecurityFilterとして使用できるように指定します。そして、一緒に渡すパラメータもfilters.ymlで指定してみます。yamlで指定する値が増えすぎてわからなくなってしまうかもしれないのですが、conditionalCacheFilterと同じようにpageごとに指定ができるようにしてみました。

ソースコード

/apps/frontend/config/filters.yml

rendering: ~
#security:  ~
security:
  class: conditionalBasicSecurityFilter
  param:
    pages:
      - { module: post, action: new, login: { module: user, action: loginNew } secure: { module: default, action: error403 } }
      - { module: post, action: edit, login: { module: user, action: loginEdit } secure: { module: default, action: error403 } }

# insert your own filters here

cache:     ~
execution: ~
~

/apps/frontend/lib/conditionalBasicSecurityFilter.class.php

class conditionalBasicSecurityFilter extends sfBasicSecurityFilter
{

  public function execute($filterChain)
  {
    if (!$pages = ($this->getParameter('pages', false))) {
      parent::execute($filterChain);
      return;
    }

    foreach ($pages as $page) {
      $module = isset($page['module']) ? $page['module'] : null;

      $action = isset($page['action']) ? $page['action'] : $this->context->getActionName();

      $login = isset($page['login']) ? $page['login'] : null;

      $secure = isset($page['secure']) ? $page['secure'] : null;

      // skip
      if ($module !== $this->context->getModuleName()) {
        continue;
      }

      // skip
      if ($action != $this->context->getActionName()) {
        continue;
      }

      if (isset($login) and !$this->context->getUser()->isAuthenticated()) {
        $loginModule = isset($login['module']) ? $login['module'] : null;
        $loginAction = isset($login['action']) ? $login['action'] : null;
        if (isset($loginModule) and isset($loginAction)) {
          $this->forwardToAction($loginModule, $loginAction);
        }
      }

      $credential = $this->getUserCredential();
      if (isset($secure) and !is_null($credential) and !$this->context->getUser()->hasCredential($credential)) {
        $secureModule = isset($secure['module']) ? $secure['module'] : null;
        $secureAction = isset($secure['action']) ? $secure['action'] : null;
        if (isset($secureModule) and isset($secureAction)) {
          $this->forwardToAction($secureModule, $secureAction);
        }
      }
    }

    parent::execute($filterChain);
  }

  protected function forwardToAction($module, $action)
  {
    $this->context->getController()->forward($module, $action);

    throw new sfStopException();
  }
}

解説

filters.ymlでsecurityFilterで使用するクラスとしてconditionalBasicSecurityFilterを指定します。そして、その中で受け取るパラメータを同時に指定させます。今回はいいサンプルのアイデアがなかったのですが、postモジュールで、アクションがnewするときとeditするときに違うloginフォームを出したい、という要望があったとして考えてみました。つまり、newの時はuserモジュールのloginNewアクションを呼びたいとします。そして、editの時はuserモジュールのloginEditアクションを呼びたいとします。secureは、とりあえずこんな感じで指定できるかな、という感じで書いてみましたので、今回は説明しません。

conditionalBasicSecurityFilter.class.phpに関しては、前回書きましたconditionalCacheFilterと同じロジックでpagesの分だけループで回し、それがloginが必要なものであったり、credentialのチェックが必要なものであった際には、forwardをするというようにしました。これで、newのときには、loginNewにforwardされ、editのときにはloginEditにforwardされるようになります。

まとめ

今回は、そのsfBasicSecurityFilterを拡張してconditionalBasicSecurityFilterを作ってみました。そこでは、モジュールやアクションによって、login_module, login_action,security_module, security_actionを分けて指定ができるようにしました。
今回は、午前1時になっていきなり、思い立ったように書いてみましたので、適当なことを言っているかもしれないのですが、せっかくなので、ソースコードまで落として、さらにブログにも書いてみました。ログインの際のロジックを拡張したい際にはsfBasicSecurityFilterを拡張して対応するというのは、結構使えるのではないかな、と思います。
しかし、ここまで書いた後に、よく考えてみるとこれはアプリケーションを別にして作ればある程度は回避できる問題なんだろうなぁ、と少し思っています。それでも、上に書いたように分けたい場合はこんな感じで対応してみてはどうでしょうか？

そろそろ寝ないと。。。勢いで書いたので、間違っているところもあると思います。それは後ほど修正します。

conditionalCacheFilterをさらに考える

shin — Tue, 27 Oct 2009 04:46:01 +0000

はじめに

前回、conditionalCacheを説明した後に、さらにそれを使った事例を考えていたのですが、考えていたところ直したいところがいくつか出てきたので、さらにconditionalCacheを考えてみました。一つは、enabledオプションによって、キャッシュをクリアすることは必要ないと考えたことです。本来の動作としては、enabledがfalseであれば、キャッシュを使わずに、そのまま表示するという方法を取るのが一番でしょうね。これはviewCacheManagerのisCacheableメソッドを直せば可能となると思います。とりあえずその方法は後に説明するということで、今回はenabledオプションを消しました。
そして、今回は、セッション関係を持つuserクラスを使って、キャッシュをするか、どうかを追加してみることにしましたので、それを説明しようと思います。

問題

ユーザ認証しているかどうかだけではなくて、ユーザ認証して、かつ自分のコントロールできるページか否かというオプションがあったらウレシイですよね。つまり、そのユーザの投稿やプロフィールページであれば、「編集する」や「削除する」というアクションが表示されるのが普通でしょう。ユーザ認証をしていても、他のユーザの内容であれば、編集や削除ができたら困りますよね。ここでもconditionalCacheの出番が必要ではないか、と考えました。

方法

セッションを操るuserを使いましょう。filters.ymlで条件としてuser_conditionを追加してみます。そこで、user_conditionに、キャッシュ可能かどうかを条件判断させるメソッドを文字列で渡してみます。

ソースコード

/apps/frontend/config/filters.yml

rendering: ~
security:  ~

# insert your own filters here
conditionalCacheFilter:
  class: conditionalCacheFilter
  param:
    pages:
      - { module: post, action: index, format: [xml] }
#      - { module: post, action: index, format: [html], user_condition: usesCache }
      - { module: post, action: index, format: [html], user_condition: isNotAuthenticated, with_layout: true }

cache:     ~
execution: ~

/apps/frontend/lib/conditonalCacheFilter.class.php

class conditionalCacheFilter extends sfFilter
{
  protected
    $cacheManager    = null,
    $request         = null,
    $user            = null,
    $uri             = null,
    $defaultLifetime = null;

  public function initialize($context, $parameters = array())
  {
    parent::initialize($context, $parameters);

    $this->cacheManager    = $context->getViewCacheManager();
    $this->request         = $context->getRequest();
    $this->user            = $context->getUser();
    $this->uri             = $context->getRouting()->getCurrentInternalUri();

    $lifetime = (isset($this->cacheManager)) ? $this->cacheManager->getLifeTime($this->uri) : 0;
    $this->defaultLifetime = ($lifetime > 0) ? $lifetime : 86400;
  }

  public function execute($filterChain)
  {
    if ((!isset($this->cacheManager)) or !($this->getParameter('pages', false))) {
      $filterChain->execute();
      return;
    }

    foreach ($this->getParameter('pages') as $page) {

      $module = isset($page['module']) ? $page['module'] : null;

      $action = isset($page['action']) ? $page['action'] : $this->request->getParameter('action');

      $format = isset($page['format']) ? $page['format'] : array();
      if (!is_array($format)) {
        $format = array($format);
      }

      $user_condition = isset($page['user_condition']) ? $page['user_condition'] : null;

      // maybe better to throw exception?
      if (is_null($module)) {
        continue;
      }
      // skip
      if ($module !== $this->request->getParameter('module')) {
        continue;
      }
      // skip
      if (!empty($format) and !in_array($this->request->getParameter('sf_format', 'html'), $format)) {
        continue;
      }

      // skip
      if (isset($user_condition)) {
        $func = array($this->user, $user_condition);
        if (!(is_callable($func) and call_user_func($func, $this->request))) {
          continue;
        }
      }

      $options['lifeTime'] = isset($page['lifetime']) ? $page['lifetime'] : $this->defaultLifetime;
      // if the page is not cached already, you can set with_layout option
      // xxx symfony page cache cannot have with_layout and without_layout cache same time
      if (!$this->cacheManager->isCacheable($this->uri)) {
        $options['withLayout'] = isset($page['with_layout']) ? $page['with_layout'] : false;
      }

      //add
      $this->cacheManager->addCache($module, $action, $options);
    }

    // chain
    $filterChain->execute();
  }
}

/apps/frontend/lib/myUser.class.php

class myUser extends sfBasicSecurityUser
{
// snip some methods for user signin or signout methods.
//
  public function getUsername()
  {
    if ($this->isAuthenticated()) {
      return $this->getAttribute('username', '', 'test');
    }
    return null;
  }

  public function usesCache($request)
  {
    $username = $request->getParameter('username', false);
    return $this->getUsername() !== $username;
  }

  public function isNotAuthenticated()
  {
    return !$this->isAuthenticated();
  }
}

解説

今回は、userクラスで条件判断をつけるuser_conditionのキーをfilters.ymlで選択させるようにしてさらに柔軟にしていました。つまり、user_conditionに与えるメソッドによって、キャッシュするかどうかを変更することができます。ここでは、isNotAuthenticatedによって、認証されていないユーザにはキャッシュをするというように与えています。前回のis_authenticatedオプションではなく、直接userクラスに判断させるようにしてあります。user_conditionが指定していなければ、認証していようが、いまいが、キャッシュが有効になります。そして、認証している際にさらに条件を加えたい場合は、user_conditionでもう少し詳しい内容を実装したメソッドを指定してみましょう。

例えば、user_conditionにusesCacheを指定すれば、リクエストパラメターにusernameがあった際に、セッションに入っているusername（ログインした際に持っておく）と比較をし、同じものであれば（そのユーザに関するページ）、キャッシュをしない、ということも可能となります。

さて、with_layoutオプションですが、これは実は少し厄介なのです。現在のsymfonyでは、同じページのキャッシュを複数持つことができないのですね。つまり、with_layoutとwithout_layoutのキャッシュが同時に持てずに、切り分けることができないのです。実際は、キャッシュといっても、シリアライズされた内容をキャッシュディレクトリに格納しているのですが、with_layoutの方は、オブジェクトなのに対し、without_layoutの方はarrayでシリアライズされているので、ここで問題が起きてしまいます。これは、すでにcache.ymlでキャッシュを指定していた際のwith_layoutの値と違う値を指定するとエラーが起きてしまうので、このようにすでになければ指定可能だが、すでにあれば、with_layoutオプションは使えない、というようにしました。

まとめ

前回の内容からさらにconditionalCacheを考えて、userクラスのメソッドにそれを判断させるキーをfilters.ymlに追加しました。このことにより、認証済みでも、さらに自分に関するページに関してはキャッシュをしない、等の処理が可能となりました。つまり、認証していても他のユーザのページであれば、キャッシュを使えるということになります。

課題

キャッシュに関しては、まだ考えているところがあります。cache.ymlにて、enabledをtrueにしているが、conditionalCacheFilterに渡すenabledをfalseにした際に、キャッシュをクリアするのではなく、そのまま置いておいて、そのページはキャッシュを使わずに表示させたいと思います。また、パーシャルキャッシュについても考えた方が良いでしょう。前回と今回に関しましては、ページキャッシュを扱いましたが、パーシャルキャッシュもログイン状態によって切り分けたいときがあると思います。それに関しても考えていきたいと思います。

ちなみに、ここで私が載せている内容は、正しい唯一の方法ではなく、「現在の私だったら、こうやって実装するかな。」という内容です。なので、時間が経つに連れて、より良い方法が見つかった際には、そちらに移行すると思います。その際には、また、ブログに書くでしょう。