For what it's worth, we're going to track this issue for MyFaces at
http://issues.apache.org/jira/browse/MYFACES-1109
Since we can't fix the behavior for JSF 1.1, we'll probably add it as
an attribute to t:dataTable, and we'll duplicate whatever you folks
come up with for MR for our 1.2 branch.
On 7/10/06, Ryan Lubke <Ryan.Lubke_at_sun.com> wrote:
> Michael Youngstrom wrote:
> > 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. :)
> I've raised the priority of Spec issue 153 for possible inclusion
> in the upcoming MR.
> >
> > 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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
>
>