You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Cosma Colanicchia <co...@gmail.com> on 2006/06/07 15:13:52 UTC

A solution for passing parameters between pages

I try to explain the solution I was thinking of.. a bit complicated to setup
because it is required to extend NavigationHandler and ViewHandler, but
once configured it is very simple to use.

Suppose you have a source-view.jsp that need to "call" a target view.

1) The source-view can use normal <f:param> in UICommands to pass parameters:

   <h:commandLink action="#{targetManagedBean.openTargetView}">
    <f:param name="paramName1" value="1"/>
    <f:param name="paramName2" value="2"/>
   </h:commandLink>


2) The openTargetView() method can get the parameters from the request
   and return an outcome.


3) Our CustomNavigationHandler is activated to find the next view.
   Searching for a matching <navigation-case> is done as in myfaces
   implementation, but the <to-view-id> is parsed to support an
   extended syntax:

   <navigation-rule>
    <navigation-case>
     <from-action>#{targetManagedBean.openTargetView}</from-action>
     <from-outcome>success</from-outcome>
     <to-view-id>/target-view.jsp(paramName1, paramName2)</to-view-id>
    </navigation-case>
   </navigation-rule>

   If any parameters have been specified in this way, we first check that
   those params are effectively present in the request parameters, then
   we create a Map object with them, and put it in the sessionScope under
   a key equals to the view-id:

   session-attributes-map
     view-id-map
       "paramName1" = "1"
       "paramName2" = "2"

   Note: if we use ADF Faces, then pageFlowScope should be used instead of
   sessionScope to better support the Dialog Framework.

   Then, we proceed as the myfaces implementation does, creating a view for
   the view id (with the extend syntax stripped out) and forwarding or
   redirecting (redirect is safe now).


4) We need also to extend the ViewHandler in order to restore the parameters.
   Our CustomViewHandler should check the sessionScope (or pageFlowScope) for
   the attribute named as its view-id. If so, its values should be exposed
   to the page (as requestScope attributes or as request parameters) and the
   Map removed from its original scope.


Compared to requestScope:
ADVANTAGES:
 - <redirect/> is trasparently supported
 - ADF Dialog Framework is supported by using the pageFlowScope
 - View parameters checking

Compared to sessionScope:
ADVANTAGES:
 - Multiple windows are supported
 - Multiple views using the same parameter names are supported
 - Avoid risk of reusing old session data (thanks to session cleaning)
 - View parameters checking
DRAWBACKS:
 - The page need to have hidden fields if it wants parameters to
   survive POSTbacks.

Compared to simple pageFlowScope:
ADVANTAGES:
 - Avoid risk of reusing old data (thanks to pageFlowScope cleaning)
   Note that a new pageFlow is created only when starting a new ADF Faces
   Dialog, otherwise a "common" pageFlow which has the same lifetime of
   the session is used.
 - View parameters checking
DRAWBACKS:
 - The page need to have hidden fields if it wants parameters to
   survive POSTbacks.

I'd like to anticipate the parameters checking before the method binding
is executed, but I can't find a point to plug any logic before that point..

Note that this should work also if your action is itself an outcome instead
of a method binding (simply skip step 2).


Any suggestion is welcome :-)
Cosma