Consigli per GUI dinamiche in Java

[F@lkland§]

Ciao ragazzi!
Dovrei creare dei form di inserimento, di visualizzazione e di modifica che variano a seconda del contesto dell'applicazione!

Questi form dinamici come consigliate di realizzarli?
Io avrei in mente due soluzioni: la prima è creare più costruttori che poi dovranno essere chiamati a seconda dell'utilità, la seconda è allocare dinamicamente le JButton, JLabel, JTextField e così via andando a leggere da un file xml.

Il programma non è un'applicazione web.

Avete consigli da dispensarmi?
Come dovrei realizzarlo sommariamente?

Grazie a tutti!

[71104]

io banalmente creerei tot form diverse che visualizzerei a seconda della situazione

il vero problema di questo problema (scusate) è che creare una form in Swing è un tantino difficile.

[banryu79]

Originariamente inviato da 71104

...è che creare una form in Swing è un tantino difficile

Perchè dici questo?
Cioè, in cosa consiste secondo te la difficoltà specifica?
Nel fatto di dover utilizzare JPanel annidati e diversi LayoutManager se le form che devi realizzare sono complesse?

Comunque, se le form in oggetto servono a rappresentare viste di dati in un DB si potrebbe utilizzare la libreria OpenSwing (vantaggi: free, attivamente supportata e in continuo corso di aggiornamento; svantaggi: richiede un certo tempo di apprendimento, si basa sul pattern MVC, quindi presenta qualche complessità, la documentazione free non chiarisce proprio tutto [esiste infatti la versione a pagamento]).

Invece "per alleviare" le difficoltà intrinseche nell'operare con i diversi LayoutManager si potrebbe usare la libreria MIG Layout (presenta una sorta di interfaccia unificata per il layouting dei componenti in Swing e SWT completamente via codice, molto chiaro, e immagino semplice da utilizzare anche se non l'ho ancora provato [perchè per ora mi trovo bene a gestire l'interfaccia con Matisse & custom code]).

[71104]

Originariamente inviato da banryu79

Perchè dici questo?
Cioè, in cosa consiste secondo te la difficoltà specifica?
Nel fatto di dover utilizzare JPanel annidati e diversi LayoutManager se le form che devi realizzare sono complesse?

te la faccio breve: con Windows Forms è più facile

[banryu79]

Originariamente inviato da 71104

te la faccio breve: con Windows Forms è più facile

Posso immaginarlo però mi sembra, così "a pelle", un confronto un po' forzato: qui siamo in ambiente Java, e sappiamo che Java non è legato a doppio nodo ad un particolare os, con tutto quello che ne deriva per il discorso interfacce grafiche.

[71104]

Originariamente inviato da banryu79

Posso immaginarlo però mi sembra, così "a pelle", un confronto un po' forzato: qui siamo in ambiente Java, e sappiamo che Java non è legato a doppio nodo ad un particolare os, con tutto quello che ne deriva per il discorso interfacce grafiche.

le Windows Forms non hanno assolutamente nulla a che vedere con le GUI di Win32, si tratta completamente di un altro sistema grafico la cui logica è costruita da zero; i componenti .NET non sono componenti nativi, e le forms sono un concetto che in Win32 neanche esiste: in Win32 hai solo la main window (SDI o MDI) e le dialogs, modal o modeless.

ma indipendentemente da questo discorso, sta di fatto una cosa soltanto: il tipico editor RAD per Windows Forms mi permette di creare interfacce grafiche molto più produttivamente che scrivendo manualmente il codice Java per Swing. come mai allora non usare un ambiente RAD anche per Swing? per due motivi:
1) fanno cagare
2) generano codice a dir poco vergognoso con cui poi tu devi avere a che fare, cosa che in C# ad esempio viene brillantemente evitata grazie alle partial classes.

[banryu79]

Originariamente inviato da 71104

ma indipendentemente da questo discorso, sta di fatto una cosa soltanto: il tipico editor RAD per Windows Forms mi permette di creare interfacce grafiche molto più produttivamente che scrivendo manualmente il codice Java per Swing. come mai allora non usare un ambiente RAD anche per Swing? per due motivi:
1) fanno cagare

Può essere, ma se vuoi scrivere interfacce grafiche in Java che opzioni migliori hai?

Originariamente inviato da 71104

2) generano codice a dir poco vergognoso con cui poi tu devi avere a che fare, cosa che in C# ad esempio viene brillantemente evitata grazie alle partial classes.

