ajaxのサンプルプログラムを動かすとき、超基本的な、忘れてならないこと！

　わけあって、ajaxをはじめようと思った。
　で、このサイトにいって、「WebDesigning掲載サンプル（サーバーからデータを読み込み表示するだけの簡単なサンプル）」を実行しようと思った。

はじめにやった手順は、以下のとおり

■■　失敗した手順
１．IEなので、ここの２つめのサンプル（灰色になってる部分の＜html＞から＜/html＞のすべて）をコピーし、test.htmという名前で保存
２．そこにsample.txtというテキストファイルをつくり、テキトーに文字を入れる
３．IEから１のtest.htmをひらく。

＊＊結果
　たしかにtest.htmはみえるが、そこをクリックしてもsample.txtは、開かん。。。

---

これが、正しい
■■　成功した手順
１．IEなので、ここの２つめのサンプル（灰色になってる部分の＜html＞から＜/html＞のすべて）をコピーし、test.htmという名前でApacheのhtdocsフォルダの下に保存
２．そこにsample.txtというテキストファイルをつくり、テキトーに文字を入れる
３．Apacheを起動する
４．IEから、http://127.0.0.1/test.htmを閲覧する

---

■■　　超基本的な、忘れてならないこと！

　どうも、サーバーのところにおいて、サーバーを起動して、それを閲覧するみたい。

ユーザーにとって、ＲＤＢのテーブルってExcelのシートなんだよね。だから問題。

　ユーザーにとって、表というと表計算ソフト、Excelの表を思い出すと思う。
　なんで、ＲＤＢのテーブルと、Excelのシートって、だいたい同じイメージになってしまう。つーか、ユーザーでなくても、そうだ（開発の人でもそういう人がいる）

　でも、この２つには、決定的なちがいがある。
　Excelは、セルの結合ができる。
　ＲＤＢは、セルの結合が出来ない。
　セルの結合のように、２レコード以上で、同じ値をとる場合は、２つのテーブルにわける。正規化の処理の一部で行う。

　この問題は、聞いていると思う。でも、もう一歩突っ込んだ話。
　つまり、ユーザーにとって、レコードの最小単位っていうのは、自分が、最小単位だと思ったのが、最小単位なのよ。それより細かく分割できても、セルを結合して、まわりに線をひいてしまえば、いいし。。。

---

　っていうことで、問題がある。

　ヒアリングをするとき、ユーザーは、レコードの説明を、「自分が、最小単位だと思っている」ものを、最小単位として説明する。
　したがって、ユーザーのヒアリングをもとに、名詞項目を抽出し、（ＥＲ図を作るのをサボって、かつ正規化の作業をはしょって、すぐに）テーブルにしてしまうと。。。
　コーディングのときに。。。
　おやおや、このレコードのあるところのステータス、２つの値をとることがないか(@_@!)

　ってなことになり、テーブル設計しなおしになる。

　でも、ユーザーは、気づかない

---

　例を挙げよう

　受注のとき、
　　りんご１００個
　　みかん９０個
　という受注をうけたとする。

　自社倉庫は、東京と大阪にある。

　このとき、東京倉庫に、りんご１５０個、みかん５０個、大阪倉庫に、みかん５０個あったとする。そうすると、大阪倉庫から東京倉庫にみかん４０個を送ってもらい（これを、倉庫間移動という）、それがついたとき、この受注の出荷をする。

　そうすると、みかん９０個のステータスは、２つに分かれて、
　　　みかん　　東京倉庫分　　　５０個　　引当済み
　　　みかん　　大阪倉庫分　　　４０個　　倉庫間移動中
　と、２レコードにわかれないと、ステータス管理できない。

　ところが、Excelの人にそんな概念はない。受注明細の２行分の商品名を連結して、１行にして、そこに「みかん」と書き、上の行に５０個、下の行に４０個と書いてしまう。

　受注明細をさらに分けるという概念はない。

　そのため、その後のヒアリングに矛盾がでてくることがある。

---

　ってことを、ユーザーからの話のなかで出てきたのならいいんだけど、

　あるプロジェクトマネージャーさんが、どうも気づいてないようだったので、気になって書いてみた。

マスタメンテプログラムの自動生成方法の例と標準化

　ちょっと、いちゃもん、揚げ足取りじみてるかもしれないけど、気になった言葉。。
「PM見習いの読書日記」さんのブログで、


たとえばマスタメンテナンスみたいな画面づくりが続いたら、開発してる人は楽しくないと感じるのかな？



　ちょっと待った！マスタメンテって、もしかして、手作業でプログラム作ってる？？

　マスタメンテって、自動的にプログラムで作る（よねえ。。ちょっと不安になった）。そのため、自動生成するんで、ＤＢのテーブル構造を、標準化したドキュメントに記述する。

　だから、標準化が必要なんじゃあなくって(@_@)!。

　この自動化プログラムがなければ、テストファーストとか言われても、マスタメンテ作って、テストデータつくるよりも仕様変更のほうが早いから（最近の仕様変更は、まさに、朝令朝改だ！）、事実上出来ない。

　こういう自動化テクニックと標準化が出来てるからこそ、ＴＤＤができると思ってたけど。。これがなくって、標準化してくれなきゃ、プログラマさん、ＮＨＫにはいっちゃうよ！（ＮＨＫは、日本放送協会ではない）

　あ、マスタメンテ「みたいな」か。。。でも、それも、マスタメンテの自動化を応用できると思うけど。。。

---

　念のための意識あわせ。

　マスタメンテの自動生成（これ以外にもあると思うし、現場は、もっともっと、進化系を使ってると思うけど、ちょー単純にした話）の例：

