2x Submits auf Seite, Problem³

[Hans Wurst]

Hallo @all,

auf einer Seite, befinden sich 2x Submit-Buttons, das eine ist zum vor. -und das andere zum zurück gehen.

In Falle eines Fehlers (warum auch immer, PERL gesteuert) sollte der User automatisch zurück geleitet werden, also die selbe Aktion wie zurück gehen, nur automatisiert.

Die PERL verarbeitet die Vorgänge, anhang des Button-Namen sowie Value.

Wenn ich jetzt den User beim Fehler umleiten will, kann ich einfach "document.submit()" aufrufen, aber dadurch weiß die PERL nicht wohin (vor oder zurück), gibt es eine Möglichkeit den Button simuliert zu drücken? So das der POST-Request den Namen und Value des Buttons enthält?

Danke,
H. Wurst

[hotti]

hi,

[..]gibt es eine Möglichkeit den Button simuliert zu drücken? So das der POST-Request den Namen und Value des Buttons enthält?

Name und Value kriegst Du aus der Parameterliste. Mal angenommen, beim POST wird über eine Kontrollstruktur in Deinem Script eine subfunktion aufgerufen, die HTML-ausgibt. Da hinein kannst Du auch javascript tun und evntl. auch eine JS-Funktion Deiner Wahl aufrufen.

Hotte

[Hans Wurst]

Name und Value kriegst Du aus der Parameterliste. Mal angenommen, beim POST wird über eine Kontrollstruktur in Deinem Script eine subfunktion aufgerufen, die HTML-ausgibt. Da hinein kannst Du auch javascript tun und evntl. auch eine JS-Funktion Deiner Wahl aufrufen.

Hi, hmmm, so ganz verstanden habe ich das nicht.

Es geht mir nur darum, das die PERL erkennt, was zutun ist, VOR oder ZURÜCK.

Vorname=Max&Nachname=Mustermann&Vor=yes
oder
Vorname=Max&Nachname=Mustermann&Zurueck=yes
aber du JS sieht der Request so aus
Vorname=Max&Nachname=Mustermann

Wie soll ich das mit JS lösen können?

[hotti]

hi,

Es geht mir nur darum, das die PERL erkennt, was zutun ist, VOR oder ZURÜCK.

Vorname=Max&Nachname=Mustermann&Vor=yes
oder
Vorname=Max&Nachname=Mustermann&Zurueck=yes
aber du JS sieht der Request so aus
Vorname=Max&Nachname=Mustermann

Wie soll ich das mit JS lösen können?

??? Perl soll die Parameter parsen, damit Du das mit JS lösen kannst? ???

Ok, bleiben wir bei den Parametern, hier der QUERY_STRING:

Vorname=Max&Nachname=Mustermann&Vor=yes

Mit dem Perl-Modul CGI.pm und der Methode param() parst Du die Parameter aus dem QUERY_STRING, das ergibt:

Parameter |  Value
---------------------------
Vorname   |  Max
Nachname  |  Mustermanne
Vor       |  yes
---------------------------

In einer Kontrollstruktur prüfst Du, ob der Parameter "Vor" den Wert "yes" hat, ist das der Fall rufst Du eine entsprechende Funktion vorwärts() dazu auf. Die Funktion zurück() hingegen rufst Du auf, wenn der Parameter "Zurueck" den Wert "yes" hat.

Jetzt könntest Du die Parameter=Value-Paare in Variablen packen und in der Subfunktion sowas machen, also Perl-Variablen an JS-Variablen übergeben:

print qq(
 <javascript>
  var zurueck = $zurueck;
 </javascript>
);

Hotte

[Hans Wurst]

Sorry, danke für deine Tipps, aber wir reden an einander vorbei.

Also:
Die Buttons sind vom Typ "submit", haben Namen:Wert (Vor:yes|Zurueck:yes).

Wenn ich VOR drücke, sende ich folgendes: (stark gekürzt!)
Vor=yes&Vorname=Max&Nachname=Mustermann

Wenn ich ZURUECK drücke, dann das:
Zurueck=yes&Vorname=Max&Nachname=Mustermann

Wenn ich manuell per "document.forms[0].submit();" sende, dann das:
Vorname=Max&Nachname=Mustermann

Zum Problem:
Bei einem Fehler, wird mit ein FehlerCode (Bsp: 1200, 4550 usw.) zurückgegeben, anhang dem ich sehen kann was u.U. schief gelaufen ist, bei schwerden Fehler'n soll ich den User umleiten, dazu muss ich diese "Button-Betätigung" simulieren, den nur so erhalte ich den Wert in der Parameterliste "Zurueck=yes", und nur so weiß die PERL was sie zutun hat.

Ich hoffe die Problematik ist jetzt deutlicher geworden...

[ChrisB]

Hi,

