AbstractTableModel [Resolvido]

Amigo vou te enviar um exemplo simples de tablemodel;

import beans.Customer;
import java.util.ArrayList;
import java.util.List;
import javax.swing.table.AbstractTableModel;

public class CustomerTableModel extends AbstractTableModel {

    private String[] columns;
    private List<Customer> list;

    public CustomerTableModel() {
        this.columns = new String[]{"Code", "Name", "Birthday"};
        this.list = new ArrayList<Customer>();
    }

    public CustomerTableModel(List<Customer> list) {
        this.columns = new String[]{"Code", "Name", "Birthday"};
        this.list = list;
    }

    public int getRowCount() {
        return this.list.size();
    }

    public int getColumnCount() {
        return this.columns.length;
    }
    
    @Override
    public String getColumnName(int index) {
        return this.columns[index];
    }

    public Object getValueAt(int rowIndex, int columnIndex) {
        Customer customer = get(rowIndex);
        switch (columnIndex) {
            case 0: return customer.getCode();//if column 0 (code)
            case 1: return customer.getName();//if column 1 (name)
            case 2: return customer.getBirthday();//if column 2 (birthday)
            default : return null;
        }
    }

    public Customer get(int index) {
        return this.list.get(index);
    }

    public boolean remove(Customer customer) {
        boolean result = this.list.remove(customer);
        this.fireTableDataChanged();//update JTable
        return result;
    }

    public void add(Customer customer) {
        this.list.add(customer);
        this.fireTableDataChanged();//update JTable
    }

}

Sim, é isso.

É possível, mas não recomendável. No fundo, é mais ou menos o que o Default faz. O grande poder do TableModel personalizado está justamente no fato dele trabalhar com sua classe de negócio, e não com uma outra classe que exigirá casts.

Se você está falando o fireTableDataChanged, sim, é necessário. E o comando que o model usa para avisar o JTable que o conteúdo da tabela mudou. Mas o ideal é usar o fireTableRowsDeleted, que avisa sobre uma linha só. O fireTableDataChanged não diz a tabela onde foi a mudança, o que força ela a se atualizar inteira. Use-o apenas quanto todos os dados mudarem de uma só vez.

Mesmo caso do remove. Mas o ideal seria lançar o evento com fireTableRowsInserted. Esse fire faz com que o model dispare um evento, que é o mesmo capturado caso você registre um TableModelListener.

Sim, é isso.

É possível, mas não recomendável. No fundo, é mais ou menos o que o Default faz. O grande poder do TableModel personalizado está justamente no fato dele trabalhar com sua classe de negócio, e não com uma outra classe que exigirá casts.

Se você está falando o fireTableDataChanged, sim, é necessário. E o comando que o model usa para avisar o JTable que o conteúdo da tabela mudou. Mas o ideal é usar o fireTableRowsDeleted, que avisa sobre uma linha só. O fireTableDataChanged não diz a tabela onde foi a mudança, o que força ela a se atualizar inteira. Use-o apenas quanto todos os dados mudarem de uma só vez.

Mesmo caso do remove. Mas o ideal seria lançar o evento com fireTableRowsInserted. Esse fire faz com que o model dispare um evento, que é o mesmo capturado caso você registre um TableModelListener.

Bom dia,

Murilo_Ferreira, com leitura tópico, e acompanhando seu código, comparando com o meu, foi possivel “visualizar” algumas coisas que não havia, entendido.

Desse exemplo passado, gostaria de uma outra informação, se possivel. A atualização, de informações após alguma alteração da JTable, é executada rapidamente?

Nota: Minhas tabelas não, vão manipular mais que 30-50 itens, devido o foco do aplicativo não exigir resultados maiores que esse, numero de linhas.

Viny_Godoy, pelo que entendi, existem metodos especificos, para implementar em cada situação: update, delete e insert; O ideal é usar cada um desses, para reduzir, o esforço de processamento, durante a atualização da tabela, instanciada. Nesses metodos, é necessário informar, a linha a ser “redesenhada”.

Para obter essas linhas, acabei iniciando a implementação, ListSelectionListener, através do codigo abaixo, pelo que havia entendido, a linha selecionada, durante a manipulação da JTable, seria passado através da implementação desse código. É isso mesmo?

public void valueChanged(ListSelectionEvent e) {  
    throw new UnsupportedOperationException("Not supported yet.");  
}

Obrigado pela ajuda que me deram, até o momento já dilui muitas duvidas, com todas as informações passadas.

[]s

Instantaneamente. Mas a JTable só mexe com a View. Se você está falando de alterações em banco, quem deve fazer isso é a tela, pedindo para o DAO.

Isso mesmo.

Não é necessário. A maior parte das vezes, você irá saber a linha que você mesmo atualizou. Por exemplo, considere uma função de inserção. Ela irá inserir ao final do List do objeto, portanto, a linha inserida será igual ao size()-1 da sua lista (a última).

A remoção é um pouco mais chata. Talvez você precise procurar o indexOf de cada elemento a ser removido, se for uma remoção pelo objeto. Se for uma remoção por índices, aí o método table.getSelectedRows() te indicará que linhas estão selecionadas, e é nelas que você deve disparar o evento do model.

Obrigado, pela força, até o momento

O View, citado em sua resposta, está relacionado ao: Control, Model e View. Usado no desenvolvimento multi-camada?

[]s

Sim.

Não é a toa que o TableModel chama-se TableModel.
Ele descreve ao JTable que dados devem ser exibidos, portanto, ele é uma espécie de model.

A view são as janelas, o JTable, os JTextFields e demais componentes usados para efetivamente exibir os dados.

O Swing segue um padrão simplificado do MVC. É simplificado pois como a aplicação e o modelo estão no mesmo PC, a camada de controle é muito transparente, praticamente inexistente.

Perfeito Muito obrigado

[]s