On 08/22/2011 02:34 AM, jsg wrote:
> Hi Jeff,
>
> Given both our experience and your confirmation, I'm going to file a
> bug report in case this thread isn't being noticed.
>
> Thanks for your effort.
>
> On Aug 22, 12:46 am, jchimene <jchim...@gmail.com> wrote:
>> 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.
The answer (at least in my case), was the following:
try {
switch (MyVariable) {
case 1: return 1;
case 2: return 2;
.
.
.
} catch (NullPointerException e) {
return 1;
}
In compiled mode, the try/catch doesn't, so the Javascript was failing
at the switch expression evaluation. So, the side-effect was that the
display was never refresh()-ing
Try compiling in PRETTY mode and checking for exceptions.
>>
>> On Aug 19, 8:17 am, jsg <jgerso...@gmail.com> 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 <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.
