What is the difference between defining View Params like this:
<f:metadata>
<f:viewParam name="id" value="#{someBean.id}"/>
</f:metadata>
And defining the property in the ManagedBean like this:
@ManagedProperty(value = "#{param.id}")
private Integer id;
2 other differences:
@ManagedProperty
is usable only with beans managed by JSF, not with beans managed by CDI (@Named
);<f:viewParam>
works only with parameters of GET requests.<f:viewParam>
:Sets the value during update model values phase only (since it extends
UIInput
).The set value is not available during
@PostConstruct
, so you need an additional<f:event type="preRenderView" listener="#{bean.init}" />
inside the<f:metadata>
to do initialization/preloading based on the set values. Since JSF 2.2 you could use<f:viewAction>
for that instead.Allows for nested
<f:converter>
and<f:validator>
for more fine-grained conversion/validation. Even a<h:message>
can be attached.Can be included as GET query string using
includeViewParams
attribute of<h:link>
orincludeViewParams=true
request parameter in any URL.Can be used on a
@RequestScoped
bean, but it requires the bean to be@ViewScoped
if you want the view parameters to survive any validation failures caused by forms enclosed in the view, otherwise you need to manually retain all request parameters for the subsequent requests by<f:param>
in the command components.Example:
with
and an
@FacesConverter("userConverter")
. Invoking page by http://example.com/context/user.xhtml?id=123 will pass theid
parameter through the converter and set theUser
object as a bean property.@ManagedProperty
:Sets the value immediately after bean's construction.
Set value is available during
@PostConstruct
which allows easy initialization/preloading of other properties based on the set value.Doesn't allow for declarative conversion/validation in view.
Managed property of
#{param}
is not allowed on beans with a broader scope than request scope, so the bean is required to be@RequestScoped
.If you rely a managed property of
#{param}
being present in the subsequent POST requests, then you need to include it as<f:param>
in theUICommand
components.Example:
But you have to manage validation yourself whenever
user
isnull
by fiddling withFacesContext#addMessage()
or something.You can use them both when both
@PostConstruct
andincludeViewParams
are mandatory. You only won't be able to apply fine-grained conversion/validation anymore.See also: