現在考案中の独自CMS、Site System。開発日誌と言うことだし、今日考えたことについて書いてみようと思います。
なお、進行中の云々については、PB*1あたりにも書いていますので、まずはご覧ください。
まあ、結果的にあまり報われなかった気はしますが、せっかく導入したNucleusなどを参考に。悪い部分を省いて、ほかの良さそうな要素を取り入れて という感じになるかな と思っています。
- 多階層ディレクトリによる記事管理
- 定数の概念。文字列を展開したり、キーワードのようにリンクさせたり(NucleusのznKeywordLinkあたりと同等)といった機能
- クリエイタ(ファイルタイプ)の指定。必要最低限の項目入力から記事を作れるようにする。
というのが柱かな？
クリエイタというのは、まあ、あちらにも書いてあるとおりMacの同名システムのようなもので、Perlスクリプトのクラスを使います。
ということをすることになるかな と。
しかし、ここからが問題です。記事にどのようにそれら設定を保存させるのか。
いちおう現在考えているのは以下のように、データベース上に一般記事テーブルとクリエイタごとのテーブルを作り、双方をつなげて使うというもの。
| 一般記事テーブル | 記事名 | 概要 | 日付 |
|---|---|---|---|
| 1 | ソフトの記事 | ソフトの紹介とダウンロード | 2006-04-09 |
| 2 | 音楽の記事 | 音楽掲載 | 2006-04-10 |
| ソフト用テーブル | 記事ID(外部キー) | バージョン | VectorID |
|---|---|---|---|
| 1 | 1 | 1.0 | ・・・ |
| 音楽記事テーブル | 記事ID(外部キー) | 自信 | ジャンル |
|---|---|---|---|
| 1 | 2 | 1 | Xmas |
…というような感じで作っておいて、あとでSQLのSELECT文でくっつける…と。
しかし、一つのディレクトリに多くのクリエイタの記事があると、SQL文がとても煩雑になってしまいますし、出力されるテーブルのサイズもかなりすごいものになりそうです。
ここで、別の案もあります。データベースを使うのをはじめからあきらめ、INIファイルなどのような形式で設定を保存するというもの。そうすれば、1行ごとに保持する要素数が変わったり、内容が変わったりしても問題ありませんしね。
Wikiを使ってみたところ、あっちはデータベースなんか使わずにすべてファイル操作でやっているようだし、上手く使えば同じくらいの早さは出るかもしれない…。
ただ、記事の移動やコピーなどの操作がやっかいそうです。
また、データベースじゃないので、別の側面*4から集計して一覧表示…といったことがやりづらい。
うーん、迷っています。これはまた来週まで続くかな。
それと、たいした話ではないですが、やっぱりトップページ(扉ページ)は欲しいかもですね。もちろん扉ページにも主要ページのリンクの中の状態表示など、配慮はすべきですが、やっぱり扉ページがないとブログっぽくなっちゃうな…というのが、Nucleusをつかったサイトを見たときの感想です。
そのためにもほかのCGIとの連携を推したいと思います。
