HikiDoc を使った WEB アプリケーション (4) #

UI について #

リアルタイムプレビューについて。現状こんな感じ なんだが、サーバ側で Hiki書式→HTML 変換してる以上、リアルタイムはつらいよなぁ。HikiDoc.js ですか？　やっぱり。

となると、時間があって気が向いた時に、って感じだな。

HikiDoc.pm について #

Plugin #

HikiDoc.pm は、本家 HikiDoc に倣い、plugin 部分の処理は行っていない。Hiki ではどのように実装しているのか、要調査

link #

例えば

[[ほげ]]

と記述すると、

<a href="ほげ">ほげ</a>

と変換される。アプリケーションで利用するなら

 <a href="/appuri/%A4%DB%A4%B2">ほげ</a>

みたいになって欲しい。これも Hiki でどう実装しているのか、要調査

調査していない現時点では、

• plugin は、_restore_plugin_block で ほげほげするように、HikiDoc::Plugin 作るかなぁ
• link は、level とか empty_element_suffix みたいに prefix_uri とか渡せるようにするかなぁ。それだと uriencode されないけど、そこはプラグインで対応

と考え中。

と、ここまで書いて、プラグインには「プラグイン記法で記述するもの」と「HikiDoc 自体の機能を変更するもの」があることに気づいた。上の方で書いた「plugin」は前者で、「link」は後者ですな。さてどうするか。

つうわけで、Hiki のコード読みます。

。。。読んだ。考えた。まず考えないといけないのは「そのプラグインは HikiDoc のプラグインなのか、アプリケーションのプラグインなのか」ということ。今自分が考えているものは、アプリケーションのプラグインであろう。つまり、アプリケーションの中で HikiDoc 以外の Parser を利用した場合も有効でなければならない。

つうわけで、プラグインは、冗長だが、いったん Parser 通したテキストをもう一回アプリケーションの側で処理することで対応に決定

リンクの方は、HikiDoc 自体に機能としてあっても悪くないよなぁ。href タグ自体は HikiDoc がつけるわけだし。名前は link_uri_prefix と urlencode くらいでいいかな？