On 08/19/2011 08:17 AM, jsg 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
You're welcome.
I agree, it's not uncommon.
Absent replies from others on this list, I'd create a new project, and
start adding bits and pieces from the existing project. You might find
an unexpected dependency that inhibits correct behavior.
One of the techniques that helped me was to dump the list data at
critical points to ensure that the list was in the expected state. I
facilitated this by using JUnit to populate the backing store, then
called appropriate routines in the System Under Test. In your case that
would be a JUnit test calling whatever routine then calls
batchTable.setRowData().
Once I had that under control, I added a menu item that called that same
logic, but permitted the additional step of display update. That way, I
could watch the behavior using development mode. I uncovered the
requirement to refresh the display after the browser update, after the
list update.
I could be completely wrong, in that, like phlogiston, my theory is a
completely inaccurate description of the actual behavior.
Bueno Suerte.
>
>
>
> On Aug 19, 4:16 pm, Jeffrey Chimene <jchim...@gmail.com> 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<jchim...@gmail.com> 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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
