Java Server Faces O Reilly Cap 8

Chapter 8. Handling Events

- il modello di eventi si ispira a quello delle GUI tradizionali ogni volta che l'utente compie un'azione viene eseguito un
evento

8.1 Understanding the JSF Event Model (TEORIA DI COME VENGONO GESTITI GLI EVENTI)

- il modello ad eventi di JSF è basto su quello di JavaBeans ogni evento è rapresentato da una istanza della classe event class. Un oggetto evento lancia un evento chiamando il metodo di notificazione dell'evento sull'oggetto event listener registrato per ricevere gli eventi, passando il riferimento all'oggeto evento come notifica del metodo argomento.
- tutte le classi eventi in JSF estendono javax.faces.event.FacesEvent (che a sua volta estende EventObject)
- questa classe prende come arogmento del costruttore UIComponent che è un event source object come argomento. Implementa anche un accessor-method type-safe per l'event source object
- Altri eventi sono rappresentati come concrete sottoclassi, per esempio la javax.faces.event.ValueChangeEvent che segnala un cambiamento di valore.
- C'è una interfaccia di listener che dichiara i metodi che gli event source chiamano per notificare che sono listeners di un evento. Una interfaccia di listener può contenere metodi per molti eventi collegati, ma per gli eventi dei componenti JSF c'è un interfaccia separate per eventi
public interface ActionListener extends FacesListener {
public void processAction(ActionEvent event) throws AbortProcessingException; }
- L'interfaccia ActionListener estende l'interfaccia javax.faces.event.FacesListener e definisce un metodo che prende l'istanza di un ActionEvent come singolo argomento.
- Le classi che vogliono essere informate su un evento sono chiamate event listener. Dichiarano quali eventi sono interessati implementando l'interfaccia listener corrispondente. Un event listener che vuole accordarsi con ActionEvent lanciato da un command componet dichiara il suo intento in questa maniera
public class ReportHandler implements ActionListener {

public void processAction(ActionEvent e) throws AbortProcessingException {

} }

- per prevenire ad altri listener di vedere un evento tutti i metodi JSF di event-processing possono lanciare una javax.faces.event.AbortProcessingException. Questo è necessario raramente ma può venire in aiuto quando accadono problemi seri nel processare un evento. Se il metodo di notifica dell'evento lancia questa eccezione, JSF ferma il processo dell'evento immediatamente.
- le classi Event source, come UICommand dichiarano il tipo di eventi che possono lanciare fornendo metodi per registrare e deregistrare i corrispondenti event listener.
public void addActionListener(ActionListener listener) {
addFacesListener(listener);
}
public void removeActionListener(ActionListener listener) {
removeFacesListener(listener);
}
I metodi seguono le convenzioni di JavaBeans, i nomi dei metodi sono composti dalle parole add e remove seguiti dal nome dell'interfaccia, entrambi i metodi prendono una istanza del listener come singolo argomento.
- I metodi addFacesListener() and removeFacesListener() chiamati dalla registrazione e deregistrazione sono metodi protetti implementati da UIComponentBase, così il processo di mantenimento della lista listener non deve essere implentato da tutte le sottoclassi.
- quando un componente notifica che si è verificato un evento utente, crea un istanza della event class corrispondente e la aggiunge alla event list. Eventualmente JSF dice al componente di lanciare un evento, cicla attraverso la lista dei listener per quelli eventi che chiamano il metodo di notifica su ciascuno di essi.

8.1.1 The Request Processing Lifecycle Phases

- possibili problemi, la connessione del client con il server può non essere continua, lo stato potrebbe dover essere salvato sul client per problemi del server (non c'è abbastanza memoria ecc.)
- il server non può accorgersi dei cambiamenti nei valori finche non c'è una nuova richiesta. Per risolvere il problema degli script lato client possono effettuare una richiesta ogni volta che i valori cambiano. Sfortunatamente possono esserci dei client che non supportano gli scripting
- bottoni e link sono facili da accordare, perchè causano una nuova richiesta ogni volta che sono premuti.
- per eventi delle interfacce utenti che coinvolge il backend non può essere processato finchè tutte le proprietà del modello non sono state aggiornate con i nuovi valori ricevuti nella richiesta.

- In figura 8.1 c'è un esempio di processamento degli eventi
1- nella fase di restore view i componenti che fanno parte della view sono riprisitinati dai dati nella richiesta o da dati salvati nel server.
2- nella apply request value, ogni componente nella vista guarda i propri valori nella richiesta e li salva
3- nella fase di process validation , i componenti validano i propri dati come già visto nel cap 7
4- le proprietà del modello limitano i componenti attraverso i limitatori dei valori e sono aggiornati nella fasi di Update Model Values
5- quando le proprietà del modello vengono popolate con l'ultimo valore, gli event listener possono chiamare il codice di backend per processare i nuovi dati nella fase di Invoke Application
6- Infine una risposta alla richiesta è mandata usando la stesso vista o una nuova, questo accade nella fase di Render Response

- se l'utente attiva la richiesta cliccando su un bottone o su un link, il corrispondent componente UICommand scopre questa nella fase di apply request values, quando trova un parametro di richiesta con un nome che matcha con il suo id. Questo crea un ActionEvent per rappresentare un evento ma non notifica al listener immediatamente, perchè il resto dei componenti nell'albero potrebbe non aver ancora raccolto i propri valori. Invece si aggiunge a una coda chiamando il suo metodo queueEvent().
- Alla fine della fase di apply request quando i componenti conoscono i loro nuovi valori
Continuare da
"At the end of the Apply Request Values "

8.2 Handling Application Backend Events

- guardiamo l'esempio 8.1: il bottone di add lancia un evento che richiede il processamento dal backend dell'applicazione. Quando l'utente clicca sul bottone una nuova entry con i valori inseriti nei campi viene aggiunta al report.
- nell'esempio 8.1 si vede un metodo che attiva gli eventi
<h:commandButton value="Add" disabled="#{reportHandler.addEntryDisabled}" action="#{entryHandler.add}" />
- l'attributo action contiene una method binding expression, la sintassi di questa è simile alla value binding expression è un subset di JSF EL che valuta con un metodo del bean una certa firma. In questo caso punta a un metodo chiamato add nell'istnaza dell'EntryHandler
- il codice per fare un ciclo è
<c:forEach items="${reportHandler.currentReportEntries}" var="e">
<li>Date: ${e.date}, Type: ${e.type}, Amount: ${e.amount}</li>
</c:forEach>

8.2.1 Using an Action Method and the Default ActionListener

Il componente UICommand supporta per il binding due tipi di metodi, action methods and action listener methods. Entrambi possono essere usati per processare un ActionEvent ma l'action methods è più largamente usato. Un action method non ha parametri e restituisce una String chiamato l'action outcome. L'outcome è tipicamente "success" se tutto è andato bene o "error" o "failure" se ci sono stati problemi. The outcome value can affect which view is displayed next, which we get back to in Chapter 9. In una pagina jsp , si può usare the action attribute con una espressione di binding for bind a UICommand component to an action method come nell'esempio 8.1 .

Un ActionEvent è manipolato da un listener che implementa l'interfaccia ActionListener

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