WikiParserの最近のブログ記事

こないだ決めた呼び出し側の仕様を変更。

    WikiParser parser = WikiParser.getParser();
    WikiNode node = parser.parse("あいうえお");
    out.print(node.toString());

なんとなく、外部インターフェイス的にはこちらの方が自然な気がして。（プロジェクト名も WikiParser だし。。。）
またすぐ元に戻すかもしれないけど。

今回の目標であった「"\n\nあいうえお\nかきくけこ\n\n" を渡して "<p>あいうえお<br>かきくけこ</p>" を取得」はさらっと実装完了。

ここまではさらっと実装でいいんだけど、これから先の構文解析をどのように実装するかが問題。
以前のプロトタイプでは、正規表現でガシガシ分割、処理用のnodeを生成、委譲、と言う方針だったので、ソースはかな～りぐちゃぐちゃ。
拡張性も柔軟性もくそもない感じだったんだけど、今回はそうならないように良く考えなくては。

例によってデザパタ本をパラパラとめくってみて、今後使いそうなパターンをピックアップ。

• 構文解析に Chain of Responsibilityパターン
• 解析結果の出力に Visitorパターン

まだよく読んでみないと分からないけど、構文解析の時には

1. 次の部分を処理するのはどなた？
2. PreserveNode : 私じゃないよ
3. BlockquoteNode : 僕じゃないよ
4. ParagraphNode : じゃー、私が処理します。

みたいな流れで処理させればスッキリ書けそう。

出力は今は Object#toString() をオーバーライドして使ってるけど、Visitorを各自実装してもらうことで様々なフォーマットで出力ができるようになる気がするです。
この辺をAPIとしてしっかり仕様決めしてあげれば出力が柔軟になるかな？
＃とうぶんは toString() でしょうけど。。。(^_^;;

この２つを組み合わせることの問題は、Visitorが訪問する相手（構文解析を誰が行ったか？）を覚えておかなければならない、もしくは適切に訪問できるよう導いてあげないといけないこと、かな。
この部分を考えるとあんまりうまくいきそうな気がしない。。。

とりあえず次回、ちょろっとやってみますかね～。
でわまた～～。

これをつけるのが今日からということで。
かれこれ２～３ヶ月前にプロトタイプを構築して今日に至る（その間放置）わけですが、あの経験を生かして、再度構築していこうと思います。

まずは、最も基本的な呼び出しをどのようにするか？をここ数日間考えていたわけですが、やっぱし不正なクラス呼び出しなどをさせないよう、AbstractFactoryパターンで詳細情報を隠蔽化するのがいいかなと思うので、その部分を作ってみました。
結城浩さんのデザパタ本を片手に、奮闘して、これまであまりようとの分からなかったこのパターンに「なるほど！」と相槌を打ちながら進みました。

とりあえず "あいうえお" の文字列を渡したら "<p>あいうえお</p>" を取得できるように。

こんな感じ。

    WikiNodeFactory factory = WikiNodeFactory.getFactory();
    WikiNode node = factory.getWikiNode();
    node.parse("あいうえお");
    out.print(node.toString());

結果：
    <p>あいうえお</p>

次の目標は "\n\nあいうえお\nかきくけこ\n\n" を渡して "<p>あいうえお<br>かきくけこ</p>" を取得することでしょうか。

というわけでまた～～。

今日から、WikiParser(仮) の構築日記をつけてみようかなと思います。

WikiParser(仮) とは？
世の中にたくさん存在する Wikiクローンですが、HTMLより遥かに単純な構造をした文書を作成するだけで、とてもキレイなHTMLとして出力ができて便利なことは言うまでもありません。
そのエントリーを解析してHTMLとして出力するエンジン部分のみを構築、配布することで、いろいろなところで「お手軽作成、きちんと体裁」が実現できればなと思っています。

これができたときには、この MovableType のエントリーをWiki形式で書いて WikiParser(仮) でHTML化することで、エントリーを書く気を萎えさせないようにしたいです。
Javaで構築しようと思っているので、もう一工夫必要ですが。

この WikiParser(仮) の目標。
・設定ファイルを利用することで、整形ルールを柔軟にしたい。
・APIを提供することで、プラグインを追加できるようにしたい。
・出力をHTML以外にも対応したい。

それでは、公開までこぎつけるか、僕が飽きるまでの間、お付き合いくださいませ。