Java Server Faces O Reilly Cap 2 a 5

Cap 2

2.3

- in faces-config.xml lo scope session indica che un unica istanza è creata per ogni utente e rimane disponibile finchè l'utente utilizza attivamente l'applicazione
<managed-bean-scope>session</managed-bean-scope>

- qui viene inizializata la proprietà subscriber con il valore subscr che è l'identificativo dell'altra classe
<managed-property>
<property-name>subscriber</property-name>
<value>#{subscr}</value>
</managed-property>

2.4 (rianalizzare la parte scritta sotto)

- quando l'elemento <h:textInput> viene processato il componente corrispondente UIInput è creato e "limitato alla proprietà specificata del bean". Viene valutata l'espressione di binding e se il bean non esiste JSF lo crea basandosi sulle informazioni del file faces-config.xml .
- Quando l'utente inserisce i valori nel form e clicca nel bottone di submit, JSF processa la richiesta chiedendo ad ogni componente di prendere il proprio valore dalla richiesta

4 capitolo saltato

5 capitolo

+5.3
+++5.3.1
- Perchè la pagina che viene scelta è una jsp e non una semplice pagina html?
- Le specifiche dicono che il web container deve mandare la pagina di login ma possono decidere loro come mandare una pagina. Il web container può mandare una richiesta di redirect con una url che matcha alla pagina di login oppure può restituire al browser la pagina di login direttamente. Quale metodo viene usato fa una grande differenza quando
si tratta di riferimenti ad altre risorse come un riferimento a un css o a una img o link ad altre pagine.
- Se il container usa un redirect il browser fa una nuova richiesta e risolve i relativi riferimenti nella pagina restituita come url relativi alla pagina di login. Questo è quello che la maggior parte delle persone si aspettano, così quando l'approccio di redirezione è usato tipicamente non ci sono sorprese. Se il container restituisce la pagina direttamente il browser risolve i riferimenti relativi nella pagina come URL per risorse protette è la sola url che conosce. Così se la url protetta è /jsfbook/expense/reports.faces e la pagina di login include come url relativa style.css, il browser prova a caricare /jsfbook/expense/style.css . A meno che non siate a conoscenza di questo piccolo cavillo si possono perdere molte ore per capire perchè la pagina non viene trovata.
- La soluzione è usare sempre path assoluti per le risorse referenziate dalla pagina di login e dalla pagina di errore. I percorsi assoluti funzionano non importa come il container restituisce le pagine. L'approcio migliore proposto è usare path assoluti ma con le espressioni EL come mostrato negli esempi.

5.3.2 Controlling Access to Web Resources

- nel file web.xml ci sono le informazioni per gestire l'autenticazione
- <security-constraint> è l'elemento che definisce le risorse da proteggere e definisce gli utenti che hanno accesso alle risorse
- <web-resource-collection> contiene una <web-resource-name> un elemento che associa un set di risorse definiti da <url-pattern> che associa la risorsa da proteggere. Si possono usare più <url-pattern> in una <web-resource-collection> e agiungere <http-method> , per esempio discriminando in maniera diversa la get e la post (Appendice F) per maggiori dettagli.
- <auth-constraint> contiene <role-name> che dichiara i ruoli che un utente deve avere associato per accedere alla risorsa.
- Un ruolo usato nell'applicazione deve anche essere definito in <security-role>
- le associazioni utente password e ruoli vanno in tomcat-users.xml

Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License