ICEfaces
  1. ICEfaces
  2. ICE-8562

ace:DateTimeEntry rendering issues with a POST redirect

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 3.1
          • Fix Version/s: EE-3.2.0.BETA, EE-3.2.0.GA, 3.3
          • Component/s: ACE-Components
          • Labels:
            None
          • Environment:
            ICEfaces 3.1, Chrome, Firefox, IE
          • Assignee Priority:
            P1

            Description

            It appears that the ace:DateTimeEntry component does not render when a page is navigated to via an internal navigation. (POST redirect)

            Source code attached.

            To reproduce:
            1. Deploy and access sample application default page.
            2. From the main page:
                2.1. Click link Navigate Externally to Tabs Wrapper (via html link) --> Selecting the date component in the tabSet works, and the date select pannel is enabled
                2.2. Click button Navigate internally to date component (via command button post redirect) --> When landing on the page selecting the date component no selection pannel is rendered

              Activity

              Descending order - Click to sort in ascending order
              Hide
              Permalink
              yip.ng added a comment - - edited

              ICE-8970, ICE-9455.

              Show
              yip.ng added a comment - - edited ICE-8970 , ICE-9455 .
              Hide
              Permalink
              yip.ng added a comment -

              Another similar case: http://jforum.icesoft.org/JForum/posts/list/15/21571.page#76150.

              Show
              yip.ng added a comment - Another similar case: http://jforum.icesoft.org/JForum/posts/list/15/21571.page#76150 .
              Hide
              Permalink
              yip.ng added a comment - - edited

              Tested wrapping group panel with common id as mentioned by Mark. Working.

              Show
              yip.ng added a comment - - edited Tested wrapping group panel with common id as mentioned by Mark. Working.
              Hide
              Permalink
              yip.ng added a comment - - edited

              After much tracing and debugging, found that there is nothing wrong with the component.
              This is yet another case of the same old issue of the framework DOM updates messing up the client-side states.
              The popup is created dynamically on the client side. (It is a div attached to the body.) Seems the popup is shared among calendar instances. The calendar instances and the shared popup are managed by a singleton manager. In this scenario the framework just comes along and wipe out the whole body, without the manager knowing.
              This can't just be solved like before using a hash code to force DOM diff. to update properly. You need to tell the manager you are wiping out HTML under its control. Even then there may not be an easy fix. Seems the manager works by assuming that the popup is created/initialized only once per jquery-ui.js load, i.e. the framework needs to reload jquery-ui.js or at least the datepicker portion of the jquery-ui.js.
              Tried hardcoding to force manager to re-create the popup for the second calendar instance in this scenario and it seemed to work. See video http://screencast.com/t/K0M6bqnF. Need to find a way to make this work without creating a host of other problems in this or other scenarios.

              Show
              yip.ng added a comment - - edited After much tracing and debugging, found that there is nothing wrong with the component. This is yet another case of the same old issue of the framework DOM updates messing up the client-side states. The popup is created dynamically on the client side. (It is a div attached to the body.) Seems the popup is shared among calendar instances. The calendar instances and the shared popup are managed by a singleton manager. In this scenario the framework just comes along and wipe out the whole body, without the manager knowing. This can't just be solved like before using a hash code to force DOM diff. to update properly. You need to tell the manager you are wiping out HTML under its control. Even then there may not be an easy fix. Seems the manager works by assuming that the popup is created/initialized only once per jquery-ui.js load, i.e. the framework needs to reload jquery-ui.js or at least the datepicker portion of the jquery-ui.js. Tried hardcoding to force manager to re-create the popup for the second calendar instance in this scenario and it seemed to work. See video http://screencast.com/t/K0M6bqnF . Need to find a way to make this work without creating a host of other problems in this or other scenarios.
              Hide
              Permalink
              Evgheni Sadovoi added a comment - - edited

              Assigning to Yip for further review. The bug is critical for our customer.
              (Restricted to icesoft-internal-developers group)

              Show
              Evgheni Sadovoi added a comment - - edited Assigning to Yip for further review. The bug is critical for our customer. (Restricted to icesoft-internal-developers group)
              4 older comments

                People

                • Assignee:
                  yip.ng
                  Reporter:
                  Evgheni Sadovoi
                • Votes:
                  5 Vote for this issue
                  Watchers:
                  7 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: