Re: recursive Observer, or TableModelListener?
thufir wrote:
How do I tie them together so that changes to the db propagate up to the
JTable?
How would the TableModelListener,
http://java.sun.com/docs/books/tutorial/uiswing/components/
table.html#modelchange
,work for this situation?
TableModelListener is correct. Don't use Observer and Observable
classes. Those are generic classes that exist outside of Swing. Use
the specific interface that Swing implements for the observer pattern,
which Swing calls *Listeners, like TableModelListener.
There are three main parts to a GUI like Swing. They are: the Model,
the View and the Controller ("MVC"). The Controller is the thing that
does the updating. The View never updates the Model directly, or
vice-versa.
Listeners are Controllers, so do your updating there. Listeners are
started by the View, when the user generates an event. Don't let this
bug you. Listeners are Controllers, they aren't part of the View.
@SuppressWarnings({"serial", "unchecked"})
public class CarModel extends DefaultTableModel implements Observer {
Use TableModelListner, not Observer.
Also, your model should not be a Controller. Make a separate object for
this. I know the example in the Swing tutorial does make the Model the
Controller also; they're just being brief. (Too brief, imho.) This is
one reason I like O'Reilly's _Learning Java_, because they actually
explain the MVC stuff and show how to implement it correctly.
@SuppressWarnings({"unchecked"})
public class Model extends Observable {
The DefaultTableModel already is an observable (small o). Use the
add*Listener method to set up an observer for the model.
Classically, Models do not generate events, the View does. However,
this model is one used by the View, so I think this counts as being
generated by the view, even though the object says "model".
Controllers act like traditional procedural functions (in my opinion;
this here is my own theory of how MVC works). It takes input (the
event), reads data (the model) and processes it and writes it out (send
to database). That's a really easy algorithm that could be implemented
here, and is very simple. That's the power of MVC. It breaks up what
could be a very complicated problem (as I think you are finding) and
decomposes it into very manageable bits. Divide and conquer.