Sylvain and Martin, I've been thinking about the tab problems you guys have been experiencing. We are not yet using tabs in our application but we will need to shortly. I was talking about your problem with a couple of developers over lunch today and one of them made a good point.
Why resubmit at all when the user is changing tabs? Why not just use <divs> and have the component write the javascript necessary to show and hide the tabs? I suppose this adds a javascript requirement, but seriously, can you really imagine writing an application that is sophisticated enough to call for tabs but doesn't support javascript? This obviously allows you to overcome a ton of potential issues. No need for <x:saveState> you can just rely on preserverDataModel. Also, you can write meaningful value change events. I know that we're going to have a tough time using the tabbed pane as it is now. This is because we don't want to save until the user specifically requests it. But once they do save, we want to know *all* of their changes, not jus the onee since the last tab switch. Something to consider at least. I have my hands full with my day job and the new tree and suggest components. I would be happy to work on something like this with you guys once that is done though. sean On Sun, 13 Feb 2005 20:04:47 -0400, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > I've found the bug : > > The HtmlDataTableHack has a _saveDescendantStates boolean. > This is set by the HtmlDataTable to false if it's rendered for the first > time (which seems reasonable), BUT also if all the table's childrens are > valid. > So, if you have no validation error in your table, the data model isn't > preserved. > This comes from the assumption that if there is no validation error, the > values will be applied to the backing bean, and thus, we don;t need to > retain them. > Unfortunately, if you're in a tabePanel and select another tab, then the > values aren't applied to the backing bean, and if you have no validation > error, then the submitted values are lots. > > I've just commented the culprit code in HtmlDataTable, as this optimization > can still be valid, but in more restricted cases. > We have to check (if possible) that the applyValues phase will be run. > > I suspect this isn't easy (if possible), but at least, the code is still > there before we decide to improve or discard it. > > As for the problem described by Sean, I'm not so sure anymore that my > previous explanation (bellow) is valid. > Indeed, now, if you press the submit button, the single checkBox value is > lost (which I thought was normal), but the values of the checkBoxes in the > dataTable aren't lost. > So, at least, we have an inconsistency here, and I'm not sure which > behavior is valid. > > Sylvain. > > On Sun, 2005-02-13 at 14:43 -0400, Sylvain Vieujot wrote: > > Hello Sean, > > I think we have two different problem here : > > 1- The one you describe, that is you check the checkbox on tab1, then > select tab2 and hit the submit button. > I don't think this is a bug. It's just that the checkbox has a request > scope. > So, when you submit, you set the submitted value to the checkbox backend > bean, but then you end the request, and instenciate a new bean, as you're > redirected to the same page. > If you set the scope of the bean to session in the examples-config.xml > file, then the bean is retained, and you still see the value after the > submit. > <managed-bean> > <managed-bean-name>testCheckBox</managed-bean-name> > > <managed-bean-class>org.apache.myfaces.examples.misc.TestCheckBox</managed-bean-class> > <managed-bean-scope>session</managed-bean-scope> > </managed-bean> > So, I don't see any bug here. > As Martin said, they used to be a bug for similar cases a few weeks ago, > but it's fixed now. > To fully answer your question, indeed, if a checkbox's value is expected > (that is the component is rendered), and isn't submitted, then the > checkbox's value will be set to false. > But if the component isn't rendered, it isn't decoded, and so it isn't > reset. > > 2 - The second problem is that if you put some components inside a > dataTable, and select another tab, then that component's submitted value is > lost. > This is what we have we the 3 checkboxes & inputText on tab3. > Martin suggested : > > 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... > I will try to check that, but this might indeed be the explanation. > He also suggested using the saveState instead, but this can't be the > solution to our problem, as saveState saves only the backing bean's value, > and not the still un-applied values that are kept in the component. > So, in this case, we really have a bug, or at least, an unexpected > behavior. > > Sylvain. > > On Sun, 2005-02-13 at 12:46 -0500, Sean Schofield wrote: > Sylvain, Do you agree with my explanation of the problem? If the values are > not submitted then your checkbox is going to always be false when you're > done decoding. That's interesting that all of the values are submitted when > you press the common submit button. I wouldn't have expected that. (I mean I > expect that as a user but not as a developer who knows about the tab > problem.) sean On Sun, 13 Feb 2005 13:41:14 -0400, Sylvain Vieujot > <[EMAIL PROTECTED]> wrote: > 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 > <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 > > > > <[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
