Have talked about this in our googletalk? I thought it was about the
rowstate between request.
This solution might not work in every case. The spec says to discard
any row state before rendering the table if no errors are on the page.
IMO clearing the rowstate and the datamodel must be done together or
not. Clearing the datamodel results in a call to the getter method of
the value for the uidata component. This value might contain data with
different content. It could have rows with different sorting, deleted
or added rows. The value of an unbound editable value holder would be
at the same row index (as it was during the decode phase) which might
be ok if the datamodel didn´t changed.
Maybe we can add this as an optional feature through a boolean attribute.
2005/10/31, Martin Marinschek <[EMAIL PROTECTED]>:
> Hi *, and especially Mathias,
>
> I have changed the following code segment
>
> _initialDescendantComponentState = null;
> if (_isValidChilds && !hasErrorMessages(context))
> {
> //Refresh DataModel for rendering:
> _dataModelMap.clear();
> _rowStates.clear();
> }
> super.encodeBegin(context);
>
> to this:
>
> _initialDescendantComponentState = null;
> if (_isValidChilds && !hasErrorMessages(context))
> {
> //Refresh DataModel for rendering:
> _dataModelMap.clear();
> //_rowStates.clear(); todo: should not be necessary.
> }
> super.encodeBegin(context);
>
> as I think that the calling the _rowStates.clear(); method is not
> correct at this location.
>
> What do you guys say to that? Particularly, I have had a component
> which didn't have a value-binding set for its value and didn't
> remember it's state if this method was called.
>
> regards,
>
> Martin
>
--
Mathias
