Return-Path: Delivered-To: apmail-incubator-myfaces-dev-archive@www.apache.org Received: (qmail 41014 invoked from network); 13 Feb 2005 17:42:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 13 Feb 2005 17:42:38 -0000 Received: (qmail 32285 invoked by uid 500); 13 Feb 2005 17:42:37 -0000 Delivered-To: apmail-incubator-myfaces-dev-archive@incubator.apache.org Received: (qmail 32139 invoked by uid 500); 13 Feb 2005 17:42:37 -0000 Mailing-List: contact myfaces-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list myfaces-dev@incubator.apache.org Received: (qmail 32125 invoked by uid 99); 13 Feb 2005 17:42:36 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO,HTML_30_40,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from mailgwvw01.freelance.com (HELO mailgwvw01.freelance.com) (207.234.129.118) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 13 Feb 2005 09:42:36 -0800 Received: from mailgwvw02.freelance.com (mailgwvw02.freelance.com [207.234.129.52]) by mailgwvw01.freelance.com (8.12.3/8.12.3) with ESMTP id j1DHgeSZ024440; Sun, 13 Feb 2005 18:42:50 +0100 Received: from 10.0.0.34 ([81.65.10.78]) by mailgwvw02.freelance.com (Lotus Domino Release 5.0.12) with ESMTP id 2005021318412421:11351 ; Sun, 13 Feb 2005 18:41:24 +0100 Subject: Re: Fwd: Another bug in h:selectBooleanCheckbox while embeded in a x:dataTable From: Sylvain Vieujot To: martin@marinschek.com Cc: MyFaces Development In-Reply-To: <5a99335f0502130314a747537@mail.gmail.com> References: <1107887132.310.11.camel@localhost.localdomain> <2387fbc505021113327694a953@mail.gmail.com> <1108167537.20347.112.camel@localhost.localdomain> <2387fbc505021207516d1a355b@mail.gmail.com> <1108228042.19198.5.camel@localhost.localdomain> <5a99335f050212102020b2cfff@mail.gmail.com> <1108236487.19198.9.camel@localhost.localdomain> <5a99335f0502121224465df649@mail.gmail.com> <1108242379.19198.17.camel@localhost.localdomain> <5a99335f05021303144044ee2e@mail.gmail.com> <5a99335f0502130314a747537@mail.gmail.com> Date: Sun, 13 Feb 2005 13:41:14 -0400 Message-Id: <1108316475.5838.4.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) X-MIMETrack: Itemize by SMTP Server on mailgw01/Freelance(Release 5.0.12 |February 13, 2003) at 02/13/2005 06:41:24 PM, Serialize by Router on mailgw01/Freelance(Release 5.0.12 |February 13, 2003) at 02/13/2005 06:41:55 PM, Serialize complete at 02/13/2005 06:41:55 PM Content-Type: multipart/alternative; boundary="=-jqdYZowh5EqQ1ZD3xSsx" X-Spam-Status: No, hits=0.5 required=5.0 tests=HTML_20_30,HTML_MESSAGE autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on mailgwvw01.freelance.com X-Virus-Scanned: ClamAV 0.80/632/Thu Dec 16 14:15:42 2004 clamav-milter version 0.80j on mailgwvw01.freelance.com X-Virus-Status: Clean X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N --=-jqdYZowh5EqQ1ZD3xSsx Content-Transfer-Encoding: 7bit Content-Type: text/plain No, no validation problem. If you just click another tab, the values aren't submitted to the backing bean. The values are submitted to the backing bean only when the commandButton is clicked. Sylvain. On Sun, 2005-02-13 at 12:14 +0100, Martin Marinschek wrote: > ---------- Forwarded message ---------- > From: Martin Marinschek > Date: Sun, 13 Feb 2005 12:14:25 +0100 > Subject: Re: Another bug in h:selectBooleanCheckbox while embeded in a > x:dataTable > To: Sylvain Vieujot > > > Why are the values not submitted? is there a validation error? > > If there is no validation error, the values ought to be submitted to > the backing bean, this is how all the other fields of the tabbed panel > work... > > regards, > > Martin > > > On Sat, 12 Feb 2005 17:06:19 -0400, Sylvain Vieujot wrote: > > Hello Martin, > > > > I checked with adding an x:saveState statement, but it doesn't work better, > > and I think this is normal. > > Indeed, saveState saves the value of the backing bean, and as we are > > dealing with submitted values (that haven't been applied to the backing bean > > yet), the submitted values aren't saved. > > > > Do you think we could change the way it works now, to preserve the data > > model if the component has been rendered once in the previous requests ? > > Like introducing on the fly a component at the root of the view that would > > be in charge of preserving the data model ? > > > > Thanks, > > > > Sylvain. > > > > > > On Sat, 2005-02-12 at 21:24 +0100, Martin Marinschek wrote: > > yes, that is wrong... the preserve data model does only work if the > > component is rendered - in this case it is not, as you are tabbing away to > > the other tab... try it with an x:saveState statement... regards, Martin On > > Sat, 12 Feb 2005 15:28:07 -0400, Sylvain Vieujot > > wrote: > Hello Martin, > > No, I didn't include any x:saveState. > I thought > > the preserveDataModel would do that. > Am I wrong ? > > Sylvain > > > On > > Sat, 2005-02-12 at 19:20 +0100, Martin Marinschek wrote: > you need to save > > the state of the checkboxes - do you do that? do you have > an x:saveState > > tag on the top of the jsp? I don't know, I can't check the > cvs right now, > > but if not, you need to save the state of your managed > bean... regards, > > Martin On Sat, 12 Feb 2005 13:07:22 -0400, Sylvain Vieujot > > > wrote: > Hello Sean, > > I agree that checkboxes are > > > being reset on decode as long as no value is > posted, BUT only the childs > > > of the selected panelTab are decoded, so this > doesn't affect the > > > components of un-selected tabs as they aren't decoded. > > Plus, in the > > > examples webapp, on the first tab, the "A checkbox" checkbox > is rendered > > > only on that tab, and isn't common to all tabs. > > Also, I just committed a > > > change to the webapp that shows that the problem > isn't specific to > > > checkboxes. > In the dataTable, tab3, you now also have texts next to the > > > checkboxes, and > the texts are reset too. > > Sylvain. > > > On Sat, > > > 2005-02-12 at 10:51 -0500, Sean Schofield wrote: > Sylvain, The other > > > checkboxes aren't reset because they are on every tab. > They are always > > > being resubmitted. Would you agree that the checkboxes are > being reset on > > > the decode as long as no value is posted (and that they are > not > > disabled)? > That much seems clear from the decodeUISelectBoolean method. > > > The only > thing I can't be sure of is that the values aren't being posted. > > I > didn't > have time to prove that. You can prove it yourself with a > > simple > test. > Just add a break point in > > HtmlRendererUtils:decodeUISelectBoolean > method. > Then start with the > > debugger. When you hit the breakpoint take a > look at > the param map and > > see if the values for those checkboxes are being > > submitted. sean > I > > don't think this is the problem now. > What you > > described was a previous > > bug, but now the pannelTab decodes only > the right > > components. > So, > > the checkboxes from another tab aren't decoded & reset. > > > > Furthermore, > > if this were the case, the checkbox from tab 1 would > reset > too, > and it > > doesn't. > I'll try to include h:inputText in the > dataTable to > see if we > > have the same > behaviour, or if it's related to > the checkBox. > > > > > Sylvain. > > > On Fri, 2005-02-11 at 16:32 -0500, Sean > Schofield wrote: > > > > Sylvain, I figured out your problem. Its a combination > of the checkbox > > and > > the panel tab together. The datatable is not the > problem. The > > default > > behavior for the checkbox is to *reset* the value > of the > > checkbox during the > > decode phase. (See > > > HtmlRendererUtils:decodeUISelectBoolean.) This makes > > sense because HTML > > > standard will not submit "false" values for unchecked > > checkboxes. So > > > unless the checkbox is disabled, faces assumes that it > is > unchecked and > > > rechecks it every time its posted (as long as the value is > > submitted > > as > true.) IMO this is desirable (and I believe probably part of > > the > > spec.) > As I mentioned your example works fine if you press the "common > > > > submit > button" on the tab (checkbox with true stays checked after the > > > > post.) > The problem starts once you click on another tab. I didn't have > > > > time to > investigate the specifics but I think I have discovered the > > > basic > > problem. You checkbox value does not get posted when you click on > > one > of > > the other tabs. Even if it does get posted, it is posted to a > > > request > > scope bean. Say you go from tab 3 to tab 1. On tab 1 your > > > sample > > checkboxes are not rendered so when you click back to tab 3, you > > > are *not* > > posting any values for them. Because the decode is resetting > > the > values, > > you end up with "false" for all of your checkboxes. The > > other > checkboxes > > are ok because they are common to all 3 tabs so they > > constantly > get > > posted. That's the source of the problem. I will try > > and learn more > about > > panelTab so I can help with the fix but there are > > some > complicated > choices > to make. I suppose for now you could have the > > checkboxes > be > hidden on the > tabs where they shouldn't be displayed so > > that they > are > common to all > tabs. HTH, sean --=-jqdYZowh5EqQ1ZD3xSsx Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8 No, no validation problem.

If you just click another tab, the values aren't submitted to the backing bean.
The values are submitted to the backing bean only when the commandButton is clicked.

Sylvain.

On Sun, 2005-02-13 at 12:14 +0100, Martin Marinschek wrote: 
---------- Forwarded message ----------
From: Martin Marinschek <martin.marinschek@gmail.com>
Date: Sun, 13 Feb 2005 12:14:25 +0100
Subject: Re: Another bug in h:selectBooleanCheckbox while embeded in a
x:dataTable
To: Sylvain Vieujot <svieujot@apache.org>


Why are the values not submitted? is there a validation error?

If there is no validation error, the values ought to be submitted to
the backing bean, this is how all the other fields of the tabbed panel
work...

regards,

Martin


On Sat, 12 Feb 2005 17:06:19 -0400, Sylvain Vieujot <svieujot@apache.org> wrote:
>  Hello Martin,
>
>  I checked with adding an x:saveState statement, but it doesn't work better,
> and I think this is normal.
>  Indeed, saveState saves the value of the backing bean, and as we are
> dealing with submitted values (that haven't been applied to the backing bean
> yet), the submitted values aren't saved.
>
>  Do you think we could change the way it works now, to preserve the data
> model if the component has been rendered once in the previous requests ?
>  Like introducing on the fly a component at the root of the view that would
> be in charge of preserving the data model ?
>
>  Thanks,
>
>  Sylvain.
>
>
>  On Sat, 2005-02-12 at 21:24 +0100, Martin Marinschek wrote:
>  yes, that is wrong... the preserve data model does only work if the
> component is rendered - in this case it is not, as you are tabbing away to
> the other tab... try it with an x:saveState statement... regards, Martin On
> Sat, 12 Feb 2005 15:28:07 -0400, Sylvain Vieujot <svieujot@apache.org>
> wrote: > Hello Martin, > > No, I didn't include any x:saveState. > I thought
> the preserveDataModel would do that. > Am I wrong ? > > Sylvain > > > On
> Sat, 2005-02-12 at 19:20 +0100, Martin Marinschek wrote: > you need to save
> the state of the checkboxes - do you do that? do you have > an x:saveState
> tag on the top of the jsp? I don't know, I can't check the > cvs right now,
> but if not, you need to save the state of your managed > bean... regards,
> Martin On Sat, 12 Feb 2005 13:07:22 -0400, Sylvain Vieujot >
> <svieujot@apache.org> wrote: > Hello Sean, > > I agree that checkboxes are >
> being reset on decode as long as no value is > posted, BUT only the childs >
> of the selected panelTab are decoded, so this > doesn't affect the >
> components of un-selected tabs as they aren't decoded. > > Plus, in the >
> examples webapp, on the first tab, the "A checkbox" checkbox > is rendered >
> only on that tab, and isn't common to all tabs. > > Also, I just committed a
> > change to the webapp that shows that the problem > isn't specific to >
> checkboxes. > In the dataTable, tab3, you now also have texts next to the >
> checkboxes, and > the texts are reset too. > > Sylvain. > > > On Sat, >
> 2005-02-12 at 10:51 -0500, Sean Schofield wrote: > Sylvain, The other >
> checkboxes aren't reset because they are on every tab. > They are always >
> being resubmitted. Would you agree that the checkboxes are > being reset on
> > the decode as long as no value is posted (and that they are > not
> disabled)? > That much seems clear from the decodeUISelectBoolean method. >
> The only > thing I can't be sure of is that the values aren't being posted.
> I > didn't > have time to prove that. You can prove it yourself with a
> simple > test. > Just add a break point in
> HtmlRendererUtils:decodeUISelectBoolean > method. > Then start with the
> debugger. When you hit the breakpoint take a > look at > the param map and
> see if the values for those checkboxes are being > > submitted. sean > I
> don't think this is the problem now. > What you > > described was a previous
> bug, but now the pannelTab decodes only > the right > > components. > So,
> the checkboxes from another tab aren't decoded & reset. > > > > Furthermore,
> if this were the case, the checkbox from tab 1 would > reset > too, > and it
> doesn't. > I'll try to include h:inputText in the > dataTable to > see if we
> have the same > behaviour, or if it's related to > the checkBox. > > >
> Sylvain. > > > On Fri, 2005-02-11 at 16:32 -0500, Sean > Schofield wrote: >
> > Sylvain, I figured out your problem. Its a combination > of the checkbox
> and > > the panel tab together. The datatable is not the > problem. The
> default > > behavior for the checkbox is to *reset* the value > of the
> checkbox during the > > decode phase. (See >
> HtmlRendererUtils:decodeUISelectBoolean.) This makes > > sense because HTML
> > standard will not submit "false" values for unchecked > > checkboxes. So >
> unless the checkbox is disabled, faces assumes that it > is > unchecked and
> > rechecks it every time its posted (as long as the value is > > submitted
> as > true.) IMO this is desirable (and I believe probably part of > > the
> spec.) > As I mentioned your example works fine if you press the "common > >
> submit > button" on the tab (checkbox with true stays checked after the > >
> post.) > The problem starts once you click on another tab. I didn't have > >
> time to > investigate the specifics but I think I have discovered the >
> basic > > problem. You checkbox value does not get posted when you click on
> one > of > > the other tabs. Even if it does get posted, it is posted to a >
> request > > scope bean. Say you go from tab 3 to tab 1. On tab 1 your >
> sample > > checkboxes are not rendered so when you click back to tab 3, you
> > are *not* > > posting any values for them. Because the decode is resetting
> the > values, > > you end up with "false" for all of your checkboxes. The
> other > checkboxes > > are ok because they are common to all 3 tabs so they
> constantly > get > > posted. That's the source of the problem. I will try
> and learn more > about > > panelTab so I can help with the fix but there are
> some > complicated > choices > to make. I suppose for now you could have the
> checkboxes > be > hidden on the > tabs where they shouldn't be displayed so
> that they > are > common to all > tabs. HTH, sean
--=-jqdYZowh5EqQ1ZD3xSsx--