configurazione con file xml

[blackraziel]

Salve a tutti, qualcuno sarebbe così gentile da darmi qualche consiglio su come utilizzare xm per la configurazione di 1applicazione java?
Mi spiego: la mia applicazione dovrebbe leggere da xml valori come : larghezza di colonne di una JTable, stringhe da inserire in una JComboBox e cose di questo genere.
C'è uno standard per effettuare queste operazioni??Tipo passare i dati da xml a un albero binario e poi assegnare i valori da li.
Grazie in anticipo a chiunque mi dia 1aiuto

[Santino83_02]

parlando da neofito, ma usare un file properties no? io l'ho trovato molto comodo...

[antotan]

Personalmente mi trovo molto bene a configurare utilizzando i file XML + dom4j.
Secondo me, i file XML sono più comprensibili dei properties dato che puoi raggruppare seguendo una logica prestabilita (molto utile durante la scrittura della configurazione) e si adattano maggiormente a delle liste di valori per una data chiave. Poi l'XPath è a prova di scimmia.
Inoltre per le GUI si adattano tantissimo, tant'è vero che sono usati da molti tool che fanno questo lavoro.

[valia]

tutto è bene e tutto è male se non lo sai usare.
All'interno del file .properties puoi dare tu la logica di raggruppamento inserendo commenti e lasciando spazi bianchi (in modo da identificare un campo logico).
Pur essendo molto abituata all'xml, un .properties lo preferisco di certo ad un .xml:

1. non sempre puoi leggere un .xml con strumenti grafici, quindi leggere un .properties con vi e un .xml con vi il primo è più comprensibile
2. supponi che nessuno possa modificare il .xml (falso) quindi il fatto che sia a prova di scimmia lascia il tempo che trova.
3. tempi di parsing: vuoi paragonare il parse di un xml al parse di un file di testo? Oltretutto i .properties ti consentono di creare strutture ad accesso rapido tipo hashmap (comodo quando devi andarti a prendere i dati).

sono 3 motivi per cui preferisco, quando possibile, il .properties al .xml

Eclipse usa file .properties per la configurazione, così come Netbeans (e se mi metto a guardare bene non so quanti altri).

Il fatto che le robe grafiche all'interno se le memorizzino come xml non significa niente, poi alla fine è una scelta tua. In genere, a parte la dimensione di una tabella (che poi io preferisco sempre fissare regole di resizing generiche e lasciare che il componente si dimensioni in modo armonico sempre in relazione allo spazio che ha) non credi che queste informazioni possano riguardare la logica (il contenuto) del programma e non il componente in generale? Non pensi che le righe del JComboBox siano più legate al contenuto che ti rappresentano ?

[blackraziel]

Mi puoi spiegare le regole di resizing??

[valia]

devi impostare un layout manager innanzi tutto.
Ovviamente il sistema funziona bene anche se tu ragioni in termini di pannelli che incapsulano componenti. Mi spiego. Io io in genere non butto tutto sul frame principale, ma raggruppo componenti logici all'interno di un pannello.
Se ad esempio ho un form di inserimento dati per poi fare una ricerca in un db avrò almeno 3 pannelli interni:
1. label con textfield contenute tutte in un pannello
2. pannello che contiene risultati
3. pannello che contiene entrambi

quindi tu vai ad indicare in generale ad ogni pannello un layout manager e anche come deve comportarsi in caso di variazione dello spazio disponibile.
In questo modo, se hai definito tutto per bene, un resizing non sposta i componenti a video e soprattutto hai gratuitamente tutta la logica che imposta le dimensioni.

Puoi fissare le dimensioni di partenza, ma a meno che non abbia particolari esigenze lascio fare al layout manager.

I layout manager, i principali li trovi sul sito della oracle (segui how to use swing), andbin ne conosceva un altro che non ricordo, magari puoi chiedere a lui (o se lui legge magari te lo indica)

[blackraziel]

Ok, darò 1cchiata.
Grazie

[antotan]

Originariamente inviato da valia

tutto è bene e tutto è male se non lo sai usare.
All'interno del file .properties puoi dare tu la logica di raggruppamento inserendo commenti e lasciando spazi bianchi (in modo da identificare un campo logico).

Assolutamente, puoi farlo, ma non mi pare il punto di forza dei properties, ne tantomento si adattano meglio allo scopo rispetto ad un file strutturato gerarchicamente.

Pur essendo molto abituata all'xml, un .properties lo preferisco di certo ad un .xml:

1. non sempre puoi leggere un .xml con strumenti grafici, quindi leggere un .properties con vi e un .xml con vi il primo è più comprensibile

Beh si è vero, però qui stai prendendo un caso specifico per spiegare qualcosa di più ampio.
Stessa cosa si può dire dei properties allora, infatti basterebbe un PC con IE per ricavare una chiave in 2 secondi con un XML rispetto a scorrerti tutto il properties (mettiti anche nei panni di chi quella configurazione non l'ha fatta).
Ripeto però, parliamo di casi specifici, dipende dalla situazione.

2. supponi che nessuno possa modificare il .xml (falso) quindi il fatto che sia a prova di scimmia lascia il tempo che trova.

Scusami, non ho capito che intendi.
Comunque sia, dicevo che l'XPath è a prova di scimmia, riferendomi alla fase di sviluppo.
Per quanto riguarda un ipotetico cliente/altro programmatore, non mi pare ci siano grossi problemi a modificare un XML (perdonami se non è questo che intendevi)

3. tempi di parsing: vuoi paragonare il parse di un xml al parse di un file di testo? Oltretutto i .properties ti consentono di creare strutture ad accesso rapido tipo hashmap (comodo quando devi andarti a prendere i dati).

Giusto, prendendo però come vero il fatto che one size fits one. Vuoi essere veloce o più chiaro?

sono 3 motivi per cui preferisco, quando possibile, il .properties al .xml

Eclipse usa file .properties per la configurazione, così come Netbeans (e se mi metto a guardare bene non so quanti altri).

Il fatto che le robe grafiche all'interno se le memorizzino come xml non significa niente, poi alla fine è una scelta tua.

Attenzione, non hai capito cosa intendo (Edit: no, sono io che mi sono spiegato da cu, scusa). L'XML oltre a poter fare altre mille cose, si adatta particolarmente alle GUI. Qui non parliamo di come le robe grafiche memorizzano come XML la struttura (tipo il GLADE della situazione), parliamo di linguaggi di "design" delle GUI che utilizzano XML, vedi XUL, MXML, XAML...
Questo vuol dire parecchio, a mio parere.

In genere, a parte la dimensione di una tabella (che poi io preferisco sempre fissare regole di resizing generiche e lasciare che il componente si dimensioni in modo armonico sempre in relazione allo spazio che ha) non credi che queste informazioni possano riguardare la logica (il contenuto) del programma e non il componente in generale? Non pensi che le righe del JComboBox siano più legate al contenuto che ti rappresentano ?

Per esperienza personale, ti posso dire che quando l'applicazione non è configurata a dovere e ti chiedono di togliere un Menu, aggiungere un MenuItem ad un altro Menu ed eliminarne da qui altri due (per fare un esempio semplice), hai non pochi problemi.
Se poi il programma lo utilizzi solo tu o clienti che non hanno bisogno di modifiche, allora ok.
Personalmente, cerco di mantenere la GUI il più dinamica possibile.
Una combo la utilizzi per mostrare quello che c'è dentro e fin qui non ci piove, ma quella combo può avere contenuto profondamente differente tra questo e quel cliente, può anche non esserci, può essere collegata ad un listener (quindi anche oltre il semplice aspetto grafico) differente per ogni caso che hai ecc...
Magari un cliente ti chiede i tastini tutto belli arrotondati, un altro vuole lo sfondo col gradiente grigio e così via...

Qundi, concludendo dicendo che tutto è relativo e non può che dipendere dal caso specifico, questi sono (più o meno) i motivi che preferisco l'XML specialmente per le GUI.

[valia]

Originariamente inviato da antotan
Per esperienza personale, ti posso dire che quando l'applicazione non è configurata a dovere e ti chiedono di togliere un Menu, aggiungere un MenuItem ad un altro Menu ed eliminarne da qui altri due (per fare un esempio semplice), hai non pochi problemi.
Se poi il programma lo utilizzi solo tu o clienti che non hanno bisogno di modifiche, allora ok.
Personalmente, cerco di mantenere la GUI il più dinamica possibile.
Una combo la utilizzi per mostrare quello che c'è dentro e fin qui non ci piove, ma quella combo può avere contenuto profondamente differente tra questo e quel cliente, può anche non esserci, può essere collegata ad un listener (quindi anche oltre il semplice aspetto grafico) differente per ogni caso che hai ecc...
Magari un cliente ti chiede i tastini tutto belli arrotondati, un altro vuole lo sfondo col gradiente grigio e così via...

Scusa forse stiamo parlando di cose differenti: cosa devi fare? Perché se usi le swing per fare grafica in java i problemi che dici non esistono (e in realtà io non ho mai usato né un xml né un properties per fare un'interfaccia grafica)

1. un MenuItem non va a toccare l'interfaccia grafica che hai stabilito prima, se hai impostato bene il form questa va in alto e al max riduce le dimensioni del frame sotto, ma non tocca il contenuto che c'è sotto. Di conseguenza, il tuo unico problema è scrivere 10 (10 si fa per dire) righe di codice java che creino il menu, mettano i vari menuitem, associno le azioni relative e lo aggiungano in alto al form. In java, a meno che non stai scrivendo un plugin matisse, queste cose non hanno niente a che fare né con un .xml né con .properties.

2. Stesso discorso dicasi per le combo: fanno uso del pattern MVC, il fatto che cambi il contenuto non vuole dire che ti devono cambiare le impostazioni grafiche.

Riguardo alle "finezze grafiche" si risolvono in istruzioni che impostano border, immagini ecc oppure ti trovi ad impostare direttamente il look and feel (ma è una istruzione che indica il tipo di look and feel che usi e lo puoi buttare in un .properties per reperirlo in maniera rapida).

Parliamo di linguaggi di "design" delle GUI che utilizzano XML, vedi XUL, MXML, XAML...
Questo vuol dire parecchio, a mio parere

Parliamo di cose differenti. Java è un linguaggio di programmazione che offre una libreria di istruzioni per la creazione di interfacce grafiche. Le varie impostazioni xml come dici tu le usa matisse, che memorizza il tutto in un xml, tu fuori vedi solo le istruzioni java che conosci e perdonami devi lavorare su quelle, non sull'xml perché matisse non tutti lo hanno (se usi eclipse puoi creare un programma perfettamente funzionante con le stesse impostazioni usando istruzioni java).

Ora mi spieghi di cosa parli tu e di come questo possa aiutare un programmatore java che crea un'interfaccia grafica?

Preferisci essere più veloce o più chiaro?

Un'ultima nota: parliamo di punto di vista utente o punto di vista programmatore?
Dal punto di vista programmatore, la chiarezza è come dire un must se devi modificare. Ma per la mia esperienza e per come lavoro io (a volte terminale su macchina remota) un xml di dimensioni ridotte è assolutamente chiaro, un xml di certe dimensioni diventa difficilmente comprensibile con vi. Resta più diretto un properties ben organizzato (solo perché hai meno righe visto che non hai tag apertura e chiusura). Con vi è facile sbagliare a scrivere una lettera, vallo poi a capire quando va in errore un parser xml, con .properties lo trovi subito visto che non ti vedi il relativo valore caricato.
Ovvio che se si lavora solo con interfacce grafiche che mascherano la creazione di un relativo xml si adori l'xml.

Dal punto di vista utente: l'utente non vede xml e vede solo in quanto tempo risponde ogni comando, la velocità non bisogna mai dimenticarla e non bisogna mai dimenticare che il pc su cui noi sviluppiamo non è quello che usa l'utente. Quindi un secondo da te per parsare l'xml possono essere 10 secondi dall'utente che ha il computer vecchiotto.
Non puoi inoltre imporre un riacquisto delle macchine per avere le giuste risorse, ergo la velocità e il considerare risorse sprecate per il parse non sono fattori da trascurare. Le risorse non sono infinite, purtroppo i programmatori pensano lo siano.

Ti sembrano banali come ragioni per dire che a volte si abusa dell'xml?

Ma queste sono opinioni derivanti dalla mia esperienza, quando non sono obbligata preferisco non usare l'xml .

[antotan]

Originariamente inviato da valia
Scusa forse stiamo parlando di cose differenti: cosa devi fare? Perché se usi le swing per fare grafica in java i problemi che dici non esistono (e in realtà io non ho mai usato né un xml né un properties per fare un'interfaccia grafica)

Forse non hai mai avuto la fortuna/sfortuna di toccare questo aspetto, ma se usi le swing per fare grafica in java allora i problemi che dico possono esistere eccome. Lo avevo già specificato però forse faccio meglio a ripetere. Se tu fai il tuo programma e di customizzazioni su di esso nessuno vuole sentir parlare allora tutto fila, il primo che viene a dirti che quella cosa lì nella finestrella non deve essere così ma con bordi x, con background y, con largezza z, quando è attiva deve avere questa immagine, quando succede questo blabla...allora semplicemente vai in panico. A meno che tu non voglia, per questo genere di modifiche, branchare la tua applicazione, e se, come presumo sia, sai cos'è un branch, capisci che ti stai impantanando

1. un MenuItem non va a toccare l'interfaccia grafica

Se decidi che un menu o un menuitem non deve essere visibile va a toccare l'interfaccia grafica eccome. Così come altre robette tipo decidere le varie icone, marchi e menate varie.

che hai stabilito prima,

e qui c'è il problema, puoi stabilirlo prima, ma senza essere capace di reagire alle richieste di modifiche future, torni al punto di partenza

se hai impostato bene il form questa va in alto e al max riduce le dimensioni del frame sotto, ma non tocca il contenuto che c'è sotto. Di conseguenza, il tuo unico problema è scrivere 10 (10 si fa per dire) righe di codice java che creino il menu, mettano i vari menuitem, associno le azioni relative e lo aggiungano in alto al form. In java, a meno che non stai scrivendo un plugin matisse, queste cose non hanno niente a che fare né con un .xml né con .properties.

Cioè se io ho 3 file di configurazione (per i clienti A, B, C), e nel mio bell'XML ricreo la struttura gerarchica (perchè un JMenu si esprime perfettamente con una struttura gerarchica) del menu, questo non avrebbe niente a che fare con quello di cui stiamo parlando?

2. Stesso discorso dicasi per le combo: fanno uso del pattern MVC, il fatto che cambi il contenuto non vuole dire che ti devono cambiare le impostazioni grafiche.

Prendi una combo, in una configurazione del tuo software deve avere le linee con solo testo, in un'altra configurazione del tuo software, per il tizio A, deve avere anche le immagini (facciamo finta siano dvd, deve avere le copertine), io questo me lo faccio configurabile (poi che siano con properties o XML poco importa), tu lo fai andando a mettere mano al codice.
Non è uguale a mio avviso.

Riguardo alle "finezze grafiche" si risolvono in istruzioni che impostano border, immagini ecc oppure ti trovi ad impostare direttamente il look and feel (ma è una istruzione che indica il tipo di look and feel che usi e lo puoi buttare in un .properties per reperirlo in maniera rapida).

ok, io invece voglio rendere i bordi configurabili, il look and feel configurabile, le immagini configurabili. L'istruzione è una sola, con la differenza che tu andrai nel tuo .java a dirgli "setta quetso look and feel", poi ricompili e ridistribuisci. Io vado nel mio file di configurazione e scrivo tutto quello che mi pare, avvio il programma e ho già finito.

Parliamo di cose differenti.

io sto parlando di configurabilità e design di interfacce grafiche tramite file di configurazione e dei suoi componenti, cosa che si avvicina alla richiesta iniziale.

Java è un linguaggio di programmazione che offre una libreria di istruzioni per la creazione di interfacce grafiche. Le varie impostazioni xml come dici tu le usa matisse, che memorizza il tutto in un xml, tu fuori vedi solo le istruzioni java che conosci e perdonami devi lavorare su quelle, non sull'xml perché matisse non tutti lo hanno (se usi eclipse puoi creare un programma perfettamente funzionante con le stesse impostazioni usando istruzioni java).

Ora mi spieghi di cosa parli tu e di come questo possa aiutare un programmatore java che crea un'interfaccia grafica?

Già detto, servono a renderti il lavoro più semplice nelle customizzazioni e a non rendere il tuo programma un'entità statica. Non è un concetto che ho inventato io, esiste da un pezzo ed è largamente usato.

Un'ultima nota: parliamo di punto di vista utente o punto di vista programmatore?

Fortunatamente, sia utente che programmatore. Qui il discorso però si fa un pò lungo.

Dal punto di vista programmatore, la chiarezza è come dire un must se devi modificare. Ma per la mia esperienza e per come lavoro io (a volte terminale su macchina remota) un xml di dimensioni ridotte è assolutamente chiaro, un xml di certe dimensioni diventa difficilmente comprensibile con vi. Resta più diretto un properties ben organizzato (solo perché hai meno righe visto che non hai tag apertura e chiusura). Con vi è facile sbagliare a scrivere una lettera, vallo poi a capire quando va in errore un parser xml, con .properties lo trovi subito visto che non ti vedi il relativo valore caricato.
Ovvio che se si lavora solo con interfacce grafiche che mascherano la creazione di un relativo xml si adori l'xml.

ripeto, questo è un discorso specifico, se per te vanno bene i properties per il tuo modo di lavorare allora è ovvio che la tua scelta ricadrà sui properties. Poi non fraintendermi, non ho mai detto che i properties sono da evitare, anzi.

Dal punto di vista utente: l'utente non vede xml e vede solo in quanto tempo risponde ogni comando, la velocità non bisogna mai dimenticarla e non bisogna mai dimenticare che il pc su cui noi sviluppiamo non è quello che usa l'utente. Quindi un secondo da te per parsare l'xml possono essere 10 secondi dall'utente che ha il computer vecchiotto.

Non puoi inoltre imporre un riacquisto delle macchine per avere le giuste risorse, ergo la velocità e il considerare risorse sprecate per il parse non sono fattori da trascurare. Le risorse non sono infinite, purtroppo i programmatori pensano lo siano.

Anche questo mi pare un discorso che va molto oltre. Qui entrano in ballo scelte di partenza non indifferenti, per cui non mi pare che sia una discriminante.
Senza contare che un cliente può direttamente/indirettamente mettere mano al file di configurazione, sganciandosi da chi quel file glielo ha creato.

Ti sembrano banali come ragioni per dire che a volte si abusa dell'xml?

Ma queste sono opinioni derivanti dalla mia esperienza, quando non sono obbligata preferisco non usare l'xml .

Mai detto di usare l'XML sempre e comunque (tant'è vero che ho usato parole come "personalmente" e "secondo me"). Dico solo che considerato quello che è stato chiesto, considerato la mia esperienza e tutte le motivazioni di sopra e del post prima, se c'è motivo di usare l'XML, va usato.