ansaurus

Question

Answer 1

+3 A:

You need to fire ExternalContext#redirect() in the bean action method yourself.

public void submit() {
    String url = "page.jsp?name1=value1&name2=value2";
    FacesContext.getCurrentInstance().getExternalContext().redirect(url);
}

If your IDE validator is jerking about the void action method, then you can just ignore it or declare it back to String and put return null; at end of method block.

If you want to set the particular parameters back in some bean in the subsequent request, then you can set them as managed properties in faces-config.xml by #{param.name1} and #{param.name2}.

That said, request attributes should not be confused with request parameters. The request attributes are attached to the current request in the server side only. They are in no way passed to the next request. There you use request parameters for which you can either attach to the redirect URL or include as hidden parameters in a POST form in the response page.

Further, it might be useful to know that you can get a handle of the HttpServletRequest in JSF by ExternalContext#getRequest(). You should however try to avoid to go that far with hauling the "raw" Servlet API from under the JSF hoods. Make use of JSF-provided facilities as many as possible.

BalusC 2009-12-31 20:04:08

Thank you for your response. I have seen this approach used in our application however I am wondering that since this particular class has an 'outcome' which then goes to faces-config.xml to decide the next url the user should be taken to, following the approach above seems to override that. I am wondering what happens to the navigation rules, if I sort of hard-code the url with the query params? Is there no other elegant way to say... follow the navigation rules and just add on these params to the end?

msharma 2009-12-31 20:23:51

Navigation rules will be ignored. `ExternalContext#redirect()` will call `FacesContext#responseComplete()`.

BalusC 2010-01-01 02:17:46

@BalusC - by the letter of the spec, that URL should pass through `ExternalContext.encodeActionURL` prior to being used for redirect - though in most cases it will be returned unchanged.

McDowell 2010-01-01 18:40:06

Hi BalusC, I am trying to implement what you suggested as we as using JSF1.2 and do not have the cool features McDowell has kindly suggested. I am hitting a problem though, any ideas, I ahve edited my original post.

msharma 2010-01-05 17:28:27

The exception says that the response was already committed. Part of it is already sent to the client. This is a point of no return. You cannot change it anymore with sendredirect. Do you have something in servlet/filter chain which is altering the response? E.g. setting some headers, writing something to output and/or flushing the output, etc. Was it by the way an ajax or normal request?

BalusC 2010-01-05 17:43:00

I am displaying headers from a properties file on the next page that the user is directed to, and there is a nullpointer for the facescontext there! Please see details above.

msharma 2010-01-05 18:26:31

Uh, you aren't supposed to write raw Java code in a JSP file. Besides, there is no means of a FacesContext in a normal JSP/HTML request. If you need the FacesContext, you need to create a JSF page and pass request through the url-pattern of the FacesServlet and you need to write Java code in a backing bean rather than inside the JSP file.

BalusC 2010-01-05 18:41:55

Maybe I'm not explaining too well, this is jsf page, and its existing architecture, so I'm trying to grasp it as I go along. The requests are being passed thru the url-pattern of FacesServlet defined in our web.xmlI have a hunch that I am close but have not fully resolved the issue. Since we have internationalization so we NEED to get translations for all content displayed, we have to use properties files for this. So I dont think its an issue with the headers....if I simply define an outcome there are no errors, since the navigation rules kick in.

msharma 2010-01-05 19:40:09

After much struggle... having Jboss corruption and other environmental issues I am happy to say that this has worked! I can see the URL for the next page with the appended params in the URL :-)For some reason I used to get the FacesContext.getCurrentInstance()=null but after debugging again and again it it started working... i.e. FacesContext was not null, I did NOT make any code changes....so it is surprising, I guess its the X-factor of programming! Many thanks BalusC...you rock!

msharma 2010-01-07 21:32:35

The `FacesContext` will be null when the request URL didn't match the `FacesServlet`'s `url-pattern`. E.g. you invoked `page.jsp` instead of `page.jsf` in URL while the `url-pattern` is `*.jsf`. The `FacesServlet` is the one who creates the `FacesContext`. Glad you fixed it. You're welcome.

BalusC 2010-01-07 21:38:03

Answer 2

+1 A:

JSF 2 added parameters to the navigation handler via the view-param element. From the spec:

If a matching <navigation-case> element was located, and the <redirect/> element was specified in this <navigation-case>, call getRedirectURL() on the ViewHandler, passing the current FacesContext, the <to-view-id>, any name=value parameter pairs specified within <view-param> elements within the element, and the value of the include-view-params attribute of the <redirect /> element if present, false, if not. The return from this method is the value to be sent to the client to which the redirect will occurr. Call getFlash().setRedirect(true) on the current FacesContext. Cause the current response to perform an HTTP redirect to this path, and call responseComplete() on the FacesContext instance for the current request. If the content of <to-view-id> is a value expression, first evaluate it to obtain the value of the view id.

McDowell 2010-01-01 18:37:37

ansaurus

tags:

views:

answers:

JSF adding query parameters

related questions