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}
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
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