Blog by msyk

INTER-Mediatrorの再構築はいいところまで行きそうなところで、実はつまずきました。Enclosure/Repeater/Linked Elementという階層を考えていたのですが、EnclosureでありLinked Elementなもの、RepeaterでありLinked Elementであるものもあります。そこを考慮していなかったので、少し戻らないといけなくなってしまいました。まずは図を書いて考えます。

 

また、実際のタグと展開パターンをまとめておいて、再検討に入ります。こう考えると、３種類のオブジェクトに分離しているのは、表だけですね（苦笑）。

 

形態	Enclosure	Repeater	Linked Element
表	TBODY	TR	any elements
汎用	DIV._im_enclosure	DIV._im_repeater	any elements
番号リスト	OL	LI	LI itself or inside of LI elements
箇条書き	UL	LI	LI itself or inside of LI elements
ポップアップ、リスト	SELECT	OPTION	OPTION itself
ラジオボタン、チェックボタンリスト	DIV._im_enclosure	INPUT [@type=readio or check]	INPUT itself

しばらく超忙しかったので、INTER-Mediatorに手を付けられなかったのですが、そろそろ戻れそうです。

Ver.5までのINTER-Mediatorは、テンプレートになるHTMLファイルを.phpにして、ページの冒頭にパラメータを定義してPHP関数の呼び出しを行う事で、生成したJavaScriptのプログラムをマージしていました。リストラクチャで、そのあたりの仕組みを変更します。今作っている部分は、あるページがあって、それがテンプレートとして機能させる場合、次のようなファイル構成にします。

テンプレートのHTMLファイル：たとえば「test.html」

サポートのPHPファイル：たとえば「Sample1.php」

これら2つのファイルを用意します。以後、「たとえば」のファイル名で具体的に説明します。Sample1.phpは、JavaScriptのソースを戻すスクリプトです。そこで、test.htmlのヘッダ部分に以下のような記述を加えます。

<scripttype="text/javascript"src="Sample1.php"></script>

データベースに必要なパラメータは、Sample1.php側に記述します。具体例は、GitHubにあるソースを見てください。

test.htmlのbodyタグのonloadで、たとえば、次のようなJavaScript関数を呼び出すと、テンプレートの展開を行うようになります。

function im_start()	{
var im = new INTERMediator( );
im.showMessages();
}

ページのロード後に最初のテンプレート展開が行われ、そのときに、必要なテーブルへのアクセスを行います。その部分はAjaxで動きますし、保存や更新等の処理でも、同様にAjaxで行います。これらは、HTMLページからはSample1.phpをそれぞれ必要なパラメータで呼び出します。従って、Webサーバで公開していないといけないPHPのスクリプトはSample1.phpだけで、INTER-Mediatorのスクリプト群についてはWebサーバで公開していないところにも移動できるようになります。

この方針で進めることにしました。

これまでのプログラミングで、元になるHTMLから、リンクした要素を拾い出し、リカーシブに集めることができるようになっています。集めたノードの配列から、あるリピーターに対するテーブル名とフィールド名のリストがデータベースアクセスには必要です。

INTER-Mediator.jsのexpandEnclosure関数でこれらの処理を続けています。リンクした要素は配列linkDefsに入ります。INPUT/TEXTAREA/SELECT要素があると、それを書き戻す処理を追加する必要があるので、これらがあるかどうかのチェックを行います。それを行いながら、リンクした要素の定義を連想配列に入れ直しておきます。入れ直した結果は配列linkDefsHashです。

そして、それらの中で、いちばん多く指定されているテーブル名を取り出し、リピーターに対応するテーブルとします。テーブル名 ” もありとして、これは定義の最初のテーブルを取得する事にします。このルールで運用すれば、一連のリンクした要素ではすべての定義にテーブル名をきちんと入れる必要はなく、最低でも1つ入っていればいいわけです。

