giovedì 8 novembre 2007

Alla ricerca del Santo Graal - Reprise

Riprendo un argomento che mi interessa molto, e su cui sto facendo un bel pò di ricerche. Chiunque usi Java per realizzare applicazioni web vi dirà che attualmente non esiste Lo Strumento. Esistono decine (sul serio) di framework, e anche filtrando per stabilità, supporto e dimensioni della comunità ne rimangono almeno una decina: Struts, Struts 2 (che è molto diverso), Stripes, RIFE, Click, Tapestry, Echo2, Thinwire, Grails, GWT, ZK, Sitemesh, Cocoon, JSF e sicuramente ne sto dimenticando qualche altro.

Leggendo un pò, ho capito che esistono principalmente due modelli: il classico, celebre, inossidabile MVC (o Model 2) detto anche Action Oriented e il Page Oriented/Component Oriented.
Il commento a una domanda postata su TheServerSide è una dei migliori e più precisi riassunti che abbia letto su questo argomento.

Io paragono il modello MVC a un approccio procedurale del problema: si individuano i flussi dei dati e si realizzano, nei controller, i metodi che li eseguono. Magari poi il modello, i controller eccetera sono realizzati col paradigma OO, però il flusso dell'applicazione è governato dalle action, ovvero da procedure in senso lato.
Il modello Page/Component Oriented invece lo paragono ad un approccio ad oggetti: ogni pagina web è un'oggetto, ha dei metodi ed è essa stessa a governare l'applicazione in base ai metodi invocati (attraverso l'URL).
E la differenza, a mio parere, è analoga a quella tra i due paradigmi di programmazione: il modello MVC (procedurale) è immediato da capire e da imparare, si comporta bene quando l'applicazione è governata da flussi di dati (per esempio l'acquisto di un e-ticket), ma mostra i suoi limiti all'aumentare della complessità del problema. Ad un certo punto diventa ingovernabile.
Il modello Page Oriented, come l'OOP, invece è arduo da governare, richiede una revisione dei processi mentali con cui immaginiamo la soluzione a un problema, però paga sul lungo periodo. Supponiamo di avere un'applicazione ricca di dati, annidati, con diversi casi particolari in base alle configurazioni di questi. Il modello Page Oriented è sicuramente il migliore perchè è un divide and conquere più efficace.
Ho scelto essenzialmente quattro framework che applicano questi due modelli:
  • Grails e Stripes sono action framework
  • Click e Wicket sono Page/Component Oriented
Gli altri non li esclusi perchè siano peggiori, tutt'altro. RIFE, Tapestry, Thinwire, sono anche migliori.
Ma io sono pigro :-)
Di conseguenza voglio strumenti agili, immediati per le cose immediate e capaci in ogni caso di reggere l'aumento di complessità in maniera lineare. RIFE, per esempio, è strepitoso ma date un'occhiata all'esempio del blog. Ad un certo punto non si capisce più nulla, anche se la sensazione è che l'autore abbia sbagliato approccio educativo.

Grails e Stripes sono invece degli ottimi esempi di comunicazione: c'è un approccio graduale alle caratteristiche, molti esempi, molti approfondimenti ben scritti. La sensazione che si ha è che le cose funzionino bene perchè l'idea alla base è semplice e pratica.

Di Click avevo parlato male, ma faccio pubblica ammenda. Utilizzando HTML puro e Velocity, la produttività è enorme. Si può buttare giù un'applicazione mentre ancora si sta imparando il framework.
Il sito è stracolmo di esempi, ben fatti, la documentazione è limpida.