Wenn ich VOR drücke, sende ich folgendes: (stark gekürzt!)
Vor=yes&Vorname=Max&Nachname=Mustermann

Wenn ich ZURUECK drücke, dann das:
Zurueck=yes&Vorname=Max&Nachname=Mustermann

Wenn ich manuell per "document.forms[0].submit();" sende, dann das:
Vorname=Max&Nachname=Mustermann

Dann könntest du vor dem submitten noch ein hidden field ins Formular hineingenerieren, welches das gewünschte name=value-Paar darstellt.

Zum Problem:
Bei einem Fehler, wird mit ein FehlerCode (Bsp: 1200, 4550 usw.) zurückgegeben, anhang dem ich sehen kann was u.U. schief gelaufen ist, bei schwerden Fehler'n soll ich den User umleiten, dazu muss ich diese "Button-Betätigung" simulieren,

Wieso "musst" du - wo tritt der Fehler denn auf, client- oder serverseitig?

MfG ChrisB

[Hans Wurst]

Dann könntest du vor dem submitten noch ein hidden field ins Formular hineingenerieren, welches das gewünschte name=value-Paar darstellt.

Ja schon, ist aber nicht schon sowas ...

Wieso "musst" du - wo tritt der Fehler denn auf, client- oder serverseitig?

Serverseitig, z.b. bei fehlgeschlagener Adressverifizierung ect.

Ich bekomme den Code, und muss nen POST absenden, aber diese "Zurueck=yes" muss eben drinstehen.

[ChrisB]

Hi,

Dann könntest du vor dem submitten noch ein hidden field ins Formular hineingenerieren, welches das gewünschte name=value-Paar darstellt.
Ja schon, ist aber nicht schon sowas ...

Das liegt daran, dass schon das Vorhaben, die Umleitung clientseitig zu machen, "nicht schön" ist.

Wieso "musst" du - wo tritt der Fehler denn auf, client- oder serverseitig?
Serverseitig, z.b. bei fehlgeschlagener Adressverifizierung ect.

Ich bekomme den Code, und muss nen POST absenden, aber diese "Zurueck=yes" muss eben drinstehen.

Und warum musst du "ein POST absenden"?

Muss die Methode POST sein?
Soll ein fehlerhaft ausgefülltes Formular erneut angezeigt werden, mit vorbelegten Feldern? Dazu lautet das gängige Stichwort Affenformular, und das erfordert keine "Weiterleitung"; erst keine, die noch mal einen Umweg über den Client nimmt.

MfG ChrisB

[Hans Wurst]

Das liegt daran, dass schon das Vorhaben, die Umleitung clientseitig zu machen, "nicht schön" ist.

Nein nein, ihr versteht mich alle irgendwie nicht.
Wieso clientseitig? Ist doch nur ein Request.

Muss die Methode POST sein?

Ja muss, Ajax fällt leider weg.
Also:

Kunde macht Eingabe (Rechnungsadresse), diese Adresse wird verifiziert, wenn POSITIV dann kann der Kunde weiter, falls NEGATIV dann auch (hat schon seine Gründe), falls aber Fehler bei der Server-Kommunikation auftaucht, oder die Adresse garnicht vorhanden ist, dann soll der Kunde umgeleitet werden, leider aus der Fronted-Sicht.

[hotti]

hi,

Ich bekomme den Code, und muss nen POST absenden, aber diese "Zurueck=yes" muss eben drinstehen.

Genau das ist die Crux am event "onSubmit()"; da passiert bei Dir nämlich das, was ein Submit-Button machen soll und zwar an den Submit-Buttons vorbei. It means: die Parameter button_name=button_value gibts nicht im Request, egal ob POST oder GET.

Event "onSubmit()" ist daher eine schlechte Wahl für Formulare, die mehr als einen Submit-Button haben, weils nicht eindeutig ist.

Im Event "onSubmit()" eine Funktion hinterlagern, die dem Benutzer unmissverständlich mitteilt, dass er auf einen von beiden Buttons klicken muss. Das kann clientseitig erfolgen und (besser) serverseitig => Parameter "vor" || "zurück" fehlt. Oder onSubmit so gestalten, dass kein Submit erfolgt (onSubmit="tuNix(); return false;".

Hotte

[Hans Wurst]

Event "onSubmit()" ist daher eine schlechte Wahl für Formulare, die mehr als einen Submit-Button haben, weils nicht eindeutig ist.

Da wo es passieren soll, steht dem Kunden kein Formular zur Verfügung, nur Hidden-Felder (Session, ID, usw.)

Im Event "onSubmit()" eine Funktion hinterlagern, die dem Benutzer unmissverständlich mitteilt, dass er auf einen von beiden Buttons klicken muss.

Eben nicht, das soll automatisch passieren, weil ja ein Fehler ist, nix was den Kunden zu Interessieren hat.

[hotti]

hi,

Eben nicht, das soll automatisch passieren, weil ja ein Fehler ist, nix was den Kunden zu Interessieren hat.

Du, Hans, ich denke, wir sollten Dein Konzept mal überschlafen, so kommen wir nicht weiter. Sag mal, was möchtest Du überhaupt machen? Unabhängig von Perl, JavaScript...

Viele Grüße,
Horst Haselhuhn

[Hans Wurst]

Du, Hans, ich denke, wir sollten Dein Konzept mal überschlafen, so kommen wir nicht weiter. Sag mal, was möchtest Du überhaupt machen? Unabhängig von Perl, JavaScript...

Ok, überschlafen ist getan, was nun?! :)

