JSF un anno dopo #12

[ciecodicolono]

La conversione e la convalida avvengono nella fase 3 (process validation).
Per ogni componente che sia un EditableValueHolder:

1. si recupera il submittedValue (ottenuto nella fase 2)
2. se c'e` un Converter si chiede di convertire, altrimenti se c'e` un binding per valore si genera un converter al volo o se non si trova niente si lascia il valore com'e`
3. se c'e` una converter exception si contrassegna il campo come non valido
4. si effettua la validazione: prima si verifica che il dato ci sia e se era required, poi per ogni validatore presente si richiede la validazione e se parte una eccezione contrassegnare come non valido;
5. se il valore e` ancora valido ed e` cambiato rispetto alla precedente esecuzione si genera un ValueChangeEvent, altrimenti si passa alla fase di redering

Un qualsivoglia convertitore deve implementare l'interfaccia Converter che da 2 soli metodi, getAsObject e getAsString. Se nell'esecuzione del primo dei due parte una eccezione il componente viene segnato come non valido e dall'eccezione viene estratto il messaggio.
Ci sono convertitori per tutti i tipi (compreso la data) e possono essere usati con , ma ci sono tag appositi per e . 
In output la conversione sara` quasi sempre implicita senza dove fare niente.

La validazione e` basata sull'uso dell'interfaccia Validator che definisce un unico metodo

void validate(FacesContext context, UIComponent component, Object value)

tale metodo viene richiamato durante la fase 2 o la fase 3 a seconda che il componente da validare abbia l'attributo immediate impostato a true o no (default). Prima di chiamare tale metodo il componente viene segnato come non valido: successivamente se il metodo termina senza problemi viene segnato come valido. Perche` questo non accada il metodo deve lanciare una ValidatorException (il messaggio dentro l'eccezione viene usato come messaggio di errore).

Esistono dei validatori preconfezionati:

1. f:validateLongRange valida interi Long. Supponendo che la conversione abbia funzionato, lancia eccezioni se il valore inserito non rientra fra quanto specificato negli attributi minimum e maximum. Tali eccezioni hanno messaggi diversi a seconda che entrambi gli attributi siano stati specificati o che ne sia stato specificato uno solo.
   
   
2. f:validateDoubleRange funziona uguale al precedente ma con valori Double
3. f:validateLength e` anche questo molto simile e valida la lunghezza delle stringhe inserite

e` poi previsto per ogni componente di input l'attributo required per stabilire se tale input e` obbligatorio. E` possibile usare due o piu` validatori per il campo di input (per esempio quello della lunghezza associato ad uno degli altri due).
Piu` importante ancora: e` possibile indicare come validatore un metodo di un bean. Tale metodo dovra` avere una firma molto simile a quella dei metodi dell'interfaccia Validator (il nome del metodo puo` cambiare). Non e` impossibile aggiungere i validatori in modo programmatico ma questo procedimento obbliga a realizzare un RootPhaseListener per garantire che il validatore sia istallato all'inizio del ciclo di vita e che rimanga al suo posto.

E` posssibile poi creare una classe che implementi l'interfaccia Validator. Un validatore fatto cosi` andra` registrato nel faces config con un tag apposito

validatoreid
        nome.package.NomeClasse

e usare nella facelet il tag di validazione generico