commandButton / commandLink / ajax akcja / nasłuchiwanie nie została wywołana lub wartość wejściowa nie została ustawiona / zaktualizowana

Zdarza się, że podczas używania <h:commandLink>, <h:commandButton>czy <f:ajax>The action, actionListenerlublistener metoda wiąże się ze znacznikiem są po prostu nie jest wywoływany. Lub właściwości fasoli nie są aktualizowane o przesłane UIInputwartości.

Jakie są możliwe przyczyny i rozwiązania tego problemu?

Wprowadzenie

W każdym przypadku gdy UICommandskładnik ( <h:commandXxx>, <p:commandXxx>itp) nie uruchomi odpowiednią metodę działania, lub UIInputskładnik ( <h:inputXxx>, <p:inputXxxx>itp) nie przetwarza przesłane wartości i / lub aktualizacji wartości modelu i nie widzisz żadnych googlable wyjątków i / lub ostrzeżenia w dzienniku serwera, także nie podczas konfigurowania modułu obsługi wyjątków ajax zgodnie z obsługą wyjątków w żądaniach JSF ajax , ani gdy ustawisz poniżej parametru kontekstu w web.xml,

<context-param>
    <param-name>javax.faces.PROJECT_STAGE</param-name>
    <param-value>Development</param-value>
</context-param>

a także nie widzisz żadnych błędów i / lub ostrzeżeń w przeglądarce w konsoli JavaScript przeglądarki (naciśnij F12 w Chrome / Firefox23 + / IE9 +, aby otworzyć zestaw narzędzi dla programistów, a następnie otwórz konsolę kartę ), a następnie zapoznaj się z poniższą listą możliwych przyczyn.

Możliwe przyczyny

1. UICommanda UIInputkomponenty muszą być umieszczone wewnątrz UIFormkomponentu, np. <h:form>(a więc nie zwykły HTML <form>), w przeciwnym razie nic nie zostanie wysłane na serwer. UICommandkomponenty również nie mogą mieć type="button"atrybutu, w przeciwnym razie będzie to martwy przycisk przydatny tylko w JavaScript onclick. Zobacz także Jak wysyłać wartości wejściowe formularza i wywoływać metodę w komponencie bean JSF, a <h: commandButton> nie inicjuje postback .

2. Nie można zagnieżdżać UIFormw sobie wielu komponentów. Jest to nielegalne w HTML. Zachowanie przeglądarki nie jest określone. Uważaj z dołączonymi plikami! Możesz używać UIFormkomponentów równolegle, ale nie będą się one przetwarzać podczas przesyłania. Powinieneś także uważać z antypatternem „God Form”; upewnij się, że nie przypadkowo przetwarzasz / weryfikujesz wszystkie inne (niewidoczne) dane wejściowe w tej samej formie (np. mając ukryte okno dialogowe z wymaganymi danymi wejściowymi w tej samej formie). Zobacz także Jak używać <h: formularz> na stronie JSF? Pojedynczy formularz? Wiele formularzy? Zagnieżdżone formularze?.

3. Nie UIInputpowinien wystąpić błąd sprawdzania poprawności / konwersji wartości. Można użyć <h:messages>do wyświetlenia dowolnych komunikatów, które nie są pokazywane przez <h:message>komponenty specyficzne dla danych wejściowych . Nie zapomnij zawierać idod <h:messages>w <f:ajax render>, jeśli w ogóle, tak, że będzie on aktualizowany w miarę dobrze na ajax żądań. Zobacz także h: wiadomości nie wyświetla wiadomości po naciśnięciu przycisku p: polecenie .

4. Jeśli UICommandlub UIInputskładniki są umieszczone wewnątrz komponentu iteracji jak <h:dataTable>, <ui:repeat>itp, to trzeba upewnić się, że dokładnie to samo valueskładnika iteracji jest zachowały się podczas zastosowania żądania wartości fazę formie przedstawienia żądania. JSF powtórzy to, aby znaleźć kliknięty link / przycisk i przesłał wartości wejściowe. Umieszczenie komponentu bean w zakresie widoku i / lub upewnienie się, że ładujesz model danych @PostConstructdo komponentu bean (a zatem nie w metodzie gettera!) Powinno to naprawić. Zobacz także Jak i kiedy powinienem załadować model z bazy danych dla h: dataTable .

5. Jeśli UICommandlub UIInputkomponenty są zawarte w dynamicznym źródle, takim jak <ui:include src="#{bean.include}">, musisz upewnić się, że dokładnie ta sama #{bean.include}wartość zostanie zachowana w czasie kompilacji widoku żądania przesyłania formularza. JSF ponownie go wykona podczas budowania drzewa komponentów. Umieszczenie komponentu bean w zakresie widoku i / lub upewnienie się, że ładujesz model danych @PostConstructdo komponentu bean (a zatem nie w metodzie gettera!) Powinno to naprawić. Zobacz także Jak odświeżyć dynamicznie ajax dołączyć zawartość według menu nawigacji? (JSF SPA) .

6. renderedAtrybut elementu i wszystkich jego rodziców i testatrybut każdego rodzica <c:if>/ <c:when>nie należy oceniać na falseczasie zastosować wartości żądania fazę formie przedstawienia żądania. JSF sprawdzi to ponownie w ramach zabezpieczenia przed sfałszowanymi / zhakowanymi żądaniami. Przechowywanie zmienne odpowiedzialne za stan w @ViewScopedfasoli lub upewniając się, że jesteś właściwie preinitializing stanu w @PostConstructz @RequestScopedfasoli powinien to naprawić. To samo dotyczy disabledatrybutu komponentu, którego nie należy oceniać truepodczas fazy stosowania wartości żądania. Zobacz także Nie akcji JSF CommandButton , Prześlij formularz w warunkowo renderowanym komponencie nie jest przetwarzany ih: commandButton nie działa, gdy zawinę go w <h: panelGroup renderowane> .

7. onclickAtrybutem UICommandelementu i onsubmitatrybut UIFormelementu nie powinna powrócić falselub spowodować błąd JavaScript. Tam w przypadku powinny <h:commandLink>lub <f:ajax>też nie ma JS błędy widoczne w konsoli JS przeglądarki. Zwykle wyszukiwanie go w dokładnym komunikacie o błędzie daje już odpowiedź. Zobacz także Ręczne dodawanie / ładowanie wyników jQuery za pomocą PrimeFaces w Uncaught TypeErrors .

8. Jeśli używasz Ajax przez JSF 2.x <f:ajax>lub np. PrimeFaces <p:commandXxx>, upewnij się, że masz <h:head>szablon główny zamiast <head>. W przeciwnym razie JSF nie będzie w stanie automatycznie dołączyć niezbędnych plików JavaScript, które zawierają funkcje Ajax. Spowodowałoby to błąd JavaScript, taki jak „mojarra nie jest zdefiniowany” lub „PrimeFaces nie jest zdefiniowany” w konsoli JS przeglądarki. Zobacz także h: commandLink actionlistener nie jest wywoływany, gdy jest używany z f: ajax i ui: repeat .

9. Jeśli używasz Ajax, a przesłane wartości są w końcu null, upewnij się, że UIInputi UICommandkomponenty będące przedmiotem zainteresowania są objęte przez <f:ajax execute>np. W <p:commandXxx process>przeciwnym razie nie zostaną wykonane / przetworzone. Zobacz także Przesłane wartości formularza niezaktualizowane w modelu podczas dodawania <f: ajax> do <h: commandButton> oraz Zrozumienie procesu / aktualizacji PrimeFaces i JSF f: ajax atrybuty wykonania / renderowania .

10. Jeśli przesłane wartości nadal się kończą null, a używasz CDI do zarządzania komponentami bean, to upewnij się, że importujesz adnotację zakresu z właściwego pakietu, w przeciwnym razie CDI domyślnie, do @Dependentktórego skutecznie odtwarza komponent bean przy każdej pojedynczej ocenie EL wyrażenie. Zobacz także @SessionScoped bean traci zakres i cały czas jest odtwarzany, pola stają się puste i jaki jest domyślny zakres Bean Managed w aplikacji JSF 2?

11. Jeśli element nadrzędny <h:form>z UICommandprzyciskiem jest wcześniej renderowany / aktualizowany przez żądanie ajax pochodzące z innego formularza na tej samej stronie, wówczas pierwsza akcja zawsze zakończy się niepowodzeniem w JSF 2.2 lub starszym. Drugie i kolejne działania będą działać. Jest to spowodowane błędem w obsłudze stanu widoku, który jest zgłaszany jako problem ze specyfikacją JSF 790 i obecnie naprawiony w JSF 2.3. Dla starszych wersji JSF, trzeba wyraźnie określić identyfikator <h:form>w renderz <f:ajax>. Zobacz także h: commandButton / h: commandLink nie działa przy pierwszym kliknięciu, działa tylko przy drugim kliknięciu .

