javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-939

behavior issues with "INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL" setting

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Components/Renderers
    • Labels:
      None
    • Status Whiteboard:
      Hide

      size_medium importance_medium

      Show
      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.

        Issue Links

          Activity

          Hide
          vabp added a comment -

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

          Show
          vabp added a comment - Can this please be addressed? It is significantly impact our in-production system.
          Hide
          balusc added a comment -
          Show
          balusc added a comment - Issue 2262 is related http://java.net/jira/browse/JAVASERVERFACES-2262
          Hide
          dennishoersch added a comment -

          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.

          Show
          dennishoersch added a comment - 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.
          Hide
          Ed Burns added a comment -

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

          Show
          Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
          Hide
          Manfred Riem added a comment -

          Setting priority to Major

          Show
          Manfred Riem added a comment - Setting priority to Major

            People

            • Assignee:
              Unassigned
              Reporter:
              rogerk
            • Votes:
              5 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated: