‘PHP’ タグのついている投稿

symfonyで携帯端末用のテンプレート切り替えを実装する

symfony 1.4で、PCサイトの携帯版を作ることになりました。

アクションは共通にして、テンプレートのファイル名を、携帯とPCで切り分けるようにしたいと思います。

例:
templates/indexSuccess.php (PC用)
templates/indexSuccess.mobile.php (携帯用)

で、これはフォーマットを指定することで実現できます。フォーマットに関してはJobeetを参照。

Practical symfony | 15日目: Web サービス | symfony | Web PHP Framework

まずは携帯キャリアのIPから高速にキャリア判定をしてくれるプラグインを準備しておきます。

sfMobileIPPluginをsymfony 1.4で使ってみた

次にフィルタを用意します。

app/frontend/lib/filter/myMobileLayoutFilter.class.php

<?php

class myMobileLayoutFilter extends sfFilter
{
    public function execute($filterChain)
    {
        if ($this->isFirstCall()) {
            
            if (sfMobileIP::carrier() != 'pc') {
                $request = $this->getContext()->getRequest();
                $request->setRequestFormat('mobile');
            }
            
        }

        $filterChain->execute();
    }
}

最後にfilters.ymlを編集すればOKです。

app/frontend/config/filters.yml

rendering: ~
security:  ~

myMobileLayoutFilter:
  class: myMobileLayoutFilter

cache:     ~
execution: ~

layoutのテンプレートも携帯版を用意しておきます。

例:

app/frontend/templates/layout.php (PC用)

app/frontend/templates/layout.mobile.php (携帯用)

注意点として、partialなども全部「.mobile.php」の形式のファイルがないと動作しません。どこかでファイルを作り忘れるとsfRenderExceptionが投げられるので注意してください。ちなみに、dev環境だとそのまま真っ白な画面になってしまって、原因追求がしにくいようです。

その場合は、ログファイルにてチェックしましょう。

log/frontend_dev.log

symfony [err] {sfRenderException} The template "indexSuccess.mobile.php" does not exist or is unreadable in "".


sfMobileIPPluginをsymfony 1.4で使ってみた

sfMobileIPPluginという、IPベースで高速にキャリア判定をするsymfonyプラグインがあったので、使ってみました。

1.0用に作られているらしく、一部修正する必要があります。

とりあえずやってみてダメだった手順。

$ ./symfony plugin:add-channel openpear.org
$ ./symfony plugin:install -s beta openpear.org/sfMobileIPPlugin

ダウンロードしてインストールを試みる。(これもXMLがおかしいと言われて不可)

$ ./symfony plugin:install ./sfMobileIPPlugin-0.0.13.tgz

ダメっぽいので適当にディレクトリ作って解凍しました。これでセットアップできました。

$ mkdir tmp
$ mv sfMobileIPPlugin-0.0.13.tgz ./tmp/
$ cd tmp/
$ tar xvzf ./sfMobileIPPlugin-0.0.13.tgz
$ mv ./sfMobileIPPlugin-0.0.13 ../plugins/sfMobileIPPlugin

configのyml類はconfigディレクトリに移さずに使える模様です。configにコピーしておけばオーバーライドできるので開発環境の場合はconfigにコピーしたあと、ローカルのネットワーク範囲を追加しておけば便利かと思います。

手動で設置したので、ProjectConfigurationにプラグインを使用するように記述する必要があります。

config/ProjectConfiguration.class.phpの

public function setup()
{
  ...
}

$this->enablePlugins('sfMobileIPPlugin');

を追加します。

1.4ではすでに存在しないメソッドがあるので、それも書き換えます。

plugins/sfMobileIPPlugin/lib/sfMobileIP.class.php

static protected function configFile()
{
  $config_dir  = sfConfig::get('sf_config_dir_name');
  $config_file = $config_dir.DIRECTORY_SEPARATOR.'mobile_ips.yml';
  return sfConfigCache::getInstance()->checkConfig($config_file);
}

を以下のように修正。

static protected function configFile()
{
  return sfContext::getInstance()->getConfigCache()->checkConfig('config/mobile_ips.yml');
}

