The row state saving is quite necessary (I remember the discussion). The algorithm in UIXTable is actually fairly simple: an atom of state is either meaningful (contains non-default values) or not. If we've got meaningful state left, don't drop it.
-- Adam On 3/1/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: > MyFaces UIData once had a sophisticated algorithm to determine if > state should be dropped or not. Well, UIData was completely refactored > some time ago and this algorithm seems to be lost. I also remember a > discussion with Mathias (the guy who did the refactoring) before a > while where we discussed the UIData state saving. Don't remember the > exact discussion, but I think Mathias argued, that saving the rowState > is not necessary at all or something like that. > Mathias, can you take over? ;-) > > Manfred > > > On 3/1/06, Michael Youngstrom <[EMAIL PROTECTED]> wrote: > > >I think this is an issue with UIData using a very > > >poor algorithm for when it thinks it can drop state, > > >something like "there weren't any errors." > > >The ADF UIXTable code has a better algorithm > > >hat doesn't suffer from this problem. > > > > So is UIData's poor algorithm a spec issue or an implementation issue? > > Its great that UIXTable doesn't suffer from these problems but it > > would be nice if the standard UIData didn't suffer from these problems > > either. :) I'm just unsure who I need to be lobbying. Can anyone > > give me some direction? > > > > Mike > > >
