第 5 章 フレームワークの動作上の特徴 43
5.4 新規レコードとレコード削除
データベースのデータを表示することと，表示したデータを修正することでデータベース側の更新をす るというバインディングの動作は前節までに解説した通りである．CRUDに基づくデータ処理では，他に，
新規レコード作成とレコードの削除が機能として必要になる．本節では，宣言的な記述でそれらの機能を 実現するボタンを用意する方法と，入力専用のページを作成する仕組みを説明する．
5.4. 新規レコードとレコード削除 57
5.4.1 コンテキストに対する新規レコードとレコード削除
新規レコードや，レコード削除のボタンは，定義ファイルで指定することで自動的にページ上に配置さ れる．
コンテキストに新規レコード作成ボタンの生成を指示すると，一連のレコードの最下部あるいは，一定数 ごとのレコードの表示範囲を切り替えるページネーション上のいずれかに，新規レコード作成ボタンが追 加される．新規レコード作成時の初期値は通常はデータベースのスキーマで設定できるが，コンテキスト でも指定できる．INTER-Mediatorでは，新規レコードを作ったときには，そのレコードが編集状態になる ように動作する．これは，Microsoft AccessやFileMakerでの動作に習ったものである．
レコード削除については，定義ファイルに指定を行うことで，リピーターの内部にボタンを用意するか，
ページネーション上にボタンを用意できる．フィールドの更新と同様，コンテキストとレコードを特定する ためのキーフィールドと値を保持し，ボタンをクリックすることでそれらの値をもとにデータベースにコマ ンドを送ってレコードの削除を行う．レコード削除後には，フレームワークが対応するリピーターを削除す る．ただし，ページネーションに関連したコンテキストの場合は，レコード削除後にページの合成をフレー ムワークがやり直す．
5.4.2 新規レコードの作成のみを行うページ
アンケートや参加申し込みのような，入力のみをもっぱら行うようなアプリケーションもWebではよく 利用されている．INTER-Mediatorはテキストフィールドなどをデータベースのテーブルにあるフィールド とバインドして自動的に値の表示や更新ができるが，入力のみのページを作成するのはバインドの仕組み を利用できなくはないものの，あらかじめレコードを用意するなど準備が必要になる．つまり，入力専用の ページのように見せるような工夫が必要になってしまう．そこで，入力専用のページを作成する「ポストオ ンリーモード」という動作をサポートした．
5.4.3 入力専用ページの作成方法
ポストオンリーモードでは，テキストフィールドは，データベースへのバインドを行わない単なるユー ザーインタフェースオブジェクトである．作成するには，テーブル名との対応付けを行うために，通常通り 定義ファイルを作成する．ここで，assetという名前のコンテキストがある場合，リスト5.1のようなHTML の記述をページファイルの作成することで，入力専用のページが稼働する．テキストフィールドにキータイ プして「新規入力」ボタンをクリックすると，assetテーブルに新しいレコードが作成され，テキストフィー ルドに入力したデータが対応するフィールドに入力された状態になる．ここでの「新規入力」ボタンの複数 クリックを防ぐため，クリックを受け付けた後はボタンを消すことができる．定義ファイルの設定により，
ボタンを消した後に表示するメッセージや，あるいはボタンをクリックした後に移動するページを指定する こともできる．
リスト5.1:「資産一覧」のページファイルの例
1 <html>
2 <head>
3 <scr ipt src="asset_contexts.php">< /s crip t>定義ファイルの読み込み
4 < /head>
5 <body onload="INTERMediator.construct()"> フレームワークをスタートさせる
6 <table>
7 <tbody data−im−c o n t r o l ="post"> この属性によりポストオンリーモードであることを示す
8 <t r>
9 <th>分類< /th><td><input type="text" data−im="asset@category"/ >< /td> テキストフィールドに
10 <th>名称< /th><td><input type="text" data−im="asset@name"/ >< /td> ターゲット指定を記述する
11 <th>メーカー< /th><td><input type="text" data−im="asset@manifacture"/ >
12 <th>型番< /th><td><input type="text" data−im="asset@productinfo"/ >< /td>
13 <th>取得日< /th><td><input type="text" data−im="asset@purchase"/ >< /td>
14 <th>< /th><td><button data−im−c o n t r o l ="post">新規入力< /button>< /td> サブミットボタンに相当
15 < /t r>
16 < /tbody>
17 < /table>
18 < /body>
19 < /html>
ポストオンリーモードのフレームワーク側の処理の概要を示す．エンクロージャーとして識別される要素
にdata-im-control属性を記述し値を「post」とする．これにより，このエンクロージャー内は入力専用であ
ると認識するので，この例のコンテキストであるassetテーブルへのクエリーは実行されない．エンクロー ジャー内では，data-im-control属性の値が「post」であるBUTTONタグ要素も配置する．チェックボックス やラジオボタンの利用も可能であり，マスターテーブルから取り出した値をポップアップメニューに表示す ることもできる．ボタンをクリックすることで，エンクロージャー内のターゲット指定のあるフォーム要素 から値を取り出し，それらをサーバーに送付し，SQLデータベースであればINSERTステートトメントを 実行して，新規レコードを作成する．
5.4.4 入力確認ページをサポートしない理由
この種の入力フォーム的なアプリケーションでは，最初にフォームで入力をして，それを確認するペー
ジを表示して，最終的にユーザーが確認してボタンを押せば完了するという流れが一般的である．INTER-Mediatorのポストオンリーモードを使ってこの種のユーザーインタフェースを構築することは不可能ではな
いが，同一ページにフォーム部と確認部を用意して，それぞれ表示/非表示をコントロールすれば良い．た だし，JavaScriptによるプログラムの作成が必要になる．こうした仕組みを簡単に実現する方法が必要であ るという考え方もできるが，入力専用フォームでの確認処理の是非を検討した結果，不要であると判断し，
現状では実装はしていない．その理由を以下に示す．
入力専用フォームでの確認処理は，(A)入力内容の確認，ないしは(B)入力内容に基づく処理結果の確認 の，2通りが考えられる．前者はシンプルな申し込みやアンケート回答に対応し，後者は例えば通信販売の ようなページで送り先から送料が決まりそれをもとに支払い合計金額が求められるような場合である．
(A)のタイプの入力専用フォームの場合，なぜ，確認ページがあるのかということを，さまざまなWebサ イトに記載されている内容から検討した結果，次のような理由があることがわかった．
1 フォームのページでは入力した情報がすべて見えているとは限らない．
2 ReturnキーやEnterキーによって，submitボタンが押されたのと同じになり，意図せずサブミッ
トしてしまうときにやり直しが効かない．
5.4. 新規レコードとレコード削除 59 3 積極的な理由はない．一般にそうだから，あるいは，とにかく確認させたい．
[1]の理由は，確かに10文字分しかないテキストフィールドに30文字を入力するような状況では発生す る可能性がある．しかしながら，入力する内容にもよるが，入力結果がその場で見えないのはデザインに問 題があるとも言える．長い文章の場合にはTEXTAREA要素が使われるが，現状のブラウザではユーザーが
TEXTAREA要素の大きさを変更できるようになっているのが一般的であり，長い文字列を入力するから見
えなくなるというのは短絡的な意見である．仮に画面に収まりきれないようなフォームが必要だとしても，
本来は分割して入力できるようにするなどの対処をすべきである．[A]の理由は，適切なデザインを行うこ とで解消できると考える．
[2]の理由は，キーボードショートカットによる操作性の向上を意図したものではあるが，キータイプに慣 れている人ほど癖でReturnキーを押してしまうことは確かにある．これは，FORMタグで囲ったフォーム で発生する問題である．INTER-MediatorはFORMタグを一切使わないため，テキストフィールドでReturn キーを押しても確定ボタンを押した処理は一切行われない．したがって，[2]の問題は一般的なFORMタグ の問題でありINTER-Mediatorでは発生しない問題である．
[3]は心理的な問題であり，技術的な問題ではない．以上より，適切なデザインを行うのであれば，
INTER-Mediatorでは確認ページは不要と言える．
ここで，(B)の場合を検討する．(B)のような形式のアプリケーションも，「入力フォーム」とひとくくり にされることが一般的であるが，実際には入力に加えて，入力した結果から求められた結果が追加された ものが確認ページで表示される．そこでは，入力結果の確認もあるかもしれないが，むしろ求められた結果 の確認が主要な目的である．入力の確認は，(A)の理由と同じく適切なデザインにより確認ページは不要で ある．そして求めた結果の確認は，入力フォームではなく，処理結果の表示に置き換えてみる．
INTER-Mediatorで実装するには，入力した結果でレコードを作成して，次のいわゆる確認ページは，入
力したレコードから求められた結果を表示するようにする．例えば，通信販売ならば，品目や個数，送り先 などを入力フォームで入力し，「確認」ボタンでレコードを作る．作成された販売レコードは，「未確定」「注 文確定」「発送済み」「キャンセル」などのステータス管理をする．レコードを新規に作った時には「未確 定」にして，そのレコードをユーザーに提示し，キャンセルかあるいは注文確定させるボタンを用意する．
これらのボタンは，レコードの特定のフィールドを更新するのが主要な作業となる．このように考えれば，
(B)のタイプのアプリケーションの確認ページは，レコードの表示のページで構築する方法をとることがで きる．ただし，この種のアプリケーションでは要求が複雑になることが一般的で，画一的な解決方法が適用 できないことが多い．結果的にJavaScriptでのプログラミングを併用しないと，要求を満たされないことに なる．つまり，アプリケーションとしては複雑な部類に入ると言える．
結果的に，従来のFORMタグを利用したWebページのような「確認」のページをワークフローに入れる 必要性は，心理的な抵抗感という以上の理由はないと言える．その結果，フレームワークがサポートする機 能としての優先度は非常に低くなり，現在でも実装していない．