Swing (Java): differenze tra le versioni

Versione delle 07:41, 6 giu 2007

Versione delle 01:53, 29 ago 2007

Riga 1:

{{W|informatica|gennaio 2007|'''[[Utente:Piracmone|Piracmone]]'''. <small>[[Discussioni utente:Piracmone|(Dimmi)]]</small> 15:40, 29 gen 2007 (CET)}}

[[Immagine:Gui-widgets.png|thumb|right|Esempio di widget in Java 5.0+ per il [[X Window System]]. La renderizzazione dei font potrebbe variare a seconda della piattaforma utilizzata.]]

'''Swing''' è un [[Framework]] per [[Java_(linguaggio)|Java]]. È una parte di [[Java Foundation Classes]] (JFC). Swing include una [[GUI|Interfaccia grafica]] (GUI), dei [[widget]] come le caselle di testo, pulsanti, pannelli e tabelle.

I widget Swing forniscono una GUI più sofisticata rispetto alla precedente [[Abstract Window Toolkit]]. Essendo scritti in puro [[Java_(linguaggio)|Java]], funzionano allo stesso modo su tutte le piattaforme (su cui java gira), al contrario delle AWT le quali sono legate al sistema grafico nativo del [[Sistema_operativo|sistema operativo]]. Swing supporta il [[look and feel]] non tramite quello che viene fornito nativamente dal gestore delle finestre, ma tramite una sua emulazione. Questo significa che si può ottenere un qualsiasi L&F supportato su qualsiasi piattaforma. Lo svantaggio di questi componenti pesanti è quello di una più lenta esecuzione. Il vantaggio è una uniformità di visualizzazione tra svariate piattaforme.

Riga 22:

* leggero

* a spedizione di eventi

* un framework GUI MVC

* con un thread unico

* Indipendente dalla piattaforma: Swing è indipendente dalla piattaforma sia in termini di linguaggio (Java) sia della sua implementazione (una renderizzazione universale e non nativa dei widget).

* Estendibile: Swing è una architettura molto suddivisa la quale permette l'aggancio di varie implementazioni modificate di specifiche interfacce: Gli utenti possono creare le loro personali implementazioni dei componenti per modificare le implementazioni di default. In generale, gli utenti Swing possono estendere il framework con: estensione delle classi esistenti; fornitura di implementazioni native dei componenti base.

* Orientato ai componenti: Swing è un framework basato a componenti. La differenza tra oggetti e componenti è leggera: concisamente, un componente è un oggetto con determinate caratteristiche di comportamento conosciute e specificate. Gli oggetti Swing emettono eventi in modo asincrono, hanno caratteristiche legate ad essi stessi, e rispondono da un ben preciso set di comandi (Specifico per componente). Specialmente i componenti Swing Java Beans, seguono le specifiche dell'architettura Java Bean.

* Modificabile: Dato il modello di renderizzazione programmatico del framework di Swing, è possibile ottenere un preciso controllo del dettaglio sulla renderizzazione dei suoi componenti. Come discorso generale, la rappresentazione grafica di un componente swing è una combinazione di un set standard di elementi, come i bordi, le rientranze, decorazioni, etc. Solitamente, gli utenti modificheranno un componente standard di Swing (come una JTable) assegnando bordi, colori, sfondi specifici come proprietà del componente. Il componente base, userà queste proprietà (o settaggi) per determinare la modalità più appropriata per disegnarsi. Comunque, è anche possibile creare controlli GUI completamente nuovi, con un livello di rappresentazione visuale molto dettagliato (Per esempio, i componenti Swing supportano le trasparenze.)

* Configurabile: Swing, facendo un uso pesante dei meccanismi di runtime e dei percorsi di renderizzazione indiretta, ha la possibilità di modificare a runtime cambiamenti anche fondamentali nei suoi settaggi. Per esempio, una applicazione basata su Swing può cambiare il suo look and feel a runtime (per esempio, dal look and feel di MacOS a quello di Windows XP). Inoltre, gli utenti possono fornire le loro proprie implementazioni di look and feel, il che permette di ottenere cambiamenti uniformi nei look and feel di applicazioni Swing esistenti, senza un continuo ritocco al codice sorgente dell'applicazione.

