2013-07-21 16 views
5

Ho una pagina con un componente di testo di input contrassegnato come required="true" e con una personalizzazione Validator sul lato server.Il validatore è saltato quando l'input è stato rimosso nel client - è conforme alle specifiche JSF?

Ora come client, invio la pagina senza l'elemento HTML reso da quel componente (ciò può essere facilmente ottenuto rimuovendo l'elemento dalla struttura DOM mediante l'ispettore di elementi DOM integrato nel browser). Il modulo viene inviato correttamente, senza la convalida lato server di questo componente richiesto.

È conforme alle specifiche JSF? C'è un modo per specificare che i validatori nella pagina devono essere eseguiti anche se la pagina postata non li contiene?

risposta

4

Questo è conforme alle specifiche. Ecco un estratto di rilevanza da UIInput#validate() javadoc:

recuperare il valore presentato con getSubmittedValue(). Se questo restituisce null, , uscire senza ulteriore elaborazione. (Ciò indica che nessun valore è stato inviato per questo componente.)

Un ingresso vuoto invierà una stringa vuota, non null. Un'assenza completa dell'input invierà null, non una stringa vuota.

Se ciò è dannoso o meno dipende dalla logica aziendale. Un modello progettato correttamente (logica aziendale e/o modello dati) che non consideri null come caso previsto causerebbe un'eccezione di puntatore nullo altrove o una violazione del vincolo SQL (NOT NULL), che di solito finirà in una risposta di errore HTTP 500 . Ma se il modello considera effettivamente null come un caso previsto, è probabile che si sia verificato un errore nel modello. La vista (la pagina JSF), intesa a presentare semplicemente il modello, può quindi fare ben poco contro di essa.

Se il modello di business logic o dati non può davvero essere modificato per considerare null come un caso eccezionale (cioè mai assumere/accettare il valore dato come null), e vi capita di usare JPA, allora la cosa migliore è quello di aggiungere a @NotNull sulla proprietà. Mentre JSF eviterà la convalida su di esso, JPA continuerà a convalidarlo, causando comunque un'eccezione e un errore HTTP 500. In questo caso, mi chiedo solo perché la colonna DB non abbia un vincolo NOT NULL al primo posto. In alternativa, fare class level validation.

Nota che dovrebbe essere che MyFaces Registra un avviso come qui di seguito su questo:

Mar 16, 2016 08:55:52 org.apache.myfaces.shared.renderkit.html.HtmlRendererUtils decodeUIInput
ATTENZIONE : Dovrebbe sempre esserci un valore inviato per un input se è sottoposto a rendering, il suo modulo viene inviato e non è stato originariamente reso disabilitato o di sola lettura. Non puoi inviare un modulo dopo aver disabilitato un elemento di input tramite javascript. Prendi in considerazione l'impostazione di sola lettura su true o ripristina il valore disabilitato su false prima dell'invio del modulo.
Componente: {Component-Path: [Classe: javax.faces.component.UIViewRoot, ViewId: /test.xhtml][Class: javax.faces.component.html.HtmlBody, Id: j_id_5] [Classe: javax.faces .component.html.HtmlForm, ID: j_id_6] [Classe: javax.faces.component.html.HtmlInputText, ID: j_id_7] Localizzazione: /test.xhtml alla linea 22 e la colonna 33}

+0

Grazie per fornire il estratto di javadoc, spiega il comportamento molto chiaramente.Come accennato da te, il danno che provoca dipende dalla logica di business: può aggiornare parzialmente un oggetto ambito applicazione prima di un'eccezione di puntatore nullo, causando così un'interruzione dell'intera applicazione. Puoi rispondere anche alla seconda parte della domanda: la convalida può essere autorizzata, anche quando l'input è nullo? – mittal

+0

Non senza hacking JSF. Se ti capita di utilizzare OmniFaces, la soluzione migliore è forzare BV (JSR303 Bean Validation; '@ NotNull' e amici) tramite' 'che supporta la convalida del bean a livello di classe. – BalusC

Problemi correlati