Category: INTER-Mediator

[IM]Postオンリーモードと「確認画面」が不要な理由

INTER-Mediatorでは、Postオンリーモードという動作をするエンクロージャーを定義でき、一般的なフォームのように入力をして、ボタンをクリックすると対応するコンテキストに新しいレコードを作るという動作を行います。ちなみに、INTER-MediatorではFORMタグを使わないで実装をしています。

通常、フォームで入力するときには、入力結果を改めて別の画面に明示し、入力者に確認をさせて、OKかあるいは修正するというユーザインタフェースが一般的です。そのサポートをもちろんPostオンリーモードでやってもいいのですが、私は不要と考えます。

なぜ、確認画面が必要なのか？

検索すると、やはり否定的な意見（例えばこちら）がいくらかある一方で、確認画面の作り方というサイトは大量に出てきます。現状、確認画面は作って当たり前というのがどうも業界の一般常識なのでしょうか？　ただし、なぜ、必要なのかという積極的な説明はざっと見た限りでは見つかりませんでした。一方、不要というのは、「出したところで見ている人はほとんどいないだろう」という消極的な側面が理由としてはよく見られる内容です。

まず、一般的なWebフォームではなぜ確認が必要なのかということがあります。当然の理由として、「確認したいから」あるいは「確認する必要があるから」ということになりますが、理由はもう少し掘り下げて考えないといけません。おそらく、過去からのいろいろな経験の積み重ねで次のような理由があるからでしょう。

  1. フォームのページでは入力した情報がすべて見ているとは限らない
  2. 入力した情報以外のものを表示したい（販売サイトの合計金額や送料など）
  3. ReturnキーやEnterキーによって、submitボタンが押されたのと同じになり、意図せずサブミットしてしまうときにやり直しが効かない
  4. 積極的な理由はない、一般にそうだからとか、とにかく確認させたいといった理由

これらを順次検討しましょう。

フォーム上で見えていないのはデザインが悪い

理由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. 必要なページをすべて1ページに作り、CSSのdisplay属性を利用して順次見せるような仕組みにして、最後にPostオンリーモードで新規レコードを作成する
  2. ページの最初にレコードを作ってしまい、それ以降のページは実際にはそのページの編集状態で提示する

例2のように、ステップで変わるページの結果を覚えるだけなら、1の手法だと比較的楽でしょう。戻るのも、そんなに労せず可能です。ただし、例1のようなECサイトなら、たとえば、選択した商品の単価や在庫情報、合計に対する送料の計算などロジックが絡みます。もちろん、AJAXで必要な情報を取得してクライアントサイドで計算することも実装の1つの手法ですが、いったんデータベースに入力した結果を参照する編集ページを遷移させる方がスキーマに組み込んだロジックが使える点では便利です。ただし、発注情報にステータス管理、つまり、確定前か後かなどの情報をきちんと設定するなど、やや複雑にはなります。

いずれにしても、これらの状況は、利用者としては入力フォームなのかもしれませんが、システムの動作を考えれば、入力だけでなく、システムの動作が絡むものです。そこをきちんと把握しないと、効率的な開発はできません。サービス提供側はユーザの視点も必要ですが、システム開発の視点を都合良く忘れてしまうのは良くありません。

それでも従来手法を求められたら？

INTER-Mediatorでシステムを作る場合、それでも「確認ページ」を求められたどうしましょうか？まず、よくある対処として「ボタンを押したらダイアログボックスで短いメッセージを出して確認」があります。まあ、その程度でいいでしょうという要求のような場合です。そのとき、Postオンリーモードでデータベースへの書き込みに行く前に実行するメソッドを定義して、そこでダイアログボックスを表示します。例えば、こんな感じです。INTERMediator.construct(true)の直前あたりに記述します。falseを返せば、何もしません。

INTERMediatorOnPage.processingBeforePostOnlyContext = function(node) {
    return confirm("本当に入力していいでしょうか？　しつこいようですが、やっちゃいますよ");
}

あるいは、「入力フォーム」と「確認ページ」をそれぞれdiv要素で1ページで作っておいて、JavaScriptで切り替えます。入力結果を確認ページ側に転記するなど、地道なプログラムは必要ですが、困難さはほとんどないと思います。

ちなみに、値の確認は、バリデーションの仕組みがPostオンリーモードでも使えるので、それを活用すれば、未入力の確認等は定義ファイルへの記述のみで可能です。

[IM]ローカルコンテキストのキャッシュと悩みポイント

Ver.4.4を目前にして足踏みしている理由について、だいぶんと頭が整理されてきたので、一度ドキュメントを書きます。

INTER-Mediatorでは、コンテキストに対する検索条件を、プログラムから指定する仕組みを持っています。ユーザが入力した条件で再検索するといった仕組みを作りやすくするためものもです。INTERMediatorオブジェクトのadditonalConditionプロパティです。この種のプロパティはいくつかありますが、「additonalConditionプロパティ」で代表して議論します。

