Database JDBC connection
Questa è l’opzione da scegliere se vogliamo che il nostro report prelevi i dati da stampare da un DB. Selezioniamo quindi questa voce e premiamo “Avanti >”. Qui di seguito possiamo osservare la schermata che ci viene proposta da iReport dopo la pressione del pulsante “Avanti>”.

Dobbiamo ovviamente avere le informazioni che servono per collegarci al DB (nella figura stiamo utilizzando una connessione JDBC a Oracle).
ATTENZIONE: Se vogliamo usare Oracle dobbiamo scaricare la libreria ojdbc14.jar e posizionarla nella sottocartella “ide10\modules\ext” della cartella in cui abbiamo installato iReport e poi strumenti/opzioni/Classpath/Add Jar e aggiungiamo il jar.
Una volta inseriti tutti i dati, scegliamo “Prova” per vedere se abbiamo fatto tutto bene e quando tutto è OK premiamo “Salva”.
Ora, in alto al centro della schermata principale di iReport possiamo notare la nostra fonte dati (nell’immagine qui sotto indicata con “Fasi”).

E adesso? Ora che abbiamo la fonte dati possiamo usarla per compilare il nostro report. Clicchiamo con il destro sul nome del report e scegliamo la voce “Edit Query” (come mostrato nella figura che segue).

Si aprirà l’interfaccia mostrata qui di seguito, nella quale non dobbiamo fare altro che inserire la nostra query SQL e premere il pulsante “Read fields”.
Come per miracolo in basso vedremo l’elenco dei campi del DB. Scegliamo “OK” e torniamo sul nostro report. Nella sezione “Report inspector” (sulla sinistra) avremo la voce “Campi” riempita con i nomi delle colonne del DB. Non ci resta che selezionare una colonna e trascinarla sul nostro report, nella sezione in cui vogliamo che compaia.

XML file datasource
Se la nostre fonte dati è un file XML, ci basta scegliere XML file datasource al “Passo 1″ e premere “Avanti >”. Diamo poi un nome e scegliamo il file XML di riferimento.
C’è però un caso in cui ci si può trovare in difficoltà nell’uso di un file XML come sorgente dati. E’ il caso in cui si cerca di inserire in una jr:table i dati contenuti nel file xml. In tal caso dopo aver creato il dataset dal quale la tabella andrà a prendere i dati, è opportuno entrare nella visualizzazione XML e modificare la seguente stringa:

in quest’altra:

Ok, facciamo un piccolo esempio
Ammettiamo che questo sia il nostro file XML:

Ammettiamo inoltre di dover inserire i dati contenuti nel tag “testo” nella prima colonna della jr:table e i dati del tag “valore” nella seconda colonna.
Trasciniamo quindi l’oggetto “Table” nella zona “Detail” del nostro report. Si presenterà la seguente schermata:

dalla quale dobbiamo associare la nostra tabella al dataset. Premiamo quindi “New dataset”. Nella schermata successiva diamo un nome al dataset (ad esempio SorgenteDatiXML) e scegliamo “Create new dataset…”. Premiamo “Avanti>”. Nella schermata successiva andiamo a cercare la sorgente dati che fa riferimento al file XML. Ora sempre “Avanti>” fino alla fine, quindi “Termina”.
Ora nel “Report inspector”, sulla sinistra, sarà comparsa la voce “SorgenteDatiXML”.
Clicchiamoci sopra con il tasto destro e scegliamo “Edit query”. Dalla schermata che si apre, nella combo “Query language” scegliamo “XPath” come nella figura qui sotto.

A questo punto tramite XPath andiamo a cercare i dati che ci interessano (documento/voce). Sulla destra apriamo il tag “voce” e trasciniamo i tag “testo” e “valore” nella parte bassa della figura. Premiamo “OK”.
Ora, sotto “SorgenteDatiXML” troveremo i campi “testo” e “valore”.
Portiamoci nell’edit della tabella e trasciniamo i campi nelle rispettive colonne, come nella sottostante figura.

Ora effettuiamo la sostituzione di cui si è parlato all’inizio di questo paragrafo (“dataSourceExpression”).