あと、pear::Net_IPv4が必要です。これがないとdev環境でもエラーを出さずに途中で止まります。

symfonyコマンドでもインストールできますが、pluginディレクトリが汚くなるので、オートロードできる場所にNet_IPv4.phpファイルを適当に設置すれば良いかと思います。

http://pear.php.net/package/Net_IPv4/download

あとは

./symfony cc

を実行して、プログラム内でsfMobileIP::carrier()を実行すればキャリアを読み取れます。


phpMyAdminのYAMLエクスポートとsymfonyのfixture

Symfony 1.4+Doctrineにて。テストを実行するために、fixtureを用意するのですが、

$ symfony doctrine:data-dump dump.yml

でやろうとしたらデータが重すぎて途中で落ちる。

ので、phpMyAdminにYAMLエクスポート機能がいつの間にか実装されていたので、それを使って必要な部分だけをエクスポートします。

ところがそれをそのまま読み込むといくつか問題が…

ということで、気になった3点。

  • 改行があると読み込めない
  • 日付形式が読み込めない
  • fixtureのymlファイルよりインデントひとつ分浅い

改行のある行はダブルクォートで囲ってから、改行文字を\nにすれば読み込めるようになります。

日付はダブルクォートで囲めばOK。

インデントは置換するなり何なりしましょう。

テスト周りに関してはチートシートが欲しいなぁ…


Symfonyで外部のプログラムを実行する

Symfony 1.4でシェルのプログラムを呼び出すときに、PHPのexec関数に代わる便利なメソッドがあったのでメモ。

sfFilesystem::execute()がそれです。
symfony API » sfFilesystem Class | symfony | Web PHP Framework

内部的にはproc_openで
戻り値は、標準出力と標準エラー出力が分離されて配列で返ってきます。

タスクから、呼び出すとこんな感じになります。

    protected
        $outputBuffer = '';

    protected function execute($arguments = array(), $options = array())
    {
        // initialize the database connection
        $databaseManager = new sfDatabaseManager($this->configuration);
        $connection = $databaseManager->getDatabase($options['connection'] ? $options['connection'] : null)->getConnection();

        // 処理待ちリストから一行取得
        $process = Doctrine::getTable('Processes')->findOneByStatus('WAIT');
        $command = $process['command'];

        // バッファクリア
        $this->outputBuffer = '';
        try {
            // 実行。第二引数は標準出力、第三引数は標準エラー出力を受け取るコールバック関数
            list($output, $err) = $this->getFilesystem()->execute($command, array($this, 'setBuffer'), array($this, 'setBuffer'));
            $process['status'] = 'SUCCESS';
            $process['message'] = $output;
            $process->save();
        } catch (RuntimeException $e) {
            // コマンドが実行できなかった場合と、終了時エラーの場合はRuntimeExceptionがthrowされる
            $process['status'] = 'FAILED';
            // エラー時はexecuteの戻り値を取得できないのでコールバックの結果からメッセージを取得
            $process['message'] = $this->outputBuffer;
            // 必要なら$e->getCode();でエラーコード取得できます
            $process->save();
        }
    }

    public function setBuffer($output)
    {
        $this->outputBuffer .= $output;
    }

/vendor/pear/php/symfony/task/project/sfProjectDeployTask.class.phpがサンプルとして使えます。

もちろん、PHPのexec関数を使って

exec($command, $output = array(), $return_var = 0);

とかしてもいいと思います。

多分プラグインのインストール段階でmakeとかするときに使うんじゃないですかね。

標準出力を段階的に画面に表示できるので。

ただし、出力バッファの読み取り単位ごとに、0.1秒のディレイをかけているようなので、速度重視なところでは注意が必要です。


Symfonyのクライアントサイドバリデータ

SymfonyでjQueryを使ったクライアントサイドのバリデーションを簡単に実現できるjnAjaxFormValitatorというプラグインがあったので、試してみました。

このプラグインはフォームが変更された際に、Ajaxでサーバにバリデーションルールと値を送ってサーバサイドでバリデーションをかけ、その結果を表示します。