Wicket alle prime stranisce. Sembra quasi che gli autori chiedano un atto di fede a chi vuole iniziare, lasciandolo completamente in balìa del framework. Non rimane che andarsi a guardare gli esempi.
Ma dopo un pò si capisce che il pargolo promette bene. L'approccio è il più puro che abbia mai visto, non una traccia di logica nella presentazione, non una traccia di presentazione nella logica.
Però è facile mettere in piedi la prima applicazione. Non facile quanto Click, ma abbastanza facile.
Andando avanti, si trovano esempi in abbondanza (qui c'è un bel pò di roba). L'unico difetto è la necessità di dovere associare una classe Java a una pagina Web per qualsiasi cosa, fosse pure un semplice messaggio di notifica.

E' stupido ribadirlo, ma non c'è e non può esserci il framework web Java. La scelta dipende innanzitutto dal problema da affrontare, e conseguente scelta dell'approccio (action/component). All'interno dei due possibili, ci sono diverse soluzioni e, per esempio, non opterei Click per una webmail Ajax-based, così come non userei Wicket per il portale dell'agenzia di viaggi.
Grails copre molte esigenze, ma se esiste già del codice Java da usare o se si prevede di interfacciarlo con altre applicazioni in Java, diventa un problema. E' possibile sicuramente, ma si perdono molti dei vantaggi nell'usare Groovy.
Stripes invece sarebbe più adatto, ma se non si hanno questi vincoli è meno "divertente".

Spero comunque che questo post aiuti perlomeno a sfoltire la rosa di scelte. In ogni caso, la discussione è aperta :-)

6 commenti:

Francesco Pasqualin ha detto...

Penso che ormai Ajax sia una caratterstica irrinuciabile e quindi e' irrinunciabile GWT, che non e' un framework.
La ricerca va indirizzata ai framework che supportano GWT.
Al momento quelli che lo supportano lo fanno a livello basic...

Pietro Bonanno ha detto...

Sono d'accordo in parte. Ajax è anche una caratteristica irrinunciabile, ma perchè GWT? Esistono ZK, Echo2, wingS che fanno un buon lavoro nella categoria rich client.
Invece, per citare uno dei miei preferiti, Grails rientra nel classico genere pagine dinamiche + Ajax, ma l'integrazione è pulita e permette di aggiungere solo quel tanto di Ajax che basta.

Non parliamo poi di Eclipse RCP che porta con poco sforzo un'app desktop sul web.

Infine esiste anche la via "tutto nel cesso e ricominciamo" che è seguita da Microsoft, Adobe e Sun quindi un qualche futuro potrebbe averlo :-)

A me, che interessa di + il genere web application data-driven, GWT piace, tanto che ne vorrei studiare le possibilità assieme a Spring MVC (tramite GWT Handler), gwthibernate e Metawidget magari tutto pilotato da Maven.
Potrebbe anche essere Il Framework Definitivo :-)

Direi cmq che la via da seguire non è ancora talmente chiara.

BTW perchè GWT non è un framework? Google stessa dice "Google Web Toolkit (GWT) is an open source Java development framework that lets you [ecc ecc]".

Francesco Pasqualini ha detto...

Ciao,
perche' GWT ?
be' mi pare sia la libreria Ajax con il futuro più roseo (google powered).... mipare.

Concordo su Grails,attualmente ho optato per GWT + Grails.
Anche se devo dire Groovy e' stata un po' una delusione. (documentazione carente, bachi e syntax sugar non così dolce come vorrei, ma posso sbagliarmi sono agli inizi)

Dicevo GWT non e' un framework perchè per il momento fornisce solo l'infrastruttura Ajax.
Nessuna funzione MVC, persistenza, scaffholding, validation, sicurezza, ecc. ecc.

Francesco Pasqualini ha detto...

dimenticavo
Optato precisamente per GWT+Grails+GetExt
http://www.gwt-ext.com/demo/

ciao

Pietro Bonanno ha detto...

Sì, penso anch'io che GWT abbia un futuro garantito dal supporto di Google, ma la sua vera garanzia saranno le applicazioni sviluppate. Qui si vedrà se l'approccio di Google farà breccia nei cuori degli sviluppatori. Certo, GMail e tutte le applicazioni Google sono già un discreto biglietto da visita :-)

GWT+Grails sarebbe interessante, non ho capito quanto il plugin è integrato con il MVC di Grails.
GWTHandler con Spring MVC mi è sembrato interessante perchè porta GWT all'interno dei controller, quindi un MVC vero e proprio.
Unito poi a gwthibernate, Ext GWT (o GWT Ext? :) ), e Metawidget sembra spaccare.

Ciao

Pietro Bonanno ha detto...

Groovy effettivamente ogni tanto sembra un pò "legnoso" nel suo tentativo di miscelare l'agilità di Ruby e il rgore di Java. Io ho letto "Groovy in Action" e penso che sia un buon testo per conoscere Groovy con quel pizzico di approfondimento che negli articoli sui linguaggi dinamici in genere viene trascurato.
Però ci ho programmato pochissimo, magari mi sbaglio.