Because I am constantly busy working on something, I have never had time to actually put everything in words and pictures. But, since you got here, then you must have already seen some part of my work - and this is the way I’m talking.I'm 23, born in Romania, student at UPG Romania in software development field. I started from 0, mostly with basic stuff, and I’m evolving every day to an expert. I'm focused on freelancing projects, from small websites, to really heavy stuff. I know that I look and act differently from most developers, but this is why you will love to work with me! Constantin has posted 42 posts at DZone. You can read more from them at their website. View Full User Profile

How to Pass JSF Parameters with HTTP GET Within the URL

04.12.2011
| 34395 views |
  • submit to reddit

In this recipe, you can see a quick method of retrieving parameters from JSF code.

Getting ready
We have developed this recipe with NetBeans 6.8, JSF 2.0, and GlassFish v3. The JSF 2.0 classes were obtained from the NetBeans JSF 2.0 bundled library.

How to do it...
You can retrieve parameters using the #{param.parameter_name} expression, such as the following (notice that the parameter is named id, and we are using #{param.id} to retrieve its value):


<h:form id="formId">
<h:commandButton id="btn1Id" value="Pass parameter 100 ..."
onclick="window.open('pagetwo.xhtml?id=100', 'MyWindow', 'height=350,
width=250, menubar=no,toolbar=no'); return false;" />
</h:form>
...
<h:outputText value="The parameter passed is: #{param.id}" />
...

Another solution is to retrieve the value through a managed bean, as shown next:
<h:form id="formId">
<h:commandButton id="btn2Id" value="Pass parameter 200 ..."
onclick="window.open('pagethree.xhtml?id=200', 'MyWindow', 'height=350,
width=250,menubar=no,toolbar=no'); return false;" />
</h:form>
...
<h:outputText value="The parameter passed is: #{bean.passedParameter}"/>
...


The managed bean that actually retrieves the parameter value is:
package bean;

import javax.faces.bean.ManagedBean;
import javax.faces.bean.RequestScoped;
import javax.faces.context.FacesContext;

@ManagedBean
@RequestScoped
public class Bean {

private String passedParameter;

public String getPassedParameter() {
FacesContext facesContext = FacesContext.getCurrentInstance();
this.passedParameter = (String) facesContext.getExternalContext().
getRequestParameterMap().get("id");
return this.passedParameter;
}

public void setPassedParameter(String passedParameter) {
this.passedParameter = passedParameter;
}
}


How it works...
In the first example, the task is performed by the EL, #{param.parameter_name}, while, in the second example, the managed bean uses the getRequestParameterMap function, which has access to the GET request parameters.


You can find this recipe in JSF 2.0 Cookbook from Packt

 

From http://e-blog-java.blogspot.com/2011/03/how-to-pass-jsf-parameters-with-http.html

Published at DZone with permission of its author, Constantin Alin.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Cosmin Mutu replied on Tue, 2011/04/12 - 1:51am

I`m sorry, but is definetly not the way to do this.

Here`s a little information from Java Server Faces 2.0, The Complete Reference 

Comparing h:commandButton and h:button
What’s the difference between h:commandButton/h:commandLink and h:button/
link? The latter two components were introduced in 2.0 to enable bookmarkable
JSF pages, when used in concert with the “View Parameters” feature explained
later in this chapter. There are three main differences between h:button/h:link and
h:commandButton/h:commandLink.
First, h:button/h:link causes the browser to issue an HTTP GET request, while
h:commandButton/h:commandLink does a form POST. This means that any components
in the page that have values entered by the user, such as text fields, checkboxes, etc., will
not automatically be submitted to the server when using h:button/h:link. To cause values
to be submitted with h:button/h:link, extra action has to be taken, using the “View
Parameters” feature.
The second main difference between the two kinds of components is that h:button/
h:link has an outcome attribute to describe where to go next while h:commandButton/
h:commandLink uses an action attribute for this purpose. This is because the former
does not result in an ActionEvent in the event system, while the latter does.
Finally, and most important to the complete understanding of this feature, the
h:button/h:link components cause the navigation system to be asked to derive the
outcome during the rendering of the page, and the answer to this question is encoded
in the markup of the page. In contrast, the h:commandButton/h:commandLink
components cause the navigation system to be asked to derive the outcome on the
POSTBACK from the page. This is a difference in timing. Rendering always happens
before POSTBACK.

