Checkbox von PHP nach HTML auslesen

[Gert Scheffler]

Ich habe ein HTML-Formular mit mehreren Zeilen mit mehreren Eingaben. "Number" und andere Typen lassen sich problemlos auslesen, Checkboxen leider nicht. Ich würde je nach Zustand der Checkbox auch gern die Werte "Rot" oder "Blau" ausgeben. Leider habe ich bisher keinen Weg gefunden um das auf dem von 1&1 empfohlenen Weg zu realisieren.

Formular-Datei (auszugsweise):

<table border=1 align=center width=70% cellPadding=0 cellSpacing=0>
	<tr height=30 align=center>
		<td width=10%>1.</td>
		<td width=30%>
			<label for="anzahl1"/>Anzahl:&nbsp;
			<input type="number" name="anzahl1" min="0" max="999" value=13/>
		</td>
		<td width=60%>
			<label for="col1"/>Farbig:
			<input type="checkbox" name="col1" value="Color1"/>
		</td>
	<tr>
</table>

Für das Auslesen dient eine PHP-Datei (auszugsweise):

foreach($_POST as $key=> $val) {
	$fmtResponse= str_replace("<$key>", $val, $fmtResponse);
}

Für die Rückmeldung dient die Datei Response.htt (auszugsweise):

<h2>Ihre Anfrage wurde gesendet</h2>
<table width=400 align=center>
	<tr>
		<td width=40%>1. Anzahl:</td>
		<td width=10%><anzahl1></td>
		<td width=50%><col1></td>
	</tr>
	..........
</table>

Angezeigte Response

Ihre Anfrage wurde gesendet

1. Anzahl: 13
2. Anzahl: 0
3. Anzahl: 7
4. Anzahl: 0
5. Anzahl: 25

Die Spalte für die Checkbox bleibt leer.

[TS]

Hallo und guten Abend,

Das liegt daran, dass Checkboxen und Radios nur dann übermittelt werden, wenn etwas ausgewählt wurde.
Da muss man dann serverseitig dafür sorgen, dass bereits ein Default gesetzt ist, der dann durch den gepostetn Wert überschrieben wird.

Grüße
TS

[TS]

Hallo und guten Abend,

Nachtrag:

Das liegt daran, dass Checkboxen und Radios nur dann übermittelt werden, wenn etwas ausgewählt wurde.
Da muss man dann serverseitig dafür sorgen, dass bereits ein Default gesetzt ist, der dann durch den gepostetn Wert überschrieben wird.

Ich habe das immer so gelöst, dass ich data, ctrl (Checkboxen und Radios), und btn (alle Submitbuttons) immer durch Namensgruppen im $_POST-Array getrennt habe:

<table border=1 align=center width=70% cellPadding=0 cellSpacing=0>
	<tr height=30 align=center>
		<td width=10%>1.</td>
		<td width=30%>
			<label for="anzahl1"/>Anzahl:&nbsp;
			<input type="number" name="data[anzahl1]" min="0" max="999" value=13/>
		</td>
		<td width=60%>
			<label for="col1"/>Farbig:
			<input type="checkbox" name="ctrl[col1]" value="Color1"/>
		</td>
	<tr>
</table>

Dann schau Dir das Post-Ergebnis an:

<?php 
$out = htmlspecialchars(print_r($_POST,1));
?>
    <pre>
        <?php echo $out; ?>
    </pre>

Dann kann man für jede Namensgruppe spezielle Default und Funktionen bereitstellen.
Manchmal bietet es sich auch noch an, die numerischen Daten auch noch auszugliedern, damit man dort gezielt fragen kann, ob mit 0 oder mit nichts geantwortet wurde.

Grüße
TS

[TS]

Hallo und guten Abend,

dieser Thread könnte sich tatsächlich noch ausweiten ;-)

Für das Auslesen dient eine PHP-Datei (auszugsweise):

foreach($_POST as $key=> $val) {
	$fmtResponse= str_replace("<$key>", $val, $fmtResponse);
}

Das sollte besser heißen:

    foreach($_POST as $key=> $val) 
    {
        $fmtResponse= str_replace("<$key>", htmlspecialchars($val, ENT_QUOTES), $fmtResponse);
    }

um XSS-Angriffe und ähnliche zu ersticken.

Wichtig für htmlspecialchars() ist dann, dass das Encoding im Script vorher gesetzt wurde, oder auch noch explizit in der Funktion angegeben wurde. Anderenfalls kann das Ergebnis auch leer bleiben. Das ergibt dann so einen "Ich-krieg-die-Kriese-Debugging-Fall", da die Kontrollausgaben dann meistens auch nicht funktionieren.

Grüße
TS

[dedlfix]

Tach!

Wichtig für htmlspecialchars() ist dann, dass das Encoding im Script vorher gesetzt wurde, oder auch noch explizit in der Funktion angegeben wurde.

Diese Funktion behandelt nur Zeichen aus dem ASCII-Bereich. Bei allen Kodierungen, die darauf aufbauen, ist es deshalb irrelevant, eine Kodierungsangabe zu machen. Generell wird ja hierzulande eine ASCII-kompatible Kodierung eingestellt sein.

dedlfix.

[TS]

Hallo und guten Tag,

Wichtig für htmlspecialchars() ist dann, dass das Encoding im Script vorher gesetzt wurde, oder auch noch explizit in der Funktion angegeben wurde.

Diese Funktion behandelt nur Zeichen aus dem ASCII-Bereich. Bei allen Kodierungen, die darauf aufbauen, ist es deshalb irrelevant, eine Kodierungsangabe zu machen. Generell wird ja hierzulande eine ASCII-kompatible Kodierung eingestellt sein.

Und was passiert dann, wenn sie Zeichen außerhalb des ASCII-Bereiches zu futtern bekommt?
Wann sollte man ini_set('default_charset', [...] ) verwenden?

Grüße
TS

[dedlfix]

Tach!

Diese Funktion behandelt nur Zeichen aus dem ASCII-Bereich. Und was passiert dann, wenn sie Zeichen außerhalb des ASCII-Bereiches zu futtern bekommt?

Nichts. Wird unverändert durchgelassen.

Wann sollte man ini_set('default_charset', [...] ) verwenden?

Ich würde es gar nicht verwenden, sondern fest einstellen. Man kann das sogar komplett ignorieren, wenn man weder iconv noch mbstring verwendet oder deren spezialisierte Funktionen zum Konfigurieren verwendet, sowie wenn man den Content-Type + Charset-Angabe stets mit header() erledigt.

dedlfix.

[TS]

Hallo und guten Morgen,

Diese Funktion behandelt nur Zeichen aus dem ASCII-Bereich. Und was passiert dann, wenn sie Zeichen außerhalb des ASCII-Bereiches zu futtern bekommt?

Nichts. Wird unverändert durchgelassen.

Ist es nicth vielmer so, dass htmlspecialchars() gar keine Ausgabe mehr macht, wenn es mit der Kodierung nicht klar kommt? Das kann bei vermischten Kodierungen schnell passieren.

Grüße
TS

[Matthias Apsel]

Hallo TS,

Ist es nicth vielmer so, dass htmlspecialchars() gar keine Ausgabe mehr macht, wenn es mit der Kodierung nicht klar kommt? Das kann bei vermischten Kodierungen schnell passieren.

Nein. Die Funktion verändert einige wenige ASCII-Zeichen unabhängig von der Kodierung.

Bis demnächst
Matthias

[TS]

Hallo und guten Tag,

Ist es nicth vielmer so, dass htmlspecialchars() gar keine Ausgabe mehr macht, wenn es mit der Kodierung nicht klar kommt? Das kann bei vermischten Kodierungen schnell passieren.

Nein. Die Funktion verändert einige wenige ASCII-Zeichen unabhängig von der Kodierung.

Könnte es sein, dass Ihr beide das Problem nicht kennt?
Google

Und bitte auch hier im Archiv gucken, da wurde das auch schon thematisiert.
Archiv Beispiel

Grüße
TS

[dedlfix]

Tach!

Könnte es sein, dass Ihr beide das Problem nicht kennt?

Kann gut sein.

Google

Das ist der Fall, wenn man UTF-8 als default_charset eingestellt hat und stattdessen ISO-8859-x verwendet. Andersrum ist das jedoch kein Problem.

PHP 5.6 hat den Default-Wert für default_charset zu UTF-8 geändert. Ab da wird es also problematisch, wenn man den Konfigurationswert nicht ändert, keine Angabe als dritten Parameter der Funktion macht und ISO-8859-x verwendet.

dedlfix.

[TS]

Hallo und guten Tag,

Könnte es sein, dass Ihr beide das Problem nicht kennt?

Kann gut sein.

Google

Das ist der Fall, wenn man UTF-8 als default_charset eingestellt hat und stattdessen ISO-8859-x verwendet. Andersrum ist das jedoch kein Problem.

PHP 5.6 hat den Default-Wert für default_charset zu UTF-8 geändert. Ab da wird es also problematisch, wenn man den Konfigurationswert nicht ändert, keine Angabe als dritten Parameter der Funktion macht und ISO-8859-x verwendet.