（１）１テーブル１シートにして、そのシートに、テーブル名を書きましょう
　　　で、テーブルの項目、型、桁数などを書くようにする
　　　これは、標準化しておく。そうしないと、自動生成プログラムがたいへんだよ！

　　　名前は、英字のものも用意しておいてね！英字のほうを使うから。

---

（２）自動生成プログラムはwebでつくるのがかんたんっす。
　　　っていうことで、Webでつくることを前提にする。

　　　で、マスタプログラム画面は、各テーブルごとに用意する。
　　　関連したテーブルを直したいときは、Viewっていうことにするのね。
　　　で、Viewの更新の場合、ちょっと工夫（実は標準フォーマット側にも）が必要。
　　　
　　　各テーブルに対して、以下の画面が必要になる
　　　　・検索（はじめの初期表示）画面
　　　　・一覧画面＝ここで、削除、更新、追加を指示
　　　　・明細画面＝更新、追加のときに、項目を修正、入力する画面

　　　で、サーバー側のＣＧＩ（じゃなくてもActionでも、おんなじだけど）は
　　　　・検索画面から、テーブルと検索条件を受け取って、一覧を出すＣＧＩ
　　　　・一覧から明細画面を出すＣＧＩ
　　　　・明細画面かた更新するＣＧＩ

　　　ＣＧＩ側は、コントローラと、ＤＢアクセス部分にわかれ、

　　　ＤＢアクセス部分は、検索・更新・削除・追加用のクラスを自動生成する。

　　　なお、このクラスの値の引渡し方法（ＶＯ）を、どのように汎用的につくるかは
　　　いろいろなテクニックがあるが、省略
　　　ただ、getter,setterを使うんなら、setterで、セットされたら、フラグをあげる
　　　ようにして、各テーブルごとに項目、そのフラグ、getter,setterを自動生成して
　　　それをＶＯクラスにすれば、なんのテクニックも使わないでできる。
　　　（フラグを使わないのにテクニックがいる）

---

（３）それぞれの自動生成を行うためのプログラムをつくる　
・検索（はじめの初期表示）画面
　検索項目を選択し、値を設定すると、検索条件ＳＱＬとテーブル名を引数としてＣＧＩを呼び出すＨＴＭＬのＦＯＲＭ画面を自動生成する。

・一覧画面＝ここで、削除、更新、追加を指示
　受け取った項目をリスト形式で表示し、削除、更新、追加ボタンを作成し、そのボタンが押されたら、選択箇所のメインキーと、押されたボタン名を引数としてＣＧＩを呼び出すＨＴＭＬのＦＯＲＭ画面を自動生成する。

・明細画面＝更新、追加のときに、項目を修正、入力する画面
　受け取った値を画面に表示し（追加の時には、この値がない状態で受け取る）、実行ボタンをつけて、実行ボタンを押されたら、各項目と入力値を返すようにする（更新か追加かは、セッションでわかるようにしておく）

・ＤＢアクセス部分
　マスタメンテを作る前に、すでに、ＤＢアクセス自動生成プログラムで出来ているとする。そのつくりかたは。。。いいよねえ、わざわざ、説明しなくて(^^;)

・検索画面から、テーブルと検索条件を受け取って、一覧を出すＣＧＩ
　受け取った条件とテーブル名をもとに検索用のＤＢアクセスプログラムを呼び出し、その結果を、一覧用に返す。

・一覧から明細画面を出すＣＧＩ
　削除の場合は、そのデータを削除する
　追加の場合は、セッションに追加だよ！と設定し（実際は、フラグに値を設定するが）
　　　明細用に値をクリアして返す
　編集の場合は、セッションに編集だよ！と設定し
　　　ＤＢアクセス用プログラムに、
　　　　　引数として渡された選択された箇所のメインキー値をいれて、
　　　　　ＤＢを検索し
　　　明細用の値に、検索結果をいれるようにして返す
　

・明細画面から更新するＣＧＩ
　チェックしたければ、引数チェック
　で、セッションにはいっている、追加か、編集かをみて、インサートかアップデートのＤＢアクセス関数を呼び出す。

---

（４）このやり方だと、複数関連テーブルの一括修正・登録ができない。

　で、その場合は、ＶＩＥＷを使うんだが、そうすると、更新部分で、ちょっとした工夫がいる。その工夫は。。。。あんまりにも長くなるので省略。

---

　マスタメンテ「みたいな」画面のときは、上記の「初期画面」ー「一覧」ー「明細」の枠組みに落とし込み、ＤＢアクセス部分をモデルにかえて、実行できるようにすると、自動化の枠組みに、はまるよ！

---

　でも、これ手作業でつくったら、ウィリアムのいたずらなんかが関係するシステムだと、テーブルだけで、５０も、いや、もっともっとあるから、それだけで、まあ１万ステップ、いやもっともっとだなあ。。。をコーディングしなくちゃならないわけで。。。

　つーか、これもってないで、テストファーストとか、ＰＭにいわれたら、「そんなご無体な」っていう感じだよねえ。。。

　ぜったい、そのＰＭさんって、いじめっ子だったとおもうよ。

　きっと、プログラマさんたちは、ＮＨＫに、はいってしまうにちがいない！(って、日本放送協会じゃないよ！くどいって！）

　だって、こんなの手作業で作ってたら、テストプログラム作ってる間に、テーブル構造変わって、やり直しになっちゃうよ（いやまじで。１日で構造が変わることもあるしさあ）！

　「まいにちまいにち、ぼくらはＰＭの、仕様変更でいやになっちゃうよ！」

っていわれて、「およげたいやきくん」のように、とびだされちゃうよ（ふる！）