Steps to reproduce with attached test case:

• App loads with two rows in the parent table.
• Expand the first row, a Child table is shown with three rows/two columns.
• The second column contains a commandLink, clicking it calls the action method which outputs a log in the server console.
• Expand the first row of the child table, a Sub Child Table is shown which has a similar structure.
• Clicking on the link in the second column of the Sub Child Table also calls the action method.
• Above steps work since this was done on the first parent table row.
• To see the issue repeat the steps above but with the second row of the Parent Table. Clicking on the links in the Child Table work, but not for the Sub Child Table.

If the first parent row is expanded, then things work properly. If it is not expanded, then the child table expansions can unexpand when clicking on the links within them, and the commandLink actionListener won't fire.

This was found to work on trunk, most likely fixed by 26898. We should confirm that it's alright in 3.0.0.RC2.

The original steps to reproduce the issue look to be fixes but now there is a new issue. If the first row is expanded then clicking on the link in the second row does not work. This looks to be an issue even with the latest ICEfaces 3 trunk.

Steps to reproduce current issue:

• Expand the first rows expansion.
• Expand the second rows expansion and also the nested tables first row to show the Sub Child table.
• Click on the sub Childs table links. No action is called.
• If the first row is contracted then the link works correctly.

Steps mentioned in my previous comment are still seen with a recent trunk build.

This issue stems from an error with our expansion state- the calls to getStateMap() during decoding for the child tables always return the state map of the 1st child table.

This may be due to caching within getStateMap or issues with our state saving itself.

Fixed issue by removing component-level stateMap caching, however the additional reloading of the data model required to now obtain the correct stateMap, increases an already noticeable slowdown in my test case.

The only foreseeable fix at the moment would be a sizeable refactoring to implement a DataTableContext object that would ferry the StateMap and other common objects, reducing the amount that they are loaded from the state. Even then this would not be applicable for some instances where StateMap is handled - like in setRowIndex.

Revision #30029
Committed by nils.lundquist
A minute ago
ICE-7624 - Resolved decoding state sharing issue by removing component-level cached RowStateMap.

Revision #30030
Committed by nils.lundquist
Moments ago
ICE-7624 - Re-adding component-level RowStateMap caching to prevent performance implications. Will eventually pursue implementing DataTableContext to increase state loading efficacy while removing caching to resolve ICE-7624.

Revision #30383
Committed by nils.lundquist
39 minutes ago
ICE-7624 - Refactored DataTable rendering to use a helper object to hold state preventing issues with indexed client ids.