上位概念の機能の実現

この節では，アプリケーションでよく利用されるような一覧と詳細を行き来するようなユーザーインタ フェースを作成する機能や，検索機能を宣言的な記述のみで実現する機能，メール送信の機能をどのように 実装しているのかについて解説をする．

5.10. 上位概念の機能の実現 71

5.10.1 一覧と詳細を行き来するユーザーインタフェース

データベースに蓄積されたデータを参照する場合，各レコードの主要なフィールドのみを一覧表示し，選 択したレコードに関して必要なすべてのフィールドを表示するという形式のユーザーインタフェースはよ く利用する．それぞれ一覧と詳細と呼ぶが，「マスター/ディテール形式」とも言われる．iPadを横長に使用 した時に，一覧と詳細が左右に並び，一覧で選択したレコードが詳細に表示される形式もある．

INTER-Mediatorでは，一覧と詳細のユーザーインタフェースを，宣言的な記述のみで実現する．原則と

して同一のテーブルをもとにした，2つのコンテキストを用意し，それぞれにnavi-controlキーを指定する．

一覧側のコンテキストのnavi-controlキーには「master」ないしは「master-hide」と記述する．詳細側のコ ンテキストのnavi-controlキーには「detail」ないしは「detail-bottom」と記述する．

ページファイル内に，一覧と詳細のコンテキストを利用した2つのTABLEタグのテーブル（あるいは2 セットのエンクロージャー/リピーター）を記述する．一覧と詳細が切り替わるタイプは，一覧側のコンテ

キストのnavi-controlキーに「master-hide」を指定する．すると，ページ合成後に，フレームワークは自動

的に各リピーター内に詳細を表示するボタンを配置する．同時に詳細部分は非表示になる．詳細を表示す るボタンをクリックすると，一覧部分が非表示になり，詳細部分が表示される．同時に，クリックしたレ コードが表示されるように，エンクロージャーを更新する．詳細側のコンテキストはnavi-controlキーの値 が「detail」に設定されており，ページテンプレートからの展開時にそのコンテキストのリピーターの前に，

「detail-bottom」であればリピーターの後に，一覧を表示するボタンを配置する．そのボタンをクリックす ると，詳細と一覧の表示/非表示を切り替える．

iPadの形式の表示を行う場合は，一覧側のコンテキストのnavi-controlキーに「master」を指定する．一 覧も詳細も最初はどちらも見える状態になっているため，CSSの設定を利用して，2つのエンクロージャー による展開領域を左右に並べるような配置にしておく．この場合，一覧側に詳細を選択するボタンは表示さ れるが，詳細から一覧に戻るボタンは配置されない．一覧側でボタンをクリックすると，詳細側に表示され るレコードがボタンに対応したレコードに切り替わる．

5.10.2 検索処理を実現する仕組み

テキストフィールドに検索条件を入れると，そのキーワードを含むレコードが検索されて一覧されると いったユーザーインタフェースへのニーズは高い．コンテキストに検索条件を記述できるが，これは固定的 な条件になる．そこで，当初はJavaScriptのAPIを利用し，決められたプロパティにオブジェクトとして 検索条件を代入しておくことで，検索時にその条件を適用したクエリーを発行できるようにした．ボタン を押した時に，検索条件のテキストフィールドから条件を取り出し，適切な演算子とともにオブジェクト を生成し決められたプロパティに与え，ページ全体を更新するなどして検索結果を表示できるようにした．

しかしながら，ここでは数行ながらも手続き的なプログラミングが必要になる．そこで，プログラムを不要 にする実装ができないかを考えた．

そのためのベースになる仕組みとして，データベースとはバインドしていない，ブラウザ側に存在する キー/バリュータイプのストレージ（ローカルコンテキスト）を用意した．そのストレージは，コンテキス

ト名の代わりに「_」を記述する．また，フィールド名がキーとなり，ローカルコンテキストはページファ イル内のノードとバインドする．

検索条件のテキストフィールドのdata-im属性に，例えば「_@condition:postalcode:f3,f7,f8,f9:*match*」と 記述する．最初の_はローカルコンテキストを示し，@以降はローカルコンテキストのキー名である．キー自 体はコロンで区切ってパラメータとしている．最初の「condition」はこのキーに対する値が検索条件である ことを示す固定のキーワードである．「postalcode」は適用するコンテキスト名を指定する．次の「f3,f7,f8,f9」

はフィールド名を示すが，複数のフィールドをカンマで区切ることで，各フィールドに対する条件式のOR を条件として付加する．最後の「*match*」はフレームワークで規定した演算子であり，ここでは部分一致 になる演算子をデータベースエンジンに応じて適用する．指定されたコンテキストに対するクエリーを実行 するとき，ローカルコンテキストを探してこの設定があれば，検索条件を追加する．このテキストフィール ドの入力値が「新宿」なら，MySQLをデータベースエンジンに使っている場合，「WHERE ((f3 LIKE ’%新宿

%) OR (f7 LIKE ’%新宿%) OR (f8 LIKE ’%新宿%) OR (f9 LIKE ’%新宿%))」というWHERE句を追加する．

同様な仕組みで，ある要素のdata-im属性を「_@addorder:postalcode:f3:asc」とすれば，この要素をクリック すると，f3フィールドの昇順でクエリー結果を得るようにもした．これにより，どのフィールドを基準にソー トをするのかといったユーザーインタフェースを追加できる．また，data-im属性が「_@update:postalcode」

であれば，その要素をクリックするとpostalcodeコンテキストが更新されるようにした．つまり，検索条件 の右にある「検索」ボタンをこの方法で追加できる．

これらの仕組みにより，検索を伴うWebアプリケーションについても，宣言的な手法で対処できるよう になっている．

5.10.3 メール送信機能の実現

Webアプリケーションでは，データの入力後などに確認のメールが送られることも多い．Webサーバー では，なんらかの準備をすることで，メールサーバーを起動することができる点に着目して，サーバー側の 機能として，メール送信の仕組みを組み込んだ．メールサーバーは送信用としてのみ利用する．別サーバー に対してSMTPでメール送信を行うこともできる．

メールの送信は，特定のコンテキストに対するデータベース処理の後に行われる．新規レコードを作成 するとき，レコードを更新したとき，クエリーを実施したときに，それらの処理の後にメールを送ること ができる．ただし，レコード削除後はサポートしていない．定義ファイルのコンテキストにメール内容に 関する設定が行え，例えば，宛先に固定の値や，フィールドから得られる値を使用できる．メール本文は，

テンプレートとなるテキストファイルを用意することができる．テキストファイル内には文字列のプレース フォルダを記述することができ，新規レコードを作った場合だと，その作ったレコードの各フィールドを，

プレースフォルダに割り当てることができる．通信販売サイトにあるような，挨拶文と入力結果を含めたよ うなメールの作成が可能である．