http://symfony-reloaded.org/
道理で1.2のサポートを打ち切るのが早かったわけだ。
1.4も安定してないのに、どうすんだろうと思うけど。
機能
http://symfony-reloaded.org/quick-tour-part-1
このページを読んだだけのまとめと感想。
- たぶんsymfony 1系統とは互換性がまったくない。
- Fabienは「標準的なプラクティスに従っていれば移植は出来る」と言っていたが、だいぶ微妙。
- PHP 5.3以降専用になった。
- ディレクトリ階層がまた増えた。 アプリケーション/バンドル/コントローラ/アクション
- それでもWebディレクトリは共通で1つしか無いのはおんなじ。
- 親ルーティングが増えた。バンドルを振り分けるのに使う。
- アクションは廃止されると言っていたが普通に残っていてsymfony 1に一番良く似ている。
- sfActionsだったものがControllerに変わっている。単数形のActionクラスが作れるかは不明。
- メソッドのサフィックスがExecuteからActionに変更されている。
- テンプレートフレームワークが刷新された。
- それと、やはりindexSuccess.phpはindex.phpに変更になっていた。
- テンプレートの中で明示的に変数の展開を命令しないと変数が使えない。
サブフレームワーク
sandboxを開けてみたが、index.htmlにあたるファイルのパスは、
sandbox_2_0_PR1/sandbox/src/Application/HelloBundle/Resources/views/Hello/index.php
になる。怒りと呆れを通り越してもはやネタである。まさにエンタープライズフレームワークって感じだ（謎
データベースまわりの事が書いてなかったので、Doctrineの良さなどはまだわからない。
一応 vendor/doctrine はあるので、モノ自体は出来てるみたいだ。
そして、propelは見あたらない。
Fabienは去年のPHPカンファで「どちらも特徴があるものだから併用していく」と言っていたはずだが。
そのとき、Propelの特徴は、強力なscaffoldにあったと言っていた気がする。記憶違いだったら申し訳ない。
ほかには、1.3から登場のswiftmailerと、Zend/CacheとZend/Logもバンドルされていた。
トップページにある通り、コンセプトとしても他フレームワークを取り入れて行く気らしい。
出来が微妙なsfFormは、そのうち似たような概念を持つZend/Formに変わってしまうのかも知れない。
vendor/symfonyに至っては、なんでもかんでもディレクトリ名の先頭文字が大文字になってるのが笑える。
ともあれ、「俺俺フレームワークに他フレームワークを合体させる事例の一つ」としては、Symfony 2.0は注目と言える。
ターゲット
このフレームワークを使うべき現場は、Javaで開発していたようなチームだと思う。
Ruby on railsを真似して小規模のアプリを書くためのツールがCakeだとしたら、
Symfony 2.0(やsymfony 1.4)はJava Strutsのパイを奪う大規模のアプリを書くための野暮ったい仕組みであるのが立ち位置ではなかろうか。
しかし、Symfonyにはtaglibが無いのでデザイナとの連携は出来ないし、相変わらず「ロジックを書く場所」の規定が弱いのでMVCを標準化できていない。「これからに期待」と言いたいところだが、開発陣に問題意識は無いと思う。
Struts2がJavaの人達にあまりうけていないのと同様、Symfony 2.0が市場に受け入れられるかは甚だ疑問だ。
PHP開発者が仕事を得るために経験しておくという意味では、Symfony 2.0も経験したほうが良いし、
業界標準となりうるエンタープライズ系のフレームワークを常に模索しておいた方が良い。
少なくともCakeはビジネス規模じゃ破綻する（事例が多い）し、Zendは部品としての用途が強い。
ビジネスじゃなければ、このフレームワークを使って開発する必要は無いと思う。
とはいえ、開発はしなくとも、開発されたアプリを導入する事で開発者以外が関与する可能性は十分にある。
その際に、レンタルサーバがPHP 5.3に対応していないのはシェアに差し障る大問題だ。
一番悩ましいのはSymfony製アプリを作ろうとしていたベンダーでは無かろうか。
手嶋屋さんとか。OpenPNEどうするんだろう。
いま一番熱心にSymfony 2.0を触ってる日本人開発者って誰なのかな。日本のコミュニティ無いのかな。
symfony-users.jpがわけわからん企業に取られている。by masaki at 2008-12-14(Sun) 23:05:35
http://wassr.jp/user/masakielastic/statuses/JCX82TirM4
ドメイン的に露出度が高いのはsymfony.jpなんだから、ディノがやれよ、と誰かが言っていた気がする。
あそこは昔から意欲的な会社だったから、symfonyに骨を埋めるつもりは無いよ、という事なのかなあ。
Fabienと飲みに行ったときのメンバーで語ってた内容は一体何だったんだろう、と今となっては思う。
まあ、自分も手嶋屋さんと同じ理由でまったく行動してないので、他人様にどうこう言えた筋合いでは無いのだが。
「妥協してsfFormを使うためにWebデザイナーに理解を求める」の記事内で、
sfWidgetFormSchemaFormatterのカスタマイズの必要性について述べたが、
残念ながら手元の環境だと、紹介したブログに記載されている方法ではうまくいかない。
うまくいかない理由は、どこかでwidgetSchemaの新しいインスタンスが作成されているからだと思う。
自分のFormクラスのsetup()でaddFormFormatter()した結果が無視されてしまう。
そこで別の方法を用いて妥協する事にした。
- sfWidgetFormSchemaFormatter からはじまる名前の sfWidgetFormSchemaFormatterHoge クラスを作成する（sfWidgetFormSchemaFormatterTableクラスのコピーで構わない）
- $helpFormat を '<br /><span class="form_help">%help%</span>', に直す（やりたかった事はこれだけ）
- Formクラスのsetup()に $this->widgetSchema->setDefaultFormFormatterName('hoge'); を書いてやる。
setFormFormatterName()ではダメ。新しいインスタンスで認識されないから。
同じ理由で、このカスタマイズ方法だと、一度に2つのフォームで複数のフォーマッタ使い分ける事が出来ない。
formとwidgetに関しては継承しているクラス数が多いため、プラグイン的に問題を解決するのが非常に困難である。
sfFormの不満を解消する気があるなら、別のフォームフレームワークを作るつもりで臨んだ方がいい。
残念ながらSymfony2でもsfFormを書き直すとは言ってなかったので、この品質が良くなる見込みは薄いのかも知れない。
sfWidgetFormSchemaFormatterでぐぐると、公式ドキュメントと、参考にしたブログと、OpenPNEと、うちのサイトしかヒットしない。たぶん、sfFormをまともに使ってる人は日本で3人しか居ないってことだと思う。
使えば使うほどうんざりしてくるsfFormの欠陥仕様。
フォームフレームワークを新規に書き起こすほうがずっと良いとよーくわかったが、
とりあえず今月は残り時間も少ないので頑張って使う。
- フォームに変数の値を持つhiddenタグを追加することができない。
- 一部の項目だけをbindするような動作が取れない。(勝手にバリデーションとCSRFトークンが発動する)
- sfWidgetFormSchemaFormatterTableの%help%がどのタグにも囲まれていない(brタグで仕切られている)
- sfWidgetFormSchemaFormatterの派生クラスは接頭句にsfWidgetFormSchemaFormatterを付けなければいけない。
開発陣の誰かは、sfFormをエンタープライズ向けのWebアプリで実際に使った事あるのか？
hiddenにユーザIDを持たせて、表示はユーザ名にするようなフィールドとか、
編集モードで開いたらidはhiddenで持たせるとか、普通に想定しないものかなあ。
setDefaultを使って回避するべきなのかどうかがわからない。
sfFormの良いところは、actionから独立したという点に尽きると思う。
sfFormの中にrequestもuserも居れば、actionには殆ど何も書かなくて済む。
そうやって将来的にはあの存在価値の無いactionsを駆逐するのがsfFormの使命なのだろう。
でも、sfFormも駆逐されてしまったほうが正直いいと思う。
Flashではなくhiddenで値を持ちまわる構造自体は別にそれで良いと思うんだけど。
symfony 1.4でFormHelperが廃止になったので、やむなくsfFormに移行した訳だが、
使い勝手の悪さは設計センスの問題なのでいつも通り諦めるとして、対応が厳しい所について触れておく。
- 入力欄の左右に文字を追加出来ない。(たとえば 西暦 [] 年 とか)
- PostValidatorを一つしか登録できない。そのためエラーも一度に1つしか表示できない。
- 相変わらず、複数フィールドに関係するバリデータが書きづらい。
- 確認画面が出せない。
入力欄については、ヘルプを表示して誤魔化した。
ヘルプの定義はウィジェットの定義とは別の場所でしなければいけないので多少煩雑である。
PostValidatorを抜本的に解決するには、1フィールドごとにバリデータクラスを定義するしかない。
データベースとの重複登録を確認するたびにクラスを書き起こすとか、そういう事態になる。鬱陶しい。
パスワードを2回入力させて、一致しなければ警告するという機能を実装したかったら、
PostValidatorで処理するのではなく、そういうWidgetとして実装しなければいけない。
確認画面を出すのはもっと大変。
PEARのHTML_QuickFormみたいなfreeze機能があればいいのに。
仕方ないから自力で実装したけど。
これは割と綺麗に出来たので、機会を見てお披露目しておきたい。
