Visualizzazione dei risultati da 1 a 3 su 3
  1. #1
    Utente di HTML.it
    Registrato dal
    Feb 2018
    Messaggi
    18

    Alcuni problemi con la jtable

    Salve a tutti ragazzi. Sto sviluppando un gestionale da portare in un esame universitario e sia io che il mio collega abbiamo alcuni problemi nell'implementare specifiche funzioni.
    Mentre lancio il programma mi connetto ad un db di mysql server con un utente senza password che ha il solo attributo di select. Ho una tabbed pane che al click mi cambia la mia jtable. Il primo problema è che il mio prof. mi ha consigliato l'uso di sql server in quanto avrei avuto una result set updatable tuttavia il return di
    codice:
    ResultSet.CONCUR_UPDATABLE 
    
    è falso dovrei settare qualcosa?
    La prima implementazione che vorrei fare è la possibilità di aggiungere un elemento direttamente dalla jtable. Quindi ho un pulsante che mi crea una riga null che è completamente vuota. Come faccio a prelevare il testo da questa riga ed eseguire la query per inserirla nel db?
    Inserisco il codice della classe Mytabe grazie in anticipo per l'aiuto.
    codice:
    public class MyTable extends JTable {
    
        private DefaultTableModel dataModel;
    
        public MyTable(Gui gui) {
            super();
    dataModel = new DefaultTableModel() {
                @Override
    public boolean isCellEditable(int row, int column) {
                    return gui.isAdmin();
    }
            };
    setModel(dataModel);
    }
    
        public void add(){
            dataModel.addRow((Object[]) null);
    dataModel.fireTableDataChanged();
    
    }
    
        public void update(ResultSet resultSet) throws SQLException {
            clear();
    //create an array of column names
    ResultSetMetaData mdata = resultSet.getMetaData();
            int colCount = mdata.getColumnCount();
    String[] colNames = new String[colCount];
            for (int i = 1; i <= colCount; i++) {
                colNames[i - 1] = mdata.getColumnName(i);
    }
            dataModel.setColumnIdentifiers(colNames);
    
    
    //now populate the data
    while (resultSet.next()) {
                Object[] rowData = new Object[colCount];
                for (int i = 1; i <= colCount; i++) {
                    switch (mdata.getColumnClassName(i)) {
                        case "java.sql.Date":
                            rowData[i - 1] = resultSet.getDate(i);
                            break;
                        case "java.lang.Integer":
                            rowData[i - 1] = resultSet.getInt(i);
                            break;
                        case "java.lang.Double":
                            rowData[i - 1] = resultSet.getDouble(i);
                            break;
                        default:
                            rowData[i - 1] = resultSet.getString(i);
                            break;
    }
                }
                dataModel.addRow(rowData);
    }
    
        }
    
        public void clear(){
            dataModel.getDataVector().removeAllElements();
    dataModel.fireTableDataChanged();
    }
    
    }
    Ultima modifica di felx; 25-01-2020 a 21:05

  2. #2
    Quote Originariamente inviata da felx Visualizza il messaggio
    Il primo problema è che il mio prof. mi ha consigliato l'uso di sql server in quanto avrei avuto una result set updatable tuttavia il return di
    codice:
    ResultSet.CONCUR_UPDATABLE 
    
    è falso dovrei settare qualcosa?
    La prima implementazione che vorrei fare è la possibilità di aggiungere un elemento direttamente dalla jtable. Quindi ho un pulsante che mi crea una riga null che è completamente vuota. Come faccio a prelevare il testo da questa riga ed eseguire la query per inserirla nel db?
    Inserisco il codice della classe Mytabe grazie in anticipo per l'aiuto.
    Innanzitutto stai usando "male" JTable e in particolare il DefaultTableModel. I metodi fireXXX in questo caso non li devi invocare tu. È già il DefaultTableModel che "sa" quando/come invocare i fireXXX appropriatamente per aggiornare la "vista" della tabella.
    I fireXXX invece vanno gestiti e invocati tipicamente quando si implementa un table model "custom", specializzato, che estende tipicamente direttamente AbstractTableModel.

    Riguardo ResultSet.CONCUR_UPDATABLE non mi è chiaro cosa vuoi fare e perché. Il ResultSet.CONCUR_UPDATABLE si può passare ai metodi createStatement/prepareStatement/prepareCall per indicare che si vuole poi ottenere dalla query un ResultSet "aggiornabile", cioè su cui si possono invocare i suoi metodi updateXXX per aggiornare i record (es. updateString, updateInt, updateDouble ecc...).
    Dove stanno nel tuo caso le invocazioni di questi updateXXX ?

    L'uso di CONCUR_UPDATABLE si utilizza di norma in modo combinato con l'altro parametro resultSetType specificando TYPE_SCROLL_INSENSITIVE oppure TYPE_SCROLL_SENSITIVE. Questo modo d'uso è stato pensato principalmente per le interfacce grafiche. In pratica si tiene il ResultSet "aperto" per molto tempo e mentre l'utente si muove avanti e indietro nella tabella e modifica le celle, il ResultSet viene aggiornato di conseguenza "al volo". È a questo che serve appunto CONCUR_UPDATABLE con TYPE_SCROLL_INSENSITIVE oppure TYPE_SCROLL_SENSITIVE.

    E comunque il supporto a CONCUR_UPDATABLE dipende anche dal driver JDBC. E per il driver Connector/J di MySQL mi pare non ci siano problemi a riguardo (ma dovrei andare a verificare, però a memoria mi pare sia assolutamente supportato).


    P.S. lo switch sul getColumnClassName è abbastanza bruttino.
    AndreaSenior Java developerSCJP 5 (91%) – SCWCD 5 (94%)
    Il mio nuovo sito-blog italiano sulla programmazione: andbin.it

  3. #3
    Utente di HTML.it
    Registrato dal
    Feb 2018
    Messaggi
    18
    Quote Originariamente inviata da andbin Visualizza il messaggio
    Innanzitutto stai usando "male" JTable e in particolare il DefaultTableModel. I metodi fireXXX in questo caso non li devi invocare tu. È già il DefaultTableModel che "sa" quando/come invocare i fireXXX appropriatamente per aggiornare la "vista" della tabella.
    I fireXXX invece vanno gestiti e invocati tipicamente quando si implementa un table model "custom", specializzato, che estende tipicamente direttamente AbstractTableModel.

    Riguardo ResultSet.CONCUR_UPDATABLE non mi è chiaro cosa vuoi fare e perché. Il ResultSet.CONCUR_UPDATABLE si può passare ai metodi createStatement/prepareStatement/prepareCall per indicare che si vuole poi ottenere dalla query un ResultSet "aggiornabile", cioè su cui si possono invocare i suoi metodi updateXXX per aggiornare i record (es. updateString, updateInt, updateDouble ecc...).
    Dove stanno nel tuo caso le invocazioni di questi updateXXX ?

    L'uso di CONCUR_UPDATABLE si utilizza di norma in modo combinato con l'altro parametro resultSetType specificando TYPE_SCROLL_INSENSITIVE oppure TYPE_SCROLL_SENSITIVE. Questo modo d'uso è stato pensato principalmente per le interfacce grafiche. In pratica si tiene il ResultSet "aperto" per molto tempo e mentre l'utente si muove avanti e indietro nella tabella e modifica le celle, il ResultSet viene aggiornato di conseguenza "al volo". È a questo che serve appunto CONCUR_UPDATABLE con TYPE_SCROLL_INSENSITIVE oppure TYPE_SCROLL_SENSITIVE.

    E comunque il supporto a CONCUR_UPDATABLE dipende anche dal driver JDBC. E per il driver Connector/J di MySQL mi pare non ci siano problemi a riguardo (ma dovrei andare a verificare, però a memoria mi pare sia assolutamente supportato).


    P.S. lo switch sul getColumnClassName è abbastanza bruttino.
    Ciao grazie mille per avermi risposto. Ho tolto le fire in effetti non ci sono differenze. Premetto di aver letto molto velocemente le doc perciò potrei dire grosse baggianate. Come avrai capito da questa classe stiamo implementando un interfaccia grafica per gestire nel nostro caso dei dipendenti. Adesso ciò che mi hai detto riguardo le rs dovrebbe essere a mio vantaggio, poiché io vorrei che ogni modifica che io faccia venga scritta immediatamente dal database my sql dal quale prendo i dati.
    P.S. Come mai non ti piace lo switch? sembrava un modo efficiente per riconoscere i tipi di dato, hai un idea migliore?

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2020 vBulletin Solutions, Inc. All rights reserved.