In both MyFaces and Mojarra 2.1, there exists a defect where when javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
is set to true
, any fields that are marked as required and pre-populated in the model, when blanked-out and submitted are re-shown with their original non-blanked-out values instead of being left blank.
Scenario is:
The issue is that the field, which should show what the user submitted -- which is that they submitted a blank value for the field -- is instead populated with the original value from the model. The only workaround is to set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
to false
. Setting to false
delivers the desired behavior that the field remains blanked out when the page is redisplayed with the required field error message.
A defect was logged with Mojarra (http://java.net/jira/browse/JAVASERVERFACES-2375) and MyFaces (https://issues.apache.org/jira/browse/MYFACES-3525) but no progress has been made in 6 weeks.
Note that it appears Mojarra had a similar issue reported over 6 mos ago yet no progress has been made.
Does anyone know of a workaround for this where we can keep javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
set to true instead of false and yet not encounter this required field usability issue?
This problem is explained in detail in JSF 2 - Bean Validation: validation failed -> empty values are replaced with last valid values from managed bean. To the point, in Mojarra it's caused by a bug or at least an oversight in HtmlBasicRenderer#getCurrentValue()
and has been reported as issue 2266.
In the meanwhile, the easiest way to workaround this, while taking 3rd party component libraries with their own renderers like PrimeFaces into account, is to copy the source file of UIInput
straight in your project's source folder and then edit the getSubmittedValue()
accordingly:
public Object getSubmittedValue() {
if (submittedValue == null && !isValid() && considerEmptyStringNull(FacesContext.getCurrentInstance())) {
return "";
}
else {
return submittedValue;
}
}
It'll end up in /WEB-INF/classes
and this will get precedence in classloading above the one in the JSF JAR file. Admittedly, it's somewhat clumsy, but it's less painful than rebuilding the JSF JAR file or overriding every single input renderer.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With