Navaneethは、まだ、話がわかる人みたいなので、高いレイヤーでのインターフェース案を受け入れる可能性がありそうな気がする。というわけで、まだ、わずかながらの交渉の余地は残っている気もするけど、問題はどれだけの時間をそれにかけるかだな・・・。こちらとしては、実装する期限があるので、のんびりとしているわけにも行かない。まぁ、そこいらのバランスだな。でも、たぶん、確定するのを待たずに実装を始める気がする・・・。
カテゴリー: Java
ポートレットフィルタ
ポートレットフィルタも1.0からいろいろと修正がされていて、Apache Portals にある 1.0 は、現在、あまり望ましくありません・・・。というわけで、どれを使えばいいのかというと、最新版を以下に置いたので、それを利用するのが良いです。
MyFaces のポートレット対応
Stan がいじっているので、どうなったか確認してみる。
- 相変わらず、FacesContext をセッションに入れる
- prcessActionからrenderへRequestのAttributeを渡すのには、SavedRequestAttributesを利用して、processActionですべてを保存(つまり、セッションへ・・・)、そして、上書きしないようにrenderで復元。そして、このSavedRequestAttributesは、セッションから削除されないような気が・・・。
- 各 render の終わりには、renderCleanup でセッションにある CURRENT_FACES_CONTEXT のFacesContextインスタンスを削除。ついに消したか・・・。これで、１つのページに複数のポートレットがあるときに、他のポートレットが更新されたときにページを維持できなくなったでしょう。まぁ、苦情が多かったから、仕方がないというものあるけど。
- REDEPLOY_FLAG を使って、ポートレットの再配備を確認している。
と言ったところかな。まぁ、個人的には、２番目のやつが大問題になると思うのだけど(JSFの実装にもよるが)。TeedaのFacesPortletでは、それは避けないとなっとちょうど思ったいたものだし。２番目は、新たな苦情の発生源になる気もする。最後のREDEPLOY_FLAGは、面白いな。これはTeedaのポートレットにも導入する価値はあると思う。まぁ、感想としては、１歩進んで、２歩さがる(後退じゃん)ような実装な感じな気がする。