Archivi categoria: DOCUMENTAZIONE

La categoria contiene tutta la documentazione disponibile per la consultazione

TUTORIAL SENCHA GXT 1 – LAVORARE CON MAVEN

Iniziamo una serie di articoli dedicati a Ext GWT, più brevemente GXT, il framework sviluppato da Sencha, che consente di estendere le potenzialità della libreria del Google Web Toolkit.

In questo articolo ci preoccupiamo di configurare un progetto GXT usando Maven ed Eclipse come IDE. Per configurare Eclipse occorre scaricare la versione Juno (4.2) , installare il GWT plugin usando l’update site disponibile all’url http://dl.google.com/eclipse/plugin/4.2 e installare m2eclipse tramite l’update site disponibile all’url http://download.eclipse.org/technology/m2e/releases.

Configurato Eclipse realizziamo il nostro primo progetto avvalendoci di maven e dell’archetipo gwt-maven-plugin tramite la direttiva

Tramite questa direttiva maven crea un progetto che supporta l’alberatura di GWT. Durante l’esecuzione della direttiva specifichiamo il nome del modulo principale (nel mio caso Application), ovvero la classe che implementa l’entry point, il punto di accesso alla nostra applicazione.

A questo punto tramite la direttiva mvn gwt:eclipse possiamo generare i file necessari ad effettuare l’import in Eclipse.

Resta da aggiungere la dipendenza da GXT, agendo sul pom.xml e sul file xml associato al modulo entry point.

Aggiungiamo la versione di GXT da usare tramite il tag <gxt.version>3.0.1</gxt.version>

Specifichiamo il repository  da cui scaricare i sorgenti di GXT

E infine aggiungiamo la dipendenza da GXT tramite il blocco

Una volta aggiunta la dipendenza rendiamola attiva nel progetto eclipse tramite la direttiva mvn gwt:eclipse che si preoccuperà di scaricare le nuove librerie.

Resta da modificare il modulo Application.gwt.xml per rimuovere il tema di GWT e innestare l’eredità da GXT tramite il comando

e linkare il file reset.css nella pagina Application.html tramite la direttiva

Nel file Application.java sostituiamo il gwt-button con un oggetto sencha com.sencha.gxt.widget.core.client.button.TextButton  e se abbiamo operato correttamente tramite la direttiva mvn gwt:run possiamo verificare che il progetto venga avviato correttamente.

XML TUTORIAL – 6 – USARE XMLBEANS

Con l’articolo di oggi vediamo in dettaglio come sfruttare una delle librerie più note nella gestione dei file XML, ovvero XMLBEANS dell’Apache Software Foundation.

Questa libreria permette di generare a partire dallo schema XSD tutte le classi per la manipolazione di file xml che rispettino lo schema dato.

Per l’installazione rimando alla guida esauriente presente sul sito di XMLBEANS. Per l’utilizzo vediamo invece quali sono gli step da seguire.

Individuiamo uno schema XSD, da cui generare le nostre classi e scegliamo la struttura libro.

Tramite la direttiva scomp posso generare la libreria contenente le classi per la manipolazione dei file.

Con questo comando dico a XmlBeans di generare un jar che libro.jar secondo gli standard di java 1.5

A questo punto importanto la libreria dentro un qualsiasi progetto posso creare file xml in accordo con lo schema definito o validare dei file xml esistenti.

Lettura File XML

In questo modo posso instanziare un oggetto libro ottenuto dalla lettura del file xml

Creazione File XML

In questo modo posso creare un file xml a partire dall’oggetto java.

Validazione File XML

Ultimo caso, ma non per questo meno interessante, prevede lo scenario in cui l’utente vuole verificare se il file da analizzare rispetta lo schema e in caso negativo in quali punti non è corretto.

 

XML TUTORIAL – 5 – XSD E PARSER

