�ݺ�ߣ

Sviluppo di applicazioni in E(fx)clipse
capitolo 02-rev01-20072018
Nelson Firmani
1. E(fx)clipse application project
Eclipse 4 Application Platform (e4) permette di sviluppare un sistema software di alta qualità e in tempi
prefissati.
Tecniche di programmazione come l’iniezione delle dipendenze, il modello di applicazione, look-and-feel delle
UI con lo stile CSS, il framework di rendering, il sistema degli eventi e i servizi OSGi riducono la complessità
e lo sforzo per sviluppare applicazioni rich client.
La piattaforma ha un‘architettura aperta, estendibile e basata su plug-in. Tale caratteristica permette una debole
dipendenza tra i vari moduli consentendo ad esempio l’utilizzo di una qualsiasi tecnologia UI come il framework
e(fx)clipse che fornisce i renderer JavaFX per scrivere applicazioni JavaFX RCP.
L’architettura basata su plugin o bundle ha inoltre permesso la crescita di centinaia di plug-in realizzati da
aziende, organizzazioni e singoli individui.
In Eclipse-RCP tutto è un plugin e ognuno di questi plugin può concorrere a diventare parte di altri plugin o
di una applicazione.
La particolarità di quest’architettura è che, ad eccezione del Platform Runtime, tutti i componenti, anche quelli
forniti di default, sono di fatto dei plug-in.
Un plug-in è la più piccola unità funzionale sviluppabile e distribuibile separatamente, così come un bundle
nello standard OSGi indica un modulo. Il plug-in e bundle nel contesto Eclipse sono intercambiabili, infatti un
plug-in Eclipse è anche un bundle OSGi e viceversa. I plug-in di Eclipse sono costituiti da codice Java (raccolto
in un archivio JAR), due file di manifesto (manifest.mf e plug-in.xml) e altre risorse di vario
genere (immagini, file, etc.).
Dal wizard javaFX→OSGI→e4 Application project è possibile creare un’applicazione Eclipse RCP (e4).
1

Sviluppo di applicazioni in E(fx)clipse capitolo 02-rev01-20072018
Figure 1. Prima pagina del wizard: proprietà del progetto di un’applicazione e4 javaFX
Figure 2. Seconda pagina del wizard: personalizzazione del progetto e4 FX
Un’applicazione Eclipse RCP (e4) è costituita da un gruppo di progetti, la struttura iniziale creata dal wizard
è costituita da:
2

• feature: un insieme un raggruppamento di moduli (plug-in, bundle, feature) che possono essere gestiti
come una singola entità (Eclipse usa features per gestire i processi di build e update)
• product: Definisce la configurazione di un’applicazione Eclipse. Il file di configurazione .product oltre che
definire la classe di applicazione del launcher specifica il set di plug-in o feauture inclusi nel prodotto,
specifica il plug-in che contiene la schermata iniziale, il nome e l’icona del launcher del prodotto, i parametri
per l’applicazione Eclipse e gli argomenti per l’ambiente runtime Java.
• releng: (release engineering) fornisce servizi e strumenti per l’automazione del rilascio del prodotto finale.
Figure 3. Struttura del progetto it.nelson.xbrl.client
1.1. target platform
E' buona prassi definire una target platform che esplicita in un file di configurazione i bundle/plugin necessari.
In questo modo le dipendenze dei plug-in e le versioni utilizzate vengono controllate e specificate durante lo
sviluppo.
Tale file di configurazione viene in genere condiviso tra gli sviluppatori per garantire che tutti stiano utilizzando
gli stessi moduli/plugin/bundle con le stesse versioni per lo sviluppo.
La definizione del file di una target platform può essere creata tramite il wizard evidenziato dalle seguenti figure:
Si crea un nuovo progetto:
3

Figure 4. Wizard creazione di una nuova risorsa per il progetto
Figure 5. Nome del progetto
4

Si aggiunge il riferimento al gruppo di progetti dell’applicazione
Figure 6. Selezione progetti di riferimento
Figure 7. Struttura del progetto it.nelson.xbrl.client
Si aggiunge il file di configurazione della target platform
5

Figure 8. Definizione di una target platform
Figure 9. Inizializzazione di una Target platform da un template vuoto
6

