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 <[EMAIL PROTECTED]> 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
