Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.8.2-EE-GA_P01, 1.8.3
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      1.8.2-ee and ICEfaces trunk

      Description

      This issue was found in nightly regression test for ICE-5158:

      Test case works fine if not built with just-ice. if building the test case using: ant clean tomcat6.0 -Djust-ice="just-ice", it fails - as long as the validation message displays, it won't disappear even though re-clicking on the numbers in the calendar.

      Test app is available at repo\qa\trunk\Regression\ICE-5158

        Activity

        Joanne Bai created issue -
        Joanne Bai made changes -
        Field Original Value New Value
        Salesforce Case []
        Fix Version/s 1.8.2-EE-GA_P01 [ 10220 ]
        Fix Version/s 1.8.3 [ 10211 ]
        Affects Version/s 1.8.2-EE-GA [ 10216 ]
        Affects Version/s 1.8.2 [ 10190 ]
        Affects Version/s 1.8.2-EE-GA_P01 [ 10220 ]
        Affects Version/s 1.8.3 [ 10211 ]
        Joanne Bai made changes -
        Salesforce Case []
        Affects Version/s 1.8.2-EE-GA [ 10216 ]
        Affects Version/s 1.8.2 [ 10190 ]
        Ken Fyten made changes -
        Salesforce Case []
        Assignee Mark Collette [ mark.collette ]
        Ken Fyten made changes -
        Salesforce Case []
        Assignee Priority P1
        Hide
        Mark Collette added a comment -

        Note: Calendar uses immediate=true

        full

        Clicking on calendar dates does up to apply request values, then render response
        Typing 1 letter into input and bluring, does up to validations, then render
        Clicking on calendar, after 1 letter, does up to apply request values, then render response

        just-ice

        Clicking on calendar dates does all phases.
        Typing 1 letter into input and bluring, does up to validations, then render
        Clicking on calendar, after 1 letter, does up to validations, then render

        Show
        Mark Collette added a comment - Note: Calendar uses immediate=true full Clicking on calendar dates does up to apply request values, then render response Typing 1 letter into input and bluring, does up to validations, then render Clicking on calendar, after 1 letter, does up to apply request values, then render response just-ice Clicking on calendar dates does all phases. Typing 1 letter into input and bluring, does up to validations, then render Clicking on calendar, after 1 letter, does up to validations, then render
        Hide
        Joanne Bai added a comment -

        Not sure why, but the just-ice version works fine on tomcat 5 though. Build it using: ant clean tomcat5.x -Djust-ice="just-ice"

        Show
        Joanne Bai added a comment - Not sure why, but the just-ice version works fine on tomcat 5 though. Build it using: ant clean tomcat5.x -Djust-ice="just-ice"
        Hide
        Mark Collette added a comment -

        Ignoring the issue of the ice:inputText field and its validation, let's look at the ice:selectInputDate component itself.

        • With full ICEfaces, clicking on a calendar date will do up to Apply Request Values phase.
        • With just-ice.jar, clicking on a calendar date will do all phases.
        • With full, the ice:commandLink that the calendar internally uses for each calendar day, queues an ActionEvent, which causes the internal JSF code that invokes any actionListener or action to call FacesContext.renderResponse(). This is correct.
        • With just-ice.jar, no ActionEvent is queued, so FacesContext.renderResponse() is not called. This is incorrect.

        SelectInputDateRenderer creates the HtmlCommandLink child components, and marks them transient, so that next render it can make new ones. It does this because it actually does the decode for the link itself, and does not want the HtmlCommandLinks to do the decode themselves. But, SelectInputDate[Renderer] does not invokeFacesContext.renderResponse() itself when immediate=true. It is relying on the HtmlCommandLink to do that, even though it has marked it transient, to not exist, and not decode. This is incorrect.

        • With full, the transient components exist on decode. This is incorrect.
        • With just-ice.jar, the transient components do not exist on decode. This is correct.
        • With full, we set <state-manager>com.icesoft.faces.application.ViewRootStateManagerImpl</state-manager> in the faces-config.xml, which saves the whole component tree, which is why the transient components remain. This is non-standard.
        • With just-ice.jar, the default StateManager only state saves the non-transient components, effectively clearing them away. This is correct.

        The SingleCopyStateManagerImpl code appears to do the standard behaviour of only state saving non-transient components.

        So, I believe that the child HtmlCommandLink components should be created once, not marked transient, but not allowed to decode, and SelectInputDate[Renderer] should call FacesContext.renderResponse() if immediate == true.

        Aside from that, I believe that the core should use SingleCopyStateManagerImpl instead of ViewRootStateManagerImpl.

        Show
        Mark Collette added a comment - Ignoring the issue of the ice:inputText field and its validation, let's look at the ice:selectInputDate component itself. With full ICEfaces, clicking on a calendar date will do up to Apply Request Values phase. With just-ice.jar, clicking on a calendar date will do all phases. With full, the ice:commandLink that the calendar internally uses for each calendar day, queues an ActionEvent, which causes the internal JSF code that invokes any actionListener or action to call FacesContext.renderResponse(). This is correct. With just-ice.jar, no ActionEvent is queued, so FacesContext.renderResponse() is not called. This is incorrect. SelectInputDateRenderer creates the HtmlCommandLink child components, and marks them transient, so that next render it can make new ones. It does this because it actually does the decode for the link itself, and does not want the HtmlCommandLinks to do the decode themselves. But, SelectInputDate [Renderer] does not invokeFacesContext.renderResponse() itself when immediate=true. It is relying on the HtmlCommandLink to do that, even though it has marked it transient, to not exist, and not decode. This is incorrect. With full, the transient components exist on decode. This is incorrect. With just-ice.jar, the transient components do not exist on decode. This is correct. With full, we set <state-manager>com.icesoft.faces.application.ViewRootStateManagerImpl</state-manager> in the faces-config.xml, which saves the whole component tree, which is why the transient components remain. This is non-standard. With just-ice.jar, the default StateManager only state saves the non-transient components, effectively clearing them away. This is correct. The SingleCopyStateManagerImpl code appears to do the standard behaviour of only state saving non-transient components. So, I believe that the child HtmlCommandLink components should be created once, not marked transient, but not allowed to decode, and SelectInputDate [Renderer] should call FacesContext.renderResponse() if immediate == true. Aside from that, I believe that the core should use SingleCopyStateManagerImpl instead of ViewRootStateManagerImpl.
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #20968 Mon Mar 15 17:46:27 MDT 2010 mark.collette ICE-5384 : ICE-5158 built with just-ice
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/component/src/com/icesoft/faces/component/selectinputdate/SelectInputDateRenderer.java
        Hide
        Mark Collette added a comment -

        Further testing showed that the full ICEfaces version would do wither the full lifecycle, or just apply request values, depending on which links you clicked. So I brought it in line with UIInput standard behaviour, and just-ice behaviour, of doing all the phases, when immediate=true. This then fixed the regression as well.

        TRUNK
        Subversion 20968
        icefaces\component\src\com\icesoft\faces\component\selectinputdate\SelectInputDateRenderer.java

        icefaces-ee-1.8.2
        Subversion 20970
        icefaces\component\src\com\icesoft\faces\component\selectinputdate\SelectInputDateRenderer.java

        Show
        Mark Collette added a comment - Further testing showed that the full ICEfaces version would do wither the full lifecycle, or just apply request values, depending on which links you clicked. So I brought it in line with UIInput standard behaviour, and just-ice behaviour, of doing all the phases, when immediate=true. This then fixed the regression as well. TRUNK Subversion 20968 icefaces\component\src\com\icesoft\faces\component\selectinputdate\SelectInputDateRenderer.java icefaces-ee-1.8.2 Subversion 20970 icefaces\component\src\com\icesoft\faces\component\selectinputdate\SelectInputDateRenderer.java
        Mark Collette made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Joanne Bai added a comment -

        Verified successfully on ICEfaces-ee-1.8.2 revision 20970
        Verified on Tomcat 6 using FF3.5.8 and IE8

        Show
        Joanne Bai added a comment - Verified successfully on ICEfaces-ee-1.8.2 revision 20970 Verified on Tomcat 6 using FF3.5.8 and IE8
        Joanne Bai made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Mandeep Hayher added a comment -

        1)Type a letter in inputtext field & tabout
        2)validation error is displayed (as expected)
        3) now with validation error still on page, click on a date in calendar
        Should this work? or is this not expected to work till the inputtext validation error is corrected.

        Show
        Mandeep Hayher added a comment - 1)Type a letter in inputtext field & tabout 2)validation error is displayed (as expected) 3) now with validation error still on page, click on a date in calendar Should this work? or is this not expected to work till the inputtext validation error is corrected.
        Mandeep Hayher made changes -
        Resolution Fixed [ 1 ]
        Status Closed [ 6 ] Reopened [ 4 ]
        Hide
        Mark Collette added a comment -

        Worked with Mandeep to amend the test case.

        Show
        Mark Collette added a comment - Worked with Mandeep to amend the test case.
        Mark Collette made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Assignee Priority P1
        Assignee Mark Collette [ mark.collette ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Joanne Bai
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: