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で書き直しました。
- ユーザ認証を経てログインさせています。
- これは、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一般に適用できる
情報をまとめてゆくことにします。
Last modified : 2003/07/04 15:13:19 UTC