カテゴリー: Java

Stan がいじっているので、どうなったか確認してみる。

• 相変わらず、FacesContext をセッションに入れる
• prcessActionからrenderへRequestのAttributeを渡すのには、SavedRequestAttributesを利用して、processActionですべてを保存(つまり、セッションへ・・・)、そして、上書きしないようにrenderで復元。そして、このSavedRequestAttributesは、セッションから削除されないような気が・・・。
• 各 render の終わりには、renderCleanup でセッションにある CURRENT_FACES_CONTEXT のFacesContextインスタンスを削除。ついに消したか・・・。これで、１つのページに複数のポートレットがあるときに、他のポートレットが更新されたときにページを維持できなくなったでしょう。まぁ、苦情が多かったから、仕方がないというものあるけど。
• REDEPLOY_FLAG を使って、ポートレットの再配備を確認している。

と言ったところかな。まぁ、個人的には、２番目のやつが大問題になると思うのだけど(JSFの実装にもよるが)。TeedaのFacesPortletでは、それは避けないとなっとちょうど思ったいたものだし。２番目は、新たな苦情の発生源になる気もする。最後のREDEPLOY_FLAGは、面白いな。これはTeedaのポートレットにも導入する価値はあると思う。まぁ、感想としては、１歩進んで、２歩さがる(後退じゃん)ような実装な感じな気がする。

近頃、Stanがいじったみたいだ。後で見てみる必要があるな。

現在、より良いJSFのポートレット実装について、研究中。java.netの実装についてふと思ったのだが、これの実装だと、ポートレットのwarの中でサーブレットを使いたい(たとえば、ポートレットでダウンロード可能なファイルを一覧して、サーブレットでダウンロードさせるなど。まぁ、JSR 168じゃ、これは無理だけど、次のJSR 286では可能になっているとは思うけど)と言う場合に、動かんと思う。と言うわけで、注意した方がいいかも(まぁ、今使っている人はほとんどいないと思うけど、Sun系の実装だと知らぬ間にこれを使っている可能性もあるのかな。java.netにあるから)。