T-Rex: Meldung auf nächster Seite werfen

Moin,

hab da so eine Webseite. Da gibt es diverse Meldungen wenn der User etwas gemacht hat. Ob die gut oder schlecht sind ist irrelevant. Normalerweise stösst der User irgend etwas an. Er füllt ein Formular aus oder klickt irgendwo drauf. Die Seite baut sich neu auf. Beim erneuten Aufbau wird die Aktiuon geprüft und eben eine Meldung ausgegeben. Soweit kein Problem.

Jetzt gibt es aber Konstelationen wo es einen reload auf der Serverseite gibt. Sprich der User macht eine Aktion, die Aktion wird geprüft, eine Meldung wird geworfen bzw. gecached und es gibt eine Weiterleitung oder Reload. Die Meldung ist jetzt jedoch verloren, da die Aktion nicht nochmal geprüft wird.
Eigentlich würde ich das so lösen in dem ich eine Fehlernummer als Parameter mitgebe: example.com?meldung=124423
Das empfinde ich jedoch als unschön. Zumal es sein kann dass mehrere Meldungen geworfen werden können. Der User soll nicht mit Meldungsnummern beheligt werden. Deswegen überlege ich die Meldungsnummer in eine Session zu packen.

MeldungsObjekt init
MeldungsObjekt - Session befüllen
Reload
MeldungsObjekt init
MeldungsObjekt - Meldung aus Session holen
MeldungsObjekt - Meldung in Session löschen

Würde gerne eure Meinung dazu hören.

Gruß
Succcess: T-Rex Greetings

  1. Hallo,

    Jetzt gibt es aber Konstelationen wo es einen reload auf der Serverseite gibt. Sprich der User macht eine Aktion, die Aktion wird geprüft, eine Meldung wird geworfen bzw. gecached und es gibt eine Weiterleitung oder Reload.

    Was spricht dagegen, diese Meldungen in einer Datenbank zu speichern und dann dem jeweiligen Benutzer über eine Technik wie AJAX entsprechend anzuzeigen?

    Deswegen überlege ich die Meldungsnummer in eine Session zu packen.

    Nein, du packst das in eine Datenbank und zeigst entsprechend der Session die Meldungen an.

    Würde gerne eure Meinung dazu hören.

    Google mal nach: web session management (ff.)

    Grüße

    1. Was spricht dagegen, diese Meldungen in einer Datenbank zu speichern und dann dem jeweiligen Benutzer über eine Technik wie AJAX entsprechend anzuzeigen?

      Wer sagt das es nicht in einer Datenbank steht?
      Es ist jedoch unerheblich wo und wie die Meldungen schlussendlich gespeichert sind. Mir geht es ja nur darum wie ich die Meldungsnummer von einer Seite auf die andere bekomme bzw. was ein guter Weg dafür ist.

      Nein, du packst das in eine Datenbank und zeigst entsprechend der Session die Meldungen an.

      Du würdest also auch mit der Session arbeiten?

      Gruß
      T-Rex

      1. Wer sagt das es nicht in einer Datenbank steht?

        Weil du mit Javascript gekommen bist, um die Meldungen zu "verwalten".

        Es ist jedoch unerheblich wo und wie die Meldungen schlussendlich gespeichert sind.

        Kommt auf den Zweck an.

        Mir geht es ja nur darum wie ich die Meldungsnummer von einer Seite auf die andere bekomme bzw. was ein guter Weg dafür ist.

        Du meinst von einem HTTP-Request in den nächsten?

        Nein, du packst das in eine Datenbank und zeigst entsprechend der Session die Meldungen an.
        Du würdest also auch mit der Session arbeiten?

        Ja, um das zustandslose HTTP in ein Anwendungsprotokoll zu überführen, sprich: Um den jeweiligen Benutzer zu identifizieren und so zu wissen, welche serverseitigen Aktionen durchzuführen sind.

        Grüße

  2. Hi!

    Normalerweise stösst der User irgend etwas an. Er füllt ein Formular aus oder klickt irgendwo drauf. Die Seite baut sich neu auf. Beim erneuten Aufbau wird die Aktiuon geprüft und eben eine Meldung ausgegeben. Soweit kein Problem.

    Falsche Reihenfolge. Nachdem der User klickt, arbeitet zuerst der Webserver den Request ab, wobei er die Aktion prüft/ausführt/wasauchimmer, dann/dabei erstellt er die Ausgabe, die sich danach erst beim Nutzer aufbauen kann.

    Jetzt gibt es aber Konstelationen wo es einen reload auf der Serverseite gibt.

    Und der ist in diesem Falle notwendig?

    Sprich der User macht eine Aktion, die Aktion wird geprüft, eine Meldung wird geworfen bzw. gecached und es gibt eine Weiterleitung oder Reload. Die Meldung ist jetzt jedoch verloren, da die Aktion nicht nochmal geprüft wird.

    Die Frage ist für mich, ob es im positiven Fall (anzunehmenderweise der mit dem Redirect) eine Bestätigung geben muss oder ob es nicht auch reicht, nur im Fehlerfall (ohne Redirect weil Affenformular) die Meldung zu bringen. Ich meine, als Anwender bin ich in der Regel nie so aufmerksam, alle Meldungen zu lesen. Und wenn dann nach ypsunddrölfzig Positiv-Meldungen eine negative auftauche, dann überlese ich die in meiner Haste-schon-so-oft-gelesen-Stimmung.

    Lo!

  3. hi,

    Würde gerne eure Meinung dazu hören.

    Ja, gerne ;)

    Fehlermeldungen allgemein: Wenn ich mit Templates arbeite, habe ich einen Platzhalter für die "kleinen" Fehlermeldungen, wie z.B. Name nicht eingegeben oder sowas. Ajax: Es werden nur die Platzhalter ausgetauscht, !Ajax: Die Seite wird komplett neu geladen (Template neu prozessiert).

    Bei größeren Fehlern, evntl. serverseitige Probleme (z.B. DB weg), wird der Body komplett ausgetauscht, weil es macht ja keinen Sinn, in so einem Fall noch ein Eingabeformular zu zeigen. Weitere Fehler wo ich den Body austausche: Unbekannte/Unerlaubte Parameter.

    Templates machen sich übrigens auch ganz gut, an einer bestimmten Stelle einen "Bestätigungslink" auszugeben (z.B. Record löschen???).

    Umleitungen/Redirektion/Location-Header: Nur dann machen, wenn wirklich nichts mehr schief gehen kann. Beispiel: Anmeldung erfolgreich. Wenn Fehler zu erwarten sind, würde ich keine Redirektion machen, sonst müsste eine Fehlerbehandlung über eine Session geschleift und serverseitig zwischengespeichert werden. Also wenn Du das machen möchtest.... 'Session.

    Hotti