[symfony]1.3/1.4からyamlでon/off/yes/noが使えない

Written by uechoco 8月 06
この記事を読む時間:19くらい

いまだにsymfonyの1.3/1.4系の和書がでないので、symfony 1.0時代の緑の本とかオレンジの本とかを参考にすることもあります。あるいはネット上には1.2系の情報がまだ蔓延しているのでそいうのも参考にしています。そんな時たまに困るのが、YAMLの書き方。タイトルの通り、symfony 1.3/1.4系ではブール値を表すのに従来のon/offやyes/noというのが使えなくなっています。正確には

  • on、y、yes、+ ⇒ true
  • off、n、no、- ⇒ false

となっています。symfony 1.2から1.3/1.4へアップグレードするためのドキュメントのYAMLの項にも明記があります。こういう変更って意外と見逃しがちで、意外と原因究明に時間を取られるんですよね。symfony 1.0~1.2ユーザの方は気をつけましょう。

そのほかの参考になるリンク;

[OpenPNE3]opFreepagePlugin 0.9.2 リリース

Written by uechoco 7月 28
この記事を読む時間:122くらい

OpenPNE3にフリーページ機能を追加するopFreepagePluginの0.9.2をリリースしました。

リリースの詳細とインストール方法は http://plugins.openpne.jp/release/223 を御覧ください。

opFreepagePluginの0.9.0からの主な変更点は以下のとおりです。

  • OpenPNE 3.4系(Doctrine)対応 (balibaliさんからのpull request、ありがとうございます!)
  • テンプレート本文をTwigテンプレートエンジンで描画(Twig構文が使えます!)

Twig自体は管理画面のメールテンプレート機能で使われていましたので、その描画部分を参考にして作りました。sfSymfonyTemplatingViewPluginというOpenPNE3のリードコミッターの海老原さんが作ったプラグインを通してTwigを使用するような仕様になっています。このプラグインの使い方というよりは、Symfony Templatingの使い方がうまく読み取れずに苦戦しました(Engineの選定とテンプレートパスの決定部分など)。

一応動いていそうなので、しばらく様子見ます。

是非使ってみてください。

[symfony]app:routesコマンド

Written by uechoco 12月 21
この記事を読む時間:1121くらい

Jobeet(Practical symfony)の5日目にあった、ルートのデバッグをするためのコマンドが、app:routesコマンドです。

./symfony app:routes application [name]

