Sviluppo Tesi FrameworK Java-Ajax

Grails validation, un incongruenza nella constraint size

2009-11-12T16:16:00.002+01:00

Dopo mesi che non mi faccio più sentire (l'elezione a sindaco ha decisamente influito) ecco che mi ripropongo a voi.
Sembra difficile crederlo, ma siete davvero in molti quelli che seguite il blog... anche se poco aggiornato.
D'altronde in Italia non sono molti quelli che programmano in GWT e Grails, e in particolare con una combinazione di entrambi.

Oggi forse abbiamo trovato un incongruenza, o almeno qualcosa di poco intuitivo, nella validazione di grails.
Era un qualcosa che avevamo già intuito in passato, oggi abbiamo fatto alcuni test e possiamo essere sicuri di questo comportamento. Stiamo usando grails 1.2M4, ma credo il comportamento sia simili almeno per grails 1.0 in avanti.

In effetti la documentazione è poco chiara sulle constraint, in particolare proprio sull'interazione della constraint size con nullable e blank, verso i quali ha una frase piuttosto criptica:

Currently this constraint cannot be used in addition to blank or nullable, a custom validator may be added to perform this kind of constraints.

Il che apparentemente significherebbe, se il mio inglese non mi tradisce, che la constraint size non si può usare in aggiunta a nullable e blank... ma la cosa risulta falsa, infatti, prendiamo ad esempio questa classe


class Prova {
    static constraints = {
  prova1(size:0..16)
  prova2(size:1..16)
    }
 String prova1
 String prova2
}

e questo codice in un controller:


  Prova provaA = new Prova()
  provaA.validate()
  println "Validazione ProvaA"
  provaA.errors.each {println it}

  Prova provaB = new Prova()
  provaB.prova1 = ""
  provaB.prova2 = ""
  provaB.validate()
  println "Validazione ProvaB"
  provaB.errors.each {println it}

si ha questo output

Validazione ProvaA
org.springframework.validation.BeanPropertyBindingResult: 2 errors
Field error in object 'Prova' on field 'prova2': rejected value [null]; codes [Prova.prova2.nullable.error.Prova.prova2,Prova.prova2.nullable.error.prova2,Prova.prova2.nullable.error.java.lang.String,Prova.prova2.nullable.error,prova.prova2.nullable.error.Prova.prova2,prova.prova2.nullable.error.prova2,prova.prova2.nullable.error.java.lang.String,prova.prova2.nullable.error,Prova.prova2.nullable.Prova.prova2,Prova.prova2.nullable.prova2,Prova.prova2.nullable.java.lang.String,Prova.prova2.nullable,prova.prova2.nullable.Prova.prova2,prova.prova2.nullable.prova2,prova.prova2.nullable.java.lang.String,prova.prova2.nullable,nullable.Prova.prova2,nullable.prova2,nullable.java.lang.String,nullable]; arguments [prova2,class Prova]; default message [La proprietà [{0}] della classe [{1}] non può essere null]
Field error in object 'Prova' on field 'prova1': rejected value [null]; codes [Prova.prova1.nullable.error.Prova.prova1,Prova.prova1.nullable.error.prova1,Prova.prova1.nullable.error.java.lang.String,Prova.prova1.nullable.error,prova.prova1.nullable.error.Prova.prova1,prova.prova1.nullable.error.prova1,prova.prova1.nullable.error.java.lang.String,prova.prova1.nullable.error,Prova.prova1.nullable.Prova.prova1,Prova.prova1.nullable.prova1,Prova.prova1.nullable.java.lang.String,Prova.prova1.nullable,prova.prova1.nullable.Prova.prova1,prova.prova1.nullable.prova1,prova.prova1.nullable.java.lang.String,prova.prova1.nullable,nullable.Prova.prova1,nullable.prova1,nullable.java.lang.String,nullable]; arguments [prova1,class Prova]; default message [La proprietà [{0}] della classe [{1}] non può essere null]
Validazione ProvaB
org.springframework.validation.BeanPropertyBindingResult: 0 errors

Non avendo dichiarato nessun'altra contraint oltre a size, come per ogni proprietà della classe, si dovrebbe sottointendere "nullable: true"
E infatti sembrerebbe così, nel tentativo su ProvaA abbiamo i due errori sul valore nullo

Il size sulla stringa è inteso come un controllo sulla lenght() della stringa stessa. quindi può trarre in inganno il size(0..16) che potrebbe far pensare di aver concesso alla stringa un lenght 0... quindi come non avergli dato valore, quindi come aver sottinteso nullable:true
Ma non è così

Altra cosa strana è il size(1..0)... concedere ad una stringa lunghezza minima di 1, potrebbe far pensare di costringere la stringa ad avere un valore diverso dal valore vuoto, in parole povere di aver sottointeso "blank: false", ma non è così
come si vede dall'output precedente, un assegnazione prova2="" è accettata... anche se palesemente un lenght su una stringa = "" sarebbe 0.

Comportamento strano, non credete?

Accedere al DataSource di grails da dovunque

2009-05-22T14:54:00.002+02:00

Mi è riservito dover riaccedere al datasource da un qualcosa che non fosse un controller o un service.

Infatti nel nostro progetto abbiamo una classe utility che deve avere accesso al database, per poter fare una query con HQL...

Per poterlo fare bisogna:


import org.codehaus.groovy.grails.web.context.ServletContextHolder as SCH
import org.codehaus.groovy.grails.web.servlet.GrailsApplicationAttributes as GA
def ctx = SCH.servletContext.getAttribute(GA.APPLICATION_CONTEXT)
def dataSource= ctx.dataSource

e ora nel dataSource si ha una classe di tipo: http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/jdbc/datasource/DriverManagerDataSource.html

e ora si può accedere alla connessione così:


def sql = new Sql((Connection)dataSource.getConnection())

Con grails 1.1 si può fare più semplicemente


import org.codehaus.groovy.grails.commons.ApplicationHolder as AH
def static ctx = AH.application.mainContext
def dataSource= ctx.dataSource

Per poi continuare come scritto prima

Database Naming convention

2009-04-30T15:17:00.002+02:00

Alcune convenzioni largamente utilizzate (in gran parte usate anche da grails e hibernate) per i nomi nei database.
Ho trovato questo libro, SQL Programming Style by Joe Celko

Che sembrerebbe essere interessante e si basa sullo standard ISO/IEC 11179-5:2005, che da quanto letto è lo standard per la "naming convention" in senso lato.

Lo standard iso, riassumento, dice tra le altre cose

1. Be unique (within any data dictionary in which it appears).
2. Be stated in the singular.
3. State what the concept is, not only what it is not.
4. Be stated as a descriptive phrase or sentence(s).
5. Contain only commonly understood abbreviations.
6. Be expressed without embedding definitions of other data elements
or underlying concepts.
7. Tables, sets, and other collections shall be named with a collective,
class, or plural name.
8. Procedures shall have a verb in their name.
9. A copy (alias) of a table shall include the base table name as
well as the role it is playing at that time.

Elenco qui, invece, alcune delle convenzioni trovate nel libro

Lunghezza dei nomi (tutti): dovrebbe essere inferiore ai 30 caratteri. Molti dbms sql accettano sino a 128 caratteri (come MS SQL) ma considerando il limite di oracle di 30 caratteri, conviene che tutti i nomi usati siano inferiori a questo limite. Comunque sembra una cifra più che sufficiente.
Evitare i caratteri speciali, come ad esempio $, #, @, alcuni dmbs li supportano, ma non tutti.
I nomi delle tabella è buona norma scriverli "capitalizzati" (prima lettera maiuscala, il resto minuscolo). Tutto il resto (nomi colonne, ecc...) tutto minuscolo. Questa però pare essere una convenzione piuttosto controversa.
Per nomi composti (sia tabella sia colonna) usare l'undescore come separatore, e non le "camel words" (cioè come in java, le parole attaccate capitalizzate, come NomeTabella). Per i nomi di tabella usare parole capitalizzate.
Essere coerenti nella scelta se usare nomi di tabella al singolare o al plurale. Ci sono alcune correnti di pensiero, alcuni pensano sia meglio usare nomi al plurale, dopotutto una tabella contiene in se solitamente più di un entità. Però nella modellazione una tabella rappresenta un oggetto, quindi espresso al sigolare. Inoltre scrivere tutto al singolare evita i problemi derivati proprio dalle particolare regole nel rendere plurarle una parola (person diventa people). Il libro consiglia nomi al plurale, anche se molti altri (e io mi aggiungo a questi) consigliano nomi al singolare.
Evitare i prefissi, soprattutto nei nomi di tabelle. Alcuni usano anteporre table_ o tbl_ ai nomi di colonne, ma è inutile, anzi scomodo. Sconsigliato anche anteporre il nome della tabella a tutte le colonne della tabella stessa.
Le tabelle di relazione dovrebbero avere nomi che riassumano al relazione stessa. Per esempio un'ipotetica relazione di "matrimonio" tra la tabella "uomo" e la tabella "donna" dovrebbe chiamarsi "matrimonio", e non "uomo_donna". Se non possibile, si usano i nomi della tabelle unite dall'underscore.
Le chiavi primarie, dove possibile, dovrebbero essere degli standard industriali, come per esempio l'ISBN, o simili.

Grails Are Not Configured

2009-02-19T11:27:00.002+01:00

Non è la prima volta che mi capita questo errore, e non è la prima volta che perdo decine di minuti per risolverlo... mi dimentico sempre la soluzione.

In questi giorni ho importato ed esportato svariati progetti... e quindi spesso ci sono incompatibilità con le configurazioni degli stessi (librerie, jdk, facet bla bla).

A volte capita che, nel tentare di far partire/compilare un progetto Intellij Idea segnali "Grails are not configured"

Per risolvere il problema bisogna verificare che:

Ci sia il Grails JDK configurato correttamente, per fare questo bisogna accedere alla struttura del progetto (ctr+alt+shift+s, oppure F4 se si clicca sulla root del progetto nel project explorer) , andare su moduli-> grails e verificare che sia richiamato un jdk di grails
sia settata, sia in IDEA che in windows la variabile GRAILS_HOME

e tutto dovrebbe risolversi :-D

Novità in ambito GWT: Smart GWT, aggiornamenti a GWT-EXT e GWTMosaic

2009-02-13T09:58:00.003+01:00

Negli ultimi mesi sono venute alla luce importanti novità nel modno di gwt.

Alcuni aggiornamenti alle librerie GWT-EXT: siamo ora alla 2.0.6, anche se nella home è dichiarata ancora la 2.0.5

Questa versione la trovate da un link posto in questo post: http://gwt-ext.com/forum/viewtopic.php?f=12&t=3624

Attenti però, le prime versioni di questo pacchetto avevano una struttura directory che richiamava la versione precedente.

Purtroppo questa release, anzi, in realtà anche quella precedente, è stata accompagnata da una notizia che ci ha un po' scioccati: GWT-EXT non verrà più aggiornato... o meglio, verranno corretti comunque eventuali bachi e, forse, mantenuta la compatibilità con futuri rilasci di GWT e di nuovi browser, ma di fatto lo sviluppo è fermo... questo perchè gli sviluppatori hanno deciso di propendere per lo sviluppo di una nuova tecnologia non più basata sulle librerie ext-JS.

Infatti viene caldamente consigliato al conversione a SmartGWT: http://www.jroller.com/sjivan/entry/smartgwt_1_0_released

Queste nuove librerie grafiche si basano sul framework SmartClient, che non ha, almeno per ora, i problemi delle licenze di EXT-js.

Molti più widget, un buon supporto al pattern MVC e una nuova e interessante struttura dati (molto simile sotto certi aspetti a quella che abbiamo sviluppato per la mia tesi).

Per ora non intendiamo migrare, ma in un futuro probabilmente lo faremo.

Comunque, di fatto, uno dei problemi di gwt-ext rimane: il codice che il sorgente deve scaricare è enorme, poichè tutto richiama librerie javascript che vanno comunque totalmente scaricate dal browser (e parliamo di 700K minimo, esclusa l'applicazione in sè).

Pochi giorni fa è stata rilasciato un nuovo aggiornamento di GWT-Mosaic, che ora si fa davvero interessante, si è arrivati alla versione 0.1.8 (http://groups.google.com/group/gwt-mosaic/browse_thread/thread/a114236cb7faaa37#)

Questo piccolosissima libreria gwt, piccolissima se paragonata a GWT-Ext o SmartGwt, è molto interessante perchè si appoggia nativamente e interamente su GWT... cioè non richiama codice javascript che il browser deve scaricare, ma lascia tutto in pasto al compilatore java-to-javascript di GWT... questo permettere di mettere in codice javascript (e quindi tutto peso che il browser deve scaricare) solo quello che in realtà si programma... e questo è un notevole vantaggio per applicazioni piccole o medio piccole

La differenza è notevolissima: per un mini progetto (giusto qualche pannello e qualche pulsante) con gwt mosaic, il codice (tra pagina html con js embedde e css) che il browser deve scaricare è di 92K, tra l'altro probabilmente molto riducibili, perchè si hanno due css da 28 k e molto probabilmente sono io l'imbranato che non ha capito come usarne solo uno, datyo che sono quasi identici, quindi possiamo dire che si arriverebbe a meno di 70 KB

Con gwt ext invece si tratterebbe di almeno 2MB (tra pagina html con js embedde, altri js e css) , poichè comunque bisogna scaricare il core in js (che sono le librerie ext) di 770KB, più i js dell'applicazione, circa 10 KB, più almeno 100KB di css (in questo caso obbligatori)

insomma... si va dai 80-90 KB con gwtmosaic agli 800-900 di gwt-ext.

certo, per grandi applicazioni le dimensioni di un progetto gwt-ext non cambiamo moltissimo in proporzione (il nostro helpdesk, che è abbastanza corposo, arriva a 900-1000KB totali), però la differenza è enorme.

Latex

2009-01-20T10:39:00.003+01:00

Ho iniziato ad impaginare al tesi con latex... in realtà non ho ancora terminato di scriverla, mi manca uno dei due capitoli centrali...

ma almeno inizio a scrivere seriamente il tutto.

Prendo appunti su alcuni settaggi:

Voglio usare una doppia bibliografia, così da costrurire la classica bibliografia, e successivamente, una sitografia

Uso ovviamente bibtex, decisamente comodo

lo affianco al pacchetto multibib

quindi nella classe caricata all'inizio del documento, scrivo questi due comandi

\usepackage{multibib}

\newcites{sito}{Sitografia}

dove il newcites introduce proprio la seconda bibliografia e una serie di comandi (simili a quelli di bibtex, ma con l'aggiunta ad onuno del suffisso "sito") appositi

all'interno del documento principale, subito dopo al creazione della bibliografia, creo la sitografia in questo modo

\bibliography{bibliografia} % inserisce la bibliografia e la prende in questo caso d bibliografia.bib

%sitografia, prendendo i dati da sitografia.bib, dentro il quale uso "misc"%

\bibliographystylesito{alpha}

\bibliographysito{sitografia}

All'interno del documento, usando il normale comando \cite citerò i documenti della bibliografia normale, usando il comando \citosito, utilizzo al sitografia

Per poter avere anche la sitografia, però, non posso usare il comodo comando preimpostato all'interno di TeXnicCenter "Build and View" (che compila tutto, crea il pdf, e lo visualizza), ma devo andare di riga di comando

latex tesi

bibtex tesi

bibtex sito

latex tesi

e qui si produce il file dvi

con il comando

dvips primo.dvi -o

si produce il file PostScript ps

Effective Java

2008-12-29T16:00:00.002+01:00

Da qualche settimana siamo fermi sullo sviluppo del framework (e quindi anche la mia tesi), ne ho approfittato, oltre che per migliorare il prototipo già funzionanente presso un nostro cliente, e per implementare nuove features richieste dal cliente stesso, per studiarmi uno dei libri che mi ero ripromesso di studiare: Effective Java.

Interessante direi, molto utile in qualche consiglio, meno in altri, ma direi un must.

Alcuni dei consigli trovati nel libro li ho già "implementati" nel framework, migliorando alcuni aspetti che erano già stati realizzati. E sicuramente molti altri ci saranno in seguito utili.

Lo consiglio a tutti, soprattutto a chi come me non è espertissimo nella programmazione di grandi progetti.

TeePee

2008-11-25T11:42:00.003+01:00

Dopo un po' di giorni senza post, forse è il caso di aggiornare un po' chi segue questo blog (e guardando dalle statistiche di google analytics non siete nemmeno pochi, lasciatemi gongolare, dai).

Nell'ultimo mese ci siamo dati completamente allo sviluppo del framework che fino dall'inizio volevamo sviluppare. Prima d'ora era poco più che un abbozzo, ma l'esperienza fatta nello sviluppare l'applicazione che già dei clienti stanno usando, ci ha permesso di trovare i reali bisogni di cui necessitiamo, e le carenze dei framework esistenti.

Il mio collega e correlatore ha gettato le basi, su cui ho costruito il resto, sempre sotto la sua supervisione.

Abbiamo anche deciso di rendere disponibile questo core del framework, rilasciandolos su google code con licenza GNU Lesser General Public License.

Il tutto lo trovate qui: http://code.google.com/p/teepee/

Ovviamente attualmente non si trova molto online, tranne il codice nudo e crudo, ma presto, anche ai fini della tesi, rilasceremo i javadoc e qualche file esplicativo, oltre a quelche schema UML.

A tale proposito, qualcuno ha quelche strumento (opensource o freeware) da consigliare? Per ora ho provato

violetUML, non male, ma di fatto non utile nei sequence diagram
ArgoUml, buono per il reverse enginering, mi ha generato tutti i diagramma di classe per tutti le classi del progetto, niente male, fa risparmiare tempo... ma poi poco usabile per creare i diagrammi
Visual Paradigm... niente male, ma a pagamento
StarUml... quello che sto usando ora, opensource, non male, ma i grafici non sono personalizzabili al 100%... alcune cose rimangono standard, come i punti di ancoraggio delle linee, frecce e simili.

Ancora su Orm

2008-10-08T15:43:00.003+02:00

Sono riuscito nel tentativo del salvataggio di una chiamata con hibernate/orm... ho in pratica trovato il modo per superare, più o meno, le restrizioni evidenziate in questo post(Alcuni problemi con gli id composti e i valori di default con Hibernate).

In pratica ho usato degli DAO molto più semplici... che non considerano in pratica le relazioni molti a molti... in pratica, all'interno della classe che rappresenta la tabella nel database, ogni riferimento a chiavi esterne... è memorizzato come un campo qualsiasi, ignorando assolutamente se nei DAO esiste una classe che potrebbe sostiurire il campo.

In pratica, prima, per esempio, se nella tabella chiamata evavo un campo id_imp che era ovviamente una chiava esterna per la tabella imp, il DAO era costituito come un field costituito da un elemento stesso della classe Imp... che a suo volta però al suo interno aveva un ID composito rappresentato dalla classe ImpId... ed è questo che pareva creare dei problemi.

Ora, con questi nuovi DAO più semplici, in un caso come quello sopra, id_imp è rappresentato nella classe Chiamata dal field chiamato idImp rappresentato da una semplice stringa... posso quindi assegnarli una semplice stringa... che rappresenta poi l'id chiave esterna di imp (imp ha il campo id come stringa)

In pratica come dovrei fare se usassi SQL.

Così sono riuscito a memorizzare senza problemi una chiamata assegnando tramite gli strumenti di HIBernate tutti i valori che mi interessano.

In realtà qualcosa di diverso c'è... tutti i campi sono memorizzati come dati primitivi, String, char, int, date... cioè come la definzione del campo nel database... tranne alcuni (pochissimi) come per esempio HdTipoContab, che è memorizzato ancora come classe... questo perchè (credo) proprio al tabella hd_tipo_contab non ha id composto (come invece il 99% delle altre tabelle) e quindi è comuinque molto semplice usarlo... anche se ho dovuto aggiungere un costruttore alla classe così come era stata creata automaticamente.

Questi DAO semplificati li ho ottenuti usando sempre Hibernate Tool, plugin di Eclipse, selezionando perà nel file di configurazione hibernate.revenge.xml solo el tabelle vere e proprie, ignorando le varie view presenti nel database, e selezionando, all'atto della creazione del codice, nessuna opzione particolare (quindi non selezionando"generate basyc typed composite id", nè "Decect optimistic lock columns", nè "detect many-to-many tables"), e nella schermata exporters, non ho selezionato nessuna delle opzioni in alto (quindi non ho selezionato nè "Use java 5 sintax" nè "Generate EJB3 annotations") e come exporters ho selezionato "domain code" (che genera le classi java che poi utilizzo), "Hibernate xml mapping .hbm.xml" (che genera i file xml per specificare ogni singola classe), "DAO Code" (che a quanto pare genera delle classi java chiamata come le precedenti+home... non so esattamente a cosa siano necessari, pare sempre ad hibernate), sia "Hibernate Xml Configuration, cfg.xml" che genera un nuovo hibernate.cfg.xml con i riferimenti ai file .hbm.xml che vengono generati.

OpenLaszlo e Flex

2008-09-21T16:16:00.009+02:00

OpenLaszlo e Flex sono stati due dei framwerok di sviluppo di RIA che avevamo inzialmente preso in considerazione. Li scartammo quasi immediatamente per il legame che questi framweork hanno (o meglio, nel caso di Laszlo, avevano) con Flash e per lo sviluppo in Javascript/Actionscript, e non Java.

Flex è un framework rilasciato da Adobe per la creazione di ria con un linguaggio markup proprio, MXML, basato su XML, utilizzato per descrivere il layout dell'interfaccia utente e i comportamenti, mentre ActionScript 3, linguaggio di programmazione orientato agli oggetti, utilizzato per creare la logica client. Il tutto compilato poi per la creazione di oggetti SWF per l'esecuzione tramite Flash Player.

OpenLazlo oper in maniera piuttosto simile, anch'esso con un linguaggio simil XML condito con un linguaggio di programmazione, Javascript, anch'esso poi compilato in file SWF.
Attualmente però la nuova versione di OpenLaszlo supporta anche la possibilità di sviluppare ria anche senza l'uso di flash, ma con dhtml/ajax (come gwt, in poche parole), ma questo supporto è stato introdotto solo con la versione 4.1, rilasciata a Luglio 2008... decisamente molto più tardi di quando la nostra scelta di frawork base su cui lavolare è caduta su GWT.

E' comunque interessante dare uno sguardo a questa tecnologia.
Grossomdo il paradigma di programmazione non è così distante da GWT... si programma in un linguaggio, il framework mette a disposizione un compilatore che processa i file sorgente e produce del codice che verrà poi eseguito sul client.
Il linguaggio di programmazione usato per OpenLaszlo è un markup language, LZX, linguaggio risultante dalla fusione di aspetti dichiarativi, derivanti dall' XML, con altri tipici della programmazione imperativa Object-Oriented, derivanti da JavaScript. Nei file sorgenti di OpenLaszlo infatti si utilizza una sintassi molto simile a quella di un classico file XML, con riferimenti alle API messe a disposizione del framwork, con l'aggiunta di codice JavaScript.
Il compilatore poi, processando questi file sorgenti, crea un file SWT (quindi un file per Macromedia Flash), che possa quindi essere eseguito da qualsiasi browser con il Flash Player. Recentemente è stato anche introdotto il supporto per la compilazione di codice slegato da Flash,
generando quindi codice DHTML/AJAX.
Comunque sia, il codice simil-Javascript scritto nei file LZX non è quello eseguito dal browser, ma viene intepretato dal compilatore e resituito come codice actionscript di Flash, nel caso si vada poi ad utilizzare la tecnologia di Macoromedia, o generando del nuovo codice Javascript nel caso di utilizzo del classico AJAX.

Pro:

La realizzazione dell'interfaccia utente risulta abbastanza semplice da realizzare, lineare e abbastanza riusabile. Il tutto viene realizzato con una serie di tag LZX che definiscono i componenti dell'interfaccia, la loro posizione, e le loro carattaristiche, il tutto riutilizzabile con la logica della programmazione ad oggetti.
Per esempio questo codice
< canvas>
<button onclick="vw.setWidth(200)">Expand
Width</button>
<button x="120"
onclick="vw.setWidth(100)">Reset</button>
<view id="vw" y="30" width="100" height="100">

<handler name="onwidth">
this.setAttribute('bgcolor', (this.width
> 100 ? red : blue));
</handler>
</view>
</canvas>
permette la creazione di due pulsanti, e relativi eventi.
Ci sono a disposizione numerevoli componenti, personalizzabili e riusabili, e le api, lmanoe per quanto riguarda l'implementazione con flash, è ben supportata e testata

Contro

Per dare un minimo di interattività alla pagina bisogna comunque utilizzare dell'actionscript, quindi bisogna conoscere questo linguaggio
Il supporto DHTML non è ancora maturo... quindi si può produrre stabilmente solo con flash, e quindi ci si lega troppo a questo prodotto

Fonti:
OpenLaszlo White Paper: http://www.openlaszlo.org/whitepaper/LaszloWhitePaper.pdf

Gwt-Log

2008-08-29T11:52:00.003+02:00

Una delle cose più noiose nel logging con applicazioni GWT è che, lato client, non si riesce ad usare nativamente la console di loggin, ne quella di GWT in Hosted mode, nè quella del server. Il che diventa noioso, poichè spesso si ha la necessita di avere un minimo di tracciabilità delle attività svolte dal codice, e si vuole subito avere un feddback con il loggin, ma con gwt, almeno lato client, sono sempre stato obbligare ad usare i fastidiosi "windows alert".
Certo, da una parte hanno la loro utilità, come quella di bloccare, di fatto, l'esecuzione dell'applicazione e questo può avere un suo aspetto positivo... ma sono troppo invadenti... e soprattutto se ce si li dimentica nel codice, passando poi il prodotto al cliente, si posson avere situazioni imbarazzanti.

Ho trovato, in questi giorni, una libreria davvero interessante per il loggin con GWT

GWT-LOG

Che gestisce in maniera del tutto trasparente il loggin su più livelli... infatti, lasciando fare tutto a lui (ci sono comunque dei setting da poter usare per disabilitare/abilitare i vari tipi di logger), si può avere il log lato server (anche gli errori lato client possono essere spediti in amniera del tutto trasparente al server con rpc), con la normale console errore del server (errori lato server, come con il normale System.out o System.err), sia nella console dell'Hosted Browser di GWT (come con il classico GWT.log)(client e server), sia un log da leggere con al console di FireBug (un ottima estensione di Fiorefox), sia con un interessante "finestrella div" che compare all'interno delal applicazione stessa, un div semitrasparente draggabile...
Insomma, si può fare veramente di tutto e con in pratica nessuna riga di codice particolare... si importa la libreria nel progetto, si inseriscono alcune righe nel file gwt.xml... e basta usare Log(stringa) e via che si logga dappertutto.
Stupendo.

Aggiornamento: Strani Errori
Ieri sembrava funzionare tutto perfettamente, mentre oggi, aggiornando il progetto a GWT 1.5, cambiando quindi librerie eccetera, ho forse commesso qualche errore... e non si compilava più il modulo gwt... continuava a lamentarsi che non trovava la libreria di gwt-log, in particolare che non trovava il file di confiugurazione gwt.xml del progetto gwt-log
L'errore era:
[echo] Module: com.fdlservizi.sse.HelpDeskGWT
[java] Loading module 'com.fdlservizi.sse.HelpDeskGWT'
[java] Loading inherited module 'com.allen_sauer.gwt.log.gwt-log'
[java] [ERROR] Unable to find 'com/allen_sauer/gwt/log/gwt-log.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?
[java] [ERROR] Line 7: Unexpected exception while processing element 'inherits'
[java] com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
[java] at com.google.gwt.dev.cfg.ModuleDefLoader.nestedLoad(ModuleDefLoader.java:225)
[java] at com.google.gwt.dev.cfg.ModuleDefSchema$BodySchema.__inherits_begin(ModuleDefSchema.java:194)
[...]

Non so per quale motivo, ma ignorava totalmente la presenza della libreria, che invece avevo normalmente selezionato tar le librerie esterne in IntelliJ Idea.
Poi, guardando bene il forum di grails (in particolare questa discussione), non ho capito bene perchè, ho scoperto che dovevo inserire tale libreria nella directory /lib/gwt.
Cosa mai fatta, anche perchè eventualmente le librerie le avrei messe in /lib, dentro al quale la directory gwt non esisteva nemmeno.
Ora invece, con l file messo lì dentro, funziona senza problemi.... misteri di grails.

Alcuni problemi con gli id composti e i valori di default con Hibernate

2008-08-22T11:05:00.004+02:00

Stamattina, dopo aver passato due giorni a studiarmi il "paradigma di programmazione" per le GUI usato in sap (potrebbe tornarci utili, è uno interessante punto di riferimento a cui potremmo ispirarci), sono tornato a fare qualche esperimento con Hibernate.
In particolare ho continuato a giocare con le select e gli insert con le nostre classi POJO create per ORM.

Ho generato una pagina gsp di esperimento, con alcuni tasti gwt che usano una rpc, che "stimola" sue servizi lato server, uno per la ricerca delle classi (sempre "chiamata") e una per salvarla.
Nessun problema nella ricerca di chiamata, sia con il findall, il list, il find, i criteria, eccetera...
Bhe, in realtà ci sono dei problemi quando nel database ci sono dei null di troppo... ma è un problema correlato a quello che descvrivo qui in seguito.

Infatti nel momento dell'inserimento abbiamo trovati i primi problemi. Essendo il nostro database costruito con delle doppie chiavi primarie (ogni tabella ha un id, nemmeno numerico autoincrementale, come sarebbe meglio fosse, ma come stringa, correlato sempre ad un altro campo presente in ogni tabella "az" che fa riferimento ad una tabella, az), ogni volta che noi abbiamo una chiave esterna, questa chiave esterna è anch'essa costruita con due campi... e anche al tabella a cui facciamo riferimento ha un id primario composto. Questo comporta che nel ricavare i dati di uno di queste colonne, devo fare un doppio passaggio. Nella colonna ricavo l'id delal classe associata, nella quale ricavo poi l'id, che è quello che viee di fatto immagazzinato nella colonna stessa.
Ma all'atto dell'inserimento questo doppio passaggio non funziona. In pratica non riesco a memorizzare i campi se sono chiavi secondarie esterne... e questo ovviamente è un grosso problema. Il fatto è che non tutto il database è costruito in maniera perfetta, per esempio la tabella chiamata non ha riferimenti di chiave secondarie che puntano ad azienda, altre colonne sì... quindi il toll per il reverse enginering è andato un po' in pappa e non riesce a gestire in maniera completa queste doppie chiavi.
Il tutto dovrebbe risolversi attuando una modifica al database che già volevamo attuare, cioè eliminare totalmente tutte le chiavi primarie composte con quel campo az, che di fatto non serve a nulla. Era stato introdotto tempo addietro quando il programma doveva essere multiazienda, cosa che è stata in seguito abbandonata.
Non toglieremo nella tabelle il campo az (presente in tutte) e nemmeno la tabella az (per retrocompatibilità, alcune query presenti qua e là nel programma fanno riferimento a questa colonna), ma modificheremo tutte le chiavi primarie, facendole diventare uniche e non più composte (composte cioè dal solo campo id) e elimineremo ogni chiave secondaria esterna, in ogni tabella, che faccia riferimento ad az.

Stamattina mi sono accorto però di un nuovo problema... la generazione automatica delle classi di dominio POJO, usate da Hibernate, non ha tenuto conto dei valori di default impostati nel database... essendo in sql server sono impostate con delle costraint di questo tipo
ALTER TABLE [dbo].[chiamata] ADD DEFAULT ('N') FOR [libretto]
in questo caso la colonna libretto della tabella chiamata è impostata con un valore di default = N (tra l'alro la colonna ha come proprietà il poter accettare valori null).
In hibernate di fatto non esistono modi per specificare nel file di mapping delle classi i valori di default... esisterebbe ma non è portabile sui vari databasi, prchè bisognerebbe specificare il formato di colonna, diverso per ogni tipologia di database, qundi da evitare.
Di fatto, in una situazione del genere, se si vuole memorizzare nel database una classe di dominio per la quale non si specificano valori per un determinato fields, se questo accetta nel mapping valori null, hibernate lo inizializza automaticamente con null... infatti hibernate, quando deve memorizzare una classe sul database, nella query sql insert, specifica tutti i campi della classe stessa che nella proprietà del mapping abbiano insert=true
Ovviamente, se questa proprietà non viene specificata, hibernate automaticamente le popola con il valore null se la proprietà stessa l'accetta, o con al string avuota nel caso sia specificata not null
Questo significa che di fatto vengono ignorati i valori di default specificati nel database, perchè di fatto al database arriva una query con quei campi specificati... quindi inserisce quelli e non i valori che lui ha come default.
Se per esempio voglio forzare il database ad inserire i valori di dafault, dovrei fare in modo che hibernate non gli passi proprio quel campo... cosa possibile da fare, basta specificare insert=false

facendo così hibernate ignora il campo libretto, e il database, non ricevendolo nella query insert, lo inserisce con il valore di default
Così facendo però non è possibile inserire alcun valore... quindi se io volessi, all'atto della insert, specificare un valore per quella propietà, di fatto questa viene ignorata.

Nel nostro caso, in effetti, c'è un modo molto semplice per risolvere il problema... basta mettere nel costruttore della classe di dominio il valore di default, o nel mio caso, dato che per le classi di dominio che vengono utilizzate anche lato client gwt, devo costruire una determinata classe che viene poi serializzata ed usata nel passaggio dati nella rpc, dichiaro quel dato field con il valore di default, così facendo, anche se lato client non viene specificato alcun valore, di fatto hibernate lo riceve con il valore preimpostato e lo passa al database.

public class DatiChiamata implements IsSerializable {
public String id;
public String apertaDa;
public String tipoChiamata;
public String gradoDisservizio;
[...]
public String noteAssegnazione;
public String libretto = "N";
[...]
}

JAVA DAO, ORM, POJO

2008-08-07T15:16:00.002+02:00

Abbiamo deciso di approfondire lo studio di Hibernate, effettivamente potrebbe esserci molto di aiuto, sia per la normale interrogazione di database (sia in selezione che in salvataggio) sia perché potrebbe evitarci i problemi di compatibilità con i due database che vogliamo supportare: Oracle e SQL Server.

Abbiamo deciso di non affidarci totalmente a GORM (Grails Object Relational Mapping) perchè groovy si rileva meno performante in alcune condizioni, e abbiamo paura che sia limitante nel futuro.

Quindi la scelta ricade sulla creazione di un ORM tramite JAVA DAO (Java Data Access Object) create con delle classi java POJO (Plain Old Java OBject).
Questo significa mappare tutto il nostro database con delle semplici classi java che devvano rispecchiare determinate carrateristiche.
In particolare Hibernate non ha richieste eccessive, ma secondo la logica del convention over configuration, è sempre meglio cercare di rispettare più richieste possibili, tra le quali:

Ogni classe dovrebbe avere un suo identificare univoco, chiamato Id (e qui per noi è un problema... perchè in pratica ogni tabella del nostro database ha un id composto da due campi stringa... decisamente lontano dagli standard che prevedono un id numerico autoincrementale... lo so lo so)
Ogni classe dovrebbe prevedere un costruttore a zero argomenti, che sarà utilizzato da Hibernate per istanziare la classe
Tutti i campi della tabella dovrebbero essere trasformari in campi della classe. Quindi ogni classe dovrebbe avere una serie di campi da considerare persistenti (quindi direttamente mappabilis ul database), preferibilmente da settare come privati, e quindi definire i getter e i setter per ognuno di questi campi. In particolare ogni campo dopvra rispettare le classiche convenzioni ORM, quindi nel caso di un nome campo (o tabella) composto d apiù nomi uniti con l'underscore, si dovrà converire con nome univoco con le lettere maiuscole per ogni parola che lo compone... esempio il campo data_di_nascita sarà convertito in dataDiNascita. Inoltre per convenzione Hibernate si aspetta di trovare i getter e i setter così composti getDataDiNascita e setDataDiNascita.
Le classi non dovrebbero essere dichiarate final, o in tal caso caso, dovrebbero implementare un interfaccia che dichiara tutti i metodi pubblici.
Nel caso di id composti conviene dichiarare l'id della classe come istanza di un'altra classe, convenzionamente chiamata nomeclasseId, nella quale vengono specificati i singoli campi delal chiave primaria composta.

Ci siamo affidati, per la stesura di queste classid i dominio, ad Hibernate Tool, un plugin per Eclipse appositamente studiato dallo staff di hibernate.
Seguendo i consigli di questa pagina, abbiamo proceduto con questi passi

dopo aver installato il plugin per eclipse (semplicemente scompattato lo zip preso dalla pagina di cui supra), ho creato un progetto grails, vuoto, con la classica procedura (nuova directory, grails create-app)
Ho messo nella cartella lib del progetto il jar con il driver jdbs del database sqlserver (jtds-1.2.2.jar preso su sourceforge). Avviato eclipse ho importato il progetto appena creato.
tasto destro sul progetto, ho creato un nuovo file di configurazione per hibernate: File -> New -> Other -> Hibernate -> Hibernate Configuration File.
Il file di configurazione l'ho salvato nella directory grails-app/config/hibernate
Come dialect ho scelto SQL Server, che poi sarà salvato nel file come org.hibernate.dialect.SQLServerDialect
Come classe del driver ho scelto net.sourceforge.jtds.jdbc.Driver
Come connection url jdbc:jtds:sqlserver://localhost/Sacci_Gabry;instance=SQLEXPRESS (ho instalato il database in locale)
Il resto ho lasciato in bianco
ancora tasto destro e quindi ho settato al configuarazione della console di Hibernate (File -> New -> Other -> Hibernate -> Hibernate Console Configuration)
Ho lasciato tutto come proposto, inserendo però nel classpath la lib inserita prima nella directory lib del progetto (il driver jdbc)
ancora tasto destro e quindi ho creato un file per il reverse enginering (di fatto quello che poi creerà i file) [File -> New -> Other -> Hibernate -> Hibernate Reverse Engineering File(reveng.xml) ]
Il file l'ho inserito come prima in grails-app/config/hibernate
dopo aver selezionato la configurazione e aspettato che il database venisse letto, ho selezionato solo le tabelle del dbo
Fatto questo ho fatto partire la compilazione (Lunch -> Hibernate Code Generation -> Open Hibernate Code Generation Dialog)
Come outpout folder ho scelto src\java, e come nome di package gorm
Come exporter ho selezionato le domain code, hibernate xml mappings, hibernate xml configuration, e lo Schema Documentation (decisamente opzionale, ma carino, genera della documentazione html interessante e facile da consultae)
La generazione del codice impiega un po' ad eseguirsi.
A questo punto bisogna spostare qualche file per seguire le convenzioni hibernate/grails
Il file hibernate.cfg.xml appena generato, diverso dal precedente in quanto conteiene tutti i riferimenti ai file di maping, va spostato nella directori config/hibernate, sovrascrivendo quindi il precedente
Tutti i file hbl.xml vanno spostati nella stessa directorty grails-app/config/hibernate

A questo punto tutto è pronto per lavorare... si possono visualizzare e quindi utilizzare le view di eclipse predisposte per hibernate, consultare il database, la session factory, fare query HQL ecc..

Hibernate, session, Dynamic Methods + Inject

2008-07-29T14:53:00.005+02:00

Ci siamo accorti che così come utilizziamo noi sql, creiamo una differente connessione al database per ogni servizio, cosa non molto gradevole in effetti.
Infatti, sino ad ora, abbiamo raramente usato GORM e Hibernate, data la "stramba" costruzione del database già esistente per il programma (id stringa, più campi per chiavi primarie, eccetera), e quindi risulta più "facile" usare sql diretto piuttosto che gorm e hibernate. Quindi usiamo groovy.sql.Sql per la creazione di query sql on the fly.
Abbiamo tentanto la strada della memorizzazione delle sessioni nella session http, cosa che funziona, ma rende poco pratica la gestione delle sessioni stesse, perchè ogni volta che serve richiamare la connessione, bisogna scrivere svariate righe di codice, per ogni metodo dei dervizi che utilizzano sql...
Per farlo abbiamo usato questa strategia: nella prima connessione al database creata, quella del login, creiamo un istanza SQL come normalmente si dovrebbe fare in ogni service
import groovy.sql.Sql
def sql = Sql.newInstance("jdbc:jtds:sqlserver://192.168.0.22/sacco;instance=SQLSSE", "sa", "fdl", "net.sourceforge.jtds.jdbc.Driver")
e poi la memorizziamo nella sessione come altre informazioni (user, profilo, eccetera)
def session = RCH.currentRequestAttributes().session
session.connessioneDB = sql
E il tutto sembra funzionare... per poi richiamare questa connessione sql, basta fare in ogni servizio
def session = RCH.currentRequestAttributes().session
def sql= session.connessioneDB
per poi usare l'oggetto sql normalmente (quindi sql.execute eccetera)
Questo portava anche al vantaggio si avere la stringa di connessione al database in uan sola classe, e non in ogni servizio (maggiore mantenibilità)

Abbiamo quindi provato un'altra strada... essendoci hibernate comodamente pronto nel framework grails, abbiamo provbato ad usare le sessioni di hibernate per fare una cosa simile, in più abbiamo provato ad utilizzare i metodi dinamici di groovy iniettando nei servizi un oggetto sql già pronto all'uso... il tutto funziona... solo che non usando nativamente hibernate (ma lo usiamo solo per ricavare connessioni e non per gestire gli accessi al database) pare che non si riescano a recuparare connessioni univoche... ma che hibernate ne crei una nuova ogni volta che viene invocato con il metodo che più avanti spieghiamo.
E' stato comunque interessante provare questo approccio perchè ci ha permesso di verificare la possibilità di iniettare metodi (e proprietà) in svariate classi (singole, nominali, tutti i servizi, i controller, le classi di dominio eccetera)... ed addirittura provare la creazione di plugin (che pare essere l'unica strada efficace per effettuare l'iniettamento di metodi dinamici)
Questo approccia, nonostante non persegue il fine di riutilizzare una connessione unica, ha il vataggio di mettere a disposizione l'oggetto sql ad ogni servizio, senza riga di codice alcuna, e di utilizzare il file DataSource.groovy normalmente presente nei progetti grails... così si possono utilizzare i tre environment di questo file (development, production, test)

Abbiamo quindi creato un nuovo plugin in (seguendo la procedura indicata qui: http://docs.codehaus.org/display/GRAILS/The+Plug-in+Developers+Guide), dentro al quale abbiamo inserito il seguente codice:


def doWithDynamicMethods = {applicationContext ->
     System.err.println("il metodo dinamico è partito1");
     def sf = applicationContext.sessionFactory    
     com.fdlservizi.sse.SSEService.metaClass.getDbConn = {->
         def sessione = sf.currentSession
         def connessione = sessione.connection()
         return connessione
     }
 }

Il quale inietta nella classe SSEService il metodo gerDbConn. In Grails inoltre vige la convenzione che ad ogni metodo get e set, corrisponda immediatamente, anche se non dichiarata, la relativa proprietà... quindi, specificando per una determinata classe il metodo getProprietà e/o setProprietà, automaticamente si può richiamare il metodo getProprietà semplicemente definendo: def proprietà (oppure utilizzando direttamente proprietà)

La classe SSEService, posta nella directory src/groovy/com.fdlservizi.sse/ è così composta


package com.fdlservizi.sse

import groovy.sql.Sql
import java.sql.Connection

class SSEService {
  
   Sql getSql(){
def globalSql = new Sql((Connection)dbConn)
       globalSql.execute("set dateformat ymd")
       System.err.println("connection = " + (Connection)dbConn);
       return globalSql
   }

   Connection getConnection(){
       System.err.println("connection = " + dbConn);
       return dbConn
   }

   org.hibernate.impl.SessionImpl getDbSession(){
       return dbSess
   }
}

In questa classe, quindi, per quello detto prima, semplicemente richiamando "dbConn", è come se richiamassimo getDbConn iniettato dal plugin.
Questa classe la usiamo poi per estendere ogni servizio che intenda usare una connessione sql... in questo modo, all'interno del servizio, possiamo semplicemente usare la sintassi che fino a quel momento usavamo, senza mai dichiarare l'oggetto sql.... perchè di fatto iniettato nella classe che estendono, quindi ereditato

In ogni servizio infatti si può tranquillamente scrivere, per esempio
sql.eachRow("select * from imp_tipo")
e si sottoindente GetSql, che a sua volta, sottointende getDbConn, che a sua volta sottointende applicationContext.sessionFactory.currentSession.connection() che restituisce la connessione di hibernate (presa dal file DataSource.groovy)
Questo però, come detto prima, al contrario delle nostre aspettative, sembra aprire sempre nuove connessioni.
Inoltre, nella classe SSEService, facciamo ad ogni richiesta di connessione, l'esecuzione del setdateformat, necessario per l'esecuzione delle nostre query, anche questo vantaggio notevole, dato che senza questo accorgimento bisognava eseguirla, in ogni servizio che utilizzava le date (DateTime, TimeStamp) e simili nelle query.

Abbiamo comunque deciso di concetrarci ora allo studio del dialetto di Hibernate, per utilizzare direttamente le sue potenzialita, demandando l'uso di sql diretto solo nei momenti in cui sarà strettamente necessario. Questo ci permetterà, presumibilmente, di demandare ad hibernate la gestione del pool di connession al database e le differenze tra i due database che dovremmo abdare a supportare (sql server e oracle).

Versioning

2008-06-26T09:38:00.006+02:00

Sto provando ora l'utilizzo delle versioni per i progetti grails.
Da riga di comando, si può manipolare il file application.properties, settando quindi la versione, con
grails set-version n
dove n sta per il numero di versione.
Questo va a modificare la proprietà app.version all'interno del file sopracitato.

Successivamente si può utilizzare questo numero, all'interno dei progetti grails, con

da un controller con

def version = grailsApplication.metadata['app.version']

Oppure con le righe

import grails.util.*
def grailsVersion = GrailsUtil.grailsVersion

Oppure, all'interno di pagine gsp, con

Una volta che è stata settata al versione dell'applicazione, la creazione del war con il comando
grails war
rifletterà questi cambiamenti, nominando il war come nomeapplicazione.n.war, dove n sarà il numero di versione (in realtà questo per ora non succede, non so perchè, rimane sempre con il numero di versione 0.1; sul forum mi hanno consigliato di usare il comando grails clean prima di grails war, ma nulla)

Durante il deploy si può inoltre specificare la directory di deploy, in quanto, di default, viene messo in una directory con lo stesso nome del war.
Per farlo basta usare il comando
asadmin deploy --contextroot /HelpDesk nomewar

Prima però bisogna fare l'undeploy dell'eventuale app già installata in quella directory, lo si fa con
asadmin undeploy nomeapp
nel nostro caso

asadmin undeploy HelpDeskGwt.1.2.6

AGGIORNAMENTO del 1 Luglio
Ho trovato l'errore del war... era colpa mia, nel file di configurazione config.groovy avevo inserito una riga di codice:
grails.war.destFile = """HelpDeskGwt-0.1.war"""
e questo forzava il nome del war... ora funziona tutto

Anche in Italia si muove qualcosa

2008-06-13T16:44:00.002+02:00

Negli ultimi giorni anche il gruppo (mailing list su yahoo gropuc: http://it.groups.yahoo.com/group/Grails-IT/) italiano di Grails si sta animando, e oggi è stato rilasciato un tutorial interessante (mannaggia... se ci fosse stato un mesetto fa, avrei faticato molto meno)

Questo il messaggio integrale

Ciao,

ieri è stato pubblicato su Mokabyte il primo articolo su Grails e Groovy.

http://www2.mokabyte.it/cms/article.run?articleId=DYG-V69-HKE-Z3O_7f000001_10553237_7391cad5

Per come è fatto Grails, una Demo vale più di mille parole. Anche
l'articolo riprende questa impostazione alla "sporchiamoci subito le
mani", nei prossimi numeri andrò più in profondità sui vari argomenti
chiave.

Ovviamente, qualsiasi domanda o suggerimento per i prossimi numeri è
bene accetto.

Buon weekend!

Brando

Alcuni Errori - bug risolti, da ricordare

2008-06-12T12:23:00.003+02:00

Durante lo sviluppo della nostra interfaccia sono emersi dei comportamenti strani di Gwt o GET-EXT o grails...
Forse dipendenti dalla mia scarsa esperienza, o forse da veri e propri buchi... non so

Elenco qui quelli che ho risolto, così da ricordarmi in futuro

Normalmente grails si accorge di ogni modifica effettuata ai file sorgenti e tenta la ricompilazione dei file necessari. Non ne sappiamo bene i motivi, ma così come è impostato Grails e il plugin di gwt, se si modificano dei file lato client di gwt, non sempre parte la compilazione. O meglio, sembra partire sempre, ma sembra che non vengano cancellati i file che gwt ha creato la compilazione precedente. Di fatto quindi le modifiche non vengono prese.

Ho perso ore prima di capire questo problema... e pensavo che none ro capace di programmare, non mi capacitavo del perchè non vedevo le modifiche che avevo progettato... ed ecco poi risolto l'arcano... il problema, almeno questa volta, non ero io.

RISOLTO:
Francesco ha trovato al soluzione... obbligare lo script del plugin di gwt a ricompilare tutto.
Questo lo si ottiene aggiungendo alla riga 76 del filke _Internal.groovy del plugin il seguente codice
gwtForceCompile = true
Avendo quindi questo codice:modules.each { moduleName ->
gwtForceCompile = true
if (!gwtForceCompile &&
GU.environment != GA.ENV_PRODUCTION &&
neW File("${outputPath}/${moduleName}/${moduleName}.nocache.js").exists()) {
// We can skip this module.
return
}

In più, per evitare il problema derivante dal "Java Heap Speace" abbiamo modificato il comando
java(classname: 'com.google.gwt.dev.GWTCompiler', fork: 'true')
sempre nello stesso file con
java(classname: 'com.google.gwt.dev.GWTCompiler', fork: 'true',maxmemory: "512m")

Se si hanno poi dei problemi con il jar di getext (non ho capito bene in quali casi avviene il problema, ma in alcune circostanze è così) va aggiunta anche questa riga di codice
pathElement(location: "${basedir}/lib/gwtext.jar")
nella zona della dichiarazioni del classhpath
Mai modificare un file di servizio lato server quando l'applicazione è up, perchè se per caso si aggiorna la pagina dell'aplicazione, grails si accorge che qualcosa è stato modificato, tenta la ricompilazione ma CANCELLA deliberatamente i file del servizio lato client. Non so bene perchè succeda, forse è provocato dalla modifica al plug in che abbiamo fatto (che forza la compilazione del modulo gwt, per risolvere il baco di cui sopra). Bisogna prima fermare l'appplicazione, o distruggere il server, poi ricompilare.
Attenzione con la gestione degli ascoltatori dei pulsanti, se poi li si vogliono abilitare e disabilitare. Non so se è un paco gi GWT o GWT-EXT (i button e i listener che utilizzo sono di GWT-EXT) o se è un normale comportamento... sta di fatto che se si aggiunge un ascoltatore ad un pulsante con una ascoltatore anonimo (come quasi sempre si fa), se ad un certo punto lo si disabilita, pare scomparire l'ascoltatore associato, quindi anche se lo si riabilita, non ascolta più nulla.
Nel mio codice infatti avevo questo

salvaButton.addListener(new ButtonListenerAdapter(){
public void onClick(Button button, EventObject e) { [...] }});

Trasformato poi in

salvaButton.addListener(new AscoltatoreBottoneSalva()); private class AscoltatoreBottoneSalva extends ButtonListenerAdapter{ public void onClick(Button button, EventObject e) { [...] } }

Giornata di aggiornamenti

2008-06-10T11:43:00.003+02:00

Stamane è giornata di aggiornamenti.
Novità non indifferente, in ufficio abbiamo aperto la nuova macchina del caffè, una gaggia, tutta automatica, con il caffè in grani... scusate se è poco... la macchinetta di prima quasi ci esplodeva in mano ogni volta che l'accendevamo...
Bella bella...
vabbhe, torniamo alle cose importanti (perchè, il caffè non lo è? sì, è essenziale nella vita di un programmatore, ma forse non ai fini di questo blog)

Stamattina ho aggiornato sia Grails che Groovy
Di Groovy è stata rilasciata la versione 1.5.6, avevo installato sino ad ora la 1.5.5... d fatto nulla di che, solo qualche bugfix e migliorie varie...
Di Grails è stata recentemente rilasciata la 1.0.3, con alcuni bug fix, il supporto al tipo Enum, e un nuovo modo operativo, l'interactive mode, e migliore supporto all'internalizzazione i18n.
Oltre aver installato grails ho anche aggiornato il nostro progetto con la nuova release, dopotutto è semplice... basta il comando grails update nella directory del progetto.

AGGIORNAMENTO di Giovedì 12
Oggi ho aggiornato anche gwt-ext, di cui hanno rilasciato al versione 2.0.4
Alcune importanti migliorie sono presenti in questo aggiornamento, come il supporto a firefox3, che con la nuova verisone, dava alcuni problemi (firefox3 è+ molto più compatibile agli standard w3c di firefox2 e ie7... questo per assurdo creava problemi).
In questo aggiornamento c'è anche una nuova componente, pagebus... non so esattamente cosa sia, non ho capito, si orienta su nuove tecnologie presenti in opera, firefox, e safari. Comunque proprio questo aggiornamento ha iniziato a crearmi dei problemi.
Non in fase di compilazione, tutto filava liscio, ma Intellij IDEA ha iniziatoa darmi strani errori... in tutti i file mi continuava a dire
class blabla is defined in module 'com.gwtext.Pagebus' witch is not inherited in in module 'nome dle modulo del mio progetto'
ho aggiunto questa riga

al file nomemodulo.gwt.xml

Rieccomi

2008-06-06T17:18:00.002+02:00

Dopo quasi un mese senza aggiornamenti, rieccomi.
Ho avuto poco tempo da dedicare al blog, nonostante le mie intenzione, a causa del sovraccarico di lavoro che la consegna di un progetto che mi coinvolgeva in prima persona ha portato.
Infatti, proprio durante lo studio sulla possibile accoppiata Grails+GWT (e GWT-Ext) si è conretizzata la possibilità di utilizzare proprio queste tecnologie per lo sviluppo di uno dei lavori richiesti da un cliente della fdl servizi.
Bisognava infatti rivedere un "HelpDesk" (una sorta di gestioen di ticket-aiuto) per la gestione di una centrale termica di un noto ospedale milanese.
Il tutto ovviamente deve essere usufruibile via web, e quale migliore occasione per testare queste tecnologie?

Il risultato? decisamente buono
A parte molti problemi nati qua e là durante il percorso, e quasi integralmente risolti, abbiamo ottenuto un interfaccia fresca, veloce e razionale, molto più performante di quello che pensavamo. Le rpc di GWT, integrate lato server con servizi groovy-grails, hanno una risposta davvero buono e lo scambio di dati tra client e server, anche attraverso "internet" e non solo uan rete intranet, è davvero buona, anche quando si tratta di compilare una griglia con migliaia di stringhe al suo interno.

Presto metterò online alcuni stralci di codice, in particolare per quanto riguarda la realizzazione delle RPC (come mi è stato richiesto da altri ragazzi che mi hanno scritto via mail per problemi riguardati lo sviluppo di RPC in GWT).
Parlerò inoltre della delegazione, da preferire in alcuni casi all'ereditarietà... anche se questo pattern, risolvendomi alcuni problemi e semplificandomi alcuni dettagli, mi ha portato a problematiche che non ho ancora risolto, che spero di annullare ocn lo studio di alcuni pattern proposti dai libri che ho già nominato in passato sul blog.

Grails + GWT

2008-05-07T16:01:00.006+02:00

Ho finito di leggere ed applicare l'esempio del libro "Getting started with Grails"... sembra proprio essere un gran bel framwork, ottimo per lo sviluppo di service web, praticamente fa tutto lui e grazie alla convention over configuration il codice da scrivere è davvero poco. Eseguendo la logica del MVC sembra non sia difficile integrare, come parte "view" del client dei moduli GWT.

Quindi ora passo allo studio proprio dell'integrazione di Grails con GWT.
Esiste un plugin per grails, già esistente nella normale installazione di Grails: http://grails.org/GWT+Plugin

Purtroppo sul sito di codehouse il plugin, o meglio, l'integrazione effettiva di gwt e grails non sono ben documentate, anzi...
Per prima cosa l'installazione del plugin nei singoli progetti grails non è veloce, almeno la prima volta: eseguito nel progetto racetack, quello che ho creato studiando GSWG, il comando
grails install-plugin gwt
ho dovuto aspettare quasi 10 minuti prima che si "ripulisse la cache"... di cosa non so bene.

Ho quindi creato il modulo gwt, chiamandolo Racetrack, seguendo la classica regola dei nomi del package, quindi con il comando
grails create-gwt-module com.fdlservizi.Racetrack

Seguendo la logica che quella che voglio fare è una view al progetto già esistente e funzionante, ho creato la pagina hosting del modulo gwt pensandola proprio come una view al controller "race".
La convenzione del plug in di gwt vuole che con il comando grails create-gwt-page , dove è la pagina hosting con il relativo path, se la pagina è indicata come una gsp e come indirizzo ha una singola cartella, questa viene interpretata come un controller view, altrimenti viene trattata come una normale pagina web.
Quindi ho eseguito il comando
grails create-gwt-page race/gwt.gsp com.fdlservizi.Racetrack

Tutto ciò dovrebbe avermi creato i file di configurazione necessari per il funzionamento del modulo gwt, e la pagina hosting dove mettere poi i widget gwt.
Con il comando
grails run-gwt-client
parte l'esecuzione dell'hosted mode di gwt, quindi parte anche il "browser" interno di gwt... va però precisato, e io me ne sono accorto dopo un po' di imprecazione, che deve essere attivo il server web... quindi da IDEA prima faccio partire il progetto racetrack e poi eseguo il comando run-gwt-client (ovviamente questo e i comandi precedenti vanno fatti all'interno del path del progetto racetrack)

Edit 8 Maggio
Iniziano i primi problemi... in pratica, come indicato nella pagina del plugin di gwt, per poter usare map e list in gwt, bisogna specificare nel servizio di grails il tipo di ritorno di queste liste o mappe. In teoria questo lo si dovrebbe fare con @CollectionTypeArg e @MapTypeArg ma qui casca l'asino. Il mio ambiente non vede le classi per queste annotation... viene questo errore
"unable to find class for annotation"
Ho chiesto aiuto nella mailing list di Nabble Grails User
Vediamo se ottengo aiuto.

Edit
Pausa pranzo finita e per ora nessun aiuto. Ho cercato di arrangiarmi e qualcosa, forse, ho risolto. Smattendo a destra e a manca no trovato dove risiede la classe delle annotazioni del plug in di gwt... in pratica nella directory del porgetto, sotto plugin in, vi è la directory in cui vi sono due jar. Uno di questi è grails-gwt-util.jar
Ho importato questa libreria da IDEA, andando in Setting -> Project Setting -> Library -> Attach Classes -> e ho selezionato il jar di cui sopra.
Poi nel file in cui voglio usare le annotazioni ho importato il riferimento alle annotazioni con
import org.codehaus.groovy.grails.plugins.gwt.annotation.CollectionTypeArg
Non so se è il metodo corretto, nè perchè abbia dovuto farlo (presupponevo che il plugin di GWT almeno importasse le jar necessarie al suo funzionamento), ma sembra funzionare.

Si passa ad Intellij Idea

2008-05-02T16:39:00.005+02:00

I problemi che ho esposto in questo post Lo Saffolding non funziona ho poi scoperto non dipendono dalla mia ignoranza in materia grails o java... ma dal plugin di eclipse per grails che funziona male... e corrompe i file e l'ambiente.

Quindi ho installato, per il momento la trial version, di Intellij Idea, (altro IDE per Java) che sembra avere un integrazione con grails molto molto migliore.

Installato intellij Idea, ho installato i plug in per grails e groovy (che si trovano praticamente comunque già elencati in IDEA) e di fatto ho tutto pronto per lavorare.
Da IDEA posso creare il progetto grails direttamente dall'IDE, senza quindi usare la riga di comando come ho fatto sino ad ora.

Abbiamo poi creato un repository di subversion... e qui magari creerò un post apposito per questo fantastico tools.

Ho ripreso poi, reiniziandolo da capo, il tutorial del libro Getting Started With Grails, ovviamente apportando le modifiche dovute al cambiamento di versione con grails, che mano a mano segnalo nel post apposito.

Ho usato, invece di MYSQL, sempre il database in Java che ha nativamente grails con se, con la differenza che invece di usare la memoria ram, uso file su disco... questo lo si ottiene semplicemente cambiando l'url di memorizzazione nel file DataSource.groovy da
url = "jdbc:hsqldb:mem:devDB"
a
url = "jdbc:hsqldb:file:devDB"

Una delle cose che attualmente pare non sia possibile fare direttamente da IDE e il comando grails generate-all per ripetere la compilazione dei controllers e per effettuare nuovamente lo scaffolding... questo attualmente lo sto eseguendo ancora da riga di comando

Lo scaffolding non funziona

2008-04-30T17:35:00.005+02:00

Grails sembra fare praticamente tutto, se si rispettano le varie convenzioni, in pratica si riescono a generare un sacco di file preimpostati... lo scaffolding dovrebbe, per esempio, generare delle pagine web per inserire/aggiornare le classi del dominio.
Come suggerisce Getting Started with Grails, ho isntallato mysql e la libreria per agganciarlo a java, e ho specificato nelal configurazione dell'applicazione racetrack di non usare il database "in memoria" ma mysql.
Qui arrivano i primi problemi... il libro è stato scritto per la versione di grails 0.3.9 mentre ora siamo alla 1.X
Quindi ho dovuto "aggiornare" il codice, il libro infatti dice di modificare il file DevelopmentDataSource in questo modo

class DevelopmentDataSource {
boolean pooling = true
String dbCreate = "update"
String url = "jdbc:mysql://localhost/racetrack_dev"
String driverClassName = "com.mysql.jdbc.Driver"
  String username = "jason"
  String password = ""
}

ma questo file non esiste... però all'interno della directory conf vi è il file DataSource.groovy che sembrerebbe integrare i vari ambienti, cioè sviluppo, produzione, test
ho modificato questo file così (seguendo un po' la logica e un po' quello che c'è scritto sul sito di groovy nella sezione getting started)

environments {
development {
  dataSource {
    dbCreate = "create-drop" // one of 'create', 'create-drop','update'
    //url = "jdbc:hsqldb:mem:devDB"
    //aggiunto qui sotto da gabriele, e quella sopra commentata
    String url = "jdbc:mysql://localhost/racetrack_dev"
    String driverClassName = "com.mysql.jdbc.Driver"
    String username = "gabry"
    String password = ""
  }
}
test {
  dataSource {
    dbCreate = "update"
    url = "jdbc:hsqldb:mem:testDb"
  }
}
production {
  dataSource {
    dbCreate = "update"
    url = "jdbc:hsqldb:file:prodDb;shutdown=true"
  }
}
}

Fatto questo però, i problemi non finiscono. Infatti, così come sono messe le cose, dopo aver creato i controller con la riga di comando
grails create-controllers
sia per Race che per Registration (e sembra funzionare tutto), sostituendo dei due controller la riga
def index = { }
con la riga
def scaffold = Race
(o Registration per la classe RegistrationController), facendo partire
grails run-app
dovrebbe automaticamente crearmi le pagine per la gestione delle classi di dominio... ma puntato il browser su http://localhost:8080/racetrack vedo sì i link ai due controller, ma invece di mostrarmi la paginetta con le classi... mi mostra un noioso errore che non capisco come risolvere (incollato in fondo al topic).
Ho comunque chiesto aiuto nella community di Napple
Error with "Getting Started with Grails" sample: scaffold

Aggiornamento di martedì 2 Maggio
Ho scoperto che non sono l'unico ad avere questo problema, sempre nella mailing list di Nabble, ho trovato questo
Grails Scaffold Issues

Inoltre ho trovato una pagina del sito dell'autore di "Getting Started With Grails", Jason Rudolph, in cui sono state messe alcuni aggiornamenti al codice del libro, dovuti ai cambiamenti che mano a mano sono stati introdotti dalle varie versioni di Grails
http://jasonrudolph.com/gswg_faq.html

Grails Runtime Exception
Error Details
Message:
Caused by:
Class: Unknown
At Line: [-1]
Code Snippet:
Stack Trace

java.lang.NullPointerException

at org.codehaus.groovy.grails.scaffolding.TemplateGeneratingResponseHandler.handleResponse(TemplateGeneratingResponseHandler.java:104)

at org.codehaus.groovy.grails.scaffolding.DefaultGrailsScaffolder$ListAction.call(DefaultGrailsScaffolder.java:113)

at groovy.lang.Closure.call(Closure.java:287)

at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleAction(SimpleGrailsControllerHelper.java:503)

at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.executeAction(SimpleGrailsControllerHelper.java:394)

at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleURI(SimpleGrailsControllerHelper.java:233)

at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsControllerHelper.handleURI(SimpleGrailsControllerHelper.java:154)

at org.codehaus.groovy.grails.web.servlet.mvc.SimpleGrailsController.handleRequest(SimpleGrailsController.java:88)

at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)

at org.codehaus.groovy.grails.web.servlet.GrailsDispatcherServlet.doDispatch(GrailsDispatcherServlet.java:251)

at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)

at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:476)

at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:431)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367)

at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)

at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)

at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)

