Re: What is the proper way of implementing page-level select-all through a Checkbox Header in a CellTable

I tried this solution, but in my case, the header checkbox seems automatically selected and it selects all the records. I have a situation where there could be pre-selected values for each row coming from DB. How do I do that?

On Monday, August 27, 2012 at 2:58:15 PM UTC-5, Kara Marie Rawson wrote:

That works like a charm. Thanx for the tip!

On Friday, June 8, 2012 8:45:04 PM UTC-4, Nicholas Lesiecki wrote:

Hi,

Thanks for your well written post. It appears that your solution works well if you construct the CheckboxCell with the right flags:

new CheckboxCell(true, true)

the two booleans are handlesSelection and dependsOnSelection, and they cure the weird event ordering issues you were seeing.

Cheers,

Nick

On Tuesday, November 22, 2011 10:19:31 AM UTC-8, Raziel wrote:

This question has been asked and partially responded in a number of
posts:

http://groups.google.com/group/google-web-toolkit/browse_thread/thread/dc3a97cd25deb6e3/392dfcdb35f04c95?lnk=gst&q=DefaultSelectionModel#392dfcdb35f04c95
http://snipt.net/araujo921/checkbox-in-gwt-celltable-header/
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/56f5513b709cd041
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/b20080056a76276f
http://0-groups.google.com.topcat.switchinc.org/group/google-web-toolkit/browse_thread/thread/6d4e65510855e6f6

However, I still haven't found I clean answer to what seems to me a
very common feature requested in data presentation (and editing)
grids.

In summary we want to be able to add a checkbox header to a selection
column of checkboxes that:

* Checking it will select all visible items in the grid.
* Unchecking it will deselect all visible items in the grid.
* Any change in the visible data, caused for example by paging or
sorting, will result in the checkbox header value to be updated
according to the rules above: if all visible items are selected then
check it, otherwise uncheck it.

The straightforward logic would suggest that the following
implementation should work:

      CheckboxCell headerCheckbox = new CheckboxCell();
      Header<Boolean> selectPageHeader = new
Header<Boolean>(headerCheckbox) {
        @Override
        public Boolean getValue() {
          for (T item : grid.getVisibleItems()) {
            if (!getSelectionModel().isSelected(item)) {
              return false;
            }
          }
          return grid.getVisibleItems().size() > 0;
        }
      };
      selectPageHeader.setUpdater(new ValueUpdater<Boolean>() {
        @Override
        public void update(Boolean value) {
          for (T item : grid.getVisibleItems()) {
            getSelectionModel().setSelected(item, value);
          }
        }
      });
      grid.insertColumn(0, checkColumn, selectPageHeader);

However, the result is not the expected:

* When updating the visible data, lets say by moving to the next page,
the getValue() method gets called. The first couple of calls,
getVisibleItems() returns empty, and then it returns the new not-yet-
selected data. In each case, getValue() returns false. However, this
produces no change in the checked state of the header. This in itself
seems like a bug to me.

* When just toggling the checkbox header, this ends up in the opposite
state than desired. Even though update() gets called with the proper
value that reflects the checkbox header state, and the last calls made
to getValue() result in the proper value being returned. The only
"irregular" logic I see that could cause this, is that when clicking
on the header, the getValue() method gets called before the update() -
to obtain the key and create a cell context. That results in
getValue() returning the wrong value (i.e. the opposite). However,
after update() gets called and it sets the selection state of the
visible items, getValue() gets called again, thus returning the proper
value this time.

I guess there are ways where the header can be created in a way where
we can control better how its value is set and retrieved. However,
this being such a common use case, and whose logical implementation
shown above produces inconsistent results, tells me that either I'm
completely missing something, or that this is a flaw in the celltable
widgets.

I would appreciate any input on this regard,

Thanks

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.