* Leggero: La magia della configurabilità di Swing è anche dovuta al fatto che non necessita di usare i controlli della GUI dell' OS nativi per la ''rappresentazione'', ma piuttosto 'disegna' i suoi controlli costantemente, attraverso l'uso delle api 2D di Java. Inoltre, un componente Swing non ha un corrispettivo nell'insieme dei componenti nativi dell'OS, ed è quindi libero di renderizzare se stesso in ogni modo possibile con le librerie grafiche di Java 2D.

Comunque, alla base, ogni componente Swing si basa su di un contenitore AWT, dato che i JComponent di Swing estendono quelli di AWT. Questo permette a Swing di innestarsi al framework di controllo della GUI dell'OS nativo, compresi la cruciale mappatura device/screen e le interazioni dell'utente (come le pressioni dei tasti, i movimenti del mouse, etc.) Swing semplicemente 'traduce' la sua (OS agnostico) semantica su quella sottostante dei componenti dell'OS. Così, per esempio, ogni componente di Swing si disegna sul dispositivo grafico in risposta alla chiamata component.paint(), la quale è definita nel container AWT. Ma, differentemente dai componenti AWT, i quali delegano il disegno ai widget nativi dell'OS, i componenti di Swing sono responsabili della loro stessa renderizzazione.

* Estendibile: Swing è una architettura molto suddivisa la quale permette l'aggancio di varie implementazioni modificate di specifiche interfacce: Gli utenti possono creare le loro personali implementazioni dei componenti per modificare le implementazioni di default. In generale, gli utenti Swing possono estendere il framework con: estensione delle classi esistenti; fornitura di implementazioni native dei componenti base.

* Orientato ai componenti: Swing è un framework basato a componenti. La differenza tra oggetti e componenti è leggera: concisamente, un componente è un oggetto con determinate caratteristiche di comportamento conosciute e specificate. Gli oggetti Swing emettono eventi in modo asincrono, hanno caratteristiche legate ad essi stessi, e rispondono da un ben preciso set di comandi (Specifico per componente). Specialmente i componenti Swing Java Beans, seguono le specifiche dell'architettura Java Bean.

* Modificabile: Dato il modello di renderizzazione programmatico del framework di Swing, è possibile ottenere un preciso controllo del dettaglio sulla renderizzazione dei suoi componenti. Come discorso generale, la rappresentazione grafica di un componente swing è una combinazione di un set standard di elementi, come i bordi, le rientranze, decorazioni, etc. Solitamente, gli utenti modificheranno un componente standard di Swing (come una JTable) assegnando bordi, colori, sfondi specifici come proprietà del componente. Il componente base, userà queste proprietà (o settaggi) per determinare la modalità più appropriata per disegnarsi. Comunque, è anche possibile creare controlli GUI completamente nuovi, con un livello di rappresentazione visuale molto dettagliato (Per esempio, i componenti Swing supportano le trasparenze.)

* Configurabile: Swing, facendo un uso pesante dei meccanismi di runtime e dei percorsi di renderizzazione indiretta, ha la possibilità di modificare a runtime cambiamenti anche fondamentali nei suoi settaggi. Per esempio, una applicazione basata su Swing può cambiare il suo look and feel a runtime (per esempio, dal look and feel di MacOS a quello di Windows XP). Inoltre, gli utenti possono fornire le loro proprie implementazioni di look and feel, il che permette di ottenere cambiamenti uniformi nei look and feel di applicazioni Swing esistenti, senza un continuo ritocco al codice sorgente dell'applicazione.

* Leggero: La magia della configurabilità di Swing è anche dovuta al fatto che non necessita di usare i controlli della GUI dell' OS nativi per la ''rappresentazione'', ma piuttosto 'disegna' i suoi controlli costantemente, attraverso l'uso delle api 2D di Java. Inoltre, un componente Swing non ha un corrispettivo nell'insieme dei componenti nativi dell'OS, ed è quindi libero di renderizzare se stesso in ogni modo possibile con le librerie grafiche di Java 2D.