しかしながら、テーブル名が2つ以上ある場合はどうなるかと言えば、そのうちの1つのテーブル名が使われ、テーブル名を省略している定義の場合は決定されたそのテーブルのフィールドであると見なします。結果的に使われないリンクした要素が登場することになります。異なるテーブルを指定したリンクした要素があれば、ノードツリー上で前にある方の設定が有効になります。いずれにしても、1つのテーブルを決定し、それ以外のテーブルの指定のリンク要素は無視となります。

ここまでのプログラミング結果は、githubの以下のURLで参照できます。（こういう使い方できるのですね〜）

http://github.com/msyk/INTER-Mediator/tree/4bc62c2235d65e7c28097be419bb4fc43635dc60

続いて、いよいよ、データベースとの連携部分の再構築を行います。ここまでのプログラミングを行いながら、HTMLソースを極力いじらない手法を取ることを実現すべく、Ver.0.5までの「HTMLソースにPHP関数を入れる」というのではなく、データベース定義もサーバ側のファイルに残す方法がよりスマートと考えます。

INTER-Mediatorでは要素が「どのテーブルのどのフィールド」なのかを記録していなければなりません。しかしながら、より汎用的に、どの属性なのかあるいはテキスト要素なのかを指定することも必要です。再構築前はTITLEなどを利用し要素のタグによってデータベースのデータが差し込まれる場所が決まっていましたが、それを汎用化します。

まず、「どのテーブルのどのフィールドなのか」という情報を、「要素のリンク指定」と呼ぶ事にします。要素のリンク指定は、TITLEないしはCLASS属性を使うということにしようと思います。両方も、一方だけでもOKとします。

TITLEの場合は、

<input title=”table@field” name=”email” />

などと記述します。CLASSの場合は、他のものとの区別を付けるため、

<input class=”IM[table@field] mailfield” name=”email” />

のようにIM[*]の形式で記述します。classにはいくつかのデータが入り、確実に区別したいので、恣意的なマーキングを要求しようと思います。

それから、同じセパレータで区切って、どの属性にセットするのかを指定できるものとします。たとえば、input要素ならvalueに設定したいわけですから、

<input title=”table@field@value” name=”email” />
<input class=”IM[table@field@value] mailfield” name=”email” />

と書くものとします。@で区切った3つ目のコンポーネントがないものは、その要素のテキスト要素になるものとします。たとえば、

<div class=”subtitle IM[table@field]”></div>

は、フィールドの値を、開きタグと閉じタグの間に展開します。

また、別の区切り文字（デバイダーと呼ぶ事にします）によって、複数の属性およびテキストデータに展開するものとします。つまり、デバイダーを縦棒の | としたら、

<option class=”IM[table@id@value|table@name]” />

とすることで、

<option value=”idフィールドの値”>nameフィールドの値</option><

と展開するようにします。

要素を展開したときには、従来の方法では、@1 @2 …をあとに付けていましたが、これはデータベースに書き込みを行うための区別を行うためです。これについては、もう少し開発が進んでからどうするのかは改めて考えます。というのは、書き込みが必要なのは、INPUT、SELECT、TEXTAREAのフィールドだけになります。要素のリンク指定に繰り返し生成された情報が必要なのか、あるいはid属性で何とかなるのか、そのあたりは今後の検討課題とします。

もとになるHTMLによるDOMがあって、そこからデータベースのデータに置き換わったノードが展開される様子を一般的に記述できるように、改めて解析を行います。概ね、左の図がもとのDOMで、エンクロージャーを起点にしてリピーターが展開されれたものが右側です。リピータの繰り返し処理を行う場合、リピーターはいったんエンクロージャーの子ノードではなくし、そのクローンを作ってデータベースからのデータを設定し、エンクロージャーの子ノードとして追加するという作業を行います。つまり、R10はノードのひな形であり、実際にデータベースの内容を展開するのは、そのクローンであるR11、R12…です。R10に含まれるリンクされた要素のL101は、データベースの値を設定された場合にはL111、L121となっています。いずれにしても、この番号付けのルールはうまく重複は存在しません。ただし、単に十進数にすると、桁が増えたときの問題になりますので、ユニークな識別子は各桁をハイフンで結ぶなどする必要があります。最終的には、各ノードのidフィールドを与える必要があるので、「R-1-2-1-1」のような各桁をハイフンで区切った文字列を識別子とします。このような識別子にしておけば、リンクされた要素からエンクロージャーやリピータを見つけるのがやりやすくなります。なお、リピーターが複数の要素からなる場合は、「R-1-2-1-1-1」のように一桁多くしておきます。リピーターは「R」以下、偶数桁なので、奇数桁となっている場合には末尾が複数の要素の何番目かを示すものであることが分かります。また、数値の0はひな形、1以降が展開された要素を示すというルールにします。

 

