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
