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

UIOutput.getValue() should return the local value of the component if it has been set, even if null.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.2
    • Fix Version/s: 2.2
    • Component/s: Lifecycle
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      566
    • Status Whiteboard:
      Hide

      cat1 javadoc size_medium importance_medium

      Show
      cat1 javadoc size_medium importance_medium

      Description

      Consider:
      ---------------------------------------------
      for example:
      <h:form>
      <h:inputText id="input1" required="#

      {true}

      "/>
      <h:message for="input1"/>
      <h:inputText id="input2" value="#

      {testBean.value}

      ">
      <f:convertNumber integerOnly="true"/>
      </h:inputText>
      <h:message for="input2"/>
      <h:commandButton/>
      </h:form>

      public class TestBean {
      private String input1;
      private Integer input2 = 1;
      ...
      }

      from browser:
      1. Enter input1 empty text.
      2. Enter input2 empty text.
      3. submit.

      results:

      • A Required error for input1 is displayed.
      • The input2 text is "1".

      I hope:

      • A Required error for input1 is displayed.
      • The input2 text is empty text.

      ---------------------------------------------

        Issue Links

          Activity

          Hide
          Ed Burns added a comment -

          Move to unscheduled target milestone

          Show
          Ed Burns added a comment - Move to unscheduled target milestone
          Hide
          Ed Burns added a comment -

          Prepare to delete api subcomponent

          Show
          Ed Burns added a comment - Prepare to delete api subcomponent
          Hide
          Ed Burns added a comment -

          cat1

          Show
          Ed Burns added a comment - cat1
          Hide
          Ed Burns added a comment -

          javadoc

          Show
          Ed Burns added a comment - javadoc
          Hide
          Ed Burns added a comment -

          2.0 rev a

          Show
          Ed Burns added a comment - 2.0 rev a
          Hide
          Ed Burns added a comment -

          These are valid 2.0 Rev a issues

          Show
          Ed Burns added a comment - These are valid 2.0 Rev a issues
          Hide
          Ed Burns added a comment -

          move to P2

          Show
          Ed Burns added a comment - move to P2
          Hide
          Ed Burns added a comment -

          take ownership.

          Show
          Ed Burns added a comment - take ownership.
          Hide
          Ed Burns added a comment -

          may be a behavior change, moving to 2.1

          Show
          Ed Burns added a comment - may be a behavior change, moving to 2.1
          Hide
          Ed Burns added a comment -

          Change target milestone.

          Show
          Ed Burns added a comment - Change target milestone.
          Hide
          rogerk added a comment -

          triage

          Show
          rogerk added a comment - triage
          Hide
          rogerk added a comment -

          triage

          Show
          rogerk added a comment - triage
          Hide
          Ed Burns added a comment -

          While the change suggested by the venerable BalusC is alluringly simple,
          it causes problems right away in our existing automated tests. As a
          side note, my experience tells me that such a fundamental change is
          impossible to introduce at this stage in the evolution of JSF.
          Nonetheless, I'll continue to entertain it in an effort to demonstrate
          the impossibility of doing what the reports suggest.

          Consider this testcase:

          request.setAttribute("foo", "bar");
          test.setValue(null);
          assertNull(test.getValue());
          test.setValueBinding("value", application.createValueBinding("#

          {foo}

          "));
          assertNotNull(test.getValueBinding("value"));
          assertEquals("bar", test.getValue());

          In this code, "test" is an instance of UIInput. Because we have
          manually called setValue(), the local value of the component has been
          set. Therefore, the new code causes that value to be returned.
          However, the spec for getValue() says that, in the absence of a local
          value, the component's value expression must be consulted.

          The root cause of all of the trouble here is that when we added
          resetValue() to UIInput in JSF, way back in 2005, we should have pushed
          it up to UIOutput as well. In the interest of minimizing the impact of
          this change, we only put it on UIInput.

          I've taken the hit now, and with that additional change, and changing
          all occurrences of setValue(null) to be resetValue(), it seems the
          BalusC code works.

          I'm re-running the full test suite to make sure.

          Show
          Ed Burns added a comment - While the change suggested by the venerable BalusC is alluringly simple, it causes problems right away in our existing automated tests. As a side note, my experience tells me that such a fundamental change is impossible to introduce at this stage in the evolution of JSF. Nonetheless, I'll continue to entertain it in an effort to demonstrate the impossibility of doing what the reports suggest. Consider this testcase: request.setAttribute("foo", "bar"); test.setValue(null); assertNull(test.getValue()); test.setValueBinding("value", application.createValueBinding("# {foo} ")); assertNotNull(test.getValueBinding("value")); assertEquals("bar", test.getValue()); In this code, "test" is an instance of UIInput. Because we have manually called setValue(), the local value of the component has been set. Therefore, the new code causes that value to be returned. However, the spec for getValue() says that, in the absence of a local value, the component's value expression must be consulted. The root cause of all of the trouble here is that when we added resetValue() to UIInput in JSF, way back in 2005, we should have pushed it up to UIOutput as well. In the interest of minimizing the impact of this change, we only put it on UIInput. I've taken the hit now, and with that additional change, and changing all occurrences of setValue(null) to be resetValue(), it seems the BalusC code works. I'm re-running the full test suite to make sure.
          Show
          Ed Burns added a comment - - edited Close this when < http://hudson-sca.us.oracle.com/view/MOJARRA_ALL/job/MOJARRA_TRUNK_GLASSFISH_TRUNK_MINUS_ONE_NO_CLUSTER/587/ > and < http://tim-vm9.us.oracle.com:7070/hudson/view/Trunk/job/trunk-test-glassfish-3_1_2_2/27/ > are clean.
          Hide
          michael_kurz added a comment -

          Is this really in JSF 2.2 (as indicated by the resolved status)? I just tried an example with a required input like above and Mojarra 2.2.0 still gives me the value from the value expression if I try to submit a null value for the required field.

          Show
          michael_kurz added a comment - Is this really in JSF 2.2 (as indicated by the resolved status)? I just tried an example with a required input like above and Mojarra 2.2.0 still gives me the value from the value expression if I try to submit a null value for the required field.
          Hide
          michael_kurz added a comment -

          OK, forget it, it is another problem I stumbled upon.

          Show
          michael_kurz added a comment - OK, forget it, it is another problem I stumbled upon.
          Hide
          Manfred Riem added a comment -

          Closing resolved issue out

          Show
          Manfred Riem added a comment - Closing resolved issue out

            People

            • Assignee:
              Ed Burns
              Reporter:
              Ryan Lubke
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 6 hours, 31 minutes
                6h 31m