Corso JSF Java Server Faces Mauro Sanfilippo 02/09/2010

Contenuto del corso Introduzione alle JSF Esercitazione (guidata dal docente) Questionario Esercizio (individuale)

JSF Framework per la creazione di web app Java Evoluzione naturale delle JSP Oggi alla versione 2.0 (JSR 314) incluso e supportato dai principali appserver e IDE Basato su standard Supportato da Sun, IBM, Oracle

Servlet e JSP

Servlet e JSP Problemi: Gestione "manuale" della request Nessun aiuto nella navigazione e nella validazione Poco OO: si lavora con le stringhe Vantaggi: Controllo più fine

Da JSP a JSF Idea: la pagina è un insieme di oggetti Java, che chiamiamo componenti i componenti sono definiti in un file xml tutte le chiamate sono intercettate da una sola servlet (Faces Servlet), che crea la struttura dati Java che rappresenta l'albero di componenti (View) i componenti sono contenitori di dati agganciati a classi create dallo sviluppatore alla fine della request la view viene renderizzata in HTML

Le pagine JSF Una pagina JSF è un file XML (solitamente suffisso XHTML) contenente codice HTML e tag JSF, che definisce un albero di componenti

Managed Bean Ogni pagina ha a disposizione oggetti Java creati dall'utente e gestiti (managed) dal framework Tramite l'Expression Language i componenti JSF vengono "legati" ai metodi del managed bean   metodi Getter e Setter metodi Action Dipendono dal componente metodi Listener Diversa firma metodi Validator

Fasi Ogni Faces Request genera l'esecuzione di una procedura divisa in 6 fasi: Restore View: viene ricreato l'albero dei componenti Apply Req Values: viene letta la request e impostati i valori passati nei componenti Process Validations: i valori impostati nei componenti vengono controllati (convertiti da stringhe (parametri request!) a oggetti Java e validati) Update Model Values: i valori validi vengono passati ai setter del managed bean (model) Invoke Application: vengono chiamate le azioni dei managed bean e/o viene definita la prossima pagina da renderizzare Render Response: viene generato la nuova view e viene renderizzata in HTML

Risorse: http://wiki.smeup.com  ricerca: "Corso JSF" Learning by examples Creiamo in 9 step un'applicazione via via sempre più complicata per imparare la basi delle JSF Applicazione CRUD Utilizzeremo le JSF 2.0 Risorse: http://wiki.smeup.com  ricerca: "Corso JSF"

Nuovo progetto Netbeans: Nuovo Progetto  Java Web  …  selezionare il framework JSF Eclipse: Dynamic Web Project con Target Runtime Glassfish v3 Java EE 6

Struttura dell'applicazione JSF 2.0 Nel Web Content: views: le pagine della nostra applicazione sections: le porzioni di pagina  inclusione resources: immagini, css, javascript e altre risorse Attenzione: il framework, per default, utilizzerà “resources” come insieme di librerie di risorse

Navigazione Navigazione JSF = passaggio da una view a un’altra In JSF 1 la navigazione è impostata in faces-config.xml <faces-config> <navigation-rule> <from-view-id>*</from-view-id> <navigation-case> <from-outcome>risultato</from-outcome> <to-view-id>pagine/res.xhtml</to-view-id> </navigation-case> </navigation-rule> </faces-config> E quindi: <h:commandButton action="risultato" value="Conferma"/>

Navigazione (2) In JSF 2.0 la navigazione è semplificata: outcome<=>percorso della pagina (esclusa l'estensione) from-view-id<=> * Quindi non serve specificare nulla in faces-config: <h:commandButton action="pagine/res" value="Conferma"/>

Composizione e templating JSF 2.0 include il motore di templating Facelets, che permette la composizione di pagine in due modalità: 1. templating => "ereditarietà" 2. inclusione

Managed Bean e scope @ManagedBean dichiara che la classe deve essere "gestita" dalla JSF l'oggetto diventa utilizzabile nella pagine XMTML per nome ListController => #{listController} @RequestScoped  istanziato e distrutto ad ogni request @SessionScoped  mantenuto in session, stessa istanza per ogni request di quella sessione @ApplicationScoped  stessa istanza per ogni sessione

Composizione <ui:include>  migliore organizzazione, riuso, incapsulamento, parametrizzazione

I componenti JSF Oggetti Java che implementano le interfacce del framework (UIComponent e sub) Si renderizzano in "pezzi" di html + javascript + risorse Possibile creare i propri, quindi possibile usare quelli fatti da altri: basta includere un JAR (opportunamente creato) Sostanzialmente tre tipologie: INPUT  metodi setter e getter del MB OUTPUT  metodi getter ACTION  metodi action (ma anche getter e setter)

Converter Le JSF oggettificano Esistono convertitori automatici non dichiarati (String, Long, Int, BigDecimal, Date, ecc ) Possono essere creati convertitori custom: Da String (HTML/Parametro request) a Object Da object a String @FacesConverter(forClass=Camera.class) public class CameraConverter implements Converter L'interfaccia Converter obbliga a implementare i metodi getAsString getAsObject  Se la conversione va male  throw new ConverterException(…)  catturata e gestita dal framework

Validators Classi e/o metodi del MB che validano gli oggetti (già convertiti) passati come input dalla pagina Validatori built-in: <f:validateLongRange minimum="1" maximum="5"/> Validatori custom: @FacesValidator (value="validaEmail“) public class ValidaEmail implements Validator   Nella pagina: <f:validator validatorId="validaEmail"/>

Messaggi <f:messages>  messaggi multipli In JSF i messaggi agli utenti sono gestiti dal framework, attraverso l'oggetto FacesContext:   FacesContext.getCurrentInstance().addMessage( null, //null=nessun componente-> messaggio "GLOBALE" new FacesMessage("Errore") ); "input_email", //id componenti-> messaggio del componente Convertitori e validatori lanciano messaggi legati ai componenti a cui sono agganciati. I messaggi vengono visualizzati nella pagina in corrispondenza dei componenti <f:messages>  messaggi multipli <f:message for="input_email">  un singolo messaggio, relativo a un componente

Problemi comuni Equals Utilizzo dei componenti "select" e dei loro convertitori Date Scope Request

Conclusione Vantaggi: tutto più OO validazione eventi Svantaggi: performance potenzialmente più scadenti debugging complicato minor controllo

Argomenti non trattati Ajax Altri scope (solo CDI) <f:event> …