Return to Answer

Yes, you can. You just have to supply a converter which converts between the string representation of the object type behind #{myBean.name} and the real object. The string representation is usually the unique technical/natural identifier of the object in question. For example, the table's PK. It has got to be a string, simply because HTTP request parameters can be strings only. You can't pass complex Java objects around in URLs. URLs are just strings.

Here's a kickoff example:

E.g. the following in the initial view:

<h:link value="Edit" outcome="edit"> <f:param name="id" value="#{personViewer.person.id}" /> </h:link> 

(which generates an <a href="edit.xhtml?id=123">Edit</a>)

and the following in the linked view:

<f:metadata> <f:viewParam name="id" value="#{personEditor.person}" converter="#{personConverter}" converterMessage="Bad request. Unknown person." required="true" requiredMessage="Bad request. Please use a link from within the system." /> </f:metadata> <h:messages /> 

with this converter

@ManagedBean @RequestScoped public class PersonConverter implements Converter { @EJB private PersonService personService; @Override public String getAsString(FacesContext context, UIComponent component, Object value) { return String.valueOf(((Person) value).getId()); } @Override public Object getAsObject(FacesContext context, UIComponent component, String value) { return personService.find(Long.valueOf(value)); } } 

(oversimplified; all null/number checks omitted, but you got the idea)

###See also:

• Communication in JSF 2.0 - Converting and validating GET request parameters

Update as per the comments, you actually want to fire a POST request. You don't need a <f:viewParam> at all. It's for setting/validating/converting GET request parameters only. Attempting to serialize the whole object makes also no utter sense. Just use @ManagedProperty.

E.g.

