Re: Funny behaviour in CellTable.
On 9/1/2011 5:55 AM, jsg wrote: Yes, the critical call which makes it work in your last example is the dataProvider.setList() . This seems to me to be unintuitive because the whole notion of a provider and view is that when your model changes, the provider is informed and updates the views accordingly. Here not only does the provider have to be reconnected to a model by setList() , severing connection with the previous model (which means it has to redraw rows that haven't changed), but the CellTable itself has to be notified individually. There might be no mechanism currently in the provider to test for row data changes, but the way the user has to call this API seems to me to be all wrong. I guess we leave this here. Thanks for your help. I was looking at this code a few days ago. I don't remember if I referenced the following from the CellTable javadoc It turns out that the important step to invalidating THE SAME CELL is the clearViewData() call, not the dataProvider.setList() call. /* * Clear the view data. The view data contains the pending change and * allows the table to render with the pending value until the data is * committed. If the data is committed into the object, the view data * is automatically cleared out. If the data is not committed because * it is invalid, you must delete. */ nameCell.clearViewData(KEY_PROVIDER.getKey(object)); On Aug 23, 5:38 pm, Jeffrey Chimenejchim...@gmail.com wrote: On 8/23/2011 8:33 AM, Jeffrey Chimene wrote: On 8/23/2011 8:19 AM, Jeffrey Chimene wrote: On 8/23/2011 2:38 AM, jsg wrote: Let me get this straight, you run the code in dev mode, you set the endTime TextInputCell to a value, let's say 14:18 and on pushing Enter or leaving focus, the code parses the value and updates it to 15:19 (as the + 1 is set in the FieldUpdater) and then this displays immediately on your machine?? Yes. In fact, there are other actions that can occur after pressing enter. For example, the user could choose to delete a row in the table. You can review the code athttp://code.google.com/p/gwt-sked, or try out the project athttp://jchimene.com/sked.htmlThe specific example you cite can be demonstrated by the following actions: 0) Select Load sample schedule under the Helpmenu 1) Click a cell in the Likely column for a specific activity 2) Set the value to zero. Press enter to blur the cell. Notice the adjacent cell values are set to zero. 3) Enter a non-zero value in the Likely cell. Press Enter to blur the cell, the other cells are immediately updated. I'm happy to supply annotations or answer questions. You might have already done this, but try compiling the code in PRETTY mode and run it using a browser that will display the Javascript console (I usually use Firefox + Firebug). See if you have any interesting runtime errors. Thinking further on your question, it occurs to me that you're asking: how do I update THE SAME CELL. I have to admit this caused some consternation. For a while, I considered sub-classing EditTextCell, an approach I abandoned as unworkable. The Predecessor column implements this same cell update behavior to correct data entry errors that might introduce a network cycle. The apropos code is in ActivityPresenter.onPredecessorChange() Demonstrate as follows: 0) Select Load sample schedule under the Helpmenu 1) Click a cell in the Predecessor column for a specific activity 2) Enter a comma-separated list that includes that row's ID. For example, if you choose activity C,enter the string 1,3 as that activity's predecessor list. Press enter to blur the cell. Notice that the string ,3 is removed from the value. The action sequence is: 0) Update the Data Provider list: dataProvider.setList(new ArrayListActivity(scheduler.getValues())); dataProvider.flush(); //Maybe not needed? 1) Update the view cellTable.setRowData(list); cellTable.redraw(); -- 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.
Re: Funny behaviour in CellTable.
Yes, the critical call which makes it work in your last example is the dataProvider.setList() . This seems to me to be unintuitive because the whole notion of a provider and view is that when your model changes, the provider is informed and updates the views accordingly. Here not only does the provider have to be reconnected to a model by setList() , severing connection with the previous model (which means it has to redraw rows that haven't changed), but the CellTable itself has to be notified individually. There might be no mechanism currently in the provider to test for row data changes, but the way the user has to call this API seems to me to be all wrong. I guess we leave this here. Thanks for your help. On Aug 23, 5:38 pm, Jeffrey Chimene jchim...@gmail.com wrote: On 8/23/2011 8:33 AM, Jeffrey Chimene wrote: On 8/23/2011 8:19 AM, Jeffrey Chimene wrote: On 8/23/2011 2:38 AM, jsg wrote: Let me get this straight, you run the code in dev mode, you set the endTime TextInputCell to a value, let's say 14:18 and on pushing Enter or leaving focus, the code parses the value and updates it to 15:19 (as the + 1 is set in the FieldUpdater) and then this displays immediately on your machine?? Yes. In fact, there are other actions that can occur after pressing enter. For example, the user could choose to delete a row in the table. You can review the code athttp://code.google.com/p/gwt-sked, or try out the project athttp://jchimene.com/sked.htmlThe specific example you cite can be demonstrated by the following actions: 0) Select Load sample schedule under the Helpmenu 1) Click a cell in the Likely column for a specific activity 2) Set the value to zero. Press enter to blur the cell. Notice the adjacent cell values are set to zero. 3) Enter a non-zero value in the Likely cell. Press Enter to blur the cell, the other cells are immediately updated. I'm happy to supply annotations or answer questions. You might have already done this, but try compiling the code in PRETTY mode and run it using a browser that will display the Javascript console (I usually use Firefox + Firebug). See if you have any interesting runtime errors. Thinking further on your question, it occurs to me that you're asking: how do I update THE SAME CELL. I have to admit this caused some consternation. For a while, I considered sub-classing EditTextCell, an approach I abandoned as unworkable. The Predecessor column implements this same cell update behavior to correct data entry errors that might introduce a network cycle. The apropos code is in ActivityPresenter.onPredecessorChange() Demonstrate as follows: 0) Select Load sample schedule under the Helpmenu 1) Click a cell in the Predecessor column for a specific activity 2) Enter a comma-separated list that includes that row's ID. For example, if you choose activity C,enter the string 1,3 as that activity's predecessor list. Press enter to blur the cell. Notice that the string ,3 is removed from the value. The action sequence is: 0) Update the Data Provider list: dataProvider.setList(new ArrayListActivity(scheduler.getValues())); dataProvider.flush(); //Maybe not needed? 1) Update the view cellTable.setRowData(list); cellTable.redraw(); -- 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.
Re: Funny behaviour in CellTable.
Let me get this straight, you run the code in dev mode, you set the
endTime TextInputCell to a value, let's say 14:18 and on pushing Enter
or leaving focus, the code parses the value and updates it to 15:19
(as the + 1 is set in the FieldUpdater) and then this displays
immediately on your machine??
On Aug 22, 10:46 pm, Jeff Chimene jchim...@gmail.com wrote:
On 08/22/2011 01:13 PM, jsg wrote:
We haven't tried it in compiled mode yet, but it definitely doesn't
work in dev mode for us.
Alright - at least that's better than what was happening on my side. The
problem was that in dev mode, the NPE exception was correctly caught in
the try/catch block.
In compiled mode, the NPE doesn't exist, it's caught as a
JavaScriptException.
My code example was intended to demonstrate that when MyVariable is
null, then the catch of the NPE doesn't happen in compiled mode.
I was hoping that you were seeing the same thing: the refresh() succeeds
in dev mode, but not in compiled mode because the NPE can't be caught in
compiled mode. The refresh() never got called because of the NPE.
In your case, it's not working in dev mode. In that case, what do you
see when the presenter does not refresh?
Also, is the celltable setup to allow focus to one cell? If so, does the
refresh occur if you set focus to a cell, the blur out of that cell? One
thing I was going to try before I figured out the NPE, was to subclass
CellTable, and start hooking into some of the protected() routines.
What is your code that returns a value? Neither the
FieldUpdate.update() nor the ScheduledCommand.execute() expects a
value back so I'm a little perplexed as to your context? And what is
MyVariable?
Sorry if I've just lost the plot.
On Aug 22, 8:47 pm, Jeff Chimene jchim...@gmail.com wrote:
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 Chimenejchim...@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
Re: Funny behaviour in CellTable.
On 8/23/2011 2:38 AM, jsg wrote:
Let me get this straight, you run the code in dev mode, you set the
endTime TextInputCell to a value, let's say 14:18 and on pushing Enter
or leaving focus, the code parses the value and updates it to 15:19
(as the + 1 is set in the FieldUpdater) and then this displays
immediately on your machine??
Yes.
In fact, there are other actions that can occur after pressing enter.
For example, the user could choose to delete a row in the table.
You can review the code at http://code.google.com/p/gwt-sked, or try out
the project at http://jchimene.com/sked.html The specific example you
cite can be demonstrated by the following actions:
0) Select Load sample schedule under the Helpmenu
1) Click a cell in the Likely column for a specific activity
2) Set the value to zero. Press enter to blur the cell. Notice the
adjacent cell values are set to zero.
3) Enter a non-zero value in the Likely cell. Press Enter to blur the
cell, the other cells are immediately updated.
I'm happy to supply annotations or answer questions.
You might have already done this, but try compiling the code in PRETTY
mode and run it using a browser that will display the Javascript console
(I usually use Firefox + Firebug). See if you have any interesting
runtime errors.
On Aug 22, 10:46 pm, Jeff Chimenejchim...@gmail.com wrote:
On 08/22/2011 01:13 PM, jsg wrote:
We haven't tried it in compiled mode yet, but it definitely doesn't
work in dev mode for us.
Alright - at least that's better than what was happening on my side. The
problem was that in dev mode, the NPE exception was correctly caught in
the try/catch block.
In compiled mode, the NPE doesn't exist, it's caught as a
JavaScriptException.
My code example was intended to demonstrate that when MyVariable is
null, then the catch of the NPE doesn't happen in compiled mode.
I was hoping that you were seeing the same thing: the refresh() succeeds
in dev mode, but not in compiled mode because the NPE can't be caught in
compiled mode. The refresh() never got called because of the NPE.
In your case, it's not working in dev mode. In that case, what do you
see when the presenter does not refresh?
Also, is the celltable setup to allow focus to one cell? If so, does the
refresh occur if you set focus to a cell, the blur out of that cell? One
thing I was going to try before I figured out the NPE, was to subclass
CellTable, and start hooking into some of the protected() routines.
What is your code that returns a value? Neither the
FieldUpdate.update() nor the ScheduledCommand.execute() expects a
value back so I'm a little perplexed as to your context? And what is
MyVariable?
Sorry if I've just lost the plot.
On Aug 22, 8:47 pm, Jeff Chimenejchim...@gmail.com wrote:
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, jchimenejchim...@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, jsgjgerso...@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 Chimenejchim...@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
Re: Funny behaviour in CellTable.
On 8/23/2011 8:19 AM, Jeffrey Chimene wrote:
On 8/23/2011 2:38 AM, jsg wrote:
Let me get this straight, you run the code in dev mode, you set the
endTime TextInputCell to a value, let's say 14:18 and on pushing Enter
or leaving focus, the code parses the value and updates it to 15:19
(as the + 1 is set in the FieldUpdater) and then this displays
immediately on your machine??
Yes.
In fact, there are other actions that can occur after pressing enter.
For example, the user could choose to delete a row in the table.
You can review the code at http://code.google.com/p/gwt-sked, or try
out the project at http://jchimene.com/sked.html The specific example
you cite can be demonstrated by the following actions:
0) Select Load sample schedule under the Helpmenu
1) Click a cell in the Likely column for a specific activity
2) Set the value to zero. Press enter to blur the cell. Notice the
adjacent cell values are set to zero.
3) Enter a non-zero value in the Likely cell. Press Enter to blur
the cell, the other cells are immediately updated.
I'm happy to supply annotations or answer questions.
You might have already done this, but try compiling the code in PRETTY
mode and run it using a browser that will display the Javascript
console (I usually use Firefox + Firebug). See if you have any
interesting runtime errors.
Thinking further on your question, it occurs to me that you're asking:
how do I update THE SAME CELL. I have to admit this caused some
consternation. For a while, I considered sub-classing EditTextCell, an
approach I abandoned as unworkable.
The Predecessor column implements this same cell update behavior to
correct data entry errors that might introduce a network cycle. The
apropos code is in ActivityPresenter.onPredecessorChange()
Demonstrate as follows:
0) Select Load sample schedule under the Helpmenu
1) Click a cell in the Predecessor column for a specific activity
2) Enter a comma-separated list that includes that row's ID. For
example, if you choose activity C,enter the string 1,3 as that
activity's predecessor list. Press enter to blur the cell. Notice that
the string ,3 is removed from the value.
On Aug 22, 10:46 pm, Jeff Chimenejchim...@gmail.com wrote:
On 08/22/2011 01:13 PM, jsg wrote:
We haven't tried it in compiled mode yet, but it definitely doesn't
work in dev mode for us.
Alright - at least that's better than what was happening on my side.
The
problem was that in dev mode, the NPE exception was correctly caught in
the try/catch block.
In compiled mode, the NPE doesn't exist, it's caught as a
JavaScriptException.
My code example was intended to demonstrate that when MyVariable is
null, then the catch of the NPE doesn't happen in compiled mode.
I was hoping that you were seeing the same thing: the refresh()
succeeds
in dev mode, but not in compiled mode because the NPE can't be
caught in
compiled mode. The refresh() never got called because of the NPE.
In your case, it's not working in dev mode. In that case, what do you
see when the presenter does not refresh?
Also, is the celltable setup to allow focus to one cell? If so, does
the
refresh occur if you set focus to a cell, the blur out of that cell?
One
thing I was going to try before I figured out the NPE, was to subclass
CellTable, and start hooking into some of the protected() routines.
What is your code that returns a value? Neither the
FieldUpdate.update() nor the ScheduledCommand.execute() expects a
value back so I'm a little perplexed as to your context? And what is
MyVariable?
Sorry if I've just lost the plot.
On Aug 22, 8:47 pm, Jeff Chimenejchim...@gmail.com wrote:
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, jchimenejchim...@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, jsgjgerso...@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
Re: Funny behaviour in CellTable.
On 8/23/2011 8:33 AM, Jeffrey Chimene wrote: On 8/23/2011 8:19 AM, Jeffrey Chimene wrote: On 8/23/2011 2:38 AM, jsg wrote: Let me get this straight, you run the code in dev mode, you set the endTime TextInputCell to a value, let's say 14:18 and on pushing Enter or leaving focus, the code parses the value and updates it to 15:19 (as the + 1 is set in the FieldUpdater) and then this displays immediately on your machine?? Yes. In fact, there are other actions that can occur after pressing enter. For example, the user could choose to delete a row in the table. You can review the code at http://code.google.com/p/gwt-sked, or try out the project at http://jchimene.com/sked.html The specific example you cite can be demonstrated by the following actions: 0) Select Load sample schedule under the Helpmenu 1) Click a cell in the Likely column for a specific activity 2) Set the value to zero. Press enter to blur the cell. Notice the adjacent cell values are set to zero. 3) Enter a non-zero value in the Likely cell. Press Enter to blur the cell, the other cells are immediately updated. I'm happy to supply annotations or answer questions. You might have already done this, but try compiling the code in PRETTY mode and run it using a browser that will display the Javascript console (I usually use Firefox + Firebug). See if you have any interesting runtime errors. Thinking further on your question, it occurs to me that you're asking: how do I update THE SAME CELL. I have to admit this caused some consternation. For a while, I considered sub-classing EditTextCell, an approach I abandoned as unworkable. The Predecessor column implements this same cell update behavior to correct data entry errors that might introduce a network cycle. The apropos code is in ActivityPresenter.onPredecessorChange() Demonstrate as follows: 0) Select Load sample schedule under the Helpmenu 1) Click a cell in the Predecessor column for a specific activity 2) Enter a comma-separated list that includes that row's ID. For example, if you choose activity C,enter the string 1,3 as that activity's predecessor list. Press enter to blur the cell. Notice that the string ,3 is removed from the value. The action sequence is: 0) Update the Data Provider list: dataProvider.setList(new ArrayListActivity(scheduler.getValues())); dataProvider.flush(); //Maybe not needed? 1) Update the view cellTable.setRowData(list); cellTable.redraw(); -- 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.
Re: Funny behaviour in CellTable.
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.
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 Chimenejchim...@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.
Re: Funny behaviour in CellTable.
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 Chimenejchim...@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.
Re: Funny behaviour in CellTable.
We haven't tried it in compiled mode yet, but it definitely doesn't
work in dev mode for us.
What is your code that returns a value? Neither the
FieldUpdate.update() nor the ScheduledCommand.execute() expects a
value back so I'm a little perplexed as to your context? And what is
MyVariable?
Sorry if I've just lost the plot.
On Aug 22, 8:47 pm, Jeff Chimene jchim...@gmail.com wrote:
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 Chimenejchim...@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
Re: Funny behaviour in CellTable.
On 08/22/2011 01:13 PM, jsg wrote:
We haven't tried it in compiled mode yet, but it definitely doesn't
work in dev mode for us.
Alright - at least that's better than what was happening on my side. The
problem was that in dev mode, the NPE exception was correctly caught in
the try/catch block.
In compiled mode, the NPE doesn't exist, it's caught as a
JavaScriptException.
My code example was intended to demonstrate that when MyVariable is
null, then the catch of the NPE doesn't happen in compiled mode.
I was hoping that you were seeing the same thing: the refresh() succeeds
in dev mode, but not in compiled mode because the NPE can't be caught in
compiled mode. The refresh() never got called because of the NPE.
In your case, it's not working in dev mode. In that case, what do you
see when the presenter does not refresh?
Also, is the celltable setup to allow focus to one cell? If so, does the
refresh occur if you set focus to a cell, the blur out of that cell? One
thing I was going to try before I figured out the NPE, was to subclass
CellTable, and start hooking into some of the protected() routines.
What is your code that returns a value? Neither the
FieldUpdate.update() nor the ScheduledCommand.execute() expects a
value back so I'm a little perplexed as to your context? And what is
MyVariable?
Sorry if I've just lost the plot.
On Aug 22, 8:47 pm, Jeff Chimene jchim...@gmail.com wrote:
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 Chimenejchim...@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
Re: Funny behaviour in CellTable.
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 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 Chimenejchim...@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.
Re: Funny behaviour in CellTable.
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.
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.
Re: Funny behaviour in CellTable.
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 Chimenejchim...@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.
Re: Funny behaviour in CellTable.
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 Chimenejchim...@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.
Re: Funny behaviour in CellTable.
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 Chimenejchim...@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.
Funny behaviour in CellTable.
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 -- 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.
Re: Funny behaviour in CellTable.
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.
