In ICE-2186 we removed the call to FacesContext.renderResponse() from the RowSelector's decode method. The idea being that developers would put it into their rowSelector's selectionListener, if need be.

Since developers tend to base their apps off of the component-showcase, we should potentially add the call to FacesContext.renderResponse() into the rowSelector example. At the very least we should add a comment explaining the pros and cons of it, which are as follows:

In applications where there are input fields with validators in the same form as a table with row selection, selecting a table row will fire the input component validators. If this is undesirable, then it's recommended to separate the table and the input fields into separate forms. If that is not possible, then you may call FacesContext.getCurrentInstance().renderResponse() from within the rowSelector's selectionListener bean method, which will skip all of the phases, including validation, up until rendering.

When using a component, like the rowSelector, to update the contents of input components (such as when editing properties of a user, after selecting the user from a table, for example), if the input components are inside of nested UIData (any iterative container component), then the update to your model should happen in the UPDATE_MODEL or INVOKE_APPLICATION phases, which may involve re-queuing the rowSelector's selectionListener RowSelectionEvent to one of those later phases. Updating the model in an earlier phase will result in the input component values being overwritten in the beans, such that the previously selected row data will be set into the newly selected row data. This technique of re-queuing the RowSelectionEvent is not compatible with the above technique of calling FacesContext.getCurrentInstance().renderResponse(), since if you call renderResponse() there will be no UPDATE_MODEL or INVOKE_APPLICATION phases, and if you re-queue the event without calling renderResponse(), and you have validators, then the validators will fire, and if they fail there will also be no UPDATE_MODEL or INVOKE_APPLICATION phases.