javascriptでの連想配列と２次元配列、連想配列のソートとか。。

さっき、javascriptでの連想配列を
WebAPIでXMLで返すようにすると、画面部分が完全分離できる:その３クライアントにマスタデータで使って、


（ただし、このやり方だと、たとえば、cobolとか入力されると、undefinedとなってしまうので、ちょっと持ち方を、かえないといけないけど。。それについては、別の機会に書きます）


って書いたので、その話。つまり、２次元配列と連想配列の話題

---

■２次元配列を初期化して検索

　もちろん、２次元配列を

var　a = [["java","じゃば"],["perl","ぱーる"],["c","しー"],["php","ぴーえっちぴー"]];

みたいな形で、初期化して宣言してしまい、
ループをまわしてa[i][0]が、その値だったら、a[i][1]を返すってしてもいい。
２次元配列が面倒なら、
keyという配列にキーをいれ、valという配列に値を入れて、key[i]が、その値だったらval[i]を返すでもOK

これが、後述のchange1()のやりかた

---

■連想配列、ハッシュマップっぽいやりかた

もうひとつは、まえにやったように、

b["java"] = "じゃば";

みたいに、連想配列にいれて、
b[調べたい値] を直接引くひきかた。
でも、これだと、値がはいってないと、undefinedになるので、
そのときは、""に置き換える。

これが、後述のchange2()のやりかた

---

■ついでに連想配列のソート

　ついでに、連想配列でやったときのソートについて書いておくと
（２次元配列のソートはふつうのソートなんで、省略）

　キーの取り出し方は、よくわかんないので、もっといいやりかたがあるのかも
しれないけど、とりあえず

var i = 0; キーの配列 = new Array(連想配列.length); for( 一時的に入れるところ in 連想配列 ) { キーの配列[i] = 一時的に入れるところ; i++; }

で、キーの配列を取得し、それをsortして、あとは、その配列を順番に取り出すかんじでできる。

---

■ソース

それらをまとめると、以下のかんじ
tx1（一番左上のテキストボックス）に入力すると、
　　２次元配列を検索して、となりのtx2に結果が

tx3（その下のテキストボックス）に入力すると、
　　連想配列を検索して、となりのtx4に結果が

ソートしてみるをクリックすると、連想配列のキーをソートして
並べ替えます。

＜?xml version="1.0" encoding="utf-8"?＞
＜!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"＞

＜html xmlns="http://www.w3.org/1999/xhtml"＞
＜head＞
＜title＞キーワード表示・選択＜/title＞
＜SCRIPT Language="JavaScript"＞
＜!--

var　a =
[["java","じゃば"],["perl","ぱーる"],["c","しー"],["php","ぴーえっちぴー"]];

	var  	b	=	new Array(4);
	b["java"]	=	"じゃば";
	b["perl"]	=	"ぱーる";
	b["c"]		=	"しー";
	b["php"]	=	"ぴーえっちぴー";

//*==============================================//
//*	関数：change1()			  *//
//	内容：２次元配列の入力が変わった	  *//
//*==============================================//
function change1()
{
	//	２次元配列
	t1 = document.getElementById('tx1');
	t2 = document.getElementById('tx2');
	for(i = 0 ; i ＜ a.length ; i ++ )
	{
		if ( a[i][0]	==	t1.value )
		{
			t2.value	=	a[i][1];
		}
	}
}
//*==============================================//
//*	関数：change2()			   *//
//	内容：連想配列の入力が変わった	   *//
//*==============================================//
function change2()
{
	//	連想配列
	t3 = document.getElementById('tx3');
	t4 = document.getElementById('tx4');
	t4.value	=	b[t3.value];
		//	未定義対策
	if ( t4.value	==	"undefined" )
	{
		t4.value	=	"";
	}

}

//*==============================================//
//*	関数：sort()			   *//
//	内容：連想配列のソートしてみる	   *//
//*==============================================//
function sort()
{
	//	連想配列
	var i = 0;
	eigo = new Array(b.length);

	//	キーをeigoに入れる
	for( key in b )
	{
		eigo[i]	=	key;
		i++;
	}

	//	ソートする
	eigo.sort();

	//	表示する
	for(i = 0 ; i ＜ eigo.length ; i++)
	{
		document.write(eigo[i] + ";" + b[eigo[i]] + "＜BR＞");
	} 

}

// --＞
＜/SCRIPT＞
＜/head＞
＜body bgcolor="#FFFFCC"＞
２次元配列＜BR/＞
＜input type=text id="tx1" value="" onChange="change1()"/＞
＜input type=text id="tx2" value=""/＞＜BR/＞
れんそうはいれつ＜BR/＞
＜input type=text id="tx3" value="" onChange="change2()"/＞
＜input type=text id="tx4" value=""/＞＜BR/＞
＜input type="button" value="ソートしてみる" onClick="sort()" /＞
＜/body＞
＜/html＞

（上記＜　＞　￥は、本当は半角）

開発の初めから順番に書いていってみる その２２：要求分析（８）プロトタイプ

シリーズ「開発の初めから順番に書いていってみる」の続きです。
　前回、要求仕様の問題について書いて、そこで、「プロトタイプ」の話と、「雛形があってそれをカスタマイズ」の話を書くということを書きました。
　で、今回はまず、プロトタイプの話を書きます。

---

■昔のプロトタイプ

　プロトタイプは、当初、画面の様子をだして、それで、ユーザーに確認してもらったり、お互いに理解しやすくしたり、エラーメッセージ等について考えるといった、ユーザーインターフェース回りの確認に使われました。

　もちろん、この目的で作ることは今でもありますが、このケースでは、

・プロトタイプができると、すぐにできるように思われてしまう

　とか、

・再利用できない（しないほうがいい）ケースも多い

　とか、

で、”この理由では”、作らない方向になっていると思います。

　ただし、作るにしても作らないにしても、これはユーザーインターフェースの確認ですので、要求仕様には関係なく、外部設計のほうの話です。

---

■方法論の確認のためのプロトタイプ

　しかし、最近、これとは別の目的でプロトタイプを作ることが多くなってきました（こっちの理由のほうが、最近は多いと思います）。
　それは、本当に実現できるかどうか、ためしに作ってみるというプロトタイプです。

　理論的には、どう実現するかは、外部設計の関心事です。
　しかし、実際には、たとえばブラウザを使ってとか、ケータイを使ってとか、Strutsをつかってとか、フレームワークに関するきまり、あるいはフレームワークそのものの指定が、要求仕様でも、というか、それ以前のRFP段階ですら、指定されてしまいます。

　なので、外部設計で、その内容をひっくるかえすのは難しいです。
　そこで、要求分析段階で、プロトタイプを作ってしまうことになります。

---

■方法論の確認方法

　で、方法論の確認方法としては、
・システムを技術的に見て、必要な要素技術に分ける
・その要素技術で、システムができるかどうか確認し、
・要素技術を全部（とまではいかなくとも、クリティカルな部分に関してはやっている）
　プロトタイプが作成できるかどうか確認する
・プロトタイプ開発経験から、自動化するところ、さらにはドキュメントなどをきめ
・システム作成までの方法論をまとめる

ということになります。

---

■プロトを作るメリット

　では、後者の「方法論の確認」としてのプロトを作るメリットを考えると、まず、

・不可能なことを排除できる
　プロトを作って、「あ、これはできない！」ということが分かることがあります。
　たとえば、BREWのIHTMLViewerを使って、カーソルを制御するという方法は、このブログが出るまで、分からない方法だったと思います（マニュアルには、はっきりと書いてなかったので）。でも、普通、請けてきてしまいます。そのくらいできるだろうと思って。

　このほかにも、複数行入力、かな漢のイベント、外字表示など、プロトをつくらないと、不可能、困難ということが気がつかないというケースがあります。

・手順の明確化、自動化
　プロトにより、手順が明確化できる場合があります。
　こうなってくると、いわゆるワーカーさんが使えるので、開発工費の減少がみこめます。自動化もできるかもしれません。その辺の検討ができます。

・見積もりの精度を上げる
　一度作ったほうが、正確。

---

■ここでの問題点

　一方、ここでの問題点は

●プロトをつくる時間が取れない
　要件定義の時間には、この時間は含まれません。
　外部設計では、もう、開始時に、「システム作成までの方法論」はできていると
　かんがえられてしまいます。つまり、プロトを作る時間はここでもありません。

　どこにも、プロトを作って確認する時間はありません。

●プロトの重要性がわからない。
　本のとおりにやると、システムができないことが多いです。
　そのためにプロトで確認するのですが、そのことを、あからさまに言う人が、最近は少ないです。

　Javaの多くの本には、複数の画面制御を行う際、どのようなクラスわけをすると、成功しやすいかなどの本は少ないです。BREWにおける、画面制御の方法論は、ウィリアムのいたずらがこのブログで書く前は、本屋さんにも、そんな本は置いてないでした（画面の出し方は、何冊かあるけど）。

　現在では、帳票における外字の問題などがあるのですが、そー言う話題に触れる本が少ないです。そのため、本で勉強した人は、どんな問題がありそうかすらわからず、なんとなくできた気になります。そーなると、できた気になっているので、プロトを作って確かめることはありません。

●技術要素に分解できない、漏れが出るのでプロトを作る意義がない
　そもそも、システムを技術的な要素に分解できないと（分解できる能力がないと）プロトのつくりようがないです。この部分ができない、あるいは問題となりそうなところが分からず、もれるというケースがあります。

なんかがあります。

---

■で結局は、

　結局は、プロトを作ったほうがいいかどうかは技術的な読みになります。
　それは、できること、できないこと、あやしいことが明確にわかるということです。