Interessante, in due parole che sarebbero?

[tomminno]

Originariamente inviato da 71104

2) generano codice a dir poco vergognoso con cui poi tu devi avere a che fare, cosa che in C# ad esempio viene brillantemente evitata grazie alle partial classes.

Solo perchè il sudicio viene nascosto sotto il tappeto non significa che non ci sia.
Inoltre ti è mai capitato che si impallasse la parte nascosta della classe e che per risistemare devi cancellare l'intero file, farlo ricreare da VS e poi ripristinare la vecchia versione?

[tomminno]

Originariamente inviato da banryu79

Interessante, in due parole che sarebbero?

Sono una feature necessaria per l'editor automatico, dopo gli enormi problemi causati dalla precendente versione di editor/C#.
In sostanza puoi spezzare una classe su più file, nella pratica viene usata solo dall'editor per generare tutte le sue schifezze in un file nascosto così che tutto appare pulitissimo e ordinato.
Ogni tanto si impalla e non avendo accesso al file nascosto devi cancellare il tuo file, farlo rigenerare dall'editor e ripristinare quello vecchio.

[71104]

Originariamente inviato da tomminno

Solo perchè il sudicio viene nascosto sotto il tappeto non significa che non ci sia.

significa che non devi averci a che fare. tu hai soluzioni migliori (ugualmente produttive s'intende, per evitare che tu mi risponda di scrivere il codice a mano)?

Inoltre ti è mai capitato che si impallasse la parte nascosta della classe e che per risistemare devi cancellare l'intero file, farlo ricreare da VS e poi ripristinare la vecchia versione?

no, motivo percui vorrei che tu mi illuminassi circa i bug introdotti dall'editor nel codice "nascosto" come lo chiami tu (che poi nascosto non è, si può visualizzare senza problemi anche nell'IDE) con un esempio riproducibile su Visual C# Express 2005 o 2008, grazie.

aggiungo che vorrei anche capire cos'è st'idiozia che dopo aver fatto ricostruire il file dall'IDE devi ripristinare quello malfunzionante

[tomminno]

Originariamente inviato da 71104

significa che non devi averci a che fare. tu hai soluzioni migliori (ugualmente produttive s'intende, per evitare che tu mi risponda di scrivere il codice a mano)?

Finchè non introdurranno dei gestori di layout automatici (e non quelle stupide ancore) l'editor del VS è adatto solo per interfacce poco più che banali. Essere produttivi è molto dura, se ci fosse modo di scriversi il codice a mano a volte sarebbe meglio. Oltretutto sei obbligato a schiaffare tutto in una stessa classe, che tende sempre a diventare caotica per via dei tanti controlli presenti e degli eventi associati.

no, motivo percui vorrei che tu mi illuminassi circa i bug introdotti dall'editor nel codice "nascosto" come lo chiami tu (che poi nascosto non è, si può visualizzare senza problemi anche nell'IDE) con un esempio riproducibile su Visual C# Express 2005 o 2008, grazie.

Esempi riproducibili non saprei fornirteli visto che capitano sia su pagine ASP.NET che su interfacce desktop anche dopo parecchio tempo che ci lavori su, ma non certo in maniera deterministica.
Ad un certo punto capita che compilando viene fuori l'errore che una classe non esiste, nonostante che esista e venga correttamente identificata dall'intellisense, andando in modalità design risulta impossibile aggiungere oggetti all'interfaccia. Cancellando il file e facendolo ricreare nuovo al VS e sovrascrivendolo con quello precedente tutto torna a funzionare, segno che è la classe parziale nascosta ad essersi danneggiata in modo irreparabile.

aggiungo che vorrei anche capire cos'è st'idiozia che dopo aver fatto ricostruire il file dall'IDE devi ripristinare quello malfunzionante

Perchè evidentemente non è il file visibile ad essere mal funzionante, ma la classe parziale nascosta generata dall'editor.
E siccome quella viene generata dinamicamente se ricrei una classe nuova l'editor cancella e rigenera anche la classe parziale nascosta. Quanto ripristini il vecchio codice "utente" l'editor rigenera anche la classe parziale nascosta correttamente.

Ah si questo metodo funziona solo con pagine ASP.NET, in caso di WinForm devi rigenerarti da 0 l'interfaccia e quando capita sono bestemmie perchè non ti salva nemmeno SVN.

