なぜ、そのような違いが起きるか考える
では、技術的な観点からなぜそのような違いが発生するか考えてみましょう。
比較に使うアプリケーション
両者を比較するために検索アプリケーションを想定します。先ほどの構成を取るデザインで、中に入る部品が、
- 最初の画面で検索の条件を決める
- 次の画面で、検索結果を表示する
という2つの状態を持つようにします。このときに、両者はどのような実装になるでしょうか。
Windowベースのアプリケーション
Windowベースのアプリケーションは、このようなものは得意です。親Windowの中に子Windowを作り、子Window自体は独立して状態遷移（画面遷移）するようなプログラムが普通だからです。
これは、「イベントハンドラ」「Windowの状態（Windowクラスのメンバ変数の内容）」が各Windowごとにまとまって管理されているからです。「イベントハンドラ」は各Windowごとにそれぞれ定義しますし、「Windowの状態」はまさにWindow固有の値です。これはちょうど、1つのWindowがオブジェクト指向で言うところの「オブジェクト」となっていると言えます。そのため、普通にプログラムを書いていれば、部品化はWindowごとにある程度は自然に行わるのです。
HTMLベースのアプリケーションでは
HTMLベースの部品化は、いつもこううまくいくとは限りません。なぜならば、HTMLベースのアプリケーションの最終的な出力は画面ではなく、直列化された文字列（HTML）だからです。そのため、直列化した後でGUIアプリケーションのように一部分を変更するのは困難です。よって、次の2つの段階を経てから出力するようにします。
- 外部からの入力（Formのパラメータ）を状態を保持する単位に対して入力して、状態遷移させる。
- その状態（例えば、検索条件待ちなのか、結果を出力するのか）に対応した出力をする
ここで、気を付けなくてはならないのが、「状態を保持する単位」が何であるかです。WindowベースのGUIでは、その単位は、「親Window」とその中の「子Window」です。Webアプリケーションでは、この「状態を保持する単位」の切り分けが明確になっていない言語やフレームワークが多いため、HTMLの部品化に苦労するのです。このような概念は、JSF（Java Server Face）では取られていますが、その他のほとんどの言語やフレームワークでは取られていません。
Alinous-CoreでのHTML部品化
では、Alinous-Coreでの画面の部品化について見てみましょう。
サンプル
まずは、サンプルを示します。このサンプルでは、親HTMLの中に子HTMLのオブジェクトを2つ埋め込みます。
<HTML> <BODY> <TABLE> <TR> <TD alns:tagid="child1" alns:inner="child.html"> </TD> </TR> <TR> <TD alns:tagid="child2" alns:inner="child.html"> </TD> </TR> </TABLE> </BODY> </HTML>
<HTML> <BODY> <FORM name="form1" action="child2.html"> 何か入力：<input type="text" name="sample"><BR> <input type="submit" value="次の状態へ"/> </FORM> </BODY> </HTML>
<HTML> <BODY> 戻るボタンを押してみてください。以前に入力した値が表示されています。 <BUTTON alns:back="true">戻る</BUTTON> </BODY> </HTML>
動作の解説
「parent.html」にアクセスすると、2つのフォーム部品が表れます。Alinous-Coreでは、2つの属性alns:tagidとalns:innerを付けることにより、TDタグを子HTMLのコンテナとして扱うことができます。
alns:tagidで名前をつけ、alns:innerで初期ページを指定します。このとき、前説で話した「状態を保持する単位」の一部として、この2つのTDタグが動作します。ですので、この2つのTDタグには同じフォームが表れますが、それぞれ別々に独立して画面遷移します。
まとめ
今回は、Web系でいつもページの保守管理で問題になるHTMLの部品化について書きました。最近ではWebアプリケーションは一度作るだけではなく、その後の管理もかなり重要視されるので、HTMLの部品化は非常に注目される技術になると思います。
次回は、Webでよく使われるBasic認証とフォーム認証について書こうと思います。
