Gestione internal Frame

[schumy2000]

...Ho un metodo rozzo che mi scrive in una label una variabile e in base alla varibile so che frame ho aperto e quindi mi regolo di conseguenza, ma ci sarebbe un sistema per poter gestire meglio la cosa?

ho usato anch'io quel metodo (setActionCommand n.d.a.) e mi sono trovato benissimo, almeno per l'applicazione che dovevo sviluppare che ha circa 15 JInternalFrame diversi tra loro...

[X-mac]

Ho diverse JInternalFrame, ognuna permette di inserire un certo tipo di dati. Quindi nell'actionSalva per me è importante sapere che dati sto trattando e in che tabella del db iserirli. Per fare ciò gestisco con il valore della label. Se c'è un sistema più carino preferisco.

Già che ci siamo ho cambiato il metodo getIsin(), in questo modo

 public  String[] getDatiForm(){
       
       String DatiForm [] = null;
       DatiForm[0]= jFxIsin.getText().trim();
       DatiForm[1]= jFxCodice.getText().trim();
       DatiForm[2]= jFxAzione.getText().trim();
       DatiForm[3]= jFxWeb.getText().trim();
       DatiForm[4]= jCmbMercato.getSelectedItem().toString().trim();
       DatiForm[5]= jCmbPaese.getSelectedItem().toString().trim();
       
       return DatiForm;
   }

però nell'actionPerformed ho un po' di problemi:

 if("Azioni".equals(Form)&"Nuovo".equals(Stato)){
            
        AzioniInternalFrame frame = (AzioniInternalFrame) deskTop.getSelectedFrame();


            if (frame != null) {
            sql = "insert into tb_Azioni (azisin, azcodaz,azazione, azpaese, azmercato) values(?,?,?,?,?)";
              
            String Vettore[] = null;
            int i = frame.getDatiForm().lenght;
            for(int h=0; h<=1; h++){
                Vettore[h]= frame.getDatiForm()[h];
            }
           
              cb.PreparedStatement(sql, Vettore); //questo è un mio metedo per fare l'insert
            }


       }

il problema è che non riesco a leggere i dati di frame.getDatiForm()[h];

[schumy2000]

Certo, questo perche non inizializzi vettore
fai così:

  String Vettore[] = null;  
  int i = frame.getDatiForm().lenght;  
  Vettore=new String[i];
  for(int h=0; h<=1; h++){      
     Vettore[h]= frame.getDatiForm()[h];  
   }

Ciao

[andbin]

Già che ci siamo ho cambiato il metodo getIsin(), in questo modo

 public  String[] getDatiForm(){
       
       String DatiForm [] = null;
       DatiForm[0]= jFxIsin.getText().trim();
       DatiForm[1]= jFxCodice.getText().trim();
       DatiForm[2]= jFxAzione.getText().trim();
       DatiForm[3]= jFxWeb.getText().trim();
       DatiForm[4]= jCmbMercato.getSelectedItem().toString().trim();
       DatiForm[5]= jCmbPaese.getSelectedItem().toString().trim();
       
       return DatiForm;
   }

No, non è una bella soluzione. I dati non hanno più "nome" ma un indice. Già solo il fatto che "guardando" quel ciclo for uno non è in grado subito di capire quale dato è quello i-esimo preso effettivamente e se è coerente con il campo i-esimo indicato nella stringa sql.

La cosa si può (e si dovrebbe) risolvere nell'ottica object-oriented.

Hai diverse classi di internal frame es. InternalFrameA, InternalFrameB, ecc.... Sarebbe bene che tutte avessero un tuo tipo in comune (oltre ovviamente a JInternalFrame). Quindi che estendono una tua classe base (che deriva da JInternalFrame) o implementano una tua certa interfaccia. Tra poco capirai il perché.

Questo tipo "comune" potrebbe avere un metodo:

public DataSaver getDataSaver()

dove DataSaver potrebbe essere una interfaccia o una classe astratta.

Avrai quindi N implementazioni di DataSaver, es. DataSaverA, DataSaverB, ecc....

Nel InternalFrameA avrai quindi un override di getDataSaver che fa una cosa del genere:

public DataSaver getDataSaver() {
    DataSaverA saver;
    // ... qui istanzi un DataSaverA, gli passi i dati specifici che DataSaverA ovviamente
    // deve "sapere" quali/quanti sono.
    // Tramite costruttore o metodi setter (non ha importanza ora)

    return saver;
}

DataSaver avrà un metodo es.:

void save() throws BlaBla

Ogni implementazione di DataSaver "sa" quale sql usare con quali dati specifici e farà la insert.
Visto che ci sono cose in comune (es. la creazione di un PreparedStatement) e altro, è facile pensare che DataSaver sia una classe astratta, che ha già un comportamento "base", solo specializzato nelle sottoclassi.

A quel punto dove gestisci l'evento è banale:

InternalFrameBase frame = (InternalFrameBase) deskTop.getSelectedFrame();

if (frame != null) {
    DataSaver saver = frame.getDataSaver();
    saver.save();   // handle eccezioni ovviamente, ecc.....
}

Come vedi qui non cambia più nulla! Non ci sono più switch o catene di if.

L'importante è che comprendi l'aspetto generale e la visione più object-oriented di questa soluzione.

[X-mac]

Allora ho creato una interfaccia

public interface DataSaver {
void save();
}

estendo i miei JInternalFrame con questa interfaccia....
Quando faccio l'ovveraide del metodo nell'internal frame passo i valori del form?

[andbin]

Allora ho creato una interfaccia

public interface DataSaver {
void save();
}

estendo i miei JInternalFrame con questa interfaccia....

No, secondo quanto ho detto prima, non sono gli internal frame che implementano DataSaver !! E comunque, sempre come ho detto, è (quasi) sicuramente più utile che DataSaver sia una classe "astratta".

Ok, rifaccio l'esempio con le persone:

Questa di seguito è la "base", che è generale:

public abstract class DataSaver {
    public void save() throws SQLException {
        // MOLTO abbozzato!
        // ... ottiene la Connection ...
        // ... eventuali setup su Connection ...

        executeSave(connection);

        // ... commit o rollback, chiusura connection ...
        // ... eventuale log, ecc...
    }

    protected abstract void executeSave(Connection conn) throws SQLException;
}

public abstract class InternalFrameBase extends JInternalFrame {
    // costruttore/i (se necessari)
    // ....

    public abstract DataSaver getDataSaver();
}

Queste di seguito sono le implementazioni per la gestione di una "persona":

public class InternalFramePersona extends InternalFrameBase {
    // ... campi componenti gui ...
    // ......costruttore/i, altro, ecc....

    public DataSaver getDataSaver() {
        DataSaverPersona saver = new DataSaverPersona();
        saver.setNome(nomeTextField.getText());
        saver.setCognome(cognomeTextField.getText());

        return saver;
    }
}

public class DataSaverPersona extends DataSaver {
    // campi nome e cognome
    // .... costruttore/i (può anche non esserci se si usano i setter).

    public void setNome(String nome) { ...... }
    public void setCognome(String cognome) { ...... }
    publid String getNome() { .... }
    publid String getCognome() { .... }

    protected void executeSave(Connection conn) throws SQLException {
        PreparedStatement pstmt = conn.prepareStatement("insert into blabla......");
        try {
            pstmt.setString(1, getNome());
            pstmt.setString(2, getCognome());
            pstmt.executeUpdate();
        } finally {
            pstmt.close();
        }
    }
}

L'ho scritto al volo, non testato ovviamente e molto abbozzato. Devi completare tu ma soprattutto comprendere il "design" in generale.

[X-mac]

public class DataSaverPersona extends DataSaver {
    // campi nome e cognome
    // .... costruttore/i (può anche non esserci se si usano i setter).

    public void setNome(String nome) { ...... }
    public void setCognome(String cognome) { ...... }
    publid String getNome() { .... }
    publid String getCognome() { .... }

    protected void executeSave(Connection conn) throws SQLException {
        PreparedStatement pstmt = conn.prepareStatement("insert into blabla......");
        try {
            pstmt.setString(1, getNome());
            pstmt.setString(2, getCognome());
            pstmt.executeUpdate();
        } finally {
            pstmt.close();
        }
    }
}

questa è una inner class di InternalFramePersona?