Figure 10. Template target platform vuoto
E' possibile aggiungere la locazione del set di plugin da aggiungere alla target platform
Figure 11. Sorgente dei plug-in
Se la locazione è un sito di aggiornamento di Eclipse p2, allora basta selezionare il sito software specificando
l’URL.
7

Figure 12. Runtime Updatesite: http://download.eclipse.org/efxclipse/runtime-nightly/site
Figure 13. Plug-ins disponibili
8

Una volta definito il target platform, può essere impostata come piattaforma attiva
Figure 14. Target platform attiva
1.2. Product
Un prodotto è un’estensione al punto di estensione org.eclipse.core.runtime.products.
Lo scopo di un prodotto è definire un ID univoco, un nome, una descrizione e una configurazione minima
dell’applicazione.
Un prodotto punta sempre a una classe di applicazione. Le classi predefinite per le applicazioni Eclipse sono:
• org.eclipse.e4.ui.workbench.swt.E4Application: per le applicazioni Eclipse RCP con framework UI swt
• org.eclipse.ui.ide.workbench: per le applicazioni basate su IDE Eclipse
• org.eclipse.fx.ui.workbench.fx.application: per le applicazioni Eclipse RCP con framework UI JavaFX
Attraverso l’editor del file di configurazione .product è possibile nella scheda Overview
puntare alla classe di applicazione. Il wizard di creazione del progetto imposta di default
org.eclipse.fx.ui.workbench.fx.application. Da questa scheda inoltre è possibile avviare l’applicazione in
modalità test o in modalità debug
9

Figure 15. Tab overview del product
nella scheda Launching è possibile inserire i parametri per l’applicazione Eclipse e gli argomenti per l’ambiente
runtime Java
Figure 16. Tab launching del product
10

1.3. Application model e4xmi
Application.e4xmi rappresenta il modello della nostra applicazione. Una struttura gerarchica ad albero che
contiene sia elementi visuali della UI che non visuali.
Ad esempio, dall’editor del modello e4, espandendo il nodo Application e i vari sottonodi, si possono definire tutti
gli elementi visuali (finestre, parti, menu, toolbar, etc) e non visuali (gestori di eventi, comandi, etc) contenute
dall’applicazione. Selezionando qualsiasi elemento nell’albero verrà aperta una vista dettagliata sul lato destro,
che consente di modificare le proprietà di quell’elemento.
Tra le proprietà oltre ad un identificatore ID si ha una URI (Uniform Resource Identifier) per il collegamento di
elementi del modello a classi e risorse.
Si ha due pattern di URI:
1. bundleclass://Bundle-SymbolicName/package.classname per le classi java
2. platform:/plugin/Bundle-SymbolicName/path/filename.extension per le risorse
Il modello iniziale generato dal wizard contiene già una finestra TrimmedWindow. Selezionando questo
elemento è possibile, ad esempio, modificare le dimensioni di questa finestra nei campi Bound(x,y,w,h) oppure
il titolo nel campo Label etc.
I singoli widget dell’interfaccia utente, che sono visualizzati in una part, non sono definiti tramite il modello
dell’applicazione, ad esempio, il contenuto della part è definito dal codice sorgente della classe java collegata.
Nella maggior parte dei casi Eclipse istanzia pigramente gli oggetti o le risorse. Ad esempio, le classi di una
part vengono istanziate quando la part diventa visibile.
Figure 17. Application model
Application.e4xmi è un file statico, si trova nella directory principale del plug-in ed è riferito attraverso il valore
della proprietà applicationXMI del punto di estensione product (org.eclipse.core.runtime.products) Questo file
11

