ICEfaces
  1. ICEfaces
  2. ICE-6896

Null-value not updated in rendered view

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: EE-2.0.0.GA
          • Fix Version/s: 2.1-Beta, 3.0, EE-2.0.0.GA_P01
          • Component/s: None
          • Labels:
            None
          • Environment:
            Mojarra 2.1.1-b04
          • Assignee Priority:
            P2
          • Affects:
            Compatibility/Configuration
          • Workaround Exists:
            Yes
          • Workaround Description:
            I the value is set to an empty string the result is as expected. But that's no real option for us as we are already using nulls everywhere.

            Description

            Given this form:

            <h:form id="myForm">
            <h:inputText id="myInput" value="#{myBean.myValue}"/>

            <h:commandButton id="submitButton" action="#{myBean.submit}" value="Submit"/>
            </h:form>

            and this action mehod:

            public String submit() {
              myValue = null;

            return null;
            }

            the user expects the textfield to be empty after the request finished.

            This works with plain Mojarra (org.icefaces.render.auto = false) but not with ICEfaces.

            I think the problem is that TextRenderer.getEndTextToRender() doesn't call the ResponseWriter if the value is null.

              Activity

              Ascending order - Click to sort in descending order
              Hide
              Permalink
              Adrian Gygax added a comment -

              Attached an Eclipse 3.6 project with a sample application.

              To reproduce the bug:

              Open http://localhost:8080/icefacesSupport/
              Enter any text into the textfield
              Press the button
              -> The text is still there

              In web.xml switch org.icefaces.render.auto to "false" and do the same again
              -> The textbox is empty

              Show
              Adrian Gygax added a comment - Attached an Eclipse 3.6 project with a sample application. To reproduce the bug: Open http://localhost:8080/icefacesSupport/ Enter any text into the textfield Press the button -> The text is still there In web.xml switch org.icefaces.render.auto to "false" and do the same again -> The textbox is empty
              Hide
              Permalink
              Mark Collette added a comment -

              When the user submits the form, DomPartialViewContext.applyBrowserChanges should be updating the old DOM to contain the submitted text, so that the DOM difference will see the submitted value in the old DOM, and the cleared value in the new DOM, and then tell the browser about the new cleared state. But there's some special logic in applyBrowserChanges that's keeping the old DOM from being updated.

              if ("".equals(value))

              { inputElement.setAttribute("value", ""); }

              else {
              if (inputElement.hasAttribute("value"))

              { // <== Problem is here inputElement.setAttribute("value", value); }

              else if (inputElement.getAttribute("type").equals("checkbox"))

              { inputElement.setAttribute("checked", "checked"); }

              }

              When the inputText was first rendered, it had no text value, so no value attribute was rendered. So when the user submitted a value, this code kept the value from being updated. The hasAttribute("value") check is from ICE-2727. It looks like it was an optimisation for ice:commandButton. When I tested with the hasAttribute("value") removed, the DOM difference worked properly, and the page updated as expected. Added an ice:commandButton to the form to be sure that it was not being updated, to ensure ICE-2727 was still being covered.

              Show
              Mark Collette added a comment - When the user submits the form, DomPartialViewContext.applyBrowserChanges should be updating the old DOM to contain the submitted text, so that the DOM difference will see the submitted value in the old DOM, and the cleared value in the new DOM, and then tell the browser about the new cleared state. But there's some special logic in applyBrowserChanges that's keeping the old DOM from being updated. if ("".equals(value)) { inputElement.setAttribute("value", ""); } else { if (inputElement.hasAttribute("value")) { // <== Problem is here inputElement.setAttribute("value", value); } else if (inputElement.getAttribute("type").equals("checkbox")) { inputElement.setAttribute("checked", "checked"); } } When the inputText was first rendered, it had no text value, so no value attribute was rendered. So when the user submitted a value, this code kept the value from being updated. The hasAttribute("value") check is from ICE-2727 . It looks like it was an optimisation for ice:commandButton. When I tested with the hasAttribute("value") removed, the DOM difference worked properly, and the page updated as expected. Added an ice:commandButton to the form to be sure that it was not being updated, to ensure ICE-2727 was still being covered.
              Hide
              Permalink
              Mark Collette added a comment -

              trunk
              Subversion 24899

              icefaces2/branches/icefaces-2.0.x-maintenance/icefaces
              Subversion 24900

              Show
              Mark Collette added a comment - trunk Subversion 24899 icefaces2/branches/icefaces-2.0.x-maintenance/icefaces Subversion 24900

                People

                • Assignee:
                  Mark Collette
                  Reporter:
                  Adrian Gygax
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: