プレステ”４”の噂話が本当なら、ＡＪＡＸのＲＰＧとか、そーいうのが出てくるんでしょうか？

ここのはなし
プレステ4に関する噂話
http://www.gizmodo.jp/2006/08/4.html
にこんなことが書かれています。
（以下斜体は上記サイトより引用）


まだプレステ3すら出ていませんが、SCE WWS（SCEワールドワイド・スタジオ）の社長、フィル・ハリソン氏は、既にその先を見ているようです。

彼によると、プレステ4では、CD-ROMやDVDのような、物理的なディスクは用いられないだろうとのこと。彼は「もしプレイステーション4が物理ドライブを持っていたら、私は驚いてしまうよ」と言っています。


　えーっとえーっと、ってことは、ゲームはオンラインゲーム化するってことなんでしょうか？
　ＡＪＡＸのＲＰＧとか、そーいうのが出て、ブラウザだけあればＯＫってなるとか。。

　たしかにゲームのＡＪＡＸ化は、ありでしょうな。。
　流通をどうするか（会員制にして、お金取る？？）も含めて、検討課題はありますが。。

ＡＪＡＸ格付け

ＡＪＡＸカクヅケ！というサイトがあります
ここ　http://ajaxranking.com/
そこによると。。
（以下斜体は上記サイトより引用）


AJAX格付けとは？
AJAXを中心に、ブラウザだけで使えるwebアプリを評価。


そして


(8.18)AJAXボードオープン！ ajax系セミナーや求人の告知などにご利用ください。

だそうです。
ほー、ＡＪＡＸも格付けですか（＾＾）

ちなみに、そのニュースはこちら
AjaxなどのWebアプリケーション比較サイト「AJAX格付け！」
http://internet.watch.impress.co.jp/cda/news/2006/08/17/12992.html

Strutsの画面前処理方法について（ＪＳＰ表示データをセッションで持たせる）

