Quote Originariamente inviata da andbin Visualizza il messaggio
Ok .. quello che "temevo". Una soluzione "fatta in casa" che però ha un sacco di problemi. Ed ora cerco di spiegarti.

Innanzitutto quel tuo file di configurazione è estremamente "prolisso". Poi, perché tutti quei "#"?? La gestione di questo formato che ti sei "inventato", è tutta a TUO carico. E non è affatto banale. Non voglio nemmeno immaginare (no, non farmelo vedere ..) cosa hai scritto per parsare questo formato!

E in ogni caso, da quella struttura si capisce molto poco. Soprattutto, quello che si capisce poco è la struttura "effettiva" dell'albero dei componenti.

Si vede ad esempio:

Parent(#FRAME, MainFrame1#);

e

Parent(#CONTAINER, MainContainer#);

Ma già così si capisce poco. MainFrame1 è il Name di un frame messo 27 righe prima. Ora, se già così si capisce poco, immagina uno scenario nemmeno troppo complesso: un JFrame che contiene 1 JPanel, che contiene 3 JPanel, e ciascuno contiene 10~12 componenti.

Secondo te, una persona che LEGGE quel file, va continuamente a cercarsi avanti e indietro le relazioni tra i nomi?? E secondo te, solo leggendo il file, riesce a farsi una idea mentalmente della struttura (ad "albero") della interfaccia utente??

E infatti: non è così che va fatto!


No, non è questo che va fatto!! Anche se tecnicamente lo facessi, il file resterebbe comunque (quasi) illeggibile.




Anche qui sbagli. Innanzitutto il setAccessible probabilmente non ti serve. Il setAccessible(true) serve per permettere l'accesso a metodi/costruttori/field che non sarebbero normalmente accessibili per reflection secondo le regole sui livelli di accesso.
Ma a te NON serve usare cose "interne" di Swing. E te basta usare l'API "pubblica" di Swing. E per questo, il setAccessible NON serve.

Ti dico di più. L'uso di "diretto" della reflection (Class, Field, Method ecc...) ok, è un conto, ma esiste un'altra API nel framework, quella nel package java.beans. Questa API è di più "alto" livello ed è stata fatta proprio per gestire gli oggetti che seguono la specifica dei JavaBeans (oggetti con getXxx/setXxx ecc...) e in modo specifico i componenti AWT/Swing, che di fatto sono proprio dei JavaBeans.

Poi hai considerato anche altri aspetti? Ad esempio il fatto che il setVisible(true) generalmente è l'ultima cosa da fare su un frame.

E inoltre anche un'altra cosa: come gestisci il fatto che ad esempio in una certa classe che estende JFrame hai bisogno del riferimento a certi componenti? Quando io faccio una UI Swing, generalmente scrivo una cosa tipo:
codice:
public class MyFrame extends JFrame {
    private JLabel infoLabel;

    public MyFrame() {
        // qui costruisco i componenti, es.:
        infoLabel = new JLabel();
        // ....
    }

    // altri metodi dove uso infoLabel
}

Se con un file di configurazione, la creazione dei componenti è dinamica basata su quel file, quel infoLabel = new JLabel(); di fatto non esiste più. Quindi la domande è: chi mi popola quel field infoLabel che comunque mi serve nel codice di MyFrame?
Sappi che ci sono diverse soluzioni (almeno 2 ho in mente) per questo aspetto.

Hai pensato e ragionato su questi aspetti?
Per quanto riguarda il file di configurazione si, dovrò valutare un approccio migliore che tenga conto di più componenti.
Il parsing è comunque immediato ed i # sono utili in queso per evitare errori di lettura secondo il mio punto di vista.

Mi sembra che se il JFrame tramite il metodo add aggiunge un JLabel labelInfo questo componente è direttamente accessibile. Non riesco a comprendere cosa intendi forse.

Se comunque esiste già una libreria Java Swing meglio usarla, questo si.
Inoltre usando i bean di swing potrei lavorare meglio?