I think we should add this to the implementation of the tomahawk
DataTable. We can not change UIData since this behavior is specified
in the spec (see API Doc for UIData.encodeBegin()). Unfortunately I´m
currently not able to find the time to set up my test environment with
the new maven build system.

I wonder how UIXTable is able to determine default values in nested
components. Do you compare the row state objects with the state object
w/o row scope?

2006/3/1, Adam Winer <[EMAIL PROTECTED]>:
> 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
> > >
> >
>


--
Mathias

Reply via email to