この図から、一連の処理を以下のように組み立てることができることが分かります。これにより、リカーシブにノードをたどることで、すべてのエンクロージャー／リピータをデータベースの内容に置き換えて複製展開できます。つまり、seekNodesとexpandEnclosureを順次呼び出すことで、展開ができるということになります。

1. seekNodesにより、最上位のノードから見たときに最初に到達されるエンクロージャーが見つかる
2. そのエンクロージャーに対してexpandEnclosure関数を実行する
3. expandEnclosureでは、リピータをエンクロージャーから取り除き、そのクローンを作って複製する用意をする
4. 続いて、リンクされる要素を探し出してリストアップする
5. リストの情報からデータベースヘ接続し、関連付ける必要のあるデータを得る
6. レコードの数だけリピータの複製、データの埋め込み、エンクロージャーへの追加を行う
7. リピーターを起点として、seekNodesによりエンクロージャーを見つける
8. エンクロージャーに対してexpandEnclosure関数を実行する
9. …以下繰り返し

 

ここで考える必要があるのは、主キー／外部キーのデータを伝達する必要があるということです。expandEnclosure関数ではデータベースにアクセスしてデータを取り出しますが、そのとき、現在のエンクロージャーの上位のエンクロージャーで展開しているリピーターとの連動が必要です。すなわち、上位から、テーブル名、主キーフィールド名、その値をもらわないといけません。つまり、expandEnclosure関数で、これらを引数として引き渡す必要があります。そして、現在のエンクロージャーのリピーターを展開するためのデータを得る時、リピーターに対応するテーブルにおいて、上位のリピータととのリレーションが設定されているかどうかを確認し、設定されているようなら、上位のエンクロージャーからの情報を検索条件に含める必要があります。

なお、このあたりで、ずっと関数で書いていたプログラムを、オブジェクトにカプセル化することにします。当面、外から呼び出すのに必要なメソッドはないので、単にこれまでに書いて来た関数を、以下のようにコンストラクタの中に閉じ込めてしまうことにします。

function INTERMediator( rootNode ) {
 
seekNodes( rootNode );
      :
}
}

 

HTMLドキュメントからリピーターを検出し、データベースのないように置き換えるための処理手順を検討します。ここで、ドキュメント内のノードの一部を取り出したものが以下の図です。「エンクロージャー」「リピーター」に加えて、データベースのデータを受け入れる「リンクされた要素」があるものとします。

.5までは、リンクされた要素はINPUTなどいくつかの種類のタグのみで、ElementsByTagNameメソッドで要素を参照して、NAME属性があるかどうかというところをチェックしていました。ここで、リンクされた要素になり得る要素はすべての要素となると、基本的にはドキュメント内のすべての要素をチェックしなければなりません。従って、BODYタグの要素より以下を調べる事になるが、ここで、エンクロージャーが見つかった場合、エンクロージャーよりも下位を走査する必要はない。もしくはしていはいけない。なぜなら、エンクロージャー以下はリピーター要素の複製などによって内容が変わる可能性があるからである。加えて、エンクロージャーが見つかった場合の処理はリピーターの中でカスケードされるようにすれば、全体は走査する必要はない。従って、BODY以下は前順走査を行い、エンクロージャーが見つかった場合はエンクロージャー内の複製・展開処理を行い、引き続いては自分の兄弟のノードに移動すれば良いということになる。この考察に基づいて、ドキュメント中の展開すべきところを検知するプログラムとしては以下のようになる。

