Ken Fyten added a comment - 28/Feb/07 10:45 PM This issue needs to be analyzed along with other Seam related issues and distilled to root causes.

Ken Fyten added a comment - 28/Mar/07 11:20 AM @DataModel cases are currently all working with the test cases we have available.

Greg Dick added a comment - 10/Aug/07 5:23 PM I've created a test case for this. It does in fact work, but the way that our ICEfaces examples are written, it can lead you to construct an example which does not work. For my test, I had a List of objects. The List could be populated by a button, sort of to duplicate the behaviour of a database. The app also had buttons to start and end conversations. The @DataModel annotation allows the author to 'outject' a DataModel to the same context in which the containing component is. In the test app, I saw the appropriate model behaviour for the List. ie. the DataModel information was not preserved over redirects unless a long running conversation was started. You could put your backing bean component into various other scopes to achieve other behaviour. That's supported well. The @DataModelSelection allows the author to 'inject' the last selected table row's row Object. The @DataModelSelectionIndex allows the user to 'inject' the last selected row's index. The tricky part is the annotation. You can do the following @DataModel(name="data") private List someData; @DataModelSelection private Object dataRow; Then the list is outjected by the name 'data' automatically by Seam, and can be used directly in the expression language as follows: <h:dataTable var="row" value="# {data} " rendered="# {data.rowCount>0} "> When the above approach is used, the DataModelSelection or the DataModelSelectionIndex works just fine. What doesn't work is the following: @DataModel(name="data") private List someData; public List getSomeData() { return someData; } <h:dataTable var="row" value="# {someData} " rendered="# {someData.rowCount>0} "> Even though the expression is fully valid, and the datatable shows the data that is in the table, the 'injection' portion of the code no longer works. This is only a problem because all our examples are written using this notation, ( necessarily, because ICEfaces only applications don't have access to the @DataModel annotation) leading downloaders to migrate to ICEfaces using examples that don't work, as they stand.