Ich habe das Gedankenspiel immer in meinen "bist-Du-noch-da?"-Requests, also bei der automatischen Überprüfung von langen Linklisten auf Antwort und auf HTTP-Header und <Head>-Bereich (Meta-Tags).

Hier habe ich das Thema nur aufgewärmt, weil Gert Scheffler ein offnes Formularsystem benutzt, in dem augenscheinlich alles ausgewertet wird, was per Post gesendet wird. Das ist nicht ganz ungefährlich, wenn man die Daten nicht sicher kastriert (escaped, umkodiert, ...).

Grüße
TS

[dedlfix]

Tach!

Ich habe das Gedankenspiel immer in meinen "bist-Du-noch-da?"-Requests, also bei der automatischen Überprüfung von langen Linklisten auf Antwort und auf HTTP-Header und <Head>-Bereich (Meta-Tags).

Wenn du nicht weißt, in welcher Kodierung deine Daten reinkommen, sag dem htmlspecialchars(), es sei ISO-8859-x. Damit sollte es die Nicht-ASCII-Daten durchreichen und die HTML-Zeichen behandeln.

dedlfix.

[pl]

Moin,

Die Spalte für die Checkbox bleibt leer.

Der Value einer checkbox wird gesendet wenn:

• das Attribut name gesetzt wurde
• die checkbox gecheckt ist

MfG

[Felix Riesterer]

Lieber pl,

Der Value einer checkbox wird gesendet wenn:

• das Attribut name gesetzt wurde
• die checkbox gecheckt ist

sehr richtig (+1 von mir), sodass man dann in PHP so vorgehen muss, wenn man XSS vermeiden will:

// define what user may put in
$input = array(
    'name1' => '', // default value empty string
    'name2' => false, // checkbox - default is false
    'namex' => ''
);

// update with POST values
foreach ($_POST as $key => $value) {

    // do we expect such a key?
    if (array_key_exists($key, $input))
        $input[$key] = $value;
    }
}

// checkbox 'name2' set?
if ($input['name2']) {
    // yes!
}

Durch die lose Typisierung in PHP kann das vom Browser üblicherweise für angewählte Checkboxen übermittelte "on" (es sei denn, Du hast mit dem value-Attribut etwas anderes festgelegt) als eine Art true interpretieren, sodass if ($input['name2']) genau dann als true verstanden wird, wenn die Checkbox angewählt war. Wäre sie das nicht, so hätte der Browser deshalb kein Schlüssel-Wert-Paar für "name2" übermittelt - in $_POST wäre der Schlüssel dann nicht vorhanden gewesen und das in $input voreingestellte false für "name2" eben false geblieben.

Liebe Grüße,

Felix Riesterer.

[pl]

Lieber pl,

Lieber Felix ;)

Der Value einer checkbox wird gesendet wenn:

• das Attribut name gesetzt wurde
• die checkbox gecheckt ist

sehr richtig (+1 von mir), sodass man dann in PHP so vorgehen muss, wenn man XSS vermeiden will:

Danke !

Im Prinzip muss man nur mit Schlüsselparametern richtig umgehen können -- Alte Schule, wird heute leider überhaupt nicht mehr kommuniziert.

Schöner Sonntag!

[TS]

Hallo und guten Abend,

// define what user may put in
$input = array(
    'name1' => '', // default value empty string
    'name2' => false, // checkbox - default is false
    'namex' => ''
);

// update with POST values
foreach ($_POST as $key => $value) {

    // do we expect such a key?
    if (array_key_exists($key, $input))
        $input[$key] = $value;
    }
}

// checkbox 'name2' set?
if ($input['name2']) {
    // yes!
}

Ich würde da sogar noch einen Schritt weiter gehen und die "Abklapperliste" von der anderen Seite angehen:

foreach ($input as $key => $value) 
{
    ### ...
}

Dann werden nur Post-Parameter abgefragt, die in der Liste stehen, also auch erwartet werden und man hat immer gleich den Default, auch wenn im $_POST kein Paramter dazu drinsteht (wie bei Checkbox oder Radio z. B.)

Grüße
TS

[Gert Scheffler]

Hallo,

als Initiator des Threads danke ich allen, die Anregungen gegeben haben.

Ich bin inzwischen dem Ziel sehr nahe gekommen und kann nicht einmal genau sagen, was den Durchbruch gebracht hat, jedenfalls nichts Grundsätzliches. Da ich relativ neu in PHP eingestiegen bin, habe ich mich immer mal wieder Fehler rein gebaut, wo ich welche beseitigen wollte. Jetzt sieht die Response bis auf die Zwischenräume so aus, wie sie aussehen sollte:

**Ihre Anfrage wurde gesendet

1. Anzahl Originale:	13	Farbig	Längste Kante > 6 cm
2. Anzahl Originale:	7		Längste Kante > 6 cm
3. Anzahl Originale:	25	Farbig	
4. Anzahl Originale:	0		
5. Anzahl Originale:	0**

Hinter den beiden Spalten mit 'Farbig' und 'Längste Kante...' stehen die Checkboxen, deren Values genau das als Inhalte haben. Wo sie nicht angeklickt wurden, erscheint wunschgemäß auch kein Eintrag. Das klappt bei der Response automatisch.

Bei der Auftrags-Mail klappt es leider nicht ganz. Geklickte Checkboxen erscheinen mit dem richtigen Wert. Bei nicht geklickten Checkboxen wird als Zeichenkette nur der Variablenname angezeigt:

**Es liegt folgende Anfrage vor:
    1. Anzahl Originale: 13    Farbig    Längste Kante > 6 cm
    2. Anzahl Originale: 7    <col2>    Längste Kante > 6 cm
    3. Anzahl Originale: 25    Farbig    <bor3>
    4. Anzahl Originale: 0    <col4>    <bor4>
    5. Anzahl Originale: 0    <col5>    <bor5>
**

Ich könnte damit leben, aber schöner wäre es, wenn man eine eigentlich nicht im Übergabe-Array enthaltene Variable (weil die Checkbox nicht geklickt wurde), in PHP aufbereiten und dann mit Wert ergänzen könnte oder dem Layout eine ganz andere php-Variable unterschieben könnte. Da werde ich nochmal recherchieren und experimentieren und vielleicht auch nochmal das Forum konsultieren. Erst wenn die Grundfunktionalität steht, werde ich alle anderen Anregungen zu Zeichensatz, Kodierung und Sicherheit angehen.

Danke zunächst mal an alle Ratgeber.

[Felix Riesterer]

Lieber Gert,

Bei der Auftrags-Mail klappt es leider nicht ganz. Geklickte Checkboxen erscheinen mit dem richtigen Wert. Bei nicht geklickten Checkboxen wird als Zeichenkette nur der Variablenname angezeigt:

dann verwendest Du einen anderen Ansatz, als ich ihn Dir gezeigt habe. Mit meinem Ansatz hast Du vordefinierte Anfangswerte (Leerstrings), die Du genau so in Deinen Bestelltext einfügen kannst:

$input = array(
    'name1' => '',
    'name2' => '', // kommt von Checkbox, die value hat
    'name3' => ''
);

// mit $_POST updaten
foreach ($_POST as $key => $value) {

    if (array_key_exists($key, $input))
        $input[$key] = $value;
    }
}

// Mailtext
$order = 'Anzahl Originale: {$name1} {$name2} {$name3}'."\r\n";

// Platzhalter in Mailtext ersetzen
foreach ($input as $key => $value) {
    $order = str_replace('{$'.$key.'}', $value, $order);
}

Liebe Grüße,

Felix Riesterer.

[Gert Scheffler]

Hallo Felix,

ich finde gern Lösungen aus meinen Überlegungen und meinem momentanen Verständnis heraus und lerne dabei dazu. Das soll nicht heißen, dass ich Deine Anregungen ignoriere. Und ich werde, nachdem jetzt eine funktionstüchtige Lösung existiert, alle Anregungen nochmal aufmerksam durchleuchten.

Aus dem wachsenden Verständnis habe ich eine Lösung für das zuletzt aufgeführte Problem gefunden, dass die Variablen in der Response richtig waren und in der Auftrags-Mail als Variablennamen ausgegeben wurden. Wenn eine Checkbox inaktiv ist, ergänze ich die fehlende Variable mit dem Wert "". Damit wird die Variablenbeschreibung vollständig und das Verhalten in beiden Ausgaben gleich.

if (isset($_POST['bor1'])==FALSE) {$_POST['bor1']='';}

Ein weiteres Problem hatte ich hier nicht angesprochen: Eine Textnachricht wurde in der Mail richtig umgebrochen, aber in der Response als fortlaufender Text ohne Zeilenumrüche ausgegeben. Nachdem ich die Sache mit den POST-Variablen einigermaßen verstanden hatte, lag auch hier die Lösung nahe. Ich habe eine zusätzliche Variable nachricht_res eingeführt und die Original-Nachricht mit nl2br() umcodiert:

//nl2br für zeilengerechte Formatierung funktioniert nur für Response, nicht für Mail
$_POST['nachricht_res']=nl2br($_POST['nachricht']);