結論から言うと、簡単に導入できて便利ですが、一部セキュリティ的に難あり、

1.2用ですが、ちょっとの修正で1.4でも使えます。

まずはダウンロード。

Plugins | jnAjaxFormValidatorPlugin | 1.0.2 | symfony | Web PHP Framework

20100617223542

ダウンロードしなくてもサーバから直接インストールできるらしいのですが、今回はtgzファイルをダウンロードしてきてインストールしました。

$ ./symfony plugin:install ./jnAjaxFormValidatorPlugin-1.0.2.tgz
>> plugin    installing plugin "./jnAjaxFormValidatorPlugin-1.0.2.tgz"
>> sfSymfonyPluginManager Installation successful for plugin "./jnAjaxFormValidatorPlugin-1.0.2.tgz"

インストール成功したら、アプリケーション以下のconfig/setting.ymlを開いてモジュールを有効にする設定を書きます。

all:
  .settings:
    enabled_modules:        [default, jnAjaxFormValidator]

READMEは全部スペルミスでjnAjaxFormValitatorになっているのでコピペすると間違えます。

次はアプリケーション以下のconfig/routing.ymlに以下を追加します。

# —– jnAjaxFormValidator —–
jnAjaxFormValidator_validateJSON:
  url:   /jnAjaxFormValidator/validateJSON
  param: { module: jnAjaxFormValidator, action: validateJSON }

その後、キャッシュをクリアします。

$ ./symfony cc

バリデーションを使用するテンプレートの先頭にでも、

<?php use_helper(‘ajaxFormValidator’) ?>
<?php echo ajaxAllFieldsValidators($form) ?>

と書いておけばOKです。

インストール手順はこれで完了ですが、このままだとSymfony 1.4で動かないので、actions.class.phpを修正します。

/plugins/jnAjaxFormValidatorPlugin/modules/jnAjaxFormValidator/actions/actions.class.php 29行目
sfLoader::loadHelpers(‘I18N’);

sfContext::getInstance()->getConfiguration()->loadHelpers(array(‘I18N’));

以上で完了です。

20100617225540

あと、書き出されるエラーが
<ul class="error_list"><li>エラーメッセージ</li></ul>
の構造に固定されているので、必要であればヘルパー側を修正する必要があります。

難点は、バリデーションのルールをブラウザ側に一度保持することです。単純にバリデータクラス名とバリデーションルール、値をJSからサーバに送信してバリデータを実行しているだけなので。

20100617225648

上の図はリクエスト時のパラメータです。GETで送られます。何が問題かというと、サーバ内のバリデーションルールが表に流れるので、攻撃者が穴を見つけやすくなるということですね。

バリデーションは完璧で、特にクリティカルな要件でないなら使えると思います。

あと、返されるエラーメッセージはformで定義したものを使えないので、デフォルトのエラーメッセージになります。

デフォルトのエラーメッセージは、アプリケーションのConfigurationなどで

sfValidatorBase::setDefaultMessage(‘max_length’, ‘%max_length%文字までにしてください’);

などとしておくか、カタログファイルでも変更できます。

ちなみにソースコードはびっくりするくらいシンプル。チェコ人が作ったらしく、I18Nも意識されてます。


sfWidgetFormInputCheckboxの正負を反転させる その2

前回のエントリで、モデルを拡張して読み出し時と保存時に正負反転させる方法を紹介しましたが、カラム名と実際の動作が逆になってしまって紛らわしいので、widgetとvalidatorで反転させることにしました。Symfony 1.4+Doctrineです。

既存のsfWidgetFormInputCheckboxとsfValidatorBooleanを継承して実装します。

lib/widget/sfWidgetFormInputCheckboxInverse.class.php

<?php

class sfWidgetFormInputCheckboxInverse extends sfWidgetFormInputCheckbox
{
    public function render($name, $value = null, $attributes = array(), $errors = array())
    {
        
        if (!(null !== $value && $value !== false))
        {
            $attributes['checked'] = 'checked';
        }

        if (!isset($attributes['value']) && null !== $this->getOption('value_attribute_value'))
        {
            $attributes['value'] = $this->getOption('value_attribute_value');
        }

        return parent::render($name, null, $attributes, $errors);
    }
}

