WiLiKi:アプリケーション
WiLiKiをwebアプリケーションのコンポーネントとして使ってみる試み…になるか? Makotoから移動。
要求仕様
ちと要求が多いので、1つずつやってみようのコーナー。
- WiLiKiのページをPDFで吐き出す。
- Schematicsのscm-pdfができるのを待つ?
- wiliki.formatをコピーして手続きをSXMLを吐かせ、それをPDFに変換する。
- WiLiKiのフォーマット要素を網羅するDTDを考える、ってそれはHTMLじゃん。
- WiLiKiはHTMLを吐くのだから、それをXHTMLを吐くようにして、XSLTをかましてPDFまで 持っていく。
最初の動機
現実
- 親サイトのデザインがリニューアルされるとのことで、急遽(2週間ほどしかない) デザインを入れ替えることになった。ついでに、eRubyを使っていたのをGaucheのCGIに 書き換えることにした。今まで、Perl->Ruby->Tcl(Rivet)->eRubyと書き換えてきたが、 書き換えるたびによりシンプルにリファクタリング&リストラクチャリングできてきたので、 今回も。
- で、下のようにWiLiKiをカスタマイズしてやりたかったのだが、とりあえず単なる Schemeということでやってみることに。少しやってみたところ、WiLiKiのどういう部分が 使えそうか、なんとなくイメージできつつあるので、固まったらここでの議論を進める予定。
- とりあえず、今やっていることはこちらへ。
当初の考え
- 今運用しているサイトをWiLiKiベースで書き換えたいと思っています。しかし、
WiLiKiがバージョンアップしたら、WiLiKi部分は通常の手法(インストール)で
バージョンアップできたいです。そういう場合は、自分のソースとWiLiKiのプログラムは
どのように連携させたら良いのでしょうか? 他にもいろいろソリューションはあると
思いますが、ぜひともWiLiKiを使いたいと思っています。
- そのサイトの機能は、全然たいしたことありません。
- 基本的にニュース配信サイトです。
- 今は、Apache Rivet(aka. mod_dtcl) + MySQLです。MySQLのレコードは、現在
約8,000件で、毎週20件くらい増えます。==> Apache2にしたので、Rubyで書き直しました。
- この程度なら、gdbmで扱えると思っています。
- ユーザ認証を経てログインさせています。
- これは、WiLiKiとは特に関係ないですね。==> wiliki.cgiに実装すればいいのか。
- トップページでは、新着記事のタイトルを一覧しています。
- トップページのタイトルリンクからそれぞれの記事へ飛びます。
- 簡単な検索機能を付けてあります。
- これは、WiLiKiの検索機能を使うか、静的に吐き出したページをNamazuで検索 させるかする予定です。
- ローカルのデータベースで記事を作って、一旦テキストに保存してサイトにアップ
ロードし、サイトには、それをデータベースに吸い込むスクリプトを置いています。
なぜ、ローカルではデータベースを使っているかというと、そのデータベースソフトの
レポート印刷機能を使いたいからです。
- 印刷については、WiLiKiデータ-->SXML-->LaTeX-->PDFを考えています。
- 記事は、Wikiのようにオンサイトで書き込みができるようにしたい。
- そのサイトの機能は、全然たいしたことありません。
WiLiKiを独自拡張するには
Shiro (2003/04/03 19:33:42 PST): 基本的には、WiLiKi本体はモジュールになっているので、 自分のアプリケーションから (use wiliki) しておけば、 WiLiKiを再インストールしても自分のアプリを書き換えずに済みます。
しかし、現在のwilikiモジュールからexportされているのは <wiliki>クラスとwiliki-mainのみなんで、ちょっとコンポーネントとしては 使いづらいですね。今コードを見直して、DBインタフェース部分や HTML生成部などをサブモジュールに分割しようとしているところです。
それまでは、(use wiliki) のかわりに (extend wiliki) として 下さい。すると、exportされていない内部手続きも自分のソースから 使えるようになります。但し内部手続きのAPIは将来のバージョンアップで 変更される可能性が多いにあるので、そのへん微妙に注意しつつ使って下さい。 (特に、次のバージョンで内部が色々変わるかもしれません)。
- Makoto (2003/04/06 17:36:18 PDT): (extend wiliki)した場合、wiliki.scmで定義されている手続きと同じ名前の手続きを 実装したら上書きされますか?例えば、wiliki.cgiで、(extend wiliki)として、 format-footerなどを定義しても、wiliki.scm内のformat-footerが実行されていると 思うのですが。
- Shiro (2003/04/06 17:50:00 PDT): 'define' は常にカレントモジュールに束縛を挿入します。 したがって、カレントモジュールからの参照は新たに定義された手続きを見るように なりますが、既にあるモジュール(例えばwiliki)内での参照は変わりません。 どうしてもwilikiモジュール内の束縛を上書きしたいのなら、次のようにします。
(with-module wiliki (define format-footer ....))
- これはもちろん、既にあるモジュールを改造してるわけなんで、
at your own riskで使って下さい。
- Makoto (2003/04/06 19:00:49 PDT): できました。というのは、WiLiKiをコンポーネントとして 使うだけでなく、一部改造する必要が出て来ると思いましたので。どうやってこれらを 切り分けるかで迷ったら(迷うと思うので)、また相談させて下さい。
内部手続きが全部見えちゃうのが気持悪いというなら、自分のソース内で 次のように書けば無理矢理一部の手続きだけexportさせてしまうことができます。
(with-module wiliki (export format-page <page>))
これも場当たり的な手段ですが、とりあえずいじってみる時には便利かと。
色々やってみて、「wilikiのこの手続きは外から使いたい」とか、 「この手続きはこうなってると応用が効く」とかあったら教えて頂ければ、 wiliki本体を合わせてゆきます。
WiLiKiのサービスレイヤについて
WiLiKiは内部では次のような階層構造で構成されています。 一部の階層だけを利用することでWiLiKiのコンポーネント的な利用が 出来るかもしれません。いくつかアイディアを書いてみます。
- cgi要求処理レイヤ : cmd-* 手続き群
- wiki記法→HTML変換レイヤ : format-* 手続き群
- ページ情報 : <page> クラスとその手続き
- データベースインタフェース : wdb-* 手続き群
データベースの差し替え
WiLiKiはデフォルトでgdbmを使うようになっていますが、 <dbm>のインタフェースを実装したクラスを用意すれば <wiliki>のコンストラクタにそのクラスを渡すだけで差し替えが可能です。 (但し、データベースの排他制御はメソッド内で行われることを 前提にしているので、<odbm>や<ndbm>だと不十分です)。
例えばMySQLとのブリッジを実装して、<dbm>抽象クラスのインタフェース メソッドを定義してやればMySQLをバックエンドに出来る…はずです。
また、バックエンドのデータベースに効率良い検索インタフェースが ある場合などは、wdb-* メソッドを定義しても良いでしょう。
wiki記法→HTML変換の利用
データを<page>クラスに合わせて用意してやればformat-*系のルーチンが 呼べるでしょう (マクロやWikiNameのフォーマッティング時にデータベース アクセスルーチンが呼ばれますが)。
<page>に余分な属性をつけたい場合は、<page>を継承したクラスを 作って、あとwdb-put!を定義してやる必要があるかな。 ここはpage->attribute-listみたいなメソッドをかましてやる方が良いかも。
- Makoto (2003/04/03 22:41:14 PST): ありがとうございます。個人的なサイトの構築については、 自分のサイトでメモっていきます。こちらには、 役に立ちそうなものをアップするようにします。(6ヶ月くらいの長期プロジェクトとして 考えてます。しかも、思いついたばっかし。 (^^); )
- Shiro (2003/04/04 00:02:33 PST) : 了解。こちらではWiLiKi一般に適用できる 情報をまとめてゆくことにします。