Im Groben und ganzen:

if(Fehler) weiterleiten_schritt_zurück();
else hier_bleiben();

weiterleiten_schritt_zurück() soll automatisch erfolgen, ohne das der Kunde was sieht, was tut, was merkt, einfach umleiten, aber eben per POST.

[ChrisB]

Hi,

if(Fehler) weiterleiten_schritt_zurück();
else hier_bleiben();

Und warum statt weiterleiten_schritt_zurück kein ausgabe_alternativen_inhalts?

weiterleiten_schritt_zurück() soll automatisch erfolgen, ohne das der Kunde was sieht, was tut, was merkt, einfach umleiten, aber eben per POST.

POST-Redirects gibt es (in der Praxis) nicht, also bleibt dir da nur der Umweg über den Client. Und Lösungsvorschläge dafür hast du ja bereits bekommen.

MfG ChrisB

[Hans Wurst]

Und warum statt weiterleiten_schritt_zurück kein ausgabe_alternativen_inhalts?

Weil es in diesem Fall keine gibt und keine geben soll (Vorgabe), weil ja Fehler!!!

POST-Redirects gibt es (in der Praxis) nicht, also bleibt dir da nur der Umweg über den Client. Und Lösungsvorschläge dafür hast du ja bereits bekommen.

Naja, aber nicht akzeptable, danke trotzdem ...

[ChrisB]

Hi,

Und warum statt weiterleiten_schritt_zurück kein ausgabe_alternativen_inhalts?
Weil es in diesem Fall keine gibt und keine geben soll (Vorgabe), weil ja Fehler!!!

Ja, und?
Irgendwas wird das Dokument, auf das du bei einem Fehler weiterleiten willst, dem Nutzer ja wohl auch mitzuteilen haben. Und das könnte man eben auch ohne weiterzuleiten machen - Stichwort Affenformular.

Und Lösungsvorschläge dafür hast du ja bereits bekommen.
Naja, aber nicht akzeptable, danke trotzdem ...

Wenn du hier nur mit irgendwelchen "Vorgaben" argumentierst, und uns über die genaueren Umstände nach wie vor im unklaren lässt (mir ist immer noch nicht klar geworden, wann umgeleitet werden soll, wohin genau, und weswegen das nur clientseitig möglich sein soll; und die Antwort auf hottis Rückfrage würde mich in dem Zusammenhang auch interessieren) - dann kannst du nicht viel mehr erwarten.
Dann musst du nehmen, "was du kriegen" kannst - wenn dir das suboptimal erscheint, dann könnte das daran liegen, dass der bisherige Aufbau bzw. das Konzept das ebenfalls bereits ist (und diesen Eindruck habe ich bis jetzt immer noch).

MfG ChrisB

[Hans Wurst]

Ja, und?
Irgendwas wird das Dokument, auf das du bei einem Fehler weiterleiten willst, dem Nutzer ja wohl auch mitzuteilen haben. Und das könnte man eben auch ohne weiterzuleiten machen - Stichwort Affenformular.

Nein, das hat nichts mit der Validierung der Kunden-Eingabe zutun.
Die Rechnungsadresse wird auf Echtheit überprfüft (verifiziert), wenn die Schnittstelle zwischen unseren Servern und dem Verifizierungs-Service fehlschägt, bzw. ein Fehler verursacht, so wird der Kunde umgeleitet. Da braucht er nix zu erfahren, wozu auch? Zuviel Input für den Kunden ist auch nicht gut...

und die Antwort auf hottis Rückfrage würde mich in dem Zusammenhang auch interessieren) - dann kannst du nicht viel mehr erwarten.

Siehe oben.

PS: Das Problem hab ich jeztz gelöst, muss wohl doch ein Element nachträglich ins Dokument schreiben, und dann abschicken, auch wenns nicht schön ist.

[hotti]

hi,

if(Fehler) weiterleiten_schritt_zurück();
else hier_bleiben();

Ja gut. Nun mal ein bischen genauer, definiere "Fehler", also was meinst Du damit?

[] Eingabefehler
[] Bugs im Browser
[] Bugs im Webserver
[] Darstellungsfehler
[...]

Viele Grüße,
Horst Wachtelei