Experience with Google Web Toolkit

Salve a tutti,

questo articolo si propone di condividere la mia esperienza con questo strumento messo a disposizione dalla grande G, nel corso delle sue evoluzioni con l’obiettivo di trasmettere pro e contro (difficile trovarne..) di questo potente tool.

-cos’è GWT ??

Il primo errore che ho commesso nel valutare il Google Web Toolkit è stato considerarlo un framework, (WARNING) , GWT non è un framework, bensì un insieme di strumenti che permettono lo sviluppo,  la manutenzione e il debugging di grosse applicazioni Javascript/AJAX. Infatti esistono quelli che possiamo definire dei veri e propri framework basati (chi più, chi meno) su GWT.

Parliamoci chiaro: a chi è che piace programmare in Javascript? Considerando specialmente aspetti come il debugging e la manutenzione non è una passeggiata, soprattutto se si proviene da una realtà come Java(SE o EE) andare su Javascript è come tornare alla preistoria.

Un primo punto di forza di questo strumento (e credo il fondamentale) è la possibilità di sviluppare le applicazioni attraverso il linguaggio Java portando con sè tutti i suoi vantaggi già affermati al giorno d’oggi specialmente per il packaging , la manutenzione,  per non parlare della facilità dei processi di sviluppo del software, che la tecnologia Java mette a disposizione.

Un altro problema del linguaggio Javascript e la tecnologia AJAX annessa, è la portabilità che i vari browser rendono sempre più difficile, il principio write once, run everywhere motto di Java viene propagato da GWT grazie al grosso lavoro del team di sviluppatori di questo toolkit che ha reso la vita facile a tanti altri sviluppatori.

Veniamo a noi:

Innanzitutto voglio premettere che non sono un “filoGoogle” d’altro canto bisogna dare a Cesare quel che è di Cesare, e Google merita un bel 10 su 10 se consideriamo aspetti come: portabilità del software, potenzialità del web, modelli di sviluppo. Su questo ed altro il tool di Google offre ampia versatilità ma allo stesso tempo riesce a dare all’utente poco esperto la consapevolezza delle potenzialità del web.  GWT si propone come un tool completo per scrivere e debuggare applicazioni: web come lo fa? Ti fa scrivere codice Java e te lo compila in Javascript. Un altro, a mio avviso, grosso errore che commettono molti utenti (me compreso) è di considerarlo un semplice compilatore, in realtà il compilatore è il cuore di GWT e fa parte dell’insieme di strumenti offerti per gestire: creazione di interfacce grafiche stile web2.0, modalità di deploy dell’applicazione, controllo del download delle risorse, ottimizzazione del codice.

Inoltre il Google Web Toolkit, offre delle API per sviluppare anche la parte server della nostra applicazione. L’invocazione della parte server è basata su chiamate RPC il cui protocollo è trasparente allo sviluppatore nel senso che non deve conoscere i dettagli del payload HTTP o dell’header, il tutto continua ad essere sviluppato in Java. Inoltre la parte server si appoggia alla specifica Servlet già ampiamente diffusa e conosciuta sul mercato.

Possibili svantaggi di GWT si possono ricondurre ad una vera e propria dipendenza dal tool che a mio avviso dovrebbe essere evitata creando disaccoppiamenti applicativi o con la consapevolezza di cosa si sta utilizzando e perché.

A presto.

NonSoloUniX

 

 

 

Ajax o non Ajax questo è il problema…

Ultimamente mi sto imbattendo in molti progetti con tecnologia Ajax (Asynchronous Javascript and Xml), una tecnica molto utilizzata ultimamente per creare applicazioni web-2.0, stile applicazioni stand-alone. Molte applicazioni quali Facebook, Gmail, e tante altre sfruttano questa tecnica per implementare le lo funzionalità, ma ci si sta imbattendo sempre di più nel solito problema: qua ognuno fa come vuole.

La nascita di Ajax è dovuta soprattuto al fatto che molti browser, oggi la maggior parte, mettono a disposizione una funzionalità per creare richieste http, la peculiarità di Ajax sta nel fatto che queste richieste Http sono state rese asincrone, per farla breve quando accedete ad un sito in realtà state facendo una richiesta Http richiedendo ad un server di fornirvi la pagina che avete appunto richiesto, quando il server esaudirà la vostra richiesta il vostro browser prenderà in carico la risposta e la processerà interpretando l’html restituito. Ora immaginate se al clic di un qualsiasi pulsante di questa pagina appena scaricata venisse innescata una nuova richiesta http e che la risposta di tale richiesta modificasse una porzione della pagina che avete inizialmente scaricato senza dare all’utente la percezione di quel fastidioso refresh… in realtà tutto ciò funziona perché la richiesta è asincrona e il browser non si mette in attesa della risposta dando la possibilità all’utente di poter fare altro.

