JSF un anno dopo #14
Alla fine si invocano i metodi dei backbean.
I componenti che implementano ActionSource o ActionSource2 possono generare eventi di azione. Anche i componenti che implementano ValueHolder o EditableValueHolder possono generare tali eventi. Nel primo caso si usano action o actionListener, nel secondo caso valueChangeListener. Ad ogni tipo di evento (evento azione o evento di cambiamento del valore) corrisponde insomma un tipo di metodo. Ogni evento e ogni listener di eventi corrisponde ad una classe nella gerarchia di faces. Gli eventi di cambiamento del valore sono elaborati al termine della fase 3, quelli di azione sono elaborati al termine della fase 5. Se il componente che ha generato l'evento porta l'attributo immediate pari a true, l'elaborazione avviene allora al termine della fase 2 (questo e` molto importante soprattutto per i componenti che servono a navigare fra le pagine e che quindi non devono far scattare la validazione).
Per gestire un evento di azione si puo` implementare ActionListener con una classe. Ci sara` un unico metodo che restituisce void e accetta un ActionEvent. Lo si specifica nel componente tramite EL da mettere dentro l'attributo actionListener. Un tale metodo comunque verra` accettato anche se si trova in un bean qualsiasi senza implementare l'interfaccia. Cosi` facendo si ottiene che il metodo viene eseguito senza navigazione. Se si vuole effettuare navigazione il metodo dovra` essere specificato nell'attributo action, non accettare parametri e restituire una stringa (corrispondente all'opportuna entry nel faces config).
Un evento di cambiamento del valore si imposta mediante l'attributo valueChangeListener, e sara` un metodo che accetta un ValueChangeEvent e restituisce void. Tale metodo al solito puo` trovarsi in una classe che implemento ValueChangeListener o piu` semplicemente in un qualsiasi bean. Siccome questi eventi vengono eseguiti al termine della fase 3, puo` accadere che non siano rieseguiti dopo ulteriori post back della stessa form: basta che il valore non sia cambiato. Anche in questo caso se l'input riporta immediate pari a true, l'evento viene elaborato alla fine della fase 2. L'utilita` di questo non e` tanto scontata.
Qualora si intenda stranamente implementare con una classe l'interfaccia actionListener, si puo` associare la classe al compontente con opportuni tag
stessa cosa per un valueChangeListener.
Tutti questi listener sono stati pensati per funzionare mediante la vecchia tecnica del fare delle submit di tutta la form usando Javascript sugli eventi onchange dei vari componenti. In questo modo se ad un campo di testo (o un combo o quel che e`...) viene associato un listener lato server, se viene modificato il valore si vedra` la form ricaricarsi e il listener verra` eseguito. A questo punto si capisce a cosa serve mettere immediate anche sui componenti. Se su un pulsante puo` essere utile per la navigazione, su un componente di input e` altrettanto utile per consentire queste variazioni veloci senza far scattare la validazione su tutti gli altri campi (per esempio quelli obbligatori, ma non solo). Con ajax tutto cio` perde un po' di significato.
Per fare in modo che le cose funzionino occorre comunque che sul finire del listener sia ordinato al ciclo di vita di procedere
FacesContext.getCurrentInstance().renderResponse();
I componenti che implementano ActionSource o ActionSource2 possono generare eventi di azione. Anche i componenti che implementano ValueHolder o EditableValueHolder possono generare tali eventi. Nel primo caso si usano action o actionListener, nel secondo caso valueChangeListener. Ad ogni tipo di evento (evento azione o evento di cambiamento del valore) corrisponde insomma un tipo di metodo. Ogni evento e ogni listener di eventi corrisponde ad una classe nella gerarchia di faces. Gli eventi di cambiamento del valore sono elaborati al termine della fase 3, quelli di azione sono elaborati al termine della fase 5. Se il componente che ha generato l'evento porta l'attributo immediate pari a true, l'elaborazione avviene allora al termine della fase 2 (questo e` molto importante soprattutto per i componenti che servono a navigare fra le pagine e che quindi non devono far scattare la validazione).
Per gestire un evento di azione si puo` implementare ActionListener con una classe. Ci sara` un unico metodo che restituisce void e accetta un ActionEvent. Lo si specifica nel componente tramite EL da mettere dentro l'attributo actionListener. Un tale metodo comunque verra` accettato anche se si trova in un bean qualsiasi senza implementare l'interfaccia. Cosi` facendo si ottiene che il metodo viene eseguito senza navigazione. Se si vuole effettuare navigazione il metodo dovra` essere specificato nell'attributo action, non accettare parametri e restituire una stringa (corrispondente all'opportuna entry nel faces config).
Un evento di cambiamento del valore si imposta mediante l'attributo valueChangeListener, e sara` un metodo che accetta un ValueChangeEvent e restituisce void. Tale metodo al solito puo` trovarsi in una classe che implemento ValueChangeListener o piu` semplicemente in un qualsiasi bean. Siccome questi eventi vengono eseguiti al termine della fase 3, puo` accadere che non siano rieseguiti dopo ulteriori post back della stessa form: basta che il valore non sia cambiato. Anche in questo caso se l'input riporta immediate pari a true, l'evento viene elaborato alla fine della fase 2. L'utilita` di questo non e` tanto scontata.
Qualora si intenda stranamente implementare con una classe l'interfaccia actionListener, si puo` associare la classe al compontente con opportuni tag
stessa cosa per un valueChangeListener.
Tutti questi listener sono stati pensati per funzionare mediante la vecchia tecnica del fare delle submit di tutta la form usando Javascript sugli eventi onchange dei vari componenti. In questo modo se ad un campo di testo (o un combo o quel che e`...) viene associato un listener lato server, se viene modificato il valore si vedra` la form ricaricarsi e il listener verra` eseguito. A questo punto si capisce a cosa serve mettere immediate anche sui componenti. Se su un pulsante puo` essere utile per la navigazione, su un componente di input e` altrettanto utile per consentire queste variazioni veloci senza far scattare la validazione su tutti gli altri campi (per esempio quelli obbligatori, ma non solo). Con ajax tutto cio` perde un po' di significato.
Per fare in modo che le cose funzionino occorre comunque che sul finire del listener sia ordinato al ciclo di vita di procedere
FacesContext.getCurrentInstance().renderResponse();