Home of: [工房 "藤車"] > [SourceForge.net における PageMixer]

使うべきか?

本ドキュメントは、 どのような局面で PageMixer フレームワークを使うべきかについて説明します。

使うべきではないのは:

サイトの仕様が頻繁に変更される場合

JSP は、ページ仕様の動的且つ簡便な変更を可能にします。 例えば、 サーバを再起動すること無しに、 ログオンのためのページを、 管理者が会員の一覧を見るためのページに変更することもできます (そんな変更をする人はいないと思いますが…)。

PageMixer フレームワークの設計は、 そのような用途を想定していません。

勿論、 Servlet コンテナのクラスリロード機構により、 ページの仕様を動的に変更することも可能です。 しかし、私自身はクラスリロードの仕組みを左程信頼していません。

まだ PageMixer を試していない場合

深刻なプロジェクトに適用する前に、 PageMixer の試用と評価を行ってください。

PageMixer フレームワークは、 あなたのプロジェクトに対する適用性を何ら保証されていません。 性能上(例: PageMixer は JSP ほど早くありません)、 機能上(例: ページ機能の動的変更は想定されていません)、 あるいは政治上(例: プロモーション上、 プロジェクトで JSP を使わなければならない) の理由から、 PageMixer フレームワークの使用を諦めることになるかもしれません。

JSP が最善の手段であると信じている場合

誰もが信教の自由を持っていますからね。

実のところ、 いくつかの制約の元でなら、 私も JSP が最善の手段であると考えています。

使う必要が無いのは:

実装担当がグラフィックデザインもできる場合

この場合、 ページデザインと処理の両成果物の統合は左程高くはつかないかもしれません。

良い人員配備に感謝すべきでしょう。

顧客がページデザインに興味が無い場合

この場合も、 ページデザインと処理の両成果物の統合は左程高くはつかないかもしれません。

しかし、"ページデザイン" には、 "ビジュアル"(例: 色、フォント種別等)と、 "利便性"(例:ページ要素の配置)の2つの側面があります。

顧客は、 "ビジュアル" 的なデザインには興味が無くても、 "利便性" 的なデザインには興味があるかもしれません。 そして、そのことは JSP ファイルの複雑さを増加させるかもしれません。

サイトがわずかなページで構成される場合

左程コストが掛からないかもしれません。

使用すべきなのは:

ウェブサイトが多くのページで構成される場合

このことは、 ページデザインと処理の両成果物の統合以外に、 それらのテストに掛かるコストを増加させます。

PageMixer フレームワークの目標の一つが、 試験容易性の向上です。

ページが別途デザインされる場合

このことは、 ページデザインと処理の両成果物の統合コストのみならず、 統合の実施それ自体の必要性を増加させます。

PageMixer フレームワークの目標の一つが、 デザイン分離性の向上です。