Ma come mai Javascript and Xml? Javascript è un linguaggio di programmazione messo a disposizione dalla maggior parte dei browser ed è tramite questo che è possbile creare richieste http e processare le risposte, in una risposta il server potrebbe piazzare qualsiasi contenuto ma per la tecnica Ajax è stato usato spesso XML e poi per renderlo ancora più veloce JSON che sta per JavaScriptObjectNotation, è infatti come dice la parola, un modo per definire oggetti con notazione Javascript. Con entrambi è possibile definire qualsiasi tipo di protocollo per processare le risposte ricevute nella nostra web-application.

Bene, ora che avete capito cos’è Ajax, possiamo svelare quelle che non sono come sempre tutte rose e fiori. Come già accennavo prima prima purtroppo, non esiste ancora uno standard ben preciso di supporto allo sviluppo di applicazioni del genere, nè tanto meno esiste uno standard per i browser su come mettere a disposizione un oggetto XHR (XmlHttpRequest) e al momento chi vuole imbattersi in sofisticate applicazioni Ajax da solo dovrà gestire numerose casistiche dettate dai diversi comportamenti dei browser.

Questo articolo termina qui e sarà di spunto per molti altri articoli che cercano di spiegare come ad oggi sono stati risolti molti problemi, come l’utilizzo di svariati framework ajax, e le varie architetture messe a disposizione, inoltre verrà dedicato un articolo alla predisposizione della comunità verso nuovi standard rivolti verso questa che al momento possiamo solamente chiamare tecnica di programmazione.

Saluti

NonSoloUnix

NonSoloUnix Vs JasperReport

Ciao a tutti oggi voglio inaugurare la ripresa di questo mio blog dedicando un articolo a questo bel framework che me ne ha fatte passare di tutti i colori.

Innanzitutto spieghiamo cosa è e a cosa serve questo framework. JasperReports è una libreria scritta in Java per sviluppatori Java e si compone di vari moduli per soddisfare richieste di reportistica aiutando gli utilizzatori della libreria a non doversi concentrare su problematiche esterne ma comunque indispensabili per lo scopo.

Immaginate ad esempio di dover preleveare una serie di informazioni da una base dati per generare dei documenti in funzione dei dati prelevati, se il vostro obiettivo si avvicina anche di poco a quello dell’esempio appena descritto JasperReport allora fa al caso vostro.

Dopo questa piccola premessa voglio precisare che scrivo questo articolo poiché mi sono imbattuto in non pochi ostacoli per l’utilizzo di questo framework data la scarsa documentazione sul suo utilizzo(sarà che i tutorial e le guide sono a pagamento?).

Non disperate non sarete completamente abbandonati, fortuntamente esiste questo blog e tutta una serie di tool che possono agevolarvi per la generazione del vostro primo report, innanzitutto vi consiglio di scaricare:

  1. la libreria JasperReport
  2. il tool iReport per Windows (vi consiglio l’ultima versione che è molto ben fatta almeno la 3.6.1 mentre scrivo queste righe)

Fatto ciò installate iReport così da poter fare i vostri primi esperimenti, la prima cosa da fare in iReport è definire un DataSource, avete a disposizione varie fonti, una connessione JDBC, un file CSV, una fonte Excel, etc, io essendo pigro ho scelto una fonte Excel.

Successivamente create un report vuoto scegliendo il template A4, potrete notare come iReport vi illustra la struttura che potrebbe avere il vostro report che vi ha già comodamente diviso in bande: Titolo, Testa di colonna, Dettaglio, Piè di Pagina, Sommario, Sfondo. Non è detto che tutte queste debbano essere utilizzate, infatti io ho eliminato tutte tranne il Titolo, il Dettaglio e il Piè Pagina. Ho settato le altezze delle relative bande, ho valorizzato i margini della pagina e ho cominciato a definire i campi da prelevare dal mio DataSource (per semplicità ho fatto un DataSource Persona in un file Excel).

Dalle proprietà del report (tasto destro sull’icona radice nello schema ad albero alla vostra sinistra) cliccate su EditQuery, da lì è possibile importare i campi del vostro DataSource. I campi appena importati saranno disponibili ora per il vostro report se volete che vengano iterate tutte le persone del vostro DataSource  dovrete piazzare i campi nella banda Detail è solo lì che il campo verrà interpretato in questo modo, per campi unici vi consiglio di non usare la banda del dettaglio.

Una volta finito il vostro report potrete testarlo utilizzando l’apposito tasto Anteprima .. et voilà il report è servito.

Nel prox articolo vedremo un approfondimento su JasperReport e WebApplication

Saluti

NonSoloUnix