dev@javaserverfaces.java.net

Re: UIData.encodeBegin row-state clearing

From: Michael Youngstrom <youngm_at_gmail.com>
Date: Mon, 10 Jul 2006 10:31:58 -0600

The main reason it wasn't fixed before is because some dataTable demo
stops working because it is dependent upon that broken functionality.
I don't know why it couldn't get pushed into 1.2 since the issue was
raised long before 1.2 went final....Anyway, in case you cannot tell
it has been the source of some frustration for me. :) Adding a custom
attribute for better functionality is a good idea for MyFaces. Now if
only I can get something done about it in the RI. :)

Mike

On 7/10/06, Mike Kienenberger <mkienenb_at_gmail.com> wrote:
> Ok. It looks like we're all in agreement. I'm surprised no one has
> tackled it in a year, though. I'll see what I can do on the MyFaces
> side to come up with a workable alternative. I'll probably try
> committing an attribute flag for t:dataTable/t:dataList that supports
> more reasonable behavior as a first pass.
>
> On 7/10/06, Michael Youngstrom <youngm_at_gmail.com> wrote:
> > Mike,
> > Thanks for bringing this up. I have been battling this issue for a
> > long time. For some history on the issue see these bugs:
> >
> > https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=140
> > https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=73
> >
> > I believe the true solution is to be basically do what you suggest
> > which is to always save the state of of ValueHolder components. See
> > this spec issue:
> >
> > https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=153
> >
> > If you can help provide some leverage to get this fixed I'd greatly
> > appreciate it. It would be very nice if we could get a fix into the
> > upcoming maintenance release of the spec.
> >
> > Mike
> >
> > On 7/10/06, Mike Kienenberger <mkienenb_at_gmail.com> wrote:
> > > The javadocs of UIData.encodeBegin state:
> > >
> > > =========
> > > In addition to the default behavior, ensure that any saved per-row
> > > state for our child input components is discarded unless it is needed
> > > to rerender the current page with errors.
> > > =========
> > >
> > > It seems to me that the "with errors" part should be dropped.
> > >
> > > Consider the case of a page with a UICommand where immediate="true"
> > > and a UIData containing UIInput components.
> > >
> > > In this case, the UIInputs will lose any submitted values when the
> > > UICommand is triggered. This is the behavior I'm seeing with the
> > > MyFaces implementation, and I don't see a way around it in the spec.
> > >
> > > Can we change the spec to preserve the state whenever the UIInputs
> > > have a submitted value or a local value still present? This seems
> > > more useful than checking for an error message.
> > >
> > > Taking a look at the latest JSF 1.2 RI source, I also see that the
> > > state is also saved if the UIData is inside another UIData. The spec
> > > docs should reflect this as well.
> > >
> > > I'm going to try to be on ##jsf today if anyone would rather talk
> > > about it there.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> > > For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> > For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>