Quando si tratta di realizzare applicazioni ad elevata interattività l‘approccio “web application” può risultare inadeguato. Optando per una tecnologia Rich Client, le alternative sono varie (Swing, SWT, Eclipse RCP). Fra queste, la soluzione Eclipse RCP risulta particolarmente produttiva e scalabile. In questo primo articolo intendiamo fornire un esempio completo senza dilungarci troppo sui dettagli. Nei prossimi articoli esamineremo con maggiore attenzione i vari aspetti.

Cos‘è Eclipse RCP?

Eclipse è una Piattaforma Open Source per la creazione di ambienti integrati di sviluppo IDE (Integrated Development Environment) e per lo sviluppo di progetti applicativi. In pratica il “prodotto” Eclipse, noto principalmente come ambiente di sviluppo, è stato realizzato attraverso la “piattaforma” Eclipse che può essere utilizzata dallo sviluppatore per creare le proprie applicazioni in architettura Rich Client.
Eclipse può essere vista come un insieme di plug-in per lo sviluppo di applicazioni Rich Client integrate con il sistema operativo grazie alla libreria nativa SWT.
Il fatto di essere una architettura “plug-in oriented” si traduce nella possibilità  di assemblare i singoli moduli, chiamati appunto “plug-in”, in modo da poter estendere, o ridimensionare, la piattaforma a seconda delle esigenze. Per capire la potenza di questo approccio pensate alla facilità  con cui è possibile arricchire l‘IDE Eclispe con nuove funzionalità , semplicemente aggiungendo un nuovo plug-in.

Il sottoinsieme di plug-in necessari per costruire una applicazione Rich Client è noto col nome di Eclipse Rich Client Platform (da cui l‘acronimo RCP). L‘insieme minimo di plug-in per costruire un applicazione RCP con una User Interface è formato dai due plug-in org.eclipse.ui e org.eclipse.core.runtime, che sono sufficienti per realizzare un client minimale.

Eclipse RCP è quindi un framework open source basato su un‘architettura a plug-in che fornisce un insieme di strumenti progettati per la realizzazione di altri plug-in. È possibile costruire un‘applicazione (che non sia necessariamente un IDE), utilizzando un sottoinsieme di plug-in della piattaforma.

La licenza di riferimento è la Eclipse Public License – v1.0 , che permette agli sviluppatori di modificare il codice (open source) e anche di riutilizzarlo all‘interno di prodotti commerciali (free redistribution). La licenza EPL è stata approvata dall‘Open Source Initiative (OSI) [1] (www.eclipse.org/legal/epl-v10.html)

Perchè RCP?

Molte persone che utilizzano Eclipse RCP dicono che il vantaggio maggiormente apprezzabile è la rapidità  con cui si realizzano applicazioni professionali, multi-piattaforma, con look-and-feel nativo: ciò permette loro di dedicare maggior energia alla logica applicativa.

La seconda importante caratteristica è che, come già  detto, la piattaforma ha un‘architettura aperta, estendibile e basata su plug-in. Tale caratteristica ha permesso la crescita della community che gravita intorno ad essa, che conta ad oggi centinaia di plug-in realizzati da aziende, organizzazioni e singoli individui.

Inoltre, utilizzare la piattaforma con cui è fatto l‘IDE per lo sviluppo ci permette di sfruttare nelle applicazioni utente tutti gli strumenti che per uno sviluppatore sono messi a disposizione da Eclipse (Help UI, Update Manager, Cheat Sheets, Intro, etc.), ormai universalmente considerato uno dei migliori IDE Java.

La qualità  dei prodotti Eclipse è garantita dall‘alta qualità  dei componenti, dalla continua manutenzione che viene assicurata da una community molto vasta e infine, ma non per importanza, il suo carattere Open Source.

Eclipse.org

Eclipse.org è un consorzio di vendor (produttori di software) che costituiscono una community il cui obiettivo è migliorare l‘integrazione dei vari prodotti. La community condivide infatti l‘interesse nel creare ambienti di sviluppo specifici, ma tutti caratterizzati da una grande interoperabilità  e facilità  di utilizzo e basati su tecnologia a plug-in.