at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:268)

at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126)

at org.codehaus.groovy.grails.web.util.WebUtils.forwardRequestForUrlMappingInfo(WebUtils.java:198)

at org.codehaus.groovy.grails.web.util.WebUtils.forwardRequestForUrlMappingInfo(WebUtils.java:185)

at org.codehaus.groovy.grails.web.mapping.filter.UrlMappingsFilter.doFilterInternal(UrlMappingsFilter.java:117)

at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)

at org.codehaus.groovy.grails.web.sitemesh.GrailsPageFilter.parsePage(GrailsPageFilter.java:119)

at org.codehaus.groovy.grails.web.sitemesh.GrailsPageFilter.doFilter(GrailsPageFilter.java:82)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)

at org.codehaus.groovy.grails.web.servlet.filter.GrailsReloadServletFilter.doFilterInternal(GrailsReloadServletFilter.java:142)

at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)

at org.codehaus.groovy.grails.web.servlet.mvc.GrailsWebRequestFilter.doFilterInternal(GrailsWebRequestFilter.java:68)

at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)

at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)

at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)

at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:183)

at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:138)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)

at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)

at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)

at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

at org.mortbay.jetty.Server.handle(Server.java:295)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503)

at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:827)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:511)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379)

at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:361)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

Getting Started with Grails

