Hi Julian, I was too glib in my earlier reply.
I, too, am seeing this problem. I hadn't completetly tested this app in production mode, and it fails miserably when compiled. So, I will post updates to this thread when I get a solution that works not only in development mode, but also when compiled. On Aug 19, 8:17 am, jsg <[email protected]> wrote: > We have refreshed the view because instead of calling > ListDataProvider.refresh() which simply calls updateRowData() for all > the registered displays, we've done the following: > > By calling batchTable.setRowData() we are simply more directly > targeting both the display and only the row that has changed. (Rather > than all visible rows by calling refresh().) > As far as I can tell from the system, the DataProviders have no > knowledge of the internal column data and so they can't know if any of > the values of the rows have been updated. Only that the row instances > themselves have changed. (I have tested it now, just to be safe, > replacing setRowData() with refresh() with the same results.) > > Our use case is not so uncommon that we should be struggling so much > with this intended functionality. > > Thanks for your prompt reply. > Julian > > On Aug 19, 4:16 pm, Jeffrey Chimene <[email protected]> wrote: > > > > > > > > > On 8/19/2011 4:53 AM, jsg wrote: > > > > Thanks for your insight. > > > > However, after wrapping the setRowData() in a ScheduleDeferred like > > > so: > > > > Scheduler.get().scheduleDeferred(new ScheduledCommand() { > > > @Override > > > public void execute() { > > > > > > batchTable.setRowData(index, > > > Collections.singletonList(object)); > > > } > > > }); > > > > There is no perceived change in behaviour. > > > I've tried wrapping the whole FieldUpdater.update() contents inside > > > the execute() action, but to no avail. > > > I'm not sitting in front of my GWT development machine,so I don't have > > this exactly right,but where are you calling the list.refresh() method? > > You've updated the backing list, but not refreshed the view (at least in > > the sample). > > > > On Aug 18, 10:01 pm, Jeff Chimene<[email protected]> wrote: > > >> On 08/18/2011 12:05 PM, jsg wrote: > > > >>> Hello. > > >>> I've created a test case of my CellTable issue as a self contained > > >>> panel that can easily be imported into any project: > > >>>http://pastebin.com/zDLPKUNh > > >>> Basically I have two Date class fields in my row model, a startDate > > >>> and an endDate. Each Date has two columns in the CellTable (called > > >>> batchTable), one to display the actual date (a DatePickerCell) and > > >>> the other being a text input cell for the time. > > >>> When the FieldUpdater of the startTime or endTime is fired we parse > > >>> the value, save the new time and call batchTable.setRowData() with > > >>> the updated object and row index. > > >>> The problem is that when FieldUpdater is fired, the cells do not > > >>> update. I specifically edited the FieldUpdater of the endTime cell > > >>> to be an hour later than what it was set at. > > >>> I've checked as best as I can that all the gets and sets of the > > >>> respective startDate and endDate are in order, but I'm thinking that > > >>> there's something about CellTable I'm not getting. > > >>> Apologies if I've missed anything. > > >>> I'm running: GWT 2.3 > > >>> I've tested it in the latest Chrome and IE9. > > >>> Regards, Julian > > >> Try putting your update actions inside a ScheduleDeferred command. > > > >> The issue seems to be the coupling between the FieldUpdater and the > > >> cellTable refresh logic. Running the FieldUpdate.update() action after > > >> the browser's refresh loop seems to address this issue. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. 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.