[banryu79]

Sì, nel frattempo ho attinto alle sempre disponibili risorse del web per capire cosa sono queste partial class: ad una prima lettura come approccio non mi sembra malvagio, francamente.

Comunque in ambiente Java per distinguere la business logic dalla UI logic (quando serve, cioè per interfacce più complesse della media) si adotta il sempiterno MVC pattern e morta là: o implementato "a mano" o sfruttando delle librerie jar disponibili (tipo la OpenSwing citata, ma ne esistono tante altre a seconda dei casi).

Che lo sviluppatore non sia mai sollevato al 100% dalla responsabilità di gestire il problema comunque mi sembra normale; alla fine, imho, la questione rimane sempre quella di imparare a conoscere un po' più affondo gli strumenti che si utilizzano; quando le possibilità/gli strumenti a disposizione per affrontare il problema sono molteplici e/o versatili una soluzione la si trova.

In effetti le difficoltà maggiori che ho incontrato fin'ora sono sempre state causate, nel 95% dei casi, dalla mia ignoranza delle possibilità/strumenti già disponibili, piuttosto che di una loro "inadeguatezza".

Per ora io mi trovo bene con l'editor messo a disposizione da NetBeans unito all'integrazione di codice "a mano" per gestire determinate situazioni.
Non ho mai dovuto, fin'ora, scriverne troppo o di troppo complesso.

[k0nt3]

da quando esiste qtjambi con annesso plugin per eclipse direi che è più facile creare GUI in java che in .NET
comunque a parte gli scherzi.. mi pare che netbeans ha un buon disegnatore di interfacce per SWING, mentre su eclipse consiglierei SWT.
non vedo assolutamente la superiorità di Windows Forms, anzi secondo me sono il punto debole del framework .NET

[tomminno]

Originariamente inviato da banryu79

Sì, nel frattempo ho attinto alle sempre disponibili risorse del web per capire cosa sono queste partial class: ad una prima lettura come approccio non mi sembra malvagio, francamente.

Si per nascondere la monnezza dell'editor sotto il tappeto sono l'ideale

Comunque in ambiente Java per distinguere la business logic dalla UI logic (quando serve, cioè per interfacce più complesse della media) si adotta il sempiterno MVC pattern e morta là: o implementato "a mano" o sfruttando delle librerie jar disponibili (tipo la OpenSwing citata, ma ne esistono tante altre a seconda dei casi).

Questo è ovvio (in qualunque linguaggio). Solo che con gli editor automatici non puoi spezzettare un'interfaccia con decine di controlli su più file (sarebbe bello poter creare ulteriori partial class quando c'è di mezzo il rad), mentre a mano per fare un esempio posso creare una classe per ogni tab di un controllo notebook, cosa che con il RAD non è possibile.
Poi ogni controllo avrà i suoi bravi eventi associati, il che comporta ritrovarsi con classi da centinaia di metodi...

Che lo sviluppatore non sia mai sollevato al 100% dalla responsabilità di gestire il problema comunque mi sembra normale; alla fine, imho, la questione rimane sempre quella di imparare a conoscere un po' più affondo gli strumenti che si utilizzano; quando le possibilità/gli strumenti a disposizione per affrontare il problema sono molteplici e/o versatili una soluzione la si trova.

Per esperienza personale ho verificato che quando uno si abitua troppo alla pappa pronta dei framework, il giorno che devi fare qualcosa di non contemplato (o meglio di non facilitato) dagli stessi, sei fregato.
Recentemente ho riscontrato questo quando un collega ha dovuto realizzare un post multipart, ci è impazzito

In effetti le difficoltà maggiori che ho incontrato fin'ora sono sempre state causate, nel 95% dei casi, dalla mia ignoranza delle possibilità/strumenti già disponibili, piuttosto che di una loro "inadeguatezza".

Non ti dico quanto ho imprecato il giorno che ho dovuto fare un'interfaccia ad espansione radiale dei controlli in C#.
Le ancore non servivano a niente, sono dovuto ricorrere al solito calcolo manuale del posizionamento dei controlli tipico delle MFC.

Per ora io mi trovo bene con l'editor messo a disposizione da NetBeans unito all'integrazione di codice "a mano" per gestire determinate situazioni.
Non ho mai dovuto, fin'ora, scriverne troppo o di troppo complesso.

Tutte le volte che ho dovuto scrivere interfacce un pò più complicate del solito gli IDE sono sempre risultati un intralcio più che un vantaggio.
Certo, se devo mettere 2 controlli in croce uso il RAD senza pensarci 2 volte.

[71104]

Originariamente inviato da tomminno

Finchè non introdurranno dei gestori di layout automatici (e non quelle stupide ancore) l'editor del VS è adatto solo per interfacce poco più che banali.

le tue opinioni non interessano a nessuno.

Essere produttivi è molto dura, se ci fosse modo di scriversi il codice a mano a volte sarebbe meglio.

nessuno ti obbliga ad usare l'editor RAD in Visual C# Express: puoi anche scrivere manualmente il codice che genera le forms e i controlli. tuttavia mi sfugge decisamente uno scenario in cui un tale approccio sarebbe preferibile.

Oltretutto sei obbligato a schiaffare tutto in una stessa classe, che tende sempre a diventare caotica per via dei tanti controlli presenti e degli eventi associati.

non reiteriamo sullo stesso problema: a meno che tu non stia progettando una GUI veramente complessa (tanto da confondere persino l'utente, motivo percui si tratta di una situazione di certo non comune) il caos non è un problema grazie alle partial classes.

Esempi riproducibili non saprei fornirteli visto che capitano sia su pagine ASP.NET che su interfacce desktop anche dopo parecchio tempo che ci lavori su, ma non certo in maniera deterministica.

i computers sono macchine deterministiche, e gli esseri umani possono emulare comportamenti deterministici. se non mi proponi un esempio riproducibile io assumo che tu scriva cazzate.
almeno, se proprio non riesci a vincere la pigrizia, abbi la decenza di darmi un link alla KB dove la Microsoft mi spieghi al posto tuo come riprodurre un bug; ma altrimenti non scrivere per nulla.

Ad un certo punto capita che compilando viene fuori l'errore che una classe non esiste, nonostante che esista e venga correttamente identificata dall'intellisense, andando in modalità design risulta impossibile aggiungere oggetti all'interfaccia. Cancellando il file e facendolo ricreare nuovo al VS e sovrascrivendolo con quello precedente tutto torna a funzionare, segno che è la classe parziale nascosta ad essersi danneggiata in modo irreparabile.

Perchè evidentemente non è il file visibile ad essere mal funzionante, ma la classe parziale nascosta generata dall'editor.

ma tralasciando un attimo il fatto che tu continui a parlare della classe parziale autogenerata come se fosse inaccessibile da dentro l'IDE...

Ah si questo metodo funziona solo con pagine ASP.NET, in caso di WinForm devi rigenerarti da 0 l'interfaccia e quando capita sono bestemmie perchè non ti salva nemmeno SVN.

... questo è il colmo
in pratica un malfunzionamento nell'editor delle Windows Forms può corrompere un database (remoto) di versioning?

senti, io al limite posso anche capire (nonostante tu non sia in grado di fornirmi degli esempi riproducibili) che l'editor RAD delle Windows Forms sia buggato: nessun software è perfetto. ma l'approccio RAD è evidentemente l'approccio migliore in termini di produttività per la creazione di interfacce grafiche, intricate e non. non è che se al tuo specifico martello si stacca il manico allora i chiodi li devi piantare a manate
e soprattutto finché non sei in grado di dimostrare e di farci riprodurre qualcosa il discorso non si pone neanche, perché come ho scritto sopra le tue opinioni non interessano a nessuno (per quanto siano poste con ironia).

Originariamente inviato da k0nt3

non vedo assolutamente la superiorità di Windows Forms, anzi secondo me sono il punto debole del framework .NET

questa discussione sta assumendo toni di forte inutilità

sembrate tutti molto bravi a sparare cazzat... pardon, a dire le vostre opinioni
ma almeno abbiate la decenza di schiaffarci pure un "IMVVVVHO" ogni tanto

[k0nt3]

Originariamente inviato da 71104

sembrate tutti molto bravi a sparare cazzat... pardon, a dire le vostre opinioni
ma almeno abbiate la decenza di schiaffarci pure un "IMVVVVHO" ogni tanto

"secondo me" cosa vorrebbe dire secondo te (scusate il gioco di parole)?
ho usato per progetti non banali sia Windows Forms che SWT che QT che SWING quindi posso dire di essermene fatto un'idea. SWING non è un granchè e non lo nascondo, ma nemmeno le Windows Forms sono perfette, se appena cerchi di fare qualcosa che non è stato previsto è un bagno di sangue

[banryu79]

Originariamente inviato da tomminno

...
Solo che con gli editor automatici non puoi spezzettare un'interfaccia con decine di controlli su più file (sarebbe bello poter creare ulteriori partial class quando c'è di mezzo il rad), mentre a mano per fare un esempio posso creare una classe per ogni tab di un controllo notebook, cosa che con il RAD non è possibile.
Poi ogni controllo avrà i suoi bravi eventi associati, il che comporta ritrovarsi con classi da centinaia di metodi...

