Just some clarification... I told you to check whether it works with preserveDataModel set to false, due to the fact that preserveDataModel set to true does not work with checkboxes placed inside the table (as the typical way to select some rows to, for example, delete all selected).
It seems that there is an order problem when MyFaces serializes them to preserve the dataModel, so the checkboxes get mixed between requests... Have you faced that problem? 2005/6/28, Werner Punz <[EMAIL PROTECTED]>: > Enrique Medina wrote: > > Fantastic. NULL tells JSF just to stay in the same page, so it should > > work as you have tested. But the problem still remains when navigating > > to another page, doesn't it? > > > Yes that is a huge problem, but the problem is bigger than it seems, it > is basically the old scope problem, which means that you basically loose > all the values unless you traverse it, because we do not have a scope > system between request and session, and add to that some weirdness in > the behavior between the datatable and the scroller and you run into > this mess. > > Shale can solve that to some degree, but I rather doubt it will solve it > for the datatable, the problem is sort of much more fundamental. > > I will try to explain what happens and why the values are lost between > faces-config navigations: > > What happens in a null: > > The values are cleard the form values are refilled, the parameters are > passed via a submit... > The datatable is generated > the scroller is generated does an encodebegin with all the needed > calculations passes it to the datatable for further reference, > the datatable is rendered > and then the scroller does its rendering. > > What happens if you dont do the refresh but a faces-config based traversal: > > The steps until the encodebegin are identical, but then the problem > arises in between encodebegin and renderchildren, the datamodel is lost > along the way and a new one is generated, which is not the same as the > rendered one, thus passing the values, altering the states, etc... does > not have any effect on the rendering and the table->scroller subsystem > resets to the first page. > > I tried to fix that, but I ran against my limited knowledge of JSF. > Probably to fix that a new datatable and scroller maybe a combined > component has to be implemented. > Trying to fix it from outside with a bunch of listeners which hook into > the component definitely wont help neither does altering the scroller > rendering code, because the problem is nested much much deeper. > >
