Fehlermeldungen gespeichert in SITZUNG

Question

Ist es eine gute Praxis, Fehlermeldungen in SESSION zu speichern? Zum Beispiel nach einer Weiterleitung. Passing in url ist nicht eine Lösung für mich ... Ich frage mich, ob es eine gute Lösung ist ... weil ..

Würde eine concurent submit des Benutzers ein Problem? (Eine lange Zeit, Post, während Ajax Inhalt von einem anderen Tab erhalten wird), die die Sitzung versauen kann! Oder ist das unmöglich?

Wenn der Benutzer eine Anfrage stellt und aus irgendeinem Grund die Seite nicht angezeigt wird, wird die Nachricht möglicherweise auf einer irrelevanten Seite angezeigt!

Also? Irgendwelche Alternativen ??
Zum Beispiel, wenn POST/umgeleitet/get Muster

Answer 1

Beim Speichern von Fehlermeldungen in der Sitzung müssen Sie darauf achten, dass zwei Anfragen die anderen nicht überschreiben, bevor sie angezeigt werden. Und Sie müssen darauf achten, dass eine Seite, die eine Nachricht anzeigen soll, nur eine eigene Nachricht anzeigt.

Sie sollten Fehler anzeigen, wenn sie auftreten und nicht vorher umleiten. Es gibt auch keinen Grund, in einer solchen Situation umzuleiten.

Answer 2

Ist es eine gute Praxis zu speichern Fehlermeldungen in SESSION? Zum Beispiel nach einer Weiterleitung.

Nicht im Allgemeinen. Sitzungsdaten sollten Daten sein, die für einen signifikanten Zeitraum von Bedeutung sind, Fehler sind im Allgemeinen das Ergebnis einer einzelnen Anfrage und die Details müssen nicht bestehen bleiben.

Das Speichern dieser Art von Daten in einer Sitzung ist nur eine Einladung zu den Rennbedingungen.

Answer 3

Es ist nicht ungewöhnlich, Fehlermeldungen in der Sitzung zu speichern, insbesondere in Fällen, in denen es mehrere Weiterleitungen geben kann. Zend Framework hat so etwas wie Flash Messenger, was das macht.

Alles, was in der Sitzung ist, würde in der Sitzung bleiben, bis Sie es oder Session-Zeitüberschreitung zerstören. Die beste Vorgehensweise besteht darin, die Fehlermeldungen in der Sitzung zu speichern. Wenn die Seite geladen wird, auf der die Fehlermeldung angezeigt werden muss, erhält der Code die Nachrichten aus der Sitzung und zeigt sie an, sofern sie vorhanden sind. Nachdem die Fehlermeldungen angezeigt werden, müssen Sie sie aus der Sitzung löschen. Andernfalls werden die Fehlermeldungen jedes Mal, wenn der Benutzer diese Seite aufruft, immer wieder angezeigt.

Der beste Ansatz ist das Anzeigen und Löschen.

Ich glaube, dass Sie kein Problem haben sollten, wenn Sie diesen Ansatz verwenden. Der Grund dafür ist, dass wenn ein falsches Formular gesendet wird, es immer Fehler enthalten wird und es immer versuchen wird, diese Fehlermeldungen in der Sitzung zu speichern und sie entsprechend anzuzeigen, egal wie oft sie in der Sitzung hinzugefügt/gelöscht wurden. Ich hoffe, das macht alles Sinn.

Auch wenn Sie Sitzungsfehlermeldungen speichern, müssen Sie sie intelligent speichern, damit das Backend weiß, dass diese Fehlermeldungen für welches Formular gespeichert werden.

Answer 4

Fokus auf den Benutzer! Alle Ihre Entwicklungsanstrengungen möchten die bestmögliche UX bereitstellen.

Die erste Frage ist, warum brauchen Sie überhaupt Nachrichten?

• Im Falle eines erfolgreichen Anforderung, möchten Sie die Benutzer, dass sein Wunsch wissen, erfolgreich ausgeführt wurde.
• Im Fall einer fehlerhaften Anfrage, können Sie unterscheiden: wenn die Anforderung vom Anwender geändert werden kann in eine erfolgreiche Anforderung zu drehen, zeigt dann eine hilfreich Fehlermeldung (zum Beispiel einer einfaches Formular Vorlage). Wenn die Anfrage nicht vom Benutzer geändert werden kann, so informativ wie möglich warum die Anfrage fehlgeschlagen (z. B. "Konnte nicht ausgeführt werden, da Service XY nicht verfügbar ist. Bitte kontaktieren Sie den Support etc.").