Beh, forse non lo puoi fare con l'editor specifico a cui stai facendo riferimento nel tuo post, però io le interfacce un attimo più complesse di solito le ho divise in 3-4 file .java (e quindi 3-4 classi principali che al loro interno possono includere classi annidate, oppure 1 o 2 classi minori utility della principale presenti dunque nello stesso file .java[questo però è più raro] ).

Di solito ho una classe per il "Frame" principale che al suo interno può essere diviso in più "aree logiche" o di "visualizzazione" (ognuna è una classe che si riferisce alla principale e gestisce solo alcuni aspetti ben precisi che rappresenta: per esempio una classe che estende JPanel per eseguire un rendering grafico di un oggetto-modello dell'applicazione; un'altra per gestire delle operazioni su quell'oggetto-modello dell'applicazione).

Se dovessi gestire qualcosa di più complesso invece che l'implementazione diretta di classi proverei a definire delle classi astratte implementate poi dalla classe concreta del caso.
Per ora a livello di GUI non mi è ancora servito.
D'altronde non ho un'esperienza significativa a livello di "casistica" per cui mi è difficile giudicare.
Come si suol dire: just my 2 cents.

[71104]

Originariamente inviato da banryu79

Come si suol dire: just my 2 cents.

se potessi raccogliere tutti i 2 cents che ho letto in questo e altri thread sarei ricco.

[banryu79]

Originariamente inviato da 71104

se potessi raccogliere tutti i 2 cents che ho letto in questo e altri thread sarei ricco.

Certamente,
volevo solo capire, da ignorante, perchè tu (che da altri post in cui ti ho letto mi sembri possedere una certa esperienza) ritieni le Swing "non valide" (hai scritto che fanno cagare) per codificare interfacce grafiche in Java.

Se non ho capito male quello che hai scritto, tu affermi che le Swing non sono valide per come sono strutturate ad essere utilizzate per la costruzione di GUI da parte di editor visuali.
Sostieni che le Windows Form siano migliori.
Ma questo è un'altro discorso: nel contesto di questo thread l'utente che l'ha aperto sta utilizzando Java, percui, per tornare a bomba, la questione rimane: se le Swing (e gli editor visuali che le utilizzano) non sono adatte, che altre opzioni rimangono?

Io sostengo che alcune facilitazioni potrebbero esserci appoggiandosi a librerie Java che affiancano Swing in questo o quell'aspetto, a patto di poter investire un certo lasso di tempo nell'apprendimento di quegli strumenti.
Tutto qua.

[71104]

Originariamente inviato da banryu79

Certamente,
volevo solo capire, da ignorante, perchè tu (che da altri post in cui ti ho letto mi sembri possedere una certa esperienza) ritieni le Swing "non valide" (hai scritto che fanno cagare) per codificare interfacce grafiche in Java.

AAAAARGH, mai detto questo!!
Swing è uno dei migliori toolkit grafici al mondo!

ma il toolkit da solo potrebbe non bastare: spesso anche io preferisco scrivere manualmente il codice Swing delle mie interfacce grafiche Java, ma come puoi ben immaginare riesco ad essere 1000 volte più produttivo in Visual C# grazie all'editor visuale. Swing è "programmaticamente" ottimo, ma i due editor visuali che ho provato (Visual Editor e un altro affare, Jigloo ) non mi piacciono per niente: erano quelli che ho scritto che fanno cagare, e scusate ma a sto punto un'opinione personale ce l'ho messa pure io

Se non ho capito male quello che hai scritto, tu affermi che le Swing non sono valide per come sono strutturate ad essere utilizzate per la costruzione di GUI da parte di editor visuali.

.....

stravolgimento completo

Sostieni che le Windows Form siano migliori.

sostengo di essere più produttivo quando creo una GUI che usa le Windows Forms, ma non per merito delle Windows Forms in se'.