@ManagedBean @ViewScoped public class PersonEditor implements Serializable { @ManagedProperty("#{personViewer.person}") private Person person; // ... } 

It's only not bookmarkable anymore and not SEO-friendly (but that's the nature of POST, you're probably already for long aware of this). Note that the #{personViewer} bean must by itself also be @ViewScoped (and thus not @ReqestScoped). You also need to make sure that you don't navigate back with a redirect, but just a forward.

Yes, you can. You just have to supply a converter which converts between the string representation of the object type behind #{myBean.name} and the real object. The string representation is usually the unique technical/natural identifier of the object in question. For example, the table's PK. It has got to be a string, simply because HTTP request parameters can be strings only. You can't pass complex Java objects around in URLs. URLs are just strings.

Here's a kickoff example:

E.g. the following in the initial view:

<h:link value="Edit" outcome="edit"> <f:param name="id" value="#{personViewer.person.id}" /> </h:link> 

(which generates an <a href="edit.xhtml?id=123">Edit</a>)

and the following in the linked view:

<f:metadata> <f:viewParam name="id" value="#{personEditor.person}" converter="#{personConverter}" converterMessage="Bad request. Unknown person." required="true" requiredMessage="Bad request. Please use a link from within the system." /> </f:metadata> <h:messages /> 

with this converter

@ManagedBean @RequestScoped public class PersonConverter implements Converter { @EJB private PersonService personService; @Override public String getAsString(FacesContext context, UIComponent component, Object value) { return String.valueOf(((Person) value).getId()); } @Override public Object getAsObject(FacesContext context, UIComponent component, String value) { return personService.find(Long.valueOf(value)); } } 

(oversimplified; all null/number checks omitted, but you got the idea)

See also:

• Communication in JSF 2.0 - Converting and validating GET request parameters

Update as per the comments, you actually want to fire a POST request. You don't need a <f:viewParam> at all. It's for setting/validating/converting GET request parameters only. Attempting to serialize the whole object makes also no utter sense. Just use @ManagedProperty.

E.g.

@ManagedBean @ViewScoped public class PersonEditor implements Serializable { @ManagedProperty("#{personViewer.person}") private Person person; // ... } 

It's only not bookmarkable anymore and not SEO-friendly (but that's the nature of POST, you're probably already for long aware of this). Note that the #{personViewer} bean must by itself also be @ViewScoped (and thus not @ReqestScoped). You also need to make sure that you don't navigate back with a redirect, but just a forward.

Yes, you can. You just have to supply a converter which converts between the string representation of the object type behind #{myBean.name} and the real object. The string representation is usually the unique technical/natural identifier of the object in question. For example, the table's PK. It has got to be a string, simply because HTTP request parameters can be strings only. You can't pass complex Java objects around in URLs. URLs are just strings.

Here's a kickoff example:

E.g. the following in the initial view:

<h:link value="Edit" outcome="edit"> <f:param name="id" value="#{personViewer.person.id}" /> </h:link> 

(which generates an <a href="edit.xhtml?id=123">Edit</a>)

and the following in the linked view:

<f:metadata> <f:viewParam name="id" value="#{personEditor.person}" converter="#{personConverter}" converterMessage="Bad request. Unknown person." required="true" requiredMessage="Bad request. Please use a link from within the system." /> </f:metadata> <h:messages /> 

with this converter

@ManagedBean @RequestScoped public class PersonConverter implements Converter { @EJB private PersonService personService; @Override public String getAsString(FacesContext context, UIComponent component, Object value) { return String.valueOf(((Person) value).getId()); } @Override public Object getAsObject(FacesContext context, UIComponent component, String value) { return personService.find(Long.valueOf(value)); } } 

(oversimplified; all null/number checks omitted, but you got the idea)

###See also:

• Communication in JSF 2.0 - Converting and validating GET request parameters

Yes, you can. You just have to supply a converter which converts between the string representation of the object type behind #{myBean.name} and the real object. The string representation is usually the unique technical/natural identifier of the object in question. For example, the table's PK. It has got to be a string, simply because HTTP request parameters can be strings only. You can't pass complex Java objects around in URLs. URLs are just strings.

Here's a kickoff example:

E.g. the following in the initial view:

<h:link value="Edit" outcome="edit"> <f:param name="id" value="#{personViewer.person.id}" /> </h:link> 

(which generates an <a href="edit.xhtml?id=123">Edit</a>)

and the following in the linked view:

<f:metadata> <f:viewParam name="id" value="#{personEditor.person}" converter="#{personConverter}" converterMessage="Bad request. Unknown person." required="true" requiredMessage="Bad request. Please use a link from within the system." /> </f:metadata> <h:messages /> 

with this converter

@ManagedBean @RequestScoped public class PersonConverter implements Converter { @EJB private PersonService personService; @Override public String getAsString(FacesContext context, UIComponent component, Object value) { return String.valueOf(((Person) value).getId()); } @Override public Object getAsObject(FacesContext context, UIComponent component, String value) { return personService.find(Long.valueOf(value)); } } 

(oversimplified; all null/number checks omitted, but you got the idea)

###See also:

• Communication in JSF 2.0 - Converting and validating GET request parameters

Update as per the comments, you actually want to fire a POST request. You don't need a <f:viewParam> at all. It's for setting/validating/converting GET request parameters only. Attempting to serialize the whole object makes also no utter sense. Just use @ManagedProperty.

E.g.

@ManagedBean @ViewScoped public class PersonEditor implements Serializable { @ManagedProperty("#{personViewer.person}") private Person person; // ... } 

It's only not bookmarkable anymore and not SEO-friendly (but that's the nature of POST, you're probably already for long aware of this). Note that the #{personViewer} bean must by itself also be @ViewScoped (and thus not @ReqestScoped). You also need to make sure that you don't navigate back with a redirect, but just a forward.

Yes, you can. You just have to supply a converter which converts between the string representation of the object type behind #{myBean.name} and the real object. The string representation is usually the unique technical/natural identifier of the object in question. For example, the table's PK. It has got to be a string, simply because HTTP request parameters can be strings only. You can't pass complex Java objects around in URLs. URLs are just strings.

Here's a kickoff example:

E.g. the following in the first view:

<h:link value="Edit" outcome="edit"> <f:param name="id" value="#{viewBean.person.id}" /> </h:link> 

(which generates an <a href="edit.xhtml?id=123">Edit</a>)

and the following in the second view (the edit page):

<f:metadata> <f:viewParam name="id" value="#{editBean.person}" converter="#{personConverter}" converterMessage="Bad request. Unknown person." required="true" requiredMessage="Bad request. Please use a link from within the system." /> </f:metadata> <h:messages /> 

with this converter

@ManagedBean @RequestScoped public class PersonConverter implements Converter { @EJB private PersonService personService; @Override public String getAsString(FacesContext context, UIComponent component, Object value) { return String.valueOf(((Person) value).getId()); } @Override public Object getAsObject(FacesContext context, UIComponent component, String value) { return personService.find(Long.valueOf(value)); } } 

(oversimplified; all null/number checks omitted, but you got the idea)

###See also:

• Communication in JSF 2.0 - Converting and validating GET request parameters

Yes, you can. You just have to supply a converter which converts between the string representation of the object type behind #{myBean.name} and the real object. The string representation is usually the unique technical/natural identifier of the object in question. For example, the table's PK. It has got to be a string, simply because HTTP request parameters can be strings only. You can't pass complex Java objects around in URLs. URLs are just strings.

Here's a kickoff example:

E.g. the following in the initial view:

<h:link value="Edit" outcome="edit"> <f:param name="id" value="#{personViewer.person.id}" /> </h:link> 

(which generates an <a href="edit.xhtml?id=123">Edit</a>)

and the following in the linked view:

<f:metadata> <f:viewParam name="id" value="#{personEditor.person}" converter="#{personConverter}" converterMessage="Bad request. Unknown person." required="true" requiredMessage="Bad request. Please use a link from within the system." /> </f:metadata> <h:messages /> 

with this converter

@ManagedBean @RequestScoped public class PersonConverter implements Converter { @EJB private PersonService personService; @Override public String getAsString(FacesContext context, UIComponent component, Object value) { return String.valueOf(((Person) value).getId()); } @Override public Object getAsObject(FacesContext context, UIComponent component, String value) { return personService.find(Long.valueOf(value)); } } 

(oversimplified; all null/number checks omitted, but you got the idea)

###See also:

• Communication in JSF 2.0 - Converting and validating GET request parameters