Browse Tag: symfony

symfony の init-admin タスクをさらに改良してみた

先日、紹介した symfony の init-admin タスクを、さらに改良してみたので、今日はその内容について紹介します。

今回は、しばらく init-admin-plus を使っていて、いくつか不便なことに遭遇したため改良してみた。具体的には、次のとおり。

  • 入力値をチェックする validator(ファイルでいうと validator/edit.yml) で、最大文字数のチェックを自分で毎回指定するのがめんどう
  • 同じく validator で、必須のパラメータを指定するのがめんどう
  • 同じく validator で、特定のカラム型に対応する validator を指定するのがめんどう
  • config/generator.yml で、フィード名をデータベースの構造を見ながら指定するのがめんどう
  • 同じく generator.yml で、各画面ごとに表示する項目を指定する display をデータベースの構造をみながら指定するのがめんどう

これらは指定しわすれて不具合につながっていた状況を改善するべく、自動生成して楽をしたいというのが改良のきっけかです。

というわけで、指定されたモデルに対応するテーブル構造を取得するいい方法はないかなと symfony の propel まわりのソースコードを読んでみたところ、config/schema.yml を読むことでいけるということが分かったので、myPakePropelAdminGeneratorPlus に追加してみた。

 

やっていることはとても単純なので、coderepos にアップしたソースコードをみてもらうことにして、config/generator.yml と validator/edit.yml の雛型を準備する必要がある。

これらの雛型は、sfConfig::get(‘sf_root_dir’) の  data/generator/sfPropelAdmin/テーマ名/skeleton に格納されているので、これを変更する。

config/generator.yml の雛型は、次のようにします。次のファイルは、list のみですが create, edit も同様に指定します。

generator:
class: sfPropelAdvancedAdminGeneratorPlus
param:
model_class: ##MODEL_CLASS##
theme: admin
css: admin

#
# 共通フィールド名の設定
#
fields:
##GEN_FIELDS##

#
# TITLE一覧
#
list:
  title: “TITLE一覧”
  display: ##GEN_DISPLAY##
  fields:
  actions:
    _create: –
  filters:
  max_per_page: 20
  sort: id

 

具体的には、##GEN_DISPLAY## のところが [カラム名1, カラム名2,…] に置換される。

 

次に、validator/edit.yml の雛型は、次のようにします。

methods: [post]

fillin:
enabled: on

#
# バリデータ設定
#
fields:
##VALIDATOR##

 

具体的には、##VALIDATOR## のところがいっきに展開されます。これはカラムによって展開される内容が変わってくるけれど、例えば次のようになる。

methods: [post]

fillin:
  enabled: on

#
# バリデータ設定
#
fields:
  hoge{name}:
    required:
      msg: “name is required.”
  sfStringValidator:
    max: 255
    max_error: “This field is too long.”
     myDateValidator:
hoge{created_at}:
  myDateValidator:
hoge{updated_at}:
  myDateValidator:

この例だと、hoge というテーブルがあって name というカラムは必須で長さが 255 まで、created_at と updated_at は timestamp 型であるのでそのチェックを行うという設定で自動的に生成される。

 

これで、かなり symfony で管理画面系を生成するのが楽になって、validation を入れ忘れるというミスもなくなるはず。管理画面系は、けっこう作るのがめんどうなので、できるかぎり自動化を進めていきたいところです。

 

なお、symfony 1.0.18 で動作確認済で、sfPropelAdvancedAdminGeneratorPlus というプラグインは、知人から拝借した sfPropelAdvancedAdminGenerator という独自のプラグインを自分好みで変更したプラグインなので、もしかするともしかするとそのうち公開されるかもしれませんので毎日ググりながら楽しみに待つことにしましょう!

symfony で独自のタスクを作ってみた

最近というかいつの間にか、なぜか仕事で symfony を使って開発をしていますが、symfony の propel-init-admin タスクで自動生成させる action のスケルトンをカスタマイズしていくうちに、標準の propel-init-admin タスクだと、モデル変数名を展開してくれなくて、不便になってきた。

{$sf_symfony_data}/tasks/sfPakePropelAdminGenerator.php をみてみると、次の変数しか展開してくれない。


$constants = array(
'PROJECT_NAME' => $task->get_property('name', 'symfony'),
'APP_NAME' => $app,
'MODULE_NAME' => $module,
'MODEL_CLASS' => $model_class,
'AUTHOR_NAME' => $author_name,
'THEME' => $theme,
);

そこで、次のように追加して、propel-init-admin-plus という独自のタスクを定義してみた。変更したのは、次のところだけ。sfInflector というクラスの存在を調べるのが、すこし大変だった。


$constants = array(
'PROJECT_NAME' => $task->get_property('name', 'symfony'),
'APP_NAME' => $app,
'MODULE_NAME' => $module,
'MODEL_NAME' => sfInflector::underscore($model_class),
'MODEL_CLASS' => $model_class,
'AUTHOR_NAME' => $author_name,
'THEME' => $theme,
);

こうすることで、##MODEL_NAME## となっている部分を自動的に展開してくれて、updated タスクなどを定義できるようになって、かなり便利になった。具体的な、action クラスのスケルトンは、次のような感じにしています。


/**
* ##MODULE_NAME## actions.
*
* @package ##PROJECT_NAME##
* @subpackage ##MODULE_NAME##
* @author ##AUTHOR_NAME##
* @version SVN: $Id: actions.class.php 2288 2006-10-02 15:22:13Z fabien $
*/
class ##MODULE_NAME##Actions extends auto##MODULE_NAME##Actions
{
protected function save##MODEL_CLASS##($##MODEL_NAME##)
{
parent::save##MODEL_CLASS##($##MODEL_NAME##);
}

protected function delete##MODEL_CLASS##($##MODEL_NAME##)
{
parent::delete##MODEL_CLASS##($##MODEL_NAME##);
}

protected function update##MODEL_CLASS##FromRequest()
{
parent::update##MODEL_CLASS##FromRequest();
}

 

protected function get##MODEL_CLASS##OrCreate($id = 'id')
{
return parent::get##MODEL_CLASS##OrCreate($id);
}

 

この独自のタスクは、symfony のプロジェクトディレクトリの data/tasks ディレクトリを作成して、その中に入れるだけで使うことができるので、かなり便利になった。

ソースコードは、coderepos に置いたので自由に使ってください。

symfony を使っていて分からないことがあったら、ぐぐるよりも symfony のソースコードを探検したほうが比較的楽に調べるということが分かってきた。