Re: Question regarding UIData state saving

[Michael Youngstrom <yo...@gmail.com>]

>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

Re: Question regarding UIData state saving

[Mathias Brökelmann <mb...@googlemail.com>]

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 <aw...@gmail.com>:
> 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 <ma...@gmail.com> 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 <yo...@gmail.com> 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

Re: Question regarding UIData state saving

[Adam Winer <aw...@gmail.com>]

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 <ma...@gmail.com> 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 <yo...@gmail.com> 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
> >
>

Re: Question regarding UIData state saving

[Manfred Geiler <ma...@gmail.com>]

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 <yo...@gmail.com> 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
>