【楽をしてサイト構築をするためのウンチクノート】
第5回
ツリー構造
CMSには想定がある。オールグラウンドで活躍できるCMSがあったとしても、どこかで想定されたステートメントがあります。では、どうして想定があるのか。ここでは、そこからCMSにしかけられたトラップを考えていきましょう。
静的コンテンツの管理=依存性の明確化
最初にも述べましたが、静的なコンテンツを生む場合、生み出されるファイルの依存性は無視できない問題です。無視すれば、更新していない個所が発生するからです。そのために、あるファイルを変更したとき、どこのファイルを変更する必要があるかという依存関係をただしく把握している必要があります。さもなければ、更新の必要もないファイルを更新することになりかねません。しかし、どれだけ多くのウェブマスタ(マネージャ、オペレータ)がその依存関係を正確に狂いなく把握できているでしょうか。やはり、依存関係は自動的に行いたいものです。そこで、依存関係のベクトルをあらかじめ決めてしまうという手段があります。これは、非常に有効な手段です。しかし、第3回で私はそれでは自由がなくなるといいました。これは矛盾しないでしょうか。
たしかに矛盾します。しかし、コンピュータはユーザの心が読めません。人でも察するのは難しいのですから、(人間が作り出した)機械が読めるわけがありません。そこで、あるファイルがどこのファイルに依存しているのかをあらかじめ決めてしまうとどうなるでしょう。確かに自由は減りますが、ユーザとのコミュニケートが十分に取れるようになります。ここがポイントです。たとえば、あなたの友達とアニメ番組の感想を言い合えるのは、お互いに同じその番組を見ていたからですよね。
依存性=多分木(ツリー)
図1 ツリー構造で依存
多くの場合、ツリー構造を利用しているのはこのためなのです。ここでツリーの親子関係を依存関係とします。ただし、子の親はひとつだけ(唯一の親)とします。親はいくつ子を持っていてもかまいません。また、子の場所は適時その直系の代に限り移動できます(つまり、子が孫になることが可能)。
すると、図1 の場合、ページA2 は ページA1 の子と サブトップA の孫に(おそらくリンクが原因で)あたりますので、ページA2 を変更すると、親のページA1 とその親の サブトップA の更新が必要ということがわかります。また、サブトップ は トップページ の親ですので更新の必要があります。これは聞くとあたりまえですが、非常に画期的なことです。なぜなら、親戚にあたるものは依存関係を持ちません。ツリーの親子関係で依存関係を示しているからです。これは、もっとも美しく人間にもわかりやすい表現方法だと思いませんか。少なくとも、メッシュ構造なんかよりはとてもきれいですよ。
ツリーの崩壊は充実したとき
ところが、このすばらしい画期的な方法には落とし穴が存在します。それは、ツリー構造を深くされると更新するファイルも増加するということです。たしかにすべて更新するよりも早いですが、それでもずいぶんな量になります。すると、階層制限がかかります。それはつまり、サブページにサブページへのリンクを管理することはできなくなります。また、親戚関係の場合は依存関係が出ませんので、新たにファイルを置くわけですが、そうすると、更新する場所は自動更新される個所を省いても2箇所です。また、同じファイルが出でくる可能性がありますのでそれが大きいと容量の無駄遣いです。自宅サーバでも自分のウェブサイトのために100GB全部使えるわけじゃないわけですし、普通プロバイダやレンタルサーバで借りれる容量は限られていますから。
しかし、ツリー構造はホームページをとりあえず作りたいという場合や、比較的ホームページ作り経験が浅いユーザにはそれで十分でしょう。なぜならば、段階的にトップダウンで作っていくと、依存性は子から見れば常に一対一であり、ツリーの上下ですべて話がすんでしまうからなのです。
この構造で、共通部品やテンプレートはかなり苦しいかもしれません。やはり、簡単なサイト設計の場合のみに適用できるということがよくわかります。ただし、それほど高機能な共通部品やテンプレートはかなり本腰をいれて構築するころの話なので、当然という仮説が成立してしまうのですが。
関連コラム
- シリーズ 【楽をしてサイト構築をするためのウンチクノート】
- 第1回 - サイトのファイルの依存性を理解する
- 第2回 - サイト運営・設計を楽にする機能
- 第3回 - CMSのコンテンツ生成と結合
- 第4回 - 埋め込みコンテンツとその活用
- 第6回 - メッシュ構造
- 第7回 - データベース参照構造
- 嫌にならない更新のために
- サイト運営って、どうやってるの?