The trick is that the checkbox is not decoded in the decode phase -
the tabbed panel knows which components are rendered, and exactly
those are decoded - there is no submitted value for components which
are not rendered.
That was not like that in earlier versions of the tabbed panel, but I
fixed this bug after Alessandro reported his problems with the tabbed
panel.
(bear in mind - I am talking about how it should work, not about how
it really works if there are any bugs crawling around ;)
regards,
Martin
On Sat, 12 Feb 2005 16:09:29 -0500, Sean Schofield
<[EMAIL PROTECTED]> wrote:
> 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
> <[EMAIL PROTECTED]> 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
> > <[EMAIL PROTECTED]> 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
> > > <[EMAIL PROTECTED]> 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
> > > >
> > >
> > >
> >
>
