| MAP | PageMixer ドキュメント > 動機 [ <| 1| 2| > ] |
JSP は、 ウェブコンピューティングに基づくシステムの構築に対する１つの回答であり、 開発初期においては確かに簡便性を享受することが出来ます。 しかし、成果物規模が大きくなればなる程、 以下に示す事柄に関するコストが増加します。
JSP に埋め込まれたコードを実行するためには、 それを Servlet 環境で実行しなければなりません。 そしてそのことが、 例えば以下のようなサーバ側処理の試験の、 実施容易性を低下させることがあります。
「買い物篭」ページは「買い物篭」機能以外にも、 未ログインユーザのための「ログイン」機能を持っているかも知れず、 それらを個別に試験したいと思うのは自然なことです。
時として、クライアント側だけでそれを行うのが難しいことがあります。
クライアント側においては、 HTTP 応答か、 あるいはその一部としての HTML ページが、 サーバ側処理の正当性を評価する材料の全てであり、 それをプログラム的に評価するのはあまり良い考えとは思えません。
JSP フレームワークはコードの埋め込みを必要とするため、 デザインと処理が平行して開発された場合、 その結合の度に JSP ファイルを調整しなければなりません。
"diff3" UNIX コマンドのようなツール類の補助を受けたとしても、 多くの場合、それを手動で行う必要があります。
XMLC は、 これまでに述べた JSP における弱点に対する一つの回答です。 しかし、いくつかの要求が満足されません。
XMLC は HTML ページを "DOM ツリー" として表現するため、 その操作方法を習得する必要があります。
XMLC は、 特定の ID によって識別される "DOM ノード" への簡便なアクセスも提供していますが、 それに十分利便性があるようには（少なくとも私には）見えません。
XMLC は以下に示す点において、 性能上の問題を抱えています。
"DOM ツリー" として表現されていることから、 HTML ページデータは 100 以上の Java オブジェクトから構成されています。
XMLC は、 HTML ページを "DOM ツリー" のトラバースによって描画していますが、 その "DOM ツリー" は多くの Java オブジェクトから構成されており、 且つ中間 "String" が必要とされます。
結論として、 私が必要としているのは、 JSP と XMLC の中間に位置するフレームワークである、 ということに気付きました。
そして同時に、 それを自分自身で開発しなければならないことにも気付きました。
| MAP | PageMixer ドキュメント > 動機 [ <| 1| 2| > ] |