Il JSF 2.0 Expert Group ha rilasciato la versione Early Draft delle specifiche della nuova release di JavaServer Faces. In questo articolo esaminiamo quelle che a prima vista sembrano le novità di maggiore interesse che potranno far parte della specifica finale

Introduzione

JavaServer Faces sin dal primo rilascio sta lentamente prendendo piede nella comunità di sviluppatori di applicazioni web Java EE. Nonostante le numerose lacune delle prime versioni, JSF costituisce un tentativo di standardizzare lo sviluppo web nel mondo Java EE mediante un modello architetturale a componenti e per eventi molto flessibile e solido.

JSF ha già portato un notevole cambiamento nel mondo Java EE caratterizzato da numerosi MVC framework ognuno con le sue specificità. La tendenza alla standardizzazione è perseguibile qualora il framework proposto come standard abbia tutte le caratteristiche che lo rendono gradito agli sviluppatori di applicazioni e ai vari vendor, in quanto i primi difficilmente abbandonerebbero le proprie abitudini consolidate e i propri strumenti ormai noti e affidabili per una strada incognita e i secondi difficilmente sposerebbero una tecnologia di scarso successo e futuro.

Con le richieste di modifiche proposte nella nuova specifica sembra che JSF stia prendendo davvero una strada interessante che potrà farne il modello unico di riferimento per lo sviluppo web Java EE nel prossimo futuro. Andando alla pagina

http://jcp.org/en/jsr/detail?id=314

è possibile scaricare la specifica JSR-314 JavaServer Faces 2.0 Early Access e farsi un‘idea delle modifiche e delle novità che si stanno definendo e che potranno entrare a far parte della specifica finale. Da una prima lettura, il lavoro da fare sembra ancora notevole visto che molte delle richieste di modifica non compaiono ancora nella specifica; e c‘è sempre da ricordare che comunque ci potranno essere cambiamenti a quanto pubblicato fino alla definizione della proposta finale di specifica.

La nuova specifica si muove su alcune direttrici frutto delle richieste fatte dalla comunità e delle esperienze tratte da altri progetti. In particolare, le numerose richieste sono state suddivise in alcuni filoni principali come di seguito elencato:

• semplicità di sviluppo
• estensione del framework con nuove caratteristiche
• performance
• stimolo all‘adozione della tecnologia

Molte delle richieste non sono altro che caratteristiche vincenti prese da progetti come Seam, Ajax4JSF, Shale, Facelets, ADF ed altri. Questa a mio parere è una cosa positiva e non un demerito in quanto è mettendo insieme le caratteristiche migliori dei vari progetti che si può arrivare ad una specifica ricca che copra nel miglior modo tutte le esigenze.

Nei prossimi paragrafi cercheremo di analizzare brevemente alcuni aspetti che si evincono dal draft; a livello macro si possono individuare alcune tendenze principali che sembrano indicare la direzione futura di JSF:

• integrazione sempre più stretta con Ajax, con la definizione di una Ajax Javascript API per l‘interazione con JSF;
• tendenza allo sviluppo di un modello client-centrico di gestione degli eventi intra-pagina;
• minimizzazione delle configurazioni XML e tendenza all‘utilizzo delle annotazioni;
• semplificazione dello sviluppo di componenti custom;
• strumento per lo “skinning” e il “themeing” dei componenti;
• integrazione standard con Facelets.

Non è nello scopo di questo articolo esaminare riga per riga la nuova specifica e spiegarne ogni dettaglio, ma vogliamo piuttosto cercare di mettere in luce alcuni aspetti interessanti ed individuare quelle che sembrano essere le tendenze future di JSF. C‘è sempre poi da tenere presente che molte cose potranno cambiare nella proposta finale e che alcune delle richieste di modifica potrebbero anche non essere standardizzate e quindi potrebbero restare escluse dalla versione finale.

Semplicità di sviluppo

La produttività e la semplicità nello sviluppo è uno dei fattori cardine per il successo di un framework, a maggior ragione in un‘area nella quale ne sono presenti già numerosissimi, alcuni dei quali ormai di largo uso e ampiamente consolidati pur con tutti i loro difetti. Un cambiamento nell‘utilizzo dei propri strumenti di sviluppo ha senso solo se il nuovo modello garantisce, oltre che affidabilità e stabilità, anche la massima produttività.

