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

this works with true and true set on the CTOR of the checkbox header cell, however this does not persist though multiple pages becuase you are only referencing the visible items. working on implementing a post processor to the updaterowcount and updaterowdata method calls. if we use a flag to determine when select all was toggled, then we can execute the post process to update new pages of visible records as the user toggles though them. Also during user interaction such as batch editing on all selected items, we can check to see if the flag is up, and apply this to all records regardless if the user has paginated to them yet. fun fun. Im still a bit curious to as of why google has not included this functionality into there datagrid release. Is it just that new??? Neways thanx for the pointers it saved me a bunch of time today.

k

On Tuesday, November 22, 2011 1:19:31 PM UTC-5, 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 view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/pcltn-6GcmEJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.