　さて、以前のブログで、画面処理について必要なのは
　　・画面間の画面遷移（遷移先とその条件）
　　・各画面の内容
　　　　　入力項目／出力項目（入出力項目も含む）の
　　　　　　　値について(int,文字列）と範囲、制限
　　　　　　　値の種別（ＳＡ，ＭＡ，ＦＡ）
　　　　　　　　→実現する画面部品
　　　　　　　レイアウト（項目の位置）
　　　　　　　　：これについては前回書き忘れました
　　　　　各種イベント時の処理
　　　　　　　・画面初期表示
　　　　　　　・部品によりおきるトリガー
　　　　　　　　→Submitボタンが押されたなど
　　　　　　　・画面終了時
　となります。

　ここで、画面をＨＴＭＬで表現し、イベント時の処理を、メソッド何々を呼び出すとしてしまえば、あとは、その呼び出す引数さえ、固定化する（きまりをつける）と、
　　ＨＴＭＬを作成し
　　呼び出すプログラムを設定ファイルに記述
　すれば、この画面処理は、部品化できることになります。こうして部品化したものが、Strutsとなります（ただし、部品化とはいわず、この場合、フレームワークとよぶけど）

---

　ところが、ここで、Strutsで困ったことがあります。

　「部品によりおきるトリガー」に対しては、どのメソッドが呼ばれるというのは、明確に記述でき、それには、きまりがあります。なんとか.doというＵＲＬで呼び出され、Actionクラスを継承したクラスのexecuteメソッドが呼び出されます。そして、そいつが、次の画面を返します。

　でも、画面の終了時と画面初期表示は、どこに書けばいいんでしょう。

　ここで終了時は答えは明白です。

　「部品によりおきるトリガー」で呼び出されるクラスのexecuteメソッドは、これが終わると、次の画面のJSPをシステムが呼び出してしまいます。なので、その前（＝次の画面表示の前）に、今の「画面の終了時」処理を行わないといけません。

　ということは、「部品によりおきるトリガー」のなかで、「画面の終了時」処理を行うということです。つまり、Strutsの場合は、この２つをまとめて仕様書に書く形になります（というか、他のケースでもそうなんだけど、フレームワークごとに仕様書は作り変えたほうがわかりやすい。汎用的な画面仕様書をつくると、整理しやすくても、誤解を招きやすい）。

---

　では、画面初期表示は？

　かける場所は（ふつうは）２つあります。
　（これ以外にもあるかもしれませんが、実務上、この２箇所がおおいです。なお、ここでは、ダイナアクションフォームで初期値を与えるといった、簡単な初期表示処理ではなく、検索してマッチングしてソートしてほんでもって、とかいう、複雑な処理が必要なケースをさします）

１．「部品によりおきるトリガー」のなか、「画面の終了時」処理のあとに、次の画面の初期表示処理を書く。

２．もう１つは、JSPの中にかく。

　２のやり方は、画面とプログラムが分離しないのでよくないといわれます。
ただ、これも、やり方の問題で、ＪＳＰから、メソッドを呼び出して、そこに全部書いてしまえば、まあ、ほぼ分離しているといっていいかもしれません。それ以上に、Strutsの場合、Strutsタグをいれておいて、画面とプログラムの分離といってもねえ。。デザイナーさんにStrutsタグがわかるわけでなし。。。という意見があります。

　１の場合は、次の画面のActionFormの実体が前の画面のAction内で取れるわけではないので、実質無理があるのと、それ以外でも、いろんなところから、ある画面が呼ばれている場合、修正するのは、かりに１つのメソッドを呼んでいたとしても、それに伴う変更がどこまで派生するか。。とか考えると、あまり得策でもないです。

　ということで、良いか悪いか別として、２のＪＳＰの中に、画面初期表示に必要な処理を行い、その結果の値を表示するということになります。

---

　で、問題は、かりに、「ＪＳＰの中に、画面初期表示に必要な処理を行う」場合、それに必要なデータをどこにしまっておくかということですが、このときセッションを使います。
　前のブログで示したように、サーバー側の処理において、処理を行った後ＪＳＰに値を渡すには、べつにサーバ側だけでセッション処理を行えばいいだけなので、これは可能な話になってきます。

　つまり、
　　　次の画面表示に必要なデータは、すべて、セッションに入っているように、
　　　あらかじめ、用意しておいて

　　　画面表示をするとき、初期処理が必要なら、ＪＳＰでセッションから
　　　値をとってきて、それをセットする

　という手段をとることによって、対応可能です。

---

ということで、Ｓｔｒｕｔｓの場合
　　　　　各種イベント時の処理
　　　　　　　・画面初期表示
　　　　　　　　　→ＪＳＰの中
　　　　　　　・部品によりおきるトリガー
　　　　　　　　　→ActionのExecuteの処理
　　　　　　　・画面終了時
　　　　　　　　　→ActionのExecuteの中での処理
という形で、画面の処理を記述することができます。

---

　ということで、産能大記号の画面関連については、これでＯＫということにして、このシリーズは、次の記号に行くことにします。

セッションについて、画面間にわたるデータ交換”以外”の利用法。。。

　Ｓｔｒｕｔｓでの画面前処理の話を以前のブログですると書きましたが、その前に、セッションについてまとめておく必要があるので、ちと書いておきます。

　セッションは、画面間で、データを受け渡しするのに、普通使います。
　　ＰＨＰだとこんなかんじ
　　（ただし、Cannot send session cookie（このあとつづく）っていうエラーが出る場合はここ）
　　Perlだとこんなかんじ、
　　ＪＳＰだとこんなかんじで、
　　Ｊａｖａのサーブレットだとこんなかんじ
　とまあ、こんなかんじになります。

　では、セッションでは、なにをやっているのかというとまとめると、結局
・画面間で、データの受け渡しをするのに、サーバー側にデータ置き場を用意しておき、クライアントにセッションＩＤをわたすことで、どこの置き場のデータを使っているということがわかるようにして、データを受け渡す
　という方法でした。

　つまり、こんなかんじ。


　で、これを実現するためには、クライアントの画面にセッションＩＤを渡して、クライアントからはそのＩＤを返してもらわないといけません。
　そのためには、クライアントに
１．クッキーを使ってもらうか
２．セッションＩＤをＵＲＬに設定して（SIDやSessionIDとなるのがふつう）
　とってくるのがふつうです。

---

　なお、上記の図のように、セッションは、サーバー側にあるものなので、
Javascriptでクライアントからセッションのデータを操作するというのは、
常識的には出来ません（ＡＪＡＸで非同期でなんかして。。。とか、
そーいうことを、今考えないとして＝常識的に）。

　また、別にセッション以外でも、このことと同じことは実現できます。
　１セッションごとにファイルやディレクトリ（＝フォルダ）を用意して、
そこに書き出し、セッションＩＤのかわりに、そのファイル名をクライアント
に受け渡しすれば、ＯＫです。
　もちろんＨｉｄｄｅｎですべてのデータをわたしてもいいし。。

　この場合のメリットは、ＡＪＡＸを利用する場合、比較的簡単にサーバ側データ
が取得できるということです。セッションに入っているデータをとってくるというと、
いろんなからくりを作らないと無理っぽそうですが、ファイルをＸＭＬで書き出し、
そのファイル名をクライアント側に渡してしまえば、あとは、フツーのＡＪＡＸ
でのＸＭＬ取得の話でｓ。

---

　で、今回は、そーいうことをいいたいんじゃなくって、

　クライアント側で、仮にクッキーも受け付けず、ＵＲＬにもいれない、つまり、セッションは一切使いたくないとしたとします。
　それでも、サーバーからみると、サーバープログラムと、その直後のＪＳＰにおいては、セッションを利用して、データを受け渡すことは可能だということです。

　たしかに、複数画面間のデータ受け渡しにはセッションＩＤをつかって、セッションをみつけるので、セッションＩＤがないとこまります。なので、クライアントでセッションＩＤを受け渡すことを、上記のように拒否された場合、”複数画面間での”データ受け渡しは出来ません。

---

　しかし、”１画面を出力するまでの”サーバープログラムと直後のＪＳＰの関係においては、クライアントはでてこないので、ここでセッションを利用して、データ共有することは可能です。つまり、”１画面内で複数プログラムがあるときの”データ受け渡しは可能です。

　おなじことが、ＰＨＰプログラムにもいえます。
　サーバー側でＰＨＰプログラムが１画面を出力する間に複数動く場合、セッションに処理したデータを突っ込んでしまえば、そのプログラム間でセッションによるデータ共有は可能です。
　ただし、複数画面における画面間でのデータ共有は、クライアント側で、セッションを利用できるように（＝クッキーを受け入れるか、ＵＲＬにセッション番号を付けることをＯＫとする等）しないとできません。

---

　この特徴を使って、ＭＶＣにプログラムをわけて、各プログラムにおいて、他プログラムに渡したいデータをセッションにいれてしまい、データ共有させたのが、カオル姫方式です。

　ということで、Ｓｔｒｕｔｓの話ができそうです。