ボルボックス


ムダなくすばやくすべてを
volvox

Q&A

質問
文書管理なんてしたくないんですが?
回答
ボルボックスは柔軟です。

お望みであれば、フロントエンドのHTMLにすべてのテキストを書いてしまってかまいません。もちろんその状態ではボルボックスの導入になんの利点もありませんが、かりにその中の1ページ、1ページの1パラグラフでもウェブのフォームから入力させたい、という要望が出たとき(たとえば「社長挨拶」を社長が自分で修正していきたい、とか)、ボルボックスがあればその箇所だけをCMSに対応させることができます。

もし既存のサイトがあるなら、ボルボックスによる管理はその状態から始められます。そしてサイトの運用状況をみながら、必要な箇所で必要な深度だけ、バックエンド文書を設計していくことができます。そのようにしてすこしずつ効率化(情報の分割と統合)をはかっていけるところに、ボルボックスのよさがあります。

質問
アプリケーションの応答が遅くなりませんか?
回答
ボルボックスは柔軟です。

たしかにバックエンドの文書管理をまともにやれば、フロントエンドの動的な生成時にも多段のスタイル適用が起こります。しかしボルボックスはまともな文書管理ツールなので、応答スピードが要求されるプロセスについては、あらかじめスタイル適用済みのページを静的に生成しておく、といったことができます。

たとえば管理者向けのページについては応答性より保守性を、応答性が求められる利用者向けのページについては、データベースからの出力を適用する前段階までの静的なページを用意しておく、といった。

応答性と保守性のトレードオフに応じて、それぞれの箇所に適切な運用パターン(XML形式のドキュメントからRDB形式のデータベースまで〜文書の動的な生成から静的な生成まで)を選択していけるところに、ボルボックスのよさがあります。

質問
ずっと使い続けられますか?
回答
サポートの継続、汚染されないXML/XSL文書、コードの公開、……

提供するソフトウェアのサポート継続は開発者の使命であり、これは他のソフトウェアと変わりません。くわえて標準と公開という2点からも、将来にわたる継続利用を考慮しています。

まず利用者が管理するバックエンド文書(XMLテキスト群/XSLスタイル群)に、このソフトウェアの独自仕様はいっさい加えられません。XSLスタイルが動的にそのふるまいを変える場合ですら、「変数」の引き渡しは与えられるXMLのセットによるもので、その構造は利用者が決めるものです。また利用者が作るプログラムもXSLで書かれます。

これは保守性という点からみれば、他のCMSアプリに対する大きなアドバンテージです。XMLやXSLはW3Cの標準仕様であり、その寿命は、単体のアプリケーション(このアプリふくむ)よりはるかに長いはずです。アプリケーションが使えなくなったとき、バックエンド文書がアプリやコミュニティ独自の変数や制御で汚染されたものだったらお手上げですが、ピュアなXML/XSL文書だったら対応することができます。

このソフトウェアのコードは公開されています。XMLパイプラインと周辺ドライバは可能なかぎり構造を単純にしており、シェル・スクリプトなどで代替することは難しくありません。