My post is not meant to denigrate your solution, I`m sure it works just fine, but it seems to be a bit odd to perform a window.open just to pass parameters via GET.

Cosmin Mutu replied on Tue, 2011/04/12 - 1:55am

And POST-REDIRECT-GET using VIEW PARAMETERS

------------------------------------------------------------

POST REDIRECT GET Using View Parameters The previous example reimplements the
registration application using a request-scoped bean and the flash. This example does so
with a request-scoped bean and the View Parameters feature.
JSF 2.0 introduced a feature similar in spirit to the “page parameters” feature found in
JBoss Seam, but the JSF 2.0 incarnation of the feature is tightly integrated with the core JSF
specification, making the feature easier to use and more powerful. Let’s show some example
code and explain how it works. The following main.xhtml file is a simplification of the one from
the section “Redirects and implicit navigation,” with the important change shown in boldface.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">
<h:head>
<title>A Simple JavaServer Faces 2.0 View</title>
</h:head>
<h:body>
<h:form>
<p> First name: <h:inputText id="fname"
value="#{userBean.firstName}" /> </p>
<p><h:commandButton value="submit"
action="page02?faces-redirect=true&amp;includeViewParams=true" /></p>
</h:form>
</h:body>
</html>
Note the expression &amp;includeViewParams=true. The &amp; entity is a separator.
JSF recognizes &amp; and the single & character as separators within the query string. The
value includeViewParams=true tells the navigation handler to include the view parameters
when performing the navigation. But what view parameters should be included? The view
parameters to be included when performing the navigation are declared on the to-view-id
page. In this case, we are using implicit navigation, so the implicit to-view-id is page02.xhtml.

Fab Mars replied on Tue, 2011/04/12 - 4:18pm

Here we go again. That's one of the most obvious things to do, and yet in the last 5 years we heard it was impossible to do, then very hard to do, and now...well...we find harder ways of doing it.

JSF 1.x

In your code:

public class MyManagedBean {

  private Long id;

  public Long getId() {
    return id;
  }
 
  //injected from #{param.id}
  public void setId(Long id) {
    if(id != null) {
      this.id = id;
    }
  }
}

  In your faces-context.xml

 <managed-bean>
  <managed-bean-name>myManagedBean</managed-bean-name>
  <managed-bean-class>com.example.MyManagedBean</managed-bean-class>
  <managed-bean-scope>request</managed-bean-scope>
  <managed-property>
   <property-name>id</property-name>
   <property-class>java.lang.Long</property-class>
   <value>#{param.id}</value>
  </managed-property>
</managed-bean>


JSF 2.x

Either Inject:
public class MyManagedBean {

  @ManagedProperty(value="#{param.id}")
  private Long id;

  //add get/set if you need
}

 Or use the View parameters:

<body>
 <f:metadata>
  <f:viewParam name="id" value="#{myManagedBean.id}" />       
 </f:metadata>
 <!-- put the rest of you view's code here -->
</body>

Over.

 

Mike P(Okidoky) replied on Tue, 2011/04/12 - 5:01pm

And end of day it all sucks because it doesn't separate design from content.

 

Fab Mars replied on Sun, 2011/04/24 - 6:47pm in response to: Mike P(Okidoky)

design from content...
design from content??
design from content????

After staring at my screen for 3 entire minutes trying to understand what you're trying to say, I came to the conclusion this statement is totally out of focus and you should consider reviewing the facelets manual, or even the whole jsf technology.

Lance Sloan replied on Tue, 2013/06/18 - 9:11am in response to: Fab Mars

Fab Mars, you're right.  Although this technique could make it easier to blur the division between design and content, that doesn't necessarily mean it should be used that way.  Some of the most important tools in a good developer's toolkit are discretion and self-discipline.  Just don't let yourself write bad code.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.