ICEfaces
  1. ICEfaces
  2. ICE-9500

Make ice.ace.instance work with all lazy init components: checkboxEntry, dateTimeEntry, buttons, etc.

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0.BETA
    • Fix Version/s: 4.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ACE
    • Assignee Priority:
      P1

      Description

      With this task, the new ice.ace.instance function from ICE-8475, which will replace widgetVar, will allow for lazy initiated components to be automatically initiated by ice.ace.instance. The idea being that with something like popup panel, which is typically made visible via its widgetVar, it previously had to eagerly initialise so that the widgetVar would be available to make it visible. Now with this alternate means of getting the javascript object reference, we can detect that the object has not yet been initialised, and do so lazily only when ice.ace.instance is called.

      Our first step needs to be to take all the components that already use lazy initialise, and integrate that to work with ice.ace.instance, as the switch to lazy init had meant that one couldn't count on accessing their widgetVar.

        Issue Links

          Activity

          Hide
          Arturo Zambrano added a comment -

          Committed new feature at revision 38540. Modified core.js to initialize lazy init components when calling ice.ace.instance so an object reference can be obtained for lazy init components as well.

          The way this was made was by adding a global object ice.ace.lazy.registry to register all lazy init components on the page. They keys of this object are client ids, and the values are functions that call ice.ace.lazy(). So, when calling ice.ace.instance, the registry is checked to see if there's a registered lazy init component. In such case, the component is initialized before returning the object reference. The component is removed from the registry as well.

          The only components using ice.ace.lazy at the moment are ace:checkboxButton, ace:linkButton, ace:pushButton, and ace:tableconfigPanel. The first three were adjusted to this change. As for ace:tableconfigPanel, it doesn't expose a client API, so no adjustment was made in this case.

          Other components that could now be made lazy init include the following:

          • ace:dialog
          • ace:confirmationDialog
          • ace:notificationPanel
          • ace:dateTimeEntry
          Show
          Arturo Zambrano added a comment - Committed new feature at revision 38540. Modified core.js to initialize lazy init components when calling ice.ace.instance so an object reference can be obtained for lazy init components as well. The way this was made was by adding a global object ice.ace.lazy.registry to register all lazy init components on the page. They keys of this object are client ids, and the values are functions that call ice.ace.lazy(). So, when calling ice.ace.instance, the registry is checked to see if there's a registered lazy init component. In such case, the component is initialized before returning the object reference. The component is removed from the registry as well. The only components using ice.ace.lazy at the moment are ace:checkboxButton, ace:linkButton, ace:pushButton, and ace:tableconfigPanel. The first three were adjusted to this change. As for ace:tableconfigPanel, it doesn't expose a client API, so no adjustment was made in this case. Other components that could now be made lazy init include the following: ace:dialog ace:confirmationDialog ace:notificationPanel ace:dateTimeEntry
          Hide
          Ken Fyten added a comment -

          We should prioritize components that are likely to be used in large UIData/dataTables, such as ace:textEntry, ace:*Entry in general.

          Show
          Ken Fyten added a comment - We should prioritize components that are likely to be used in large UIData/dataTables, such as ace:textEntry, ace:*Entry in general.
          Hide
          Arturo Zambrano added a comment - - edited

          revision 38575:
          Modified ace:textEntry and ace:textAreaEntry to use ice.ace.lazy.

          I found out that widgetVar can still be used in conjunction with ice.ace.lazy. The only difference is that the variable won't be available until after the component is initialized (lazily) or after invoking ice.ace.instance.

          Show
          Arturo Zambrano added a comment - - edited revision 38575: Modified ace:textEntry and ace:textAreaEntry to use ice.ace.lazy. I found out that widgetVar can still be used in conjunction with ice.ace.lazy. The only difference is that the variable won't be available until after the component is initialized (lazily) or after invoking ice.ace.instance.
          Hide
          Ken Fyten added a comment -

          Re-target 4.0 final to complete the following remaining components that use widgetvar for actual client APIs:

          • ace:dialog
          • ace:confirmationDialog
          • ace:notificationPanel
          • ace:dateTimeEntry
          Show
          Ken Fyten added a comment - Re-target 4.0 final to complete the following remaining components that use widgetvar for actual client APIs: ace:dialog ace:confirmationDialog ace:notificationPanel ace:dateTimeEntry
          Hide
          Arturo Zambrano added a comment -

          Committed improvement at revision 41507. Modified the lazy init strategy to cover cases where the component is modified dynamically and when the node to which the jquery plugin is applied to isn't the root node. These cases weren't initially contemplated, but now they are supported. Also, modified ace:dialog to be lazily initialized.

          Show
          Arturo Zambrano added a comment - Committed improvement at revision 41507. Modified the lazy init strategy to cover cases where the component is modified dynamically and when the node to which the jquery plugin is applied to isn't the root node. These cases weren't initially contemplated, but now they are supported. Also, modified ace:dialog to be lazily initialized.
          Hide
          Arturo Zambrano added a comment -

          Modified ace:confirmDialog to be lazily initialized, at revision 41508.

          Show
          Arturo Zambrano added a comment - Modified ace:confirmDialog to be lazily initialized, at revision 41508.
          Hide
          Arturo Zambrano added a comment -

          r41511: committed various fixes to increase robustness; fixed issues with ace:dialog; adjusted ace:dateTimeEntry to work well with recent modifications to lazy init strategy.

          ace:dateTimeEntry was already making use of ice.ace.lazy(), as part of a more complex lazy init approach. However, it was necessary to make a slight adjustment to make it work with recent modifications to our general lazy init strategy.

          ace:notificationPanel won't be modified to use lazy init, since it's not necessary. The component doesn't make use of a jquery plugin or any other underlying widget. The init function simply sets some CSS properties. Therefore, in terms of memory, there's virtually no difference. Moreover, since the notification panel can also be hidden and made visible via the server, it's required to be already initialized from the moment it's loaded on the page.

          Show
          Arturo Zambrano added a comment - r41511: committed various fixes to increase robustness; fixed issues with ace:dialog; adjusted ace:dateTimeEntry to work well with recent modifications to lazy init strategy. ace:dateTimeEntry was already making use of ice.ace.lazy(), as part of a more complex lazy init approach. However, it was necessary to make a slight adjustment to make it work with recent modifications to our general lazy init strategy. ace:notificationPanel won't be modified to use lazy init, since it's not necessary. The component doesn't make use of a jquery plugin or any other underlying widget. The init function simply sets some CSS properties. Therefore, in terms of memory, there's virtually no difference. Moreover, since the notification panel can also be hidden and made visible via the server, it's required to be already initialized from the moment it's loaded on the page.
          Hide
          Arturo Zambrano added a comment -

          r41512: modified demos to use ice.ace.instance() instead of widgetvar.

          Show
          Arturo Zambrano added a comment - r41512: modified demos to use ice.ace.instance() instead of widgetvar.
          Hide
          Arturo Zambrano added a comment -

          r41513: fixed issue with ace:confirmationDialog being visible when loading the page.

          Show
          Arturo Zambrano added a comment - r41513: fixed issue with ace:confirmationDialog being visible when loading the page.
          Hide
          Carmen Cristurean added a comment -

          Re-opening because there are QA tests failing for ace:dialog:
          http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dialog

          1) Opening the ace:dialog fails if using an h:commandButton with type=submit via an actionListener.
          This is not an issue if using the libraries from Jenkins IF4 trunk Build# 440 (rev. 41501).
          Test page: /dialogSetFocus1.jsf
          Steps: on this test page click on the bottom "Show" button for the corresponding test. The dialog fails to open.

          2) Dialog in ace:tabSet fails to render on page load.
          No issues on IF4 trunk rev. 41501.
          Test page: /dialogSparkleTabset.jsf

          Show
          Carmen Cristurean added a comment - Re-opening because there are QA tests failing for ace:dialog: http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dialog 1) Opening the ace:dialog fails if using an h:commandButton with type=submit via an actionListener. This is not an issue if using the libraries from Jenkins IF4 trunk Build# 440 (rev. 41501). Test page: /dialogSetFocus1.jsf Steps: on this test page click on the bottom "Show" button for the corresponding test. The dialog fails to open. 2) Dialog in ace:tabSet fails to render on page load. No issues on IF4 trunk rev. 41501. Test page: /dialogSparkleTabset.jsf
          Hide
          Arturo Zambrano added a comment -

          r41525: Committed fix to show dialog when visible=true.

          Since ace:dialog is not lazily initialized, it was necessary to add a call to the show() function when visible=true, so that the component gets initialized right away and displayed. This fixes both issues above.

          Show
          Arturo Zambrano added a comment - r41525: Committed fix to show dialog when visible=true. Since ace:dialog is not lazily initialized, it was necessary to add a call to the show() function when visible=true, so that the component gets initialized right away and displayed. This fixes both issues above.
          Hide
          Carmen Cristurean added a comment - - edited

          Issue 1) is partially resolved only, as the ace:dialog opens up now however the inputText is missing the focus (Chrome35/ rev.41525).

          Issue 2) is resolved.

          Show
          Carmen Cristurean added a comment - - edited Issue 1) is partially resolved only, as the ace:dialog opens up now however the inputText is missing the focus (Chrome35/ rev.41525). Issue 2) is resolved.
          Hide
          Arturo Zambrano added a comment -

          r41527: wrapped input focus function inside a timeout function, in order to allow the child components to be loaded first before applying focus to them.

          This fixes issue #1 above.

          Show
          Arturo Zambrano added a comment - r41527: wrapped input focus function inside a timeout function, in order to allow the child components to be loaded first before applying focus to them. This fixes issue #1 above.
          Hide
          Carmen Cristurean added a comment -

          Re-opening this JIRA because of the following regressions in showcase (Icefaces 4 trunk rev. 41557/all browsers):

          messages/ textEntry/ textAreaEntry (all browsers)
          > All: demos are not functional: messages are not rendered when tabbing through without text being entered; when tabbing through after typing text, the focus jumps back to the input entry at the end of the typed text (no errors seen).
          Steps:

          • type at least one character in one of the inputs.
          • press Tab - > focus is initially visible on the next input entry, but it goes back to the first input entry, at the end of the typed text.
          Show
          Carmen Cristurean added a comment - Re-opening this JIRA because of the following regressions in showcase (Icefaces 4 trunk rev. 41557/all browsers): messages/ textEntry/ textAreaEntry (all browsers) > All: demos are not functional: messages are not rendered when tabbing through without text being entered; when tabbing through after typing text, the focus jumps back to the input entry at the end of the typed text (no errors seen). Steps: type at least one character in one of the inputs. press Tab - > focus is initially visible on the next input entry, but it goes back to the first input entry, at the end of the typed text.
          Hide
          Arturo Zambrano added a comment -

          The last issues reported are not caused by this fix. They became visible after the changes made for ICE-10100. More information can be found on that JIRA.

          Show
          Arturo Zambrano added a comment - The last issues reported are not caused by this fix. They became visible after the changes made for ICE-10100 . More information can be found on that JIRA.

            People

            • Assignee:
              Arturo Zambrano
              Reporter:
              Mark Collette
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: