assets問題への対応 - s

Plaggerのassets周りでの

について。

現状では大雑把に分けると、assetsは次の2種類に分けられています。

Publish,Notify等のtt(テンプレート)
Filter,Widget等のyamlやpl(設定やPerlコード)

自分としては、分類方法は上のリストのテンプレートとyaml,plで分類するのがいいと思います。

理由としては、

テンプレートは一度決めたらほとんど変更しない(もしくは、用意されたものから変更することがない)
yamlやplは積極的に新しいものを取り入れたい。

からです。これについては自分だけでなく、他の人も同じではないかと。

で、処理の仕方ですが、

ttはyamlでttを指定できる*1ようにして、もし、templateを指定していない場合はpm内の__DATA__を使用する様にする。

 plugins:

   - module: Publish::Gmail

     template: /edit/template/path/file.tt

これであれば、カスタマイズしたテンプレートを使用することも出来るし、デフォルトも用意できるので事前にファイを用意することも不要になると。

yamlとplについては、Filter::Fooごとにひとつのファイルにまとめてしまい、@INCにインストールしてしまうのが手っ取り早いでしょう。ひとつのファイルへのまとめ方としては、リリースのタイミングを活用してrelease.plで、phpのserializeみたいに読み込んだオブジェクトをダンプしておくのがいいかと。ファイル数が減れば鬱陶しさと読込みスピードが軽減するかと思います。

そのうえで、前述のyamlでtemplateを指定するみたいに、

 plugins:

   - module: Filter::EntryFullText

     asset: /edit/asset/path

assetパスを指定できるようにする。globalでのassetsパス指定も有効にしておけば、流れは

@INCにあるダンプされたデータを読込み。
assetsパスがあればそれを読込み(svnユーザー向け)
プラグインの項目にassetがあればそれを読込み

となって、assetsをコピーすることを知らない層、SVNで追いかけるTrunk層、全て自分で管理したいcustomize層の全てに対応できると思います。

これで、パッケージ管理でインストールする人たちは何も考えずに、@INCにインストールされたassetsを使用することが出来るのではないかと思います。

*1:planet.yamlでthemeを指定できるように