lib/validator/sfValidatorBooleanInverse.class.php

<?php

class sfValidatorBooleanInverse extends sfValidatorBoolean
{

    protected function configure($options = array(), $messages = array())
    {
        parent::configure($options, $messages);
        $this->setOption('empty_value', true);
    }

    protected function doClean($value)
    {
        if (in_array($value, $this->getOption('true_values')))
        {
          return false;
        }

        if (in_array($value, $this->getOption('false_values')))
        {
          return true;
        }

        throw new sfValidatorError($this, 'invalid', array('value' => $value));
    }

}

ほぼ、逆にしたメソッドでオーバーライドしただけです。チェックボックスにチェックを入れなかった場合の挙動がデフォルトではfalseなので、trueに変更しています。

これをformクラスから

        $this->widgetSchema['show_flag'] = new sfWidgetFormInputCheckboxInverse();
        $this->validatorSchema['show_flag'] = new sfValidatorBooleanInverse();

のように定義してやればいいだけです。

例によってカラムのタイプがbooleanになっていることを確認してください。なっていないと0でも1でもtrueと判断されてしまうので。

        $this->hasColumn('show_flag', 'boolean', null, array(
             'type' => 'boolean',
             'notnull' => true,
             'default' => 0,
             ));


sfWidgetFormInputCheckboxの正負を反転させる その1

symfony 1.4にて。データベースの定義は「表示」フラグなのに、フォームでは「非表示」時にチェックを入れさせたい場合などがありまして。

データベースのカラム自体の意味を変えるのは、逆にフォームの意味が今後変わったときにどうするんだという話なので、今回はモデルでの入出力時点で値を変更する方法を試してみました。

actAsで各モデルの好きなカラムを反転できる拡張にしてみました。

lib/InvertBoolean.class.php

<?php

class InvertBoolean extends Doctrine_Template
{
    protected $_options = array(
        'columns' => array()
    );
    
    public function setTableDefinition()
    {
        $this->addListener(new InvertBooleanListener($this->_options));
    }
    
    public function setUp()
    {
    }
}

lib/model/invert_boolean/InvertBooleanListener.class.php

<?php

class InvertBooleanListener extends Doctrine_Record_Listener
{
    protected $_options;
    
    public function __construct(array $options)
    {
        $this->_options = $options;
    }

    public function postHydrate(Doctrine_Event $event)
    {
        $obj = $event->data;
        foreach ($this->_options['columns'] as $column) {
            $obj->$column = !($obj->$column);
        }
        $event->set('data', $obj);
    }

    public function preSave(Doctrine_Event $event)
    {
        foreach ($this->_options['columns'] as $column) {
            $value = !($event->getInvoker()->get($column));
            $event->getInvoker()->set($column, $value);
        }
    }
}

postHydrateでデータをデータベースから読み出してきてハイドレートした後に、preSaveで保存する前にそれぞれデータを反転しています。

カラムのタイプはあらかじめbooleanにしておく必要があります。schema.ymlからデータベース生成した場合は問題ないかと思います。そうでないなら、モデルのsetUpメソッドにでも

        $this->hasColumn('show_flag', 'boolean', null, array(
             'type' => 'boolean',
             'notnull' => true,
             'default' => 0,
             ));

など。

これを使用できるようにするために、同じくモデルのsetUpメソッドに

$this->actAs('InvertBoolean', array('columns'=>array('show_flag')));

とすればOKです。actAsのcolumnsオプションに複数カラム名設定すれば複数カラムを一括で指定できます。

これで、sfWidgetFormInputCheckboxを使ったチェックボックスにチェックを入れたときにデータベースに0が保存され、チェックを外すと1が保存されるカラムができあがりました。

問題点として、カラム名と反対の動きをすることになるので、うっかりする可能性が高まります。