12. Jeśli <h:form>został enctype="multipart/form-data"ustawiony w celu przesyłania plików wsparcie, to trzeba się upewnić, że używasz przynajmniej JSF 2.2, lub że filtr serwletu, który jest odpowiedzialny za analizowanie wniosków wieloczęściowy / form-data jest poprawnie skonfigurowany, w przeciwnym razie FacesServletwolę ostatecznie nie otrzyma żadnych parametrów żądania, a zatem nie będzie w stanie zastosować wartości żądania. Sposób skonfigurowania takiego filtra zależy od używanego komponentu do przesyłania plików. W przypadku Tomahawk <t:inputFileUpload>sprawdź tę odpowiedź, aw przypadku PrimeFaces <p:fileUpload>sprawdź tę odpowiedź . Lub, jeśli w ogóle nie przesyłasz pliku, usuń atrybut całkowicie.

13. Upewnij się, że ActionEventargumentem actionListenerjest, javax.faces.event.ActionEventa zatem nie java.awt.event.ActionEvent, co sugeruje większość IDE jako pierwsza opcja autouzupełniania. Brak argumentu jest również błędny, jeśli używasz actionListener="#{bean.method}". Jeśli nie chcesz argumentu w swojej metodzie, użyj actionListener="#{bean.method()}". A może faktycznie chcesz użyć actionzamiast actionListener. Zobacz także Różnice między akcją a listą akcji .

14. Upewnij się, że żaden PhaseListenerlub żaden EventListenerw łańcuchu żądania-odpowiedzi nie zmienił cyklu życia JSF, aby pominąć fazę działania invoke, na przykład wywołując FacesContext#renderResponse()lub FacesContext#responseComplete().

15. Upewnij się, że żaden Filterlub Servletw tym samym łańcuchu żądanie-odpowiedź w FacesServletjakiś sposób nie zablokował żądania . Na przykład filtry logowania / bezpieczeństwa, takie jak Spring Security. Zwłaszcza w żądaniach ajax, które domyślnie nie miałyby żadnej informacji zwrotnej z interfejsu użytkownika. Zobacz także Obsługa żądań AJAX Spring Security 4 i PrimeFaces 5 .

16. Jeśli używasz PrimeFaces <p:dialog>lub a <p:overlayPanel>, upewnij się, że mają swoje własne <h:form>. Ponieważ te składniki są domyślnie przenoszone przez JavaScript na koniec HTML <body>. Tak więc, jeśli pierwotnie siedzieli w środku <form>, to nie mogliby już więcej siedzieć w <form>. Zobacz także akcja przycisku p: polecenie nie działa w oknie dialogowym p:

17. Błąd w ramach. Na przykład RichFaces ma „ błąd konwersji ” podczas używania rich:calendarelementu interfejsu użytkownika z defaultLabelatrybutem (lub, w niektórych przypadkach, rich:placeholderpodelementem). Ten błąd uniemożliwia wywołanie metody komponentu bean, gdy dla daty kalendarzowej nie jest ustawiona żadna wartość. Śledzenie błędów frameworka można osiągnąć, zaczynając od prostego działającego przykładu i budując stronę z powrotem do momentu wykrycia błędu.

Wskazówki dotyczące debugowania

Jeśli nadal utkniesz, czas na debugowanie. Po stronie klienta naciśnij klawisz F12 w przeglądarce, aby otworzyć zestaw narzędzi dla programistów. Kliknij kartę Konsola , aby zobaczyć plik JavaScript. Powinien być wolny od błędów JavaScript. Poniższy zrzut ekranu to przykład z Chrome, który pokazuje przypadek przesłania <f:ajax>włączonego przycisku bez jego <h:head>zadeklarowania (jak opisano w punkcie 7 powyżej).

Kliknij kartę Sieć , aby wyświetlić monitor ruchu HTTP. Prześlij formularz i sprawdź, czy nagłówki żądania i dane formularza oraz treść odpowiedzi są zgodne z oczekiwaniami. Poniższy zrzut ekranu przedstawia przykład z Chrome, który pokazuje pomyślne przesłanie ajax prostego formularza z pojedynczym <h:inputText>i pojedynczym <h:commandButton>z <f:ajax execute="@form" render="@form">.

