HikiDoc Archive

今日はあんましやる気がなかったんだが、ちょっとくらいはやっとこうと思って、tDiary のテーマとの互換性だけ検討しておいた。

。。。ひょっとすると、tDiary 利用再開すればいいだけなんじゃなかろうか？

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

meta tag の Keywords について。

• ページ毎に設定できればうれしいかもしれないが、面倒だ
• タグ（この記事でいうと [Perl] と [HikiDoc]) をそのまま利用するのは、お手軽でよいかもしれない
• タグクラウドの上位 10 番までを利用するとかでもいいかもしれない

設定について
一つの場所に複数名ログインするわけではなくて、たとえば ASPタイプの Blog サービスとか、http://www.tdiary.net/ みたいなレンタル日記サービスとか、そういう使い方について考えてみる

設定は

1. アプリケーションインストール直後のデフォルト設定
2. システム管理者が行う、システム共通の設定
3. ユーザが個別に行う、ユーザ別設定

があって、それぞれ上位を有効にしたい場合と下位で上書きしたい場合とがあって、ややこしそうだ

lib/Hoge/Plugin/Fuga.pm

を設置して、

• Hoge::Plugin::Fuga::do_action … runmode = Fuga の時実行
• Hoge::Plugin::Fuga::do_string … {{fuga}} を HTML に変換

とかでどうだろう？

以前作った時、do_loop とか用意してループ用だけ別にしてた記憶があるんだが、なんでそんなことしたんだっけ？　TT のループの中でなんかしてたんやったかな？

HikiDoc.pm r1_006 を公開しました。フルパッケージは「B's Soft」のコーナーにおいてあります。

変更点：一行に二つ以上リンクが含まれるとき、最初の一個しか parse していなかった bug を修整

。。。しまった。ついでに Text::HikiDoc にしておけばよかった。。。

HikiDoc を使った WEB アプリケーションを作ろう作ろうと思いながら遅々として進まないので、思いついたことをちょっとづつ書きためていく

• Wiki のようにいろんな人が使うアプリケーションではなくて、自分だけが使うツールのイメージ。日記サイト作りツールになるかな？　まだわからん
• HTML 化した内容はキャッシュしておく。記事作成／編集時のみ、HTML 変換が行われる
• plugin で実装するものは、plugin 毎にキャッシュするかどうかを決める
• HikiDoc 形式以外も使えるようにするが、内部的に HikiDoc 形式への変換は行わない。一度ある書式で記述した記事は、編集時には常にその書式を利用する。
  • こうすることで、他エンジンをそのまま使えるようになり、他のエンジン使いたくなった時に導入しやすそうな気がする。過去の記事を編集したい時って、せいぜい文字修正くらいだろうから、問題にはならないでしょ、きっと。すごく修正したい時は、あらためて別のページを作るってことで
  • Wiki 書式を使わず、HTML 直書きもできるようにしようかな。その場合は Wiki 書式保存をせず、キャッシュの部分を直接編集する
• 長い文章を書く時はパート編集機能があると大変便利だが、記事自体をパート単位で作り、表示する時にパートを組み合わせて 1 ページにするというアプローチもあると思うので、自分が何に使いたいのか用途を考えて決めていこう
• 認証系はアプリケーションで実装したくないんだが、さて、どうするかな

自分が今欲しいツールは

• このサイトを作るツール
• レポートを書くツール

で、どちらに重きを置くかで色々変わってきそうだな。まぁ、考えているうちが楽しいので、のんびりやろう。

HikiDoc ではなくて、Perl 的には Text::HikiDoc とかの方がいいんではないかと思った。いや、何となく。今ならまだ間に合うなぁ、きっと。

上に書いたように xmlHttpRequest 投げるとすると、onkeyup で一文字毎に送信すると、結構壮大にリクエストし続けることになるので、ちょっとWait かまさんとまずいかもしれない。で、そのためにこんなことをしてみる。

   <script language="javascript" type="text/javascript">
     function countNum() {
       var n = 1;
       return function() {
         return n++;
       };
     };
     function updateHTML() {
       if ( c() % 10 == 0 )
         document.getElementById('out_html').innerHTML = document.getElementById('in_text').value;
     };
     var c = countNum();
   </script>
   <div id="out_html"></div>
   <form action="post">
     <textarea name="in_text" id="in_text" cols="80" rows="20" onkeyup="updateHTML();"></textarea>
   </form>

これで 1/10 になった。。。というような単純なことを、努めて日記に書き残すようにしよう、と思った。

。。。とか大げさなことを書いてるが、もっとも単純と思われるサンプルを見てもらうのが一番かな

   <script language="javascript" type="text/javascript">
     function updateHTML() {
       document.getElementById('out_html').innerHTML = document.getElementById('in_text').value;
     };
   </script>
   <div id="out_html"></div>
   <form action="post">
     <textarea name="in_text" id="in_text" cols="80" rows="20" onkeyup="updateHTML();"></textarea>
   </form>

動作サンプル

まぁ、アプリケーションにするにはもっといろんなことをしないといけないわけだが、この例のように

HTML を入力→ブラウザで即レンダリング

ではなくて、

HikiDoc 書式で入力 → xmlHttpRequest → サーバで HTML に変換 → ブラウザに表示

とやれば使いやすくなるかなぁ、と。