日々の破片

_ Sun Java Studio Creatorリリース

これがあのJSCかというくらいマトモになっている。

1.JSFコンポーネントのアイコンが立体できれいになった（どうでもいいことだけど、結構重要な気が）

2.Page#getBean、Page#setBeanがまともに動作する。

3.アーリーアクセスではただのゴミだったアプリケーションビーンとセッションビーンが、ページビーンに統合された。

疑問：で、どうやってPage#getBean（これはたどれば良いからまあいいとして）、Page#setBeanがスコープを判断するのだろうか？ （試してみると、Managed Beanのmanaged-bean-name要素に登録されていればmanaged-bean-scope要素の記述に従い、それ以外ならリクエストスコープという判断のようだ）

4.やっと日本語というか、JSPを勝手に書き換えなくなったし、ロケールを見て勝手に初期設定してくれる（Windows XPではWindows-31Jになっている。良い判断だ）。とは言え、別の言語に変えると、ちょっとしたはずみでWindows-31Jに変わるんだったら以前と変わらないわけだがとりあえずその検証は不要なのでおいておく。

5.ヘルプも妙にきれいになった。

6.パッケージの変名はうまくいっているのかな？ パッケージ名にa.b.cを入れるとa.b.cというディレクトリができてしまうが、WEB-INF/classesの下にはa/b/c/とできているからまあいいのかも。（追記：コンパイルは通るがインテリセンスが赤いバツを食らわしてうるさいから、ちゃんとディレクトリを分離しなければならないようだ。分離させるのはまだ試していない。）

相変わらずダメな点：

1.PageBeanのJavadocが無い。インテリセンスのヘルプがすべてなのか？ Helpメニューで検索してもAbstractPageBeanでは意味が無いページが1箇所ひっかかるだけだ。

後はこれから。

_ ページビーンフレームワークのメモ

ページ（フォーム）フレームワークというのは、ASP.NET＋VS.NETのフレームワークで、JSCはある程度まではそれを踏襲しているが、異なる点もある。

一番異なるのは、最初からセッションビーンとアプリケーションビーンというものをプロジェクトに用意している点だ。

ASP.NETの場合、アプリケーションスコープ（そもそもJ2EEのServletフレームワークではないから、アプリケーションスコープとは呼ばないが）相当のHttpApplicationStateクラスのインスタンスと、セッションスコープに相当するHttpSessionStateクラスのインスタンスは、基本的にASP.NETが提供するクラスを直接使い、それぞれのインデクサに対して値を設定する（サーブレットのServletContextおよびHttpSessionに相当すると考えれば良い）のだが、JSCでは、このあたりはPage#getBean、Page#setBeanという形で目に見えないようにし（区別が必要な場合はManaged Beanの設定に行う）、PageBean間の値の受け渡しには直接setBeanで設定した値を利用するかあるいは直前のページビーンそのものを参照し、セッションおよびアプリケーションスコープで保持すべき情報が必要であればそれぞれManaged Beanの設定にあらかじめ組み込まれているアプリケーションビーンまたはセッションビーンに対してフィールドを作成することで対応する、ということのようだ。（追記：直接いじりたい＝マップマンセーな人用にPage#getSessionMapとかPage#getApplicationMapとかは用意されているが……最後の手段――用意はしておくがそれを使うことはしない――だろうなぁ）

ページビーンとJSPは基本的に（Managed Beanの設定では同一ページビーンを複数のJSPで共用することも可能だろうがあまり良い方法とは考えにくい）密結合しているから、StrutsのようなJSPタイプ2フレームワークのようにMVCモデルで考えるのには向かない（VとCが密結合しているからだ）。むしろBCEのBとしてページがあり、パラメータ的にビジュアル編集可能なJSPとそのコード（プロセス）を記述するページビーンと、共用情報としてのセッション/アプリケーションビーンがあると考えたほうが素直だろう。

ではCやEはといえば、EJBが好きならローカルホームインターフェイスを呼び出せば良いし、単一JVMで済むのならDIコンテナを使えば良いということになる。Strutsにマッピングすれば、アクション（ページビーンのイベントハンドラに対応させる）＋アクションフォーム（JSF＋バリデータ）＝ページビーンとなるから、それほどわけがわからないことでは無い（やりたければ、AbstractPageBean > ProjectCommonPageBean > 個別ページビーン と実装継承したって構わないわけだが、JSCがうまくハンドリングできるかは別問題）。ASP.NETにようにIsPostBackメソッドがページに実装されているわけではないから必ずしも1ページでリクエストレスポンスをやる必然も無い（というか、判断するのが難しいような気がするけど）。

#Struts使ったって、ActionからいきなりJDBC使う実装だってできちゃうわけだから、JSCを使ってイベントハンドラでいきなりDataSource#getConnectionしていろいろやることも可能なわけで、それで構わなければそれで構わないのだが、そういうのってテストはどうするんだという問題が常に付いて回るわけだから、やらないのが賢明。VBだってまともに作ればイベントハンドラから内包したコンポーネントへ委譲するように作るわけで、どんなフレームワークを使おうが妙な方法論を採用すればそれなりの結果になるということだ。たとえば：ソースファイルは1個にしましょう、とか。

_ あの

XをクリックしてJSCを終了させた場合、AppServerとPointbaseは起動しておいたままにしてくれるんですか？ 親切過ぎると思うんですが。