it-swarm.com.de

Wie navigiere ich in JSF? Wie man URL die aktuelle Seite widerspiegelt (und nicht die vorherige)

Ich lerne gerade JSF und war ziemlich erstaunt und verblüfft, als ich feststellte, dass es bei jeder Verwendung von <h:form> Das Standardverhalten von JSF ist, mir immer die URL der Seite previous zu zeigen im Browser im Gegensatz zur URL der Seite current.

Ich verstehe, dass dies damit zusammenhängt, dass JSF ein Formular immer auf derselben Seite veröffentlicht und dann nur die vom Controller zurückgegebene Seite an den Browser rendert, der nicht weiß, dass sich die Seitenposition geändert hat.

Es scheint, als ob JSF schon lange genug da ist, dass es eine saubere und solide Möglichkeit geben muss, damit umzugehen. Wenn ja, würde es Ihnen etwas ausmachen, dies mitzuteilen?

Ich habe verschiedene Workarounds gefunden, aber leider nichts, was nach einer wirklich soliden Lösung aussieht.

  • Akzeptieren Sie einfach, dass die URL irreführend ist.
  • Hänge "?faces-redirect=true" An den Rückgabewert von every bean's action an und dann
    • überlegen Sie, wie Sie @RequestScoped durch etwas anderes ersetzen können (Flash Scopes, CDI-Konversation, @SessionScoped, ...).
    • akzeptieren Sie zwei HTTP-Roundtrips für jede Benutzeraktion.
  • Verwenden Sie eine Methode (z. B. Bibliothek eines Drittanbieters oder benutzerdefinierten Code), um den Seitennamen in der URL auszublenden, und verwenden Sie für jede Seite immer dieselbe generische URL.

Wenn "?faces-redirect=true" So gut ist, wie es nur geht, gibt es eine Möglichkeit, eine gesamte Anwendung so zu konfigurieren, dass alle Anforderungen auf diese Weise behandelt werden?

48
Student

Tatsächlich sendet JSF als formularbasiertes, anwendungsorientiertes MVC-Framework das POST) - Formular an dieselbe URL, unter der die Seite mit dem <h:form> - Formular angefordert wurde. Sie können dies bestätigen Betrachten Sie dazu die URL <form action> der generierten HTML-Ausgabe. Dies wird in Bezug auf die Webentwicklung als Postback bezeichnet Postback führt standardmäßig nicht zu einer neuen Anforderung an die neue URL, sondern lädt die Zielseite als Inhalt der Antwort. Dies ist in der Tat verwirrend, wenn Sie nur von Seite zu Seite navigieren möchten.

Im Allgemeinen hängt der richtige Ansatz wie zur Navigation/Umleitung auf den Geschäftsanforderungen und die idempotence (sprich: „bookmarkability“) der Anfrage (Anmerkung: für konkrete Codebeispiele finden Sie in die „Siehe auch“ Links unten).

  • Wenn die Anforderung idempotent ist, verwenden Sie einfach ein GET-Formular/einen GET-Link anstelle von POST Form (dh verwenden Sie <a>, <form>, <h:link> Oder <h:button> Anstelle von <h:form> Und <h:commandXxx>).
    Zum Beispiel Seite-zu-Seite-Navigation, Google-ähnliches Suchformular usw.

  • Wenn die Anforderung nicht idempotent ist, nur Ergebnisse zeigen, bedingt in der gleichen Ansicht (dh Rückkehr null oder void von Aktionsmethode und nutzt zB <h:message(s)> und/oder rendered).
    Zum Beispiel Eingabe/Bearbeitung von In-Page-Daten, mehrstufiger Assistent, modaler Dialog, Bestätigungsformular usw.

  • Wenn die Anforderung nicht idempotent ist, die Zielseite jedoch idempotent, senden Sie einfach eine Umleitung nach POST (dh Ergebnis mit ?faces-redirect=true Aus der Aktionsmethode zurückgeben) oder rufen Sie ExternalContext#redirect(), oder setzen Sie <redirect/> in die alte XML-Navigation.
    Anzeigen einer Liste aller Daten nach erfolgreicher Bearbeitung, Weiterleiten nach dem Anmelden usw.

Beachten Sie, dass reine Seite-zu-Seite Navigation in der Regel idempotent ist und das ist, wo viele JSF Starter nicht durch Befehl missbrauchen Links/Tasten für das und dann beschweren sich danach, dass URLs nicht ändern. Beachten Sie auch, dass Navigationsfälle in realen Anwendungen, die in Bezug auf SEO/UX entwickelt wurden, sehr selten verwendet werden. Hier schlagen viele JSF-Tutorials fehl, da die Leser das Gegenteil glauben lassen.

Beachten Sie auch, dass die Verwendung von POST ist absolut nicht „sicherer“ als GET, weil die Anforderungsparameter in URL nicht sofort sichtbar sind. Sie sind noch sichtbar in HTTP-Anforderung Körper und noch manipulierbar. So gibt es absolut kein Grund zu bevorzugen POST für idempotent Anfragen aus Gründen der „Sicherheit“. die wirkliche Sicherheit ist HTTPS statt HTTP bei der Verwendung und in Business-Service-Methoden zu überprüfen, ob aktuell eingeloggte Benutzer erlaubt frage Entität X ab oder manipuliere Entität X usw. Ein anständiges Sicherheits-Framework bietet Annotationen dafür.

Siehe auch:

73
BalusC