Open GoogleCodeExporter opened 9 years ago
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
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
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
<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
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
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
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
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
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
Original comment by sumitcha...@google.com
on 2 May 2008 at 5:47
Original comment by sumitcha...@google.com
on 2 May 2008 at 5:50
Original issue reported on code.google.com by
tobeerr...@gmail.com
on 31 Oct 2007 at 8:07