Naoki Takezoe
ADS28****@nifty*****
2003年 7月 15日 (火) 11:58:53 JST
Fork竹添です。パーサのリニューアルについてです。
皆さんもご存知かと思いますが、パーサの解析は現在、行書式解析→
インライン書式解析という２段階の構成になっています。
で、パーサ内部でパース結果のオブジェクト（HTMLパーサの場合は
HTML文字列ですが）を溜め込んでいくという感じになっています。
ここで問題になるのは現在、プラグインはいわゆるHTML的に「パラ
グラフ」になるものがインラインで書けてしまうということです。
つまり、インライン書式の解析部で検出されたプラグインから行書式
の出力が返される場合があるということです。
これを解決しないと少なくともPDFへの反映がうまくいきません。
案としては以下の２つが考えられます。
1.行書式プラグインとインラインプラグインを区別する
たとえば以下のような感じで書式自体を変えてしまう
{{{行書式プラグイン}}}
{{インラインプラグイン}}
2.行書式プラグインは強制的にパラグラフとみなす
{{行書式プラグイン}}ここは次の段落
どちらにしてもパーサ側でそのプラグインはインライン形式なのか
行書式形式なのかを判別するためにプラグインに例えば
$obj->is_inline();
などのようなメソッドを用意しておくか、Install.pmでのインス
トール時に明示するなどする必要があります。
また、生成部分ですが、実装方法としては大きく分けて以下の２つが
考えられると思います。
1.パーサで全て溜め込んでから一気に生成
2.パーサから逐次生成器のメソッドを呼ぶ
プラグインから生成器を叩くのであれば、２の方法になりますし、
パース結果オブジェクトを返却するような仕様であれば１になります。
今のところシンプルさやパフォーマンスを考えると２のほうがいい
かなと思います。
Wiki形式のテキストを返すプラグインの場合は、パーサのインスタン
スを別に生成して処理するというような感じになるでしょうか。
これはあくまでいまのところぼんやりと考えていることですが、
パーサの改造は3.5で行おうと思っていますので、ツッコミお願い
します。
> 好みはさておき、PDF対応、他のwikiフォーマット対応やサニタイジングを考えると、
> そろそろパーサの設計を見直す時期かもしれません。
>
> 以下思い付いたところで、
> ・今のパーサを、構文解析・分離分割を行う本当の意味でパース主体の部分と、
> htmlやPDF生成の部分に分る。
> ・プラグインは両者の間に入るドライバ的存在で、生成側のインターフェースを使ったり、
> パース側にもう一度わたしたりして出力を構成する。
> てな所ですが、大手術になりそう...
----
Naoki Takezoe <ADS28****@nifty*****>