Can you reproduce this in a quickstart? Considering nobody had a pertinent
ide the last time, it might be easier.
Thomas
On Tue, Jun 24, 2008 at 4:12 PM, Kirk Israel <[EMAIL PROTECTED]> wrote:
> OK, to summarize what came previously:
> we had a "palette" control (two parallel listboxes, with push buttons
> in between for moving items from one list to the other), and tried to
> have a checkbox that would "select all" - that part worked fine, but
> for some reason we couldn't get it so using the buttons to remove
> items from the right list would also cause the "select all" checkbox
> to be unchecked. We punted, and used a "select all" link that didn't
> need to be visually updated.
>
> But now we're seeing some kind of related problem... in this form we
> have a big CheckGroup -- (previously we had trouble getting the
> contents of the CheckGroup to update when they weren't DHTML-visible,
> so we redraw the whole panel the checkboxes are on). Individual
> subsets of the checkboxes in the overall checkgroup have their own
> "select all" and "clear" links, along with a written summary of what
> is selected inside that checkgroup.
>
> Now, when someone clicks the push button in the pallet control, the
> "select all" links for the checkgroup subsets seem to be updating the
> model (since we see the written summary labels update") but the
> checkboxes don't check! -- until you click one of the checkboxes in
> ANY of the check group subsets, then the select all links can update
> the checkboxes as well.
>
> By using labels w/ timestamps, it seems clear that everything is being
> redrawn. And even if all the internal logic for the palette control
> pushbutton is removed, it's just a AjaxFallbackButton with
> setDefaultFormProcessing(false) that does nothing, the select all
> links can no longer make the checkboxes show the correct state of
> their entry in the cjeckgroup, even as they're redrawn. (Until one is
> clicked, at which point the connection is restored)
>
> So what is going on here? Does this symptom seem to point to
> something we're doing wrong, or is there some kind of generalized
> checkbox updating issue? (since this is KIND of like the previous
> problem)
>
> This is Wicket 1.3.3...
>
>
>
> On Tue, May 27, 2008 at 9:15 AM, Kirk Israel <[EMAIL PROTECTED]> wrote:
> > The Model was a HashMap.
> > When the page was first loaded, only "true" values were loaded into
> > it, i.e. there were no keys or values for checkboxes that weren't
> > supposed to be checked.
> > Later, it didn't matter if we added in an explicit false value for a
> > key, or removing the key, neither were enough to get the checkbox to
> > read that its value had changed.
> >
> > On Sun, May 25, 2008 at 6:00 AM, Thomas Mäder <[EMAIL PROTECTED]>
> wrote:
> >> What value are you returning from the model? In CheckBox.java, I find
> this:
> >>
> >>
> >>final String value = getValue();
> >>if (value != null)
> >>{
> >>try
> >>{
> >>if (Strings.isTrue(value))
> >>{
> >>tag.put("checked", "checked");
> >>}
> >>
> >> And Strings.isTrue() only accepts a bunch of well known values (plus
> null)
> >>
> >> Thomas
> >>
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>