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

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

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.

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

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.

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

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.

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

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

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

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.

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.

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.

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.

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.