従来のJAVAScriptの書き方より、AJAXの書き方のほうが、MVCや自動生成がしやすいかも。

　あくまでも、独断と偏見の話なんですけど、最近AJAXの本を読んでて思うのは、AJAXになって、JAVAScriptより、ソースをViewと他のところに分離しやすいんじゃないかなって思います。

　AJAXが従来と違うところというと、もちろん、非同期にアクセスできるための

１．HTTPによるデータ取得が可能

ってこともあるけど、それ以外に、

２．動的に表示部分を書き換えることを可能にするため、Pタグやdivタグなどなどに
　　IDをふり、document.getElementByIdで、それらにアクセスでき、値を設定
　　できるようになった。

３．前からできるものの、イベントリスナーによって、イベント関数を記述できるように
　なった。

っていうことが、あげられると思うんです。

---

　で、とくに２の効果により、いままで、Javascriptのときは、文字を書き出すのに、HTML内に、スクリプトをわりこませ、document.writeとしなきゃいけないところも、ID指定して、プログラム内で値を設定できることになったので、まあ、これ以外もそうなんだけど、IDさえ降ってくれれば、わざわざ、HTMLの中に、途中割り込んで、JavaScriptを書く必要が無くなった。

　で、３の効果により、onClick=などなどの形でJavaScriptをかかないですむようになった。
　onClickなんとかの形で書く場合、自動生成させようとすると、そこだけ、自動生成させるってことはむずかしいので、input文全部。。。ってことは、画面自動生成かい？？ってことになってしまったが、イベントリスナーの関数の自動生成なら、画面の項目を書かなくていいので、自動生成時に画面のことを考えなくていい。

---

　っていうことで、画面であるViewの部分と、プログラムの部分である、モデル、コントロールの部分（ここがJavaScriptになる）が、分離しやすくなった。

　で、さらに、コントローラーの部分は、イベントリスナーで、addListnerした関数っていうことになるので、明確になる。あとは、コントローラー部分の役割と規約を決めれば、（つまり、コントローラーでチェックまでするのか、値セットはするのか、それともなにもしないでモデル呼び出しか？などなど）とりあえず、コントローラーの分離もできそうだ。

---

で、自動生成になるわけなのだが、画面定義書を
１．画面遷移図
２．各画面について
　　　（・画面の図）
　　　・各画面項目の説明
　　　・イベント発生時の処理
　と別れている場合、画面の図がViewであり、ここをXHTMLで書くようになる。
　このとき、各画面項目の説明で示された、IDをXHTMLでセットすることになる。
　各画面項目の説明から、自動生成もありだ（ぶらんこみたいなかんじ）

　イベント発生時の処理に対応する関数をaddListnerすることになる。
　なお、画面表示時はLoadイベントになる。

---

なーんておもったりしたわけ。
けっこう、AJAXの場合、型にはまりそうだ。

ケータイで英語を提示、発音等をチェックするっていうのは、確かにアリかも

　昨日のＮＨＫラジオ「ビジネス英会話」で、たしか、高橋修三が言ってたと思うんだけど、ケータイ端末で英語を提示して、それを読み上げ、発音をチェックするっていう教材は、アリかもしれない。

　ちょっと、高橋修三と考えているやり方はちがうかもしんないけど、こんなかんじ。

ケータイのテレビ電話って、普通、顔を映すけど、ここでは、

１．先生のかわりに英語教材（英語で書かれた文章と、絵）を写す
２．生徒は、テレビ電話でその文章を読む。まあ、質問なんかもＯＫだ
３．先生は、（英語教材が写っているので）写ってないけど、実際には、いて
　　ケータイのテレビ電話で、生徒の読み上げた英語の発音などをチェックし、
４．良くなかったらコメントし、良かったら、次にいく。

　この方法だと、先生は、どこにいてもいいし、映らないので、どんなかっこしててもいい。
　そう、生徒は一生懸命、ケータイに向かってお勉強しているが、実は、先生は、人件費削除のため、インド人で、インドにいるなんていうのもＯＫ（コメントするとき、しゃべらないで、文章で提示するようにすれば、インド人って、ばれないばれない　＾＾；）

　つーか、人間じゃなくってもＯＫだけどね。

　たしかに、これは、アリかも

ケータイ、webアプリで必要な「ファイル等のデータをどこに置くか」戦略（その２：データの種類）

　前に書いた話のつづき。
　ファイルをクライアント側に置くのに制限がある（容量が少ないとか、クライアント側では更新できないとか）場合に、あらかじめ、ファイルをどこにおくか（サーバーか、クライアントか、それとも他の外部か？）の戦略を決める必要があるときがある。
　そのときの考え方。

　で、その手順を、前のブログでは、以下の３段階で考えると書きました。

　戦略には、次の３ステップがある
第一ステップ：どこにおけるか考える
第二ステップ：どんなデータがあるか考える
第三ステップ：どんなデータをどこに置くかを考える


今回は、第二ステップ。どんなデータがあるかについて。

---

■データは、マスタ系とトランザクション系にわけられる
データは、マスタ系とトランザクション系に分けられると思います。

＜＜トランザクション系＞＞
　業務を遂行するときにできるデータ（発注・受注データなど）です。
　業務を行う中で、作成され、更新されたりします。たいてい参照され、削除されることも多いです（かならずしも、削除されるとは限らず、ずーっとたまってしまうケースあり）。
　業務を行うことによってできることが特徴で、多くは、業務名＝ファイル（ＤＢ）名になります。

＜＜マスタ系＞＞
　業務を行う以前に、すでにないと困るデータ（ファイル・ＤＢ）です。
　たとえば、受注業務を行う前に、商品マスタがないと困ります。そうしないと、商品が発注できませんから。。

　ちなみに、中間的なデータとして、ファイルを利用する場合、連番用のファイルというのがある（受注データの連番ファイルで、新規受注データ書き出しことに１上げて保存する）

　なお、上記はウィリアムのいたずらの独断と偏見であり、受注マスタというファイルが存在する場合がある。この場合のマスタの意味はちがい、その場合は、夜間バッチをやる前のデータがマスタであり、今日１日の最新データがトランザクションという意味である。昔のＣＯＢＯＬなどで、この概念がある。

　さらに、感覚的にマスタ・トランザクションといっている人もいる。

　でも、ここでは、そんなことはどーでもよくて、あくまでも、話をすすめるための分類なので、今回は、上記の分類で行く。

---

■トランザクション系は、画面に対応していることが多い
　で、トランザクション系は、業務に関係していると書いた。
　で、一般に、業務にそって、画面を設計することが多い。そのため、

　　「この画面では、このトランザクション系のデータを扱う」

という形になることが多い。

　たとえば、受注と受注明細データは受注画面であつかう。
　たとえば、発注と発注明細データは受注画面であつかう。

などなど。

　そーすると、画面表示（切り替え）のタイミングで、ファイルを参照・更新できればいいということになる。なので、これらのデータは、サーバーにおいておいて、画面切り替えのたびにサーバーアクセス、必要なデータをとってくればいいというケースが多い。

■マスタ系は、おおきく２つのタイプがある
　で、マスタ系だが、大きく２つのタイプがある。
　１つは、コード的に短く、種類も少ないもの
　　→コードが短く、種類が多いと、表現できない。
　　　２桁で、１０００００個の種類のデータを表現しろって（＾＾；）
　　　例：性別、星座、都道府県コード、曜日、

　もうひとつは、コード的に長く、種類が多いもの
　　例：従業員コード、商品コード

　で、マスタ系は、参照されるのが不定期で、入力したら、すぐに反応しないといけない場合もある。たとえば、商品を入力したら、単価をすぐに出し、あと、数量をいれるなど。
　この場合、商品マスタのデータをすぐに表示しないと（画面切り替えしないで）入力のときに待ちができてしまう。

　逆に、マスタデータとおなじで、画面切り替えのタイミングで参照したり、更新するときだけ必要などというものもある。

---

　そして、この場合、こんな性質を持っている気がする
　（あくまでも経験上、大雑把に分けたもので、例外はある）

　コードが短いものは、変更されることが少ない。
（性別は、たいてい男女しかない。星座は１２だし（１３？）都道府県は、たぶん合併されることはない。年号は、とーぶん増えそうもないし？？仮に増えたら、つぎ増えるのはずっと先）

　コードが長いものは、変更されることが結構多い
　商品マスタ、従業員マスタ。。。

---

　ということで、「第三ステップ：どんなデータをどこに置くかを考える」場合、トランザクション系はサーバーにおくのはいいが、問題はマスタデータをどこにおくか？という戦略が重要になる。

　で、第三ステップになるのだが、まあ、それは気が向いたときに。。