今まで、このプロパティは、ページを再合成すると消えてなくなりました。しかしながら、あるページで検索して、別のページに行き、さらに後ほど前のページに戻ったら、同じ検索条件で検索されていて欲しいと思うのではないでしょうか。そこから紆余曲折を端折ると、データベース関連したコンテキストとは別に、クライアント内部だけで利用可能なキーバリューストアの「ローカルコンテキスト」に、additonalConditionプロパティの値も入れて、ローカルコンテキスト自体をキャッシュする仕組みを作りました。キャッシュインやクリア等、APIも用意されています。要約すると、次のような実装になっているはずです（ま、そこもデバッグポイント）。

  1. 定義ファイルの最初の読み出し（SCRIPTタグで読み込む部分）時において、additonalConditionプロパティがnullであれば、{} で初期化する。ただし、ここでは、キャッシュへの書き込みは行わない実装になっている。
  2. INTERMediator.construct(); でページ合成を行うときには、キャッシュの値を取り出して、additonalConditionプロパティにセットする。
  3. additonalConditionプロパティに値を設定すれば、その都度キャッシュをするのが通常動作である。ただし、IE8のみ、1行呼び出しが必要になる。

条件を入力し、検索ボタンを押したときに、上記3のプログラムが動いて、additonalConditionプロパティは設定され、キャッシュもされます。もちろん、検索時に条件として、追加されます。そして、ブラウザを閉じて同じURLを開くと、キャッシュがあるので上記2のメカニズムにより、以前の検索条件が復活して、条件が適用されたクエリー結果が得られます。

そこで、また、別の条件で検索したとします。ここからが問題です。このときに、以前の条件をクリアして、additonalConditionプロパティを {} から構築しなおせば、おそらく問題はないと思います。つまり、キャッシュの内容と、additonalConditionプロパティへの設定プログラムが、同じ意図を持って存在している場合です。検索条件で使うフィールドがいつも同じだと、この条件が成り立つでしょう。

しかしながら、フィールドAで検索するというキャッシュと、フィールドBで検索するというプログラムの両方があったらどうでしょうか？　Aか、Bか、はたまたAとBの合成か？　合成といってもどうするか？　ここに明確な答えはないと思われます。アプリケーション次第なのではないでしょうか。そうなると、フレームワークとしてはどういう「仕様」を「サポートする」のかというのが非常に決めづらくなります。

additonalConditionプロパティへの設定は、必ずクリアしてから行ってください…というのもありなんですが、残っていることを利用して効率的に設定を適用したい場合もあります。前者は原則で、後者は理解した方はどうぞということになるのでしょうか？　あるいは、キャッシュするかしないかというようなフラグを別途作る事で解決するのか、あるいはより混乱するのか。

この辺りを決めかねています。

[IM]JavaScript、プロパティ、セッタ、オブザーバブル？

JavaScript一般のお話ですが、詳細はINTER-Mediatorがらみとなります。

まず、プロパティは、オブジェクトに対して自由に用意できるのですが、Object.definePropertyというメソッドを使えば、セッタ、ゲッタの実装ができます。IEのみ、このメソッドが限定された状況でしか使えないこともありますが、やはり複雑な事をするときにはセッタやゲッタを利用するのはきわめて自然な発送です。

ここで、オブザーバブルです。最近のJavaScriptフロントエンド系フレームワークではもはや実装されていて当たり前の機能です。MVCという点よりも、むしろオブザーバブルな方が重要な仕組みであるとも言えます。これは、フロントエンドなのでユーザインタフェースを構築することが大きな目的であることから来ます。ユーザインタフェース、つまりMVCのViewとModelの連動のために、イベントに対応するプログラムを書くという手法ではなく、イベントが自動的に伝搬されて行く仕組みが欲しい訳で、それをベースにすると、同一のエンティティにバインドした2つの要素が連動するとか、それをさらにはクライアント間で連動させるといったベースになるのです。ここを自動化できれば、アプリケーションの複雑さはそこそこ緩和でき、より手軽にアプリケーションの作成ができるようになると言えばいいでしょうか。

INTER-Mediatorでは、コンテキストに対する検索条件を、INTERMediator.additinalConditionというプロパティに記述することで、条件を追加できます。コンテキスト、つまりはテーブルへのアクセスにおいて、プロパティの値を条件として記述します。しかしながら、条件の記述においてはさまざまなパラメータが必要になるので、結果として、次の様な記述を行うのを基本にしています。

INTERMediator.additinalCondition["コンテキスト名"]
    = [{field: "フィールド名", operator: "演算子", value: "値"}];

連想配列や配列として解釈すると、きわめて階層が深いですが、必要な情報なので記録が必要です。右辺のオブジェクトの配列を指定できるので、単一のコンテキストで複数の条件を指定したり、あるいはもちろんのこと、コンテキストごとに追加条件を指定できます。

ここで、この追加条件を変更したときに、クッキーに記録させることを考え、なるほど、それならば、このプロパティのセッタを作ればいいのではないかと考えました。もちろん、大した実装でもないので、セッタやゲッタは簡単にできたのですが、セッタが呼ばれない事が時々あり、考え込んでしまいました。考えてみれば当たり前のことなのですが、既存のサンプルなどの動きが正しくなくなると、正しい答えに行くのに回り道をしてしまいます。

まず、以下のようにすればセッタが動きます。