viene letto all’avvio dell’applicazione e viene utilizzato per costruire il modello dell’applicazione runtime cioè la
creazione dell’insieme degli oggetti del modello.
Dall’editor plugin.xml
Figure 18. Punto di estensione per Application.e4xmi
Dal sorgente plugin.xml
Proprietà "applicationXMI" presente nel file plugin.xml.
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin>
<extension id="product" point="org.eclipse.core.runtime.products">
<product name="it.nelson.xbrl.client" application="org.eclipse.fx.ui.workbench.fx.application" >
<property name="appName" value="it.nelson.xbrl.client" />
<property name="applicationXMI" value="it.nelson.xbrl.client.app/Application.e4xmi" />
<property name="cssTheme" value="theme.default" />
<property
name="lifeCycleURI"
value="bundleclass://it.nelson.xbrl.client.app/
it.nelson.xbrl.client.app.lifecycle.E4LifeCycle">
</property>
</product>
</extension>
</plugin>
Questo modello di applicazione runtime è dinamico, cioè è possibile modificare gli oggetti del modello e i
relativi attributi e tali modifiche si riflettono nell’applicazione. Il modello di applicazione è estensibile, altri plug-
in possono contribuire all’applicazione (essa stessa un plug-in) tramite model processors and model fragments
Esempio di un elemento fragment del file plugin.xml.
<?xml version="1.0" encoding="UTF-8"?>
<plugin>
<extension
id="it.nelson.xbrl.client.db.fragment"
point="org.eclipse.e4.workbench.model">
<fragment
uri="fragment.e4xmi">
</fragment>
</extension>
12

</plugin>
Dalla scheda overview del product è possibile eseguire l’applicazione:
Figure 19. Tab overview del product
Figure 20. Applicazione in esecuzione
L’ide eclipse permette l’esportazione dell’intero progetto in un file di archivio.
13

Figure 21. Esportazione progetto
1.4. Add-on
Servizi aggiuntivi di drag and drop, min max delle finestre e ciclo di vita possono avvenire mediante l’inserimento
di elementi add-ons nel modello di applicazione:
org.eclipse.fx.ui.workbench.renderers.base.addons.DnDAddon
org.eclipse.fx.ui.workbench.renderers.base.addons.CleanUpAddon
org.eclipse.fx.ui.workbench.renderers.base.addons.MinMaxAddon
org.eclipse.fx.ui.workbench.services.lifecycle.LifecycleAddon
Ad esempio org.eclipse.fx.ui.workbench.renderers.base.addons.DnDAddon aggiunge il supporto per il drag
and drop per riordinare, dividere e riunire delle PartStacks. Il comportamento predefinito può essere cambiato
attraverso il servizio org.eclipse.fx.ui.workbench.renderers.base.services.DnDFeedbackService
così come i colori possono cambiare attraverso elementi css:
.tab-outline-marker {
-fx-fill: blue;
}
.position-marker {
-fx-fill: red;
}
Editor per l’aggiunta di add-on al modello
14

Figure 22. Add-on
Add-on per il suppporto del drag and drop delle part.
Figure 23. Add-on drag and drop
Class-URI del add-on
15

Figure 24. Add-on class uri drag and drop
Esecuzione dell’applicazione e verifica
Figure 25. Add-on drag and drop in esecuzione
Add-on per il suppporto della minimizzazione/massimizzazione delle part.
16

Figure 26. Add-on min max
Dettaglio degli add-on nel sorgente XMI del modello
Figure 27. Dettaglio del sorgente XMI dell’application model
1.5. Project object model (POM)
Costruzione dell’applicazione Eclipse con Maven Tycho (Processo di build di products Eclipse con Maven
Tycho)
Tycho è un insieme di plugin Maven ed estensioni per la creazione di plugin Eclipse e bundle OSGi tramite il
sistema di generazione Maven. Tycho supporta bundles, fragments, features, update site projects (basati su
p2) e RCP applicazioni.
Tycho, per quanto possibile, utilizza i metadati dei componenti di Eclipse. Ad esempio, Tycho determina le
dipendenze di un plug-in tramite il file MANIFEST.MF.
Per configurare e per alimentare-guidare il processo di build, Tycho utilizza i file di configurazione standard
di Maven chiamati file pom.xml (project object model). La cartella che contiene il file pom responsabile del
processo di build è .releng (releng sta per release engineering)
Editor configurazione del file pom.
17

Figure 28. Configurazione pom.xml
File di configurazione pom con il dettaglio dei moduli del progetto.
18

Figure 29. Dettaglio moduli aggiunti al progetto releng nel file di configurazione pom.xml
Dopo la configurazione del file pom della cartella .releng, è possibile con il comando mvn clean install creare e
installare il componente (products) eclipse nel repository maven locale con le dipendenze dei plug-in necessari.
Questo comando esegue ogni fase del ciclo di vita predefinito della build nell’ordine (validate, compile, package
quindi install).
Cartella product prima del processo di build
Figure 30. Cartella del progetto product
Maven clean per cancellare eventuali compilati precedenti dal progetto
19

