Fusayuki Minamoto
fusay****@gmail*****
2009年 6月 3日 (水) 13:59:24 JST
佐野さん 返信が遅れてすみません。 インラインで書かせていただきます。 2009/06/01 9:54 佐野大輔 <d-san****@nri*****>: > 2.「Web Beanにおいて、それがデフォルトのバインディングタイプに加えて別の > バインディングタイプを持つ場合」の具体例がわからない > → > PaymentProcessorクラスがPaymentクラスを継承していて、 > > @Current PaymentProcessor paymentProcessor; > @Payment Payment payment; > > 上のpaymentProcessorとpaymentに同じPaymentProcessorクラスの > インスタンスを注入したいような場合には、 > PaymentProcessorクラスの定義に、 > > @Current > @Payment > public class PaymentProcessor extends Payment { > ... > > のようにWeb Beanの定義の方にも@Currentを入れるってことなんですかね？ > もう一回読み込んでみます。 上の例で理解できました。 「Web Beanの定義の方にも@Currentを入れるってこと」で良いと思います。 JSR 299の仕様書で5.2 Type Resolutionの記述を確認してみました(5/30版のPDF)。 これを見ると、Beanを解決するとき、Binding Annotationに関しては、 ・BeanにBinding Annotationの宣言がない場合は、@Currentがついているものとみなす ・その上で、Binding Annotationが一致しているものを選択し、探索対象を絞る と読めました。 たとえば、Web Bean定義にBinding Annotationが1つだけしかついていない場合、 Web Beansのコンテナはそれと一致しているものしか選択しないことになります。 ということで、Binding AnnotationがついているWeb Beanを@Currentで宣言した フィールドにインジェクト可能にするためには、Web Bean定義において、 @Currentを付加すればよいということで合点がいきました。 （逆に、＠CurrentをWeb Beansの宣言に付加しなければ、それは＠Currentの フィールドへインジェクトされなくなります） でも、Web Beans定義に＠Currentを入れる場合と入れない場合の使い分けが Web Beans開発者に委ねられることになりますね。 Binding Annotationは実装を識別するものなので、APIタイプとは異なるような属性も 表現できるでしょうから、@Currentを宣言をつけられるか否かはAnnotationが意味する 内容に依存するということでしょうね。 良い例ではないですが、キャッシングのための多くのメモリを使用するようなBeanを 安易に@Currentのフィールドにインジェクトするのは良くないという場合もありそうです。 > > 3.「これは、共通のPOST-then-redirectパターンの実装をとても簡単なものに > し、"flash"オブジェクトのような脆弱なアーキテクチャに頼る必要がありませ > ん。」の部分がわからない > → > これは、多分大したことを言っていなくて、 > POST-then-redirectパターンがフレームワークとしてサポートされることによっ > て、ページ、ひいてはコンポーネントドリブンなアプリケーションを簡単に作る > ことができ、 > （サーブレット/JSPとかだと、ブックマーク可能なURLの中で、サーブレットと > JSPのURLが混ぜこぜになったり、それを避けるために毎回リダイレクトさせるよ > うな処理を追加したり大変だったので） > AdobeのFlash（のことだと思うんですが）みたいなものを使わなくても良くなった。 > というようなことが書いてあるんだと思うんですが。。 > もうちょっと読み込んでわかりやすいように意訳したいと思います。 なるほど、AdobeのFlashですか。わかりました。 ありがとうございます。 -- 皆本 房幸 <fusay****@gmail*****> http://d.hatena.ne.jp/neverbird/
