読者です 読者をやめる 読者になる 読者になる

高見知英のかいはつにっし(β)

高見知英のアプリケーション開発日誌 のほか、地域活動などの活動報告ブログ。

Site System

現在考案中の独自CMS、Site System。開発日誌と言うことだし、今日考えたことについて書いてみようと思います。
なお、進行中の云々については、PB*1あたりにも書いていますので、まずはご覧ください。

まあ、結果的にあまり報われなかった気はしますが、せっかく導入したNucleusなどを参考に。悪い部分を省いて、ほかの良さそうな要素を取り入れて という感じになるかな と思っています。

  • 多階層ディレクトリによる記事管理
  • 定数の概念。文字列を展開したり、キーワードのようにリンクさせたり(NucleusznKeywordLinkあたりと同等)といった機能
  • クリエイタ(ファイルタイプ)の指定。必要最低限の項目入力から記事を作れるようにする。

というのが柱かな?

クリエイタというのは、まあ、あちらにも書いてあるとおりMacの同名システムのようなもので、Perlスクリプトのクラスを使います。

  • 記事は、どのようなフィールド(設定)をどのようなタイプ*2で保持するのかを指定。
  • 記事は、どのようなテンプレートにより展開されるのか。
  • テンプレート展開時の、変数の登録処理
  • ほかのCGIとの連携*3

ということをすることになるかな と。


しかし、ここからが問題です。記事にどのようにそれら設定を保存させるのか。
いちおう現在考えているのは以下のように、データベース上に一般記事テーブルとクリエイタごとのテーブルを作り、双方をつなげて使うというもの。

一般記事テーブル 記事名 概要 日付
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との連携を推したいと思います。

*1:Programming Background。 早くも略記で済みませんm(__)m

*2:数値なのか、ファイル名なのか などというふうに

*3:ほかのCGIからサイトの任意の部品を取得するなど

*4:たとえば、あるクリエイタを持っているものすべて表示 といったように。Webサイトを作る専用のものだから、そもそもそんなことまでは考えなくて良いのか?