Results 1 to 7 of 7
  1. #1
    NateLogan is offline Member
    Join Date
    Mar 2010
    Posts
    2
    Rep Power
    0

    Default TableModelListener

    How do I exactly use TableModelListener? I think I misunderstood something I I can't figure out what I'm doing wrong.

    When is the table event issued? Are the fireTable* methods fired automatically?

    Very simple example of my code (one of many):
    Java Code:
    public class MyTableModel extends AbstractTableModel implements TableModel, TableModelListener{
        
        public MyTableModel() {
            this.addTableModelListener(this);
        }
    
        public int getRowCount() {
            return 5;
        }
    
        public int getColumnCount() {
            return 3;
        }
    
        @Override
        public boolean isCellEditable(int rowIndex, int columnIndex) {
            return true;
        }
       
        public Object getValueAt(int rowIndex, int columnIndex) {
            return "value";
        }
    
        public void tableChanged(TableModelEvent e) {
            System.out.println("tChanged");
        }
    
    }

  2. #2
    camickr is offline Senior Member
    Join Date
    Jul 2009
    Posts
    1,233
    Rep Power
    6

    Default

    When is the table event issued? Are the fireTable* methods fired automatically?
    The TableModel is responsible for invoking the fireXXX methods. If you want to see how this is done then look at the source code for the DefaultTableModel. The source code comes with the JDK in a src.zip file.

    Generally you can use the DefaultTableModel until you are more familiar with how the table and model work together.

    For an example of using a TableModelListener see: Swing - JTable cell editing

  3. #3
    Steve11235's Avatar
    Steve11235 is offline Senior Member
    Join Date
    Dec 2008
    Posts
    1,046
    Rep Power
    7

    Default

    Typically, you implement the TableModel, providing methods to update the data. These methods should call the fireTable* methods whenever the data changes. Note that you can use the most simple version of these methods all the time in most cases.

  4. #4
    NateLogan is offline Member
    Join Date
    Mar 2010
    Posts
    2
    Rep Power
    0

    Default

    I see, I somehow forget about DefaultTableModel. Shame on me.

    Still, I am not sure how to efficiently use TableModel without the need of duplicating of user data. Storing them inside of TableModel seems quiet wrong and having TableModel inside of data object is also strange in certain applications.

  5. #5
    Fubarable's Avatar
    Fubarable is offline Moderator
    Join Date
    Jun 2008
    Posts
    19,316
    Blog Entries
    1
    Rep Power
    26

    Default

    Quote Originally Posted by NateLogan View Post
    I see, I somehow forget about DefaultTableModel. Shame on me.

    Still, I am not sure how to efficiently use TableModel without the need of duplicating of user data. Storing them inside of TableModel seems quiet wrong and having TableModel inside of data object is also strange in certain applications.
    Then it sounds like you're heading towards using the Abstract version, but perhaps you can cut your teeth first on the Default.

  6. #6
    camickr is offline Senior Member
    Join Date
    Jul 2009
    Posts
    1,233
    Rep Power
    6

    Default

    Still, I am not sure how to efficiently use TableModel without the need of duplicating of user data
    Why do you think you have to duplicate user data? The DefaultTableModel stores its data in a Vector of Vectors. So if you initially load your data (where ever it comes from) into the Vectors then you are not duplicating data.

    What is your specific requirement?

  7. #7
    Steve11235's Avatar
    Steve11235 is offline Senior Member
    Join Date
    Dec 2008
    Posts
    1,046
    Rep Power
    7

    Default

    Actually, duplication of data may be the "right" solution. The reason is that view components, like a table, must hold their own data. Each component implements its own MVC model. However, there is no reason you have to base your model on the models of each component. Sometimes, it's better to implement the component model separately and to let the controller shuttle data between the view component and your model.

    In other words, your data model holds the "real" data. The controller copies some of the data to the view component for display. Later, the controller can copy data from the view component back to the data model, which should validate the changes and either persist them or issue error messages.

    You can build the view component model around the actual data model, so that there is no duplication. However, for larger applications, this approach can become very difficult to work with.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •