[JAVASERVERFACES_SPEC_PUBLIC-939] behavior issues with "INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL" setting Created: 31/Jan/11  Updated: 10/Feb/16  Resolved: 10/Feb/16

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Duplicate Votes: 6
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-3098 Regression in UIComponentBase#saveAtt... Closed
Status Whiteboard:

size_medium importance_medium


 Description   

currently - where INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is FALSE - we
have the following behavior:

Imaging two elements, bound to some managed bean (e.g in sessionScope)

<inputText id="one" />
<inputText id="two" required="true" />

Enter this:
one => FOO
two => BAR
HIT_ENTER (e.g submit the form)

now remove all the values
one =>
two =>
HIT_ENTER (e.g submit the form)

the rendered result is that BOTH fields are empty and there is an error-msg
for the required one.

Now when "INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL" is set to TRUE, we
have the following behavior
(same components used):

Enter this:
one => FOO
two => BAR
HIT_ENTER (e.g submit the form)

now remove all the values
one =>
two =>
HIT_ENTER (e.g submit the form)

the rendered result is that ONLY the required field is empty (and it has a
warning msg).
The other one - b/c submitted value is NULL is getting the real value, which has
been pushed into the bean before (=>FOO)

=> Is this really the intention ?

Do we really want to show the "original" data ? Today we don't, we just provided
the entered stuff/wrong_value (e.g nothing in this particular case)

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=mwessendorf%40java.net):

ah, ok.

basically the fix is this:

public Object getValue()
{
FacesContext fc = getFacesContext();
if (fc != null && fc.isValidationFailed())

{ return getStateHelper().get(PropertyKeys.value); }

else

{ return getStateHelper().eval(PropertyKeys.value); }

}

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=mwessendorf%40java.net):

IMO you shouldn't return something different from getValue because validation
failed!

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=rlubke):

It's returning the local value that would have been pushed to the model if
validation hadn't failed. That behavior seems correct based on the problem report.

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=gabfest):

let's say validation doesn't fail, but for some reason the developer calls
renderResponse in a valueChangeListener. Shouldn't the local value still get
shown when you rerender?
[ Show ยป ]
gabfest added a comment - 02/Dec/09 11:16 AM let's say validation doesn't fail, but for some reason the developer calls renderResponse in a valueChangeListener. Shouldn't the local value still get shown when you rerender?

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=rlubke):

Fair point.



 Comments   
Comment by vabp [ 15/May/12 ]

Can this please be addressed? It is significantly impact our in-production system.

Comment by balusc [ 11/Oct/12 ]

Issue 2262 is related http://java.net/jira/browse/JAVASERVERFACES-2262

Comment by dennishoersch [ 14/Jan/13 ]

Is there any decision made?

We're using the 'interpretion' of a submitted value as null, but the redisplay of the old value is a problem for us too.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by balusc [ 10/Feb/16 ]

Duplicates https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-671

Generated at Thu Apr 27 19:18:59 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.