Figure 31. Maven clean
Figure 32. Risultato maven clean
Maven install per depositare il pacchetto generato nel repository locale;
20

Figure 33. Maven install
Il processo maven install crea una cartella target
Figure 34. Risultato maven install creazione cartella target
21

Figure 35. Risultato maven install installazione nel repository maven locale
Cartella releng prima della creazione dell’applicazione
Figure 36. Cartella del progetto releng
Nella cartella .releng il file build.xml definisce un progetto Ant composto da target in cui sono elencati i task,
le istruzioni da eseguire per creare l’applicazione.
22

Figure 37. Ant build
L’esecuzione Ant dello script build.xml crea la cartella deploy
Figure 38. Risultato Ant buil con creazione della cartella deploy
23

Cartella deploy con il file eseguibile
Figure 39. Eseguibile
Esecuzione dell’applicazione al di fuori dell’ambiente di sviluppo.
Figure 40. Eseguibile avviato
1.6. Decorazione dell’applicazione: aggiunta delle classi di gestione delle parts:
treeshow, overview e detail
Creazione package it.nelson.xbrl.client.app.parts
24

Figure 41. Wizard java package
Creazione classe TreeView
Figure 42. Wizard java class
Collegamento della part treeshow con la corrispondente classe di controllo-gestione TreeShow
25

Figure 43. Mappaggio classe e part
Creazione della classe OverView mediante l’hyperlink ClassURI di mappaggio della part overview
Figure 44. Creazione classe OverView
Il template della classe generata dal wizard E4 ha una dipendenza dalla classe
org.eclipse.swt.widgets.Composite del framework SWT (Standard Widget Toolkit) non presente nel
runtime target platform di e(fx)clipse. Va sostituito con un layout di javaFX ad esempio con il layout
javafx.scene.layout.BorderPane
26

Figure 45. Template predefinito per E4 e non per e(fx)clipse
Figure 46. Classe corretta
27

Figure 47. Collegamento con la classe Overview
Figure 48. Sorgente che necessita l’import di package
Esistono modi alternativi per esprimere le dipendenze, in particolare l’intestazione Require-Bundle è un
legame a grana più grossa in quanto la dipendenza è con l’intero bundle mentre nell’intestazione Import-
Package la dipendenza è con i package specificati
Risoluzione delle dipendenze facilitate dal content assist di eclipse
28

Figure 49. Aggiunta bundle nel manifest con intestazione Require-Bundle
Visualizzazione delle dipendenze dall’editor del plugin
Figure 50. Dettaglio dipendenze dall’editor del plugin
La classe Overview necessita di metodi della libreria Jersey JAX-RS 2.1
29

Figure 51. Sorgente necessita di libreria esterna (jar archives)
Creazione modulo di dipendenza da librerie esterne mediante wizard
Figure 52. Wizard per creare un plugin con jar archives
30

Figure 53. Wizard jar archives da includere
31

Figure 54. Wizard proprietà del plugin
32

Figure 55. Aggiunta del nuovo plugin al working set
Figure 56. Package esportati dal plugin it.nelson.xbrl.client.libs
33

Figure 57. Descrittore plugin delle dipendenze richieste
Risoluzione delle dipendenze mediante l’aggiunta del plugin appena creato it.nelson.xbrl.client.libs al plugin
it.nelson.xbrl.client.app
Figure 58. Aggiungere la dipendenza del plugin it.nelson.xbrl.client.libs
34

Figure 59. Aggiunta la dipendenza dal plugin it.nelson.xbrl.client.libs
Correzione del sorgente mediante il package necessario ora visibile
Figure 60. Correzione sorgente mediante import package
35

Figure 61. Sorgente corretta
36

�ݺ�ߣ

Sviluppo di applicazioni in E(fx)clipse capitolo 02-rev01-20072018

Recommended

More Related Content

Similar to Sviluppo di applicazioni in E(fx)clipse capitolo 02-rev01-20072018 (20)

More from Nelson Firmani (11)

Sviluppo di applicazioni in E(fx)clipse capitolo 02-rev01-20072018