myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <martin.marinsc...@gmail.com>
Subject Re: Another bug in h:selectBooleanCheckbox while embeded in a x:dataTable
Date Sun, 13 Feb 2005 11:17:29 GMT
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
<sean.schofield@gmail.com> 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
> <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
> > > >
> > >
> > >
> >
>

Mime
View raw message