Estensibilità  della piattaforma è ottenuta attraverso l‘implementazione OSGi (Eclipse 3.0 aderisce completamente allo standard OSGi framework specification R3.0) e più in particolare sulla nozione di bundle, che per quanto riguarda Eclipse è equivalente al concetto di plug-in.

All‘interno del progetto Eclipse, esistono alcuni progetti OpenSource sui quali Eclipse stessa è costruita.

• Business Intelligence and Reporting Tools (BIRT)
• Eclipse Communications Framework (ECF)
• Web Tools Project (WTP)
• Eclipse Modeling Framework (EMF)
• Graphical Editing Framework (GEF)
• Test and Performance Tooling Project (TPTP)

Tutti i progetti di Eclipse sono disponibili gratuitamente per il download, e sono tutti open source: per ogni progetto sono disponibili sul sito eclipse.org i soliti strumenti che caratterizzano questo tipo di progetti (Articles, Wiki, BugTracking, etc…). La community è formata inoltre da centinaia di contributions, che partecipano alla crescita dei progetti e dei plug-in realizzati da aziende, organizzazioni e singoli individui.

Altre risorse importantissime sono la comunità  di blogger (http://www.planeteclipse.org) e i numerosi portali dedicati, tra cui ricordiamo:

• EclipseZone (http://www.eclipsezone.com)
• Eclipse Plug-in Central (http://www.eclipseplugincentral.com)
• le community di Eclipse.org (http://www.eclipse.org/community)

E passiamo ora a presentare un modello di sviluppo “sostenibile”

Una ricerca che parte da lontano

La nascita degli ambienti di sviluppo grafici (Visual Basic, Delphi, i vari IDE basati su Java, etc…) dagli anni Novanta in poi ha determinato un duplice effetto nel mondo dello sviluppo software.
Da un lato l‘IDE ha assunto le caratteristiche di strumento “General Purpose” (in realtà  questa tendenza era già  iniziata con ambienti non grafici, come ad esempio Turbo Pascal) e quindi si sono moltiplicate le possibilità  nella programmazione. Dall‘altro però c‘è stata, per così dire, una sorta di “regressione” per tutto ciò che riguarda la programmazione orientata al database.
Chi ha avuto il piacere e l‘onere di lavorare in Clipper ricorderà  quanto fosse facile e rapido creare una form per la gestione di una tabella. Era sufficiente disporre un campo di tabella sulla form in modo che questo assumesse automaticamente le dimensioni e le caratteristiche appropriate in base alla struttura del database. Nessuna distinzione fra “casella di testo” e “campo della tabella”, nessuna operazione manuale di copia del valore dal record alla form e viceversa (data-binding), nessuna necessità  di introdurre una maschera di immissione o artifici vari per impedire l‘inserimento di caratteri alfanumerici in un campo numerico o per l‘immissione di una data (validazione e conversione).
Certo, si dirà , il numero di gradi di libertà  era notevolmente ridotto. Basti pensare che le schermate erano solo testuali a 80 colonne per 25 righe, il concetto di sovrapposizione di finestre era primitivo e il tipo di database era fisso (DBF), solo per ricordarne alcuni. Già , d‘altra parte sono trascorsi quasi 20 anni da allora, ma proprio per questo molti sviluppatori si trovano oggi a chiedersi “perché per realizzare la gestione di una semplice tabella non mi basta qualche decina di minuti?”.

In questa serie di articoli intendiamo mostrare come l‘utilizzo di Eclipse RCP può farci riavvicinare a un modello di sviluppo più produttivo e quindi riappropriare del concetto di RAD (Rapid Application Development). Il tutto adottando strumenti e tecnologie open source. Be‘, che aspettiamo a vedere subito come funziona?

Un‘applicazione Rich Client in pochi minuti

Presentiamo un tutorial che guida il lettore nella costruzione di una applicazione RCP di esempio. Nei prossimi articoli, forniremo ulteriori dettagli, ma intendiamo intanto dare al lettore qualcosa di “concreto” da cui partire

Cosa serve

Scaricare Eclipse for RCP/Plug-in Developers dal sito http://www.eclipse.org/downloads/ (come si può vedere in figura sono disponibili più versioni a seconda del target di sviluppo e del sistema operativo). Scompattare lo zip in una directory (es: C:/)

 

Figura 1 – Pagina di download di Eclipse

Scaricare e installare Java JDK 5 (o superiore) dal sito http://java.sun.com/javase/downloads/

Come iniziare

Lanciando l‘eseguibile di Eclipse (C:/eclipse/eclipse.exe) si aprirà  il popup per la scelta del workspace come mostrato nella figura 2. Il workspace, letteralmente “spazio di lavoro”, è un‘area del filesystem in cui Eclipse salva tutte le informazioni che riguardano la nostra sessione di lavoro.

 

 

Figura 2 – Popup per la scelta del workspace

Alla prima esecuzione di Eclipse (oppure se il workspace è stato appena creato) sarà  visualizzata la pagina di benvenuto, che contiene informazioni utili per gli utenti alle prime armi. Per chiuderla cliccate sulla X accanto alla label “Welcome”; potrete riaprirla in seguito seguendo la voce di menù Help -> Welcome.

La prima cosa da fare è creare un nuovo progetto. Per far ciò è sufficiente selezionare la voce di menù File -> New -> Project e selezionare dalla lista che appare nella prima pagina dello Wizard la voce Plug-in Project. Premendo il bottone Next sarà  visualizzato la finestra mostrata in figura 3, in cui è possibile specificare il nome del progetto (es: it.mokabyte.rcp.test1).

 

 

Figura 3 – Wizard di creazione del progetto

Per convenzione i nomi dei package contenuti in un plugin devono iniziare con il nome del plugin stesso [1].

Nella schermata successiva, assicuratevi che l‘opzione “Would you like to create a rich client application” sia valorizzata a “Yes” e premete Next. Infine, nell‘ultima schermata, dopo avere selezionato l‘opzione “Create a plug-in using one of the templates”, scegliere dalla lista di template “Hello RCP”e premere Finish. Si aprirà  un popup per il cambio di prospettiva, a cui dovrete rispondere affermativamente.

 

Figura 4 – Struttura del plug-in

A questo punto il progetto è stato creato correttamente e vi trovate davanti la prospettiva di gestione del plug-in da cui potete osservare la struttura (riportata nella figura 4). Sulla sinistra troviamo la vista per esplorare le risorse del progetto, in cui ritroviamo le classi all‘interno del package e altri file che descriveremo più avanti, mentre sulla destra una vista riassuntiva del plug-in. Cliccando su link “Launch an Eclipse application” potete già  vedere il nostro client in esecuzione (figura 5).

 

Figura 5 – La prima esecuzione

In questo primo articolo non ci soffermeremo sulla descrizione delle seguenti classi:

• Activator.java
• Application.java
• ApplicationWorkbench.java
• ApplicationWorkbenchAdvisor.java
• ApplicationWorkbenchWindowAdvisor.java

Esse costituiscono la struttura vera e propria del plug-in, ma la loro conoscenza non è necessaria per lo scopo di questo primo articolo. Analizziamo invece velocemente la classe Perspective.java.

Una Perspective in Eclipse corrisponde a un contenitore per le parti visuali (Views ed Editors) che compongono l‘applicazione. Queste parti possono essere visualizzate solo all‘interno di una prospettiva.

Per capire meglio i concetti di Perspective e View immaginate di trovarvi in una stanza con vari oggetti. Supponiamo che da un qualsiasi punto di osservazione all‘interno di essa riusciate a vedere un sottoinsieme degli oggetti presenti (Views). Cambiando il punto di osservazione (altra Perspective) potrete continuare a vedere alcuni di questi oggetti e non vederne più altri; è inoltre probabile che riusciate a vederne altri che prima non vedevate.
Ritornando al linguaggio Java, una prospettiva è un‘implentazione dell‘interfaccia IPerspectiveFactory.

Dato che la prospettiva non è altro che un contenitore, è necessario definire almeno una view all‘interno della quale disporre i componenti dell‘interfaccia grafica. Per far ciò abbiamo bisogno di modificare la configurazione del plug-in, che è contenuta nei file MANIFEST.MF e plugin.xml.
Cliccando due volte su uno di questi file viene aperta la view (notate come i concetti di perspective e view si applichino sia alla nostra applicazione che all‘IDE che stiamo utilizzando per realizzarla) della gestione del plug-in che abbiamo già  visto (figura 4), ma di cui ora approfondiamo le funzionalità .

È possibile sfogliare le funzionalità  della configurazione attraverso i tab riportati nella parte inferiore della view. Selezionando la voce “Extensions”, si aprirà  la schermata che racchiude le extensions associate al nostro plug-in, che rappresentano unità  riutilizzabili messe a disposizione dai plug-in elencati tra le nostre “Dependencies” (altro tab in basso).
Premendo il bottone “Add…” si apre una popup (figura 6) che permette di selezionare una tra le extensions a nostra disposizione. Digitando “views” nel campo filter sarà  più facile selezionare la voce “org.eclipse.ui.views”; premere Finish dopo averla selezionate per portarla nella lista del nostro plugin.

 

Figura 6 – Aggiungere una Extension

A questo punto, posizionandosi sulla voce appena creata, basterà  cliccare con il tasto destro e selezionare New, view per creare una nuova vista. Come si può vedere nella Figura 7, sulla destra ci sono tutte le proprietà  che caratterizzano la nostra vista, che per il momento lasceremo così.

 

Figura 7 – Creazione di una view

Per creare la classe di implementazione è sufficiente cliccare sul link class*: che scatenerà  l‘apertura della popup di definizione della view nella quale sarà  sufficiente premere il bottone Finish. Dal punto di vista Java, la view non è altro che una classe che estende la classe astratta ViewPart e che quindi deve implementarne i metodi astratti:

public void createPartControl(Composite parent)
public void setFocus()

Il primo serve per la creazione degli oggetti grafici, mentre il secondo è necessario per indicare qual‘è il campo che per primo deve prendere il focus (se lasciato vuoto il primo campo è il default).
Per questo primo esempio ci limiteremo alla creazione di una form semplice, con due campi di input testuali (codice e titolo).
Di seguito riportiamo gli import che è necessario aggiungere alla classe

import org.eclipse.swt.SWT;
import org.eclipse.swt.layout.GridData;
import org.eclipse.swt.layout.GridLayout;
import org.eclipse.swt.widgets.Button;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Text;
  

e il metodo createPartControl()

 

@Override
public void createPartControl(Composite parent) {
 //Container
 Composite container= new Composite(parent,SWT.NONE);
 container.setLayout(new GridLayout(2,false));
 container.setLayoutData(new GridData(GridData.FILL_HORIZONTAL));
 //Campo Codice
 Label lblCodice= new Label(container,SWT.NONE);
 lblCodice.setText("Codice");
 Text txtCodice= new Text(container,SWT.BORDER);
 txtCodice.setLayoutData(new GridData(100,-1));
 //Campo Titolo
 Label lblTitolo= new Label(container,SWT.NONE);
 lblTitolo.setText("Titolo");
 Text txtTitolo= new Text(container,SWT.BORDER);
 txtTitolo.setLayoutData(new GridData(300,-1));
 //Bottone salva
 Button btnSalva= new Button(container,SWT.NONE);
 btnSalva.setText("salva");
  
}
  

Naturalmente esiste un metodo più pratico per disporre i componenti grafici su una form in modo visuale. L‘introduzione all‘uso di Eclipse Visual Editor sarà  infatti oggetto di un prossimo articolo.
In questo articolo non affrontiamo neanche la spiegazione di come si utilizzano le librerie SWT; l‘esempio sopra riportato è abbastanza semplice da permetterne la comprensione anche a chi non è pratico di questa libreria.

Dato che, come abbiamo detto, la perspective è il contenitore che rappresenta il nostro client, è necessario associare la view appena creata alla perspective già  presente nel progetto.
Il caso del nostro esempio è molto semplice e prevede unicamente l‘implementazione all‘interno della classe Perspective del metodo seguente:

 

public void createInitialLayout(IPageLayout layout) {
 String editorArea = layout.getEditorArea();
 layout.setEditorAreaVisible(false);
 layout.setFixed(true);
  
    layout.addStandaloneView("it.mokabyte.rcp.test1.view1", false, 
            IPageLayout.LEFT, 1.0f, editorArea);
}
  

In queste poche righe, oltre ad alcune inizializzazioni standard, viene aggiunta alla prospettiva una vista attraverso l‘istruzione layout.addStandaloneView(), indicandone l‘id specificato nella configurazione.

A questo punto abbiamo finito l‘implementazione e possiamo lanciare per la seconda volta la nostra applicazione attraverso il link “Launch an Eclipse application” nell‘overview del plug-in (come detto qualche riga più in alto) ed otterremo l‘esecuzione come in figura 8.

 

Figura 8 – La seconda esecuzione

Data Binding con EJB 3.0

Il termine “Data Binding” indica un meccanismo di sincronizzazione automatica fra due strutture dati. Nel caso di realizzazione di una interfaccia grafica questo si traduce in un legame automatico fra i valori contenuti nei componenti visuali dell‘interfaccia stessa (p.e. campi di testo, radiobutton, checkbox, etc…) e i corrispondenti attributi delle classi del dominio applicativo (detto anche “modello”).
Nella maggior parte dei progetti software questo tipo di operazione viene effettuata manualmente, cioè è a carico dello sviluppatore. Tuttavia tale approccio si dimostra spesso oneroso, oltre che potenziale fonte di errore. Il meccanismo di data binding rappresenta invece una metodologia efficace e produttiva.

Dato lo scopo introduttivo di questo articolo non entreremo nei dettagli di tale argomento, tuttavia intendiamo esporre i passi da seguire per realizzare una applicazione minimale con uso di data binding. Nel caso specifico intendiamo fare in modo che, su pressione del tasto “Salva”, nella tabella LIBRO venga inserito o aggiornato un record con i valori inseriti dall‘utente nei componenti visuali dell‘interfaccia utente (codice e titolo). Il tutto senza esplicite operazioni di copia di tali valori nel modello, nè dal modello alle strutture di database.

Nel seguito, per gli scopi dell‘esempio, faremo riferimento ad un database MySQL 5. In particolare utilizzeremo il database-schema chiamato “test” che viene normalmente creato durante l‘installazione di default di MySQL.

Per utilizzare l‘implementazione Hibernate di EJB 3.0 occorre effettuare il download delle seguenti librerie:

• Hibernate Core (faremo riferimento alla versione 3.2.5 GA)
• Hibernate Entity Manager (faremo riferimento alla versione 3.3.1.GA)

scaricabili all‘indirizzo www.hibernate.org/6.html. Dopo aver scompattato tali librerie è necessario estrarre da queste i seguenti Jars (non vi scoraggiate, sebbene l‘operazione sia laboriosa verrà  fatta una sola volta per tutte):

• hibernate-3.2/hibernate3.jar

• hibernate-3.2/lib/antlr-2.7.6.jar
• hibernate-3.2/lib/asm.jar
• hibernate-3.2/lib/cglib-2.1.3.jar
• hibernate-3.2/lib/commons-collections-2.1.1.jar
• hibernate-3.2/lib/commons-logging-1.0.4.jar
• hibernate-3.2/lib/dom4j-1.6.1.jar
• hibernate-3.2/lib/javassist.jar
• hibernate-3.2/lib/jta.jar

• hibernate-entitymanager-3.3.1.GA/hibernate-entitymanager.jar

 

• hibernate-entitymanager-3.3.1.GA/lib/ejb3-persistence.jar
• hibernate-entitymanager-3.3.1.GA/lib/jboss-archive-browsing.jar
• hibernate-entitymanager-3.3.1.GA/lib/hibernate-annotations.jar
• hibernate-entitymanager-3.3.1.GA/lib/hibernate-commons-annotations.jar

inoltre sarà  necessario anche il Jar corrispondente al driver JDBC per lo specifico database che intendiamo utilizzare, nel nostro caso si tratta del file mysql-connector-java-5.1.5-bin.jar, contenuto nel prodotto mysql-connector-java-5.1.5 scaricabile all‘indirizzo

http://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-5.1.5.zip/from/pick#mirrors

Questo insieme di Jars costituirà  la base per i nostri progetti che utilizzeranno il modello di sviluppo proposto. È quindi opportuno creare una cartella apposita per le librerie cliccando con il tasto destro del mouse sul progetto e selezionando New -> Folder dandogli come nome “lib”.
A questo punto possiamo procedere copiando ed incollando tutti i Jars elencati sopra all‘interno di tale cartella.
Per poter poi fare in modo che queste librerie siano utilizzabili nel progetto esse devono essere aggiunte al Classpath andando al tab Runtime della gestione del plugin e nella sezione Classpath premere il bottone “Add…”, selezionare tutti i jars della cartella “lib” e premere OK.
Assicuratevi che nella lista sia presente un elemento rappresentato dalla cartella corrente (“.”); in caso contrario premete il bottone “New…”, sostituite il testo proposto “library.jar” con “.” e confermate.

Passiamo ora alla creazione del modello, a quelle classi cioè che modellano il dominio applicativo.
Per questo creiamo un nuovo package it.mokabyte.rcp.test1.domain cliccando con il tasto destro del mouse sul package esistente e selezionando New -> Package come mostrato nella figura 9.

 

 

Figura 9 – Creare un nuovo package

Per creare la classe che rappresenta il nostro modello, cliccare ancora col tasto destro sul nuovo package, selezionare New -> Class, inserire il nome (es: Libro) e premere Finish.
L‘implementazione della classe è riportata di seguito.

 

package it.mokabyte.rcp.test1.domain;
  
import javax.persistence.Entity;
import javax.persistence.Id;
  
@Entity
public class Libro {
  
	private String codice;
	private String titolo;
  
    @Id
 public String getCodice() {
 return codice;
 }
 public void setCodice(String codice) {
 this.codice = codice;
 }
 public String getTitolo() {
 return titolo;
 }
 public void setTitolo(String titolo) {
 this.titolo = titolo;
 }
}
  

Nel codice sopra riportato sono già  presenti le annotation che serviranno ad Hibernate per mappare questo oggetto sulla tabella.

Posizioniamoci ora sulla cartella META-INF e col tasto destro New -> File creiamo il file persistence.xml col seguente contenuto (selezionate il tab “Source” per accedere all‘editor testuale del file):

 version="1.0">
 
 org.hibernate.ejb.HibernatePersistence
 it.mokabyte.rcp.test1.domain.Libro
 
 
  value="com.mysql.jdbc.Driver" />
 
 
  value="jdbc:mysql://localhost:3306/test" />
  value="org.hibernate.dialect.MySQLDialect" />
 
 
 

   

Lo scopo di tale file è quello di fornire ad Hibernate le informazioni per l‘accesso al database (potreste doverle modificare per adattarle al vostro caso specifico, in particolare per ciò che riguarda username e password) e indicare quali classi fanno parte del modello.
Notate che, grazie alla property “hibernate.hbm2ddl.auto” impostata al valore “update”, la tabella LIBRO verrà  creata automaticamente alla prima esecuzione.

Ora è necessaria una classe che si occupi delle varie operazioni di gestione (salvataggio, caricamento, cancellazione) dell‘entità  Libro. Ci limiteremo in questo esempio alle sole operazioni di inserimento e aggiornamento. Per fare ciò creiamo un nuovo package it.mokabyte.rcp.test1.business e al suo interno una classe LibroBusiness con il seguente codice:

 

package it.mokabyte.rcp.test1.business;
  
import it.mokabyte.rcp.test1.domain.Libro;
import javax.persistence.EntityManager;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
  
public class LibroBusiness {
  
    private static EntityManagerFactory emf = 
        Persistence.createEntityManagerFactory("dominioApplicativo");
  
    public static void save(Libro libro) {
 EntityManager em = emf.createEntityManager();
 em.getTransaction().begin();
 em.merge(libro);
 em.getTransaction().commit();
 }
}
  

Come potete osservare qui si fa riferimento all‘unità  di persistenza “dominioApplicativo” definita nel file persistence.xml creato prima e attraverso una istanza di classe EntityManager si realizza il salvataggio (insert o update) dell‘oggetto passato come parametro.

Fin qui ci siamo occupati del mapping fra il modello e la tabella del database. Passiamo ora all‘altro mapping, quello cioè fra interfaccia grafica e modello (data binding). Questa operazione richiede alcune dipendenze aggiuntive nel nostro plug-in, che possono essere incluse attraverso il tab “Dependencies”. Nella sezione Required Plug-ins premiamo “Add…” e, aiutandoci col filtro di ricerca “*databinding”, aggiungiamo i seguenti tre plug-in:

• org.eclipse.core.databinding
• org.eclipse.core.databinding.beans
• org.eclipse.jface.databinding

Dopo aver salvato la configurazione (File -> Save) à© inoltre necessario aggiornare la lista dei plug-in da caricare in fase di esecuzione selezionando dal menu di Eclipse Run -> Open Run Dialog…, andando al tab Plug-ins, premendo il bottone Add Required Plug-ins e poi Close, confermando la richesta di salvataggio.

Passiamo ora alle modifiche necessarie alla classe View per l‘implementazione del data binding e dell‘operazione di salvataggio:

Per prima cosa avremo bisogno di una variabile globale Libro che rappresenterà  il modello da associare alla form.

private Libro libro = new Libro();

Nel metodo createPartControl poi gli attributi di tale modello (libro.codice e libro.titolo) vengono legati col meccanismo di data binding ai componenti grafici della form (txtCodice e txtTitolo) attraverso il seguente codice:

DataBindingContext dbc = new DataBindingContext();
 dbc.bindValue(SWTObservables.observeText(txtCodice,SWT.Modify),
	 BeansObservables.observeValue(libro,"codice"),null,null);
	 dbc.bindValue(SWTObservables.observeText(txtTitolo,SWT.Modify),
	 BeansObservables.observeValue(libro,"titolo"),null,null);

Infine, all‘evento corrispondente alla selezione del bottone “Salva”, viene richiamato il metodo statico save della classe di business passando il modello che, tramite il data binding, risulterà  sincronizzato con i valori inseriti dall‘utente nei campi della form.

 btnSalva.addSelectionListener(new SelectionAdapter(){
 @Override
 public void widgetSelected(SelectionEvent e) {
 LibroBusiness.save(libro);
 }
 });

Per completezza riportiamo le import aggiuntive necessarie:

import it.mokabyte.rcp.test1.business.LibroBusiness;
import it.mokabyte.rcp.test1.domain.Libro;
import org.eclipse.core.databinding.DataBindingContext;
import org.eclipse.core.databinding.beans.BeansObservables;
import org.eclipse.jface.databinding.swt.SWTObservables;
import org.eclipse.swt.events.SelectionAdapter;
import org.eclipse.swt.events.SelectionEvent;

Possiamo finalmente lanciare la nostra applicazione dal menu Run -> Run, inserire dei valori nei campi codice e titolo, premere il bottone “Salva” e verificare che sulla tabella LIBRO sia stato effettivamente inserito un record con i valori inseriti. Dopo alcune prove di inserimento possiamo poi reimmettere un valore già  utilizzato nel campo codice e verificare che venga eseguito un update del corrispondente record.
Concludendo questo nostro primo articolo suggeriamo come esercizio di sperimentare quanto sia minimo l‘impatto sul codice nel caso di aggiunta di un nuovo attributo sul modello. Supponendo infatti di dover aggiungere l‘attributo “autore” si tratterà , dopo aver aggiunto il campo sulla tabella e il campo di testo sulla form, di aggiungere la sola riga di data binding.

Conclusioni

Questo articolo aspira ad essere un‘introduzione alla progammazione per la creazione di una applicazione Rich Client con piattaforma Eclipse RCP. Esso presenta un esempio pratico (la cui implementazione è assolutamente da ritenersi una semplificazione a scopo didattico) in cui, partendo dal download degli strumenti necessari allo sviluppo, siamo arrivati ad una piccola applicazione in grado di inserire i dati in una tabella.
Negli articoli che seguiranno nei prossimi mesi, vedremo come arricchire la nostra applicazione utilizzando tutte le funzionalità  che la piattaforma RCP ci mette a disposizione.

Riferimenti

[1] Eclipse Naming Conventions
http://wiki.eclipse.org/Naming_Conventions

[2] EclipseZone
http://www.eclipsezone.com

[3] Eclipse Plug-in Central
http://www.eclipseplugincentral.com

[4] Eclipse Community
http://www.eclipse.org/community