var bodyNode = document.getElementsByTagName( ‘BODY’ )[0];
seekNodes( bodyNode );

function seekNodes( node ) {
var enclosure = null;
var nType = node.nodeType;
if ( nType == 1 ) {
if ( isLinkedElement( node ) ) {
enclosure = getEnclosure( node );
} else {
var childs = node.childNodes;
for ( var i = 0 ; i &lt; childs.length ; i++ ) {
var checkingEncl = seekNodes( childs[i] );
if ( checkingEncl != null ) {
if ( checkingEncl == childs[i] ) {
expandEnclosure( node );
enclosure = null;
} else {
return checkingEncl;
}
}
}
}
} else {

}
return enclosure;
}

function isLinkedElement( node ) {
if ( node.getAttribute( ‘TITLE’ ) != null ) {
return true
} else {
return false;
}
}

function getEnclosure( node ) {
var currentNode = node;
var encTagCandidate = null;
var encTagCandidateAlt = null;
var encClassCandidate = null;
while ( currentNode != null ) {
var tagName = currentNode.tagName;
var className = currentNode.getAttribute(‘class’);
if ( tagName == ‘TR’ ) {
encTagCandidate = ‘TBODY’;
} else if ( tagName == ‘LI’ ) {
encTagCandidate = ‘UL’;
encTagCandidateAlt = ‘OL’;
} else if ( tagName == ‘OPTION’ ) {
encTagCandidate = ‘SELECT’;
} else if ( tagName == ‘DIV’ &amp;&amp; (className != null) &amp;&amp; className.match(/_im_repeater/) {
encTagCandidate = ‘DIV’;
encClassCandidate = ‘_im_enclosure’;
}
if ( (( encTagCandidate != null ) &amp;&amp; ( tagName == encTagCandidate ))
|| (( encTagCandidateAlt != null ) &amp;&amp; ( tagName == encTagCandidateAlt ))
|| (( encClassCandidate != null ) &amp;&amp; ( className.indexOf(encClassCandidate) &gt;= 0 ))) {
return currentNode;
}
<div class=”wiki_entry”> currentNode 2010-03-08 02:49:24
=”Apple-tab-span”> </span>currentNode = currentNode.parentNode;</div>
}
return null;
}

function expandEnclosure( node ) {

}

INTER-Mediator Ver.0.5まで来たところで、見直しを始めました。現状、それなりに動いているのですが、「選択入力」の実現を考えていたときにちょっと壁があることが分かりました。選択入力は簡単ですが、「状況に依存して選択肢が変化する」までを視野に入れると、今のままではスマートな解決方法はありません。もちろん、いかにも取って付けたような対応は可能ですが、それだと美しくありません。加えて、現状では、リスト形式の画面のとき、リストの１行１行からのリレーションがあるような場合にうまく対応できません。これらを考えて、いろいろな状況に対応できるように、データベース処理をより汎用化することを考えました。

Ver.0.5までのアーキテクチャだと、「リレーションのリレーション」ができません。一方、リレーションをいくつも定義できれば、「状況に依存して選択肢が変化する」ができるのです。つまり、選択肢は、リレーションして絞り込まれた結果であるからです。常に同じ選択肢のものは、そのテーブルとのデカルト積で考えれば良いので、この手法で、選択肢の件は解決するはずです。

Ver.0.5までは、InitializePage関数の引数で、テーブル名／キーフィールド名／外部キーフィールド名、を指定していますが、外部キーフィールドが、どのテーブルのどのキーに対応するものなのかを指定する必要があります。1つ目のテーブルの場合や、相手のテーブルのキーフィールドに対応する場合には省略可能とすると、シンプルなものであれば現状と変わらないと言えるでしょう。

そこで、InitializePage関数の第一引数で、’foreign-key’ というキーに対してテーブル名を記述していたのを、以下のキーと値を持つ配列で定義することにします。

• ‘field-name’：外部キーフィールド名
• ‘table’：対応するテーブル名
• ‘key’：対応するテーブルのキーフィールド名

一方、現在は繰り返しは1つのTRタグの繰り返しです。テーブルのデザインによっては、複数のTRで1つのレコードを表現し、それを繰り返したいこともあります。また、UL/OLもあるし、SELECT/OPTIONもある意味繰り返しです。DIVを繰り返したいと思う事もあります。そこで、汎用的な繰り返しを実現するために、リピーターとエンクロージャーを定義します。HTMLページは要素の繰り返しですし、要素に要素が含まれることになります。ここで、1つのノードを「エンクロージャー」とし、その中にあるあるノード以下の全てのノードを「リピーター」とします。元のドキュメントで、エンクロージャーとリピーターが認識できれば、リピーターを繰り返しデータベースのデータに置き換えることで、繰り返すレコードをドキュメント内に展開できることになります。右側はノードとして見たときの関係を示した図です。

リピーターとエンクロージャーとして、以下のようなものをサポートする事にします。テーブル、項目リストはもちろんですが、SELECTも同様な仕組みです。また、汎用的にDIV要素と既定儀のクラス名で、リピーター／エンクロージャーのセットを定義できるものとします。DIV以外は、リピーターとエンクロージャーはノードの階層関係の上では親子関係になっていることになります。リピーターとエンクロージャーの間にノードがあっても良いということになると、今度は繰り返しをつなぐポイントを定義しないといけないことになるので、DIV要素の場合も直接の親子関係にあるものとします。ただし、そうなれば、DIV要素の双方にクラスを付けることは不要であるとも考えられますが、これは後からの検討課題とします。

リピーターとエンクロージャーとして、以下のようなものをサポートする事にします。テーブル、項目リストはもちろんですが、SELECTも同様な仕組みです。また、汎用的にDIV要素と既定儀のクラス名で、リピーター／エンクロージャーのセットを定義できるものとします。DIV以外は、リピーターとエンクロージャーはノードの階層関係の上では親子関係になっていることになります。リピーターとエンクロージャーの間にノードがあっても良いということになると、今度は繰り返しをつなぐポイントを定義しないといけないことになるので、DIV要素の場合も直接の親子関係にあるものとします。ただし、そうなれば、DIV要素の双方にクラスを付けることは不要であるとも考えられますが、これは後からの検討課題とします。

リピーター	エンクロージャー
TR要素、TR要素の配列	TBODY要素
LI要素、LI要素の配列	OL要素、UL要素
OPTION要素	SELECT要素
DIV.im_repeater要素	DIV.im_enclosure要素

Ver.0.5までは、リピーターとエンクロージャーは明確に識別はされていませんでした。というのは、TABLE要素にある1つのTR要素を繰り返すというルールだけだったからです。ドキュメント内のINPUTタグの要素を検索し、それを含むTRを探し、さらにTRを含むTABLEを探すということを行っていたのです。従って、INPUTタグに何らかの識別マーク（具体的にはNAME属性）を付けることで、そこからリピーターとエンクロージャーを自動的に探す事ができます。また、リレーションも2段階までだったので、見つけたエンクロージャーに対してデータベースからの読み込み結果を適用すれば済みます。

アーキテクチャを変更した後はどうなるでしょうか？　ここにはいろいろな問題が発生します。リレーションも多段階であることも考慮すると、ドキュメントからエンクロージャーを見つけて処理するとう方法は限界があります。たとえば、リピーターとして繰り返した要素のさらに下位にエンクロージャーがあった場合はどうなるでしょうか？　このことを考えれば、結果的にはドキュメントの要素を順次調べて、リピーターとエンクロージャーを識別し、その都度データベースの差し込みをする必要があります。以後は、Ver.0.5までと同様に、INPUTタグの要素などデータベースのデータと実際に置き換えが行われる要素に「テーブル名」「フィールド名」などの情報を埋め込み、そこからエンクロージャーやリピータを識別することにします。アルゴリズムを考えるときに、リピーターの中にあるエンクロージャーをどう識別するのかということがポイントになると考えられます。