MyFaces のポートレット対応

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

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

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

java.netのFacesPortlet

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

SHALE-282

コメントしてくれていたのに、気がつかなかった(興味がないコミットやバグの通知メールはYahooメールのフィルタリングで全然見ていない。Mavenとか何もしないと大量に受信して、本当に読むべきものが読めなかったりするから)・・・。というわけで、コメントをしておいた。まぁ、今のところ、Shaleは使わないから、特に問題はないけど。

Trinidad on Portal

ADF(Trinidad)を全然チェックしていなかったけど、ADFのメーリングリストで私の名前が挙がっている話題があったので、読んでみると、どうも、Tomahawk同様にフィルタで何かやっているような雰囲気が・・・。それだと、やっかいだよね・・・。今のところ、Trinidadを使う予定はないので、私が作ることはないけど、誰かが作ってくれるような雰囲気があるのでほっておこう。となると、TomahawkとTrinidadを同時に使うとなると、もっと汎用的なコードにしないとだめだと思うな。まぁ、将来的にはMyFacesブリッジの手法を汎用化しようとは思っていたけど。

個人的には、とっととMYFACES-434を終了してほしい。もう1年近くたつわけだから・・・。Martinの話だと、近々、やってくれるような感じだったな。ポートレットフィルタもここにきてようやく、認知され始めてきたので良いことだ。