Joined: 31/Aug/2010 11:18:29
Thanks for bringing this to our attention, I believe this is the result of changes we've made to the distinction between 'passive' and 'active' selection using the table.
The table supports submitting selections and deselections passively, that is, storing them until submitted as part of an ajax request is initiated by another feature of the table, or during as part of communication initiated by another component in the view.
The alternative is active selection, which performs an ajax communication for every (de)selection. This was typically defined in beta 2 and prior with the 'update', 'rowSelectUpdate' and 'rowDeselectUpdate' properties which defined targets on the page to render during selection, and implied active selection.
However, active selection could also be implied by using a rowSelectListener as, of course, a server side listener requires a round trip. This has been missed in our new handling, which checks to see if there are any non-disabled ace:ajax tags applied to the component for the "select" event, and if so, enables 'active' selection, using the configuration of the ajax tag, or "select" event defaults.
To fix your issue in the short term, try adding Code:
as a child to the table. This should trigger default active selection behaviour.
<ace:ajax event="select" />
In the long term rowSelectListener will be patched to enable active selection, or the 'listener' available on the ace:ajax tag will be enhanced to provide event-specific information, like the rowSelectListener does currently. The ace:ajax listener, currently provides a generic AjaxBehaviourEvent to the listening method.
Hope that solves solve the issue for you and illuminates the behaviour of selection somewhat.