[Soci SLIP] Non riesco a fare una cosa con NETBEANS...

[Lucio]

Il martedì 11 gennaio 2011 13:19:18 roby.gir a libero.it ha scritto:
> la questione. In sostanza mi stò cimentando a creare un gestionale JAVA
> utilizzando, appunto, il framework SWING.
>
> "Le tre entità hanno in comune le semplici azioni di INSERIMENTO, MODIFICA,
> CANCELLAZIONE, STAMPA, VISUALIZZAZIONE DETTAGLIO e VISUALIZZAZIONE ELENCO"

Manca la ricerca con i dovuti filtri... a parte ciò, l'assunto di base può 
andar bene, ma non giustifica il fatto di derivare le tue classi da quelle di 
Swing. Tu stesso parli di "azioni", mentre Swing si occupa di "click". 
L'interfaccia Action di Swing è una delle poche ad essere lì apposta per gli 
sviluppatori per poter essere implementata, ma come noti anche tu è 
un'interfaccia e non una classe concreta, quindi le tue azioni continuano a 
stare nella gerarchia di classi che ti devi disegnare tu e poi 
implementano "casualmente" Action in modo da poter "parlare" con Swing.

Per dirla ancora in un altro modo, avrebbe senso derivare classi da Swing se 
tu stessi sviluppando una libreria grafica che si propone come estensione di 
Swing. Tu però vuoi fare un gestionale, non un'estensione di Swing.

>
> Da questo assunto, ho pensato che sia opportuno creare un Form di base
> contenente questi semplici elementi:
>
> - JToolbar con i pulsanti di inserimento, modifica, cancellazione e stampa
> - JTabbedPane per contenere i vari campi dell'entità (articolo, cliente o
> fornitore) nel dettaglio
> - JTable per l'elenco delle entità

Questo va bene, ma la classe che conterrà questi widget non dovrà derivare da 
JInternalFrame o simili, altrimenti è come se tu dicessi che la tua view è 
uno speciale componente di Swing.

>
> Inoltre, la form di base contiene le funzioni per gestire  i pulsanti e la
> visualizzazione dell'elenco
>
> Derivando da questa form, io mi scaricherei l'onere di riscrivere del
> codice che in realtà può essere usato a prescindere dal tipo di entità
> gestito, ed andrei semplicemente ad aggiungere i campi (relativi all'entità
> specifica in questione) nel JTabbedPane ereditato, nonchè le funzionalità
> specifiche per l'entità in questione.
>
> Cosa ne pensi?

Difficile dare una valutazione. Mi sembra che stai cercando di risolvere il 
problema un po' troppo "top-down", ma prendi la mia opinione con le pinze, 
non ho abbastanza informazioni per formulare un giudizio sensato e poi sono 
abituato a ragionare in termini di MVC. Di solito io parto dal data model, da 
quello ottengo la struttura del database e la gerarchia delle classi del mio 
domain model, da lì ho una corrispondenza quasi uno a uno con il presentation 
model, il che mi guida nella creazione delle views e dei rispettivi 
controllers.