試しにJobeetの5日目の状態で「./symfony app:routes frontend」をたたくとこんな感じです。

  1. $ ./symfony app:routes frontend
  2. >> app       Current routes for application "frontend"
  3. Name          Method Pattern
  4. job           GET    /job.:sf_format
  5. job_new       GET    /job/new.:sf_format
  6. job_create    POST   /job.:sf_format
  7. job_edit      GET    /job/:id/edit.:sf_format
  8. job_update    PUT    /job/:id.:sf_format
  9. job_delete    DELETE /job/:id.:sf_format
  10. job_show      GET    /job/:id.:sf_format
  11. job_show_user GET    /job/:company_slug/:location_slug/:id/:position_slug
  12. homepage      ANY    /
  13. default_index ANY    /:module
  14. default       ANY    /:module/:action/*

お決まりのdefaultルートに対して、「./symfony app:routes frontend default」をたたくとこんな感じです。

  1. $ ./symfony app:routes frontend default
  2. >> app       Route "default" for application "frontend"
  3. Name         default
  4. Pattern      /:module/:action/*
  5. Class        sfRoute
  6. Defaults    
  7. Requirements action: '[^/\\.]+'
  8.              module: '[^/\\.]+'
  9. Options      cache: NULL
  10.              context: array ()
  11.              debug: true
  12.              default_action: 'index'
  13.              default_module: 'default'
  14.              extra_parameters_as_query_string: true
  15.              generate_shortest_url: true
  16.              lazy_routes_deserialize: false
  17.              load_configuration: false
  18.              logging: false
  19.              lookup_cache_dedicated_keys: false
  20.              segment_separators: array (0 => '/',1 => '.',)
  21.              segment_separators_regex: '(?:/|\\.)'
  22.              suffix: ''
  23.              text_regex: '.+?'
  24.              variable_content_regex: '[^/\\.]+'
  25.              variable_prefix_regex: '(?:\\:)'
  26.              variable_prefixes: array (0 => ':',)
  27.              variable_regex: '[\\w\\d_]+'
  28. Regex        #^
  29.              /(?P<module>[^/\.]+)
  30.              /(?P<action>[^/\.]+)
  31.              (?:(?:/(?P<_star>.*))?
  32.              )?
  33.              $#x
  34. Tokens       separator  array (0 => '/',1 => NULL,)
  35.              variable   array (0 => ':module',1 => 'module',)
  36.              separator  array (0 => '/',1 => NULL,)
  37.              variable   array (0 => ':action',1 => 'action',)
  38.              separator  array (0 => '/',1 => NULL,)
  39.              text       array (0 => '*',1 => NULL,)

そしてsfPropelRouteCollectionによる自動生成ルートの1つに対して「./symfony app:routes frontend job_edit」をたたくとこんな感じです。

  1. $ ./symfony app:routes frontend job_edit
  2. >> app       Route "job_edit" for application "frontend"
  3. Name         job_edit
  4. Pattern      /job/:id/edit.:sf_format
  5. Class        sfPropelRoute
  6. Defaults     action: 'edit'
  7.              module: 'job'
  8.              sf_format: 'html'
  9. Requirements id: '\\d+'
  10.              sf_format: '[^/\\.]+'
  11.              sf_method: array (0 => 'get',)
  12. Options      cache: NULL
  13.              context: array ()
  14.              debug: true
  15.              default_action: 'index'
  16.              default_module: 'default'
  17.              extra_parameters_as_query_string: true
  18.              generate_shortest_url: true
  19.              lazy_routes_deserialize: false
  20.              load_configuration: false
  21.              logging: false
  22.              lookup_cache_dedicated_keys: false
  23.              method: NULL
  24.              model: 'JobeetJobPeer'
  25.              object_model: 'JobeetJob'
  26.              segment_separators: array (0 => '/',1 => '.',)
  27.              segment_separators_regex: '(?:/|\\.)'
  28.              suffix: ''
  29.              text_regex: '.+?'
  30.              type: 'object'
  31.              variable_content_regex: '[^/\\.]+'
  32.              variable_prefix_regex: '(?:\\:)'
  33.              variable_prefixes: array (0 => ':',)
  34.              variable_regex: '[\\w\\d_]+'
  35. Regex        #^
  36.              /job
  37.              /(?P<id>\d+)
  38.              /edit
  39.              (?:\.(?P<sf_format>[^/\.]+)
  40.              )?
  41.              $#x
  42. Tokens       separator  array (0 => '/',1 => NULL,)
  43.              text       array (0 => 'job',1 => NULL,)
  44.              separator  array (0 => '/',1 => NULL,)
  45.              variable   array (0 => ':id',1 => 'id',)
  46.              separator  array (0 => '/',1 => NULL,)
  47.              text       array (0 => 'edit',1 => NULL,)
  48.              separator  array (0 => '.',1 => NULL,)
  49.              variable   array (0 => ':sf_format',1 => 'sf_format',)

あまりに細かすぎて謎な感じですが、私が使うとしたら、詳細表示の末尾のTokensセクションにて、セパレータ文字が有効かどうかを確認するくらいでしょうか。以前セパレータに「_」を使ったらセパレータとして認識されなかったことがあったので、悩んだ末に「.」に変更したのですが、もしかしたらそこで使えたのかもしれません。

[symfony]propel:build-model時のBaseモデルのタイムスタンプ変更を停止する

Written by uechoco 12月 16
この記事を読む時間:120くらい

symfonyでsubversionやgitなどのバージョン管理システムを使っているとき、symfonyコマンドのpropel:build-modelをした後に、モデルとPeerのベースクラスが根こそぎ更新されているのが気になっていませんか?

実はpropelがモデルとPeerのベースクラスのphpDocコメント内に、生成日時のタイムスタンプを入れているんです。このタイムスタンプがbuild-modelをするたびに書き変わるので、毎回バージョン管理システムの更新対象になってしまっています。

このタイムスタンプの生成を停止する方法がありました。

モデル再構築で余計な更新が発生しないようにする – aki77の日記

このブログに載っているように、config/propel.iniの中にある、propel.addTimeStampをfalseにすると、タイムスタンプの生成が停止します。この変更で、build-model後のsvn status/git statusの結果がだいぶ改善されました。これはぜひお勧めしたい設定です。

こういうような、symfonyの新規プロジェクトを立ち上げたら、始めにやっておくべきTODO集があるといいですね。

[symfony]Webデバッグツールバーにピークメモリを表示する

Written by uechoco 12月 08
この記事を読む時間:116くらい

知りませんでした。symfonyのWebデバッグツールバーに表示されているメモリ使用量は、メモリの最大使用量ではなかったのです現在の確保されたメモリ量というのが正しいです。これってsymfony使いの常識ですか?

当然、メモリの最大使用量を表示したいですよね。symfony 1.2以上であれば、簡単に実装できます。(symfony 1.0をお使いの方は、sfWebDebugで、より正確なメモリ使用量を見るには – Sooeyをご覧ください。)

symfonyのWebデバッグツールバーのカスタマイズ方法は、Cookbookにしっかりと載っているのです。今回参考にするのは、The symfony Cookbook | Webデバッグツールバーをカスタマイズする方法 | symfony | Web PHP Frameworkです。実際にやってみましょう。

まずはメモリの最大使用量を表示するためのsfWebDebugPanelクラスの派生クラスを作成します。sfWebDebugPanelMemoryクラスをほんの少しだけ変えただけのクラスです。libフォルダなどに作りましょう。

  1. <?php
  2.  
  3. /**
  4.  * sfWebDebugPanelPeakMemory adds a panel to the web debug toolbar with the peak memory used by the script.
  5.  *
  6.  * @package    symfony
  7.  * @subpackage debug
  8.  */
  9. class sfWebDebugPanelPeakMemory extends sfWebDebugPanel
  10. {
  11.   public function getTitle()
  12.   {
  13.     if (function_exists('memory_get_peak_usage'))
  14.     {
  15.       $totalMemory = sprintf('%.1f', (memory_get_peak_usage() / 1024));
  16.  
  17.       return '<img src="'.$this->webDebug->getOption('image_root_path').'/memory.png" alt="Peak Memory" /> peak:'.$totalMemory.' KB';
  18.     }
  19.   }
  20.  
  21.   public function getPanelTitle()
  22.   {
  23.   }
  24.  
  25.   public function getPanelContent()
  26.   {
  27.   }
  28. }