JavaBeans set datasource
Questa è la scelta più complicata, ma forse più utile per un javista. In questo modo possiamo dire a jasperReport di prelevare le informazioni da stampare da un elenco (collezione o array) di beans! Procediamo.
Dobbiamo innanzitutto sapere che

“this datasource need a spacial factory class that provides a static method to generate a collection or an array of JavaBeans”

ossia dobbiamo creare una classe che abbia un metodo statico e tale metodo DEVE restituire una collection o un array riempiti con i nostri beans.
Qui di seguito vi porto un esempio di tale metodo (si presuppone l’esistenza di una classe di nome Bean che rappresenta il nostro bean):

Fatto questo, creiamo un .jar dal nostro progetto. Poi da iReport “Strumenti/Opzioni/Classpath”. Scegliamo “Add JAR” e aggiungiamo il nostro jar. Ora, aggiungendo un datasource di tipo “JavaBeans set datasource”, nel campo “Factory class” possiamo aggiungere la classe (completa di percorso del package in cui si trova). Nell’altro campo (il metodo statico) aggiungiamo il nome del metodo statico (nell’esempio “dammiLista) che ci restituisce la collection o l’array di beans, come mostrato nella figura qui sotto.

Premiamo il pulsate “Prova”. Deve venire fuori un “successo”, altrimenti abbiam sbagliato qualcosa… Se tutto è ok, clicchiamo sul destro sul nome del nostro progetto e scegliemo “Edit query”. Comparirà la schermata qui sotto

Dobbiamo quindi premere su “JavaBean Datasource” e inserire il nome della classe che rappresenta il singolo bean (nel nostro caso proprio Bean). Poi premiamo “Read attributes”. Al centro, come mostrato, comparirà l’elenco degli attributi del singolo Bean Selezioniamo quelli che ci interessano e premiamo “Aggiungi il campo(i) selezionati. Poi diamo “ok”.
Adesso nei campi del nostro report sono comparsi quelli selezionati e, trascinandoli sul report possiamo stamparne i valori
Ue’, sia chiaro! Tutto questo discorso sui javabeans serve esclusivamente per vedere da iReport l’anteprima del nostro report. Nella nostra applicazione poi le cose son diverse! Non è che dobbiamo creare un metodo statico nel codice!!!
Procediamo nella lettura per capire…

Bene.
Qualunque sia stata la nostra scelta, ora prcediamo e creiamo il nostro report.
Ritorniamo nella schermata principale e clicchiamo sul “Passo 2″.
Ci verrà proposto un insieme di layout. Senza complicarci la vita dietro a layout più o meno belli e complicati, scegliamo il primo se vogliamo un report con stampa verticale o il secondo se preferiamo una stampa orizzontale. Clicchiamo quindi sul layout scelto e premiamo “Open this template”. Ora siamo pronti a disegnare il nostro report.
Le guide sull’argomento non mancano, quindi vi rimando ad una qualunque di esse per prendere dimestichezza con iReport.
Una volta terminato il nostro lavoro sul report è opportuno compilarlo per ottenere il file jasper. Per farlo basta premere il bottone evidenziato nelle figura qui sotto.

2.USO DI JASPERREPORT IN JAVA
Usare jasperReport in java significa semplicemente aggiungere la sua jar (attualmente jasperreports-3.7.3.jar) nelle librerie del progetto. Fatto questo possiamo accedere alle sue classi.
Se, ad esempio, il nostro file jasper compilato si chiama “ricevutaTrasfProgrTriennale.jasper” e deve recuperare i dati da un file XML, inviato tramite post in una web application, con il codice qui di seguito recuperiamo l’inputstream, modifichiamo il file XML (tramite jaxp) e richiamiamo jasperReport per la realizzazione del file PDF:

Se invece i dati sono contenuti in una collezione di beans, possiamo procedere come segue:

CLASSICI PROBLEMI INCONTRATI DURANTE L’USO DI JASPERREPORT
Dopo aver creato il file jasper e aver provato a interagire con esso tramite codice java, può capitare di imbattersi nel seguente messaggio di errore:

java.lang.NoClassDefFoundError: org/codehaus/groovy/control/CompilationFailedException

In questo caso bisogna aprire il jrxml ed eliminare l’attributo language=”groovy” nel nodo jasperReport.

[... to be continued ...]

Tornando a jQuery4j, vediamo ora di capire come possiamo usare tutta questa struttura per scrivere il codice, lato server, che si trasformerà poi in un calendario interattivo lato client.
Per fare questo dobbiamo usare quella che i progettisti di jQuery4j chiamano richlet: a richlet is a small Java program that creates all necessary components in response to user’s request. You can compose the UI by purely java, without html, ZUML. The programming logic is much like swing.

Ecco qui di seguito un richlet che realizza il nostro calendario:

Bisogna ovviamente settare correttemente il proprio web.xml e zk.xml affinché queste richlet funzioni correttamente, ma per i dettagli vi rimando ai siti di riferimento sopra linkati.

• Supporto alle annotation
• Configurazione dinamica delle librerie tramite codice inserito nel web.xml
• Embedding semplificato
• Miglioramento del secure session tracking

Controlla le note di rilascio di Apache Tomcat 7, oppure vai semplicemente alla pagina di download della RC4.

• una local class non può avere memebri statici (questo però non esclude la possibilità di avere un membro final static, essendo esso una costante)
• una local class non può avere modificatori di accessibilità (public, private, ecc.). Sarà quindi dichiarata scrivendo semplicemente class nomeClasse {…}
• una local class può estendere un’altra classe
• all’interno del blocco in cui è definita, una local class può accedere solo ai membri dichiarati final
• una non-static local class può accedere sia ai membri statici sia ai membri non statici della classe contenitore (da non confondere con il blocco contenitore)
• una static local class può accedere solo ai membri statici della classe che la contiene
• una local class (essendo locale) può essere istanziata solo nel blocco nel quale è definita e deve essere dichiarata prima di essere utilizzata

Prima accortezza: se il blocco contenente la dichiarazione della local class è definito in un contesto statico (ad esempio un metodo statico o un inizializzatore statico) allora la local class è implicitamente statica e quindi non richiede alcun oggetto contenitore per essere istanziata.
Facciamo però attenzione al fatto che, sebbene in certi contesti (appena visti) la local class è intesa implicitamente statica, essa non consente di utilizzare nella propria dichiarazione la parola chiave static. Mai.
Facciamo anche attenzione al fatto che se una local class si trova dichiarata in un contesto statico, ciò influenzerà quello che la local class può “vedere” nel contesto contenitore.
Possiamo leggere i commenti nel seguente esempio per chiarirci (spero) le idee…

• Un’istanza di una non-static member class può esistere solo e soltanto insieme all’istanza della classe che la contiene
• Una non-static member class non può avere static members (a meno che non siano anche final)
• Il codice scritto in una non-static member class può avere accesso diretto a ogni membro (inclusi i nested) anche se dichiarato private

Vediamo un esempio con un po’ di casi particolari.

Osserviamo il punto (4).
Viene modificato il valore asseganto all’attributo di tipo stringa message. Ma esistono 2 attributi di tipo stringa denominati message! Li vediamo dichiarati al punto (1) e al punto (3), entrambi private. Il message al punto (1) appartiene alla classe contenitore (MyLinkedList), mentre quello dichiarato al punto (4) appartiene alla non-static inner class (Node). Abbiamo detto che in una non-static member class possiamo riferirci a qualunque membro, anche dichiarato private, anche appartenente alla classe contenitore. Ma come possiamo riferisci all’attributo message del contenitore? Lo si può fare con un uso particolare della parole chiave this. Osserviamo a tal riguardo il punto (5).

ATTENZIONE.
Se non fosse stato dichiarato l’attributo al punto (4), allora scrivendo

non si avrebbe alcun errore (come invece ci si potrebbe aspettare), poiché ci riferiremmo, in modo implicito, all’attributo message della classe contenitore!!!
Facciamo attenzione a questo caso particolare!

Definizione:
Con il termine nested type (tipi annidati) si intende indicare:

• nested classes
• nested enums
• nested interfaces

Definizione:
Con il termine nested class (classe annidata) si intende una classe dichiarata all’interno di un’altra classe.
Allo stesso modo si definisono le nested enum e le nested interface.
Ci sono 4 tipi di nested classes:

1. static member classes, enums e interfaces
2. non-static member classes
3. local classes
4. anonymous classes

Definizione:
Con il termine inner class (classe interna) si indica una qualsiasi nested class purché NON di tipo 1 (vedi definizione precedente).

Facciamo un esempio commentato a dovere:

• ClasseA
• ClasseB

e che ClasseB sia una sottoclasse di ClasseA ossia “ClasseB extends ClasseA”.

Ora, supponendo che le classi si trovino tutte nello stesso package, scriviamo questo codice nel nostro main method:

Problemi?
Il codice scritto funziona? Anzi, compila?
La risposta è, ovviamente, no e il problema è nell’ultima riga (2): b = a;
Perché?
Eppure sembra tutto ok!
In (1) abbiamo assegnato b ad a, quindi a = b. Come è mai possibile che scrivendo poi b = a la cosa non sia corretta?
La spiegazione è nel tipo di dichiarazione iniziale dei reference a e b.
ClasseA è una superclasse di ClasseB, quindi scrivere a = b è possibile per automatico widening (a è “più grande” di b). La cosa invece non è possibile in senso inverso perché b è “più piccolo” di a e non può quindi “contenerlo”.
L’osservazione più comune a questo punto è:
ma se in (1) abbiamo scritto a = b significa che a e b sono diventati uguali! Quindi come è mai possibile che b = a dia problemi?
Già, come è mai possibile?
Leggete il post su java i reference e la RAM e forse ne capirete di più…

è un’affermazione che il programmatore fa in un certo punto del codice da lui scritto.. Il compilatore si occupa di verificare che tale affermazione sia corretta, in caso contrario lancia un’eccezione di tipo unchecked. E’ decisamente opportuno disabilitarle in fase di produzione del sistema, mentre possono essere utili in fase di sviluppo e test.

Come si dichiarano?
In 2 modi diversi:

Se ad esempio, in una nostra classe stiamo calcolando la velocità come spazio/tempo, potremmo scrivere:

Come si abilitano?
Per default le asserzioni sono disabilitate.
Bisogna quindi esplicitamente abilitarle. Ecco come fare:

In questo modo abilitiamo l’uso delle asserzioni nella nostra classe e in tutte le sue dipendenze, ma non nelle classi di sistema (quelle caricate direttamente dalla JVM). Per abilitare anche quelle ci tocca scrivere:

L’errore più clamoroso che si possa commettere nell’uso di una

è quello di confonderla con la gestione delle eccezzioni!

Se avete chiara la differenza tra un reference e un dato primitivo, diventa tutto facile.
In java i parametri vengono sempre passati per valore e sempre duplicati con copie locali al metodo.
Dovrebbe però essere chiaro che duplicare una variabile di tipo primitivo è diverso dal duplicare una varibile di tipo reference! Duplicare un reference significa avere 2 reference che puntano allo stesso oggetto! Ecco perché quando in un metodo modifico il valore di un parametro di tipo primitivo esso non modifica il valore del parametro fuori dal metodo, mentre quando uso un parametro di tipo reference ogni modifica apportata all’oggetto puntato da tale reference viene riflessa sull’oggetto puntato dal parametro esterno: entrambi i reference (essendo uno la copia dell’altro) puntano lo stesso oggetto!

• integral types (byte, short, int, long e char)
• floating-point types (float, double)
• boolean type (boolean)

E’ lecito scrivere:

Cosa succede nella RAM del PC quando noi scriviamo una tale istruzione?
La figura di seguito dovrebbe spiegarlo.

Nella cella di memoria con sfondo verde è stato inserito il valore del nostro tipo primitivo; in questo caso il valore 10. Da adesso in poi ogni istruzione di modifica della variabile intVar modificherà direttamente il valore contenuto in quella cella di memoria. Quindi scrivendo:

java modificherà per noi il contenuto della cella in figura.
E’ molto importante notare e capire che java gestisce in modo differente gli oggetti e i dati primitivi.

Innanzitutto distinguiamo tra reference value e object reference.
Un reference value rappresenta un valore (value) e precisamente il valore che viene restituto quando viene creato un particolare oggetto.
Un object reference (o semplicemnte reference) rappresenta invece una variabile che può memorizzare un reference value.
Questa differenza deve essere chiara perché altrimenti niente sarà mai chiaro con i reference in java!
Ora traduciamo questi concetti in codice.
Creiamo 2 object reference di tipo MiaClasse:

Scrivendo questa riga di codice abbiamo comunicato a java di creare due variabili (nella RAM del calcolatore) di tipo MiaClasse e gli abbiamo anche detto che in queste 2 variabili DOVRANNO essere inseriti dei valori che si riferiranno (reference) a 2 oggetti di tipo MiaClasse. Stiamo parlando di “reference”! Questo significa che in queste 2 variabili java NON inserirà MAI gli oggetti veri e propri, ma il rifeimento a tali oggetti!!!
Rileggete bene l’ultimo paragrafo: è molto importante!

Bene. Inseriamo allora tali riferimenti ai 2 oggetti:

A questo punto java assegna un valore a refOggetto1 e un altro valore a refOggetto2. Ribadisco ancora che tale valore NON indica l’oggetto vero e proprio, ma indica la posizione (in RAM) dell’oggetto; il suo “riferimento”.
Si può rappresentare graficamente quanto detto con la seguente figura (scusate la poca eleganza).

In questa figura c’è rappresentato tutto quello che bisogna sapere sui reference!

Perché i reference refOggetto1 e refOggetto2 hanno uno sfondo bicolore?
La risposta a questa domanda svelerà uno dei segreti di java…
Nei reference non viene inserito soltanto l’indirizzo di memoria in cui è memorizzato l’oggetto, ma anche l’intervallo di memoria che sarà occupato dall’oggetto!
Quindi è come se nella parte verde chiaro ci fosse scritto l’indirizzo RAM dove “inizia” l’oggetto che ci interessa, mentre nella parte verde scuro fosse indicato lo spazio da sommare al punto iniziale per contenere l’oggetto.
Vi siete mai chiesti perché scrivere:

procuri un output simile al seguente?

La @ è il separatore tra la parte verde chiaro e quella verde scuro!

Ora comprendere a fondo questo concetto sarà di fondamentale importanza quando parleremo di polimorfismo e di metodi virtuali!

In java NON avremo mai a che fare con gli oggetti veri e propri (indicati con lo sfondo rosa nella figura), ma solo con i loro riferimenti (sfondo verde).
Ecco perché quando noi scriviamo:

NON stiamo rendendo uguali gli oggetti e in realtà non stiamo rendendo uguali neanche i reference, ma solo una parte dei reference, cioè la parte che indica dove inizia l’oggetto in memoria.
Questo significa che dopo tale istruzione refOggetto2 punterà allo stesso indirizzo di memoria a cui punta refOggetto1 e quindi se noi apportiamo una modifica all’oggetto puntato da refOggetto2 la ritroviamo anche sull’oggetto puntato da refOggetto1; per forza! Entrambi puntano allo stesso oggetto!

L’oggetto a cui puntava refOggetto2 rimarrà in memoria fino a quando java, tramite il suo garbage collector, non si accorgerà che nessuno lo “cerca” e lo eliminerà.

Ma tutto quanto detto è valido solo e soltanto se i 2 reference sono stati dichiarati dello stesso tipo (come nel nostro caso)!
Se invece avessimo scritto:

e se non ci fosse legame tra le 2 classi, scrivere:

produrrebbe un errore in compilazione!

Abbiamo già visto che con i dati primitivi le cose funzionano ben diversamente, ma vi rimando ai relativi post.
I dati primitivi
Il passaggio dei parametri
Gli argomenti sono strettamente collegati.
Per “evolvere” il pensiero invece, è bene leggere questo post: java il polomorfismo e i metodi virtuali.
Mal di testa? E’ normale… passerà!