Echo2, aka "Swing su web"

Nel progetto a cui sto lavorando, oltre a Castor per il marshaling/unmarshaling dell'xml (di cui ho già parlato qui), si usa Echo2 per la GUI.

In maniera concettualmente simile a quello che fa Google web toolkit, Echo2 funziona che si scrive in Java e lui, in maniera completamente invisibile a noi programmatori, produce il codice HTML + Javascript + AJAX; a differenza di GWT, però, Echo2 produce il codice "al volo" in una servlet anzichè essere compilato "a bocce ferme"...non che faccia sta differenza abissale comunque, visto anche che GWT può essere eseguito in hosted mode che funziona circa come Echo2 ma con un browser apposito.

Ad ogni modo, la figata di Echo2 è che quasi tutte le classi dei componenti si chiamano esattamente come quelle di Swing, per cui del codice come questo:

Button update = new Button("Update");
update.setToolTipText("Update");
update.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
doUpdate();
}
});

Valido in Swing, è perfettamente valido anche in Echo2, a patto ovviamente di importare le classi dai package giusti.

Come in Swing, ci sono praticamente tutti i componenti GUI più comuni (e alcuni di quelli meno utili ma presenti in quasi ogni framework, tipo l'AccordionPane) e tutti hanno performances assolutamente ottime, il che è una cosa positiva visto che il pannellino di "please wait" che compare quando una richiesta AJAX ci mette troppo tempo a ricevere risposta è aberrante e neppure troppo semplice nè flessibile da customizzare.

Di fatto, quindi, Echo2 consente di realizzare applicazioni web con interfaccia grafica molto, ma proprio molto simile a quella delle applicazioni desktop, mascherando praticamente tutti gli sbattimenti della programmazione web tipo:

• Casini dovuti alla discordia tra i browser web e Internet Explorer
• Casini dovuti alla difficoltà di implementare in HTML + Javascript comportamenti standard delle GUI desktop, tipo il drag & drop
• Casini per noi sviluppatori Java alle prese con un linguaggio spesso criptico come Javascript

Oltre a tutto ciò, ha anche una serie di cazzimmine carine pensate proprio per le applicazioni web, tipo il meccanismo di server push, che è fondamentalmente una richiesta AJAX nascosta che continua a interrogare il server, dando all'utente l'impressione che sia il server ad aggiornargli il client spontaneamente anzichè su richiesta come previsto dall'HTTP, o tipo la gestione integrata del download di file sul client.

Per chi volesse lucidarsi un po' gli occhi, qui c'è la demo che fa vedere un po' tutto quello che si può fare e, ora che ci lavoro da qualche mese, mi sento in grado di dire che non è neanche esageratamente incasinata ma anzi è roba che si può rifare in pochissimo tempo.

Unico difetto non di poco conto, essendo un framework di nicchia la documentazione non è nè molta nè esaustiva (in pratica c'è solo il support forum sul sito ufficiale) e la situazione non è destinata a migliorare, visto che Echo3 è già in beta e consente di sviluppare anche direttamente in Javascript mantenendo la stessa API del Java lato server, per cui c'è il rischio che all'uscita della nuova versione la community di sviluppatori si concentri sulla parte client-only e trascuri quella Java; tuttavia, lo scope del framework è abbastanza ristretto, dato che si limita alla GUI, per cui anche lo scope di possibili problemi è piuttosto limitato.

Nuove sfide

Visto che ormai i giochi son fatti, posso dichiararlo anche qui, pubblicamente: il primo vero botto del mercato estivo sono io.

Dal mese di luglio che inizia proprio oggi, infatti, ho ufficialmente cambiato lavoro.

Guadagno (ovviamente) di più, ma come sottolinea il mio test della personalità descritto qui, quello che veramente mi importa è che sia un lavoro divertente: visto che sono qui da pochissimo, si tratta solo di prime impressioni, ma non mi pare poi così male.

Fondamentalmente, si tratta di un progettino relativamente piccolo (è in consegna il 15 di settembre) per un cliente abbastanza grosso, di cui non farò il nome, con backend in EJB+Hibernate e frontend web-based in Echo2.

Hibernate lo conoscevo già e gli EJB per ora non li ho nemmeno incrociati, mentre il primo impatto con Echo2 è stato veramente ottimo...fondamentalmente, è un framework per la generazione delle GUI in HTML/CSS/Javascript/Ajax che si programma esattamente come Swing, visto che il grosso delle classi hanno anche lo stesso nome di quelle di Swing.

Tutti i dettagli webbici della GUI, quindi - gli sbattimenti di differenze tra Explorer e i browser seri, tanto per dirne uno - sono nascosti al fortunato programmatore, che, molto a spanne e in un mondo ideale, scrive circa lo stesso codice che scriverebbe per la GUI di un client desktop stand-alone, con tanto di paradigma ad eventi per tutti gli input.

Non ci ho mai giocato, ma credo che la filosofia di Google Web Toolkit sia molto simile, e siccome della grande G mi fido credo che questa di mascherare i dettagli dell'HTML sia un'ottima strada in prospettiva futura, visto che consente ai Javisti di scrivere solo Java e di non doversi preoccupare di tutte le noie delle GUI web.

Per ora ci ho fatto solo una paginettina e magari mettendoci mano più a fondo scopro che è veramente una merda e rimpiango i tempi in cui avevo il controllo dell'HTML, ma per ora non dovermi sbattere a debuggare il javascript con Firebug o non dover fare i test con 200 browser ed Explorer (che non è un browser, ricordiamolo) mi riempie il cuore di gioia :)

Da stringa a tipo primitivo in 4 righe

Visto che l'ultimo post non era abbastanza nerd, rincaro la dose.

Problema: ho due stringhe, una delle quali mi dice di che tipo è il dato contenuto nell'altra.

Soluzione merdosa: una catena di if che considera tutti i possibili tipi ammessi e quando trova quello giusto usa il metodo parse* (Integer.parseInt, Long.parseLong, etc.) appropriato.

Schifo, duecentomila righe di codice di un'idiozia rara e noiose da estendere.

Soluzione stylish:

Class[] prototype = {String.class};
Class objClass = Class.forName(type);
Constructor ctor = objClass.getConstructor(prototype);
return ctor.newInstance(new Object[]{value});

Non solo è estremamente più elegante, ma consente di ritornare oggetti di qualunque tipo che abbia un costruttore che prende una String come parametro senza toccare il codice.

Io a fare ste cose mi ci diverto veramente tanto, lo so, sono gravemente malato e dovrei farmi internare...abbiate pietà di me.

Castor: un framework esagggerato per oggettizzare l'XML

Warning! Questo post è ad altissimo contenuto di geekiness. Se non sei un nerd di quelli veramente feroci, scappa finché sei in tempo: qui trovi sicuro modi migliori di passare il tempo.

Ora che ho allontanato un buon 90% dei possibili lettori, posso introdurre l'argomento del giorno: oggi parliamo di Castor, un framework open-source per la gestione in java di dati strutturati in maniera non-object-oriented.

Dato che il mondo pullula di framework con lo stesso scopo (addirittura credo che uno sia stato integrato nel jdk ufficiale, a partire da java 6), anziché stare a spiegare perché ho deciso di dedicare un post proprio a Castor faccio prima a raccontare come l'ho usato.

Scopo del gioco: caricare un file xml piuttosto complesso, validarlo rispetto a uno schema xsd e usare i dati in esso contenuti come configurazione per un altro pezzo di software.

Detta così pare veramente una cazzata, se non fosse che il file xml "piuttosto complesso" è roba di 6-7 livelli di tag annidati, ciascuno coi suoi attributi e contenuti: usare direttamente il DOM e imballare il codice di getElementsByTagName(), getChildren() e simili in casi complessi come questo è assolutamente impraticabile.

Servirebbe una struttura di oggetti in grado di capire la semantica di ciascun tag e che mi consenta quindi di manipolare i dati, in Java, in base al loro reale significato anzichè alla loro posizione nell'albero del DOM.

Ed è qui che entra in gioco Castor.


Step 1: si prende lo schema XSD, che descrive come deve essere fatto l'XML che vogliamo ravanare in Java, e lo si dà in pasto al task ant di Castor.

Il task ant genera automagicamente una classe Java per ogni tipo di tag XML definito nell'XSD, con tutte le proprietà e le associazioni del caso.

Esempio, poniamo di avere un XML siffatto:

<root>
<person happy="true">
<name>Raibaz</name>
<surname>Raibaz</surname>
</person>
</root>

L'ant di Castor genererà una classe Root, con un array di Person, ciascuna delle quali avrà un name, un surname e una proprietà happy.

Voila oggettificato l'XML.

Step 2: per ravanare i dati XML, la classe dell'elemento radice ha due metodi statici, marshal e unmarshal, che rispettivamente fanno da Java a XML e viceversa.

Fine.

I dati XML sono completamente mappati su oggetti Java e posso completamente dimenticarmi della loro struttura originaria e di come fare il passaggio da e verso di essa.

Tra l'altro, la generazione di codice di Castor fa anche un sacco di cose molto fiche tipo che se hai un elemento XML che può assumere solo determinati valori (chessò, nell'XSD l'hai definito usando xs:restriction), ti crea da solo l'Enumeration, a scelta se 1.4 o java 5 compliant, con tutti i possibili valori.

Pregio assoluto, non ho altre parole.

Tra l'altro mi pare che Castor faccia la stessa cosa anche coi database oltre che con l'XML, ma non ci ho giocato perchè tanto per l'ORM c'è Hibernate che basta e avanza :)

I principi chiave dell'MVC spiegati adeguatamente

Ho trovato su dzone questo post di railsenvy.com, con 4 video che spiegano un po' di linee guida da seguire implementando il pattern MVC in maniera veramente ottima, con tanto di sigla da sitcom anni 80 e, soprattutto, il personaggio chiave:

"Hi. I vaguely resemble TV's Burt Reynolds, which makes me kind of an authority."

Di seguito il video che suggerisce di mantenere il controller magro e far ingrassare a dismisura e a piacimento il model:

Stackoverflow

Quando due dei più influenti blogger che parlano di programmazione si mettono insieme per un progetto, è inevitabile che si generi almeno del gran buzz.

I due in questione sono Joel Spolsky e Jeff Atwood, aka il signor Joelonsoftware e il signor Coding horror, e il progetto è, a detta di entrambi, una risposta al problema che i programmatori non comprano più libri e scrivono in modalità 'trial-and-error', chiedendo a Google ogni volta che hanno un problema e, spesso e volentieri (questo lo so anche per esperienza personale) trovando solo altri problemi simili o siti a pagamento, ma raramente le soluzioni.

La vision di stackoverflow.com, quindi, nelle parole di Jeff Atwood che fa il CEO della cosa solo perchè Joel Spolsky è già abbastanza preso in Fog Creek Software, è questa:

Stackoverflow is sort of like the anti-experts-exchange (minus the nausea-inducing sleaze and quasi-legal search engine gaming) meets wikipedia meets programming reddit. It is by programmers, for programmers, with the ultimate intent of collectively increasing the sum total of good programming knowledge in the world. No matter what programming language you use, or what operating system you call home. Better programming is our goal.

Detta così, pare una gran figata: una community, interamente free, di shared knowledge legata alla programmazione, studiata per essere usata in modalità domanda-risposta, con in più pure un podcast settimanale delle conversazioni telefoniche dei due gestori, che è un bel valore aggiunto.

Ok, c'è anche snipplr che è molto simile (è una raccolta di snippet di codice molto 2.0 già nel nome), ma stiamo parlando di Joel Spolsky e Jeff Atwood, mica di Gino Salamella :)

PHP e Zend Studio

Si sa, il successo di un linguaggio di programmazione dipende in maniera pesantissima dagli strumenti esistenti per utilizzarlo: l'intero sistema .NET si poggia su quel gioiello che è Visual Studio, il successo di Java è dovuto in gran parte anche alla fioritura di ottimi IDE (su tutti Eclipse, ma anche IntelliJ IDEA, NetBeans e qualche altro), etc., etc.

Finora mi era capitato di lavorare in php, ma solo per qualche progettino universitario o poco più complesso, o per fare un po' di manutenzione su siti Joomla-based, per cui non avevo mai sentito il bisogno di un IDE e mi ero sempre accontentato del mio editor di testo preferito (che per inciso è questo: ve lo consiglio, è leggerissimo, fa il syntax highlighting di qualunque cosa al mondo e ha un sacco di funzioncine interessanti).

In questi ultimi giorni, nel tempo "libero", sto lavorando a un progettino, sempre di dimensioni contenute, ma meno, per cui ho deciso di fare il salto e procurarmi l'IDE che costituisce lo standard de facto per PHP: Zend Studio.

Devo dire che mi ha veramente stupito: finora avevo sempre considerato PHP un linguaggio abbastanza fuffa, buono giusto per un paio di scriptini semplici e pronissimo a tutte le cattive pratiche di programmazione del mondo, e grazie a Zend ho cambiato almeno la prima delle due idee...grazie a un autocompletamento veramente succoso e rapido, infatti, lo sviluppo diventa estremamente più snello, consentendo di rendere i propri siti belli complessi in tempi abbastanza contenuti; inoltre è molto ben documentato e offre la propria documentazione anche in maniera "proattiva", coi tips of the day, per cui devo dire che negli ultimi 2-3 giorni ho scalato la curva di apprendimento di PHP in maniera vertiginosa.

Certo, PHP è sempre un linguaggio procedurale (lo so che gli hanno chiavato dentro l'OOP a forza, ma è evidentemente uno stupro, dato che io, che pure non riesco a non "pensare" object-oriented, in PHP riesco solo a programmare procedurale), con tutti gli svantaggi che ne conseguono, primo fra tutti la spaghettificazione quasi istantanea del codice: io faccio veramente una fatica boia a leggerlo, anche quando è scritto da chi dovrebbe saperne mooolto più di me e dovrebbe aver scritto specificatamente per far modificare il proprio codice da altri, come nel caso di Joomla..cmq, grazie all'autocompletamento e al ctrl+click di Zend, seguire il flusso del codice è un pò meno un pain in the ass, il che è già veramente una grandissima cosa.

Adesso che la logica del mio progetto è praticamente finita (e che quindi ho finito di smanullare la parte di Zend legata all'editing di codice e il suo ottimo client SQL), mi resta da vedere come si comporta coi CSS e le cazzimme di presentazione, ma se è valido solo metà di quanto merita nella scrittura del codice direi che siamo definitivamente diventati amici.

Filtrare un report Access per l'esportazione

Ok, visto che finora qui su questo blog non ho fatto poi molto il nerd, è il caso di recuperare un po'...ma neanche troppo, visto che Access e VBA non sono roba da veri programmatori.

Comunque, oggi ho sfarfugliato un po' per un progetto a cui sto lavorando, e la soluzione che ho trovato è abbastanza interessante e tricky, per cui ho deciso di condividerla.

L'obiettivo è "ho un db Access, vorrei un file di Word per ciascun record che appare in un form con una lettera da mandare a ciascuno dei record stessi (che rappresentano dei clienti)"

Access, molto gentilmente, ha la macro built-in DoCmd.OutputTo che consente di esportare qualsiasi cazzimma, sia essa report, tabella, form o che altro su file Xls, Rtf, Html o Txt; capita a fagiuolo per esportare un report costruito ad-hoc in Rtf, per poterlo poi editare in Word, stamparlo e/o mandarlo per email (oltretutto Rtf è pure open standard, che è cosa buona e giusta).

Quindi, morale, aggiungo nel form un pulsante che faccia DoCmd.OutputTo blablabla per salvarmi su file il mio report (oltretutto Access, nel wizard dei pulsanti, ha pure quello per fare l'esportazione su file di un report, segno che è, effettivamente, un'operazione comune)...ma....problema!

Clicco sul mio meraviglioso pulsante nuovo, e il report non è filtrato, mi mostra tutti i record della tabella anzichè solo quelli che comparivano nel form.

Come risolvere? La soluzione, come vi avevo anticipato, è abbastanza tricky, non è l'apice dell'eleganza nè della manutenibilità, ma pare essere l'unica per filtrare un report prima di esportarlo con DoCmd.OutputTo.

In sostanza, bisogna creare una query fasulla, anche vuota, e settarla come origine dati del report; dopodichè, a runtime, bisognerà iniettare l'SQL desiderato nella query stessa:

Dim qd As DAO.QueryDef
Set qd = CurrentDb.QueryDefs("QueryTestReport")
qd.SQL = "Select * from persona where id_persona = " & idPersona

Dove, ovviamente, "QueryTestReport" è il nome della query dummy che usiamo per popolare il report.
In questo modo, posso popolare il report con dell'SQL arbitrario, settandogli la where clause come più mi pare e piace e filtrando quindi il report in base ai parametri che mi fanno comodo.

A questo punto, però, mi serve anche di aggiungere la logica che esporta un report separato per ciascuna riga del form...come si fa: a sto giro è abbastanza banale, visto che il form stesso consente di accedere al proprio RecordSet, sia per riferimento che per copia, banalmente con

Dim rs As Recordset
Set rs = Me.RecordsetClone

Posso quindi looparmi tutto il recordset (while not rs.EOF) e prendere le proprietà di ciascuna riga (rs("id_persona")), per usarle nel processo di esportazione del report.

Et voilà :)

Deliri di onnipotenza

Credo che solo i più nerd tra i miei lettori possano immaginare l'enorme sensazione di onnipotenza che si prova quando si risolve un bug pesante dopo un buon paio d'ore di coding feroce...mi vien voglia di togliermi la maglietta e correre per l'ufficio gridando "SONO INVINCIBILE!", ma credo che mi tratterrò sfogando la mia gioia qui sul blog :D

(Per inciso, l'architettura del sistema su cui sto lavorando fa tanto schifo per la gestione del frontend quanto invece è scaltra per la gestione del passaggio dei parametri alle query dei metodi di backend...evidentemente le due parti sono frutto di due menti diverse, anche se hanno in comune la totale assenza di uno straccio di documentazione, che rende la curva di apprendimento per i newcomers come me qualcosa di assassino...ma tanto io oggi sono invincibileeeeeeeeeeeeeeeeeeeeeeeeeeeeeee!! :D)