Movable Type/第8回MTプラグイン勉強会 - registryのリファレンスを精読する(1) http://www.ark-web.jp/sandbox/wiki/708.html
Movable Type/第8回MTプラグイン勉強会 - registryのリファレンスを精読する(1)
第8回はMovable Type Registry Referenceをじっくり読んでみることを行いたいと思います。長くなるので第9回とわけてやろうと思います。
動画(Ustream) †
勉強会の模様をアップしました。
Ustreamのチャンネルはこちら。
http://www.ustream.tv/channel/mt%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%E5%8B%89%E5%BC%B7%E4%BC%9A
ご感想・ご質問など †
ご感想、ご質問などあればお気軽にどうぞ。頂けるととても励みになります。
勉強会で解説したプログラムコードのダウンロード †
ネタ †
日時 †
- 2008/07/11(金) 10:30〜11:00
ちょっと復習 †
MTではplugin本体のファイル(クラス)はMT::Pluginを継承し、MT::Component->MT::Pluginと継承しているinit_registryメソッドをオーバーライドして、registryメソッドで独自設定をMTのグローバルレジストリにマージします*1。
init_registryメソッドは各プラグインがnewされる際にコンストラクタの初期化処理でコールされます。
以上から、init_registryメソッドをオーバーライドしてregistryメソッドを使うことでプラグインの独自設定を行うことができます。
例えば、以下は__mode=list_productsという管理画面を追加する設定例。
sub init_registry { my $plugin = shift; $plugin->registry({ 'applications' => { 'cms' => { 'methods' => { list_products => 'ProductsManager::CMS::_list_products', }, }, }, }); }
registryにできることを調べることで、プラグインでできることを網羅的に把握できるのではないかと思います。
Registry Syntax †
registryはplugin内でメソッドに指定する方法以外にもconfig.ymlという名前でYAMLで書いてあげることもできるようです。
RegistryのSyntaxが解説されます。
scalar †
既存のkeyと同じkeyの値が指定されると上書きされる。
array †
既存の同じkeyの値が指定されると、当該keyの既存の値群にマージされる。
$registry = { urls => [ 'http://somedomain.com/foo', 'http://somedomain.com/bar', 'http://somedomain.com/baz', ], };
次のようにも書ける。
$registry = { urls => 'http://somedomain.com/foo', urls => 'http://somedomain.com/bar', urls => 'http://somedomain.com/baz', };
Perlの配列アクセスと同じ方法でアクセス可能。
$registry->{'urls'}->[0] # is http://www.soracger.com/blog/
hash †
Hashは他のHashを含むことができる。registryそのものもhashで表現されている。
より複雑な構造を表現することに利用できる。
$registry = { permissions => { 'system.create_blog' => { label => trans("Create Blogs"), group => 'sys_admin', order => 100, }, }, };
handlers †
イベントが生じたときにこれを処理する関数。値はcoderefを指定する
coderef †
関数リファレンス。人まとまりの処理(関数)、その参照を指定できます。
指定方法は以下の通り。
- 関数名を指定する方法
\&function_name \&MT::ComponentName::function_name
- 無名関数を指定する方法
sub { code goes here }
Registry Keys †
registryで指定できるkeyとその解説。
name †
登録するコンポーネント*2の名前
class †
登録されるコンポーネントのパッケージ名。
このパッケージ(クラス)にはコンポーネント登録のために必要な全てのビジネスロジックが書かれている必要があり、Movable Typeがコンポーネント自体も含めて初期化するとき、このパッケージは自動的にロードされる。
# 具体的な使い方がよくわからない^^;
author †
作者名
version †
バージョン。ユーザに対して表示するバージョンナンバーとして利用される。また、インストール済の同じコンポーネントのより新しいバージョンが存在するかどうかの判定に利用される。
バージョンは正の浮動小数点数で表現する。lettersやspecial charactersは含まないようにすること。
# おそらく新しいバージョンの判定で数値の大小で比較するからと思われる。
正しい例
1.0 2.05 0.03
誤った例
0.45a version 3 1.42.1
schema_version †
カスタムデータタイプを定義するコンポーネントを使う場合はschema_versionを指定する必要がある。versionと同じくMTがロードされる際に都度コンポーネントのshcema_versionと記録しているschema_versionが比較されてアップグレードが必要であれば、アップグレード処理が走る。schema_versionに指定する値はversionと同じく正の浮動小数点数。
object_types †
コンポーネントがオリジナルのデータベーステーブルが必要な場合、object_typesを利用できる。MTのコアのアップグレードもこの仕組みを利用している。object_typesのkeyはデータ型名(data type name)、valueには紐付けるパッケージ名与える。valueに指定するパッケージにはそのパッケージが必要とするビジネスロジックの他にデータベース構造の定義が書かれている。
$registry = { version => MT->VERSION, schema_version => MT->schema_version, object_types => { 'foo' => 'MT::Foo', # Custom data type 'bar' => 'MT::Bar', }, };
package MT::Foo; use strict; __PACKAGE__->install_properties({ column_defs => { 'id' => 'integer not null auto_increment', 'blog_id' => 'integer not null', 'title' => 'string(255)', 'text' => 'text', }, });
既存のObject Typesを拡張することもできる。
MT::Entry(data type name = entry)にratingという属性を追加する例。
$registry = { object_types => { 'entry' => { rating => integer, }, }, };
アップグレードを実行させるにはschema_versionをあげてMTのアップグレード機能を呼び出す必要がある。
object_drivers †
※ドキュメント化はされているが現状機能していない
- サポートされているMySQL、Postgres、SQLite以外に、“Enterprise Connectivity Pack.”アドオンを使うことでOracleとMicrosoft SQLServerが利用可能。
- 全てのDBMSの操作は“object drivers.”によって提供される。object driverはDBMS操作の以下のフレームワークを提供する
- インストール時のテーブル作成
- アップグレード時のテーブルメンテナンス
- 一般的な操作を行う際に発行される標準的SQLステートメントの生成
Custom Object Driversの利用
- サポートされていないDBMSやバックエンドのストレージシステムを利用するためには、それらのシステムがMTのobject driverシステムと互換性を持つために、以下の条件を満たす必要がある。
- シンプルなCRUD(create, read, update and delete)が実行可能
- 特定のフィールドに対してインデックスがはれる
- 2テーブル間のjoinが可能
permissions †
(次回)
config_settings †
- MTは二つのコンフィギュレーションの仕組みを持っている。基本的な方法はmt-config.cgiやその他設定ファイルによるコンフィギューレーション*3。この方法のメリットは
- 実装の容易さ
- ユーザインタフェースを破壊しない
- MTがmt-config.cgiのディレクティブをパースしていく際に、未定義のディレクティブが存在していたらエラーになります。独自ディレクティブを使いたい場合、開発者は独自ディレクティブをregistryを使って登録する必要があります。
例)
config_settings => { 'AtomApp' => { type => 'HASH', default => 'weblog=MT::AtomServer::Weblog' }, 'DefaultEntryPrefs' => { type => 'HASH', default => { type => 'Default', # Default|All|Custom button => 'Below', # Above|Below|Both height => 162, # textarea height }, }, 'DefaultLanguage' => { default => 'en_US', }, },
- type
- コンフィギュレーション設定のデータタイプを指定する。SCALAR、ARRAY、HASHから指定可能。SCALARがデフォルト(未定義の時はSCALARが選択される)
- default
- 未定義の場合に使うデフォルト値。type=HASHの場合は
- path
- mt-config.cgiに記述された設定に相対パスがある場合に、これをフルパスに書き換えるかどうかの指定。1/0のbooleanで指定する。
設定の記述例)
PluginSwitch foo=bar PluginSwitch baz=boo Schema 1 Schema 2 Goozer abc
※ PluginSwitchはHASH、SchemaはARRAY、GoozerはSCALARタイプのディレクティブの設定例
text_filters †
(次回)
次回予定 †
次回は引き続きRegistry Referenceを見ていきたいと思います。
tag: Movable Type、MT、MT、MTPlugin、勉強会
*1 Movable Type/第3回MTプラグイン勉強会 - MVC風アーキテクチャ実装例・続き コントローラとビューを参照
*2 コンポーネントって言葉が急に出てきたけれど、おそらくregistryに指定するデータ構造をまとめて呼称していると思われます。ので、プラグイン開発の範囲においてはコンポーネント≒プラグインで読み替えて問題ないかと。
*3 もう一つは何かよくわからない