なので、動作は確認しましたが、結局この案は使ってません。次のエントリーで紹介するカスタムウィジェットの方法を使っています。


admin generatorの編集後のリダイレクト先変更

admin generatorのeditアクションで、編集後に再度編集画面ではなく、リストに飛ばしたい要件があったのでメモ。例によってSymfony 1.4+Doctrine+admin generator。

class hogeActions extends autoHogeActions
{
    public function executeUpdate(sfWebRequest $request)
    {
        $this->forward404Unless($request->isMethod('put'));
        
        $this->hoge = $this->getRoute()->getObject();
        $this->form = $this->configuration->getForm($this->hoge);
        
        if ($this->form->bindAndSave($request->getParameter($this->form->getName()), $request->getFiles($this->form->getName()))) {
            $this->redirect('hoge');
        }
        
        $this->setTemplate('edit');
    }
}

executeUpdateをオーバーライドすればOKのようです。ここではisMethodがputなことに注意。


Symfonyでのsave時に独自の処理を挟む

Symfony 1.4+Doctrineで、admin generatorな環境です。editなど、自動生成なので、どこをオーバーライドすれば目的の動作になるのかわかりにくいことがありますね。

例えば、あるモデルのステータスを変更すると同時に、他のモデルに対しても操作したい場合があるとします。

まぁ、mergeFormとかembedFormとか使ってもいいのですが、今回は他テーブルのプライマリキーをフォームから選択させたかったので、汎用性のあるdoSaveでの処理を追加してみました。

symfony Forms in Action | 第11章 – Doctrine との統合 | symfony | Web PHP Framework

class BackendHogeForm extends HogeForm
{
    public function configure()
    {
        parent::configure();

        // 使用するフィールドを指定
        $this->useFields(array('status'));
        
        // 別モデルのIDリストを選択するフォームを作成する
        $choices = array(100 => '100:value1', 101 => '101:value2');
        $this->widgetSchema['other_model_id'] = new sfWidgetFormSelect(array('choices' => $choices));
        $this->validatorSchema['other_model_id'] = new sfValidatorChoice(array('choices' => array_keys($choices)));
    }

    protected function doSave($con = null)
    {
        if ($this->getValue('status') == 'DONE') {
            Doctrine::getTable('OtherModel')->find($this->getValue('other_model_id'))
                ->setIsSelected(TRUE)
                ->save();
        }
        return parent::doSave($con);
    }
}

基本的にはdoSaveをオーバーライドするだけです。ちなみにuseFieldsメソッドを使うと必要なフィールド以外を全部unsetしてくれるので便利です。


PHPのDateTimeの結果が-0001-11-30 00:00:00になる現象について

mySQLなどで、日時を0000-00-00 00:00:00としてデータベースに格納しておくことがありますが、これを読み込んでそのままPHPのDateTimeオブジェクトに渡すと、出力が-0001-11-30 00:00:00になってしまいます。

$a = new DateTime('0000-00-00 00:00:00');
echo $a->format('Y-m-d H:i:s');
// Output: -0001-11-30 00:00:00

PHP :: Bug #42971 :: DataTime::format(): not well formated data ‘0000-00-00 00:00:00’

で、これはバグではないと言われているので、どういうことかと考えてみると、0000-00-00は存在しない0月0日を指定しているので、0月は繰り下がって-1年12月0日、さらに0日も繰り下がって-1年11月30日、となるわけですね。

データベースとPHPの文化の違い、というところでしょうか。

ちなみにDateTime型、コンストラクタにNULLを渡すと現在時刻のインスタンスが生成されるので、データベースの値をNULLにしておくと、現在時刻になってしまいます。うーん…symfonyのDoctrineでNULL判定したい場合はどうすればいいんだ…

$row->getDateTimeObject('deleted_at')

みたいなことがやりたいのですが。

sfDoctrineRecordも

    $type = $this->getTable()->getTypeOf($dateFieldName);
    if ($type == 'date' || $type == 'timestamp')
    {
      return new DateTime($this->get($dateFieldName));
    }

こうなってるからオーバーライドするしかないのかな。