Movable Typeのプラグインファイル構成について: 小粋空間

Top ＞ Movable Type ＞プラグイン開発＞ Movable Typeのプラグインファイル構成について

Movable Typeのプラグインファイル構成について

Posted at November 6,2010 2:02 AM
Tag：[Developer, MovableType, Plugin]

Movable Typeのプラグインファイル構成について紹介します。

MTQでプラグインファイルについて質問があり、このエントリーを書くことにしました。質問の要旨は次の通りです。

プラグインにはYAMLファイルがないものが多く、単にxxx.plのみで配布されているものもあります。またlibディレクトリ内の～.pmというファイルもあったりなかったりします。どういう時にこれらのファイルを選択または使用しているのでしょうか。

ということで、本エントリーではプラグインファイルの選択・配置について解説します。

１．YAMLファイル（config.yaml）の有無について

YAMLファイル（config.yaml）は、プラグインの定義（プラグイン名やバージョン、プラグインの初期設定など）を行うためのファイルで、Movable Type 4からYAML形式でのプラグイン定義ができるようになりました（下）。

config.yaml

id: MyPlugin
name: Sample plugin
version: 1.0
description: Sample plugin
author_name: Plugin author
author_link: http://www.example.com/about/
doc_link: http://www.example.com/MyPlugin/docs/
…後略…

Movable Type 4以前のMovable TypeプラグインはPerl言語しか許容されておらず、その際に定義するプラグインファイルがxxx.plというファイルです（下）。拡張子が.plであればファイル名は任意です。

MyPlugin.pl

package MT::Plugin::MyPlugin;
use strict;
use base qw( MT::Plugin );
 
my $plugin = new MT::Plugin::MyPlugin({
    name => 'Sample Plugin',
    version => 1.0,
    description => 'Sample plugin',
    author_name => 'Plugin author',
    author_link => 'http://www.example.com/about/',
    doc_link => 'http://www.example.com/MyPlugin/docs/',
});
MT->add_plugin($plugin);

プラグインの機能を実現する上では、PerlでもYAMLでもプラグイン定義に関する機能の違いはありませんが、上のコードから分かるようにYAMLの方がシンプルに記述できます。~~以前開催されたMTDDCの澤田さんのスライドで「YAMLは実行コードを含まないのでセキュア」というお話もありました。~~→Perlとの違いはありませんでした。参考：「Re: Movable Typeのプラグインファイル構成について」

２．YAML形式で定義されたプラグインが少ない理由など

YAML形式で定義されたプラグインが少ないとすれば、以下の理由が考えられます。あくまで推測です。

配布プラグインがMovable Type 3の時代に作られており、バージョンアップを行ってもPerl形式のプラグイン定義が継承されている。
Movable Type 3との互換性を考慮してPerl形式のプラグインを開発している。
Perl形式のプラグイン開発が定着しており、Movable Type 4以降もPerlで開発を行っている。
YAMLでのプラグイン開発に関する情報が少ない。

ちなみに私は、最近作っているプラグインについてはすべてYAMLで定義しています。以前開発したプラグインもバージョンアップの機会があればYAMLにリファクタリングしています。

最初はYAMLのお作法になじまなかったのですが、Perlよりも楽に記述でき、最近は重宝しています。

３．libディレクトリ（モジュール）の必要性について

１項で説明したプラグイン定義をPerlで実装すれば、そのファイルでPerlが扱えるので、すべてのコードをまとめて記述することもできます。ただし、1つのファイルにすべてのコードを埋め込むと、コード自体の機能が不明確になります。

config.yamlにもPerlのコードを記述することは可能ですが、いずれにしても機能分担を明確にするために、モジュールを作成した方が良いと思います。そうすることでコードの保守性が向上します。MTのコア機能でも、オブジェクトや機能別にモジュールに分割して、lib/MT配下に配置しています。

lib（library）ディレクトリ配下にモジュールを配置するのは、LinuxやPerl言語のお作法のようです。プラグインもこの形式に倣った配置が行えます。プラグイン定義ファイルにモジュール名を記述する場合も、libディレクトリを意識せずに定義できるようになっています（YAMLでの定義については後述）。

４．libディレクトリ配下の構成について

lib配下に直接モジュール（xxx.pm）を配置しても構いませんが、よくみかけるのは、次のようにプラグイン名のディレクトリを配置し、その配下にモジュールまたはディレクトリを配置する方法です。

下はMyPluginというプラグインのモジュール配置例です。

MT_DIR/
  └ plugins/
      └ MyPlugin/
          ├ config.yaml
          └ lib/
             └ MyPlugin/
                ├ Tags.pm
                └ CMS.pm

この例のように、Tags.pmやCMS.pmという、意味のある名称にしたモジュールを配置すれば機能分担が明確になり、保守性が向上します。より大規模なプラグインを開発する場合、さらにディレクトリやファイルを分割しても良いでしょう。

５．config.yamlでのモジュール定義

４項のようにモジュールを配置した場合、config.yamlでのモジュール（Tags.pm/CMS.pm）の記述は次のように行います。Tags.pmには
_hdlr_fooと_hdlr_barというメソッド、CMS.pmには_add_fieldと_set_paramというメソッドがあると仮定します。

…前略…
tags:
    block:
        MTFooLoop: $MyPlugin::MyPlugin::Tags::_hdlr_foo
    function:
        MTFooName: $MyPlugin::MyPlugin::Tags::_hdlr_bar
callbacks:
    MT::App::CMS::template_source.edit_entry: $MyPlugin::MyPlugin::CMS::_add_field
    MT::App::CMS::template_param.edit_entry: $MyPlugin::MyPlugin::CMS::_set_param

それぞれのハッシュの右辺にある「$MyPlugin::MyPlugin::Tags::_hdlr_foo」というフォーマットは、「$+プラグイン名::lib配下のプラグインディレクトリ名::モジュール名::メソッド名」になります。

この部分の定義が実際のディレクトリ・ファイル配置やモジュールの先頭に記述したパッケージ名と異なっていると正常に動作しません。大文字・小文字の違いも動作しない原因となります。

６．YAML形式での開発について

YAML形式のプラグイン定義の弱点は、エラーが発生するとPerlでの定義よりも原因が分かりにくい点ですが、５項の設定がきちんと行えていればその事象に遭遇することはないと思います。

よって、YAML形式のプラグイン定義でプラグインを開発する場合、既存の配布プラグインで自分が作りたいタイプ（拡張テンプレートタグやコールバックなど）に近いものを選び、ファイル名やパッケージ名・メソッド名だけを書き換えてファイル構成は流用する方法をお勧めします。モジュール内のPerlエラーについては、YAMLもPerlも特に違いはなく、システムログにメッセージが出力されます。

当ブログで公開している最近のプラグインは以下のリンクから利用してください。