Ganz einfach: Fehlerhafte Anforderung, die verändert werden kann:

Im Fall einer fehlerhaften Anfrage, wo der Benutzer die Anforderung ändern kann, kann es nicht in der Sitzung speichern und machen direkt auf der Seite, wo die Benutzer kann seine Anfrage korrigieren.

Schwierig: Erfolgreiche Anfrage oder fehlerhafte Anforderung, die nicht verändert werden kann:

hier Sie in der Regel die Benutzer nicht in der Lage wünschen können, die genau die gleiche Anforderung erneut auszuführen, nachdem F5 oder unter ähnlichen Maßnahmen treffen, damit Sie leiten den Benutzer um. In diesem Fall bevorzuge ich persönlich die Lösung mit einer Flash-Nachrichten-Komponente (siehe Symfony Docs oder Zend Docs für ein Beispiel). Im Allgemeinen führt diese Technik nicht zu rauen Bedingungen, wenn Ihre Anwendungen diese Annahmen erfüllen:

• Ihre HTTP-Anforderungen, die vom Browser ausgelöst werden, werden schnell ausgeführt. Ein Benutzer hat in der Zwischenzeit keine reelle Chance, eine zweite Anfrage auszulösen.
• Ihre AJAX-Aufrufe haben keinen Einfluss auf die Flash-Nachrichten - oder, wenn Sie strukturierte Daten (XML, JSON) zurückgeben, können Sie einen speziellen Abschnitt für Flash-Nachrichten einfügen, die dann von Javascript gerendert werden.

, jetzt Fehlerraten minimieren Sie folgendes tun:

• Shop der Zeitstempel, wenn Sie den Flash-Nachricht hinzugefügt. Zeigen Sie keine alten Nachrichten an (z. B.> 1 Minute). Ein mobiler Benutzer verliert möglicherweise die Verbindung und versucht es erneut. In welchem ​​Zustand erwartet er die Bewerbung?
• Lassen Sie die HTTP-Anfragen zwischen Ihrem Benutzer und Ihrem Server niemals lange dauern. Wenn Sie lange Berechnungen durchführen müssen, versuchen Sie, Dinge an einen Hintergrund-Worker auszulagern, und zeigen Sie dem Benutzer den Status der Verarbeitung an.

Zusammengefasst: Wenn Sie allgemeine gute Praktiken in Bezug auf Ihre HTTP-Kommunikation an den richtigen Stelle, dann der Benutzer unwahrscheinlich kann mess up Flash-Mitteilungen. Wägen Sie die Vor- und Nachteile ab und konzentrieren Sie sich auf den Benutzer, nicht auf die Komplexität Ihrer Implementierung, da es Methoden gibt, um damit umzugehen.

Answer 5

Generell gilt:

Versuchen Sie, auf der Client-Seite so viel zu setzen (JavaScript und Cookies) und versucht, so wenig wie möglich auf der Serverseite zu speichern.

Dazu gehört das SESSION-Variable, die im besten Fall nur Benutzer-ID enthalten.

Wenn die Nachricht nach Redirect ist, könnten Sie eine Anforderungsvariable hinzufügen, die Index, der die Nachricht konnte und es auf diese Weise zu zeigen.

Answer 6

warum nicht Sie ihnen eine spezifische ID wie ERROR_ID = 2 und schickt sie durch url zuweisen? oder ist das in Ihrem Fall auch nicht möglich? Sie könnten auch eine Fehler-ID durch Sitzung senden ...

Answer 7

Anstatt in einer Sitzung zu speichern, könnten Sie einen Fehlercode in der URL übergeben, die Sie dann verwenden würden, um den Fehler zu suchen. Ich habe Benutzer Barebone-Exception-Klassen für dieses Ding irgendwie:

class MyException extends Exception 
{ 
    const USER_NOT_FOUND = 'The requested user was not found'; 
    // ... 
} 

Dann würde Ihre umgeleiteten URL etwas wie /controller/action/error/USER_NOT_FOUND sein und Sie würden, dass die Nachricht suchen aufbrauchen:

echo constant('MyException::' . $error); 

Sie brauchen keine Exception Klasse für diese zu verwenden, aber es ermöglicht es Ihnen, die Dinge wirklich ordentlich

if ($errorState) { 
    throw new MyException(
     MyException::USER_NOT_FOUND 
    ); 
}