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 くらいでいいかな?