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

345

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?

Muhammad Hewedy
źródło

Odpowiedzi:

687

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).

konsola js

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">.

monitor sieci

(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.

serwer debugowania

BalusC
źródło
1
twój drugi punkt zmusił mnie do myślenia - na długo. Właśnie dowiedziałem się, że przyczyną mojego problemu był znacznik f: view w moim głównym pliku. I prawdopodobnie dlatego, że renderuje formularz, prawda?
Paulo Guedes,
2
@pauloguedes Nie mogę znaleźć niczego, co mówi, że f: view renderuje formularz. Rozumiem, że to tylko pojemnik. Z mojego doświadczenia wynika, że ​​f: view nie renderuje żadnych elementów.
Lucas,
@balusc Trochę wyjaśnienia w punkcie 4, jeśli komendy LinkLink nie ma w samej tabeli danych, czy nadal ma to znaczenie?
Lucas,
dzięki, chodzi o to, że umieszczenie komponentu bean w zakresie widoku i / lub upewnienie się, że ładujesz model danych do (post) konstruktora komponentu bean (a zatem nie w metodzie gettera!) powinno to naprawić.
merveotesi
2
@Kukeltje: spowodowałoby to wyjątek EL (już uwzględniony w pierwszym akapicie odpowiedzi)
BalusC
54

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!

jbandi
źródło
2
Ok, nie było to dla mnie całkiem jasne. Mam nadzieję, że moja odpowiedź i tak jest pomocna, ponieważ przynajmniej w moim przypadku przynajmniej nie miałem do czynienia z UICommand / UIData. „Rozwiązanie” promowało
komponent
1
Drugi komentarz Jensa ... ustawienie mojej fasoli RequestScoped na SessionScoped zmieniło moją tabelę danych - dzięki
Zack Macomber
28

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!)

Kawu
źródło
6
Domyślna wartość dla PrimeFaces processto @form. Więc jeśli akcja nie jest wywoływana w ten sposób, ale dzieje się to podczas używania @this, najprawdopodobniej ma zastosowanie punkt 3 mojej odpowiedzi.
BalusC
3
To nie może być. Miałem p:commandButtonmetodę, która nie wywołała metody actionListener, dopóki nie dodałem process="@this". Ponadto Podręcznik użytkownika PrimeFaces wyraźnie wymienia wartości domyślne, o których wspomniałem w sekcjach 3.18 i 3.19. Jest tutaj: primefaces.googlecode.com/files/primefaces_users_guide_3_4.pdf ... może zmieniono ustawienia domyślne?
Kawu
8
Prawdopodobnie jest to błąd w dokumentacji. Usuń process="@this"i dodaj <p:messages autoUpdate="true">(lub po prostu przeczytaj dziennik serwera dla wiadomości w kolejce, ale nie wyświetlanych), a zobaczysz, że faktycznie wystąpił błąd konwersji / weryfikacji.
BalusC
Dlaczego usunąłeś to pytanie stackoverflow.com/questions/60673695/…
Kukeltje
Pomyślałem, że teraz może to nie przynieść większej wartości ... Cofnąłem to.
Kawu
9

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!

akelec
źródło
to był mój główny problem na jednej z naszych stron, żaden punkt w zaakceptowanej odpowiedzi nie zbliżył nas bliżej, gdzie znalazłeś te informacje?
Uriel Arvizu
Cóż, miałem ten problem wiele razy i przeprowadziłem badania i odkryłem, że p:commandButtonma on kilka wartości typeatrybutu i buttonjest jednym, który dotyczy wszystkiego po stronie klienta. Trochę trudno to znaleźć w Primefacesdokumencie, ale tutaj jest jeden link: developer.am/primefaces/…
akelec
Twoja wskazówka rozwiązała mój problem, z którym borykam się od wielu dni. Wielkie dzięki za twój post!
gpuk360
Dziękuję, to przyjemność po mojej stronie. Celowo podałem tę odpowiedź, ponieważ wielu z nas miało taki problem. Straciłem też kilka dni, dopóki nie zrozumiałem, o co chodzi.
akelec
3

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.

Dnawir
źródło
5
Powinno to doprowadzić do dość samo wyjaśniającego się PropertyNotWritableException. Jeśli go nie widziałeś, być może uruchomiłeś żądanie ajax bez odpowiedniej procedury obsługi wyjątków ajax, ale powinieneś zobaczyć je w logach serwera.
BalusC
3
Nie pokazywał tego wyjątku, dopóki nie utworzyłem p: commandButton's ajax = "false".
Dnavir
Dzięki Bogu uratowałeś mi życie
exrezzo
3

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.

Brent C
źródło
2

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ół.

Strumyki
źródło
1

Ś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.

Mustafa
źródło
0

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 .

Dave Mulligan
źródło
-1

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>
Georgi Peev
źródło
To numer 1 w> 600 głosowanych odpowiedziach. Nie musisz pisać tego jako osobnej odpowiedzi.
Kukeltje
-1

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.

Rajib Kumer Ghosh
źródło
-2
<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>
Kenan Gökbak
źródło
Przepraszam, ale to jest moim skromnym zdaniem całkowicie nieprawda. Skutecznie stwierdzasz, że 2 okna dialogowe muszą mieć swoją własną formę do działania. Z 99% pewnością miałeś inny problem, który rozwiązałeś i dla którego teraz uważasz, że jest to rozwiązanie ...
Kukeltje
To jest dołączona strona. Być może może to powodować problemy. Powinieneś przetestować to przed głosowaniem.
Kenan Gökbak
Nie, powinieneś stworzyć minimalny, powtarzalny przykład przed opublikowaniem (i tylko wtedy mogę przetestować) ... I tak obejmuje może powodować problemy z oknami dialogowymi i formularzami, ale problem nadal nie jest tym, co chcesz rozwiązać tutaj . Najpierw przykładem jest perfekcyjnie, a drugi jest w 100% nie pewności roztwór nieistniejącego problemu
Kukeltje
Tak czy siak. Moja aplikacja działa dobrze. Myślę, że nie jest ważne, gdzie w oknie dialogowym pojawia się okno dialogowe. Muszę utworzyć drugi formularz, aby rozwiązać inny problem.
Kenan Gökbak
Twoja aplikacja może działać, ale nie jest to jasne / widoczne z oryginalnego problemu i twojego rozwiązania. Poza tym mówisz _ „Myślę, że nie jest ważne, gdzie okno dialogowe jest w formularzu.” _Ale w twojej odpowiedzi wydaje się być ważne, gdzie się znajdują. Sprzeczność, która popiera moje stwierdzenie. Niestety, ale odpowiedź jest zwykły się źle ... (nie ma innej downvote na nim już)
Kukeltje