Swing (Java): differenze tra le versioni

Versione delle 07:17, 23 mar 2011

Versione delle 07:34, 23 mar 2011

Riga 12:

== Architettura ==

Swing è una libreria

Swing è un modello di programmazione per il Java:

* indipendente dalla [[piattaforma (informatica)|piattaforma]]

* orientato ai componenti

Riga 26:

;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 asu componenti. La differenza tra oggetti e componenti è leggera: concisamentein breve, un componente è un oggetto con determinate caratteristiche di comportamento conosciute e specificate. Gli oggetti Swing emettono [[evento (informatica)|eventi]] in modo asincrono, hanno caratteristiche legate ad essi stessi, e rispondono da un ben preciso set di comandi (Specifico per componente). In particolare i componenti ''Swing Java Beans'' seguono le specifiche dell'architettura [[JavaBean]].

;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 modificherannomodificano 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. ComunqueIn aggiunta, è 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 configurabilità di Swing è anche dovuta al fatto che non necessita di usare i controlli della GUI del [[sistema operativo|SO]] nativi per la ''rappresentazione'', ma piuttosto "disegna" i suoi controlli costantemente, attraverso l'uso delle [[Application programming interface|API]] 2D di Java. Inoltre, un componente Swing non hadeve necessariamente un corrispettivo nell'insieme dei componenti nativi del SO, ed e questo significa che è quindipossibile liberorealizzare dicomponenti [[render]]izzarecon sela stessomassima inlibertà, ognisfruttando modoa possibilepropria condiscrezione le potenzialità messe a disposizione dalle librerie grafiche di Java 2D.

Il principale vantaggio della libreria Swing è che essa permette al programmatore di astrarsi dai vincoli imposti dall'architettura del sistema grafico adottato dal sistema operativo in uso. Il sistema grafico AWT risente di queste limitazioni, in quanto l'insieme dei componenti e le caratteristiche che questi ultimi offrono all'applicazione sono ristretti ad uno standard comune, un minimo denominatore che possa essere supportato da tutti i sistemi operativi sui quali AWT deve funzionare.

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 del SO 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 (SO agnostico) [[semantica]] su quella sottostante dei componenti del SO. 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 del SO, i componenti di Swing sono responsabili della loro stessa renderizzazione.

I componenti Swing gestiscono in modo autonomo la propria grafica e il proprio comportamento; è pur vero che il rendering finale deve essere affidato al sistema operativo, in quanto è quest'ultimo che ha in mano la gestione delle periferiche video e delle periferiche che segnalano l'input utente (tastiera, mouse, rotellina del mouse, ecc.), ma è anche vero che Swing "traduce" la sua [[semantica]] su quella sottostante dei componenti del SO con un legame molto più debole rispetto a quanto l'architettura stessa dell'AWT consentiva di ottenere. <br/>

<!-- HELP

Così, per esempio, di fatto ogni componente di Swing si disegna sul dispositivo grafico del sistema operativo servendosi di un [[wrapper]] opportunamente implementato in Java (realizzato tramite un oggetto <tt>java.awt.Graphics</tt>). Ma, differentemente dai componenti AWT, i quali delegano il disegno ai widget nativi del SO, i componenti di Swing sono responsabili della loro stessa renderizzazione.

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.

-->

Soprattutto, l'architettura di Swing delega il compito del mappaggio di tutte le sfaccettature della semantica della GUI del SO in un semplice, ma generalizzato percorso al contenitore AWT. Poi, costruito su di una piattaforma generale, crea le sue proprie ricche e complesse semantiche della GUI, sotto forma della classe JComponent<ref>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</ref>.