JSF 2.0 @ViewScoped Umleitung (Navigation) = „_ blank“ Ziel

Question

Grundsätzlich ist die gleiche Frage wie here

Wie behalte ich eine ViewScoped Bohne auf der Seite, von der ich auf einen anderen Browser-Tab umleiten:

firstPage.xhtml:

<h:commandLink action="#{controller.redirect}" value="#{bean.value} target="_blank"/> 

Wenn Umleitung/Navigation endet mit den anderen Bohnen initialisiert, zerstört sie diese # {} Bohne in den Prozess. Im umgeleiteten Code verwende ich nicht einmal # {bean}. Dies funktioniert mit

<a4j:keepAlive> 

Hier ist meine aktuelle Einstellung. Bean-Klasse:

@ViewScoped 
public class Bean{ 
    @PreDestroy 
    public void onDestroy(){ // being destroyed when I don't want to } 
} 

faces-config:

<navigation-rule> 
    <from-view-id>/firstPage.xhtml</from-view-id> 
    <navigation-case> 
     <from-outcome>redirect</from-outcome> 
     <to-view-id>/secondPage.xhtml</to-view-id> 
    </navigation-case> 
</navigation-rule> 

Answer 1

Sie tun müssen, als Luiggi und speichern Daten legten nahe, vorübergehend in der Sitzung oder die Daten übergeben (oder Schlüssel ausreicht, um die Daten erneut abzurufen) über Abfrageparameter zur Zielansicht. Dies ist auch dann der Fall, wenn Sie ein neues Fenster/Tab nicht umleiten und/oder nicht darauf abzielen.

Ansichtsbereich ist seltsam. Es existiert nur so lange, wie der Benutzer auf derselben Ansicht bleibt. Wenn JSF erkennt, dass von der Ansicht weg navigiert wurde, werden automatisch alle Beans zerstört, die sich auf diese Ansicht beziehen.

Sie können auf zwei Arten zu einer anderen Ansicht navigieren. Die erste ist eine Anfrage ohne Gesichter, wie zum Beispiel von h:link oder h:button. In diesem Fall wird die vorherige Ansicht nicht wiederhergestellt, so dass JSF nicht weiß, dass es zu zerstörende View-Scoped-Beans gibt. Die zweite ist eine Faces-Anfrage, beispielsweise von h:commandLink oder h:commandButton, die etwas anderes als void oder null zurückgibt. In diesem Fall gibt es ein Postback für die Ansicht, das wiederhergestellt wird, um die Aktion zu verarbeiten. Wenn das Ergebnis dieser Aktion darin besteht, von dieser Ansicht weg zu navigieren, oder umleiten, werden alle Beans, die auf diese Ansicht beschränkt sind, zerstört.

Unter der Haube, View-Bereich ist im Wesentlichen Session-Bereich mit einigen integrierten Semantik zum Aufräumen "alter" Daten. Dies funktioniert tatsächlich gut, wenn Benutzer die Anwendung nicht in mehr als einem Fenster/Tab öffnen und nur die in der Anwendung bereitgestellte Navigation verwenden (d. H. Nicht die Schaltflächen zum Zurück/Vorwärts des Browsers). Da wir jedoch von Webbrowsern sprechen, ist der Ansichtsbereich meines Erachtens ziemlich nutzlos (mit der einzigen Ausnahme, dass Sie den Zielbrowser steuern und den Zurück-/Vorwärts-/Neuladevorgang/Standort vollständig deaktivieren können, aber das ist nicht der Fall Es klingt nicht so, als wärst du in einer solchen Umgebung.