Die Nachricht in der Mail basiert weiterhin auf der Originalnachricht.

Danke nochmal Dir und allen anderen Beteiligten.

[TS]

Hallo und guten Morgen,

Noch ein paar Überlegungen:

if (isset($_POST['bor1'])==FALSE) {$_POST['bor1']='';}

Es ist so herum möglich, auf isset() zu prüfen, wenn Du also das $_POST-Array iterierst. Begründung: über $_POST können nur textuelle Werte kommen, die dann entweder als String oder als Array aufbereitet werden. der Wert NULL kann also nicht vorkommen.

Anderenfalls müsstest Du mit der Funktion array_key_exists() prüfen, ob das Element vorhanden ist.

Obige Abfrage kann auch anders formuliert werden:

if (!isset($_POST['bor1'])) {$_POST['bor1']='';}

Ein weiteres Problem hatte ich hier nicht angesprochen: Eine Textnachricht wurde in der Mail richtig umgebrochen, aber in der Response als fortlaufender Text ohne Zeilenumrüche ausgegeben. Nachdem ich die Sache mit den POST-Variablen einigermaßen verstanden hatte, lag auch hier die Lösung nahe. Ich habe eine zusätzliche Variable nachricht_res eingeführt und die Original-Nachricht mit nl2br() umcodiert:

Da würde ich eher dazu neigen, in der HTML-Response ein <pre> ... </pre> zu spendieren um die gesamte Quittung, da ja die eMail auch im Plaintext-Format erstellt wird. Dann kann der Benuzter eher sehen, wie die Mail aussehen wird. Durch <pre> kommen dann sowohl die Umbrüche, als auch die Einrückungen per Whitespaces zur Geltung.

Grüße
TS

[Gert Scheffler]

if (!isset($_POST['bor1'])) {$_POST['bor1']='';}

Ist kürzer und ich habe es eingearbeitet

Da würde ich eher dazu neigen, in der HTML-Response ein <pre> ... </pre> zu spendieren um die gesamte Quittung, da ja die eMail auch im Plaintext-Format erstellt wird. Dann kann der Benuzter eher sehen, wie die Mail aussehen wird. Durch <pre> kommen dann sowohl die Umbrüche, als auch die Einrückungen per Whitespaces zur Geltung.

Das mit der <PRE> war mir völlig neu, vereinfacht aber die Handhabung deutlich.

Nur wenn es Dich interessiert: Ich habe jetzt oben die gegenwärtige (vorläufige) [Adresse der Seite]stehen. Da wird im März noch eine echte Domain draus. Eine Sache muss ich noch verbessern: Mit der Feststellung von Fehlern sind die Einträge im Formluar weg. Das ist natürlich unprofesionell.

Grüße

Gert

[TS]

Hallo und guten Abend,

den Rest bekommst Du auch noch hin :-)

Erstmal solltest Du einen Seiten-Grundrahmen bauen, in den dann jeweils die Inhalte eingestanzt werden. Dann steht die Quittung nachher auch nicht so beziehungslos im Raum. So fehlt auf jeden Fall ein Rücklink zur Seite.

Und dann die passenden Input-Typen auswählen. Dann werden die von den Browsern besser unterstützt, besonders wichtig bei Mobilgeräten. Bei email hapert es da noch.

Ich würde das <pre> übrigens über die gesamte Antwort legen, nicht nur über die Textarea.

Grüße
TS

[Matthias Apsel]

Hallo TS,

Und dann die passenden Input-Typen auswählen. […] Bei email hapert es da noch.

Meinst du <input type="email">? Warum sollte es hapern?

Bis demnächst
Matthias

[TS]

Hallo und guten Abend,

Und dann die passenden Input-Typen auswählen. […] Bei email hapert es da noch.

Meinst du <input type="email">? Warum sollte es hapern?

Oh, da war Gert wohl sehr schnell. Eben hatte er noch keine speziellen Inputtypen festgelegt für die drei einzeiligen Textfelder.

?

Sind doch immer noch auf Defaulttype Text.

Grüße
TS

[Matthias Apsel]

Hallo TS,

Und dann die passenden Input-Typen auswählen. […] Bei email hapert es da noch.

Meinst du <input type="email">? Warum sollte es hapern?

Oh, da war Gert wohl sehr schnell. Eben hatte er noch keine speziellen Inputtypen festgelegt für die drei einzeiligen Textfelder.

?

Sind doch immer noch auf Defaulttype Text.

Ah. Jetzt weiß ich auch, was du mit „Bei email hapert es da noch.“ meinst.