INTERMediator.additinalCondition 
    = {"context": [{field: "f1", operator: "=", value: "123"]};

しかし、以下のようにするとセッタは動きません。ようするに、サンプルの多くの書き方では、セッタは動かないのです。

INTERMediator.additinalCondition["context"] 
    = [{field: "f1", operator: "=", value: "123"];

ここをえらく勘違いしていました。なぜ、後者はセッタが動かないのか？　これは、additinalConditionプロパティそのものへのに対する代入をしていないからです。左辺の記述により、additinalConditionプロパティにアクセスするのでゲッタは動きます。そこで、オブジェクトがあれば取り出されて、そのオブジェクトに対して、右辺を代入しているので、additinalConditionプロパティ自体への代入はまったくしていないのです。そこから参照されているオブジェクトに対しての変更処理をしているので、additinalConditionプロパティのセッタは稼働しません。

結果的に、ここでの最下層にあるfieldプロパティなどを書き換えてもadditinalConditionプロパティのセッタが動くようにならないといけないわけでして、それを突き詰めれば、オブザーバブルな配列、オブザーバブルなオブジェクトが必要になってくるわけです。残念ながら、INTER-Mediatorではそこの実装はしていません。KnockoutやEmber.jsではそういう仕組みが用意されているのです。モデルに対するプログラミングインタフェースを持つとしたら、確かにオブザーバブルな配列は必要かもしれません。また、これらの代表的フレームワークに関わらず、オブザーバブルな配列の実装はかなりたくさん公開されています。

INTER-Mediatorに汎用的なオブザーバブルな配列やオブジェクトを組み込むのも、ある意味はいいのですが、その前に本来の目的に立ち返られないといけません。INTER-Mediatorはモデルをプログラマが定義しないと使えないのではなく、宣言的な記述で定義したコンテキストを仮想的に「モデル」として見る以上のとは通常はしなくてもかまいません。オブザーバブルな配列があれば、開発している私はいいのですが、利用者の直接的なメリットではないと考えます。

一方、プロパティの値を自動的にクッキーに入れれば、一見すると便利なのですが、アプリケーションで必要なのはむしろ、細かな記録と消去のような気がします。自動的に覚えさせるのは、確かにデモウケは良さそうですが、いくつかのサンプルに実装してみて感じることは「忘れてくれ！」と思う場面も多いことです。このあたり、どういう実装にするか非常に悩みます。今現在、セッタから呼び出されるようにしていますが、もしかすると、クッキーへの記録は明示的に開発者に記述してもらうのがいいのかもしれません。もし、現状のままだと、additinalConditionプロパティへの値の設定の書き方がきわめて限定される点も考慮すべきところです。この点はしばらく考えるつもりですが、ご意見があれば、FacebookのINTER-Mediatorのグループへどうぞ。

[IM]コンテキストの内部実装

コンテキスト定義に従って、実際にページ合成を行うときに、クライアントの内部にコンテキストのオブジェクトを作ります。このオブジェクトは以下の3種類あります。

  • IMLibLocalContext：ローカルコンテキスト
  • IMLibContext：データベースから取り出したコンテキスト
  • IMLibContextPool：コンテキスト群を管理するオブジェクト

このうち、IMLibContextについては、new等、生成をして利用します。他の2つは1つだけでいいので（つまり、シングルトンでいいので）、そのまま使います。IMLibLocalContextについては、別の記事で説明しています。この記事では残りの2つを解説します。

IMLibContextは、エンクロージャ／リピーターの識別があるごとに1つのオブジェクトが生成されます。いくつかプロパティがあり、それぞれ動作上は細かい説明が必要かとは思いますが、まず、いちばん重要なプロパティは、storeとbindingです。いずれも多次元の連想配列、つまりオブジェクトのオブジェクトという形式になっています。1次元目はレコードを示すキーで、主キーフィールド名がid、そのフィールドの値が45なら「id=45」という文字列をキーとして仕様します。2次元目はフィールド名です。storeプロパティは、this.store[‘id=45’][‘birthday’]という要素に対して、その値が代入されています。

一方、bindingプロパティは、this.binding[‘id=45’][‘birthday’]という要素に対して、{id: id属性値, target: ターゲット}形式の配列になっています。階層の深いオブジェクトです。つまり、bindingは、あるレコードのあるフィールドの値を、ページ上のどの要素に設定したかを記録するものであり、id属性値とターゲットが必要です。また、複数の要素に値を設定することもあるので、オブジェクトの配列で記録しなければなりません。

さらに、要素のid属性とターゲットから、コンテキスト、レコード、フィールドを知るために、contextInfoというプロパティを用意しあり、this.contextInfo[id属性値][ターゲット]という要素に対して、{context: this, record: recKey, field: key} といったオブジェクトが保存されています。なお、ターゲットは””もあるので、その場合は”_im_no_target”に置き換えて記録します。

これらに直接アクセスして利用することも可能ですが、IMLibContextPoolでは生成したコンテキストすべてを把握していて、ここからコンテキストに対するさまざまな処理ができるようにメソッドを用意しています。これは一種のMediatorパターンです。

  • IMLibContextPool.getContextInfoFromId(id属性値, ターゲット)
    • 引数に指定したid属性値を持つ要素の指定したターゲットにバインドしているコンテキスト情報（キーとして、context、record、fieldを持つ）を返す
  • IMLibContextPool.contextFromName(コンテキスト名)
    • 引数に指定したコンテキスト名を持つコンテキスト（IMLibContextクラス）のうち、最初に見つかったものを返す
  • 《IMLibContext》.getValue = function (recKey, key)
    • コンテキスト内にある指定したレコード（”id=45″）とフィールド（”birthday”） の値を返す
  • 《IMLibContext》.getContextInfo = function (nodeId, target)
    •  引数に指定したid属性値を持つ要素の指定したターゲットにバインドしているコンテキスト情報（キーとして、context、record、fieldを持つ）を返す
  • 《IMLibContext》.getContextValue = function (nodeId, target)
    •  引数に指定したid属性値を持つ要素の指定したターゲットにバインドしているコンテキスト内での値を返す
  • 《IMLibContext》.setValue = function (recKey, key, value, nodeId, target)
    • コンテキストに値を設定する。nodeIdがnullの場合、最初から3つの引数（レコード、フィールド、値）により、値が記録されると同時に、同じレコードの同じフィールドを持つ他のコンテキストに対しても値の同期を行う。nodeIdとtargetを指定すると、値は自分のコンテキストにのみ設定し、同時にbindingなどの連携情報を設定する。通常はnodeIdはnullを指定してコンテキストへの設定と他のコンテキストへの同期処理をさせることが多いと思われる

 

IMLibContextPoolが記録している全てのコンテキストを得るには、プロパティのIMLibContextPool.poolingContextsを利用します。ここにコンテキストの配列が設定されています。

[IM] コンテキストを実体化する改良

4月からずっと、ちょっとずつ、INTER-Mediatorを改良してきました。内部の構造については別記事にまとめる予定です。

INTER-Mediatorでは「コンテキスト」という概念を、データソースつまりデータベースから得られる結果に当てはめています。単にテーブルということではなく、テーブルから得られた列構造を持つレコードの集合を「コンテキスト」として位置づけています。たとえば、住所録から「会社関係」「親戚関係」といった分類をして取り出すとすると、それは住所録テーブルから得られるものではありますが、列構造を持つレコード群が、意味を持ちます。そうした意味付けされてデータベースから取り出された結果をコンテキストと読んでいます。システムのアーキテクチャとして、DCI（Data, Context and Interaction）という手法が提唱されていたりしますが、そこでのコンテキストと同じ意味です。この考え方は別に新しいものではなく、FileMakerなどでも見られる概念です。ただ、コンテキストと抽象的に説明すると分かりにくくなり、一方で「検索条件を適用したテーブルアクセス結果」というとあまりに陳腐な感じになってしまい、とらえどころのない用語でもあります。

これまでのINTER-Mediatorでは、コンテキストは「定義する」ものでした。定義ファイル（.phpファイル）で、どのテーブルあるいはビューであり、主キーは何で、検索条件やソート条件は何でと言ったいちれんの設定を「コンテキスト」と読んでいました、この定義ファイルにあるコンテキストに名前をつけて、その名前をページファイル（.htmlファイル）側から参照します。シンプルに説明するときには、ページファイルにテーブル名とフィールド名を書けば、その要素とフィールドがバインドして、データを表示し修正すれば書き直しができるという言い方をします。しかしながら、正確には、コンテキストとして意味付けされた一連の列構造を持つレコード群を、ページ上に展開するということです。従って、同じテーブルから一覧表を作る場合と、単一のレコードを示す場合では、目的が違うので、「異なるコンテキストを要求している」と見なして、定義ファイルに別々のコンテキストを記述するというのが原則と考えています。

定義ファイルに記述した、コンテキストの仕様に相当する者は、「コンテキスト定義」と呼ぶ事にします。

一方、このコンテキストに従った動作をするために、内部的には明確な形でオブジェクトを作っていませんでしたが、それを実現しました。内部的なコンテキストは、クライアントのブラウザ内でオブジェクトとして存在し、一つの見方はデータベースの内容のプロキシです。データベースの内容は、コンテキストのオブジェクト内に「再現」されていると考えてください。加えて、コンテキスト内のデータと、ページ上の要素あるいはその属性との間でのバインドが実現されており、たとえばテキストフィールドでデータを修正すれば、コンテキストオブジェクトの関連したデータも更新されることを自動的に行えるようにしました。

ただし、ここで、内部的なコンテキストは、JavaScriptからタッチすることは可能で、プログラマに対して解放されているとも言えますが、一方で、INTER-Mediatorはそうした手続き的なプログラミングを必要としなくても多くの目的をまかなえるように作りたいことがあります。本来、こうしたバインドの実装は、厳密な意味ではオブザーバブルな実装が必要になりますが、まずは、メソッドベースでの実装を行うことにしました。従って、オブザーバとオブザーバブルは明確になっていない実装になり、そうした仕組みの拡張については今後の課題と考えています。現状は、コンテキストのオブジェクトのメソッドを使って値を設定すれば、同じレコードの同じフィールドの結果を表示している他の要素にも変更結果が伝わるという状態にしてあり、スタティックな意味でオブザーバブルになっています。

こうした内部的にコンテキストを持つことに対して、データベースと連動しない「ローカルコンテキスト」も実装しました。ローカルコンテキストは、ターゲット指定でのコンテキスト名に「_」を使い、フィールド名は自由に使います。次のような2つのテキストフィールドを用意します。そして、INTERMediator.construct(true); を実行します。すると、一方に入力してタブキーでchangeイベントを発生させると、他方のテキストフィルドに入力したデータがコピーされます。連動させるためのプログラムの作成は必要ありません。

<input id="tf1" type="text" data-im="_@feeling" />
<input id="tf2" type="text" data-im="_@feeling" />

このローカルコンテキストは、FileMakerで言えば、グローバルフィールドのようなものです。また、ターゲット指定からそのテキストフィールドの値を取り出すメソッドも用意しているので、他の機能との統合を行うときにも気軽に利用できます。以下のように、IMLibLocalContextで参照されるオブジェクトでローカルコンテキストは実現されており、getValueメソッドで引数にターゲット指定のフィールド名のみを指定することで、テキストフィールドの値を取り出すことができます。

var inputValue = IMLibLocalContext.getValue("feeling");

ローカルコンテキストはクッキーに記録されるような動作を考えました。たとえば、検索条件をテキストフィールドに入れていれば、別のページから戻って来たときにも元の検索条件を覚えているような動作を自動化させたいからです。ただし、この動作については、おそらくさまざまな要求が実際の開発では発生すると思われるので、ぜひとも使ってみた意見をいただきたいです。

ページナビゲーションの「更新」ボタンをクリックすると、このローカルコンテキストのクッキーによるキャッシュをクリアします。

[IM]ドキュメントの方針

INTER-Mediatorについて、ドキュメントをもっと充実させるべきという声は常に聞かれますし、その通りだと思います。とは言え、いかに効率的に作るかを考えないと、本体以上に破綻するかもしれません。ドキュメントはテストドリブンでの制作はできないのですから。そういうわけで、当面の方針をきちんと作り、そして書いて、実行することにします。

以前は、最終的には「パターン」への落とし込みが重要ではないかと考えていましたが、パターンとして落とし込むには、知の集約が必要であり、一定期間に少人数でできることではありません。既存のパターンを使うとしても同様です。

現在考えているのは、プラクティスの充実です。たぶん、サンプルや例題というのもプラクティスの一つなのでしょうけど、サンプルは説明がしづらいとか、デバッグ用に無意味な組み合わせの機能があるとか、プラットフォームを初めて見る人には辛いものです。その意味で「例題」なのですが、fluent 2014に言ったときにEmber.jsのセッションで言われていたのは「フレームワークはコミュニティのプラクティスを取り込まないといけない」というところで、ピンと来ました。例題の題材は、コミュニティにあるものを採用しないといけないということです。機能説明になっては本末転倒になるというところでしょうか。そういうわけで、プラクティスという言葉がきっかけで、やるべきことが整理された気がします。

ソフトウエアプラットフォームの開設のための文書にどのようなタイプのものがあるかを考えてみました。マーケティング的なことを抜きにして、利用者（通常は開発者）に対するコミュニケーションのためには次の4つがあるのではないかということです。

  • 仕様の記述：当然必要、網羅性が求められる
  • チュートリアル：手を動かして学習、INTER-Mediatorでは有償コンテンツとして用意
  • プラクティス：これから充実させたい
  • パターン：抽象度の高いノウハウ

今は、プラクティスを充実させる段階であり、それが一段落してからパターンに進むのが手法としてはステップを踏む感じがするのです。

プラクティスとして作成する予定のテーマは次の通りです。もちろん、みなさんからの要望やアドバイスを期待します。とは言え、あまり重いものはプラクティスではなく、実システムになってしまい、微妙なところです。以下の5、6はえらく長くなりそうですし、むしろ上級向けのチュートリアルのテーマではないかとも思います。

  1. 検索をしてその結果を一覧表示する
  2. 一覧表示と詳細表示を行き来する
  3. アンケートなどの入力のみのページ
  4. 伝票形式のページを作成する
  5. 会員制サイト（ヘビーか？）
  6. カート（不要か？）

一方、「こういう作りのページを簡単に作れることは意図していない」という、ある意味のアンチプラクティスも記述が必要と考えています。たとえば、こんなテーマです。とりあえず、1つだけです。

  1. 入力フォームの後の確認ページが不要な理由

ということで、プランを立てないと前に進めない気がするので、とりあえず、書いておこうと思います。

[IM]ローカルコンテキストの利用方法

INTER-Mediatorでは、タグのdata-im属性に、「テーブル名@フィールド名」の形式で記述するターゲット指定により、そのタグ要素がデータベースのフィールドにバインドされて、データベースから読み込んだデータを表示し、フォーム用のコンポーネントであればユーザによる変更結果をデータベースに書き戻す事が自動的に設定されます。しかしながら、データベースとは関係ない記憶領域があると何かと便利です。言い換えれば、データベースにしか保持できないとなると設計の順内製がそがれます。そこで、クライアントサイドの計算フィールドを実装し、さらにローカルコンテキストという機能を実装しました。

ローカルコンテキストの利用方法

ローカルコンテキストとは、データベースと連動していない記憶領域で、テーブル名は一律に「_」を使います。フィールド名は任意の変数名でかまいません。Sample_searchでは、type属性がtextのINPUTタグに対して、<input type=”text” data-im=”_@placeCondition”/> という設定を行いました。placeConditionがローカルコンテキスト内の名前です。この記述をするだけで、テキストフィールドに一度入力したデータは、ページを更新しても必ず再現されます。イメージとしてはどこかに記録されて、それが必要に応じて自動的に復活すると考えてください。保存場所はクッキーの中です。

通常のコンテキストは、1つのコンテキストに複数のレコードがあり、そのレコード内にフィールドがあるという構造です。ローカルコンテキストは「レコード」という構造がありません。コンテキスト名も常に決まっているので、実質的にはシンプルなキーバリューストアと同一です。一般のコンテキストは、エンクロージャーとリピーターという繰り返しを誘発する階層構造をベースにしますが、ローカルコンテキストは1ページごとに1つずつ持っており、どこにどう書いてもかまいません。同一のフィールド名のタグ要素が複数あれば、それらでの編集結果も連動します。

ローカルコンテキストへの直接アクセス

テキストフィールドがある場合、そこに入力した値を取り出すのは、通常はgetElementById等を使ってノードを参照します。一方、ローカルコンテキストを利用したテキストフィールドなら、ローカルコンテキストから値を取り出すほうが確実です。たとえば、前述のinputタグ要素の場合、

var c1 = IMLibLocalContext.getValue("placeCondition");

とすれば、テキストフィールドに入れた値を取得できます。なお、テキストフィールドをローカルコンテキストに反映するタイミングは、フォーカスがはずれたとき、つまりonchangeイベントで行っています。もし意図的に値をローカルコンテキストに記録するには、

IMLibLocalContext.setValue("placeCondition", value);

と記述します。

計算式の中に、ローカルコンテキストのリンクノードを参照する記述「_@field」などがあった場合、他のコンテキストにあるフィールドと同様なルートで検索します。つまり、同一のエンクロージャーを探し、なければ上位のエンクロージャを探してその子孫のノードを検索します。

ローカルコンテキストは、URLにひもづくクッキーに記録し、とりあえず、期限は1年にしてみました。いろいろなタイミングで自動的にクッキーに記録し、一方でクッキーから取り出すので、ほぼ、そういうことは意識しなくてもいいのですが、この後に説明する件で、一部のブラウザで書き込みを明示的に記述しないといけない場合があります。

連動するプロパティ

こうして、ローカルコンテキストが稼働しているので、一部のプロパティについては、ローカルコンテキストで保持することにしました。

INTERMediator.startFrom = 0;
INTERMediator.additionalCondition = {};
INTERMediator.additionalSortKey = {};

これらは、前から順番に、検索結果の何レコード目から表示するのか、追加の検索条件、追加のソート条件となります。たとえば、ユーザインタフェースを使って、追加の検索条件を与えると、それがローカルコンテキストに記録されて、事実上永続化されます。検索条件は、随時適用されるので、検索条件を与えるといつまでもその条件が適用されるようになります。

これらの動作に関連する情報は、以下のキー名を使ってローカルコンテキストに保存しています。なお、_im_で始まるキーは、システム予約としておきます。今後、こうした記録が増える可能性があります。

_im_startFrom
_im_additionalCondition
_im_additionalSortKey

たとえば、検索条件を特定のコンテキスト「context」に対して設定する場合、例えば、次のように記述するのは、従来と変わりありません。

INTERMediator.additionalCondition['context'] = {
    field: 'zipcode',
    operator: 'LIKE',
    value: IMLibLocalContext.getValue("criteria") + '%'
};

このとき、背後では、ローカルコンテキストに右辺のオブジェクトを記録し、さらにクッキーへの記録まで同時に行います。

Internet Explorer 8での対処

Ineternet Explorer Ver.8のみ、プロパティに記録したデータを自動的に永続化する事ができません。IE8の場合のみ、INTERMediatorオブジェクトのstartFrom、additionalCondition、additionalSortKeyプロパティに設定した直後に、

IMLibLocalContext.archive();

という呼び出しを入れて、ローカルコンテキストに反映しつつ、クッキーへの保存を行うようにします。IE9以降や、その他のブラウザではこの呼び出しはなくてもかまいませんが、あっても問題はありません。ただし、同じ作業を複数回行うことになるので、効率は低下します。INTER-Mediatorの内部ではIEやそのバージョンの把握を行っているので、たとえば、次のように記述すれば、IE8の場合だけ、前述のメソッド呼び出しが実装できます。

if (INTERMediator.isIE && INTERMediator.ieVersion < 9) {
    IMLibLocalContext.archive();
}

[IM]メールをポストする機能を追加

2014/2/15にコミットしたINTER-Mediatorでは、メールの送信を機能として組み込みました。つまり、メール送信の処理をプログラムを一切しなくても、宣言的な記述だけでできるようになりました。

まず、メールはサーバで送ります。送信方法は、PHPのmail関数を使う方法なので、UNIX系ならsendmailコマンドをたたく方法になります。一方、これだとSMTPサーバへの転送ができないので、qdsmtpも組み込みました（Thanks to Mr. Spok）。SMTP認証はPlainのみの対応となっています。Windowsの場合はmail関数がすでにSMTPですので、php.iniにサーバ情報などを書くことで対処できます。なお、Windows環境はチェックしていないので、何かあれば知らせてもらえると助かります。

ただ、これだけではだめだろうというのはご存知の方はお分かりかと思いますが、昔作っていたOMEというメールソフトにはPHPのクラスもあったので、それをUTF-8で動くように改造してエンコードなどをさせるようにしました。ちなみに、さらにその前に『メール送信システムの作り方大全』という書籍も書いていて、その中の一部のクラスを使いやすいようにしたのがOME.phpです。この本、もう10年以上前なのですね…。

定義ファイルに指定可能なキーワードは以下の通り全て列挙します。しかしながら、すべてを記述することはないです。

IM_Entry(
    array(   // Contexts
         array(
            'name' => 'request',
            'send-mail' => array(
                 'new' => array(
                    'from' => '',
                    'to' => 'email',
                    'cc' => '',
                    'bcc' => '',
                    'subject' => '',
                    'body' => '',
                    'from-constant' => 'Officer <info@msyk.net>',
                    'to-constant' => 'msyk@me.com',
                    'cc-constant' => 'businessmatching@cocoa-study.com',
                    'bcc-constant' => '',
                    'subject-constant' => 'Cocoa勉強会ビジネスマッチング申し込み',
                    'body-constant' => 'テストメール',
                    'body-template' => 'welcome.txt',
                    'body-fields' => 'name,compnay,email,tel',
                    'f-option' => true,
                    'body-wrap' => 68,
                 )
             )
         )
    ),
    array(   // Options
        'formatter' => array(...),
        'smtp' => array(
            'server' => 'mysmtp.msyk.net',
            'port' => 587,
          　　　'username' => 'msyktest@msyk.net',
            'password' => 'oshienai',
        )
    ),
    array('db-class' => 'PDO'),
    false
);

メールを送信するタイミングの指定

‘send-mail’キーの配列の次のレベルのキーとして、’load’ ‘edit’ ‘new’のいずれかを指定できます。それぞれ、データベースからの読み込み時、更新時、新規レコード作成時を意味し、コンテキストに対するそれぞれのタイミングでメールを送信します。いずれも、データベース処理が終了してからメールの送信にかかります。上記の例では、新規レコード作成時に、メールが送信されます。

宛先や送信者の指定

宛先の指定は、’to’ないしは’to-constant’キーに指定します。もし、宛先が一定のものであれば、’to-constant’キーに指定をしてください。’to’キーにはフィールド名を指定します。データベース処理の結果、たとえば新規レコードの場合には新しいレコードが1つ作成されて、そのレコードの内容から’to’キーに指定したフィールドより宛先のデータが取り出されます。編集も原則は1レコードです。一方、読み出しの場合は1レコードにならないかもしれませんが、その場合は最初のレコードから取り出します。むしろ、1レコードに絞り込むコンテキストにするのがメールを送る場合には妥当だと考えられます。

メールアドレスは「名前 <アドレス>」ないしは「アドレス」の2つの形式のみのサポートになります。’to-constant’キーに対する値、あるいは’to’キーで指定されるフィールドの値は、このどちらかの形式にしてください。

cc、bccについてもまったく同様のルールです。’to’と’to-constant’の両方の指定があれば、’to-constant’が優先されます。cc、bccでも-constantが優先となります。

fromについても、fromとfrom-constantキーがあり、設定や動作等は同じです。ただし、UNIXでSMTPサーバを使わない場合だと、通常はソース側のFrom:は無視されて、UNIXアカウントそのものをFrom:として設定してしまいます。ただし、サーバ側で許可されていれば「’f-option’ => true」の指定を定義ファイル内に記述することで、sendmailコマンドの-fパラメータを指定して、送信者の指定が可能です。

件名と本文の指定

件名は、subjectあるいはsubject-constantのいずれかのキーに指定します。toなどと同じルールです。

メールの本文は、定義ファイル内に指定した通りに送信する’body-constant’、フィールドの内容をそのまま送信する’body’に加えて、テンプレートの処理も可能です。優先順はテンプレート、body-constant、bodyの順になりますので、不要なフィールドは消しておきましょう。

テンプレート処理をするには、テンプレートのファイル名をbody-templateキーに指定します。このとき、テンプレートのファイルは、定義ファイルのあるディレクトリを基準に検索します。つまり、定義ファイルといっしょに何らかのテキストファイルを億としたら、body-templateキーの値はファイル名だけでかまいません。

テンプレートのファイル内では、そのファイルの内容を本文にしますが、フィールドの値との置き換えも可能です。置き換えたい箇所に@@1@@、@@2@@のように、アットマーク2つに囲まれた1から始まる整数を指定します。テンプレートのファイルはUTF-8で保存します。

フィールドについては、’body-fields’キーに、半角のカンマで区切って指定します。最初が1で、順次番号が増えるようになります。例で言えば、emailフィールドの値は、テンプレート内の@@3@@と置き換わって表示されます。’body-fields’キーを省略すると、テンプレートのファイル通りにメールが送信されます。

本文は一定の長さで改行を入れます。既定値では72バイトですが、’body-wrap’キーで異なる値にできます。0に設定すると改行しません。ここで、バイト数ですが、実際のバイト数ではなく、日本語は2バイト、英語は1バイトと数えた結果で示しています。実際のエンコードはUTF-8なので、嘘と言えば嘘のカウントになりますが、おそらくこうして指定をすることに慣れている人が多いので、ここでは実態とは関係ない数値ではありますけども実用的という意味で「2バイトルール」でカウントしたものとします。

UNIXの場合のSMTPサーバの指定

定義ファイルのIM_Entry関数の第3引数のオプション領域に’smtp’キーで配列を指定します。その他のキーは、前記の例の通りで、キーを見れば意味は分かると思います。もし、SMTP認証をしない場合は、serverとportだけを指定します。認証する場合は、server, port, username, passwordを指定します。したがって、2つないしは4つの要素があるかのどちらかになります。

SMTPサーバの指定は、params.phpファイルでも指定が可能です。変数名として、$sendMailSMTPの定義し、値は’smtp’の右側の配列と同様に指定をします。params.phpファイルでの指定よりも、定義ファイルの指定が優先されます。どこにもSMTPサーバの設定がない場合には、mail関数での送信になります。

Windowsの場合は、’smtp’の指定やparams.phpファイルでの指定は一般には不要ですが、もし設定すれば、mail関数ではなく、qdsmtpによるメール送信ができます。

送信されるメールの文字セット

基本的にはメールはUTF-8でエンコードして送られます。ISO-2022-JPの指定はOME.phpではできるのですが、必要なら定義ファイルでの指定ができるようにしようと思います。リクエストがなければUTF-8固定で行きます。

ヘッダについては、base64のインラインエンコードを、ASCIIコード以外の文字について行います。本文はそのままですが、ヘッダのContent-TyleのcharsetにUTF-8という文字を付けます。つまり、本文はbase64等でのエンコードは行いません。

ファイルの添付は実装する予定はありません。ファイルを送りたいのなら、そのリンクを送るようなアプリケーションの動作にしましょう。

Internet Explorer 8にまた苦しめられる

Web系のお仲間の皆さんも同様にいつも苦しめられていると思われるIE8ですが、ここ最近にあったいくつかのはまりポイントを自分の備忘録としてもまとめておきます。まあ、あと数年はIE8からは逃れられないということで。

  • jQuery 2.0を入れたら動かない（対応ブラウザからはずれている）。慌てて1.10に戻す
  • JavaScriptではObject.keysという記述が使えない
  • 要素のid名と同一のグローバル変数が作られる

特に最後のは苦労しました。メッセージを見る限りは、「オブジェクトでサポートされていないプロパティまたはメソッドです。」と出ます。プログラムはこんな感じ。INPUTタグ要素で、idが「yourname」になっていると思ってください。

yourname = document.getElementById("yourname").value;

まさかgetElementByIdが使えないのかと思ったら、使えます。他の箇所では動いている。valueがない訳は絶対にない。当然右辺を疑うわけですが、必死に検索した結果、問題は左辺でした。つまり、以下の条件が満たされると発生されるトラブルだったのです。

  • IE8でJavaScriptでプログラムを組む
  • ページ内の要素のid属性と同一の変数を、何も定義しないでJavaScript側で使う

どうやら、IE8は、id属性と同一名のグローバル変数を勝手に定義するようです。上記のプログラムは、つまり、勝手に定義しているyourname変数が何らかのオブジェクトを記録していて、そのオブジェクトが書き換えに対応していないためにエラーが出ていると思っていいようです。

対処法は「var yourname」のように頭にvarを付けるか、ページにリンクされたjsファイル等でグローバルとして「var yourname;」のように変数定義することで回避できます。自分自身のグローバルでも、同一名称の変数は後から定義した方のストレージが有効になるので、IEが勝手に作るグローバル変数は無視されるようになるということです。つまり、変数定義を必ずしろというプラクティスをしていれば、エラーに合わないのですが、こう書いてしまったらエラーになってしまうよということですね。

[IM] バージョン入りのINTER-Mediatorを生成する

INTER-Mediatorを使って開発をするとき、レポジトリからプルした結果を使うという話を別の記事で書きました。もちろん、動く状態としてそのままをアップしてもいいのですが、ページ最後に出ているINTER-Mediatorの帯のバージョンが@@1@@などといった文字列になっていて、ちょっと雑な感じがすると思います。独自のバージョンと本日の日付を組み込んだ現状のINTER-Mediatorを作るには、dist_docs/buildup.shというスクリプトを使ってください。

たとえば、INTER-Mediatorのディレクトリがカレントディレクトリであれば、

cd dist_docs
./buildup.sh

とコマンドを入力します。すると、だーっと何か出て来て、INTER-Mediatorフォルダと同じ階層に、「INTER-Mediator-4_2.zip」などとバージョン入りのフレームワークが作られます。中身は現状のINTER-Mediatorフォルダの内容とほぼ同じですが、日付とバージョンが入ったものになります。

INTER-Mediator-4_2.zipファイルを展開すると、「INTER-Mediator-4_2」フォルダが出来上がります。現在のINTER-Mediatorフォルダの名前を変えるか削除して、「INTER-Mediator-4_2」フォルダの名前を「INTER-Mediator」フォルダすれば置き換え完了です。同じディレクトリにあるtempフォルダは一時領域なので、これも削除してOKです。

なお、このとき、INTER-Mediatorフォルダと同じフォルダに、yuicompressor-2.4.7.jarファイルがあれば、これを使ってJavaScriptのプログラムを圧縮します。ない場合には圧縮しないで、いくつかあるJavaScriptのファイルを1つにまとめることだけを行います。なお、別のバージョンのものを使う場合には、buildup.shファイルの最初の方にパスを記述する箇所があるので、それを修正してください。

バージョン番号については、同様に、buildup.shの最初の方に記述があるので、それを変更して利用してください。なお、バージョンのルールは次のようにします。

  • バージョン番号は、整数をピリオドで区切ることとする（例：3.4、3.11）
  • バージョン表記は、Ver.を基本とするが、vでもVersionでもversionでも基本的には構わない
  • 整数が2つのものを「正式バージョン」とする（例：3.4、3.11）
  • 開発者が独自にバージョンを付ける場合、3つ目の整数を必ず付ける（例：3.4.1、3.11.133）

つまり、INTER-Mediatorをダウンロードして、実際にアプリケーションに搭載する上で少し修正したとしたら、3つ目の整数で枝番号を付けてくださいということです。できれば、その状態をコミット/プッシュした上で、そのバージョンタグをつけていただけると、自分のバックアップ用にもなると思います。他の人とバージョンが重ならないように、レポジトリをチェックして異なる番号を付けてください。また、3桁目は飛び番号でもいいとしましょう。けっこう緩いルールですね。