2013-07-21 11 views
5

Mam stronę z komponentem tekstu wejściowego oznaczoną jako required="true" i mającą niestandardową Validator po stronie serwera.Validator pominięty po usunięciu wejścia w kliencie - czy jest to zgodne ze specyfikacją JSF?

Teraz jako klient, przesyłam stronę bez elementu HTML renderowanego przez ten komponent (można to łatwo osiągnąć poprzez usunięcie elementu z drzewa DOM za pomocą wbudowanego inspektora DOM w przeglądarce). Formularz został pomyślnie przesłany, bez sprawdzania poprawności tego wymaganego składnika po stronie serwera.

Czy jest to zgodne ze specyfikacją JSF? Czy istnieje sposób, aby określić, że walidatory na stronie mają być wykonywane, nawet jeśli strona opublikowana ich nie zawiera?

Odpowiedz

4

Jest to zgodne ze specyfikacją. Oto wyciąg z UIInput#validate() javadoc znaczenie:

Odzyskać wartość złożonej z getSubmittedValue(). Jeśli to zwróci null, wyjście bez dalszego przetwarzania. (Oznacza to, że dla tego komponentu nie przesłano żadnej wartości).

Puste wejście wyśle ​​pusty ciąg znaków, a nie null. Pełny brak danych wejściowych wyśle ​​null, a nie pusty ciąg znaków.

To, czy jest to szkodliwe czy nie, zależy od logiki biznesowej. Przyzwoicie zaprojektowany model (logika biznesowa i/lub model danych), który nie jest zgodny z oczekiwaniami, spowodowałby wyjątek wskaźnika pustego w innym miejscu lub naruszenie ograniczenia SQL (NOT NULL), które zwykle kończy się błędem HTTP 500 . Ale jeśli model rzeczywiście uważa, że ​​jest to oczekiwany przypadek, prawdopodobnie jest to błąd w modelu. Widok (strona JSF), mający na celu jedynie przedstawienie modelu, może w związku z tym niewiele zrobić.

Jeśli model logiki biznesowej lub dane mogą nie być naprawdę zmieniany rozważyć null jak wyjątkowym przypadku (czyli nigdy nie zakładaj/zaakceptować daną wartość jako null) i zdarzy ci się korzystać z JPA, wtedy najlepiej jest dodać a @NotNull na nieruchomości. Chociaż JSF obejmie sprawdzanie poprawności, JPA nadal będzie go sprawdzać, powodując nadal wyjątek i błąd HTTP 500. Chciałbym w tym przypadku tylko zastanawiać się, dlaczego kolumna DB nie ma na początku więzu NOT NULL. Alternatywnie, wykonaj class level validation.

Zauważyć należy, że MyFaces rejestruje ostrzeżenie jak poniżej na ten temat:

16 marca 2016 08:55:52 org.apache.myfaces.shared.renderkit.html.HtmlRendererUtils decodeUIInput
OSTRZEŻENIE : Zawsze należy podać przesłaną wartość dla danych wejściowych, jeśli zostanie ona wyrenderowana, jej formularz zostanie przesłany i nie był pierwotnie renderowany jako wyłączony lub tylko do odczytu. Nie można przesłać formularza po wyłączeniu elementu wejściowego za pośrednictwem javascript. Rozważ ustawienie wartości tylko do odczytu na wartość true lub zresetowanie wartości wyłączonej z powrotem na wartość false przed przesłaniem formularza.
Komponent: {Ścieżka komponentu: [Klasa: javax.faces.component.UIViewRoot, ViewId: /test.xhtml][Class: javax.faces.component.html.HtmlBody, Id: j_id_5] [Klasa: javax.faces .component.html.HtmlForm, ID j_id_6] [klasy: javax.faces.component.html.HtmlInputText, ID j_id_7] Lokalizacja: /test.xhtml na linię 22 i kolumny 33}

+0

Dzięki za dostarczanie ekstrakt javadoc, wyjaśnia to zachowanie bardzo wyraźnie.Jak już wspomniano, szkoda, którą powoduje, zależy od logiki biznesowej: może częściowo zaktualizować obiekt o zasięgu aplikacji przed wyłączeniem wskaźnika pustego, powodując awarię całej aplikacji. Czy możesz również odpowiedzieć na drugą część pytania: czy można zatwierdzić zatwierdzenie, nawet jeśli dane wejściowe są zerowe? – mittal

+0

Nie bez hackowania JSF. Jeśli używasz OmniFaces, twój najlepszy zakład zmusza BV (JSR303 Bean Validation; '@ NotNull' i przyjaciele) przez' 'który obsługuje sprawdzanie poziomu fasoli na poziomie klasy. – BalusC

Powiązane problemy