2008-04-29T15:54:00.011+02:00

Dopo essermi ben ben infarinato con Groovy, è ora di passare a Grails, e quindi, dopo aver proceduto all'installazione e alla configurazione del framework, parto con lo "studiare" qualche libro si questo framework. Speriamo che alla fine di queste letture mi convinca (anzi, ci convinciamo) che sia proprio il prodotto che fa per noi.

Parto con la lettura di un libro trovato online, scaricabile anche gratuitamente sul sito dedicato al minibook: http://www.infoq.com/minibooks/grails oppure acquistabile online sul famoso servizio di POD (Printing On Demand): lulu.com (http://www.lulu.com/content/618462)

Come sempre, userò questo post per prendere appunti, ove necessario, su questo libro.

Sebbene Grails abbia un database embedded, validissimo per i primi esempi "al volo", il libro consiglia, per un qualcosa di più duraturo, un database come mysql, sebbene grails sia compatibile con molti altri, tra cui, per esempio, oracle.
Procedo quindi all'installazione di MySql 5.0 (per rendermi le cose semplici scarico l'autoinstallante, scegliendo l'installazione completa, lasciando le opzioni standard, compreso l'installare il servzio di windows per il server mysql, sulla porta 3306).

All'interno della definizione del dominio (cioè, in pratica, la definizione delle classi che definiscono di fatto il progetto) del progetto di esempio Racetrack, si definisce la classe Race. All'interno della stessa, nell'elenco dei fields, si ha questa
static hasMany = [registrations:Registration]
che permette di specificare la relazione uno a molti che intercorre tra Race e Registration. Quella riga di codice, infatti, dice a Grails che la classe Race avrà la proprietà registrations che memorizzerà una collezione di oggetti Registration. Non serve poi specificare di nuovo l'esistenza del field registrations, perchè è implicita nella riga sopracitata (Grails segue la logica del DRY - Don't Repeat Yourself).
La definizione delle relazioni ha diverse configurazioni, specificate dal GORM (Grails Object Relational Mapping), tutte reperibili qui: http://grails.org/GORM+-+Defining+relationships
Grails considera tutti le propietà (fields) di una classe come obbligatori, cioè per ogni classe devono essere espressi. Se si vuole specificare che uno dei campi non è obbligatorio, va aggiunta nelle constrains l'opzione nullable=true per ogni campo che si vuole specificare come facoltativo
Sempre seguendo l'esempio di prima, se nella relazione tra due classi, come definita prima, una a molti tra Race e Registration (cioè una corsa a zero o più registrazioni ad essa associata) possiamo aggiungere il concetto che una Registration non esiste se non correlata ad una Race. Quindi nella classe Registration aggiungiamo questa riga di codice
static belongsTo = Race
Cioè creiamo la proprietà belongsTo che specifica appunto che l'istanza della classe Registration esiste solo se associata ad un'istanza della classe Race, e se cancelliamo la Race, si cancellano tutte le Registration ad essa associate.
Secondo la logica del Convention Over Configuration, non serve specificare che le due classi specificate prima sono classi da "memorizzare", perché per convenzione le classi del dominio, come quelle di cui sopra, realizzate nella directory Domain, hanno bisogno della persistenza, e Grails quindi la gestirà in maniera automatica (di default, tramite Hibernate).
Il concetto del flash message è stato introdotto per permettere il "passaggio di parametri" tra le pagine. Infatti, per memorizzare messaggi di errore/avviso, e per passarseli tra le pagine, non possiamo usare variabili normali di una classe, perchè scomparirebbero all'aggiornamento della pagina (a meno di memorizzarle fisicamente da qualche parte). Usando invece questa variabile automaticamente creata da grails, possiamo passare tra le pagine questi messaggi: flash.message = "bla bla".
Ciò che viene memorizzato nella variabile flash è disponibile durante la richiesta nella quale viene memorizzata e la successiva, quindi anche, per esempio, dopo un redirect della pagina.

