Außerdem werden in der JavaScript-Konsole des Browsers keine googlable Fehler und / oder Warnungen angezeigt (drücken Sie F12 in Chrome / Firefox23 + / IE9 +, um das Toolset für Webentwickler zu öffnen, und öffnen Sie dann die Registerkarte Konsole ). Arbeiten Sie dann die folgende Liste möglicher Ursachen durch.
UICommand
und UIInput
Komponenten müssen innerhalb einer UIForm
Komponente platziert werden, z. B. <h:form>
(und damit kein einfaches HTML <form>
), sonst kann nichts an den Server gesendet werden. UICommand
Komponenten dürfen auch keine type="button"
Attribute haben, sonst ist es eine tote Schaltfläche, die nur für JavaScript nützlich ist onclick
. Siehe auch So senden Sie Formulareingabewerte und rufen eine Methode in der JSF-Bean auf, und <h: commandButton> initiiert kein Postback .
Sie können nicht mehrere UIForm
Komponenten ineinander verschachteln . Dies ist in HTML illegal. Das Browserverhalten ist nicht angegeben. Achtung mit Include-Dateien! Sie können UIForm
Komponenten parallel verwenden, diese verarbeiten sich jedoch beim Senden nicht gegenseitig. Sie sollten auch mit "God Form" Antipattern aufpassen; Stellen Sie sicher, dass Sie nicht alle anderen (unsichtbaren) Eingaben in derselben Form unbeabsichtigt verarbeiten / validieren (z. B. einen versteckten Dialog mit den erforderlichen Eingaben in derselben Form). Siehe auch Verwendung von <h: form> auf der JSF-Seite. Einzelform? Mehrere Formen? Verschachtelte Formulare? .
Es UIInput
sollte kein Wertüberprüfungs- / Konvertierungsfehler aufgetreten sein. Sie können <h:messages>
damit alle Nachrichten anzeigen, die von keinen eingabespezifischen <h:message>
Komponenten angezeigt werden . Vergessen Sie nicht, das id
von <h:messages>
in das <f:ajax render>
, falls vorhanden, aufzunehmen, damit es auch bei Ajax-Anfragen aktualisiert wird. Siehe auch h: messages zeigt keine Meldungen an, wenn p: commandButton gedrückt wird .
Wenn UICommand
oder UIInput
Komponenten innerhalb einer Iterieren Komponente platziert sind , wie <h:dataTable>
, <ui:repeat>
etc, dann brauchen Sie , dass genau das gleiche , um sicherzustellen , value
der Iterieren Komponente erhalten geblieben ist während der Anforderungswerte Phase des Formulars Antrag stellen beantragen. JSF wiederholt dies, um den angeklickten Link / die angeklickte Schaltfläche und die übermittelten Eingabewerte zu finden. Wenn Sie die Bean in den Ansichtsbereich einfügen und / oder sicherstellen, dass Sie das Datenmodell in @PostConstruct
die Bean laden (und damit nicht in eine Getter-Methode!), Sollte dies behoben werden. Siehe auch Wie und wann soll ich das Modell aus der Datenbank für h laden: Datatable .
Wenn UICommand
oder UIInput
Komponenten von einer dynamischen Quelle wie z. B. enthalten sind <ui:include src="#{bean.include}">
, müssen Sie sicherstellen, dass #{bean.include}
während der Ansichtserstellungszeit der Formularübermittlungsanforderung genau derselbe Wert beibehalten wird. JSF führt es beim Erstellen des Komponentenbaums erneut aus. Wenn Sie die Bean in den Ansichtsbereich einfügen und / oder sicherstellen, dass Sie das Datenmodell in @PostConstruct
die Bean laden (und damit nicht in eine Getter-Methode!), Sollte dies behoben werden. Siehe auch Wie kann ich dynamische Include-Inhalte über das Navigationsmenü aktualisieren? (JSF SPA) .
Das rendered
Attribut der Komponente und aller ihrer test
übergeordneten Elemente sowie das Attribut eines übergeordneten Elements <c:if>
/ <c:when>
sollten false
während der Phase zum Anwenden von Anforderungswerten des Formulars zum Senden von Anforderungen nicht ausgewertet werden . JSF überprüft dies erneut, um sich vor manipulierten / gehackten Anforderungen zu schützen. Speichern der Variablen für den Zustand verantwortlich in einer @ViewScoped
Bohne oder dafür sorgen , dass Sie in den Zustand richtig sind preinitializing @PostConstruct
einer @RequestScoped
Bohne sollte es beheben. Gleiches gilt für das disabled
Attribut der Komponente, das true
während der Phase der Anwendung der Anforderungswerte nicht ausgewertet werden sollte . Siehe auch JSF CommandButton-Aktion nicht aufgerufen , Formularübermittlung in bedingt gerenderter Komponente wird nicht verarbeitet undh: commandButton funktioniert nicht, wenn ich es in eine <h: panelGroup gerendert> verpacke .
Das onclick
Attribut der UICommand
Komponente und das onsubmit
Attribut der UIForm
Komponente sollten keinen false
JavaScript-Fehler zurückgeben oder verursachen. In der JS-Konsole des Browsers sollten im Falle <h:commandLink>
oder <f:ajax>
auch keine JS-Fehler sichtbar sein. Wenn Sie die genaue Fehlermeldung googeln, erhalten Sie normalerweise bereits die Antwort. Siehe auch Manuelles Hinzufügen / Laden von jQuery mit PrimeFaces führt zu nicht erfassten TypeErrors .
Wenn Sie Ajax über JSF 2.x <f:ajax>
oder z. B. PrimeFaces verwenden <p:commandXxx>
, stellen Sie sicher, dass Sie eine <h:head>
in der Master-Vorlage anstelle von haben <head>
. Andernfalls kann JSF die erforderlichen JavaScript-Dateien, die die Ajax-Funktionen enthalten, nicht automatisch einschließen. Dies würde zu einem JavaScript-Fehler wie "Mojarra ist nicht definiert" oder "PrimeFaces ist nicht definiert" in der JS-Konsole des Browsers führen. Siehe auch h: commandLink actionlistener wird bei Verwendung mit f: ajax und ui: repeat nicht aufgerufen .
Wenn Sie Ajax verwenden und die übermittelten Werte am Ende sind null
, stellen Sie sicher, dass die UIInput
und die UICommand
interessierenden Komponenten durch das <f:ajax execute>
oder z. B. abgedeckt sind <p:commandXxx process>
, da sie sonst nicht ausgeführt / verarbeitet werden. Siehe auch Übermittelte Formularwerte, die im Modell nicht aktualisiert wurden, wenn <f: ajax> zu <h: commandButton> hinzugefügt wurde, und Grundlegendes zu PrimeFaces-Prozess- / Aktualisierungs- und JSF f: ajax-Ausführungs- / Renderattributen .
Wenn die übermittelten Werte immer noch gültig null
sind und Sie CDI zum Verwalten von Beans verwenden, stellen Sie sicher, dass Sie die Bereichsanmerkung aus dem richtigen Paket importieren. Andernfalls wird CDI standardmäßig verwendet, @Dependent
um die Bean bei jeder einzelnen Auswertung der EL effektiv neu zu erstellen Ausdruck. Siehe auch @SessionScoped Bean verliert den Gültigkeitsbereich und wird ständig neu erstellt, Felder werden null und Was ist der Standardbereich für verwaltete Bean in einer JSF 2-Anwendung?
Wenn ein übergeordnetes Element <h:form>
mit der UICommand
Schaltfläche zuvor durch eine Ajax-Anforderung gerendert / aktualisiert wurde, die von einem anderen Formular auf derselben Seite stammt, schlägt die erste Aktion in JSF 2.2 oder älter immer fehl. Die zweite und die folgenden Aktionen funktionieren. Dies wird durch einen Fehler in der Behandlung des Ansichtsstatus verursacht, der als JSF-Spezifikationsproblem 790 gemeldet und derzeit in JSF 2.3 behoben wird. Für ältere Versionen JSF, müssen Sie explizit die ID der spezifizieren <h:form>
in der render
von der <f:ajax>
. Siehe auch h: commandButton / h: commandLink funktioniert nicht beim ersten Klick, sondern nur beim zweiten Klick .
Wenn das <h:form>
ist , enctype="multipart/form-data"
um Support - Datei - Upload festlegen, dann müssen Sie sicherstellen , dass Sie mindestens JSF 2.2 verwenden, oder dass die Servlet - Filter , die für das Parsen von multipart / form-data - Anforderungen verantwortlich ist richtig konfiguriert ist , da sonst den FacesServlet
Willen Am Ende erhalten Sie überhaupt keine Anforderungsparameter und können daher die Anforderungswerte nicht anwenden. Wie ein solcher Filter konfiguriert wird, hängt von der verwendeten Datei-Upload-Komponente ab. Für Tomahawk <t:inputFileUpload>
, überprüfen Sie diese Antwort und für PrimeFaces <p:fileUpload>
, überprüfen Sie diese Antwort . Wenn Sie tatsächlich überhaupt keine Datei hochladen, entfernen Sie das Attribut vollständig.
Stellen Sie sicher, dass das ActionEvent
Argument von actionListener
ein javax.faces.event.ActionEvent
und somit nicht java.awt.event.ActionEvent
ist, was die meisten IDEs als erste Option für die automatische Vervollständigung vorschlagen. Kein Argument zu haben ist auch falsch, wenn Sie verwenden actionListener="#{bean.method}"
. Wenn Sie kein Argument in Ihrer Methode möchten, verwenden Sie actionListener="#{bean.method()}"
. Oder vielleicht möchten Sie tatsächlich action
anstelle von verwenden actionListener
. Siehe auch Unterschiede zwischen action und actionListener .
Stellen Sie sicher, dass keine PhaseListener
oder keine EventListener
in der Anforderungs- / Antwortkette den JSF-Lebenszyklus geändert hat, um die Aufrufaktionsphase zu überspringen, indem Sie beispielsweise FacesContext#renderResponse()
oder aufrufen FacesContext#responseComplete()
.
Stellen Sie sicher, dass keine Filter
oder Servlet
dieselbe Anforderungs-Antwort-Kette die Anforderung für die FacesServlet
irgendwie blockiert hat . Zum Beispiel Anmelde- / Sicherheitsfilter wie Spring Security. Insbesondere bei Ajax-Anfragen, die standardmäßig überhaupt kein Feedback zur Benutzeroberfläche erhalten. Siehe auch Spring Security 4 und PrimeFaces 5 AJAX-Anforderungsbearbeitung .
Wenn Sie ein PrimeFaces <p:dialog>
oder ein PrimeFaces verwenden <p:overlayPanel>
, stellen Sie sicher, dass diese ihre eigenen haben <h:form>
. Da diese Komponenten standardmäßig von JavaScript an das Ende von HTML verschoben werden <body>
. Wenn sie also ursprünglich in einem <form>
sitzen würden, würden sie jetzt nicht mehr in einem sitzen <form>
. Siehe auch p: Befehlsschaltflächenaktion funktioniert im p: -Dialog nicht
Fehler im Framework. Beispielsweise weist RichFaces einen " Konvertierungsfehler " auf, wenn ein rich:calendar
UI-Element mit einem defaultLabel
Attribut (oder in einigen Fällen einem rich:placeholder
Unterelement) verwendet wird. Dieser Fehler verhindert, dass die Bean-Methode aufgerufen wird, wenn für das Kalenderdatum kein Wert festgelegt ist. Das Verfolgen von Framework-Fehlern kann erreicht werden, indem Sie mit einem einfachen Arbeitsbeispiel beginnen und die Seite wieder aufbauen, bis der Fehler entdeckt wird.
Falls Sie immer noch stecken bleiben, ist es Zeit zum Debuggen. Drücken Sie auf der Clientseite im Webbrowser F12, um das Webentwickler-Toolset zu öffnen. Klicken Sie auf die Registerkarte Konsole , um das JavaScript-Conosle anzuzeigen. Es sollte frei von JavaScript-Fehlern sein. Der folgende Screenshot zeigt ein Beispiel aus Chrome, das den Fall zeigt, dass eine <f:ajax>
aktivierte Schaltfläche gesendet wird, ohne sie <h:head>
deklariert zu haben (wie in Punkt 7 oben beschrieben).
Stellen Sie auf der Serverseite sicher, dass der Server im Debug-Modus gestartet wird. Fügen Sie einen Debug-Haltepunkt in eine Methode der interessierenden JSF-Komponente ein, die Sie voraussichtlich während der Verarbeitung des Formulars aufrufen werden. Zum Beispiel im Falle einer UICommand
Komponente wäre das UICommand#queueEvent()
und im Falle einer UIInput
Komponente wäre das UIInput#validate()
. Gehen Sie einfach die Codeausführung durch und prüfen Sie, ob der Ablauf und die Variablen den Erwartungen entsprechen. Der folgende Screenshot zeigt ein Beispiel aus dem Eclipse-Debugger.
Wenn Sie
h:commandLink
sich in einemh:dataTable
befinden, gibt es einen anderen Grund, warum dash:commandLink
möglicherweise nicht funktioniert:Die zugrunde liegende Datenquelle, die an die gebunden ist,
h:dataTable
muss auch im zweiten JSF-Lebenszyklus verfügbar sein, der beim Klicken auf den Link ausgelöst wird.Wenn die zugrunde liegende Datenquelle einen Anforderungsbereich hat,
h:commandLink
funktioniert die nicht!quelle
Obwohl meine Antwort nicht zu 100% zutreffend ist, aber die meisten Suchmaschinen dies als ersten Treffer ansehen, habe ich mich dennoch entschlossen, sie zu veröffentlichen:
Wenn Sie PrimeFaces (oder eine ähnliche API)
p:commandButton
oder verwendenp:commandLink
, haben Sie möglicherweise vergessenprocess="@this"
, Ihre Befehlskomponenten explizit hinzuzufügen .Als Leitfaden erklärt die PrimeFaces Benutzer in Abschnitt 3.18, die Standardeinstellungen für
process
undupdate
sind beide@form
, die so ziemlich die Standardwerte wendet sich gegen Sie aus einfachen JSF erwartenf:ajax
oder Richfaces, die sindexecute="@this"
undrender="@none"
jeweils.Ich habe nur eine lange Zeit gebraucht, um es herauszufinden. (... und ich denke, es ist ziemlich unkonventionell, Standardeinstellungen zu verwenden, die sich von JSF unterscheiden!)
quelle
process
ist@form
. Wenn die Aktion also nicht auf diese Weise aufgerufen wird, sondern bei der Verwendung@this
, gilt höchstwahrscheinlich Punkt 3 meiner Antwort.p:commandButton
, die die actionListener-Methode erst aufrief, als ich sie hinzufügteprocess="@this"
. Darüber hinaus werden im PrimeFaces-Benutzerhandbuch die in den Abschnitten 3.18 und 3.19 genannten Standardeinstellungen explizit aufgeführt. Es ist hier: primefaces.googlecode.com/files/primefaces_users_guide_3_4.pdf ... vielleicht wurden die Standardeinstellungen geändert?process="@this"
und Hinzufügen<p:messages autoUpdate="true">
(oder lesen Sie einfach das Serverprotokoll für Nachrichten in der Warteschlange, aber nicht angezeigt) und Sie werden sehen, dass tatsächlich ein Konvertierungs- / Validierungsfehler aufgetreten ist.Ich würde noch eine Sache erwähnen, die Primefaces betrifft
p:commandButton
!Wenn Sie a
p:commandButton
für die Aktion verwenden, die auf dem Server ausgeführt werden muss, können Sie diese nicht verwenden,type="button"
da dies für Drucktasten gilt, mit denen benutzerdefiniertes Javascript ausgeführt wird, ohne dass eine Ajax- / Nicht-Ajax-Anforderung an den Server gesendet wird.Zu diesem Zweck können Sie das
type
Attribut ausgeben (Standardwert ist"submit"
) oder Sie können es explizit verwendentype="submit"
.Hoffe das hilft jemandem!
quelle
p:commandButton
es die verschiedenen Werte vontype
Attributen hat undbutton
alles, was die Client-Seite betrifft. Es ist ein bisschen schwer, dies inPrimefaces
doc zu finden , aber hier ist ein Link: developer.am/primefaces/…Ich habe mich selbst mit diesem Problem beschäftigt und eine weitere Ursache für dieses Problem gefunden. Wenn Ihre Backing Bean keine Setter-Methoden für die in Ihrer * .xhtml verwendeten Eigenschaften enthält, wird die Aktion einfach nicht aufgerufen.
quelle
PropertyNotWritableException
. Wenn Sie es nicht gesehen haben, haben Sie möglicherweise eine Ajax-Anfrage ohne einen geeigneten Ajax-Ausnahmebehandler ausgelöst, aber Sie sollten es in Serverprotokollen sehen.Ich bin kürzlich auf ein Problem mit einem UICommand gestoßen, der in einer JSF 1.2-Anwendung mit IBM Extended Faces Components nicht aufgerufen wird.
Ich hatte eine Befehlsschaltfläche in einer Zeile einer Datentabelle (also die erweiterte Version
<hx:datatable>
) und der UICommand wurde nicht aus bestimmten Zeilen aus der Tabelle ausgelöst (die Zeilen, die nicht ausgelöst wurden, waren die Zeilen, die größer als die Standardzeilenanzeige waren).Ich hatte eine Dropdown-Komponente zum Auswählen der Anzahl der anzuzeigenden Zeilen. Der Wert, der dieses Feld unterstützt, war in
RequestScope
. Die Daten, die die Tabelle selbst sichern, befanden sich in einer ArtViewScope
(in Wirklichkeit vorübergehend inSessionScope
).Wenn die
rows
Zeilenanzeige über das Steuerelement erhöht wurde, welcher Wert auch an das Attribut der Datentabelle gebunden war , konnte keine der als Ergebnis dieser Änderung angezeigten Zeilen den UICommand auslösen, wenn darauf geklickt wurde.Durch Platzieren dieses Attributs im selben Bereich wie die Tabellendaten selbst wurde das Problem behoben.
Ich denke, dass dies in BalusC # 4 oben erwähnt wird, aber nicht nur der Tabellenwert musste einen Gültigkeitsbereich für Ansicht oder Sitzung haben, sondern auch das Attribut, das die Anzahl der Zeilen steuert, die in dieser Tabelle angezeigt werden sollen.
quelle
Ich hatte auch dieses Problem und begann erst nach dem Öffnen der Webkonsole des Browsers wirklich, die Grundursache zu untersuchen. Bis dahin konnte ich keine Fehlermeldungen erhalten (auch nicht mit
<p:messages>
). Die Webkonsole zeigte einen HTTP 405-Statuscode an, der von der zurückkam<h:commandButton type="submit" action="#{myBean.submit}">
.In meinem Fall habe ich eine Mischung aus Vanille-HttpServlets, die OAuth-Authentifizierung über Auth0- und JSF-Facelets und Beans bereitstellen und meine Anwendungsansichten und Geschäftslogik ausführen.
Nachdem ich meine web.xml überarbeitet und ein Middle-Man-Servlet entfernt hatte, funktionierte es "magisch".
Unterm Strich bestand das Problem darin, dass das Middle-Man-Servlet RequestDispatcher.forward (...) verwendete, um von der HttpServlet-Umgebung in die JSF-Umgebung umzuleiten, während das zuvor aufgerufene Servlet mit HttpServletResponse.sendRedirect (.. .).
Grundsätzlich ermöglichte die Verwendung von sendRedirect () dem JSF- "Container", die Kontrolle zu übernehmen, während dies bei RequestDispatcher.forward () offensichtlich nicht der Fall war.
Was ich nicht weiß, ist, warum das Facelet auf die Bean-Eigenschaften zugreifen konnte, diese aber nicht einstellen konnte, und dies schreit eindeutig danach, die Mischung aus Servlets und JSF zu beseitigen, aber ich hoffe, dies hilft jemandem, viele Stunden Kopf zu vermeiden. zu Tisch schlagen.
quelle
Ich hatte viel Spaß beim Debuggen eines Problems, bei dem sich
<h:commandLink>
die Aktion von arichfaces
datatable
weigerte, zu feuern. Der Tisch funktionierte früher, blieb aber ohne ersichtlichen Grund stehen. Ich ließ nichts unversucht, nur um herauszufinden, dass ichrich:datatable
das Falsche verwendete,rowKeyConverter
das Nullen zurückgab, die Richfaces gerne als Zeilenschlüssel verwendeten. Dies verhinderte, dass meine<h:commandLink>
Aktion aufgerufen wurde.quelle
Eine weitere Möglichkeit: Wenn das Symptom ist, dass der erste Aufruf funktioniert, nachfolgende jedoch nicht, verwenden Sie möglicherweise PrimeFaces 3.x mit JSF 2.2, wie hier beschrieben: Es wird kein ViewState gesendet .
quelle
Ich habe mein Problem mit der Platzierung behoben:
Im:
quelle
Dies ist die Lösung, die für mich funktioniert.
Hier ist process = "userGroupSetupForm" atrribute für den Ajax-Aufruf obligatorisch. actionListener ruft eine Methode von @ViewScope Bean auf. Aktualisieren Sie auch die Growl-Nachricht Datatable: userGroupList und Form: userGroupSetupForm.
quelle
Lösen;
quelle