In ambito Java EE la semplicità e rapidità nello sviluppo delle applicazioni è sempre stato indicato come uno dei principali ambiti di miglioramento ed è sempre stato uno dei punti per i quali Java EE ha ricevuto il maggior numero di critiche dai suoi detrattori. Tra le richieste che la nuova specifica si propone di indirizzare ci sono diversi importanti aspetti che riguardano questo tema:

• semplificazione dello sviluppo di componenti;
• possibilità di usare le annotazioni per dichiarare i vari componenti JSF per arrivare ad un‘applicazione con il minimo di file XML di configurazione;
• fornire un meccanismo standard di gestione delle eccezioni;
• possibilità di indicare al runtime del farmework lo stadio in cui si trova l‘applicazione, sviluppo, test , produzione in modo che esso possa comportarsi di conseguenza a seconda delle esigenze;
• possibilità di utilizzo di tecnologie consolidate per il templating delle viste.

Scorrendo la versione attuale si nota che molte delle richieste non sono state ancora esplicitate nella nuova specifica. Il Capitolo 10 non ancora completamente sviluppato è quello dedicato all‘integrazione con Facelets, una delle novità più importanti, che introduce nella specifica la possibilità di utilizzare le caratteristiche di templating e di composizione di componenti di Facelets. Facelets diventerà così parte dello standard Java EE.

Altra cosa interessante che già compare nella specifica è la definizione della proprietà ProjectStage. Questa proprietà può assumere uno tra i valori “Development”, “UnitTest”, “SystemTest”, o “Production”, valori costanti della classe javax.faces.application.ProjectStage. Il valore può essere configurato mediante un context init-parameter come segue:

    javax.faces.PROJECT_STAGE
    Development

A runtime, il valore configurato può essere acquisito dall‘oggetto Application invocando il metodo Application.getProjectStage(). L‘idea è molto interessante ed è quella di condizionare il comportamento dell‘applicazione a seconda dello stadio dello sviluppo della stessa. Ciò può consentire di attivare messaggi di errore, controlli o altre funzionalità solo nello stadio di sviluppo desiderato a scopo di testing e validazione.

Altra interessante novità è quella riportata al paragrafo 5.4 che parla dell‘utilizzo delle annotazioni nei Managed Beans. Interessanti ad esempio la @PostConstruct, che serve a marcare un metodo che deve andare in esecuzione dopo che il container ha eseguito l‘iniezione delle risorse ma prima che il bean sia memorizzato nello scope, così come la @PreDestroy che marca un metodo che va in esecuzione prima che il bean sia eliminato dallo scope o che lo scope stesso venga distrutto.

Nuove caratteristiche

In questa area sono molte le richieste di modifiche pervenute all‘Expert Group, molte delle quali scaturite dall‘esperienza in altri progetti paralleli a JSF. Molto importante è sicuramente l‘integrazione con Ajax di cui si parla al capitolo 13. La specifica si propone di definire la API JavaScript che rende disponibile allo sviluppatore di JSF le potenzialità di Ajax e gli consente di iniziare richieste Ajax al framework. Vengono inoltre descritti alcuni interessanti use-case quali “Partial Tree Traversal” e “Partial Page Update”. Molto interessante è la possibilità di visitare un particolare nodo del tree e di eseguire l‘elaborazione a partire da una richiesta fatta dal client con Ajax. Altrettanto interessante è la possibilità di aggiornare singole porzioni di pagina lato client, cosa già possibile e mutuata dai componenti ADF Faces. Queste caratteristiche ancora non del tutto specificate fanno capire come l‘integrazione tra Ajax e JSF sia uno dei filoni chiave per l‘evoluzione del framework.

Altra interessante caratteristica è riportata nel capitolo 12 e si tratta della separazione logica del ciclo di vita di elaborazione delle richieste in due fasi distinte, quella di esecuzione e quella di renderizzazione. Questa suddivisione logica renderà molto più semplice la gestione del ciclo di vita JSF in ambito portlet, uno dei filoni di maggiore sviluppo nel mondo Java EE.

Altra novità è l‘introduzione di uno standard nella gestione delle risorse dell‘applicazione, dove per risorse si intendono tutti quegli artifact di cui un componente ha bisogno quali file CSS, JavaScript, immagini etc. La nuova versione di JSF definisce un packaging standard per queste risorse, cosa inesistente nelle precedenti release. Il framework individuerà le risorse in due percorsi standard:

• /resources: in questa cartella al di sotto della root dell‘applicazione saranno presenti le risorse della web application
• /META-INF/resources: questa cartella rappresenta le risorse nel classpath

La specifica definisce inoltre un meccanismo standard per l‘individuazione delle risorse che comprende anche un numero di versione, il che consente , cosa davvero interessante, di aggiornare la versione di una risorsa a run-time senza dover effettuare nuovamente il deploy o riavviare l‘applicazione.

Performance

Uno dei punti fondamentali per l‘adozione di una tecnologia è sicuramente l‘aspetto delle prestazioni che assume un ruolo chiave tanto più in ambito web nel quale si richiedono applicazioni sempre più complesse, dall‘interfaccia ricca e comunque molto performanti. Alcune delle richieste di modifiche alla specifica riguardano proprio questo importantissimo ambito:

• possibilità di non restorare ogni volta l‘intero stato di un tree ma solo i “delta” necessari;
• avere un controller “client-side” che sia in grado di gestire la gran parte degli eventi intra-pagina ed evitare così i round-trip con il server;
• migliorare la gestione del PhaseListener in modo che lo sviluppatore possa controllare in modo preciso quali richieste debbano essere elaborate dal Listener.

È difficile dire allo stato del lavoro quale sia il reale impatto della nuova versione sulle performance di JSF, per cui ci riserviamo di approfondire il tema in un prossimo futuro quando la specifica sarà giunta ad uno stato di maturazione più avanzato.

Adozione della tecnologia

Uno degli scopi del miglioramento nelle specifiche di una tecnologia è anche quello di rendere la stessa sempre più attraente e di stimolarne quindi l‘adozione. Per JSF che si propone di diventare il modello di riferimento per lo sviluppo web Java EE questo è un aspetto molto importante. Diverse richieste di modifica alla specifica sono definite come appartenenti a questo ambito, anche se, a dire il vero, qualsiasi modifica migliorativa potrebbe classificarsi in questo senso.

Tra le richieste di modifica si possono ricordare le seguenti:

• Consentire l‘uso di alcune caratteristiche di JSF anche in applicazioni che non usano JSF in toto. Ad esempio la definizione dei managed-bean potrebbe risultare utile anche in applicazioni che utilizzano esclusivamente servlet.
• Facilitare l‘implementazione di funzionalità lato client quali drag&drop pensando ad un ciclo di vita “client-side”.
• Stabilire una modalità standard di definizione per “skin” e temi dei componenti
• Miglioramento della specifica dei componenti per facilitare l‘integrazione con librerie di componenti di terze parti.
• Consentire alle applicazioni JSF di essere accedute via REST.

Tutte le richieste sono relative a miglioramenti molto interessanti e promettenti: bisognerà ovviamente attendere la specifica finale per capire a che risultato il gruppo di esperti riuscirà ad arrivare.

Conclusioni

Con questo articolo si è tentato non tanto di descrivere nel dettaglio ogni singolo paragrafo della nuova specifica JSF, che tra l‘altro è solo in versione Early Draft e quindi potrà subire numerosissimi cambiamenti, ma si è cercato piuttosto di far intuire che strada stia prendendo il framework e cosa ci si possa aspettare da questo nel prossimo futuro. La trattazione è sicuramente incompleta e osservazioni più precise sulla nuova versione di JSF si potranno fare solo quando sarà disponibile la proposta finale della specifica.

Sicuramente però si può già dire che la versione 2.0 sarà un grosso salto in avanti rispetto alle versioni precedenti in quanto introdurrà nello standard numerose caratteristiche ed esperienze fatte in altri progetti di grande successo. Basti pensare a Facelets o a Shale, ad ASF o Ajax4JSF per citarne alcuni. Mettere a fattor comune gli sforzi e le innovazioni portate in questi e altri progetti non può che essere la strada giusta per arrivare alla definizione di una specifica ricca, solida e che potrà coprire e soddisfare le esigenze di una platea sempre più vasta di utilizzatori.

Riferimenti

[1] E. Burns – R. Kitain, “JavaServer Faces Specification. Version 2.0. Early Draft Review”