<o:viewParamValidationFailed>
allows the developer to handle a view parameter validation failure
with either a redirect or a HTTP error status, optionally with respectively a flash message or HTTP error message.
This tag can be placed inside <f:metadata>
or <f|o:viewParam>
. When placed in
<f|o:viewParam>
, then it will be applied when the particular view parameter has a validation
error as per UIViewParameter#isValid()
. When placed in <f:metadata>
, and no one view
parameter has already handled the validation error via its own <o:viewParamValidationFailed>
,
then it will be applied when there's a general validation error as per FacesContext#isValidationFailed()
.
The sendRedirect
attribute uses under the covers Faces#redirect(String, String...)
to send the
redirect, so the same rules as to scheme and leading slash apply here.
The sendError
attribute uses under the covers Faces#responseSendError(int, String)
to send the
error, so you can customize HTTP error pages via <error-page>
entries in web.xml
,
otherwise the server-default one will be displayed instead.
*
As a precaution, the <f:viewParam required="true">
has in current Mojarra and MyFaces releases
(as of now, Mojarra 2.2.7 and MyFaces 2.2.4) a design error. When the parameter is not specified in the query string,
then it is retrieved as null
which causes that an internal isRequired()
check is performed
instead of delegating the check to standard UIInput
implementation. This has the consequence that
PreValidateEvent
and PostValidateEvent
listeners are never invoked, which the
<o:viewParamValidationFailed>
is actually relying on. This is fixed in
<o:viewParam
.
*
With the example below, when at least one view param is absent, then the client will be returned a HTTP 400 error.
<f:metadata> <o:viewParam name="foo" required="true" /> <o:viewParam name="bar" required="true" /> <o:viewParamValidationFailed sendError="400" /> </f:metadata>
With the example below, only when the "foo" parameter is absent, then the client will be redirected to "login.xhtml". When the "bar" parameter is absent, nothing new will happen. The process will proceed "as usual". I.e. the validation error will end up as a faces message in the current view the usual way.
<f:metadata> <o:viewParam name="foo" required="true"> <o:viewParamValidationFailed sendRedirect="login.xhtml" /> </o:viewParam> <o:viewParam name="bar" required="true" /> </f:metadata>
With the example below, only when the "foo" parameter is absent, regardless of the "bar" or "baz" parameters, then the client will be returned a HTTP 401 error. When the "foo" parameter is present, but either "bar" or "baz" parameter is absent, then the client will be redirected to "search.xhtml".
<f:metadata> <o:viewParam name="foo" required="true"> <o:viewParamValidationFailed sendError="401" /> </o:viewParam> <o:viewParam name="bar" required="true" /> <o:viewParam name="baz" required="true" /> <o:viewParamValidationFailed sendRedirect="search.xhtml" /> </f:metadata>
In a nutshell: when there are multiple <o:viewParamValidationFailed>
tags, then they will be
applied in the same order as they are declared in the view. So, with the example above, the one nested in
<f|o:viewParam>
takes precedence over the one nested in <f:metadata>
.
*
By default, the first occurring faces message on the parent component will be copied, or when there is none, then
the first occurring global faces message will be copied. When sendRedirect
is used, then it will be set
as a global flash error message. When sendError
is used, then it will be set as HTTP status message.
You can override this message by explicitly specifying the message
attribute. This is applicable on
both sendRedirect
and sendError
.
<o:viewParamValidationFailed sendRedirect="search.xhtml" message="You need to perform a search." /> ... <o:viewParamValidationFailed sendError="401" message="Authentication failed. You need to login." />*
You can technically nest multiple <o:viewParamValidationFailed>
inside the same parent, but this
is not the documented approach and the behavior is unspecified.
You can not change the HTTP status code of a redirect. This is not a JSF limitation, but a HTTP
limitation. The status code of a redirect will always end up the one of the redirected response.
If you intend to "redirect" with a different HTTP status code, then you should be using sendError
instead and specify the desired page as <error-page>
in web.xml
.
Name | Required | Type | Description |
---|---|---|---|
message | false | jakarta.el.ValueExpression
(must evaluate to java.lang.String )
| The message to send along with the redirect or error. If this attribute is not specified, then by default the validation error message will be used. |
sendError | false | jakarta.el.ValueExpression
(must evaluate to java.lang.Integer )
|
The HTTP status to send error with on validation failure.
This attribute cannot be specified when the sendRedirect is already specified.
|
sendRedirect | false | jakarta.el.ValueExpression
(must evaluate to java.lang.String )
|
The URL to send redirect to on validation failure.
The same rules apply as with Faces#redirect().
This attribute is required when the sendError attribute is absent.
|
Output generated by Vdldoc View Declaration Language Documentation Generator.