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:
1.
la pagina è un insieme di oggetti Java, che chiamiamo componenti
2.
i componenti sono definiti in un file xml
3.
tutte le chiamate sono intercettate da una sola servlet (Faces Servlet), che crea la struttura dati Java
che rappresenta l'albero di componenti (View)
4.
i componenti sono contenitori di dati agganciati a classi create dallo sviluppatore
5.
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:
1. Restore View: viene ricreato l'albero dei componenti
2. Apply Req Values: viene letta la request e impostati i valori passati nei componenti
3. Process Validations: i valori impostati nei componenti vengono controllati (convertiti
da stringhe (parametri request!) a oggetti Java e validati)
4. Update Model Values: i valori validi vengono passati ai setter del managed bean
(model)
5. Invoke Application: vengono chiamate le azioni dei managed bean e/o viene definita
la prossima pagina da renderizzare
6. Render Response: viene generato la nuova view e viene renderizzata in HTML
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:
1. outcome<=>percorso della pagina (esclusa
l'estensione)
2. 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
o
o
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:
o INPUT

metodi setter e getter del MB
o OUTPUT

metodi getter
o 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:
1. Da String (HTML/Parametro request) a Object
2. Da object a String
@FacesConverter(forClass=Camera.class)
public class CameraConverter implements Converter
•
•
L'interfaccia Converter obbliga a implementare i metodi
o
getAsString
o
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
•
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")
);
FacesContext.getCurrentInstance().addMessage(
"input_email", //id componenti-> messaggio del componente
new FacesMessage("Errore")
);
•
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
convertitori
• Date
• Scope Request
"select"
e
dei
loro
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>
• …