Load Error handeling in TableController

[GoogleCodeExporter]

The TableController should allow one to handle rpc load errors.  

I would implement this in the following way:
The TableController should be able to fire an extra event
onLoadError(Throwable error).  This would be triggered by an extra method
in the Callback function in addition to onRowsReady, say call it
onRequestFailure(Throughable caught).  This method would be triggered when
the AsyncCallback returned onError(Throwable error).  In this way, errors
could be propagated up through TableController events.  

Original issue reported on code.google.com by tobeerr...@gmail.com on 31 Oct 2007 at 8:07

[GoogleCodeExporter]

Why would you not want the RPC call to figure out what to do on failure?  As 
while
TableController is certainly built with the idea that we can use it with RPC, 
it is
not requires so I would not want to put RPC specific code in the controller.

Original comment by gwt.team...@gmail.com on 7 Nov 2007 at 2:59

• Changed state: NeedsInfo

[GoogleCodeExporter]

I see your point.  It just seems more straightforward to have one object, the
TableController, be able to report on the complete status of the table data.  
That
way, you could listen to one object's events to determine the status of the 
table. 
If the RPC call bypasses the TableController, it must fire events of its own to
notify other widgets of the error.  Then any object that needs to get the true 
status
of the table must listen to two classes.  

I don't think load errors are limited to RPC related table calls.  Its true 
that your
basic requestRows function doesn't allow for load errors because its too 
simple. 
But, anyone implementing this table system is going to extend the TableModel to 
allow
for more elaborate requests.  As soon as that happens, irregardless of the 
origin of
the data, you open yourself up to the possibility of a variety of errors.

Original comment by tobeerr...@gmail.com on 7 Nov 2007 at 3:27

[GoogleCodeExporter]

Your code definitely shouldn't bypass the TableController, I would think that 
either
your error handler would call the table controller methods or you would pass in 
a
custom table controller with your error handling routines. 

Original comment by gwt.team...@gmail.com on 7 Nov 2007 at 3:36

[GoogleCodeExporter]

<quote>...you would pass in a
custom table controller with your error handling routines. </quote>

I made a custom table controller that had a custom error handler.  I just 
implemented
what I suggested you do in the first comment.  I though that it was something 
basic
enough it should go in the distro.  I understand you want to made the 
TableController
free of RPC related stuff but I think anyone who is going to the trouble of 
using a
Table-Controller-Model paradigm will have a remote data source.  Perhaps you 
should
add new child classes RpcTableModel and RpcTableController. I have already 
written a
first draft of these classes and I'd be happy to share them if you like.  

Original comment by tobeerr...@gmail.com on 7 Nov 2007 at 8:01

[GoogleCodeExporter]

I like the idea of an onRequestFailure(Throughable caught) method in the 
Callback.

In the latest commit, TableController no longer has its own listener, so we 
could
just add  an onRequestFailure(Throughable caught) method to the TableController
itself that users can override.  The TableController will call its own
onRequestFailure if the TableModel calls onRequestFailure in the callback.

Original comment by gwt.team...@gmail.com on 7 Nov 2007 at 8:47

[GoogleCodeExporter]

Why did you remove the listener?  That kinda makes the whole issue moot, 
doesn't it?
 I guess you could register a widget with the controller to do error handling but the
event driven way compartmentalizes the dependency between classes nicely. It 
also
means you wouldn't have to extend TableController just to get an error handler. 

The event driven method generally makes it very easy to make more table 
dependent
widgets.  I'm already using the listener's onSetData event to get the rows 
Iterator
for another class.  How does the GridView get the data if it doesn't listen to 
the
tableController events?  

Original comment by tobeerr...@gmail.com on 7 Nov 2007 at 9:16

[GoogleCodeExporter]

Just the mechanism has changed, the GridView (now called PagingGrid because of
earlier feedback) now directly implements a ControllableTable interface that the
TableController issues commands to. 

You guys convinced me that adding the error handler to the main classes would 
be a
good idea, as it is actually useful in more than the RPC case. So the current 
plan is
to add  an onError method to the TableModel.Callback. The TableController would 
then
tell the views under its control that the error has happened.

Original comment by gwt.team...@gmail.com on 7 Nov 2007 at 10:11

• Changed state: Accepted

[GoogleCodeExporter]

I guess that works too. I don't really appreciate the stylistic distinction.  
They
both have the same functionality.  The only thing I can think of is it seems 
there
are more then views that could depend on the tableController.  For example, how 
does
the MutableTableModel mutate without events?  It wasn't completely clear how 
that
would be implemented anyway and I'm not using it.  Is there already a thread on 
this
stuff?  Sometimes I think I'm the only person on the internet fooling around 
with
this code. 

Original comment by tobeerr...@gmail.com on 7 Nov 2007 at 11:47

[GoogleCodeExporter]

The discussion group for these widgets is on:
http://groups.google.com/group/Google-Web-Toolkit-Contributors
check out its archive for previous conversations about bulk loading and tables. 
 The
newest changes have not been sent out for review, but probably should be.

MutableTableModel actually confused several people, so instead of TableModel and
MutableTableModel we now have ReadOnlyTableModel and TableModel.

As we have held up the first announced release of the incubator project waiting 
for
these table changes to stabilize, I don't think many external people are 
actually
using the code yet. 

Original comment by gwt.team...@gmail.com on 8 Nov 2007 at 1:55

[GoogleCodeExporter]

Original comment by sumitcha...@google.com on 2 May 2008 at 5:47

[GoogleCodeExporter]

Original comment by sumitcha...@google.com on 2 May 2008 at 5:50