Re: ADF, PrettyFaces and a persistent query param

Splash Forums PrettyFaces Users ADF, PrettyFaces and a persistent query param Re: ADF, PrettyFaces and a persistent query param

#21582

clemmonsm
Participant

Correct, the _adf.ctrl-state parameter is included in the URL as a query parameter AND is included in the HTML form tag as an attribute for normal ADF behavior.

For your 1., yes, when I append the query param to the pretty:links in processOutbound(), the links rendered to the HTML page via processOutbound() contain the _adf.ctrl-state parameter and ADF sees the param and loads the target page with the same parameter, so the session state stays intact.

Here is the processOutbound() code I use for this scenario:

public String processOutbound(final HttpServletRequest request, final HttpServletResponse response, final RewriteRule rewrite, final String url) {

if (request.getParameterValues("_adf.ctrl-state") != null && !url.contains("_adf.ctrl-state")) {
// param exists and is not assigned to url, so append _adf.ctrl-state key/value to query string
String newUrl = url + "?_adf.ctrl-state=" + request.getParameterValues("_adf.ctrl-state")[0];
return newUrl;
}

return url;
}

Here is the resulting HTML link on the page:

<a href="/homes/about-us/welcome/?_adf.ctrl-state=i81e0uwwi_4">
About Us
</a>

In regards to your 2., to get a clean look at the processing, I retested without any outbound or inbound processing logic and without any limitations from a regex match on the rewrite (so I could see every call to processInbound() ). The below order of operations was the result. Remember, in this scenario, I am not appending the param to the outbound links.

Here is what happens inside processInbound() when the user clicks the pretty:link URL “/homes/about-us/welcome/” given the scenario described above (fyi, “homes” is the context root):

1st call: Request object: none; URL: /about-us/welcome/

2nd call: Request object: none; URL: /about-us/welcome/?_afrLoop=1320336831920366000&_afrWindowMode=0&_afrWindowId=nlrvjdams_1

3rd call: Request object: exists; URL: /about-us/welcome/?_afrLoop=1320336859052522000&_afrWindowMode=0&_adf.ctrl-state=nlrvjdams_9

Subsequent call are all css, js, images, etc.

Note that on the third call, ADF has determined there is no “_adf.ctrl-state” param for this server-browser instance, so it reinitializes and increments the token value from nlrvjdams_4 to nlrvjdams_9.

Came across this today: http://www.scribd.com/doc/58980702/38/Appendix-Redirecting-a-JSF-view-to-itself

Notably, this statement: “The ControllerContext.getInstance() method appends the ADF controller _adf.ctrl-state token tothe redirect URL it creates to ensure that when the document re-renders, the page state, such asthe current row selection of a table is preserved.”

Before we used Pretty Faces, this is how we redirected in the app. For ex:

public void redirectAboutWelcome(ActionEvent actionEvent) {
String viewId = "pages/about-welcome.jspx";
ControllerContext controllerCtx = null;
controllerCtx = ControllerContext.getInstance();
String activityURL =
controllerCtx.getGlobalViewActivityURL(viewId);
try {
this.facesContext().getExternalContext().redirect(activityURL);

} catch (IOException e) {
// Can't redirect
e.printStackTrace();
}
}

I actually did not realize that ControllerContext.getInstance() also managed the _adf.ctrl-state token. I wonder if this means that ADF is not set up to handle redirects in this manner…