JSR 168 のポートレットの処理

複数のポートレットがあった場合に、それぞれがどのような処理をするかをまとめる機会があったので、JSR 168 の肝になり、私の理解を整理するためにもまとめておきます。

たとえば、1つのページに A, B, C というポートレットがあった場合、A のフォームで送信すると A の ActionURL を使って、送信することになり、送られるフォームのデータは、A だけに送られ、その処理は、A の processAction ですることになります。このとき、B と C の processAction は呼ばれません。ですので、このとき、A の processAction が一番先に処理されるといえます。processAction では、A の render (doView など)で処理するためにデータを作成します。つまり、ActionResponse の setRenderParameter とかにデータを渡して、render で RenderRequestで getParameter で値をとれるようにします。これで、フォームデータの送信処理が完了だと思います。もし、A の処理が B と C に影響するような場合、ポートレット間のコミュニケーションが必要になり、これは、JSR 168 では、TODO になっています。これをやる場合には、ポートレットセッションのアプリケーションスコープで B と C で表示するためのデータを渡すことになります。J2 には、これをAPI化して、PortletMessaging というのがあります。

そして、次に render に移ります。このときの(普通は) A, B, C のどの順番で処理されるかは、保証されません(と思う)。まず、A については、processActionで作られた値が、RenderRequest の getParameter で取得することができます。B と C については、前回の値が保持されているので、同じ値が、getParameter で取得することができます。つまり、doView とかでデータベースへ追加などのビジネスロジックがあったりすると、他のポートレットでフォームの送信などのを処理されてページが更新されたりすると、そのたびにデータがデータベースに追加されてしまうなどの問題が起こると思います。つまり、RenderRequest で取得する値は、表示のためだけに使うものを置いておく必要があると思います。

と言う感じで、processAction では、ビジネスロジックを実行して、doView などのrenderでは、getParameter が何度同じ値を返してきても変な動作をしないように、表示にだけ使うためのデータを置いておくというのが特徴でしょうか。まぁ、この概念に慣れるまでに違和感がありましたが、慣れると、当然だなと言う気になりました。

コメントやつっこみ(^^)などありましたら、歓迎いたします。変な理解していたら、直しておきたいところですし♪

コメントを残す

メールアドレスが公開されることはありません。