Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.7RC1, 1.8.1, 2.0.0
-
Fix Version/s: 2.0.1
-
Component/s: ICE-Components
-
Labels:None
-
Environment:All
-
ICEsoft Forum Reference:
Description
Upon examination of com.icesoft.faces.component.commandsortheader.CommandSortHeader.broadcast(-), it appears that HtmlDataTable.setSortColumn(-) and HtmlDataTable.setSortAscending(-) are not being called in the right phase, and are also being called after the commandSortHeader's actionListener.
We should decide if we want to follow the typical EditableValueHolder paradigm for HtmlDataTable's sortColumn and sortAscending properties, and make them UpdatableProperties that CommandSortHeader sets on decode ( queueEvent(-) ), or if we want to follow the UICommand paradigm for CommandSortHeader, and have it use the immediate property, which would necessitate setting HtmlDataTable's sortColumn and sortAscending properties immediately before the ActionEvent is broadcast.
We should decide if we want to follow the typical EditableValueHolder paradigm for HtmlDataTable's sortColumn and sortAscending properties, and make them UpdatableProperties that CommandSortHeader sets on decode ( queueEvent(-) ), or if we want to follow the UICommand paradigm for CommandSortHeader, and have it use the immediate property, which would necessitate setting HtmlDataTable's sortColumn and sortAscending properties immediately before the ActionEvent is broadcast.
I ended up not switching the columnName and columnAscending values to be set during UpdateModel, as that opens up the issue of still setting them before the commandSortHeader if it acquires an immediate property. The main thing is for them to be set before the actionListener is called, which is now fixed. As well, I removed some redundant property re-gets an sets. We were getting the commandSortHeader's column name 3x, and then setting the dataTable's column name in the case where we know it's already that value.
I updated the component-showcase to strip out all the excess logic that was there to work around this bug. But the work-around was so well thought out, that fixing the bug didn't actually necessitate removing the work-around. It just simplified the code.
Component changes
Subversion 24001
component-showcase changes
Subversion 24002