Per poter validare un file XML occorre indicare al parser dove recuperare lo schema. Tale informazione può essere indicata  nell’elemento radice del file usando i tag xmlns:xsi e xsi:noNamespaceSchemaLocation.

L’attributo xmlns:xsi indica un URL che specifica la modalità con cui si indicherà il riferimento allo schema XML, mentre l’attributoxsi:noNamespaceSchemaLocation indica il nome e l’eventuale percorso del file contenente lo schema XML di riferimento.

Concetto fondamentale è quello del namespace, che permette di individuare univocamente un tipo all’interno del file xml, qualora all’interno del file sia presenti grammatiche diverse.

Per namespace si intende un insieme di nomi di elementi e nomi di attributi identificati univocamente da un identificatore.

Per definire un namespace si usa l’attributo xmlns associato al root element, come nel seguente esempio:

Questa formula indica che l’elemento articolo ed i suoi sottoelementi utilizzano i nomi definiti nel namespace identificato dall’identificatore http://www.valeriofinazzo.it/libro. Il valore del namespace è una stringa libera, che per prassi, viene indicata tramite una URI, Uniform Resource Identifier.

È possibile creare delle abbreviazioni per fare riferimento ai namespace, costituite da caratteri alfanumerici seguiti da due punti (:) dichiarati nel root element ed utilizzati come prefissi dei nomi degli elementi.

Es. <lib:libro titolo=”Titolo” xmlns:lib=”http://www.valeriofinazzo.it/libro”  >

XML TUTORIAL – 4 – XML SCHEMA DEFINITION

Dopo aver visto i limiti del DTD analizziamo l’altra soluzione che li supera e permette una definizione univoca di tutte le caratteristiche di un file xml.

L’XML Schema introduce il concetto di tipo di dato semplice per definire gli elementi che non possono contenere altri elementi e non prevedono attributi. Tali dati semplici possono essere utilizzati per definire elementi più complessi.

Sono previsti dei dati predefiniti come ad esempio l’integer, che definisce un numero intero oppure è possibile definire altri tipi semplici.

Ad esempio <xs:element name=”nome” type=”xs:string” /> preveve che l’elemento name in un documento XML possa contenere una sequenza di caratteri.

A partire dai dati predefiniti è possibile definire altri tipi di dati semplici, potendo aggiungere ulteriori restrizioni. Ad esempio possiamo ridefinire l’elemento nome aggiungendo che sia una stringa di almeno 5 caratteri. La definizione di un tipo semplice utilizza il tag simpleType.

In altre parole, la dichiarazione indica che l’elemento <quantita> è di tipo semplice e prevede una restrizione sul tipo di dato intero predefinito accettando valori compresi tra 1 e 100.

Per dato complesso si intende un elemento che possa contenere altri elementi o avere attributi. La definizione di un elemento complesso si avvale del tag complexType. Per definire gli elementi che un elemento complesso sono disponibili 3 costruttori diversi:

  • <xs:sequence> Consente di definire una sequenza ordinata di sottoelementi
  • <xs:choice> Consente di definire un elenco di sottoelementi alternativi
  • <xs:all> Consente di definire una sequenza non ordinata di sottoelementi

Per ciascuno di questi costruttori e per ciascun elemento è possibile definire il numero di occorrenze previste utilizzando gli attributi minOccurs e maxOccurs.

Per definire gli attributi di un elemento si usa il tag <xs:attribute>, che può essere dichiarato opzionale o obbligatorio.

XML TUTORIAL – 3 – DOCUMENT TYPE DEFINITION

Il Document Type Definitio, detto Dtd, è un documento che descrive i tag previsti in un documento XML, la loro relazione e le informazioni sugli attributi di ciascun tag.

All’interno di un Dtd si individuano essenzialmente 2 tag:

  • <!ELEMENT>
  • <!ATTLIST>

<!ELEMNT> definisce gli elementi del documento, la loro relazione e di conseguenza la struttura del documento.

<!ATTLIST> definisce la lista di attributi di ciascun elemento.

La sintassi del Dtd prevede l’utilizzo di alcuni operatori per individuare l’occorrenza degli elementi in uno schema.

  • + indica che l’elemento è presente una o più volte

  • * indica che l’elemento è presente zero o più volte

  • ? indica che l’elemento è presente zero o una sola volta

Dunque un DTD del genere <!ELEMENT libro(autore, capitolo+)> indica che un libro contiene un elemento autore e una o più occcorenze di un elemente capitolo.

Per gestire il contenuto di un elemento si posso usare le parole chiavi EMPTY, PCDATA, CDATA e ANY.

Un tag vuoto viene definito come <!ELEMENT vuoto EMPTY>, un tag che contiene solo testo prevede una definizione del tipo <!ELEMENT text (#PCDATA)>, se non sono noti valori a priori si usa ANY con una dichiarazione del tipo <!ELEMENT jolly ANY>

Per definire gli attributi di un elemento si usa il tag <!ATTLIST>, con l’ausilio delle parole chiavi

  • #REQUIRED (obbligatorio)
  • #IMPLIED     (opzionale)

  • #FIXED        (valore fisso)

Ad esempio la dichiarazione <!ATTLIST libro titolo   CDATA #REQUIRED > indica che l’elemento libro ha un attributo obbligatorio di tipo testo denominato titolo.

Per indicare il Dtd cui fa riferimento un file XML è possibile seguire 2 approcci: inserire il Dtd all’interno del file XML utilizzando il tag !DOCTYPE oppure inserendo il path del file Dtd, che può essere un path locale o un indirizzo web.

es. 1  <?xml version=”1.0″><!DOCTYPE libro[…Definizioni del Dtd…]>

es. 2  <?xml version=”1.0″><!DOCTYPE libro SYSTEM “articolo.dtd”>

es.3  <?xml version=”1.0″><!DOCTYPE articolo SYSTEM http://www.valeriofinazzo.it/libro.dtd”>

Con l’uso dei Dtd un parser può verificare la correttezza sintattica di un file xml, tuttavia alcune limitazioni del Dtd ne sconsigliano l’uso in favore di un altro approccio, quello dell’XML Schema.

XML TUTORIAL – 2 – ELEMENTI BASE

partiamo da un esempio di file xml per evidenziare le caratteristiche basi di un file xml

La prima riga del documento  <?xml version=”1.0″ ?> identifica il file documento XML specificando la versione.

XML permette di definire quanti tag si voglia purchè essi vengano sempre chiusi. Inoltre è possibile specificare un attributo inserendo il nome dell’attributo con il relativo valore all’interno del tag di apertura dell’elemento.

XML prevede una sintassi abbreviata per gli elementi vuoti che evita di dover specificare il tag di chiusura, terminando il tag di apertura con la sequenza di caratteri “/>”, come nel seguente esempio.

Le due notazioni per gli elementi vuoti sono equivalenti.

Riassumendo tutti i documenti XML devono essere ben formati e affinchè un documento XML sia ben formato deve rispettare le seguenti regole:

  • Ogni documento XML deve contenere un unico elemento di massimo livello (root) che contenga tutti gli altri elementi del documento.
  • Ogni elemento deve avere un tag di chiusura o, se vuoti, possono prevedere la forma abbreviata (/>)
  • Gli elementi devono essere opportunamente nidificati, cioè i tag di chiusura devono seguire l’ordine inverso dei rispettivi tag di apertura
  • XML fa distinzione tra maiuscole e minuscole, per cui i nomi dei tag e degli attributi devono coincidere nei tag di apertura e chiusura anche in relazione a questo aspetto
  • I valori degli attributi devono sempre essere racchiusi tra singoli o doppi apici

La scelta dei nomi dei tag deve seguire alcune regole: un tag può iniziare con un lettera o un underscore (_) e può contenere lettere, numeri, il punto, l’underscore (_) o il trattino (-). Non sono ammessi spazi o altri caratteri. Inoltre XML è sensibile all’uso di maiuscolo e minuscolo.

Per quanto riguarda il contenuto, un documento XML può contenere potenzialmente qualsiasi carattere dell’alfabeto latino, cifre e punteggiatura. L’encoding deve essere specificato nell’intestazione del documento, es.

E’ possibile inserire dei commenti tramite le sequenze di caratteri <!– e –> e possono trovarsi in qualsiasi punto del documento.

Infine per poter inserire caratteri chiavi dell’xml in modo che vengano considerati come semplice testo si fa ricorso alla sezione CDATA.

La sezione CDATA (Character DATA) è un blocco di testo che viene considerato sempre come testo, anche se contiene codice XML o altri caratteri speciali. Per indicare una sezione CDATA è sufficiente racchiuderla tra le sequenze di caratteri <![CDATA[ e ]]>.

XML TUTORIAL – 1 – INTRODUZIONE

Inizia una serie di articoli dedicati a quel componente che ha influenzato pesantemente lo sviluppo delle applicazioni in ambito enterprise, ovvero l’XML, acronimo di eXtensible Markup Language.

Esso è un linguaggio che permette di definire altri linguaggi di markup. Definisce un insieme standard di regole sintattiche per modellare la struttura di documenti e dati. Tali specifiche ufficiali sono state definite dal W3C (Worl Wide Web Consortium) e sono consultabili all’indirizzo http://www.w3.org/XML.

XML è dunque un meta-linguaggio per definire la struttura di documenti e dati, dove per documento XML si intende un file di testo contenente una serie di tag, attributi e testo secondo regole sintattiche ben definite.

Il documento XML è caratterizzato da una struttura gerarchica, composto da componenti denominati elementi. Ciascun elemento rappresenta un componente logico del documento e può contenere altri elementi (sottoelementi) o del testo. Ad ogni elemento possono essere associate informazioni dette attributi, che descrivono le proprietà dell’elemento.

L’organizzazione degli elementi presenta un ordine gerarchico con un elemento principale detto root element e gli elementi che compongono l’albero vengono definiti tag.

Nel prossimo articolo vedremo in dettaglio una struttura xml per approfondire i contetti espressi

MAVEN TUTORIAL – 11 – INTEGRARE JASPERREPORTS

In questo articolo vedremo come integrare un interessante plugin maven per la compilazione automatica dei report realizzati con jasperReports.

Incominciamo con il creare il nostro progetto maven con la direttiva

mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

La direttiva crea una cartella contenente contenente il file pom.xml e la cartella src contenente i sorgenti e i file junit per l’esecuzione dei test.

Lanciamo la direttiva mvn eclipse:eclipse per creare i file necessari ad un progetto eclipse ed importiamo il progetto nel nostro workspace.

A questo punto agganciamo il plugin responsabile della compilazione dei sorgenti jrxml, tipici di JasperReports. Tale plugin prevede la presenza di una cartella jasperreports sotto src/main. Creiamo la cartella e modifichiamo il pom inserendo la dichiarazione del plugin.

A questo punto lanciamo la direttiva mvn compile per verificare la correttezza delle nostre operazioni. Se avete sbagliato a posizionare la cartella il plugin vi ricorderà il percorso esatto.

Restano da definire le dipendenze dalla versione di jasperReports da usare. Per farlo è sufficiente specificare la dipendenza a livello di progetto e a livello di plugin, nel nostro caso ho scelto la versione 4.0.2

Creiamo il nostro file jrxml nella cartella jasperreports e lanciamo la direttiva mcn compile. A questo sotto la cartella target avremo il nostro file compilato e pronto all’uso.

Il vantaggio di questa soluzione è di aver all’atto della compilazione tutti i report in linea con i file jrxml presenti nel progetto.

Qui trovate i sorgenti dell’articolo.

MAVEN TUTORIAL – 10 – GESTONE DEI MODULI

Nell’articolo di oggi vedremo una delle caratteristiche più interessanti di maven, ovvero quella di poter strutturare un progetto in moduli, componenti del progetto principale detto parent. In particolare definiremo un progetto composto da una interfaccia grafica realizzata in flex e un back-end che espone servizi soa basati su spring ws. Per le caratteristiche di spring-ws rimando alla sezione dedicata.

Iniziamo con il creare il progetto parent tramite la direttiva base

Adesso dobbiamo configurare i moduli all’interno del nostro progetto. Per farlo è sufficiente modificare il tag di packaging specificando pom al posto di jar e indicando i moduli tramite il tag modules.

Creiamo il progetto relativo al front-end realizzato in flex. In questo caso ci avvaliamo di flexmojos, un set di plugin realizzati da Sonatype per consentire in maven la compilazione, l’ottimizzazione e il testing di componenti flex. Mister Sonatype ha messo a disposizione una serie di archetipi per soddisfare le nostre esigenze: la creazione di una libreria, la creazione di una applicazione flex e la creazione di un progetto progetto suddiviso in moduli swc, swf e flex. Nel nostro caso ci avvaliamo del secondo archetipo e scegliamo la versione stable che è , nel momento in cui scrivo, la 3.9.

Generato il progetto occorre modificare il pom per includere il repository maven di Sonatype per consentire il download di tutti i componenti necessari alla compilazione. Potete includere il repository all’interno del pom file dello specifico progetto o nel file settings.xml per renderlo disponibile per tutti i progetti.

 

Infine specifichiamo il path del flash player stand alone per poter eseguire i test tramite la variabile flashPlayer.command

Creiamo il progetto del back-end realizzato in spring-ws 2.0. Usiamo la direttiva che abbiamo usato in uno dei precedenti articoli per generare il nostro back-end.

All’interno del progetto back-end specifichiamo la dipendenza dal progetto front-end tramite il tag dependencies

e includiamo il plugin flexmojos-maven-plugin responsabile di copiare gli swf generati nella root del nostro back-end.

Per verificare il corretto funzionamento lanciamo la direttiva mvn package sul progetto parent. I moduli verranno compilati e assemblati nell’ordine dichiarato, ottenenendo il seguente ouput:

Qui trovate i file necessari per fare il vostro progetto modulare.

MAVEN TUTORIAL – 9 – CREARE UN ARCHETIPO

Nell’articolo di oggi vedremo una delle funzioni più interessanti di Maven, ovvero la creazione di archetipi. La creazione di archetipi consente all’utente di creare progetti base da cui far partire gli sviluppi evitando le noiose fasi di configurazione, integrazione e i copia e incolla di sorgenti comuni.

L’uso di archetipi consente di definire dei progetti standard, la cui alberatura e le cui classi rispondono agli standard scelti, e che sono alla base deii progetti da essi derivati.

La generazione dell’archetipo si basa sulla direttiva archetype:create-from-project.

Tale direttiva genera l’archetipo basato sul progetto nella directory target/generated-sources/archetype.

Accediamo alla directory dell’archetipo e lanciamo la direttiva mvn:install.

Tale direttiva consente l’installazione dell’archetipo nel catalogo locale a disposizione per la creazione di altri progetti.

Per sfruttare l’archetipo appena generato creiamo una nuova directory e dopo esserci spostati al suo interno usiamo la seguente direttiva

mvn archetype:generate -DarchetypeCatalog=local

Tale direttiva consente attraverso una procedura guidata la creazione del nostro progetto basato sull’archetipo generato.

Il passo successivo è condividere il nostro archetipo su un repository maven all’interno della nostra azienda in modo da consentire a tutti gli utenti la creazione agevole di nuovi progetti.