the reason why I introduced this flag was a recent change to t:datatable by martin who hard coded this to preserveRowState=true. But it is not a solution for every one, since clearing the datamodel cache and rowstate cache must be done together. If preserveRowState=true is used only the datamodel cache is cleared (which results in calling the getter method for the value of t:datatable before rendering the response).
If the rowstate is not cleared it is possible to save unbounded values to the rendering phase. But if the datamodel changes (like add, remove or sort rows) it will not work since t:datatable do not know which rowstate belongs to which row data object. The rowstates are identified only by the row index (current clientId of t:datatable is used internally) not by row data. The rowstate and the datamodel must be held during decode, validate, update and invoke application phases. before rendering the datatable it is determined if an error in the previous phases happened. If that is the case the rowstate and the datamodel cache is not cleared and reused to show the error on the page with old content. If there is no error the rowstate and datamodel cache is discarded. 2005/11/14, Grant Smith <[EMAIL PROTECTED]>: > I'm having problems with this too. In my application, I now have to submit > twice before I see the changes effect the datatable, even though the model > is updated correctly after the first submit. I presume it's work in progress > :) > > > On 11/13/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I see that recently some work has been done on implementing a > > "preserveRowStates" flag for the dataTable component. > > > > As is (now) documented, the ancestor UIData component uses the > > "flyweight" pattern so that only one set of child objects is used to > > represent the columns and their contents. As each row is selected via > > setRowIndex, the component state is saved in _rowStates array, and the > > components are reinitialised with the _rowStates entry appropriate for > > the next row. > > > > However unless preserveRowState is set (it is false by default), the > > encodeBegin method discards all row state before rendering begins. > > > > I'm puzzled by this. Why is the row state cleared? > > > > And if row state is going to be ignored, what's the point of saving it > > at all? > > > > Regards, > > > > Simon > > > > > > -- > Grant Smith > -- Mathias