(ostrzeżenie: publikując zrzuty ekranu z nagłówków żądań HTTP takich jak powyżej ze środowiska produkcyjnego, upewnij się, że szyfrujesz / zaciemniasz pliki cookie sesji na zrzucie ekranu, aby uniknąć ataków przechwytywania sesji!)

Po stronie serwera upewnij się, że serwer jest uruchomiony w trybie debugowania. Umieść punkt przerwania debugowania w metodzie interesującego komponentu JSF, który ma zostać wywołany podczas przetwarzania formularza przesyłania. Np. W przypadku UICommandkomponentu byłoby to, UICommand#queueEvent()aw przypadku UIInputkomponentu, byłoby UIInput#validate(). Wystarczy wykonać wykonanie kodu i sprawdzić, czy przepływ i zmienne są zgodne z oczekiwaniami. Poniższy zrzut ekranu przedstawia przykład z debugera Eclipse.

Jeśli Twój h:commandLinkjest w środku, h:dataTableistnieje inny powód, dla którego h:commandLinkmoże nie działać:

Podstawowe źródło danych, które jest powiązane z h:dataTablemusi, musi być również dostępne w drugim cyklu życia JSF, który jest uruchamiany po kliknięciu łącza.

Więc jeśli podstawowe źródło danych ma zasięg zapytania, h:commandLinkto nie działa!

Chociaż moja odpowiedź nie ma zastosowania w 100%, ale większość wyszukiwarek uważa ją za pierwsze trafienie, postanowiłem jednak opublikować:

Jeśli używasz PrimeFaces (lub podobny API)p:commandButton lub p:commandLinkistnieje szansa, że ​​zapomniałeś jawnie dodać process="@this"do swoich komponentów poleceń.

Jako przewodnik w PrimeFaces użytkownika stwierdza w punkcie 3.18, domyślne dla processi updateto zarówno @form, który dość dużo sprzeciwia domyślne można oczekiwać od zwykłego JSF f:ajaxlub RichFaces, które są execute="@this"i render="@none"odpowiednio.

Długo mi to zajęło, żeby się dowiedzieć. (... i myślę, że raczej niewygodne jest używanie wartości domyślnych innych niż JSF!)

Wspomnę jeszcze o jednej rzeczy, która dotyczy Primefaces p:commandButton!

Kiedy używasz a p:commandButtondo akcji, która musi zostać wykonana na serwerze, nie możesz jej użyć, type="button"ponieważ dotyczy to przycisków Push, które są używane do wykonywania niestandardowego javascript bez powodowania do serwera żądania ajax / non-ajax.

W tym celu możesz zrezygnować z typeatrybutu (wartość domyślna to "submit") lub możesz użyć jawnie type="submit".

Mam nadzieję, że to komuś pomoże!

Sam utknąłem z tym problemem i znalazłem jeszcze jedną przyczynę tego problemu. Jeśli nie masz metod ustawiających w komponencie bean backing dla właściwości używanych w pliku * .xhtml, akcja po prostu nie jest wywoływana.

Niedawno napotkałem problem z tym, że UICommand nie wywołuje aplikacji JSF 1.2 przy użyciu komponentów IBM Extended Faces Components.