　これには、経験もありますが（経験知識の形式化も含む）、やはり、サンプロがあると楽です。っていうか、サンプルって、そもそも、プロトなんですけどね。。

---

　ということで、次回は、「雛形があってそれをカスタマイズ」の話です。

WebAPIでXMLで返すようにすると、画面部分が完全分離できる:その３クライアントにマスタデータ

　この前、WebAPIでXMLで返すようにすると、画面部分が完全分離できる:その２クッキーを使わない値渡しというのを書いたときに、以下のようなやり方を書きました


１．トップ画面の変数(top.変数名）に値を保存して
２．画面は、トップでなく、gamenとか名前を付けて、そこに出すようにすれば、
３．画面間で、１の変数が共用できる。


　で、これだけならクッキーとおなじなんだけど、ちょっと違った使い方があります。
　それは、クライアント側に商品名とコード対応表や顧客マスタなどのデータを読み込んでしまい、画面か切り替わっても、そのデータを保持しておくという方法です。

　これにより、マスタデータ検索のときに、サーバーアクセスに行かなくてすむので、入力されたら検索して。。。などというとき、スムーズにできます。

　ってことについてです。

---

■トップ画面の変数に読み込む

　前に書いたエントリの例のとき、一番初めにアクセスするindex.htmを、
以下のように書きました。

＜html＞
＜SCRIPT type="text/javascript" src="abc.js"＞＜/script＞
＜SCRIPT Language="JavaScript"＞
＜!--
var	val1	=	"2345";
// --＞
＜/SCRIPT＞
＜head＞
＜title＞テスト＜/title＞
＜/head＞

＜frameset＞
 ＜frame name="gamen" src="main.htm"＞
 ＜noframes＞
  ＜body＞

  ＜p＞このページにはフレームが使用されていますが、
  お使いのブラウザではサポートされていません。＜/p＞

  ＜/body＞
  ＜/noframes＞
＜/frameset＞
＜/html＞

（上記＜　＞は実際には半角）

ここで、
＜SCRIPT type="text/javascript" src="abc.js"＞＜/script＞
と、abc.jsというファイルをインクルードしているわけですが、たとえば、ここで、このabc.jsに、以下のように書かれていたとします。

var a = new Array(4);
a["java"] = "じゃば";
a["c"] = "しー";
a["perl"] ="ぱーる";
a["php"] = "ぴーえっちぴー";

そーすると、top.a["java"]と入れれば、"じゃば"って受け取れます。

そこで、index.htmから呼び出されるmain.htmを

＜?xml version="1.0" encoding="utf-8"?＞
＜!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"＞

＜html xmlns="http://www.w3.org/1999/xhtml"＞
＜head＞
＜title＞表示＜/title＞
＜SCRIPT Language="JavaScript"＞
＜!--
//*==============================================//
//*	関数：change()			  *//
//	内容：入力が変わった		  *//
//*==============================================//
function change()
{
		
	t1 = document.getElementById('tx1');
	t2 = document.getElementById('tx2');
	t2.value=top.a[t1.value];
}

// --＞
＜/SCRIPT＞
＜/head＞
＜body bgcolor="#FFFFCC"＞
＜input type=text id="tx1" value="" onChange="change()"/＞
＜input type=text id="tx2" value=""/＞
＜/body＞
＜/html＞

（上記＜　＞は、本当は半角）

　なふうに書いて、テキストボックスのIDがtx1にjavaとかいれられたら、じゃばと出すようにできます。
　つまり、コード引きができます（ただし、このやり方だと、たとえば、cobolとか入力されると、undefinedとなってしまうので、ちょっと持ち方を、かえないといけないけど。。それについては、別の機会に書きます）。

---

■つまり、別ファイルに、マスタデータやコードデータを持てる。

　つまり、

１．abc.jsというような、別のファイルをつくって、そこに、
２．商品名とコード対応表や顧客マスタなどのデータを、
　　変数を初期化する形で書き込んでおけば、
３．topのところで、それをインクルードして変数を読み込むので、
４．クライアント側で利用するときはtop.変数名で使えるってことになります。

　こーなると、サーバー側にいちいち毎回アクセスに行かなくても、クライアント側で値が取れるので、はやいってことがあります。

　これは、クライアント側にソースがあるなら、配信データで、マスターが更新されたら書き換える（実際には１日何回かとか、立ち上げ時に書き換えとかになるのかな？）し、サーバー側に画面ソースがあれば、それを書き換えるってことで、どちらのケースでも、利用可能です。

---

■ただ。。
　ただ、この方法、マスタが巨大になると、クライアント側で、メモリ的にどーなの？とか、処理スピードがどーなの？とかなるので、適当な限度というのがあると思います。

　場合によっては、起動時にマスタデータをクッキーに入れて、それを参照するなんていうほうがいいかもしれないし。。。

　ま、そのへんは、ケースバイケースなんでしょう
　（サーバーアクセスして検索したほうが早い場合もあるし。。）