お気づきかと思いますが、Webデバッグツールバーの1つ1つの項目はsfWebDebugPanelクラスの派生クラスです。構造化がうまくなされているので、追加も簡単という訳です。

次に、Webデバッグツールバーに登録します。今回はプロジェクト全体で適用したいので、ProjectConfiguration.class.phpを変更します。frontendConfiguration.class.phpでも同じコードで動きます。

  1. class ProjectConfiguration extends sfProjectConfiguration
  2. {
  3.   public function setup()
  4.   {
  5.     // ...
  6.     $this->dispatcher->connect('debug.web.load_panels', array($this, 'configureWebDebugToolbar'));
  7.   }
  8.  
  9.   public function configureWebDebugToolbar(sfEvent $event)
  10.   {
  11.     $webDebugToolbar = $event->getSubject();
  12.     $webDebugToolbar->setPanel('peak_memory', new sfWebDebugPanelPeakMemory($webDebugToolbar));
  13.     $webDebugToolbar->removePanel('memory');
  14.   }
  15.  
  16. }

字面でなんとなくわかるかもしれませんが、Webデバッグツールバーのロード時にconfigureWebDebugToolbar()メソッドを呼び出すように登録しています。メソッド内では、さきほど作成した最大使用量を表示するパネルを追加し、代わりに元々あったメモリ表示のパネルを削除しています。

実際に使用したときのWebデバッグツールバーがこのようになります。
sfWebDebugPanelPeakMemory
上記sfWebDebugPanelPeakMemoryクラスの中で、わかりやすく「peak:」を表示するようにしています。

今一度、symfonyを見直してみるのもいいかもしれませんね。