Thank you for you opinion :-) On 8/26/05, Dennis Byrne <[EMAIL PROTECTED]> wrote: > > * Suppose this (selecting a row while model has been > >concurrently modified by a different user): > > Is the backing bean that supplies the List/DataModel/UIData > in session scope? If so, this is a consequence of the > design, not JSF. You'll get the same thing w/ Tapestry, or > ASP.NET for that matter. >
I think that you are not right: - problem is that sequence number of the rows has changed (this problem arises whenever sequence number (position) of a row changes before the page with table is submitted) - we are displaying life data, so if user's had a break and after a while submits the page with the table and data (in db) has been modified concurrently, submitted values will be applied to bad rows :-( - if model were cached in the session, it would surprisingly work - because if the model is cached, it cannot be modified concurrently by a different user > > 3) Submitted value (selected checkbox of the first > row) will > >be applied to the first row of the model. So, actually the > second row > >is selected :-(. (we've developed a quite simple solution, > so if you > >are interested, let me know - and we definitely do not > serialize whole > >model of the table!) > > Please share this w/ the list. This comes up a lot in my shop > and it would be appreciated. I'm also looking for ideas for > one of my side projects, > http://forum.hibernate.org/viewtopic.php?t=945552 . > Dennis Byrne > we've extended MyFaces table. Our table expects "stronger" data model, that extends DataModel but implementation of our model must: return id of any row, return value of a row by ID So, when the method saveState is called on our table, we store IDs of displayed rows (from first to first+rows). So, if table is scrolled (10 of 1000 rows is displayed), we will serialize only IDs of displayed (10) rows. When table is to be restored, we read serialized row IDs, ask for data (getRowDataById(id)) and we provide a temporary model - this model contains exactly the same data as when the page was previously rendered. After all the request values were applied and model is updated we just restore original model (maybe model contains more or less rows, maybe in a different order ...) Btw. I will definitely check your project :-)