Du meinst, Gert soll type="email" verwenden. Ich hatte gelesen, die Browserunterstützung von type="email" ist noch nicht gut.

Bis demnächst
Matthias

[TS]

Hallo und guten Morgen,

Ah. Jetzt weiß ich auch, was du mit „Bei email hapert es da noch.“ meinst.

Du meinst, Gert soll type="email" verwenden. Ich hatte gelesen, die Browserunterstützung von type="email" ist noch nicht gut.

Genau ;-)

Aber er hat noch mehr zu tun mit seinem Webseitenaufbau. Er sollte besser vorne anfangen.

Grüße
TS

[Gert Scheffler]

Aber er hat noch mehr zu tun mit seinem Webseitenaufbau. Er sollte besser vorne anfangen.

Er (ich) fängt sowieso von vorne an und das hat wohl jeder mal. Deswegen bin ich froh für alle Tips, die hier gekommen sind. Ich habe in den letzten beiden Tagen viele Details angepasst. Dazu gehören der irgendwo erwähnte Zurück-Button und in Verbindung mit 'monospace' und 'pre' die Gestaltung des tabellarischen Layouts der Response bzw. der Fehler-Meldung, außerdem viele Prüfungen der Eingaben. Wer möchte, kann ja mal auf die Seite schauen:

[http://www.drschef.de/DiasScannen/]

Im Großen und Ganzen bin ich vielleicht übern Berg. Es hat schon beim Test gestört, dass der gelobte Chrome-Browser das Formular beim Rücksprung nicht wiederherstellt. Dagegen klappt das beim IE, Edge und Firefox problemlos. Dazu gibt es im Netz natürlich wieder ein AddOn, was ich ausprobiert habe. Ging (natürlich) nicht. Auf weitere Recherchen erfährt man, dass das Tool zur Zeit tatsächlich nicht zu gehen scheint, aber schon gibt es eine Beta, die das Problem beheben soll.

Wie schon gesagt. Manche Dinge muss man einfach aussitzen.

Gruss an alle Mitwirkenden.

[Auge]

Hallo

Es hat schon beim Test gestört, dass der gelobte Chrome-Browser das Formular beim Rücksprung nicht wiederherstellt. Dagegen klappt das beim IE, Edge und Firefox problemlos. Dazu gibt es im Netz natürlich wieder ein AddOn, was ich ausprobiert habe. Ging (natürlich) nicht. Auf weitere Recherchen erfährt man, dass das Tool zur Zeit tatsächlich nicht zu gehen scheint, aber schon gibt es eine Beta, die das Problem beheben soll.

Sei dir dessen bewusst, dass es niemandem sonst hilft, wenn du ein Browserplugin zur Umgehung eines dir missfallenden Browserverhaltens benutzt. Im Zweifelsfall kennen die Chrome-Benutzer dieses Verhalten und halten es für normal, da sie es nicht anders oder zumindest auch von anderen Seiten kennen.

Tschö, Auge

[Gert Scheffler]

Hallo Auge,

Sei dir dessen bewusst, dass es niemandem sonst hilft, wenn du ein Browserplugin zur Umgehung eines dir missfallenden Browserverhaltens benutzt. Im Zweifelsfall kennen die Chrome-Benutzer dieses Verhalten und halten es für normal, da sie es nicht anders oder zumindest auch von anderen Seiten kennen.

Bin ich mir voll bewusst. Die Sache mit dem Plugin war eher ironisch gemeint. Aber für den Test auf fehlerhafte Eingaben in über 30 Feldern in Kombination (wenn a, dann b usw.) hätte es mir viel Zeit gespart. Das mit dem 'Aussitzen' war auch etwas scherzhaft gemeint: Da viele Browser die Rückspeicherung gewährleisten, könnte es eine folgende Version von Chrome vielleicht ebenfalls anbieten.

Gruß drschef

[TS]

Hallo und guten Tag,

[http://www.drschef.de/DiasScannen/]

Es hat schon beim Test gestört, dass der gelobte Chrome-Browser das Formular beim Rücksprung nicht wiederherstellt.

Bitte definiere "Rücksprung" etwas genauer!

Da könnte ein recht umfangreiches Thema auf Dich zukommen. Für den Anfang sei mal dahingesagt, dass es besser ist, auf einen Post-Request nicht mit einem Status 200 + Daten zu antworten, wie PHP das leider macht, sondern mit einem Status 201 und einer neuen Ressource, die nur für den letzten Request gültig ist. Ich habe jetzt keine Möglichkeit zu kontrollieren, ob das in allen gängigen Browsern noch zum Neuladen der Antwortressource (und zum Löschen des Post-Buffers) führt.

Das stelle ich hier jetzt mal in den Raum zum llgemeinen Test. :-)

Grüße
TS

[Gert Scheffler]

Hallo TS

Bitte definiere "Rücksprung" etwas genauer!

Der Rücksprung erfolgt in den Dateien byerror.htt und response.htt auf folgende Art

<form>
	<input Type="button" VALUE="Zur&uuml;ck" onClick="history.go(-1);return true;">
</form>

Vor allen Dingen bei einer Fehlermeldung (byerror) wäre es natürlich schön, wenn die bisherigen (teils fehlerhaften) Werte wieder zur Korrektur angeboten würden.

Gruß drschef

[TS]

Hallo und guten Morgen,

Der Rücksprung erfolgt in den Dateien byerror.htt und response.htt auf folgende Art

<form>
	<input Type="button" VALUE="Zur&uuml;ck" onClick="history.go(-1);return true;">
</form>

Vor allen Dingen bei einer Fehlermeldung (byerror) wäre es natürlich schön, wenn die bisherigen (teils fehlerhaften) Werte wieder zur Korrektur angeboten würden.

Das realisierst Du auf dem Server im Verarbeitungsskript mit Sessionvariablen.

Wenn die Felder bezüglich der Gültigkeit voneinander abhängig sind, musst Du dein Formular ggf. sogar mehrstufig aufbauen ("Expertensystem").

Grüße
TS

[Matthias Apsel]

Hallo Gert Scheffler,

<form>
	<input Type="button" VALUE="Zur&uuml;ck" onClick="history.go(-1);return true;">
</form>

Von der nicht notwendigen Verst&uuml;mmelung der &Uuml;ml&auml;ute mal abgesehen, ist das eine ganz schlechte Idee. Auch das form-Element ist nicht notwendig und der click-Handler sollte ins JavaScript. Die inkonsistenten Schreibweisen der Attributnamen würden mir auch einen Hauch von Unprofessionalität suggerieren.

Gib die Fehlermeldung auf derselben Seite aus. Dazu nimmst du alle eingegebenen Werte entgegen und füllst das Formular mit diesen Werten neu aus. So brauchst du dich nicht darauf zu verlassen, dass der Browser das von sich aus macht.

Bis demnächst
Matthias

[Gert Scheffler]

Hallo Matthias,

Gib die Fehlermeldung auf derselben Seite aus. Dazu nimmst du alle eingegebenen Werte entgegen und füllst das Formular mit diesen Werten neu aus. So brauchst du dich nicht darauf zu verlassen, dass der Browser das von sich aus macht.

Würde das nicht bedeuten, dass das Formular auch über php aufgebaut wird. Ich bin den Empfehlungen von 1&1 gefolgt und genau umgekehrt vorgegangen. Das Fromular ist in eine normale HTML-Seite integriert. Das schien mir auch vernünftig, weil man da alles im Blick hat. Der php-Teil wird dann über

<input type="submit" value="Anfrage senden">

gestartet.

Auch das form-Element ist nicht notwendig und der click-Handler sollte ins JavaScript.

Werde ich als nächstes machen. Danke.

Die inkonsistenten Schreibweisen der Attributnamen würden mir auch einen Hauch von Unprofessionalität suggerieren.

Was heißt hier Hauch und was ist genau mit der Inkonsistenz der Attributnamen gemeint? Und Unprofessionalität darf nicht verwundern. Ich habe den 'Keks' php gerade erst am Rand angeknabbert und habe in meinem Bekanntenkreis niemand, der mir über die Schulter schaut oder darauf klopft.

Ich bleibe weiter am Ball.

[Matthias Apsel]

Hallo Gert Scheffler,

Gib die Fehlermeldung auf derselben Seite aus. Würde das nicht bedeuten, dass das Formular auch über php aufgebaut wird.

Ja. Allerdings letztendlich in ein und derselben PHP-Datei.

WENN (Formulardaten vorhanden)
DANN
    WENN (keine Fehler vorhanden)
    DANN Daten weiterverarbeiten
    SONST Formular mit übergebenen Werten füllen und wieder vorlegen
SONST
    leeres Formular erstellen

Programmiertechnisch muss man dann schauen, wie man es anstellt, dass man sich möglichst wenig wiederholt. Es wäre zum Beispiel nicht klug, wenn man für das leere Formular und das zur Wiedervorlage doppelt fast denselben Code noch mal schreibt.

Damit du nur wenige Roundtrips zum Server hast, möchtest du vorher mit den Möglichkeiten von HTML (und JavaScript) schon möglichst viele Fehler ausschalten und ein Abschicken nur dann erlauben, wenn keine offensichtlichen Fehler im Formular sind. Die serverseitige Prüfung ist trotzdem unbedingt notwendig.

<input type="submit" value="Anfrage senden">

Für buttons gibt es das button-Element.

Auch das form-Element ist nicht notwendig und der click-Handler sollte ins JavaScript.

Werde ich als nächstes machen. Danke.

Brauchst du ja nicht, weil du es ja anders machst ;-)

