I have encountered this issue myself in 1.7.1. The ascending property in the backing bean gets set during the invoke application phase AFTER the action listener. This should definitely be happening during the update model values phase.

Furthermore, it seems to not set the bound sort column of the backing bean at all. I can see it getting the value, but not setting it. I was forced to get the value from the compenent class directly.

Also, the initial page load is not reading the sort column value from the backing bean. It is fine on post back, but not the initial render. I was forced to do this by manually instanciating a new HtmlDataTable to the bound property, and setting the sort column directly on the class in @PostConstruct in the backing bean. I guess this could also be done in the before render response phase, but this should be read automatically from the instanciated backing bean, should it not?

Voted.

Kurzweil4

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