if/else
Bernd
- php
Guten morgen,
was stimmt hier nicht?
$begin = new DateTime( $_POST["transportauftrag_von"] );
if ($_POST["transportauftrag_bis"] == "") {
$end = new DateTime( $p_bis );
} else {
$end = new DateTime( $_POST["transportauftrag_bis"] );
}
Wenn $_POST["transportauftrag_von"] leer ist, wird nicht $end = new DateTime( $p_bis ); genommen warum? Ich habe $_POST["transportauftrag_von"] schon mit echo ausgeben lassen da steht nicht drin.
Tach!
was stimmt hier nicht?
$begin = new DateTime( $_POST["transportauftrag_von"] ); if ($_POST["transportauftrag_bis"] == "") { $end = new DateTime( $p_bis ); } else { $end = new DateTime( $_POST["transportauftrag_bis"] ); }
Wenn $_POST["transportauftrag_von"] leer ist, wird nicht $end = new DateTime( $p_bis ); genommen warum?
Wenn du $_POST["transportauftrag_von"]
prüfen möchtest, musst du es auch verwenden und nicht etwas anderes.
Ich habe $_POST["transportauftrag_von"] schon mit echo ausgeben lassen da steht nicht drin.
Nimm lieber var_dump() für Kontrollausgaben. Das zeigt an, was wirklich ist und keinen in einen String konvertierten Wert, wie es ein echo macht.
dedlfix.
Wenn du
$_POST["transportauftrag_von"]
prüfen möchtest, musst du es auch verwenden und nicht etwas anderes.
Sorry, war ein Fehler beim kopieren, ich meinte natürlich wie es auch im Code steht $_POST["transportauftrag_bis"]
Nimm lieber var_dump() für Kontrollausgaben. Das zeigt an, was wirklich ist und keinen in einen String konvertierten Wert, wie es ein echo macht.
Wenn ich var_dump($_POST["transportauftrag_bis"]);
mir ausgeben lasse erhalte ich
string(0) ""
steht also tatsächlich nichts drin?
Hi,
Wenn ich
var_dump($_POST["transportauftrag_bis"]);
mir ausgeben lasse erhalte ichstring(0) ""
was ergibt vardump($_POST);
?
cu,
Andreas a/k/a MudGuard
Tach!
Wenn ich
var_dump($_POST["transportauftrag_bis"]);
mir ausgeben lasse erhalte ichstring(0) ""
was ergibt
vardump($_POST);
?
Nicht vorhandene Einträge hätten bei var_dump() NULL ergeben (bei echo nur einen Leerstring). Zuzüglich zu einer Notice, die man bei E_ALL im error_reporting zu sehen bekommt.
dedlfix.
😱 Jetzt bin ich etwas überrascht
["transportauftrag_bis"]=> string(1) " "
Da ist ein Leerzeichen drin. Habe ich die Möglichkeit dieses zu entfernen? Und warum hatvar_dump($_POST["transportauftrag_bis"]); mir dieses nicht angezeigt?
Tach!
["transportauftrag_bis"]=> string(1) " "
Da ist ein Leerzeichen drin. Habe ich die Möglichkeit dieses zu entfernen? Und warum hatvar_dump($_POST["transportauftrag_bis"]); mir dieses nicht angezeigt?
Beobachtungsfehler wäre mein Erklärungsversuch. var_dump() kann nicht zwei verschiedene Ausgaben zum selben Wert erzeugen und er ändert sich auch nicht zwischen zwei Tests im selben Request.
dedlfix.
Ok, ich schau also ob es ein Leerzeichen gibt und entfernen dieses
$begin = new DateTime( $_POST["transportauftrag_von"] );
if (trim($_POST["transportauftrag_bis"]) == "") {
$end = new DateTime( $p_bis );
} else {
$end = new DateTime( $_POST["transportauftrag_bis"] );
}
Muss ich auf sonst noch etwas achten? Ich frage mich auch, woher das Leerzeichen im Imput Feld kommt.
Hallo Bernd,
Ok, ich schau also ob es ein Leerzeichen gibt und entfernen dieses
if (trim($_POST["transportauftrag_bis"]) == "") {
Du entfernst es hier ausschließlich für die Prüfung.
Bis demnächst
Matthias
Hallo,
stimmt, ich muss es auch noch beim eintragen beachten. Danke für den Hinweis.
Tach!
Ok, ich schau also ob es ein Leerzeichen gibt und entfernen dieses
Ja, wenn das ein möglicher Eingabefehler ist, dann sollte man das berücksichtigen. Überflüssige Leerzeichen vorn und hinten wegzutrimmen, ist meist auch anderenorts keine schlechte Idee.
Muss ich auf sonst noch etwas achten? Ich frage mich auch, woher das Leerzeichen im Imput Feld kommt.
Frag lieber den Code. Ist es bereits drin, wenn du das Eingabefeld erstellst? Bist du sicher, dass weder du noch irgendein Javascript es in das Feld oder die zum Server gesendeten Daten bringt?
dedlfix.
Ok, ich schau also ob es ein Leerzeichen gibt und entfernen dieses
Wozu? Ob eins oder mehr als 1 Leerzeichen oder gar keins, das Ergebnis new DateTime()
ist dasselbe!
Aber Deine Eingaben solltest Du schon prüfen ob die programmgefällig sind. Und auch ob es sich um ein gültiges Datum handelt. MFG
Tach!
Ok, ich schau also ob es ein Leerzeichen gibt und entfernen dieses
Wozu? Ob eins oder mehr als 1 Leerzeichen oder gar keins, das Ergebnis
new DateTime()
ist dasselbe!
Kann es sein, dass es deiner geschätzten Aufmerksamkeit entgangen ist, dass das Problem nicht bei new DateTime()
sondern beim Vergleich mit einem Leerstring auftrat und überflüssige Leerzeichen zumindest dafür entfernt werden müssen?
dedlfix.
Achja nochwas Bernd,
Deine Logik solltest Du mal überdenken. D.h., es fängt damit an, den Benutzer darauf hinzuweisen was er da einzugeben hat. Und daß keine Eingabe heißt: Aktuelles Datum. Dann hast Du nur noch zu prüfen, ob bei der Eingabe eines Datum das Objekt erstellt werden konnte, was soviel heißt daß das eingegebene Datum gültig ist.
Auf jeden Fall würde ich das Ergebnis (was PHP daraus macht) nocheinmal dem Benutzer zeigen damit er das bestätigen kann.
Siehst Du, Dein Leerzeichenvergleich löst sich mit der richtigen Herangehensweise in Luft auf 😉 MFG
Tach!
Deine Logik solltest Du mal überdenken. D.h., es fängt damit an, den Benutzer darauf hinzuweisen was er da einzugeben hat. Und daß keine Eingabe heißt: Aktuelles Datum.
Das ist aber laut gezeigtem Code nicht das Ziel. Keine Eingabe heißt, das Datum in $p_bis zu verwenden. Das aktuelle Datum spielt in dem Anwendungsfall laut Code keine Rolle.
Dann hast Du nur noch zu prüfen, ob bei der Eingabe eines Datum das Objekt erstellt werden konnte, was soviel heißt daß das eingegebene Datum gültig ist. Auf jeden Fall würde ich das Ergebnis (was PHP daraus macht) nocheinmal dem Benutzer zeigen damit er das bestätigen kann.
Das sollte man auch tun, für den Fall, dass die Eingabe nicht leer ist. Aber das Problem bleibt bestehen, dass er Eingaben erkennen möchte, die leer oder gleichwertig zu leer sind.
Siehst Du, Dein Leerzeichenvergleich löst sich mit der richtigen Herangehensweise in Luft auf
Nö, tut es nicht, wenn du nicht den Anwendungsfall umschreibst, so dass er zum Programmierproblem passt. Üblicherweise macht man das andersherum.
dedlfix.
Tach!
Nimm lieber var_dump() für Kontrollausgaben. Das zeigt an, was wirklich ist und keinen in einen String konvertierten Wert, wie es ein echo macht.
Wenn ich
var_dump($_POST["transportauftrag_bis"]);
mir ausgeben lasse erhalte ichstring(0) ""
steht also tatsächlich nichts drin?
Gut, nächster Schritt ist eine Kontrolle, dass die richtige Abzweigung genommen wird. Also ein je ein unterschiedliches echo ins if
und ins else
sollte bestätigen, oder auch nicht, dass der richtige Abzweig genommen wurde. War es der richtige, ist wohl deine Beobachtung nicht richtig, und in $p_bis steht was anderes als erwartet.
dedlfix.
Hi,
if ($_POST["transportauftrag_bis"] == "") {
Wenn $_POST["transportauftrag_von"] leer ist, wird nicht $end = new DateTime( $p_bis ); genommen warum?
Weil nicht …von, sondern …bis auf Leerstring geprüft wird.
cu,
Andreas a/k/a MudGuard
Hallo,
sorry, ich meinte natürlich
$_POST["transportauftrag_bis"]
War ein Fehler beim Kopieren. Im Code steht es richtig.
Tach!
sorry, ich meinte natürlich
$_POST["transportauftrag_bis"]
War ein Fehler beim Kopieren. Im Code steht es richtig.
Dann prüf mit var_dump(), was wirklich einhalten ist. Vergleiche anschließend mit der Type Comparison Table, ob die beiden Werte gleich sein können.
dedlfix.
Hallo Bernd,
der Code sollte meiner Meinung nach so aussehen:
$end = get_post_date('transportauftrag_bis', $p_bis);
...
function get_post_trimmed($key, $default = NULL) {
$wert = trim(filter_input(INPUT_POST, $key));
return ($wert == "") ? $default : $wert;
}
function get_post_date($key, $default = NULL) {
$dateString = get_post_trimmed($key);
return $dateString ? new DateTime($dateString) : $default;
}
filter_input ist ein eingebauter PHP Helper, der Daten aus $_GET, $_POST oder $_COOKIE lesen kann und Fehlermeldungen vermeidet wenn der Eintrag in $_POST fehlt. Statt dessen kommt dann einfach NULL zurück. Die Funktion kann noch viel mehr, guck's mal nach.
trim() entfernt randständige Leerstellen und hat die nette Eigenschaft, dass trim(NULL) einen Leerstring liefert.
Die Funktion get_post_trimmed kannst Du generell für Formeingaben verwenden, wenn Spaces am Rand zu entfernen sind. Wenn Du magst, gibst Du für fehlende Feldinhalte einen Default-Wert mit.
get_post_date baut darauf auf und wandelt den gefundenen Wert in ein Datum um. Auch hier kann ein Default-Wert mitgegeben werden; für deinen Anwendungsfall $p_bis. Du könntest ihn aber auch weglassen, dann kommt bei fehlendem Datum NULL zurück.
Die wichtigste Aufgabe beim Programmieren ist, sich ein solches Set kleiner Helferlein zu bauen. Sonst wiederholt man sich ständig.
Rolf
Lieber Bernd,
if ($_POST["transportauftrag_bis"] == "") {
bei sowas verwende ich gerne empty():
$end = new DateTime( $p_bis ); // default
if (!empty($_POST['transportauftrag_von'])) {
$end = $_POST['transportauftrag_bis'];
}
Liebe Grüße,
Felix Riesterer.
Tach!
if ($_POST["transportauftrag_bis"] == "") {
bei sowas verwende ich gerne empty():
empty()
hat auch die Eigenschaft, keine Meldung zu erzeugen, wenn der Wert im Array nicht vorhanden ist. Andererseits ist ein Leerstring zwar leer, aber ein String mit Leerzeichen ist es nicht. empty()
hätte hier also nicht allein geholfen.
Ein empty(trim($array['feld']))
ist zwar mittlerweile ausführbar (früher wollte empty() lediglich Variablen und keine Ausdrücke als Parameter), hat aber wieder das Problem, dass für das trim()
der Wert $array['feld']
ermittelt werden muss, und das zur bekannten Notice bei Nichtvorhandensein führt. empty()
ist keine normale Funktion sondern ein Sprachkonstrukt, und PHP löst hier nicht den übergebenen Parameter auf, wie es das bei normalen Funktionen tun würde. Allerdings kann empty() auch nicht solche verschachtelten Parameter selbst auswerten, weswegen das trim() unabhängig von empty()s Eigenheiten zuerst aufgelöst wird und es gegebenenfalls dabei zur Notice kommt.
Man kann also zwar hier mit empty() arbeiten, muss aber selbst das Vorhandesein des Eintrags in $_POST prüfen und darauf ein trim() ausführen, bevor man empty() bemüht.
dedlfix.
Lieber dedlfix,
empty()
hat auch die Eigenschaft, keine Meldung zu erzeugen, wenn der Wert im Array nicht vorhanden ist.
das ist zwar richtig, in diesem Falle aber in Ordnung. Ist der Array-Schlüssel nicht vorhanden, liefert empty()
ein true
, so dass der if
-Zweig nicht eingeschlagen wird.
Andererseits ist ein Leerstring zwar leer, aber ein String mit Leerzeichen ist es nicht.
empty()
hätte hier also nicht allein geholfen.
Eine Plausibilitätsprüfung habe ich nicht geliefert, das ist richtig. Aber Bernds Frage war eher, warum seine Prüfung auf Leerstring nicht griff. Hier hat mein Code geleistet, was Bernds Code nicht leisten konnte.
Ein
empty(trim($array['feld']))
ist zwar mittlerweile ausführbar (früher wollte empty() lediglich Variablen und keine Ausdrücke als Parameter), hat aber wieder das Problem, dass für dastrim()
der Wert$array['feld']
ermittelt werden muss, und das zur bekannten Notice bei Nichtvorhandensein führt.
Also war mein Code für diese Prüfung alleine besser.
empty()
ist keine normale Funktion sondern ein Sprachkonstrukt, und PHP löst hier nicht den übergebenen Parameter auf, wie es das bei normalen Funktionen tun würde.
Wozu auch? Es ist eine Holzhammer-Methode! Wer sie einsetzt, muss sie genau kennen, um sie korrekt anzuwenden.
Man kann also zwar hier mit empty() arbeiten, muss aber selbst das Vorhandesein des Eintrags in $_POST prüfen und darauf ein trim() ausführen, bevor man empty() bemüht.
Oder man macht einfach eine echte Plausibilitätsprüfung, indem korrekt nach dem Vorhandensein des Array-Schlüssels geschaut wird (array_key_exists()
), um dann den Wert auf seine Gültigkeit hin zu prüfen.
Liebe Grüße,
Felix Riesterer.
Tach!
Andererseits ist ein Leerstring zwar leer, aber ein String mit Leerzeichen ist es nicht.
empty()
hätte hier also nicht allein geholfen.Eine Plausibilitätsprüfung habe ich nicht geliefert, das ist richtig. Aber Bernds Frage war eher, warum seine Prüfung auf Leerstring nicht griff. Hier hat mein Code geleistet, was Bernds Code nicht leisten konnte.
Doch, Bernds Code hat genauso reagiert wie die Empty-Variante. Beide können nämlich nicht nicht-leere Strings als leer erkennen. Damit können sie beide keine Leerzeichen enthaltenden Strings als leere Eingabe werten.
Ein
empty(trim($array['feld']))
ist zwar mittlerweile ausführbar (früher wollte empty() lediglich Variablen und keine Ausdrücke als Parameter), hat aber wieder das Problem, dass für dastrim()
der Wert$array['feld']
ermittelt werden muss, und das zur bekannten Notice bei Nichtvorhandensein führt.Also war mein Code für diese Prüfung alleine besser.
In Bezug auf die Notice, aber das ist dann auch nicht mehr wichtig, wenn er nicht zum Ziel führt.
empty()
ist keine normale Funktion sondern ein Sprachkonstrukt, und PHP löst hier nicht den übergebenen Parameter auf, wie es das bei normalen Funktionen tun würde.Wozu auch? Es ist eine Holzhammer-Methode! Wer sie einsetzt, muss sie genau kennen, um sie korrekt anzuwenden.
Du hast mich da wohl falsch verstanden. Das sollte eine allgemeine Erklärung zum Sonderstatus von empty() als Sprachkonstrukt statt normale Funktion werden.
Man kann also zwar hier mit empty() arbeiten, muss aber selbst das Vorhandesein des Eintrags in $_POST prüfen und darauf ein trim() ausführen, bevor man empty() bemüht.
Oder man macht einfach eine echte Plausibilitätsprüfung, indem korrekt nach dem Vorhandensein des Array-Schlüssels geschaut wird (
array_key_exists()
), um dann den Wert auf seine Gültigkeit hin zu prüfen.
Lieber isset()
verwenden. Auch das ist ein Sprachkonstrukt und erzeugt keine Notice-Meldungen. array_key_exists()
trennt Array und Key auf zwei Parameter auf, so dass der Key nun ein Magic String ist. Wenn man isset($array['key'])
nimmt, bleibt das $array['key']
syntaktisch beieinander und kann besser von IDEs mit Code-Analyse erkannt werden. Eine solche Code-Analyse versucht die für Array-Keys verwendeten Stringliterale zu erkennen und kann diese dann beim Code-Vervollständigen besser vorschlagen, als Stringliterale, die sonstwo als Magic String verwendet werden. Aber ja, fachlich gesehen ergibt es keinen Unterschied. (Der Unterschied bezüglich NULL enthaltende Werte ist hier nicht relevant, weil das im $_POST-Array normal nicht vorkommen kann.)
dedlfix.