Comunque, alla base, ogni componente Swing si basa su di un contenitore AWT, dato che i JComponent di Swing estendono quelli di AWT. Questo permette a Swing di innestarsi al framework di controllo della GUI dell'OS nativo, compresi la cruciale mappatura device/screen e le interazioni dell'utente (come le pressioni dei tasti, i movimenti del mouse, etc.) Swing semplicemente 'traduce' la sua (OS agnostico) semantica su quella sottostante dei componenti dell'OS. Così, per esempio, ogni componente di Swing si disegna sul dispositivo grafico in risposta alla chiamata component.paint(), la quale è definita nel container AWT. Ma, differentemente dai componenti AWT, i quali delegano il disegno ai widget nativi dell'OS, i componenti di Swing sono responsabili della loro stessa renderizzazione.

<!-- HELP

Inoltre, questa traduzione e disaccoppiamento, non è puramente visuale, si estende alla gestione dei widget and extends to the Swing's management of, and application of its own OS-indepenent semantics for, events fired within its component containment hierarchies.

-->

Line 48 ⟶ 41:

(Il lettore interessato è incoraggiato a dare uno sguardo al codice sorgente delle classi Container.java e JComponent.java per ulteriori approfondimenti sull'interfacciamento tra i componenti Swing, più leggeri, e quelli AWT, più pesanti).

* Loosely-Coupled/MVC: La libreria Swing fa un forte uso del [[design pattern (computer science)|design pattern]] [[Model-view-controller|Model/View/Controller]], il quale concettualmente disaccoppia i dati mostrati ed i controlli dell'interfaccia utente attraverso i quali sono mostrati. Grazie a questo, la maggior parte dei componenti Swing hanno associati ''modelli'' (specificati in termini di Java [[interfaccia_(informatica)|interfaces]]), il programmatore può usare varie implementazioni di default o crearne di proprie. Il framework provvede implementazioni di default di modelli per le interfacce per tutti i suoi componenti.

Tipicamente, gli oggetti dei modelli dei componenti Swing sono responsabili di provvedere ad una concisa intrfaccia per la definizione degli eventi che vengono emessi, nonché proprietà accessibili per il modello dei dati da usare con i JComponent associati. Dato questo il modello di sviluppo MVC è un loosely-coupled percorso di oggetti in relazione collaborativamente, il modello provvede i consueti modi per creare event listeners aigli oggetti del data model. Tipicamente, questi eventi sono model centric (ad esempio: l'inserimento di righe in un modello di tabella) e sono mappati dalla specializzazione del JComponent in un ben preciso evento per il componente GUI.

* Loosely-Coupled/MVC: La libreria Swing fa un forte uso del [[design pattern (computer science)|design pattern]] [[Model-view-controller|Model/View/Controller]], il quale concettualmente disaccoppia i dati mostrati ed i controlli dell'interfaccia utente attraverso i quali sono mostrati. Grazie a questo, la maggior parte dei componenti Swing hanno associati ''modelli'' (specificati in termini di Java [[interfaccia_(informatica)|interfaces]]), il programmatore può usare varie implementazioni di default o crearne di proprie. Il framework provvede implementazioni di default di modelli per le interfacce per tutti i suoi componenti.

Per esempio, il {{Javadoc:SE|javax/swing|JTable}} ha un modello chiamato {{Javadoc:SE|javax/swing/table|TableModel}} che descrive una interfaccia per come una tabella dovrebbe accedere ai dati. Una implementazione di default di questo opera su di un [[array]] bidimensionale.

Tipicamente, gli oggetti dei modelli dei componenti Swing sono responsabili di provvedere ad una concisa intrfaccia per la definizione degli eventi che vengono emessi, nonché proprietà accessibili per il modello dei dati da usare con i JComponent associati. Dato questo il modello di sviluppo MVC è un loosely-coupled percorso di oggetti in relazione collaborativamente, il modello provvede i consueti modi per creare event listeners aigli oggetti del data model. Tipicamente, questi eventi sono model centric (ad esempio: l'inserimento di righe in un modello di tabella) e sono mappati dalla specializzazione del JComponent in un ben preciso evento per il componente GUI.

La componente visiva di un JComponent Swing è l'oggetto usato per 'rappresentare' graficamente il controllo GUI concettuale. Una distinzione di Swing, come framework GUI, è il suo utilizzo sulla continua rappresentazione di controlli gui (al contrario dell'uso dei componenti nativi della gui dell' OS). (Questa distinzione è fonte di complicazione quando si mischiano controlli AWT, che usano controlli nativi, con controlli Swing in una GUI.)

Per esempio, il {{Javadoc:SE|javax/swing|JTable}} ha un modello chiamato {{Javadoc:SE|javax/swing/table|TableModel}} che descrive una interfaccia per come una tabella dovrebbe accedere ai dati. Una implementazione di default di questo opera su di un [[array]] bidimensionale.

Deve essere notato che il tipico uso del framework Swing, non richiede la creazione di modelli modificati, siccome il framework fornisce un insieme di implementazioni di default che sono trasparentemente, per default, associati con le corrispondenti figlie della classe JComponent nella libreria Swing. In generale, solo componenti complessi come le tabelle e le viste di collezioni ''potrebbero'' aver bisogno di modifiche ai loro modelli di default.

La componente visiva di un JComponent Swing è l'oggetto usato per 'rappresentare' graficamente il controllo GUI concettuale. Una distinzione di Swing, come framework GUI, è il suo utilizzo sulla continua rappresentazione di controlli gui (al contrario dell'uso dei componenti nativi della gui dell' OS). (Questa distinzione è fonte di complicazione quando si mischiano controlli AWT, che usano controlli nativi, con controlli Swing in una GUI.)

Deve essere notato che il tipico uso del framework Swing, non richiede la creazione di modelli modificati, siccome il framework fornisce un insieme di implementazioni di default che sono trasparentemente, per default, associati con le corrispondenti figlie della classe JComponent nella libreria Swing. In generale, solo componenti complessi come le tabelle e le viste di collezioni ''potrebbero'' aver bisogno di modifiche ai loro modelli di default.

(Comunque, per capire bene il potenziale che l'architettura Swing rende possibile, considerate l'ipotetica situazione in cui i modelli modificati delle tabelle e le liste sono creati al di sopra di servizi DAO e/o EJB).

Line 66 ⟶ 58:

==Look and feel==

Swing permette di specializzare il [[Look_and_feel#Look and Feel in Widget Toolkits|look and feel]] dei suoi [[Widget|widget]], modificando quello di default (con parametri a runtime), basandosi su di uno esistente, creandone uno da zero, o, iniziando con '''J2SE 5.0''', usando lo [[skinnable]] {{Javadoc:SE|package=Synth Look and Feel|javax/swing/plaf/synth}}, il quale viene configurato con un file di proprietà [[XML]]. Il look and feel può essere modificato a can be changed at runtime, una prossima dimostrazione di Swing mostrerà spesso come fare.

==Legami con AWT==

Line 72 ⟶ 64:

Al contrario, i componenti Swing sono spesso descritti come ''lightweight'' perché non necessitano l'allocazione di risorse native nel toolkit della GUI del sistema operativo. I componenti AWT vengono detti come ''heavyweight components''.

La maggior parte delle API Swing è generalmente una estensione complementare di AWT piuttosto che un diretto rimpiazzo. Infatti, ogni interfaccia Swing lightweight éè basata su un componente AWT heavyweight perché tutti i componenti top-level in Swing ({{Javadoc:SE|javax/swing|JApplet}}, {{Javadoc:SE|javax/swing|JDialog}}, {{Javadoc:SE|javax/swing|JFrame}} e {{Javadoc:SE|javax/swing|JWindow}}) estendono i container top-level AWT. La funzionalità di renderizzazione usata da Swing per disegnare i suoi componenti è fornita da [[Java2D]], una altra parte di JFC. Comunque l'uso contemporaneo di componenti lightweight ed heavyweight nella stessa finestra è generalmente scoraggiato per incompatibilità di [[Z-order]].

==Legami con SWT==

Lo [[Standard Widget Toolkit]] (SWT) è un toolkit concorrente originalmente sviluppato dalla [[IBM]] ed ora mantenuto dalla [[Eclipse Foundation]]. Le implementazioni SWT sono più in comune con i componenti AWT heavyweight. Questo conferisce benefici come una più accurata fedeltà con il sottostante toolkit window nativo, al costo di una maggior esposizione ad una programmazione più nativa nel modello di programmazione.

L'avvento di SWT ha dato origine ad una grande divisione tra gli sviluppatori del Java desktop con molti fortemente favorevoli a SWT e altri a Swing. Lo sviluppo di Sun su Swing continua a concentrarsi sulla fedeltà del look and feel (PLAF) in ogni toolkit window. Nel frattempo non vi sono altre risorse di PLAFs fedeli, molti dei quali sono nel sito [http://www.javootoo.com/ javootoo].

C'è stato un dibattito significativo sulle prestazioni di SWT rispetto a quelle di Swing; La dipendenza di SWT da JNI lo rende lento quando i componenti GUI e Java necessitano di scambiarsi i dati, ma più veloce a disegnarsi quando il modello dei dati è stato caricato nella GUI.

SWT serve alla piattaforma delle finestre molto bene ma è considerata da alcuni di essere meno efficace come tecnologia per lo sviluppo multipiattaforma. Usando le funzionalità di alto livello dei window toolkit nativi, SWT riporta alla situazione vista negli anni 90 (con toolkit come zApp, Zinc, XVT e IBM/Smalltalk) dove i toolkit cercavano di mascherare le differenze nel comportamento e gestione del focus, della gestione degli eventi e dei layout grafici. Il fallimento di avere eguali comportamenti su ogni piattaforma può causare errori di programmazione subdoli e difficili da risolvere, che impattano sull'interazione dell'utente e sull'aspetto grafico della GUI.

==Esempio==

Il seguente è un programma [[Hello world]] di esempio che usa Swing.

import javax.swing.JFrame;

import javax.swing.JLabel;

import java.awt.EventQueue;

public final class HelloWorld {

public static void main(String[] args) {

// Swing has its own dispatch thread, which is

// distinct from the main JVM (launcher) thread.

// This means that even if the (launcher) thread exited

// (this) main method, the Swing GUI thread would

// still be running, waiting to respond to user input, etc.

// and if the user closes the window, then the program would

// continue to run (due to the live gui thread). As of Java 1.4, the

// GUI thread will automatically stop if all Components are hidden and

// disposed.

//

//

// Execute all GUI code on the event dispatch thread, even initialization:

EventQueue.invokeLater(new Runnable() { public void run() {

// Create frame with title "Hello, World!"

JFrame f = new JFrame("Hello, World!");

// Previously we typically attached a window listener to our main JFrame

// and on windowClosing() event notification callback, we would

// explicitly call System.exit(stat) or some other such nastiness.

// The following is the new (clean) way of defining default close behavior

// for a JFrame. The following will merely dispose the JFrame but it will not

// stop the application unless *all* Windows are disposed.

f.setDefaultCloseOperation (JFrame.DISPOSE_ON_CLOSE);

// this stops the app on window close

// (it is commented out.)

// f.setDefaultCloseOperation (JFrame.EXIT_ON_CLOSE);

// JFrame, which is the 'window' component of Swing, has an interesting feature:

// it has a layered content architecture which (conceptually) allows for placement

// of a component of the JFrame in a designated layer. The layers can be conceptually

// viewed as a series of transparencies placed one above another in a overhead projector

// Swing typically places user components (such as buttons, etc.) in what it calls its

// 'content pane'. This pane is layer that is below most of the other (transparent) layers.

// What are the layers for? Think of when you right-click on a control and it 'pops' a

// contextual menu 'over' the original control; or, when you press 'help' for a control or

// hover the mouse for a 'tool tip' and the information is 'placed over the control'. How is that

// done? By rendering the information in a layer 'above' the lower level 'content' pane.

// So:

// The standard way of adding a component to a 'multi-pane' container such as JFrame is by first

// establishing a reference to its 'content pane' (which is, by default just a JPanel with

// BorderLayout and adding the components the JFrame to the content pane and NOT directly

// to the JFrame. (The latest Swing releasehowever alters the semantics of the JFrame.add(..)

// to assume convenient addition to the content pane).

f.getContentPane().add(new JLabel("Hello, World!"));

// Remember the relative layouts of Swing?

// pack() tells the receiving container (here 'this' JFrame)

// for it to optimally pack its components according to its layout.

f.pack();

f.setVisible(true);

} });

}

}

}

Line 189 ⟶ 181:

[[Categoria:Java]]

[[Categoria:Strumenti di sviluppo]]

[[de:Swing (Java)]]