Die inkonsistenten Schreibweisen der Attributnamen würden mir auch einen Hauch von Unprofessionalität suggerieren.

Wenn man „Type“, „VALUE“ und „onClick“ in einer Zeile hat, wirkt es so, als wäre das von irgendwoher zusammenkopiert. Tipp: Schreibe Elemente und Attribute (und auch Werte)^[1] konsequent klein.

Dass auch dein HTML stark verbesserungswürdig ist, wurde am Rande auch schon angedeutet. (Tabellenlayout, misbilligte Attribute, Abstände durch feste Leerzeichen, label, die keinen input-Partner haben und falsch geschlossen sind)

Bis demnächst
Matthias

---

1. Du hast Attributwerte, die gemäß Rechtschreibregeln zu behandeln sind. ↩︎

[TS]

Hallo und guten Abend,

Gib die Fehlermeldung auf derselben Seite aus.

Der Tipp ist noch nicht vollständig.
Da geht es um Status 200, 201 und 205.

Die Daten-Antworten dazu kann man nicht so ohne weiters alle "auf derselben Seite" ausgeben.

Ich melde mich morgen früh nochmal vom Desktop dazu ;-)

Grüße
TS

[Gert Scheffler]

Hallo TS,

Ich habe heute meine Organisation so umgestellt, dass die index.html eine Kontakt.php ruft, welche die Formularseite erzeugt. Beim Senden des ausgefüllten Formulars wird eine KontaktAction.php aktiviert, die ein Dutzend Prüfungen macht, entsprechende Fehlerkommentare erzeugt und dann die Schlussbilanz mit der Fallunterscheidung 'Anfrage wurde übermittelt' bzw. 'Beheben Sie Ihre Fehler' ausgibt. Die eingetragenen Inhalte bleiben sogar erhalten und können korrigiert werden.

Gib die Fehlermeldung auf derselben Seite aus.

Das klappt noch nicht. Die folgende Variante wurde irgendwo empfohlen, funktioniert aber nicht:

Kontakt.php

<html>
    <body>
        <form action="Kontakt.php" method="POST" enctype="text" autocomplete="on">
            <table border=0 width=800 cellPadding=0 cellSpacing=0 align="center">
                ...
                <tr>
                    <td>
                        <input type="text" name="test" id="03" value="<?php echo $resultat; ?>" />
                    </td>
                </tr>
            </table>	
	</form>
    </body>
</html>

wobei $resultat für die Summe der Prüfergebnisse steht.

[pl]

hi,

<form action="Kontakt.php" method="POST" enctype="text" autocomplete="on">

Unsinniger Enctype. Lass diese Angabe einfach weg, das funktioniert per Default.

MfG

[Gert Scheffler]

Hallo PL,

Unsinniger Enctype. Lass diese Angabe einfach weg, das funktioniert per Default.

Schon geschehen.

Ich habe inzwischen den Aufruf nochmal verändert, in dem ich das Formular Kontakt.php von KontaktAktion.php am Ende wieder aufrufe. Da erscheinen alle Prüf-Kommentare im neuen Formular von oben her. Aber es ist dann wirklich ein neues Formular, d.h. die Eingaben sind wieder weg. Das ist mein Problem für morgen.

[Dr. Gert Scheffler]

Ich habe seit meiner letzten Meldung das Projekt (für mich) zufriedenstellend abgeschlossen. Die Checkboxen waren der Auslöser. Auch Folgendes gelang nicht auf Anhieb:

• Umgang im Formular mit Checkboxen
• Umgang im Formular mit Textarea
• Ausgabe von Fehler- und Erfolgsmeldungen in das Anfrage-Formular
• Erhaltung der vorgenommenen Eingaben im Anfrage-Formular und Korrektur

Das war ausgehend von vorheriger völliger Unkentnnis bei PHP nur dank der eingegangenen Hinweise von allen Seiten möglich.

Auch das Finden der richtigen Aufruffolge hat etwas Mühe gemacht. Hier ist sie:

index.html => Kontakt.php => KontaktAction.php => Mail.htt | | <============

Danke allen Helfern. Wenn's wieder mal so klappt.