dev@javaserverfaces.java.net

Re: UIData.encodeBegin row-state clearing

From: Ryan Lubke <Ryan.Lubke_at_Sun.COM>
Date: Mon, 10 Jul 2006 09:35:21 -0700

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
>