Mailing-List: contact myfaces-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <myfaces-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: domain of sean.schofield@gmail.com
 designates 64.233.184.204 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=bapqvJJswghj6IL7vcZNqqLanuV7rxNDwwPMryWriYSfeO9FUQhCOes7kJ/VbZelQZkI28aLvLIfZ4HXiAzMFQ5+814SznkLd5dsPDl9FHL7yeYrczC69tL4er0onWAZKQdSf1ZhvfUM5F8kxvrjJBsGfLQ+Gobg1dWRZOp5BQ8=
Message-ID: <2387fbc50502121309787edd55@mail.gmail.com>
Date: Sat, 12 Feb 2005 16:09:29 -0500
From: Sean Schofield <sean.schofield@gmail.com>
Reply-To: Sean Schofield <sean.schofield@gmail.com>
To: martin@marinschek.com,
	MyFaces Development <myfaces-dev@incubator.apache.org>
Subject: Re: Another bug in h:selectBooleanCheckbox while embeded in a
 x:dataTable
In-Reply-To: <5a99335f050212130040e430d4@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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>
	 <2387fbc505021212525adf2b75@mail.gmail.com>
	 <5a99335f050212130040e430d4@mail.gmail.com>

Martin,

I still don't see how this wound fix the *checkbox* case.  For text,
etc. I would agree with you.  But it seems like saving the state only
fixes part of the problem.  Ultimately the decode for the checkbox
will replace whatever the value with "false" if no value has been
submitted for the checkbox.

The decode statement happens *after* Restore View phase so it doesn't
matter what you saved to state.  If the checkbox is not resubmitted
with a "value" of true, it will be reset to false and that is what you
will see after Render Response.

As I said I am not an expert on saveState so I might be mistaken. 
When I was thinking about solving a different dataTable issue I was
told that preserve data model will update the value of the data with a
new bean just before Render Response.  If saveState does this same
thing (gets the boolean value from the backing bean just before render
response) then I guess that would work.

Is that what is happening?  

sean


On Sat, 12 Feb 2005 22:00:52 +0100, Martin Marinschek
<martin.marinschek@gmail.com> wrote:
> well, the x:saveState tag is exactly what solves this issue - it
> basically makes a session bean out of a request bean, and there is no
> problem anymore!
> 
> it ought to work if you use this tag to store the bean in between requests!
> 
> regards,
> 
> Martin
> 
> On Sat, 12 Feb 2005 15:52:07 -0500, Sean Schofield
> <sean.schofield@gmail.com> wrote:
> > Sylvain,
> >
> > That is also what is happening to your text.  I haven't seen your
> > updated example but if your h:inputText is mapped to a request scope
> > bean you will have the same problem.  Once you switch to a new tab you
> > are no longer rendering those values.  The next time you come back,
> > you are posting nothing and you get nothing back.
> >
> > I hadn't thought about the dataTable and preserve data model option.
> > In the checkbox case I don't think this matters.  Even with preserving
> > the data model or using x:saveState will likely not fix this issue.
> > I'm not really familiar with x:saveState though so I can't say for
> > sure.
> >
> > Lets suppose you do manage to save the state of the bean.  The decode
> > method *still* resets the value to false if you do not post anything
> > for a checkbox.  So now it will be saving the wrong value ("false") to
> > state.
> >
> > The fundamental problem is difficult.  You've got checkboxes that
> > *require* their values be reposted every time and you've got these
> > tabs that don't always post the checkbox values.  When you click on
> > tab2, tab3 is not rendered.  So there is no way that when you click on
> > tab3 that these checkbox values are going to be reposted.
> >
> > I don't know why the 'A checkbox' works on the first tab.  On my
> > dialup connection its too difficult to verify.  I will look into it
> > later though.  In the meantime I would guess that it has a backer bean
> > with session scope (or that it really itsn't working.)
> >
> > Ultimately there needs to be a strategy devised for dealing with these
> > tabs and situations like the checkbox where the decode is "resetting"
> > the values.  The solution will likely take some thought (at least I
> > can't come up with one off the top of my head.)  Maybe a customized
> > checkbox control (or renderer) that does not reset checkboxes if the
> > previous tab is not the same as the current tab.
> >
> > sean
> >
> > On Sat, 12 Feb 2005 21:24:12 +0100, Martin Marinschek
> > <martin.marinschek@gmail.com> 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
> > >
> >
> >
>