佐野大輔
sanod****@mail1*****
2009年 6月 4日 (木) 01:12:41 JST
和田さん、ありがとうございます。 なるほど、RoRですか。知りませんでした。 まずかったですね。。 これですね。 >http://rubist.blog77.fc2.com/blog-entry-99.html なぜ、fragileと言っているのかははっきり分かりませんが、 >http://d.hatena.ne.jp/LukeSilvia/20070711/1184191946 に書いてあるように、必ずリダイレクトと共に用いなければ、 意図した動作にならないこと。 また、長期対話のような強力なことはやりようがないことなどを、 意味しているのかもしれません。 訳ですが、「RoRの」と明記したうえで、当初、 良く分からないけどセキュリティ対策のようなことを言ってるんだろうと思って fragileを「脆弱な」と訳していましたが、どうやらセキュリティに関することではなさそうなので、 （セキュリティという意味ではリダイレクトのURLにパラメタを載せる方が弱そうな感じもしますし。 次のリクエストに無理やりパラメタをくっつけたらどうなるんでしょうね？） 「貧弱な」という風に変えたいと思います。 ニュアンスの問題かもしれませんが。。 → これは、よくあるPOST-then-redirectパターンの実装をとても簡単なものにし、Ruby on Railsの\"flash\"オブジェクトのような貧弱なアーキテクチャに頼る必要がありません。このようなケースで、Web Beanマネージャは自動的にリダイレクトURLにリクエストパラメタを付加します。 で、5章もコメントを反映してコミットしました。 2009/06/03 23:27 Hiroyuki Wada <wadah****@gmail*****>: > 和田です。 > お疲れさまです。 > >>> 3.「これは、共通のPOST-then-redirectパターンの実装をとても簡単なものに >>> し、"flash"オブジェクトのような脆弱なアーキテクチャに頼る必要がありませ >>> ん。」の部分がわからない >>> … >>> AdobeのFlash（のことだと思うんですが）みたいなものを使わなくても良くなった。 >>> というようなことが書いてあるんだと思うんですが。。 >>> もうちょっと読み込んでわかりやすいように意訳したいと思います。 >> >> なるほど、AdobeのFlashですか。わかりました。 >> ありがとうございます。 > > 私はRuby on Railsなどが提供しているFlashスコープのことだと思いました。 > Seamのフォーラムにも"flash object"という言葉で出ていますし。 > > http://seamframework.org/Documentation/DoesSeamHaveSomethingLikeTheRubyOnRailsFlashObject > > WebBeansの対話スコープは、短期対話の状態でもリダイレクト > を跨いで伝播させることができるので、(Railsのような) > Flashスコープのような仕組みを必要としないよ、ということを > 言っていると思います。 > (なぜ"fragile"とまで言っているのかは分かりませんが... ) > > > 以上です。 > > 2009/6/3 Fusayuki Minamoto <fusay****@gmail*****>: >> 佐野さん >> >> 返信が遅れてすみません。 >> インラインで書かせていただきます。 >> >> 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/ >> >> _______________________________________________ >> Japan-jbug-translators mailing list >> Japan****@lists***** >> http://lists.sourceforge.jp/mailman/listinfo/japan-jbug-translators >> > > _______________________________________________ > Japan-jbug-translators mailing list > Japan****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/japan-jbug-translators >
