INTER-Mediatorでは、Postオンリーモードという動作をするエンクロージャーを定義でき、一般的なフォームのように入力をして、ボタンをクリックすると対応するコンテキストに新しいレコードを作るという動作を行います。ちなみに、INTER-MediatorではFORMタグを使わないで実装をしています。
通常、フォームで入力するときには、入力結果を改めて別の画面に明示し、入力者に確認をさせて、OKかあるいは修正するというユーザインタフェースが一般的です。そのサポートをもちろんPostオンリーモードでやってもいいのですが、私は不要と考えます。
なぜ、確認画面が必要なのか？
検索すると、やはり否定的な意見（例えばこちら）がいくらかある一方で、確認画面の作り方というサイトは大量に出てきます。現状、確認画面は作って当たり前というのがどうも業界の一般常識なのでしょうか？ ただし、なぜ、必要なのかという積極的な説明はざっと見た限りでは見つかりませんでした。一方、不要というのは、「出したところで見ている人はほとんどいないだろう」という消極的な側面が理由としてはよく見られる内容です。
まず、一般的なWebフォームではなぜ確認が必要なのかということがあります。当然の理由として、「確認したいから」あるいは「確認する必要があるから」ということになりますが、理由はもう少し掘り下げて考えないといけません。おそらく、過去からのいろいろな経験の積み重ねで次のような理由があるからでしょう。
- フォームのページでは入力した情報がすべて見ているとは限らない
- 入力した情報以外のものを表示したい（販売サイトの合計金額や送料など）
- ReturnキーやEnterキーによって、submitボタンが押されたのと同じになり、意図せずサブミットしてしまうときにやり直しが効かない
- 積極的な理由はない、一般にそうだからとか、とにかく確認させたいといった理由
これらを順次検討しましょう。
フォーム上で見えていないのはデザインが悪い
理由1は、大昔の解像度の低いWebページを作っていた時代では確かにあったかもしれません。テキストフィールドが40文字としても、50文字の入力があるような場合、ユーザに対しては全項目を入力した後の状態の画面で全部が見えていないのは確かにあります。ユーザは垂直方向はもちろん、水平方向にもスクロールしないと文字が見えません。そのような状況で、念のため一度全部、ページに見せるということは確かに必要でした。
しかしながら、現在は解像度が高いディスプレイが一般的です。また、スマホでも何でも1ページに押し込めるなんてことはしないようにするという積極的な対応が普通に行われます。現在はデザインが重視されており、入力中に今自分が入力したものが見えないようなレイアウトは、一般にはデザインが悪いと言わざるを得ないでしょう。もし、この理由でフォームの確認画面が必要なら、まず、フォーム自体を見直す必要があり、その結果、確認画面は不要という結論になると言えます。
別の情報の確認は入力結果の確認ではない
理由2です。これは、入力した結果の確認画面の話でしょうか？ 違います。これは、システムが生成した結果を利用者が確認する画面のことで、入力の確認画面の議論と混同してはいけません。この件は最後に別の確度でも検討します。
Returnキーの動作はFORMタグ特有の動作
古い時代のフォームでは、入力途中にReturnキーに触れてしまって意図せずサブミットされて困った人も多いかもしれません。理由3のように、テキストフィールドにフォーカスがあるときにReturnキーを押すと、自動的にそれを含むFORMタグのsubmitボタンがクリックしたものとみなされるのは一般的な動作です。
他のフレームワークならともかく、INTER-MediatorはテキストフィールドでReturnを押しても、submit的な動作はもちろん、設定やあるいはプログラムを追加しない限りは何も起こりません。つまり、INTER-Mediatorであれば、Returnで意図せずサブミットされることはありません。逆に、Returnでサブミットしたいのなら、何かしらの記述を追加しなければなりません。
考えましょう
理由4に対してはエクスキューズの必要すらないと考えます。利用者の事を真剣に考えていないサイトの存在理由って何でしょうか？ そうか、失礼しました。そういうことを考えないから、個別の動作についても理由がないのですね。
作っているものは「入力フォーム」なのかを考える
以上のように、入力結果を新規レコードとして残すような入力フォームでは、INTER-Mediatorで適切なデザインをしていれば、確認画面が必要な積極的な理由はありません。しかし、理由2も含めて、いわゆる入力フォームにはそういう単純なパターンではない場合もあります。
理由2に記載したように、たとえば、商品発注の入力フォームがあって、サブミットしたら合計金額と送料を表示させたいとします。これは、実は、入力＋システム処理結果の確認なのです。こういうものは必要と言えば必要ですが、これは入力の確認というよりも、システム処理結果の確認です（例1）。
また、これと同様なものとして、入力情報を、複数のページで入力する場合です。アンケートなどで1問ずつページが変わるものがあります。これも、過去のページを保持するという意味では、システムの処理が絡みます（例2）。
こうしたページをINTER-Mediatorで作る場合は、2つのアプローチがあると考えます。
- 必要なページをすべて1ページに作り、CSSのdisplay属性を利用して順次見せるような仕組みにして、最後にPostオンリーモードで新規レコードを作成する
- ページの最初にレコードを作ってしまい、それ以降のページは実際にはそのページの編集状態で提示する
例2のように、ステップで変わるページの結果を覚えるだけなら、1の手法だと比較的楽でしょう。戻るのも、そんなに労せず可能です。ただし、例1のようなECサイトなら、たとえば、選択した商品の単価や在庫情報、合計に対する送料の計算などロジックが絡みます。もちろん、AJAXで必要な情報を取得してクライアントサイドで計算することも実装の1つの手法ですが、いったんデータベースに入力した結果を参照する編集ページを遷移させる方がスキーマに組み込んだロジックが使える点では便利です。ただし、発注情報にステータス管理、つまり、確定前か後かなどの情報をきちんと設定するなど、やや複雑にはなります。
いずれにしても、これらの状況は、利用者としては入力フォームなのかもしれませんが、システムの動作を考えれば、入力だけでなく、システムの動作が絡むものです。そこをきちんと把握しないと、効率的な開発はできません。サービス提供側はユーザの視点も必要ですが、システム開発の視点を都合良く忘れてしまうのは良くありません。
それでも従来手法を求められたら？
INTER-Mediatorでシステムを作る場合、それでも「確認ページ」を求められたどうしましょうか？まず、よくある対処として「ボタンを押したらダイアログボックスで短いメッセージを出して確認」があります。まあ、その程度でいいでしょうという要求のような場合です。そのとき、Postオンリーモードでデータベースへの書き込みに行く前に実行するメソッドを定義して、そこでダイアログボックスを表示します。例えば、こんな感じです。INTERMediator.construct(true)の直前あたりに記述します。falseを返せば、何もしません。
INTERMediatorOnPage.processingBeforePostOnlyContext = function(node) {
return confirm("本当に入力していいでしょうか？ しつこいようですが、やっちゃいますよ");
}
あるいは、「入力フォーム」と「確認ページ」をそれぞれdiv要素で1ページで作っておいて、JavaScriptで切り替えます。入力結果を確認ページ側に転記するなど、地道なプログラムは必要ですが、困難さはほとんどないと思います。
ちなみに、値の確認は、バリデーションの仕組みがPostオンリーモードでも使えるので、それを活用すれば、未入力の確認等は定義ファイルへの記述のみで可能です。