doctrine:generate-modeleで自動生成されたモジュールは、簡易的なCRUDを提供してくれる優れもの。確かにこれは便利だ。ただし、Djangoと違って、外部キーのレコードを引っ張ってきてくれるとか、そういう部分は自分で書く必要があるのかもしれない。

たとえば、sfDoctrineGuardPluginのsfGuardUserテーブルのidに対してuser_idで外部キーを張っているテーブルがあったとして、このモデルのモジュールを自動生成すると、DjangoのORMのようにuserとしてではなく、単純にuser_idとしてidが表示される。まだORMのDoctrineも良く分かってないので、やはり実作業の流れをつかむのには時間がかかりそうだ。

アクションコントローラとテンプレート

自動生成された操作機能モジュールはactionsとtemplateに配置される。

• apps/frontend/modules/
  • modulename/
    • actions/
      • actions.class.php
    • templates/
      • _form.php
      • editSuccess.php
      • indexSuccess.php
      • newSuccess.php
      • showSuccess.php

アクション

• executeIndex：Indexアクション。モジュールのデフォルトアクション。
• executeShow:Showアクション。Indexで表示された個々のレコードへのリンクをクリックしたときに実行されるアクション。単票形式でレコードを表示する。
• executeNew:Newアクション。Newリンクをクリックしたときに実行される。新規レコードを入力可能なフォームとして表示する。
• executeCreate:登録実行アクション。レコードをDBに登録する。
• executeEdit:Editアクション。Editリンクをクリックしたときに実行される。既存のレコードを編集可能なフォームとして表示する。
• executeUpdate:編集実行アクション。編集内容をDBに更新する。
• executeDelete:Deleteアクション。Deleteリンクをクリックしたときに実行される。

processFormはisValid()メソッドが実行されているので、フォーム処理に関連する何かのはず。createとupdateの中から実行されてるから、多分そうだろう。isValid()=falseの場合が書いてないのがちょっと気になる。symfonyって検証結果がNGだった場合の処理って勝手にやってくれるのかな。この辺の話はチュートリアルでは、また後で出てきたはず。

同じアクション内で、GETの場合とPOSTの場合の処理を分けて記述するわけではないのかもしれない。この辺りもDjangoのお作法とは違うらしい。aspみたいなもんなのかな。

テンプレート

• indexSuccess:Indexアクションにより呼び出される
• showSuccess:Showアクションにより呼び出される
• newSuccess:Newアクションにより呼び出される
• editSuccess:Editアクションにより呼び出される

_form.phpについては、formインスタンス関連の何かが書いてあるはず。まだちょっと理解できてないので、また後で。