posted 14 years ago
"Selected" doesn't mean what you think it does. In JSF terms, the "selected" row of a datamodel is the one corresponding to a commandLink or a commandButton that was clicked. You can have zero or many checkboxes in a datatable, so how would the framework know which one was the "selection" checkbox?
JSF is based on MVC and part of that basis means that the code to update the model is in the Controller and doesn't need to be written by you. In the case of the DataTable, the controller is the DataTable element itself.
If you create a DataTable with writable row elements - such as a ListDataModel provides - the rows would be mapped to the GUI. So normally, you'd define row classes such that there'd be a property to back the checkbox value and one to back the selection value. JSF itself would ensure that the values were set properly, automatically.
Which brings up a point. A lot of people think that JSF is supposed to be directly mapping to their persistence datamodels. While it can, very often it should not. The backing beans are actually GUI datamodels, so when you do that, you're overloading 2 functional roles onto one object. In cases where you don't want the persistent datamodel to be directly updated from the GUI (for example, only update checked selections), and for cases where the persistent object doesn't translate well to the GUI (database ORM objects often don't handle booleans well), it's more appropriate to keep the GUI and persistence model objects separate and insert a business layer to translate between them. The business layer is normally invoked by the backing bean's action processor.
Often the most important part of the news is what they didn't tell.