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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
