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.

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 :)