上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

UIコンポーネント2 [2008/11/21 (金)]

2008/10/20の記事に追記で書いた方法よりもっといい方法を見つけたっぽい気がする…。(前の記事の方法はお蔵入り…うまくいきそうにない…。ちなみに今回の方法はある程度検証済み!!)

その記事でおいらはJSFの複数のコンポーネントの値を連携させようとしていた。で、遅延評価式の確定は大概RenderResponseフェーズだって事に気づいた。そんなら、そこで確定した値を他のコンポーネントに設定するのは同じくRenderResponseフェーズしかないわけで…。だけど、RenderResponseフェーズでetcいじるのはまずいのでは…という事に。

今回の方法のポイントはMapを利用したEL式を作る所。参照する時はこんな感じ…

#{requestScope['myFQCN']['clientId']['key']}

キーの意味はそれぞれ…

myFQCN
専用クラスのFQCN (FQCNでなくても他とかぶらなければ何でもいい)
clienId
子コンポーネントと共有すべき値を持つ親コンポーネントのclientId
key
共有する属性値のキー

で、このマップに対して…

  1. PhaseListenerでRenderResponseフェーズの直前に共有すべき値を持つ コンポーネント(マーカインタフェース等で識別)の全てにアナウンスを流す。
  2. アナウンスを受けたコンポーネントは自身のclientIdと共有属性のキーを指定して先のマップを参照するEL式を作り、それを子コンポーネントのEL式として設定。
  3. コンポーネントはレンダリングと同時に自身のELを評価して、その値を先のマップに設定する。

こうすれば、遅延評価式の評価はレンダリング時に行われ、なおかつ連携するコンポーネントは予め設定された場所を参照するだけなので、レンダリング時にコンポーネントの値を再設定する必要が無い。

ちなみに、本当はMapを使わなくても、EL式から参照できてコンポーネントの外で値を共有出来れば何でもいい。ただEL式には予めマップを処理する機能があるのでありがたく拝借する。

UMLシーケンス図

役に立ったらぽちっとよろしく。 人気ブログランキングへ

スポンサーサイト

JPAでは保存・復元時にプロパティ経由かフィールド経由か選べる。

オブジェクト指向の入門本を読むと、フィールドを直接使うよりプロパティを通してアクセスした方がフィールドアクセス時の必須操作を必ず実行させるように出来るので、自前でフィールドにアクセスするよりも遥かに安全。だからなるべくプロパティを使うように!と書いてある。…ので、ここもプロパティでしょ!と思ったら…。

プロパティの場合だと、publicとprotectedにしか使えない。これだとエンティティクラスのAPIを公開する時にそれらの部分も必ず公開される事になる。たとえ、それがエンティティの作成時刻の様にただ一度設定されるものであっても、再設定の機会をライブラリ使用者に与えてしまう。これはまずい…。ちなみにもっと酷い場合は以下の様になる。

/* 知ると消される国家機密. */
@Column(name="danger_info")
public String getDangerInfo() {
    return dangerInfo;
}
/* 落書厳禁マフィアの隠れ家. */
public void setDangerInfo(String dangerInfo) {
    this.dangerInfo = dangerInfo;
}
private String dangerInfo;

これではプログラマの命が幾つあっても足りない…。そんなこんなで、仕方なくフィールド経由にするか…と鬱々なる……けど、案外そっちのが妥当と気づいた。

てのはMementoパターン[Gof]がこれに似てる。Mementoパターンも保存復元の内部動作を担当するクラスに対しては保存情報(記念品:Memento)の中身へのアクセスを許可している。つまり、保存復元というテーマを扱う以上、通常の小さなインタフェースの他に、保存復元を担当する部分に提供するprivateでもアクセス出来るインタフェースを備えるのはごく自然な流れである。

一方、エンティティのフィールドにおいても、保存・復元を担うJPAはprivateでもアクセスするようになっている。つまり、先のMementoの例と似ている。しかもこの場合、JPAが直に元のprivateフィールドにアクセスするので記念品作りは必要ない。しかも、別にそのフィールドに新たなプロパティをかぶせてはいけないって事ではないのでロジック部分もきちんと作りこめる。というわけでJPAエンジンのアクセスはフィールド経由でしょっ!!て事になる。

ところが今度は…「じゃぁプロパティ版は何のためにあんの?」って疑問が出てくる。自分ではさっぱり分からなくなったので、サクッとググっとしてみると…

Adam Bien's Weblog
Property Based Access in JPA - is an Emerging Antipattern

発見!!…どうやらプロパティ版はアンチパターンだと…。ただ、必要になる場面もあるらしく、Detached状態にあるエンティティを値オブジェクトとして使う時とかがそれらしい。つまり、例え遅延ロードが有効になっていてManagedの時にロード(フェッチ)が行われてなくて、Detachedになっちゃっても取り敢えず何とかシリアライズ出来るよ言う事らしい。うーん、なるほど!!

役に立ったらぽちっとよろしく。 人気ブログランキングへ

続きを読む »

First contact… [2008/11/04 (火)]

こないだの記事の内容、色々調べたけども、結局分からなかった…。なので、どっかの掲示板に投稿しようと思った。だけど日本語のサイトでぴったしの掲示板が見当たらない…。しかたないので、海外のサイトに投稿する事に…もちろん英語で…。

結論だけ言うと、どうやらJSFの仕様的バグかも…ということらしい。つまり、めずらしい事に、おいらの疑問は正しかったみたい。………なんだけど、問題はその結論に辿り着くまでのやりとり。ぶっちゃけ、おいらの英語は中学で習ったレベルで、コンピュータ関連の英語だけ必要に迫られてReadOnlyって程度。それでも英語、日本語、コンピュータ全て出来る外国の人が昔は側にいてくれてたので、それをいい事にサボり続け今に至る…。なので、一人であちゃらのサイトに投稿する等出来るはずもないのだけども、もうそれしか手は無い…。それに…エンジニア同士だしソースコードのみでも伝わるだろう…と思ってた。けどいざ書いて見るとものの見事に伝わらない!もう誤解の連続…。

以下が、そのスレッド…。なんかもう誤解を生みまくりでニュアンスもきっと全部凄い失礼な感じになってる可能性大!!そんなで分けも分からずとにかく誤りまくっている自分…笑。そして、どんなに変な英語でも、ちゃんとレスを返してくれるあちゃらの方々!

Sun's JSF Forum
http://forums.sun.com/thread.jspa?threadID=5343413&tstart=0

あちゃらの方々皆がそうではないんだろうけども…、これだけ根気強く対応をされると、おいらは使えなくて残念なんだけど、、、うんやっぱり世界の共通語はこの人らの言葉がいい!…と思ったのでした。

…ん?てか「おいらは使えなくて残念なんだけど」と書くと、まるで英語・日本語以外でなんか他の言葉を喋れそうなニュアンスになる気もする。…違う…、日本語だけ…いや…つまり日本語もまともに使えてない可能性大………。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

Copyright © ふらふら技術者の日記 All Rights Reserved.
Powered by FC2 Blog
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。