Miałem przycisk polecenia w wierszu bazy danych (wersja rozszerzona, więc <hx:datatable> tabeli danych ( ), a UICommand nie uruchamiał się z niektórych wierszy z tabeli (wiersze, które nie uruchamiałyby się, były wiersze większe niż domyślny rozmiar wyświetlania wiersza).

Miałem rozwijany komponent do wyboru liczby wierszy do wyświetlenia. Wartość podana w tym polu była RequestScope. Dane, na których opiera się sama tabela, były w pewnym sensie ViewScope(w rzeczywistości tymczasowo włączone SessionScope).

Jeśli wyświetlanie wiersza zostało zwiększone za pomocą kontrolki, która wartość była również powiązana z rowsatrybutem bazy danych, żaden z wierszy wyświetlanych w wyniku tej zmiany nie mógł uruchomić UICommand po kliknięciu.

Umieszczenie tego atrybutu w tym samym zakresie, co same dane tabeli, rozwiązało problem.

Myślę, że wspomniano o tym w BalusC # 4 powyżej, ale nie tylko wartość tabeli musiała mieć zakres View lub Session, ale także atrybut kontrolujący liczbę wierszy wyświetlanych w tej tabeli.

Miałem też ten problem i dopiero po otwarciu konsoli internetowej przeglądarki zacząłem doskonalić główną przyczynę. Do tego czasu nie mogłem uzyskać żadnych komunikatów o błędach (nawet z <p:messages>). Konsola internetowa pokazała kod stanu HTTP 405 wracający z <h:commandButton type="submit" action="#{myBean.submit}">.

W moim przypadku mam połączenie waniliowego HttpServleta zapewniającego uwierzytelnianie OAuth za pomocą faset Auth0 i JSF oraz fasoli realizujących moje widoki aplikacji i logikę biznesową.

Po ponownym przeredagowaniu pliku web.xml i usunięciu serwletu pośredniego, działało ono „magicznie”.

Podsumowując, problem polegał na tym, że serwlet pośredni używał RequestDispatcher.forward (...) do przekierowania ze środowiska HttpServlet do środowiska JSF, podczas gdy wywoływany wcześniej serwlet przekierowywał za pomocą HttpServletResponse.sendRedirect (.. .).

Zasadniczo użycie sendRedirect () pozwoliło „kontenerowi” JSF przejąć kontrolę, podczas gdy RequestDispatcher.forward () oczywiście nie.

Nie wiem, dlaczego facelet był w stanie uzyskać dostęp do właściwości fasoli, ale nie mógł ich ustawić, a to wyraźnie krzyczy za rezygnację z mieszanki serwletów i JSF, ale mam nadzieję, że pomoże to komuś uniknąć wielu godzin głowy walenie w stół.

Świetnie się bawiłem debugowaniem problemu, w którym <h:commandLink>akcja richfaces datatableodmawiała strzału. Tabela kiedyś działała, ale zatrzymała się bez wyraźnego powodu. Nie zostawiłem żadnego kamienia obróconego, tylko po to, aby dowiedzieć się, że użyłem rich:datatablezła, rowKeyConverterktóre zwróciło wartości zerowe, które richfaces chętnie wykorzystywał jako klucze wierszy. Zapobiegło to <h:commandLink>wywołaniu mojego działania.

Jeszcze jedna możliwość: jeśli symptomem jest to, że pierwsze wywołanie działa, ale kolejne nie, możesz używać PrimeFaces 3.x z JSF 2.2, jak wyszczególniono tutaj: Nie wysyłane jest ViewState .

Rozwiązałem problem z umieszczeniem:

<h:commandButton class="btn btn-danger" value = "Remove" action="#{deleteEmployeeBean.delete}"></h:commandButton>

W:

<h:form>
     <h:commandButton class="btn btn-danger" value = "Remove" action="#{deleteEmployeeBean.delete}"></h:commandButton>
</h:form>

To jest rozwiązanie, które dla mnie działa.

<p:commandButton id="b1" value="Save" process="userGroupSetupForm"
                    actionListener="#{userGroupSetupController.saveData()}" 
                    update="growl userGroupList userGroupSetupForm" />

W tym przypadku atrybut process = „userGroupSetupForm” jest obowiązkowy dla wywołania Ajax. actionListener wywołuje metodę z @ViewScope Bean. Aktualizujemy również komunikat warczenia, Datatable: userGroupList i Form: userGroupSetupForm.

<ui:composition>  
  <h:form id="form1">
    <p:dialog id="dialog1">
      <p:commandButton value="Save" action="#{bean.method1}" /> <!--Working-->
    </p:dialog>
  </h:form>

  <h:form id="form2">
    <p:dialog id="dialog2">
      <p:commandButton value="Save" action="#{bean.method2}" /> <!--Not Working-->
    </p:dialog>
  </h:form>
</ui:composition>

Rozwiązać;

<ui:composition>  
  <h:form id="form1">
    <p:dialog id="dialog1">
      <p:commandButton value="Save" action="#{bean.method1}" />   <!-- Working  -->
    </p:dialog>

    <p:dialog id="dialog2">
      <p:commandButton value="Save" action="#{bean.method2}" />   <!--Working  -->
    </p:dialog>
  </h:form>
  <h:form id="form2">
    <!-- ..........  -->
  </h:form>
</ui:composition>