Mar 14, 2006

Re: MovableType Mapperプラグインと locationプラグインの融合キボンヌ

何となく予想できた方面から万艦飾なリクエストが来ました(笑)。

ここギコ!: MovableType Mapperプラグインとlocationプラグインの融合キボンヌ

私も同じようなことを考えていました。ついでに言うとオレオレトラックバックサーバにしかトラックバックできないようにし、相互リンクでオレオレアクセス数を稼ぎ、広告収入をがっぽがっぽ...とかいきたいところなんですが...嘘です。

私なりに整理してみると、(1)ロケーション情報の入力源の充実、(2)ロケーション情報へのアクセスメソッドの提供、(3)トラックバックの実現、の3点があります。で、私の考えでは別のプラグインとしてこれらの機能を提供するのでもよいかな、というところです。

この別プラグインでは、まずエントリーやエントリーに添付された画像ファイルに記述されたロケーション情報をエントリー保存(公開)時にextractして、中間ストレージに保存します。トラックバックなどのNotification系のアクションは基本的に同じタイミングで行います*1。トラックバックの送信の有無をコントロールしたければ、ロケーションデータにトラックバックURLを関連付けておいて(その情報も中間ストレージに保存してもよい)、後で送信するという方法にする必要があるかもしれませんけどね。

*1 ところでAlps Clip!のMTプラグインは、グローバルフィルタ適用時、すなわち再構築時(≒ビューの生成時)にトラックバックを送信しますが、あまり良くないような気も。再構築するたびにトラックバックを送信する、悪魔のプラグイン...。Alps Baseの方ではURLでユニフィケーションしてトラックバックを捨てたりしているのでしょうか。MT::Entry::post_save()などのフックを利用された方がよいでしょう。

一方で、中間ストレージに格納されたロケーション情報へのアクセスメソッドもコンテナタグや変数タグとしてテンプレートから利用できるようにします。こちらは再構築時にテンプレートの記述にしたがって処理されるものとします。こっちのアクションは、Notificationとは異なり、中間ストレージへのアクセスだけで実現できます。

そうすると、Mapper Pluginの実現する変換処理は、このプラグインが管理する中間ストレージへのアクセスできさえすれば、コンテナタグやグローバルフィルタとして実現できてしまうので、独立したプラグイン(あるいはプラグインのサブのサブ機能くらい)でもいいかな、と。

さて、ねねさんのエントリーでは(1)~(3)に加えて、テンプレートでの制御(=プログラミング)のアイディアが提示されています。これは面白いのですが、ここはConcernをseparateすべき部分だと思っています。

テンプレートはエントリー保存時に参照されるものではなく、再構築時(≒ビュー生成時)に参照されるものです。言い換えると、エントリー保存時のアクションをテンプレートに書くべきではありません。これを厳密に守るならエントリーにプログラム記述する方がむしろ筋が良いわけで、例えば、Alps Clip!では、mapタグとmap_tbタグがあるおかげで、ユーザがエントリー内で処理をプログラムできているんだぜという言い方もできます。とは言え、これ以上に複雑な制御をエントリーに書かせるのは無理があるのは確かです。オルタナティブとしては、プラグインの設定画面のフォーム上でトラックバックの上位プロトコルをプログラムできるようにするとよいかも...と思います。

あと、ロケーション情報のストレージとアクセスメソッドはRightFieldsにオフロードしてしまうのととても簡単なのですが、そうすると導入時障壁が高くなってしまうのが悩みでもあります。Tagwire PluginのときにPluginDataを使ってネチネチ書いたのは(まったくもって苦痛な作業でしたが)、この点を当初重視していたためなのです。が、結果として速度やダイナミックパブリッシングからの可用性を犠牲にしてしまいました。Tim Appnelも以前mt-dev : MovableType Plugin Developersあたりで何か叫んでいましたが、本当はMovable Typeがユーザ定義のオブジェクトを管理する機能を持っていればいいんですけれど。

ここギコ!: Re^2: MovableType Mapperプラグインとlocationプラグインの融合キボンヌ

中間ストレージに吐いておくのは、後で別用途でソートしたりする際にも軽くなるので、よいかなと思いました。 ただMovableTypeって、中間ストレージをプラグイン等で自由に作れる公式仕様ってあるんでしたでしょうか。 なかったので今までkeyword属性をいろんな用途に使いまわしたり、RightFieldsとかが画期的だったりしたのかなと思ったのです。

Movable Typeが提供している機能としては、MT::PluginDataがあります。Storableなどを使ってシリアライズしたデータをBLOBとしてDBにストアするという単純なものです。本来はプラグインのconfigurationを保存しておく目的のものですが、事実上いかなる用途にも使えます。細かい話をすれば、MT 3.1と3.2ではシリアライザの仕様が違っていてプラグイン開発者泣かせです。

RightFieldsやTags.AppなどのようにDB上に自前のテーブルを作成することも当然できます。前者はmt_entryテーブルを拡張する任意のテーブルを定義できますが、1エントリーに1レコードしか対応付けられないという制約があります。後者はタグ用のテーブルを定義し、1エントリーに複数のレコードを関連付けられます(がもちろんタグしか格納できません)。彼らが「勇者」たる所以は、「たかが一プラグインのためにここまでするのか」という点に尽きます。

Six Apartでは、開発者コミュニティで不満の出ていた、プラグインのブートストラップ周りを弄っているようですし、ユーザ定義の永続オブジェクトもサポートしてくれるんじゃなかろうかと思っています。それまではあまり深入りしたくない気もしますけどね。

作成のフック利用でもいいと思うんですが、エントリ作成でなく更新時に新しい位置情報入れたりするケースもあると思うので、Entryオブジェクトのpinged_urlに突っ込んじゃってもいいと思います。

MT::Entry::{pre,post}_save()は新規作成に限らず、エントリー保存時に呼び出されるフックなので、そのタイミングでto_ping_urlに突っ込めばMTのトラックバック送信機能を使ってトラックバックを打つことができます。Alps Clip!のようにプラグインが自前で送信してもよいですし。また、pinged_urlをチェックして重複トラックバックを検査するというアイディアは、別の単体プラグインのアイディアとしても悪くないなと思いました。

そうではなくて、トラックバックは保存時の処理であって、エントリ再構築の中で行うべき処理ではないという意味の事であれば、個人的には所定の機能が得られればどちらでもよいのかなあと思います。

しかし、ダイナミックパブリッシングの時には再構築自体行われないのです。ですから、ビューを生成する作業を再構築時もしくはダイナミックパブリッシングによるページ生成時に行い、それ以外の作業を保存時に行う必要があります。


作るべきものはだんだん明確になってきたのですが、全然時間が取れません。地下鉄プログラミングを再開しなくては!!

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com