Cambiamenti da fare al codice del tutorial dovuti ad errori di stampa del libro o necessari per le nuove vesioni di Grails (il libro è stato scritto per grails antecedente lo 0.4 e io attualmente sto usando grails 1.0.x)

Pagina 13 (25 sul pdf)
La proprietà optional non esiste più da grails 1.0, ora, per dichiarare opzionale un campo, va aggiunta la propietà nullable=true nelle constraints per quel dato campo.
Quindi la riga
static optionals = ["postalAddress", "gender"]
non va scritta, e si aggiunge invece una constraints nella classe
static constraints = { postalAddress(nullable:true) }
ricordandosi ovviamente di mantenere questa constraints anche successivamente
Pagina 21 (33 sul pdf)
Il file DevelopmentDataSource non esiste più
Le configurazioni vanno tutte fatte nel file DataSource.groovy
Oltretutto io ho deciso di non usare, almeno per ora, mysql, ma di usare HSQLDB, già integrato con grails... l'unica modifica che faccio al file è quella di non memorizzare in memoria principale il file, ma di memorizzarlo a disco.
Quindi le configurazioni per il development che si vogliono introdurre vanno comunque fatte nel file DataSource.groovy all'interno di queste righe di codice
[...]
environments {
development {
dataSource {
//dbCreate = "create-drop" // one of 'create', 'create-drop','update'
dbCreate = "update"
url = "jdbc:hsqldb:file:devDB"
}
}
[...]
Pagina 25 (37 sul pdf), pagina 27 (39 sul pdf)
La proprietà maxLength non esiste più, va sostituita da maxSize, così, per esempio la riga
city(maxLength:30,blank:false)
diventa
city(maxSize:30,blank:false)
Pagina 35 (47 sul pdf)
Il codice della pagina gjp è proposta è diverso, in realtà qui non c'è nulla da modificare poichè la pagina gsp è stata creata automaticamente dal framework, quindi già aggiornata al codice necessario per il funzionamento.
Pagina 36 (48 sul pdf)
Il codice del controller a cui si fa riferimento è diverso, in realtà qui non c'è nulla da modificare poichè il controller è stata creato automaticamente dal framework, quindi già aggiornata al codice necessario per il funzionamento, con il comando "generate-all".
Pagina 40 (52 sul pdf)
Il messaggio a cui si fa riferimento, default.invalid.max.length.message, in realtà è default.invalid.max.size.message, dato che, come spiegato prima, il maxLength e minLength sono sostituiti da maxSize e minSize.
Pagina 41 (53 sul pdf)
Non serve più riavviare il server ad ogni cambiamento, grails si accorge da solo e basta salvare le modifiche, e se si ritorna sulla pagina web, riaggiornandola, le si ritrovano subito.
Pagina 41 (53 sul pdf)
In realtà non servirebbe aggiungere questo segnale di avvertimento, perchè le nuove versioni di grails lo aggiungono in maniera automatica, sempre tramite un javascript onclick
Pagine 43-45 (55-57 sul pdf)
In realtà anche qui pare non sia necessario aggiungere il flash.massage ad ogni azione, perchè già create in automatico dalla nuove versioni di Grails
Pagina 46 (58 sul pdf)
Come indicato prima la pagina gsp è diversa, ma il codice da rimuovere è facilmente identificabile. Però, oltre rimuovere la colonna id effettivamente inutile, va conservato il link per leggere i dettagli della race. Questo link è proprio conservato nell'id, quindi cancelliamo pure la riga dell'id, ma modifichiamo anche quella del nome in modo da conservare questo link
Cancelliamo quindi:
${race.id?.encodeAsHTML()}
E modifichiamo la riga sotto da
${race.name?.encodeAsHTML()}
a
${race.name?.encodeAsHTML()}
pagina 102 -103 (114-115 sul pdf)
Il file di configurazione di log4j, log4j.production.properties, non si trova più in racetrack/web-app/WEB-INF. Tutte le configurazioni di log4j vanno inserite nel file Config.groovy che si trova in /grails-app/conf. Inoltre le modifiche da apportare sono diverse da quelle indicate nel libro.
La parte dedicata a log4j del mio file Config.groovy è così diventata:
log4j { appender.stdout = "org.apache.log4j.ConsoleAppender" appender.'stdout.layout'="org.apache.log4j.PatternLayout" appender.'stdout.layout.ConversionPattern'='[%r] %c{2} %m%n' appender.errors = "org.apache.log4j.FileAppender" appender.'errors.layout'="org.apache.log4j.PatternLayout" appender.'errors.layout.ConversionPattern'='[%r] %c{2} %m%n' appender.'errors.File'="stacktrace.log" rootLogger="error,stdout" appender.access="org.apache.log4j.FileAppender" appender.'access.file'="access.log" appender.'access.layout'="org.apache.log4j.PatternLayout" appender.'access.layout.ConversionPattern'='%d %p %x [%c] %m%n' logger { //grails="error" StackTrace="error,errors" grails.'app.controller.UserController'="warn,access" org { codehaus.groovy.grails.web.servlet="error" // controllers codehaus.groovy.grails.web.pages="error" // GSP codehaus.groovy.grails.web.sitemesh="error" // layouts codehaus.groovy.grails."web.mapping.filter"="error" // URL mapping codehaus.groovy.grails."web.mapping"="error" // URL mapping codehaus.groovy.grails.commons="info" // core / classloading codehaus.groovy.grails.plugins="error" // plugins codehaus.groovy.grails.orm.hibernate="error" // hibernate integration springframework="off" hibernate="off" } } additivity.StackTrace=false additivity.grails.app.controller.UserController=false }

Groovy Programming: An Introduction for Java Developers

2008-04-21T09:13:00.012+02:00

Mi sono procurato questo libro, che viene pubblicizzato anche sul sito ufficiale di groovy. In questo post metterò via via i principali concetti, da tenersi bene a mente, che troverò nel libro. I codici presenti nel libro possono essere recuperati nella pagina web predisposta dall'autore.

Groovy è un linguaggio di scripting, nativamente compatibile con Java e le sue API (dato che sfruttano la stessa JVM, Java Virtual Machine). Può essere usato come collante per applicazioni create con Java, oppure il codice può essere "mischiato" con codice Java senza grossi problemi.
Linguaggi di scripting sono in particolare adeguati per le situazioni in cui bisogna integrare applicazioni già esistenti, manipolare una vasta varietà di entità dinamiche, applicazioni con interfaccia grafica, sono particolarmente adeguati per applicazioni medio-piccole.
I linguaggi come Java sono fortemente tipizzati, per garantire al sicurezza del codice e epr rende agevola la manutenzione di grosse applicazioni. Però così si rende il linguaggio poco adeguato per l'integrazione di componenti differenti, perchè spesso non si sa a priori il tipo di dati da associare ad una variabile, in questo vengono in soccorso i linguaggi di scrripting che spesso sono debolmente tipizzati, appunto come groovy. L'altro lato della medaglia è che con un linguaggio poco tipizzato codice che non solleva errori in compile time potrebbe sollevare eccezzioni, per problemi di tipo, a run time. Questo rende obbligatorio una intensa attività di test per questo tipo di applicazioni.
Tutto in groovy è un oggetto, quindi ogni variabili è un istanza di una certa classe.
Seguono la regola di cui sopra anche i numeri, quindi per esempio, per un dato integer, per esempio il valore 123, possiamo chiamare, per sapere il successivo, il metodo "next" delal classe integer: 123.next() ottenendo quindi 124. Oppure per sommare due numeri possiamo chiamare il metodo +, passando come parametro il secondo numero, quindi per esempio 123.+(56) oppure il metodo plus, 123.plus(56); fortunatamente groovy prevede l'overloading degli operatori, e quindi possiamo efefttuare la somma nella classica forma 123 + 56
Da notare come la divisione di due integer risulti SEMPRE in un floating point.
Da sottolineare come l'operazione modulo (mod oppure %) può essere chiamata solo su due integer
Sebbene non si debba definire il tipo di una variabile, al variabile stessa deve essere definita tramite la keyword def, in rpatica la prima volta che si usa una variabile bisogna dichiararla così
def age
oppure facendo subito un assegnamento
def age = 25
Le stringe si possono specificare con apice singoli ('), apici doppi (") o addirittura triplici apici - cioè tre volte apici doppi - ("""); con apici tripli si possono specificare stringe multiriga. Con gli apici singoli di specificano stringhe letterali, con le altre due interpretate, cioè ogni espressione in questa forma ${expression} viene interpretata e viene scritto il risultato, cioè
def age = 25 ’My age is ${age}’ // My age is ${age} “My age is ${age}” // My age is 25
La comparazione tra stringhe è fatta in maniera molto simile ai classi metodi dei linguaggi di scripting, capitolo 3.5 e 3.6 del libro.
Evidentemente groovy (o java) è un po' cambiato da quando è stato fatto il libro. Nella parte dedicata all'I/O infatti, in uno degli esempi si da questo codice
name = System.in.readLine()
ma risulta deprecato, quindi va sostituito con
name = new BufferedReader( new InputStreamReader(System.in) ).readLine()
I metodi sono definiti come le variabili con al parola riservata def, esempio
def printName(name) { println “Name (at entry): ${name}” name = ‘John’ println “Name (after assignment): ${name}” }
seguono poi le regole classiche delle funzioni in java
interessante poi l'uso delle parentesi graffe come "funzione"... in pratica possiamo chiamare un pezzo di codice con un determinato nome e poi eseguirlo un po' come se fosse una funzione, qui sotto un esempio con verifica dello scope dei parametri

def greeting = ‘Hello’
def clos = {param -> println “${greeting} ${param}”}
clos.call(‘world’)
// Now show that changes to this variable change the closure.
greeting = ‘Welcome’
clos.call(‘world’)
def demo(clo) {
def greeting = ‘Bonjour’ // does not affect closure
clo.call(‘Ken’)
}
demo(clos)

e l'outupt è:

Hello world
Welcome world
Welcome Ken
La gestione delle classi è praticamente identica a Java, quindi anche in Groovy ogni classe, per ogni fields, ha il setter preimpostato. Cioè, data una classe con un campo chiamato, per esempio balance, di cui creiamo un istanza chiamata, per esempio, acccount1, possiamo settare il fields sia con account1.balance=300 sia con account.setBalance(300).
Molte delle cose qui non scritte sono identiche o pressoché identiche a Java.
Il corrispettivo delle JSP per java, in Groovy viene indicato come GSP e il corrispettivo delle servlet viene soprannominato Groovlet, e il funzionamento ne è stato semplificato.
Per ora non approfondisco le Groovlet, preferisco rimandare il tutto a quando mi metto a studiare Grails. Per quanto riguarda le GSP invece va sottolineato che sono un poco meno potenti delle JSP in quanto si riducono ad essere assimilate ad un template Framework. In partica si condisce una pagina html semplice con del codice groovy ( <% - %> ) per aggiungere contenuto dinamico, definito altrove (secondo la logica del MVC)

Grails, Groovy On Rails

2008-04-16T17:11:00.004+02:00

Non faccio a tempo a finire di studiare un framework, che già se ne trova un altro da analizzare... piuttosto impressionate come cosa.

Non riesco nemmeno a finire di comprendere, come si deve, enunciare che subito salta fuori Grails... un framework completo per lo sviluppo di RIC con il linguaggio Groovy, una sorta di semplificazione di Java (e totalmente compatibile con Java stesso).

Ho trovato il plug in per integrare groovy e eclipse
http://groovy.codehaus.org/Eclipse+Plugin
e sembra funzionare.
Così come l'integrazione con Eclipse del framework
http://grails.org/Eclipse+IDE+Integration
PS: ho attivato l'opzione "Disable Groovy Compiler Generating Class Files" per rendere automatiche alcune funzioni del plugin... da ricordare però che così non funziona il debugging.

Enunciate, Maven, GWT, forse Spring, qualcos'altro?

2008-04-10T14:13:00.007+02:00

Mi sto studiando un po' Enunciate, alla fine sembrerebbe interessante e potrebbe servirci per velocizzare lo sviluppo dei Web Services, evitando di scrivere tanto codice piuttosto ridondante.

Facendo il primo tutorial, anzi, il secondo, mi sono trovato di fronte ad un po' di difficoltà... si integra maven, con GWT, con enunciate, e volendo pure con spring... quindi insomma, un po' difficile per me che non conosco bene praticamente nessuna di queste tecnologie.

Comunque, spulciando un po' nei readme di enunciate (nella release ci sono anche 3 esempi) e un po' spulciando in rete, ho trovato come fare.

Dalla directory principale del sample, dal prompt dei comandi, si lancia maven

mvn -Dgwt.home=/path/to/gwt/home package

ovviamente inserendo il path dell'installazione di gwt
Questo comanda chiede a maven di compilare il progetto... nel progetto infatti c'è già un file pom.xml bello pronto.

Altrimenti si può chiedere a maven di compilate, far partire il server jetty e pubblicare il tutto, così da renderlo accessibile in locale, con questo comando

mvn -Dgwt.home=/path/to/gwt/home jetty:run-war

e puntando il browser su http://localhost:8080/petclinic/petclinic.html (petclinic è il secondo il progetto che i tutorial di enunciate prendono in considerazione) si vede il tutto all'opera

Se in più si vuole creare i file per importare il tutto in eclipse, si usa il plugin eclipse di maven, digitando sempre dalla directory root del progetto

mvn eclipse:eclipse

In alcuni casi, non ho capito bene l'agoritmo però, bisogna controllare la path in eclipse... verificando che tutte le librerie siano importate in maniera corretta

Si può inoltre evitare di scrivere, via riga di comando, il parametro -Dgwt.home (quindi per esempio richiamando il comando con "mvn jetty:run-war") inserendo nel file di configurazione enunciate.xml questo parametro

gwtHome="c:\Programmi\GWT\gwt-windows-1.4.62"

rispettando ovviamente la path della propria installazione di gwt, all'interno della dichiarazione del modulo gwt. Per esempio, nel mio petclinic, il file enunciate.xml, è così composto


<enunciate>
  <modules>
    <gwt disabled="false"
gwtHome="c:\Programmi\GWT\gwt-windows-1.4.62"
       
rpcModuleName="org.codehaus.enunciate.samples.petclinic.PetClinic">
      <app
srcdir="src/main/gwt-apps" javascriptstyle="PRETTY">
      
<module
name="org.codehaus.enunciate.samples.petclinic.app.PetClinicApp">
      </app>
    </gwt>
    <amf disabled="true">
      <app
srcdir="src/main/flex-apps" name="vets"
mainmxmlfile="src/main/flex-apps/org/codehaus/enunciate/samples/petclinic/flex/vets.mxml">
    </amf>
  </modules>
</enunciate>

Google App Engine

2008-04-10T11:52:00.004+02:00

Ieri, mentre finivo di rivedermi JSON e il supporto di GWT verso questo sistema di "scambio messaggi", mi arriva un alert da google desktop... "Google lancia una nuova iniziativa: Google App Engine"

Si tratta di un iniziativa interessante, che in poche ore ha scosso un po' il mondo degli sviluppatori... basti pensare che il video rilasciato da google di presentazione di questa tecnologia, quando l'ho visionato per la prima volta io (penso davvero poco dopo che i due blog su google più visitati, Google Blogoscoped e Google Operating System, aveva 427 Views... dopo meno di 20 minuti, ne aveva più di 30mila

In pratica google mette a disposizione, inizialmente solo ai primi 10mila sviluppatori (speriamo io sia tra questi, intanto mi sono messo in lista) spazio web (inizialmente 500 MB), banda (non poca), cicli di CPU (non pochi) eccetera, per poter mettere online le proprie applicazioni e testarle, sia in privato, sia di diffonderle al pubblico. Il tutto reso davevro semplice dall'environment che hanno sviluppato. Infatti rilasciano anche un SDK per gli sviluppatori, con una buona documentazione, per rendere di fatto subito disponibili le proprie applicazioni online, con un sacco di strumenti di analisi. Il tutto sotto l'ottima tecnologia di google, con database e sistemi scalari (maggiore traffico ha la tua applicazione, maggiore risorse ti danno).
Il tutto inizialmente solo per il linguaggio Python, ma in futuro (prossima pare) anche in altri linguaggi di programmazione.

Nel frattempo è nata una discussione tra sviluppatori, proprio all'interno di youtube, nei commenti dei video, per chiedersi come mai google abbia lanciato questo sistema con il supporto al solo linguaggio phyton
Nel video, i tecnini di google, dichiarano che è perchè buona parte dell'infrastruttura di google è proprio fatta in phyton e perchè gli inventori di questo linguaggio di programmazione, se non ho capito male, lavorano proprio, da qualche mese, in google.
La domanda che molti si sono posti, comunque, è perchè non c'è sin dall'inizio Java tra i linguaggi supportati: dopotutto google ha recentemente lanciato, con discreto successo GWT e Android, entrambi applicazioni per lo sviluppo di RIC in Java... quindi?
Alcuni sviluppatori rispondono che... Java non è il futuro, troppo pesante e "lungo" da programmare... e Phython è molto meglio.
Bho, non ho le conoscenze sufficienti per giudicare... ma è strano che google prima lanci due importanti tecnologie per Java e poi la ignori... forse non si vuole legare troppo ad un linguaggio di programmazione?

Google App Engine: http://code.google.com/appengine/

Enunciate

2008-04-08T15:37:00.005+02:00

Non faccio nemmeno a tempo di finire di approfondire (se si può dire approfondire... diciamo rivedere) le GWT-RPC, che già mi trovo di fronte ad un nuovo framework da analizzare!!!

E sì, giusto ora ho finito i capitoli sull'RPC di GWT in Action, ma stamane Francesco mi ha presentato questo framwork, ENUNCIATE (http://enunciate.codehaus.org/index.html), framework per lo sviluppo di Web Service, che ne semplifica lo sviluppo, sfruttando le tecnologie esistenti per fornire uno stumento per il build, il package, la distribuzione ecc...

Ora mi rivedo meglio l'utilizzo di GWT-JSON, poi mi studio questo frework, sia sul sito http://enunciate.codehaus.org/getting_started.html sia sul blog dell'autore di enunciate: http://weblogs.java.net/blog/stoicflame/archive/2008/01/web_service_pro_1.html

GWT-RPC

2008-04-03T10:56:00.003+02:00

Attualmente sono arrivato in una fase di stallo per lo studio di Maven: ho capito cosa è e grossomodo come funziona. Idem, grossomodo, per Spring: ho capito, grossomodo, cosa è e ho un infarinatura su come funziona.

Ora però mi sono reso conto che è inutile, o comunque troppo complicato, per me studiarmi l'integrazione tra GWT e Spring, che in effetti sembra essere una buona strada, se non so bene come si comportano le RPC in GWT.

Quindi ho deciso di ritornare sullo studio di GWT, in particolare sull'utilizzo delle sue RPC (GWT-RPC). Una volta studiate, se sarò in grado di utilizzarle in maniera decente, e potrò dire di conoscerle, forse potrò affrontare l'integrazione con Spring senza troppa difficoltà... e se voglio analizzare altri sistemi di dialogo Client-Server, per sapere che strada affrontare, è il caso che conosca bene le RPC per conoscerne vantaggi e svantaggi.

Ho trovato qualche altro tutorial in rete:

RPC To Java Tutorial
Java Version of GWT-RPC, una discussione sul gruppo gwt di google groups
Using Google Web Toolkit RPC with AsyncCreator, descrizione di un tool per la generazione automatica di codice per le chiamate asincrone

RPC To Java Tutorial
Ho provato ad usare questo tutorial. Molto semplice, con poche informazioni e non spiegato benissimo, da però alcuni accorgimenti interessanti per gli "niubbi" di Java e gwt
Ho voluto però implementarlo da zero. Non ho quindi usato il codice online, ma ho creato un progetto in Eclipse da zero e piano piano ho aggiunto il codice.
Nuovo progetto web dinamico
Ho poi aggiunto il modulo GWT (dal progetto, new -> other -> GWT Module)
Ho aggiunto poi il modulo per le rpc (in pratica crea le classi async, imple eccetera, sia per client che per server) (dal progetto, new -> other -> GWT Remote Service)
Ho aggiunto il codice del tutorial (rinominando però RPCImpl in RPCInterfaceImpl perchè mi pareva più conforme agli standard... usare il nome stesso, aggiungendo prima async e poi impl)
Ho rinominato anche il nome del modulo, ma nulla di che

però ho poi dovuto consultare il codice che veniva fornito, perchè ho dovuto aggiungere questa riga al file "nomemodulo".gwt.xml perchè la configurazione di eclipse non la crea

ancora su Maven

2008-04-01T14:01:00.004+02:00

Ho provato a fare il tutorial trovato in questa pagina, che spiega il triodo Maven-Spring-GWT (si dice triodo? vabbhe avete capito)
http://shinetech.com/pages/viewpage.action?pageId=1396
ma purtroppo non riesco a finirlo, in quanto una delle ultime parti mi da un errore strano
Non so se sia un errore di utilizzo di Spring o GWT... più probabilmente non so usare Maven
Ho creato una discussione nel gruppo di GWT-Maven
http://groups.google.com/group/gwt-maven/t/f29cc4c833d14ad9
Vediamo se otterrò rispsota
(EDIT: 2 aprile
ho ricevuto risposta, che ha risolto il problema... ma ora ottengo un altro build error... che scatole... vedremo se mi aiutano ancora)

Nel frattempo mi leggo un'altra guida su Maven... primi passi, quelli che servono a me
http://www.javajournal.it/blog/2006/11/21/primi_passi_com_maven_prima_parte_3.html
http://www.javajournal.it/blog/2006/11/24/primi_passi_com_maven_seconda_parte_3.html
http://www.javajournal.it/blog/2006/11/30/primi_passi_com_maven_terza_parte_3.html

Aggiornamento 14:43
Guida letta, facile, molto semplice... ho capito il contenuto e almeno ora ho un po' più chiare le dinamiche di maven. Ma è una guida semplice, che spiega meno di quello che mi serve per capire i tutorial maven-spring-gwt

Nel frattempo trovo qualcosa per l'integrazione di Maven ed Eclipse
http://www.jugsiracusa.it/pmwiki.php?n=KnowledgeBase.KBMavenEclipse
in realtà ho già installato un plug in per ecplise (M2Eclipse)... ma me ne installo un'altra che viene consigliata sul sito ufficiale di Maven (http://maven.apache.org/eclipse-plugin.html)

Continuo a Studiarmi Maven

Maven

2008-03-27T17:09:00.004+01:00

Già nelle scorse settimane mi era più volte capitato di leggere qualcosa su Maven... alcuni tutorial e progetti che ho analizzato lo richiedevano o facevano riferimento a questo tool, ma ho sempre evitato di "sapere cosa fosse".

Leggendo però il tutorial (anzi, vedendo la videolezione e relativi source) per l'integrazione tra GWT e Spring si è resa necessario lo studio, anche solo approssimativo, di cosa sia Maven.

Copio la definizione trovata in questa pagina:
http://www2.mokabyte.it/cms/article.run?articleId=S85-L5J-HP3-86O_7f000001_30480431_0844866c

Maven è un uno strumento "intelligente" e di alto livello per la gestione dei progetti in termini di compilazione, assemblaggio, test, deployment, e così via.

Sembrerebbe qualcosa di fin troppo evoluto per quello che sto facendo ora, anche se probabilmente diventerà interessante e utile per ciò che implementeremo. E dato che per comprendere ed utilizzare alcuni tutorial devo saperlo utilizzare, forse è il caso che me los tudi almeno superficialmente.

Attualmente sto leggendo questi articoli: Maven: best practices per il processo di build e di rilascio dei progetti in Java
Sembrano fatti bene, la prima pagina me la sono letta e più o meno capita tutta: è un introduzione a cosa sia Maven e una semplificata analisi di confronto Maven VS Ant (uno strumento di build di progetti Java)

Alcuni libri da comprare

2008-03-26T10:17:00.007+01:00

Qui un elenco di libri che dovremmo proprio acquistare. Alcuni di questi sono riuscito a recuperarli come pdf, anche se sarebbe il caso di averli stampati!

Amazon UK (normalmente la merce arriva in 10 giorni dal pagamento)
Spese di spedizione: 3,99 £ a spedizione (per libri) e 0,99 £ per libro

Effective Java: A Programming Language Guide
Pratici consigli (e codice) per programmare al meglio in Java

GWT In Action:
Sembrerebbe essere un ottimo libro per l'uso di GWT. Molti esempi e pezzi di codice da questo blog sono tratti da questo libro

GWT in Practice
Potrebbe essere un alternativa, consigliato per il modello MVC

Spring in Action
Altro libro della serie "In Action", per l'utilizzo di spting

Spring FrameWork 2.0
Potrebbe essere una valida alternativa, come libro per Springs

Java Persistence with Hibernate
Molto probabilmente Hibernate saràù il framwork che useremo per la persistenza dei dati

Amazon COM (normalmente la merce arriva in 15-20 giorni dal pagamento)
Spese di spedizione: 3,99 $ a spedizione e 3,99 $ per libro

Effective Java: A Programming Language Guide
Pratici consigli (e codice) per programmare al meglio in Java

GWT In Action:
Sembrerebbe essere un ottimo libro per l'uso di GWT. Molti esempi e pezzi di codice da questo blog sono tratti da questo libro

GWT In Practice
Potrebbe essere un alternativa, consigliato per il modello MVC

Spring in Action
Altro libro della serie "In Action", per l'utilizzo di spting

Professional Java Development with the Spring Framework
Potrebbe essere una valida alternativa, come libro per Springs

Java Persistence with Hibernate
Molto probabilmente Hibernate saràù il framwork che useremo per la persistenza dei dati

Rilasciato un aggiornamento minore di GWT: GWT 1.4.62

2008-03-18T17:10:00.003+01:00

Mentre sto un po' impazzendo per studiarmi almeno un pochino (giusto un infarinatura, prima di buttarmici seriamente) riguardo spring e la sua integrazione con gwt, leggo che è stata rilasciata ieri un aggiornamento, minore, a GWT.
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/bd5cbb7a0d5b60aa
sembrano solo bugfix... ma dato che uno di questi sembra importante per problemi connessi a Firefox3, e dato che il rilascio di FF3 sembra imminente, forse è il caso di aggiornarsi...

Chissà quando verrà rilasciato GWT 1.5
In questo caso l'aggiornamento sarà decisamente più interessante, no?

Spring

2008-03-13T10:07:00.009+01:00

Dopo aver analizzato un po' di licenze sui prodotti opensource, per verificare se in effetti potremo utilizzarli nel nostro lavoro, penso sia il caso di dedicare un po' di tempo allo studio di Spring, un framework osannato da molti per lo sviluppo di applicazioni professionali in Java, soprattutto in ambito web.

Questi gli articoli, presentazioni, tutorial, documentazione che sto analizzando

Spring Framework Reviewed, by Howardism.org
Introduction to The Spring Framwork, by Rod Johnson, principale sviluppatore di Spring
Spring MVC, Inversione del Controllo e Dependency Injection, prima parte, seconda parte
Usare Spring a pieno regime con WebFlow
Developing a Spring Framework MVC application step-by-step

Altro su Spring:

https://springmodules.dev.java.net/ progetto parallelo a spring, con alcuni moduli da poter integrare a Spring, tra cui un Validator che support validazioni dichiarative (non so benissimo cosa significhi) per validare i dati di un forum (modulo: springmodules-validator.jar). Pagina 517 di "Spring in Action".
The Three Amigos : Maven, Spring and GWT sempre sull'integrazioe gwt psrings (vedi sotto) ma qui spiega anche maven2 (che non ho capito bene come si usa... e nemmeno bene cosa sia esattamente)

E alcuni tutorial e articoli sull'integrazione Spring e GWT

GWT-Spring Integration Demystified
Google Web Toolkit. Integration with Spring framework, raccolta di proposte
Using the GWTHandler, che usa le librerie GWT Server Library di cui abbiamo già parlato
Three parts tutorial : Spring, Hibernate and GWT
GWT-RPC with Spring 2.x
Building web-based 'fat clients' using GWT sembrerebbe un interessante videolezione (link diretto) su come integrare il back end di una grossa applicazione costruita in spring con gwt (qui codici sorgenti e slides)
Non invasive GWT and Spring integration

Licenze

2008-03-12T17:07:00.009+01:00

Analizzando e considerando la possibilità di utilizzare vari framework, librerie ed altro, rilasciati sotto vari tipi di licenze, è il caso di analizzarne una ad una, soprattutto per verificare se siano compatibili co il rilascio di lavoro commerciale e proprietario (come ovviamente la fdl è intenzionata a fare)

GNU General Public License (GPLv3)
Non permette di usare software rilasciato con GPLv3 in prodotti commerciali, poichè comunque bisogna rilasciare tutto il progetto sotto GPLv3
GNU Affero General Public License
Deriva dalla GPL, ma si intende per software usato in un network. Quindi non utilizzabile in software commerciale.
Sono rilasciati sotto AGPL
- Itext (dalla versione 5.X)
Apache Software License Version 2.0 (ASL 2.0)
E' una licenza poco restrittiva. Permette l'uso del materiale rilasciato sotto di essa per lavori commerciali e proprietari. ???Non molto dissimile dalla BSD???
E' compatibile con la licenza GPLv3 (ma non con GPL versione 2), quindi materiale rilasciato con ASL può essere incluso in materiale rilasciato sotto la GPLv3
Si può ridistribuire materiale che contiene sofwtare rilasciato sotto ASL in ogni forma e mezzo a patto di
- Allegare copia della licenza ASL 2.0
- se si è modificato qualche file rilasciato sotto ASL bisogna specificarlo nel file stesso prima di redistribuirlo
Sono rilasciati sotto ASL (e quindi inseribili/utilizzabili senza problemi nel nostro lavoro):
Mozilla Public License (MPL)
Licenza per software libero, senza un forte permesso d'autore (poco restrittivo). E' però incompatibile con la GNU GPL.
Contiene però una clausola che permette agli sviluppatori iniziali di associare al prodotto una nuova licenza. Generalmente quindi utilizzabile anche per prodotti commerciali e proprietari

Sono rilasciati sotto MPL i seguenti prodotti
- Echo2 (usabile e ridistribile con prodotti commerciali e propietari)
GNU Lesser General Public Licence (LGPL), v 3.0.
Versione meno restrittiva della Gnu. Permette l'utilizzo di librerie/codice rilasciato in progetti commerciali e proprietari, a patto di indicarne la presenza, l'origine e la licenza stessa. Se nel progetto commerciale si usano modifiche a questo codice, si è obbligati, assieme al codice stesso, rilasciare le modifiche come codice open, indicando l'origine primaria e rilasciando (queste modifiche) con licenza LGPL. In sostenza, se useremo nel nostro progetto codice LGPL, dovremo indicarne la presenza... se dovremo modificare codice LGPL dovremo inserire nelle realease (anche commerciali e proprietarie) il sorgente di questo codice proprietario che dovremo rilasciare sotto LGPL. Se il codice LGPL viene usato "as is", non si è obbligati ad includerlo, basta farne riferimento nella licenza del programma proprietario rilasciato. Recentemente (2011) ho trovato un link che spiega un'ulteriore obbligo previsto dalla LGPL: bisogna permettere a chi usa il proprio software che comprende una libreria LGPL di poter usare un'eventuale nuova versione di tale libreria (http://www.gamedev.net/topic/80919-using-gpl-libraries-with-commercial-software/) (Non ho indagato bene su questo aspetto)

Sono rilasciati sotto LGPL v 3.0
- GWT-Ext
- MyGWT
- EXT JS, le librerie che servono per il funzionamento di GWT-EXT e MyGWT. In realtà esistono altri tipi di licenza per queste librerie, come quella commerciale.
- Itext, sino alla versione 4.2 (poi passa alla AGPL)
- Flyng-Saucer, che comprende IText 2.0.8 (quindi ancora LGPL)
Licenza BSD
Licenza molto libera, esistente in diverse versione, che ne aumentano, o restingono, di poco la libertà.
Le licenze BSD riflettono l'idea più ampia possibile del dono liberale: chiunque può fare ciò che meglio crede del programma rilasciato ed acquisito con l'unico dovere di citare l'autore (l'università di Berkeley); questo significa anche che chiunque può sviluppare in forma chiusa con una licenza proprietaria un programma BSD modificato, magari anche impedendo ai propri acquirenti di modificarlo e ridistribuirlo a loro volta.
In realtà esiste anche una versione, chiamata "a tre clausole", che toglie la clausola della obbligatoria pubblicità verso l'università di Berkeley.

Sono rilasciati sotto licenze di tipo BSD
- Gwt-Ext-Ux, qualche estensione alle librerie Gwt-Ext

Spring / Hibernate e altri framework

2008-03-12T12:11:00.003+01:00

Studiando per la rete il pattern MVC, sono incappato in alcuni framework che inizialmente avevamo considerato per lo sviluppo del nostro frameweork, tra i quali, Spring (http://www.springframework.org/), Hibernate (http://www.hibernate.org/) e altri framework che possono aiutarci nello sviluppo di ciò che vogliamo realizzare

Spring
E' un framework a strati per la realizzazione di applicazioni Java/J2EE. Ha al suo interno diversi "moduli", tra cui una sorta di implementazione del pattern MVC e permette la facile integrazione di altri framework, come Hibernate.
Un interessante articolo: Mokabyte Sprin e successivi
Hibernate
è una piattaforma middleware open source per lo sviluppo di applicazioni Java che fornisce un servizio di Object-relational mapping (ORM), ovvero che gestisce la rappresentazione e il mantenimento su database relazionale di un sistema di oggetti Java.
GWT Server Library
Una libreria che permette la facile integrazione tra GWT e Spring

MyGWT

2008-03-12T10:54:00.002+01:00

Mygwt è un altra libreria/framework sviluppata sulla libreria ext (così come Gwt-Ext). Non sembra introdurre elementi grafici più interessanti di altre librerie (Gwt-Ext sembra appunto molto più completa ed interessante da questo punto di vista), ma implementa una forma embrionale di MVC (pattern Model View Controller) e quindi è interessante da analizzare, anche solo per vedere un implementazione di questo pattern.

MyGwt lo si scarica dal sito ufficiale, http://mygwt.net/, l'installazione è semplice ed immediata: basta scompattare il file dalla pagina download del sito in una cartella del proprio fyle system, per poi referenziarla nei progetti che si intende utilizzare.
Anche la configurazione di eclipse per l'utilizzo di MyGwt è semplice, e basta seguire i pochi passi proposti nel wiki della libreria (http://mygwt.net/learn/index.php?title=Configuring_Eclipse).
Per prima cosa è meglio creare un progetto nuovo, come Web -> Dinamic Web -> selezionando poi "dionamic web project using GWT" in "configuration".
Si deve poi importare tutto il framework GWT... per fare ciò possiamo aiutarci come al solito dal plugin GWT-Tooling. Basta quindi cliccare con il destro sul progetto appena creato, selezionare new -> other -> GWT -> GWT-Module
Poi In poche parole basta aggiungere il jar come libreria esterna (tasto destro sul progetto eclipse -> Build Path (oppure proprties) -> Configure Build path (oppure Java Build Path) -> Libraries -> Add External Jar -> selezionare il mygwt.jar cercandolo nel proprio file system dove si è scompattato prima il file scaricato dal sito. Bisogna poi fare attenzione che il mygwt.jar rimanga sempre più in altro, nella finestra "order and export" (sempre nella Java Bild Path), rispetto alla libreria normale di GWT. Questo perchè, se non ho capito male, MyGwt riscrive alcune classi di GWT.
Bisogna poi inserire nel file xml del modulo gwt questa riga

<inherits name="net.mygwt.ui.MyGWT" />

e inserire gli stili css nel file htm

<link rel="stylesheet" type="text/css" href="mygwt-all.css" />
<link rel="stylesheet" type="text/css" href="mygwt-all-gray.css" />

Model View Controller e altri design pattern

2008-03-10T16:13:00.003+01:00

Sto analizzando ora, per la realizzazione del framwork da sviluppare, dei design pattern che possano essere adeguati.

Uno dei più importanti e utili, probabilmente, è il MVC (Model View Controller), la divisione tra gestione delle view (visioni, rappresentazioni all'utente), il controller (che intercetta le interazioni dell'utente, e chiede al model aggiornamenti di stato) e il model (business logic e data management)

MVC, esempi
http://java.sun.com/blueprints/patterns/MVC.html
http://java.sun.com/blueprints/patterns/MVC-detailed.html
Front Controller
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
Esempio del Java Pet Store Demo, con MVC e Front Controller

Altro design pattern, che trovo consigliato nei vari tutorial di spring + gwt e simili, è una variante (credo) al MVC, cioè Hierarchical Model-View-Controller. Sembrerebbe un sistema più stratificato e "separatista" del MVC.
Alcuni tutorial:

GWT, JSTM e JSTM4GWT

2008-03-06T17:40:00.002+01:00

In questa settimana sono riuscito nell'impresa di far dialogare GWT con JSTM4GWT (la versione per GWT di XSTM) e JSTM (la versione Java di XSTM.
Ho realizzato (e sto ampliando) un piccolo esempio per verificare se riesco ad ottenere da XSTM ciò che voglio.

L'idea di base è cercare di creare una form logica sul server, via Java, replicarla in GWT sul client, sia in via logica che come UI fisica sul browser e far comunicare il tutto in maniera semplice senza PRC.

Lo strato che fa la maggior parte del lavoro è proprio, ovviamente XSMT... si realizza la maschera (form) logica sul server via java... sul serve non serve una rappresentazione visiva (ma sarebbe immediato implementarla). Si condivide con il client questa maschera logica (attraverso appunto il dialogo JSTM e JSTM4GWT) e la si replica poi in GWT per realizzarla fisicamente sul browser, e viceversa

In questo modo ogni interazione sulla maschera fatta da un utente sul client viene replicata sulla maschera logica sul server, che può agire autonomamente in base ad ascoltatori che intercettano le variazioni della maschera logica, aggiorna la maschera logica che poi verrà replicata immediatamente sul client

Per ora, nell'esempio che ho fatto io, si replicano immediatamente sul client le modifiche fatte sulla maschera logica del server... ma non viceversa (bisogna sempre premere il tasto "commit"... questo anche per una scelta architetturale di JSTM), anche se il comportamento è non difficilmente modificabile (già parzialmente testato)

Il server riesce a capire se le modifiche sulla maschera logica sono avvenute internamente al server o dal client e quindi può agire diversamente di conseguenza.

A quanto pare sono riuscito ad ottenere ciò che volevamo... devo verificare alcuni dettagli ma forse siamo arrivati ad un livello di astrazione/interazione vicino a quello che vorremmo ottenere... anche perchè la realizzazione grafica del client può essere abbastanza facilmente svincolata da GWT e realizzata in uno dei qualsiasi 3 linguaggi supportati da XSTM: Java, .NET e appunto Java/GWT

Image Tooltip

2008-02-27T15:53:00.006+01:00

Ho finalmente finito, più o meno, il primo applicativo "reale" con gwt.
Come anticipato ho creato un modulo gwt che per ogni immagine in una pagina web (con una determinata classe) crei un "tooltip" con l'immagine a grandezza "naturale" che compaia quando si passa con il mouse sopra l'immagine stessa.
In pratica il modulo parserizza tutta la pagina per cercare immagini con la data classe. Per ognuna di queste immagini crea un widget (una window di gwt-ext) con la stessa grandezza dell'immagine, contenente l'immagine stessa. A questo widgets viene aggiuntpo un ascoltatore per il mouse, e in caso di mouse hover si attiva (con una simpatica animazione fornita da gwt-ext), attiva una nuova window che carica la versione ad alta risoluzione dell'immagine (sul server ci devono essere quindi due immagini, l'immagine originale e una miniatura con lo stesso nome + "_th").
Funziona tutto ok... meno bene la gestione del ridimensionamento della finestra del browser... i widgets della miniatura si spostano correttamente, le dimensioni del tooltip vengono correttamente calcolate (perchè in base al viewport del browser riduco la grandezza dell'immagine originale), ma la posizione e la grandezza del gagtes "tooltip" contenitore fanno un po' quello che vogliono... ma solo in caso di ridimensionamento.

Ora comunque, visto che riesco a creare qualcosina, anche se semplice, con gwt e gwt-ext, sposto l'attenzione su XSTM

codice per IMGTOOLTIP, Versione.... diciamo 0.5


package mie.prove.client;

import java.util.ArrayList;
import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.ui.Widget;
import com.google.gwt.user.client.ui.Image;
import com.google.gwt.user.client.Window;
import com.google.gwt.user.client.ui.MouseListenerAdapter;
import com.google.gwt.user.client.WindowResizeListener;
import com.gwtext.client.widgets.layout.FitLayout;
import com.gwtext.client.widgets.Component;

public class GwtImageTooltip implements EntryPoint {

 ArrayList immagineTHWList  = new ArrayList();
 ArrayList imgList = new ArrayList();
 ArrayList TTwindowList = new ArrayList();
 ArrayList immagineToolTipList = new ArrayList();
 ArrayList misureOriginaliImmaginiTT = new ArrayList();
 int viewportW, viewportH;
 
 public void onModuleLoad() {
  viewportW = Window.getClientWidth();
  viewportH = Window.getClientHeight();
  com.google.gwt.core.client.GWT.log("il viewport ha altezza" + viewportH + " e larghezza " + viewportW,null);
  
  Element elemento = DOM.getElementById("contenuto");
  imgList = getElementsByClass(elemento, "img_tooltip");  
  int numImg = imgList.size();    
  for (int i=0; i < numImg; i++){
   com.google.gwt.core.client.GWT.log("processo il tooltip numero"+i,null);
   
   String urlImmagineTH = DOM.getElementProperty((Element)imgList.get(i), "src");
   String altImmagineTH = DOM.getElementProperty((Element)imgList.get(i), "alt");
   
   int imgY = DOM.getAbsoluteTop((Element)imgList.get(i));
   int imgX = DOM.getAbsoluteLeft((Element)imgList.get(i));
   int[] posizioneImmagine = {imgX,imgY};
   com.google.gwt.core.client.GWT.log("l'immagine"+i+" si trova in posizione "+imgX+" "+imgY,null);
   
   Image immagineTH = new Image(urlImmagineTH);
   
   final com.gwtext.client.widgets.Window immagineTHWindow = new com.gwtext.client.widgets.Window();     
   /*
   //per farlo diventare esattamente come un immagine
   immagineTHWindow.setFrame(false);
   immagineTHWindow.setHeader(false);
   immagineTHWindow.setHeaderAsText(false);
   //fine per farlo diventare esattamente come un immagine
   */
   immagineTHWindow.setLayout(new FitLayout());  
   immagineTHWindow.add(immagineTH);   
   //immagineTHWindow.anchorTo((Element)imgList.get(i), position, offsetXY)
   immagineTHWindow.setModal(false);
   immagineTHWindow.setPixelSize(immagineTH.getWidth(),immagineTH.getHeight());
   immagineTHWindow.setDraggable(false);
   immagineTHWindow.setClosable(false);
   immagineTHWindow.setResizable(false);
   immagineTHWindow.setFooter(true);
   immagineTHWindow.setTitle(altImmagineTH);  
   immagineTHWindow.setPosition(imgX,imgY);
   immagineTHWindow.show();
   
   //aggiungo la window immagineTHWindow alla lista immagineTHWList
   immagineTHWList.add(immagineTHWindow);
      
   String urlTT = urlImmagineTH.replaceAll("_th", "");
   Image immagineToolTip = new Image(urlTT);
   immagineToolTip.setVisible(false);
   immagineToolTipList.add(immagineToolTip);
   int[] misureOriginali = {immagineToolTip.getWidth(),immagineToolTip.getHeight()};
   misureOriginaliImmaginiTT.add(misureOriginali);
   
   int [] misureTTwindow = calcolaMisuraTTwindow(posizioneImmagine,immagineToolTip);
   int immagineTTW = misureTTwindow[0];
   int immagineTTH = misureTTwindow[1];
   
   immagineToolTip.setPixelSize(immagineTTW, immagineTTH);
   
   final com.gwtext.client.widgets.Window TTwindow = new com.gwtext.client.widgets.Window();  
   TTwindow.setLayout(new FitLayout()); 
   TTwindow.add(immagineToolTip); 
   TTwindow.setTitle(altImmagineTH);    
   TTwindow.setModal(false);
   TTwindow.setDraggable(false);
   TTwindow.setClosable(false);
   TTwindow.setResizable(false);
   TTwindow.setFooter(true);
   TTwindow.setAnimateTarget((Element)imgList.get(i));
   TTwindow.setPixelSize(immagineTTW, immagineTTH);
   
   posizionaTTwindow(TTwindow, posizioneImmagine);
   
   //aggiungo la window TTwindow alla lista TTwindowList
   TTwindowList.add(TTwindow);
      
   //agiungo ascoltatore eventi all'immagine per aprire tooltip
   immagineTH.addMouseListener(new MouseListenerAdapter() {
         public void onMouseEnter(Widget sender) {
          TTwindow.show();
          Component immagineToolTip = TTwindow.getComponent(0);
          immagineToolTip.setVisible(true);
         }
   });
       
   //agiungo ascoltatore eventi mouse al tooltip per chiuderlo
   immagineToolTip.addMouseListener(new MouseListenerAdapter() {
         public void onMouseLeave(Widget sender) {
          TTwindow.hide();
         }
   });       
  }  
  
  //aggiungo l'ascoltatore alla finestra per spostare le immagini in caso di resize
  Window.addWindowResizeListener(new WindowResizeListener(){
   public void onWindowResized(int x, int y){    
    aggiornaPosizioneimmaginiTHWindow(immagineTHWList); 
    viewportW = Window.getClientWidth();
    viewportH = Window.getClientHeight();
    aggiornaMisureTTwindow(TTwindowList,imgList,immagineToolTipList);
    aggiornaPosizioniTTwindows(TTwindowList,imgList);
   }
  });
 }
 
 public void aggiornaMisureTTwindow(ArrayList TTwindowList, ArrayList imgList, ArrayList immagineToolTipList){
  int numImg = TTwindowList.size();
  int [] posizioneImmagine = new int[2];
  for (int i=0; i < numImg; i++){
   com.gwtext.client.widgets.Window TTwindow = (com.gwtext.client.widgets.Window)TTwindowList.get(i);
   try{
    int imgY = DOM.getAbsoluteTop((Element)imgList.get(i));
    int imgX = DOM.getAbsoluteLeft((Element)imgList.get(i));
    posizioneImmagine[0] = imgX;
    posizioneImmagine[1] = imgY;
   }
   catch(IndexOutOfBoundsException e){
    System.err.print("IndexOutOfBoundsException: ");
    System.err.println(e.getMessage());
    com.google.gwt.core.client.GWT.log("IndexOutOfBoundsException: ",null);
    com.google.gwt.core.client.GWT.log(e.getMessage(),null);
   }
   Image immagineToolTip = (Image)immagineToolTipList.get(i);
   int[] misureOriginali = (int[])misureOriginaliImmaginiTT.get(i);
   immagineToolTip.setPixelSize(misureOriginali[0], misureOriginali[1]);
   int [] misureTTwindow = calcolaMisuraTTwindow(posizioneImmagine,immagineToolTip);
   int immagineTTW = misureTTwindow[0];
   int immagineTTH = misureTTwindow[1];
   com.google.gwt.core.client.GWT.log("misure ricalcolate: imgx="+immagineTTW+" imgy="+immagineTTH,null);   
   immagineToolTip.setPixelSize(immagineTTW, immagineTTH);
   TTwindow.setPixelSize(immagineTTW, immagineTTH);
  }
 }
 
 public int[] calcolaMisuraTTwindow(int[] posizioneImmagine, Image immagineToolTip){
  float resize = 1; //% di resize in caso l'immagine sia troppo grande
  int immagineTTH = immagineToolTip.getHeight();
  int immagineTTW = immagineToolTip.getWidth();
  String url = immagineToolTip.getUrl();

  com.google.gwt.core.client.GWT.log("L'immagine tooltip ha altezza" + immagineTTH + " e larghezza " + immagineTTW + " e url = " +url,null);
  
  //se l'immagine è più grande del viewport, devo scalarla e posizionarla centrata
  if ((immagineTTW > viewportW-10) || (immagineTTH > viewportH-10)){
   if (immagineTTW > viewportW-10){
    resize = (float)immagineTTW / ((float)viewportW-10);
   }
   else {
    resize = (float)immagineTTH/((float)viewportH-10);
   }
   float temp = (immagineTTW/resize);
   immagineTTW = Math.round(temp);
   temp = (immagineTTH/resize);
   immagineTTH = Math.round(temp);
  }
  int [] misureTTwindow = {immagineTTW,immagineTTH};
  return misureTTwindow;
 }
 
 public void aggiornaPosizioniTTwindows(ArrayList TTwindowList, ArrayList imgList){
  int numImg = TTwindowList.size();
  for (int i=0; i < numImg; i++){
   com.gwtext.client.widgets.Window TTwindow = (com.gwtext.client.widgets.Window)TTwindowList.get(i);
   int imgY = DOM.getAbsoluteTop((Element)imgList.get(i));
   int imgX = DOM.getAbsoluteLeft((Element)imgList.get(i));
   int [] posizioneImmagine = {imgX,imgY};
   posizionaTTwindow(TTwindow,posizioneImmagine);
   Component immagineToolTip = TTwindow.getComponent(0); 
   immagineToolTip.setVisible(false);
  }
 }
 
 public void posizionaTTwindow(com.gwtext.client.widgets.Window TTwindow, int[] posizioneImmagine){
  int posTTX = posizioneImmagine[0]; //posizione X del tooltip
  int posTTY = posizioneImmagine[1]; //posizione Y del tooltip
  int spostTTX = 0; //spostamento del tooltip nel caso l'immagine sia larga
  int ttwindowWidth = TTwindow.getWidth(); //larghezza tooltip
  //se l'immagine TT è troppo larga per stare nella posizione dell'immagine TH, la sposto a sinistra
  if (posTTX + ttwindowWidth > viewportW-5){
   spostTTX = posTTX + ttwindowWidth - (viewportW-5); 
  } 
  TTwindow.setPagePosition(posTTX-spostTTX,posTTY);
 }
 
 //imgList e immagineTHWList hanno gli stessi indici
 public void aggiornaPosizioneimmaginiTHWindow(ArrayList immagineTHWList){
  int numImg = immagineTHWList.size();
  for (int i=0; i < numImg; i++){
   int imgY = DOM.getAbsoluteTop((Element)imgList.get(i));
   int imgX = DOM.getAbsoluteLeft((Element)imgList.get(i));
   com.gwtext.client.widgets.Window currentWindow = (com.gwtext.client.widgets.Window)immagineTHWList.get(i);
   currentWindow.setPosition(imgX,imgY);
  }
 }

 private ArrayList getElementsByClass(Element parent, String className){
  ArrayList list = new ArrayList();
  Element current = DOM.getFirstChild(parent);
  String classe = null;
  
  while(current != null){
   classe = DOM.getElementProperty(current, "className"); 
   if (classe!=null){
    if(classe.equals(className)){
     com.google.gwt.core.client.GWT.log("trovato un img_tooltip",null);
     list.add(current);
    }
   }
   current = DOM.getNextSibling(current);
  }
  return list;
 } 
}

Gwt-Ext

2008-02-20T09:34:00.003+01:00

Gwt-Ext (http://gwt-ext.com/) sembrerebbe una libreria ben fornita. Anche Francesco ne è rimasto positivamente colpito. Sto provando a creare una mini applicazione con gwt-ext, un tooltip per le immagini...
Vorrei che in una pagina web ci siano delle miniatura delle immagini, e passando il mouse sopra l'immagine si apra un tooltip contenente l'immagine in grandezza originale.
Userei i tooltip presenti in gwt-ext, che accettano anche del codice html.

Dal wiki di GWT-EXT: Introduction to GWT Ext 2.0
Bisogna anche scaricare la libreria Ext-Js (http://extjs.com/download)

una volta creato il progetto in eclipse, copiare queste cartelle di ext-js
```
* /adapter
* /resources
* ext-all.js
* ext-all-debug.js
* ext-core.js
* ext-core-debug.js
```
nella cartella src/com/mycompany/mypackage/public/js (ovviamente adattata ai nomi del package)
importare la libreria nel progetto: Tasto destro del mouse sul progetto, in eclipse, "build path"->"configure build path"->"libraries"->"add external jar" e si individua il jar di gwt-ext
Successivamente bisogna inserire nel file di configurazione xml "nomeprogetto.gwt.xml" queste due righe, prima dell'importazione della classe del progetto



<inherits name="'com.gwtext.GwtExt'">

</inherits>

nel file html inserire queste righe

<!-- Begin ExtJS library files -->
 <link rel="stylesheet" type="text/css" href="js/ext/resources/css/ext-all.css"/>
 <script type="text/javascript" src="js/ext/adapter/ext/ext-base.js"></script>
 <script type="text/javascript" src="js/ext/ext-all.js"></script>
<!-- End ExtJS library files -->

prima dell'inclusione del js del progetto

Per ora ho creato la funzione che scorre la pagina e trova tutte le immagini con la classe css "img_tooltip". Per ogni immagine crea una lista che da in pasto poi alla funzione che attaccherà ad ogni immagine il tooltip stesso.

Vediamo cosa riesco a fare.

Risorse GWT

2008-02-15T11:50:00.008+01:00

Ora mi sono messo in rete a spulciare un po' di risorse per GWT, così nei prossimi giorni mi studio altro e provo a sviluppare qualcosa in GWT. Il fine primario è quello sia di imparare meglio a programmare in Java, sia famigliarizzare di più con GWT ma soprattutto tenere a mente l'obbiettivo che devo pormi per la il progetto/tesi: trovare un modo per sviluppare uno strato intermedio tra il server e il client... andando a fare qalcosa di simile a ciò che fa già echo2; in pratica fare in modo di non dover usare solo RPC per ogni interazione del client, ma cercare di pensare sul server la stessa logica sul client, fare comunicare le due logiche e interagire solo con quella lato server

GWT Windows Manager (http://www.gwtwindowmanager.org/)
Offre un sistema "ad alto livello" per la creazione/gestione di finestre e finestre di dialogo. Davvero bello e ben fatto. Da tenere in considerazione.
GWT-EXT (http://gwt-ext.com/)
Libreria fornitissima, con alberi, finestre, layout, e veramenti molti widgets, alcuni interessantissimi.
GWTSITE (http://www.gwtsite.com/)
Un blog con un sacco di risorse interessanti, link utili, tutorial ecc..
OnGWT (http://www.ongwt.com/)
Altro blog aggiornato con risorse su GWT
Tutorial GWT
Un elenco di 17 nuovi tutorial su GWT, alcuni sembran interessanti, altri meno
XSTM (http://www.xstm.net/)
Replicazione e sincronizzazione di oggetti, tra client e client, o client e server, per Java, .NET e GWT. Può esserci molto utile
GWT-Tooling (http://code.google.com/p/gwt-tooling/)
Plugin per Eclipse... questo pare funzionare davvero. Dopo averlo installato, per usarlo, in Eclipse creo un nuovo progetto Web dinamico, seleziono Apache Tomcat 6 come Target Runtime, e seleziono "dinamic web project using GWT" in configuration. Poi una volta creato il progetto, lo seleziono, e con il destro "new" "other" "GWT" "Gwt module". Poi "run on server" (in realtà forse bisogna selezionare run as -> open run dialog -> GWTBrowser)
MyGWT (http://mygwt.net)
Libreria con alcuni riguardi vero il pattern Model-View-Controller (MVC)
GWT Small Guide: Integrazione GWT e PHP con JSON

I 3 metodi di compilazione di GWT

2008-02-15T10:07:00.003+01:00

Stamattina ho praticamente terminato la "lettura" del libro "GWT in Action".
Ho provato a spulciare qualche file js generato dalal compilazione del progetto del libro, Dashboard... illeggibile. Questo è normale, perchè il compilatore di GWT, in maniera standard, genera del codice supercompresso, illeggibile in pratica dall'uomo.
Esistono tre stili di compilazione, dal più compresso al più verboso. Ho provato a controllare la grandezza dei file generati, e la differenza è impressionante.

La scelta del tipo di compilazione la si fa con il parametro -style dato in pasto al compilatore. Questo lo si fa normalmente modificando il file nomeprogetto-shell.cmd, con questi parametri OBFUSCATED, PRETTY e DETAILED.

Ho compilato il progetto contenuto nel libro, GWT in Action, scaricabile anche dal forum/sito del libro (http://www.manning.com/hanson/), e questo è il risultato.

-style OBFUSCATED (dovrebbe valere anche OBF): occupazione cartella www = 10,4 MB
codice illeggibile, adatto per la compilazione finale, per la messa online del lavoro
-style PRETTY : occupazione cartella www = 24,8 MB
codice leggibile, ma con alcuni nomi compressi e codice non troppo lineare
-style DETAILED: occupazione cartella www = 61,2 MB
codice leggibile, esteso, più lineare e descrittivo

La differenza di occupazione di memoria è impressionante, (compressione all'83%... il file generati da obfuscated pesano il 17% rispetto ai file generati da detailed). Ed essembito in ambito web, o comunque di passaggio file attraverso una rete, questa differenza è enorme in termini prestazionali.

Convenzioni sui nomi in Java

2008-02-07T09:56:00.000+01:00

Dal sito di Java (http://java.sun.com/docs/books/jls/second_edition/html/names.doc.html) presento qui le convenzioni per la rappresentazioni dei nomi in un progetto Java.

Package: impotante utilizzare le convenzioni per evitare conflitti sui nomi, soprattutto nel caso di utilizzo di package importati da terze fonti.
- I nomi dei package vanno scritti tutti in minuscolo.
- Se si appartiene/lavora per una compagnia che ha un dominio internet, lo si usa all'inizio del nome del package, prima il "suffisso" del nome a dominio (il dominio di primo livello) poi il dominio effettivo della compagnia (il dominio di secondo livello). Nel casa dei package della Sun si ha "com.sun".
- Se il nome a dominio contiene caratteri speciali non usabili nel nome del package, bisogna convertirli in underscore (per esempio se il nome a dominio è una keyword o se il nome inizia con un numero.
- Se si vuole indicare un sottodominio, lo si può fare, sempre con la logica di scrivere il nome a dominio in maniera inversa, cioè primolivello.secondolivello.sottodominio
- Si può specificare anche il nome dle progetto o della persona che ha sviluppato il package, sempre con la logica di inserirlo in fondo al nome del package.
- Esempi validi sono, per esempio
  com.java
  com.apple.quicktime.v2
Classi e interfacce: Anche in questo caso è buona norma rispettare le seguenti convenzioni
- i nomi dovrebbero rappresentare sostantivi o frasi descrittive non eccessivamente lunghe
- La prima lettera deve essere maiuscola, le altre minuscolo.
- Se il nome è composto da più parole, vanno scritte attaccate, con la prima lettera di ognuna in maiuscolo
- Il nome dovrebbe essere descrittivo della classe, avere un senso, una connessione al significato semantico della classe stessa
- Sono da evitare i verbi, riservati ai metodi
- Esempi di nomi corretti per classi ed interfacce sono:
  ClassLoader
  SecurityManager
  ThreadDictionary
Metodi: utile anche in questo caso rispettare le convenzioni
- il nome di un metodo dovrebbe essere costituito da un vervo che spieghi l'azione del metodo stesso, scritto in minuscolo.
- Se si vuole usare più di una parola, contenenti comunque in verbo, la prima parola deve essere minuscola e le altre avere la prima lettera maiuscola.
- Metodi che leggono e settano una variabile, dovrebbero indicare come prima parola, rispettivamente, get e set, seguita dal nome di variabile interessata
- Metodi che servono per ricavare la lunghezza di un oggetto dovrebbero chiamarsi lenght
- Metodi che verificano una variabile booleana dovrebbero chiamarsi is seguita dal nome di variabile da verificare
- Nomi corretti di metodi sono
  getV
  setV
  isV
  toV
  sommaCostanti
Fields (non so bene cosa siano)
- Names of fields that are not final should be in mixed case with a lowercase first letter and the first letters of subsequent words capitalized.
- Note that well-designed classes have very few public or protected fields, except for fields that are constants (final static fields).
- Fields should have names that are nouns, noun phrases, or abbreviations for nouns.
Costanti:
- Le costanti dovrebbero essere rappresentate da parole o frasi descrittive e/o abbreviazioni, scritte in maiuscolo, divise, se più parola, da un underscore.
- Corretti nomi di costanti sono:
  MIN_VALUE
  MAX_VALUE
  PS_RUNNING
  S_SUSPENDED
Varibili locali e Parametri
- Dovrebbero essere costituite da parole corte, o assemblamenti di lettere, sempre in minuscole, che non necessariamente formano una parola di senso compiuto
- per esempio una variabile che contiene un riferimento all'oggetto ColoredPoint potrebbe chiamarsi cp
- oppure buf potrebbe essere un buon nome per un puntatore ad un buffer
- si dovrebbero evitare variabili di uan sola lettera, escludendo i cicli dove si possono usare (come la classica i) oppure se indicano un type, per esempio per convenzione si usa
  - b for a byte
  - c for a char
  - d for a double
  - e for an Exception
  - f for a float
  - i, j, and k for integers
  - l for a long
  - o for an Object
  - s for a String
  - v for an arbitrary value of some type

Cypal Studio for GWT

2008-02-06T15:18:00.000+01:00

Leggengo "GWT in Action" scopro, e questo è un altro punto a favore di GWT, che esistono alcuni tool per aiutare la vita dello sviluppatore GWT (sì, ok, non posso ancora definirmi uno sviluppatore GWT, manco mi posso definire sviluppatore, però è interessante).
Tra questi un plug in di Eclipse che potrebbe tornarmi utile: Cypal Studio for GWT
E annesso a questo trovo anche un tutorial che mi insegna ad usare questo plugin: http://grprakash.googlepages.com/gwttutorialwithgooglipse

Ritorno a GWT

2008-02-06T14:05:00.001+01:00

Parlando stamane con il mio correlatore, abbiamo pensato, soprattutto vista la non entusiastamente esperienza con la scarsa presenza di documentazione su Echo2/Cooee e la scarsa attività delle community a queste connesse, di riprovare a dare uno sguardo a GWT.

Questo perchè? Forse principalmente per la prima lettera di GWT... la G di Google. Dopotutto questa G da garanzie di stabilità futura, di continua manutenzione. Ma soprattutto è sinonimo di ottima documentazione, grande community e numerosi utilizzatori.

Per fare un esempio, se si cercano in rete tutorial o libri su GWT in breve tempo se ne trovano una marea... su Echo2/Cooee? Poco o nulla

L'idea è tornare su GWT per quanto riguarda l'aspetto client, il disegno dell'interfaccia web, e di pensare noi a qualcosa che possa interfacciarsi con questa per dialogare con il server, senza usare le RPC previste da google

Nel libro "GWT in Action", nella parte in cui si parla di un confronto/integrazione con Ruby On Rail si sottolinea che è possibile intraprendere questa strada: (PAG 24 del pdf)

GWT is client-centric, and most of what GWT does is on the client-side of the picture. It allows you to develop and display widgets using Java and write Java handlers to trap user-triggered actions. GWT can communicate with the server, as needed, which could be driven by user interaction, or perhaps a timed event.
GWT then allows you to compile all of the Java code to JavaScript so that the program can be run in the browser. On the server, GWT only provides a mechanism for serializing and desterilizing Java objects so that they can be received from the browser and sent back, and does not get involved in other aspects of the server.
Instead of competition between GWT and Ruby on Rails, we find an opportunity for integration. This is in part driven by the fact that GWT provides several non-proprietary schemes for passing data between client and server. We are finding that many developers who are starting to use GWT are using non-Java technologies on the server, and are looking at GWT to provide only client-side functionality.

Credo che il discorso si possa allargare ad ogni tecnologia (o quasi) ci sia su lato server. Ora mi studio ancora un po' GWT, sperando di riuscire ad apprenderlo a fondo in modo da concretizzare l'idea di realizzare un "interfaccia lato client con GWT e lato server con Java"

Cooee e i threads

2008-02-05T10:19:00.000+01:00

Ieri e stamane ho provato a convertire le mie prove fatte con echo2, in cooee.
Non è un operazione molto difficile, basta cambiare, come spiegato qui http://www.karora.org/wiki/display/COO/Migrating+from+Echo2 , le referenze ai package di cooee.
In realtà ho dovuto cambiare anche altre cosucce, che non so bene spiegarmi (come cambiare il tipo Boolean in boolean... non so come mai), ma alla fine tutto sembra funzionare.

O quasi.

Le finestre funzionano, le aperture di quelle modali anche, il passaggi di parametri non ha problemi. A Parte qualche discrepanza (in Echo 2 i selectfilds si autoselezionano, almeno graficamente, mentre in cooee no, forse è anche meglio, dato che nemmeno in echo2 si selezioanno davvero in maniera automatica), è tutto ok.

Ma i threads paiono non andare, o meglio, sembra che non riescano ad aggiornare l'interfaccia utente

Exception in thread "conta2" java.lang.IllegalStateException: Attempt to update state of application user interface outside of user interface thread.

non so bene cosa significhi, ho chiesto un aiuto alla community... che però non sembra così attva come mi aveva indicato Fissore: http://www.karora.org/forum/thread.jspa?threadID=138&tstart=0
Staremo a vedere.

Federico Fissore e Cooee

2008-02-04T12:13:00.000+01:00

La settimana scorsa, tra le poche cose fatte, ho scritto a Federico Fissore (www.fissore.org), personaggio che spesso è "saltato fuori" durante le mie ricerche in internet riguardo a echo2. A quanto pare è uno degli italiani che ha sviluppato con questo fremowork.
Gli ho scritto chiedendogli un suo parere sul futuro di Echo2... gli ho spiegato la mia situazione chiedendogli qualche consiglio.
Prontissimo e gentilissimo mi ha risposto...

Incollo qui la sua rispota... può sempre essere utile a qualcun altro:

[...]
Dunque, se posso riassumere la tua mail, tu vuoi sapere se Echo2/3 sono
una soluzione viabile e, se sì, dove trovare documentazione più completa

Il mio parere, e mi spiace davvero tanto dirlo, è negativo: no, non mi
fiderei troppo di Echo2, per una somma di ragioni diverse, che ti
snocciolo perchè tu possa usarle anche in altri contesti

Framework per costruire Rich Internet Applications ce ne sono tanti,
troppi: spiccare fra gli altri è difficile.
GWT ci riesce per due motivi

* si chiama GOOGLE web toolkit (ChiTiConosce web toolkit non avrebbe
avuto lo stesso successo)
* come dicevo nell'intervista, GWT si presta più facilmente allo
sviluppo di applicazioni per il grande pubblico, il che significa
visibilità e passaparola

Tutti gli altri rimangono nelle nicchie, e lì gioca davvero il loro
valore e la loro community.
Sul valore di Echo2 non ho dubbi: è tecnicamente un OTTIMO strumento. Le
API sono chiare e semplici. Si possono fare (e ho fatto) cose moolto
interessanti con poche righe di codice. Personalmente mi sono davvero
divertito
Ma Echo2 è un prodotto di nicchia, gestito ahimè da un idiota, che

* non ha abbastanza soldi per sviluppare certe componenti importanti
* ha una community piccola, quindi in grado di sopperire alle
mancanze economiche con eccessiva lentezza
* non è molto propenso a dare accesso in scrittura ai membri anche
capaci della comunità, causando un rallentamento anche
nell'applicazioni delle patch proposte dai membri della comunità

Un'alternativa è Cooee (http://karora.org/), fork di Echo2, che promette di fare
manutenzione evolutiva sui componenti esistenti (evitando di rompere la
retro compatibilità come ha fatto Echo3). Anche qui, per quel poco che
ne so, la community è piccola

Quindi?
Ho lavorato con Echo2 per un anno, sviluppandoci 2 progetti. Oggi a quel
mio cliente propongo di passare a Cooee per non dover rifare tutto ma
per evitare di applicare delle patch fatte in casa come invece fa oggi
(le patch che ho sviluppato io e che sono sempre state ignorate
dall'idiota di prima, nonostante il numero di download di chi se le
voleva applicare a mano)

Se però dovessi cominciare un lavoro nuovo, penserei ad altro
ZK (http://zkoss.org/) sembra essere un buon prodotto: è GPL, quindi non ci si può fare
applicazioni proprietarie da redistribuire, ma continua a ricevere elogi
e chi lo ha usato qui a Torino me ne ha parlato bene
wingS (http://wingsframework.org/) è un altro progetto che mi attira: ha delle API molto simili a
Swing ed è sviluppato da tedeschi (quindi si "gioca in casa")
openlaszlo (www.openlaszlo.org/): altro progetto moolto interessante per supporto e
qualità finale del prodotto. Con la versione 4 hanno finalmente aggiunto
un rendering DHTML invece del solo rendering Flash (che 2 anni fa me lo
aveva fatto scartare)
[...]

Lo switch in Java

2008-02-01T16:45:00.000+01:00

Un'altra delle cose scoperte la settimana scorsa, che all'inizio mi ha lasciato nel panico, perchè non capivo cosa stesse succedendo, è che Java a uno switch... che funziona solo su integer...
Non conosco i moivi di questa scelta implementativa... che mi pare bizzarra... in un linguaggio dove puoi fare quasi tutto, questa è una limitazione non da poco

E a volte è proprio utile, soprattutto ai fini delal leggibilità del codice, eseguire uno switch su delle stringhe

Ok, ok, la soluzione potrebbe essere una serie di If elseif... ma ve lo immaginate un codice con una decina di elseif?
Uno schifo.

Certo, si potrebbe pure fare una mappatura "caratteri-integer", ma che barba... e poi risulterebbe meno leggibile il codice

Girovagando in rete ho trovato una soluzione abbastanza buona.
In pratica, prima di eseguire lo switch, si crea una costante Enum, elencando come contenuti enumerativi le stringhe che si vogliono usae... e poi switchare su queste

Esempio, ho una variabile stringa che può assumere questi valori "carne, pesce, dolce, contorno, frutta" e voglio creare uno switch su questa variabile sringa
Si prosegue così:

Definire una costante enum con i valori congruenti alle stringhe che si vogliono prendere in considerazione

enum portate {
carne, pesce, dolce, contorno, frutta
}
Successivamente eseguire uno switch con un valueof(costanteenum). Il valueof fa una comparazione tra le stringhe e i valori di enum. Si può usare toLowerCase per un confronto non case sensitive

switch (portate.valueOf(e.getActionCommand().toLowerCase())){
case carne:
bla bla
break;

[...]

case frutta:
bla bla
break;
}

L'unico problema è che così si potrebbero sollevare delle eccezioni IllegalArgumentException or NullPointerException (penso che succeda se la stringa ha un valore che non ha corrispondenze nell'enum. Si possono gestire con un Try-catch


enum portate {

carne, pesce, dolce, contorno, frutta;

public static portate cercaportata(String stringa)
  {
      try {
          return valueOf(strimga);
      }
      catch (Exception ex) {
          return NOVALUE;
      }
  }
}

switch (portate.valueOf(e.getActionCommand().toLowerCase())){
           case carne:
               bla bla
               break;
         
                    [...]
        
           case frutta:
               bla bla
               break;

          default:
               bla bla per valori non presenti nell'enum
       }

Thread & company

2008-02-01T14:37:00.000+01:00

Durante questa settimana non sono riuscito a fare molto.
Ieri ho dato il mio ultimo esame... laboratorio di sistemi operativi
Quindi un giorno di lavoro in meno, in più non sono stato nemmeno bene... insomma ho lavorato ben poco purtroppo

Comunque sono riuscito ad implementare, nella mia mini-stupida applicazione i thread

In pratica ho provato a vedere se si riuscivano ad usare in echo2 i thread e tutto ciò che riguarda la programmazione concorrente che Java mette a disposizione.

Mi sono dedicato ai thread perchè mi sono accorto, leggendo qua e la e provando con il codice, che la classe timer di swing non è disponibile in echo2.

Ma i Thread sì.

Funzionano, ne ho creati due, da far partire in momenti diversi, che aggiornato ogni secondo delle etichette di testo... un thread parte attivo con l'applicazione e s ferma all'atto dell'apertura di una nuova finestra, l'altro viceversa... viene attivato con l'apertura di una nuova finestra e si adormenta alla chiusura della stessa.

Attualmente ho utilizzato un busy waiting per gestire il controllo dello stato dell'applicazione, giusto per provare.
Lo so, non è una soluzione molto corretta, ma qui non mi serviva l'efficienza.
Ma comunque credo sarebbero comunque disponibili i monitor e gli altri sistemi di sincronizzazione di Java, senza alcun problema.

Però è emersa un'altra particolarità di Echo2... che in effetti avevo letto, ma non compreso sino in fondo...
In pratica non tutto cio che il lato server "aggiorna" viene effettivamente aggiornato lato client... la sincronizzazione avviene solo quando lato client succede qualcosa... questo per ridurre lo scambio di messaggi tra client e server per non appesantire la banda

Questo cosa comporta? che per esempio le etichette dei contatori, sebbene i contatori si tengono aggiornati lato server e sono coerenti anche lato client quando vengono visualizzati, romangono FISSI fino a quanto l'utente fa qualcosa lato client... apre una finestra, clicca un pulsante, fa uno scrolling eccetera

Infatti i miei contatori rimangono apparentemente fermi, ma alla prima interazione si aggiornano con i valori che piano piano si erano aggiornati via server...
Questo potrebbe creare dei problemi, ma esiste il sistema per rimediare, modificando la parte client del framework

Comunque, la disponibilità e il funzionamento dei thread, ha messo in risalto che gli eventuali problemi che potrebbero nascere dal bisogno di avere una parte del codice "bloccata" in attesa di qualche interazione, si potrebbero risolvere proprio con l'utilizzo dei thread... che di fatto si posson bloccare su delle risorse e/o condizioni varie con dei monitor o altre soluzioni simili

Connessione al database

2008-01-25T08:50:00.000+01:00

Da ricordare per far funzionare la connessione a derby in un programma Java.
In Eclipse, dopo aver fatto le istruzioni per la creazione di un progetto Echo2, devo

nel progetto, come fatto per echo2, apro l'albero, selezione Web-Content -> Web-Inf -> Lib e importo (come file system) il contenuto della cartella di lib della cartella di installazione di Derby
Per me quindi: C:\Apache\db-derby-10.3.2.1-bin\lib
faccio partire il server derby (credo di farlo almeno) con questa riga di comando, da dare appunto nel promt dei comandi
java -jar %DERBY_HOME%\lib\derbyrun.jar server start
La connessione al databse in derby deve essere quella da "client-server" quindi:
CONNECT 'jdbc:derby://localhost:1527/NOMEDATABASE';

Agiornamento ore 11:36
Alla fine funziona... il collegamento al database funziona e tutto è in regola.
La domanda ora è:
Echo2 è quello che fa per noi?
Sarà un progetto che da continuità?
Echo3 introdurrà cose interessanti, tra cui (se non ho capito male) la possibilità, con apposite api, di manipolare anche il javascript lato client, ma avrà la stessa licenza? ci si può fidare?
Spero di sì... perché sembra carino, e penso non sarà troppo difficile creare qualcosa di decente per la mia tesi

Database Derby

2008-01-24T12:02:00.000+01:00

Dopo aver definito una mini applicazione, ora devo verificare se riesco ad usare java/echo2 per consultare e lavorare con un database

Per il momento provo ad utilizzare Derby, un database improntato a java (e sviluppato in java, se non ho capito male), della apache foundation: http://db.apache.org/derby/

L'installazione, che avevo già effettuato, è andata a buon termine, e anche i settaggi.
Ho avuto qualche problema (di nuovo) con le variabili di ambiente (dal pannello di controllo sembra che non si settino a dovere, devo fare da prompt con "set")

Ho eseguito il "tutorial" del file, nelle documentation "Getting Started With Derby": http://db.apache.org/derby/docs/10.3/getstart/
Imparando le basi della connessione al database sia via promt dei comandi, sia, soprattutto, da un file java
Sembra abbastanza facile... un po' come la connessione in php a un server mysql
La stessa guida è anche in formato pdf.

Ora sto dando un occhiata alla guida per gli sviluppatori di applicazioni derby, qui in pdf
In particolare può essere utile la mini guida pratica per la gestione delle connessioni, o quella per la gestione dei resultset

Sarà utile sicuramente anche tenere sottomano il Manual Reference, anche in pdf

Tutta la documentazione di Derby la si trova comunque qui: http://db.apache.org/derby/manuals/index.html

Le prime creazioni

2008-01-23T17:10:00.000+01:00

Dopo due giorni di lavoro ho creato la prima mini applicazione...
bhe, non merita nemmeno di essere chiamata una applicazione... diciamo che almeno sono riuscito a costruire qualcosa.

Per verificare se Echo2 corrisponde alle nostre esigenze ho provato a creare una finestra di "inserimento anagrafica". Questa finestra ha dei TextField che devono essere popolati dall'utente...
Due di queste maschere hanno un aiuto... in pratica hanno associato un tasto, ognuna, che apre una nuova finestra per svolgere qualche operazione (come la ricerca nel database) e che chiudendole restituiscano alla finestra principale i dati ricercati.

Ovviamente al momento la ricerca nel database è fittizia... queste due finestre hanno una listbox prepopolata.

All'atto dell'apertura di una delel due nuove finestre, tutto il resto è bloccato. Infatti queste due finestre sono create modali... in pratica sì può solo interagire con questa, non si può fare nulla con le altre.
Tutte le finestre sono Drag&Drop.
Così si può spostare questa seconda finestra per vedere la sottostante, che però è inattiva.
Queste seconde finestre sono rese "non chiudibili" in modo che non abbiano la classica icona di chiusura.
Entrambe le finestre di aiuto hanno una list box, e due tasti... un cancel (per chiudere la finestra modale senza apportare modifiche alla finestra sottostante) e una ok, per trasferire i dati del campo selezionato alla finestra sottostante.

E funzionano!
Come volevo io...

Non sono bloccanti, non nel senso che Francesco pensava... non si può, nel mezzo del codice, creare un istruzione del tipo
int cap = aprimi_finestra();
dove si interromperebbe qui l'esecuzione, si richiama la procedura aprimi_finestra e si aspetta la sua risposta...
questo non si può fare

ma in pratica essendo, essendo al gestione del programma a "stati", non comporta alcun problema, almeno dal mio punto di vista

Ho una finestra e ho uno stato
apro un'altra finestra e ho un altro stato
alla chiusura di quest'ultima aggiorno lo stato della prima

e così via

WindowPane

2008-01-22T16:48:00.000+01:00

Dove Pane va letto come "pain" quindi, sofferenza
Sì, sofferenza... qualcosa come 6 ore a faticare per far funzionare questo componente di Echo... sono le finestre Drag & Drop.
Dagli errori più stupidi, derivati dalla mia scarsa conoscenza di Java (della serie che cercavo di usare degli oggetti non istanziati), a quelli che derivano dalla mia scarsa conoscenza di Eclipse (chi lo sapeva che bisogna sempre uccidere, o almeno svuotare la path, del processo del server che sta andando? Altrimenti sembra non "compilare" il codice nuovo, ma utilizzare quello vecchio... quindi selezionare il server in basso, nella finestra server, tasto destro sul processo in esecuzione e o lo si elimina oppure si svuota la directory di lavoro del modulo)

Bhe, alla fine ce lho fatta

Ora ho una finestra Drag&Drop, con dentro un po' di etichette (Label) textfield, e un bottone... che premendolo fa cambiare titolo alla finestra stessa, ma soprattutto ne ape un altra.

E non è poco :-D

Ora devo provare a fare diventare la nuova finestra modale, in modo che renda inutilizzabile la finestra "madre", e provare a far dialogare le due finestre...
Vedremo se riuscirò.

Echo2, possibile "soluzione"

2008-01-18T10:35:00.000+01:00

Parlando con Francesco Echo2 potrebbe essere il framework a cui ci dedicheremo. Dopo qualche minuto di panico sulla licenza (sul sito non si capiva bene che licenza avesse), abbiamo scoperto che è sotto la Mozilla Public Licenze (MPL) e quindi si possono sviluppare con questo framework anche applicazioni "propietarie".

Ora il discorso principale è capire se Echo2 ha il "difetto" di GWT: non essere bloccante.

E' una cosa che ho fatto un po' fatica a capire anche io, non tanto capire la cosa in se, ma capire i problemi ad esso correlati. In pratica noi avremmo l'esigenza che l'applicazione creata possa essere "bloccata" nel momento in cui si richiede l'interazione con l'utente.

Tipicamente con le applicazioni AJAX, questo non si può fare (non per nulla la A di Ajax sta per asincrono).

Quale è il problema:
Se siamo in una maschera e l'utete clicca un pulsante per un "cerca", noi vorremmo che tutto nell'applicazione si blocchi in attesa della risposta... ma co al logica dell'essere asincrono no è così... il resto dell'applicazione se ne va avanti indipendentemente da cosa fa l'utente con la nuova finestra.
Anche con GWT esiste la possibilità di inserimento di una finestra modale, come quelle di avviso (classico segnale di errore con il tasto ok) e un'altra alert modale (con tasti ok e cancel) e queste bloccano di fatto l'applicazione, ma non si può fare nulla di più di una finestrella con due tasti.

Con Echo si potrà avere una logica bloccante? Nella documentazione letta al volo si parla di finestre modali, e questo "modale" può significare bloccante

Staremo a vedere

Aggiornameno alle ore 11:33
Dal sito di Echo2 (http://echo.nextapp.com/site/) non capisco bene come procedere per capire le basi dello sviluppo con questa applicazione.
Fortunatamente nel wiki trovo un link che pare interessante: www.pathf.com/echo2/Echo2-Part1.pdf
Pare che spieghi come integrare echo e eclipse, cosa installare, come iniziare
Quello che fa per me

Aggiornamento alle ore 15:35
Mannaggia, più di 3 ore su ste cavolo di tutorial, semplicissimo, ma non andava
dopo un po' di incavolatura (prima c'era un altro server sulla porta 8080, trovato come chiuderlo, dava ancora problemi, un errore 505) ho trovato con google (potere google) la soluzione
in pratica nel tutorial c'era un piccolo errore, nel file web.xml la riga

AjaxSample.servlet.AjaxSampleServlet

è errata e va sotituta con

ajaxsample.servlet.AjaxSampleServlet

argh... problemi di case sensitive..
cmq ora va

ma ovviamente non era abbastanza, troppo breve come tutorial
trovo il blog dell'autore... che non hai mai fatto la parte numero 2 di quel tutorial, comunque eccola: http://blogs.pathf.com/agileajax/echo2/index.html
e anche queste due pagine sembrano interessanti: http://ensode.net/echo2_review.html
http://ensode.net/echo2_closer_look.html

Aggiornamento delle 17:02
Ancora un ora persa per cercare di far partire uno dei tutorial "ufficiali", in number guess
non mi andava... continuavano ad esserci errori
metto qui i passaggi così se in futuro devo usare altri source simili so cosa fare

in eclipse creo un nuovo progetto, New (dall'icona, non dal menu), Web, Dinamic web project. Scelto tomcat come server
in base alla logica dei package che trovo nei file "java" del source che voglio usare, creo in eclipse i relativi package e ci sbatto dentro i file source java... ovviamente rispettando la logica dei package
in eclipse, cerco la cartella webcontent->Web-Inf->Lib; clicco con il destro e poi "import". Scelto File System. Cerco in "browse" la cartella di installazione di echo due, poi la sottocartella binary libraries. Nel mio caso "C:\Programmi\NextApp_Echo2\BinaryLibraries". Scelgo quindi questi jar: Echo2_App.jar, Echo2_WebContainer.jar, Echo2_WebRenderer.jar e
EchopointNG.jar
nella cartella "WebContent" creo un file "index.html" così composto

<!DOCTYPE
HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<meta http-equiv="Refresh" Content="0; URL=app">
</head>
<body>Redirecting to application.</body>
</html>
nella cartella Web-Inf dentro WebContent modifico il file "Web.xml" fino a renderlo simile a questo

<?xml
version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID"
version="2.5">

<display-name>provaecho2</display-name>
<servlet>

<servlet-name>NumberGuessServlet</servlet-name>

<servlet-class>echo2tutorial.numberguess.NumberGuessServlet</servlet-class>
    </servlet>
    <servlet-mapping>

<servlet-name>NumberGuessServlet</servlet-name>

<url-pattern>/app</url-pattern>
    </servlet-mapping>
<welcome-file-list>

<welcome-file>index.html</welcome-file>

<welcome-file>index.htm</welcome-file>

<welcome-file>index.jsp</welcome-file>

<welcome-file>default.html</welcome-file>

<welcome-file>default.htm</welcome-file>

<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
</web-app>

importanti queste due righe
NumberGuessServlet
echo2tutorial.numberguess.NumberGuessServlet
Che devono avere il nome e la struttura dei package del servlet creati (cioè il file source java che si chiama "nomeapplicazione.Servlet.java")
Fatto tutto questo dovrebbe essere pronta per "partire"
Seleziono con il destro il progetto in eclipse, seleziono "RunAs" e "Ron On Server", seleziono il server tomcat e tutto dovrebbe partire

GWT In Action

2008-01-15T19:59:00.007+01:00

Nel week end sono riuscito a procurarmi una copia del libro che avevo presentato, GWT In Action.
Userò questo post per segnarmi gli appunti presi da questo libro che potranno servirmi in futuro.
Per prima cosa, bisogna modificare qualche cosettina nel codice scaricato dal sito (http://www.manning.com/hanson/), oltre ovviamente quello indicato nel file install.txt
Leggendo sul forum del libro

Now GWT 1.4 is out and final, there are a couple of changes required for the Dashboard download code; until we get chance to replace the downloadable version, here are the changes that are needed:

1) In ToolBarImageBundle.java replace the "import com.google.gwt.user.client.ImageBundle;" with "import com.google.gwt.user.client.ui.ImageBundle;"

2) In Dashboard.java, remove "import com.google.gwt.i18n.client.DateRecord;"

For me, at least, that seems the only changes needed to make the Dashboard work with the full 1.4 release. Feel free to post other issues you find below and we'll see if we can identify fixes if needed.

GWT accetta solo codice scritto in Java 1.4 (al momento). Per i componenti server invece si uò usare la versione che si vuole. PAG 7
ci sono 3 metodi di compilazione: obfuscate (che genera codice praticamente illeggibile, ma compresso), "pretty" (che genera codice intermedio), "detailed" (che genera codice leggibile e non compresso). PAG 6
JSON è un formato di messaggi per scambiare dati srutturati con il browser. Sul sito http://json.org esistono i formati per molti linguaggi. In questo modo si può integrare un qualsiasi linguaggio sul server e si può dialogare senza problemi, tramite il browser, con GWT. Si usa, per esempio, quando si gestiscono le RPC con il metodo RequestBuilder. Se sul server si usa Java, non ha molto senso usare JSON, perchè si tradurrebbe da Java a JSON e poi da JSON a Java... quindi è meglio usare direttamente GWT-RPC. PAG 15 e JSON a capitolo 12
I widget di GWT hanno delle classi css già assegnata... quindi se si vuole si possono usare direttamente quelle nei css legati alla pagina web (ai file gwt tramite l'xml di configurazione). Per sapere quali classi ci sono per ogni widget cercare nei java docs di gwt
la gerarchia dei widget:

E la loro suddivisione in categorie:
I nomi dei package in gwt dovrebbero rispettare il classico nome dei package e le classi (come quelle usate nella creazione con applicationCreator) dovrebbero avere il nome del package, obbligatoriamente la parola client, e il none della classe.
Ad esempio org.gwtbook.client.Dashboard

Facendo un salto in avanti
Serializzazione di oggetti:
- Si serializzano solo i campi non transient. Anche i campi definiti final non vengono serializzati, ma è meglio sempre dichiararli transient per chiarezza.
- Se una classe implementa com.google.gwt.user.client.rpc.IsSerializable, anche le sottoclassi, anche se non la implementano specificatamente, sono serializzabili.
- Ai fini di ottimizzare il codice javascript creato da GWT è sempre meglio specificare i tipi delle variabili. Perchè con oggetti poco tipizzati come ArrayList, Vector, HashSet ecc... il compilatore, non sapendo il tipo della variabile, genera codice javascript molto più grosso. GWT ci permette però di specificare il tipo di queste variabili con annotazioni commentate, in questo modo, per esempio
```
/**
* @gwt.typeArgs <java.lang.String>
*/
private ArrayList listOfNames;
```
Servizi RPC
- Anche in questo caso è sempre meglio definire bene i tipi delle variabili, dei parametri eccetera usati dai metodi sei servizi RPC
```
/**
* @gwt.typeArgs arg1 <java.lang.Integer>
* @gwt.typeArgs arg2 <java.util.Date>
* @gwt.typeArgs <java.lang.String>
*/
ArrayList operationThree (List arg1, Vector arg2);
```
  in questo modo si è specificato il tipo dei due parametri e il tipo del parametro di risposta (il terzo)
- Se si vogliono sollevare eccezioni, anche l'eccezione deve essere serializzabile
Quando si utilizzano gli array JSON, bisogna stare attenti, non essendoci il metodo add, ma dovendo inserire ogni elemento nell'array specificandone l'indice, poichè si potrebbe avere un array con dei "buchi", cioè senza valore per alcuni degli indici interni. Questo potrebbe portare a delle eccezioni nel codice, per esempio se si richiama il metodo toString() sull'array "bucato". Per risolvere questo problema si potrebbe usare questo codice per "riempire potenziali buchi" negli array
```
private void fixJsonArray(JSONArray array){
    for (int i = 0; i < array.size(); i++) {
        JSONValue val = array.get(i);
        if (val == null) {
            array.set(i, JSONNull.getInstance());
        }
    }
}
```

Echo2

2008-01-15T11:12:00.000+01:00

Durante lo studio del libro GWT in action, sono arivato a pagina 22 del libro, dove si parla del confronto di GWT con altri framework... tra cui questo "echo2". Leggendo le parole del libro e questa intervista www.javajournal.it/blog/2007/01/15/intervista_federico_fissore_su_echo2.html in effetti sembrerebbe che questo framework sia proprio sulla strada di quello che vorremmo realizzare qui alla fdl. Ne parlerò con Francesco.

Altra pagina interessante, che mi porta sempre più al pensiero che echo 2 faccia per noi: www.theserverside.com/news/thread.tss?thread_id=40804

Continuo comunque nello studio del libro GWT in action

Dentro GWT

2008-01-10T23:43:00.000+01:00

Oggi termino i tutorial iniziati ieri... me li studio meglio
In mattinata riprendo i primi due e finisco il terzo.
Trovo in rete, studiando questi, alcune risorse interessanti:

JRE Emulation Galery se non ho capito male si tratta di un elenco di tutte le classi, metodì eccetera, accettati da GWT. Sempre se non ho capito male, in pratica, queste sono le cose che posso senza problemi usare come in Java... e GWT le capisce e interpreta (e traduce) correttamente.
GWT Javadocs ( o ancora meglio direttamente nella pagine di google) (verificare se le due pagine contengono info diverse... da preferire quelle di google), un elenco di tutto lo scibile di GWT... ci sono tutte le classi che posso usare in gwt, comprese quelle "proprietarie" di gwt... serve più che altro per capire cosa fa una classe se la si incontra nei tutorial... ha un completo "index", si trova di tutto insomma
Roughian Examples: sono un po' di tutorial e spiegaziono sulle classi di gwt... l'intera sezione è fatta, pare, con gwt

In tarda mattinata, giusto prima di pausa pranzo, mi addentro a capire come funziona il lato server di GWT... in pratica usa delle RPC (remote procedure call) per dialogare con il server
sul sito di google code c'è l'introduzione alle rpc... devo ammettere che non è che ci capisco molto

trovo alcune pagine che ne parlano, le elenco qui, in futuro le riprenderò
http://www.oracle.com/technology/pub/articles/dubois-gwt.html

nel frattempo trovo un altro tutorial carino di GWT, me lo studio e lo esamino, carino. Tra le altre cose introduce il concetto di focus panel, che prima non avevo nemmeno capito esistesse... e usa delel tecniche particolari per le animazioni
Agile Ajax: another GWT Tutorial

alla fine mi sa che devo studiarmelo seriamente GWT... avendo basi super traballanti per Java (ma anche, se non soprattutto, per concetti come quello del RPC) devo prendermi un libro
ne esiste uno su GWT... proverò a cercarlo come pdf per poi eventualmente comprarlo

Google Web ToolKit - GWT

2008-01-10T02:30:00.000+01:00

Ed ecco che oggi inizio a guardarmi GWT (http://code.google.com/webtoolkit/).
In pratica son una serie di librerie di Java che permettono di programmare in Java per poi produrre del codice Javascript al fine di creare applicazioni in AJAX.
Sostanzialmente ci si scorpora dall'obbligo di conoscere a menadito Javascript, ma soprattutto, di evitare di addentrarsi nei problemi di compatibilità dei broweser... fa tutto l'interprete di GWT.

Leggendo la documentazione sul sito di google code, scopro che l'IDE da preferirsi per lo sviluppo di applicazioni con GWT è l'open source Eclipse. Infatti uno degli eseguibili di GWT può, volendo, creare dei file per usare al meglio questo IDE.

Installare GWT è semplice... poche istruzioni da seguire.
Per iniziare i progetti con eclipse basta dare dei parametri in più all'eseguibile "crea progetto" di gwt.
Creo la mia cartella di progetto, che chiamamo "GWT_Esempio", dal promt dei comandi (CMD) entro in questa cartella
eseguo poi il creatore di progetto passandogli come parametri il fatto che voglio creare un progetto eclipse che si chiama GWT_Esempio (come la cartella che ho creato) con questa riga di codice:
c:\Programmi\gwt-windows-1.4.61\projectCreator -eclipse GWT_Esempio
per poi fare uan cosa simile con il creatore di applicazioni
c:\Programmi\gwt-windows-1.4.61\applicationCreator -eclipse GWT_Esempio GWT_Moonwalk.client.GWT_Esempio
Così facendo creo i file principali che serviranno per compilare con GWT ed eseguire l'applicazione in maniera HOSTED MODE
Ma ancora meglio così si crea la situazione ideale per programmare in eclipse... posso semplicemente accedere in eclipse, cliccare file, import, import existing project, seleziono la cartella ed ecco il progetto importato... con tutto pronto per eseguire il tutto direttamente in eclipse, con la possibilità di fare il debugging

Prima disperazione:
Sembrano non esistere tutorial ufficiali di gwt... il sito di google code ha un sacco di materiale su gwt, ma pare più che altro adatto a chi conosce bene Java... e non chi l'ha iniziata a studiare meno di un mese fa
Cerco in rete dei tutorial... ne trovo alcuni per il classico "Hello World" che non mi insegnano molto, dato che sono quasi identici a Java puro... ma almeno prendo un minimo di pratica con Eclipse

Trovo un tutorial Working with GWT, decente, inizio a capire qualcosa... ma non è spiegato molto bene e vado subito in confusione

Ne trovo un altro, sul sito della ibm: Build an Ajax application using Google Web Toolkit, Apache Derby, and Eclipse sembra promettere bene
Mi installo quindi Derby, che se non erro è un database sviluppato e pensato per Java
Perdo tutta la mattinata e il primo pomeriggio ad installarlo... ho un conflitto con due versioni di java presenti sul portatile che ho in dotazione, un maledetteo
java.lang.UnsupportedClassVersionError
In pratica, navigando in rete, scopro che è un conflitto tra due versioni di java che ho sul pc... ho meglio... io ne uso normalmente una (qualcosa come 1.6.x), questo derby richiede una 1.4.x ma sul pc, da qualche parte, ho una 1.3.x che continua a prendere il sopravvento

impazzisco... cerco le variabili di sistema, sembra tutto ok... mamma mia aiuto cosa è
disinstallo java, reinstallo... ma nulla
dopo un po' scopro che sul pc è stato installato (prima che io lo toccassi) Oracle... e oracle ha un jdk 1.3.x
impazzendo un po' trovo la variabile di sistema installata da oracle. Ed ecco lì la stronza... c'era un "Path" settato da lui... e quindi il mio pc cercava prima lì dentro il java.exe
metto prima di questa variabile un altra path specificando la nuova directory di isntallazione
riavvio e....

funziona
derby installato... ma... alla fine mi accorgo che il tutorial non fa per me
(l'intero tutorial, che riprenderò in seguito, si trova: parte 1 | parte 2 | parte 3 )

Nel pomeriggio trovo un tutorial con qualche esempio un minimo complesso... e qui inizio a capire come funziona davvero GWT: KickStartin GWT on clint side
Ci sono 3 demo, con un minimo di complessità
riesco a vedere le prime due...a modificarle un po', a capire come funzionano i Panel e I widgets (tutto funziona in pannelli a quanto pare, simili a quelli di Swing, ma ovviamente con nomi e proprietà diversi)

Swing e AWT

2008-01-09T02:30:00.000+01:00

Con oggi ho terminato di "studiare" la parte principale del secondo libro di java che mi sono posto di studiare. Ho sostanzialmente terminato tutta la parte riguardante le librerie grafiche AWT e Swing. Ho fatto un po' di esperimenti con il codice del libro, e in sostanza riesco a creare qualcosa che assomiglia ad un abbozzo di applicazione... tuttosommato non è difficile. E l'IDE che uso per programmare (NetBeans, si trova sul sito della sun) rende le cose ancora più facili. Da domani inizio a studiarmi GWT, il tollkit di google per programmare in Java e produrre "codice Ajax"

Lavoro del mese di Dicembre

2008-01-07T19:30:00.000+01:00

Ecco che inizia la seconda settimana di lavoro. Bhe, sono stat fortunato... la prima è durata due giorni, causa feste.

Comunque già tutto rivoluzionato: per permettermi di avere un minimo di dialogo con il mio correlatore (condividiamo l'ufficio qui in FDL) mi spostano il mio "giorno di riposo" dal Venerdì al Lunedì... così dalla settimana prossima lavorerò da Martedì a Venerdì

Vediamo un po' la preparazione che mi sono fatto nel mese di Dicembre, in qualche modo dovevo pur prepararmi a questo lavoro e allo sviluppo della tesi.

Per prima cosa mi sono scaricato qualche manuale Javascript, leggendo qualcosina, spulciando qui e la, compresi qualche tutorial online, ho imparato qualcosina di questo linguaggio.
Giusto una spolverata... in teoria nella mia tesi Javascript non lo userò proprio... sebbene le parti web saranno Ajax (quindi in javascript), è probabile non lo useremo a basso livello, ma sfrutteremo quello generato da GWT o poco più

Mi sono letto anche qualche pdf per Ajax, cercando di entrare nella logica di questa "piattaforma", facendo qualche piccolo tutorials online.

Dopo un incontro con Franscesco Pasqualini, il mio correlatore, mi sono deciso a dedicarmi a Java, così mi sono comprato su IBS due libri su questo linguaggio di programmazione... erano in offerta

Giusto un bigino di Java, un riassunto del riassunto, ma almeno ho capito le basi di questo linguaggio. Poi è piccolo, è comodo da tenersi vicino nel caso degli atroci dubbi che sempre vengono

Libro un po' più corposo, sviluppato in maniera molto "didattica". Incentrato sull'aspetto di sviluppo di applicazioni grafiche. Sono appena riuscito ad iniziarlo, a dicembre

Mi sono presentato così alla fdl... in pratica non so nulla di quello che devo fare per il mio progetto... imparerò... dopotutto è uno stage, sono qui per imparare, no?

Titolo della Tesi

2008-01-03T21:30:00.000+01:00

Questa è la mia domanda di tesi, in teoria accettata (il giorno che sono andato alla riunione della commissione per l'accettazione della tesi... la riunione non c'è stata... ci hanno riferito "se non vi telefoniamo significa che la vostra tesi è stata accettata)... manderò comunque una mail per sapere se è tutto ok

SPAZIO DOMANDA TESI

Primo Giorno di lavoro

2008-01-02T21:00:00.000+01:00

Oggi è il mio primo giorno di lavoro qui alla fdl servizi.
Dopo mesi di attesa per le carte burocratiche (che devono ancora finire) ho potuto finalmente iniziare il mio stage presso questa società informatica della mia zona.

Obbiettivo: sviluppare la mia tesi presso questa azienda, progettandola di laurearmi nella sessione di Luglio 2008 (15-18 Luglio 2008)... ce la farò?

Lavoro dal Lunedì al Giovedì, 8 ore al giorno