Checkbox abfragen

[Sara]

Hallo,

ich habe glaube ich ein Denkfehler :/

Wenn ich diesen Code ausführe

if ($_POST['tagesPreis'] == "") {
	$tagesPreis = "";
}else {
  $tagesPreis = $_POST["tagesPreis"];
}

erhalte ich diese Meldung "Notice: Undefined index: tagesPreis" wenn ich nichts angeklickt habe. Aber warum?

Edit, wenn ich es so prüfe funktioniert es

if(!isset($_POST['tagesPreis'])) {
	$tagesPreis = "";
}else {
  $tagesPreis = $_POST["tagesPreis"];
}

Ich verstehe es allerdings nicht, denn in der ersten Zeile if ($_POST['tagesPreis'] == "") prüfe ich doch, ob das Feld leer ist?

[Gunnar Bittersmann]

@@Sara

erhalte ich diese Meldung "Notice: Undefined index: tagesPreis" wenn ich nichts angeklickt habe. Aber warum?

s. Doku: „Die Werte von ausgewählten Checkboxen werden beim Absenden des Formulars mit übertragen.“ (Hervorhebung von mir)

var_dump($_POST); hätte dir das auch verraten.

Ich verstehe es allerdings nicht, denn in der ersten Zeile if ($_POST['tagesPreis'] == "") prüfe ich doch, ob das Feld leer ist?

Aber nicht, ob $_POST['tagesPreis'] überhaupt existiert.

LLAP 🖖

[Der Martin]

Hi,

Wenn ich diesen Code ausführe

if ($_POST['tagesPreis'] == "") {
	$tagesPreis = "";
}else {
  $tagesPreis = $_POST["tagesPreis"];
}

erhalte ich diese Meldung "Notice: Undefined index: tagesPreis" wenn ich nichts angeklickt habe. Aber warum?

weil du dann trotzdem erstmal versuchst, $_POST['tagesPreis'] zu lesen, obwohl dieser Wert gar nicht existiert. Merke: Ein Leerstring ist nicht "nichts".
Genau dafür gibt es ja die Abfrage mit isset(), die einfach auf Vorhandensein prüft.

Ich verstehe es allerdings nicht, denn in der ersten Zeile if ($_POST['tagesPreis'] == "") prüfe ich doch, ob das Feld leer ist?

Nein. Du prüfst, ob der Wert von $_POST['tagesPreis'], der dazu erst existieren muss, ein leerer String ist.

So long,
 Martin

[Matthias Apsel]

Hallo Sara,

Edit, wenn ich es so prüfe funktioniert es

if(!isset($_POST['tagesPreis'])) {
	$tagesPreis = "";
}else {
  $tagesPreis = $_POST["tagesPreis"];
}

Zusätzlich zu den bisherigen Antworten: Du solltest dir vielleicht das Umkopieren sparen:

if(!isset($_POST['tagesPreis'])) $_POST['tagesPreis'] = "";

Wenn du dir die möglichen Werte im Vorfeld initialisierst (und du nicht auf einen fehlenden Tagespreis reagieren möchtest, kannst du dir die Prüfung sparen

  $_POST['tagesPreis'] = "";

  // durchlaufe das Postarray und weise alle vorhandenen Werte zu
  // die, die es nicht gibt, behalten ihren Ausgangswert

Beachte ggf. auch, dass du es mit Benutzereingaben zu tun hast, bei der Ausgabe musst du den Kontext beachten.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Du solltest dir vielleicht das Umkopieren sparen

Womöglich ja.

$_POST['tagesPreis'] = "";

Die Befüllung des $_POST-Arrays (dessen Sinn es ist, von außen kommende Werte aufzunehmen) mit Werten von innen halte ich für keinen guten Programmierstil.

Beachte ggf. auch, dass du es mit Benutzereingaben zu tun hast, bei der Ausgabe musst du den Kontext beachten.

Nicht um den heißen Brei herumreden! Hier ist Klartext angesagt:

Benutzereingaben u.a. Daten fremder Herkunft dürfen nie unbearbeitet in HTML-Code ausgegeben werden, sondern müssen immer gegen Einschleusen von Schadcode abgesichert werden: htmlspecialchars()

LLAP 🖖

[dedlfix]

Tach!

Beachte ggf. auch, dass du es mit Benutzereingaben zu tun hast, bei der Ausgabe musst du den Kontext beachten.

Nicht um den heißen Brei herumreden! Hier ist Klartext angesagt:

Benutzereingaben u.a. Daten fremder Herkunft dürfen nie unbearbeitet in HTML-Code ausgegeben werden, sondern müssen immer gegen Einschleusen von Schadcode abgesichert werden: htmlspecialchars()

Hab ich doch auch schon so oft gesagt: Es kommt nicht auf die Herkunft an! Man muss bei jeglichen Daten den Ausgabekontext berücksichtigen. Ob es "fremde" Daten sind oder eigene, muss und darf dabei nicht unterschieden werden.

Auch ist das Ziel nicht allein das Verhindern von Schadcodeeinschleusung, sondern dass die Daten generell den Regeln gemäß und damit wie gewünscht in den Ausgabekontext eingebettet werden. Dass Schadcode keine Auswirkungen hat, wenn er wie sämtliche andere Daten auch behandelt wird, ist dabei quasi eine (erwünschte) Nebenwirkung.

dedlfix.

[Mitleser]

Grundsätzlich (mal wieder) schön auf den Punkt gebracht. Aber:

Hab ich doch auch schon so oft gesagt: Es kommt nicht auf die Herkunft an! Man muss bei jeglichen Daten den Ausgabekontext berücksichtigen. Ob es "fremde" Daten sind oder eigene, muss und darf dabei nicht unterschieden werden.

In Ausnahmefällen kann die Unterscheidung nach "fremde / eigene Daten" nötig sein. Z.B. wenn ein Inhalt aus einem CMS (gepflegt durch Backend-Redakteure) kommt, will man evtl. HTML ausgeben. Kommt der Inhalt aus einem Kommantarfeld eines profanen Users, will man mituntender doch stupide escapen.

Auch ist das Ziel nicht allein das Verhindern von Schadcodeeinschleusung, sondern dass die Daten generell den Regeln gemäß und damit wie gewünscht in den Ausgabekontext eingebettet werden. Dass Schadcode keine Auswirkungen hat, wenn er wie sämtliche andere Daten auch behandelt wird, ist dabei quasi eine (erwünschte) Nebenwirkung.

ACK.

[dedlfix]

Tach!

Hab ich doch auch schon so oft gesagt: Es kommt nicht auf die Herkunft an! Man muss bei jeglichen Daten den Ausgabekontext berücksichtigen. Ob es "fremde" Daten sind oder eigene, muss und darf dabei nicht unterschieden werden.

In Ausnahmefällen kann die Unterscheidung nach "fremde / eigene Daten" nötig sein. Z.B. wenn ein Inhalt aus einem CMS (gepflegt durch Backend-Redakteure) kommt, will man evtl. HTML ausgeben. Kommt der Inhalt aus einem Kommantarfeld eines profanen Users, will man mituntender doch stupide escapen.

Njein, man muss dabei nicht nach eigen oder fremd unterscheiden, sondern nach der Art der Daten und der Aufgabenstellung. Je nachdem ändert sich dann der Kontext. Ist die Aufgabenstellung zum Beispiel HTML in HTML einzufügen, dann ist das keine Ausnahme, sondern eine andere Aufgabenstellung / ein anderer Kontext als Text-Daten in HTML einzufügen. Dass dabei andere Regeln gelten (die man nicht mit htmlspecialchars() erfüllen kann), ist nur logische Fortsetzung.

Von "stupide" irgendwelchen Regen zu folgen, halte ich nichts, besonders nicht beim Programmieren. Vielmehr empfehle ich, dass man sich bewusst ist oder macht, warum man eine bestimmte Regel in einer bestimmten Situation befolgt - oder auch nicht.

dedlfix.

[Sara]

Hallo,

Benutzereingaben u.a. Daten fremder Herkunft dürfen nie unbearbeitet in HTML-Code ausgegeben werden, sondern müssen immer gegen Einschleusen von Schadcode abgesichert werden: htmlspecialchars()

es geht hier nicht um eine Ausgabe wie im Ausgangsposting sehen kannst, sondern um eine Datenbankabfrage bzw. um das Füllen von einer Variable. Daher ist diese Bemerkung von dir an dieser Stelle völlig unnötig.

Auch ist deine Aussage falsch wenn man möchte, dass Code vom User ausgeführt wird, solche Anwendungen gibt es zu genüge! Es kommt immer auf das Gesamtkonzept an.

Ein Beispiel, ich bekomme von unserem Lieferanten Daten die auch HTML Code beinhalten, wenn ich diesen durch htmlspecialchars laufen lassen würde, hätte ich eine verfälschte Ausgabe und wäre sofort meine Lizenz los und müsste mit einer Klage rechnen.

Allerdings kenne ich deine Beiträge und rege mich über solche Aussagen erst gar nicht auf.

[Gunnar Bittersmann]

@@Sara

es geht hier nicht um eine Ausgabe wie im Ausgangsposting sehen kannst, sondern um eine Datenbankabfrage bzw. um das Füllen von einer Variable. Daher ist diese Bemerkung von dir an dieser Stelle völlig unnötig.

Zum einen war die Bemerkung nicht von mir, sondern von Matthias. Ich hab sie lediglich präsiziert.

Zum anderen war sie ein Hinweis darauf, was du später mit deiner befüllten Variablen machst. Wenn du an späterer Stelle echo $tagesPreis; im Code hast, könntest du das Problem vielleicht übersehen.

Das soll nicht heißen, dass du gleich $tagesPreis = htmlspecialchars($_POST['tagesPreis']); schreiben solltest; sondern später dann eben echo htmlspecialchars($tagesPreis);.

Und die Beurteilung, welche Bemerkung an welcher Stelle nötig ist, überlässt du bitte denen, die Ahnung von dem Kram haben.

Auch ist deine Aussage falsch wenn man möchte, dass Code vom User ausgeführt wird, solche Anwendungen gibt es zu genüge!

Was dedlfix sagte.

Und man möchte nie, dass jedweder Code vom User ausgeführt wird.

Eingeschleustes JavaScript ganz sicher nicht. <script> käme auf die Blacklist der Dinge, die man abfangen muss.

Oder besser man führt eine Whitelist der Dinge, die erlaubt sind. Das muss auch kein HTML-Code sein. Wenn man Nutzer Formatierungen erlauben will, bietet sich auch BB-Code oder Markdown an.

Ein Beispiel, ich bekomme von unserem Lieferanten Daten die auch HTML Code beinhalten, wenn ich diesen durch htmlspecialchars laufen lassen würde, hätte ich eine verfälschte Ausgabe und wäre sofort meine Lizenz los und müsste mit einer Klage rechnen.

Und wenn du den Code vom Lieferanten unbehandelt ausgibst und damit Sicherheitslöcher aufreißt, wärst du sofort deine Lizenz los und müsstest mit einer Klage rechnen.

Du fügst aber nicht die Daten von deinem Lieferanten unbehandelt in deinen HTML-Code ein? Ich hoffe, ich habe dich falsch verstanden.

Allerdings kenne ich deine Beiträge und rege mich über solche Aussagen erst gar nicht auf.

Wenn du dir dir Mühe machst, meine Beiträge zu verstehen, hast du gar keinen Grund zur Aufregung.

LLAP 🖖

[Sara]

Hallo,

Ein Beispiel, ich bekomme von unserem Lieferanten Daten die auch HTML Code beinhalten, wenn ich diesen durch htmlspecialchars laufen lassen würde, hätte ich eine verfälschte Ausgabe und wäre sofort meine Lizenz los und müsste mit einer Klage rechnen.

Und wenn du den Code vom Lieferanten unbehandelt ausgibst und damit Sicherheitslöcher aufreißt, wärst du sofort meine Lizenz los und müsstest mit einer Klage rechnen.

Du fügst aber nicht die Daten von deinem Lieferanten unbehandelt in deinen HTML-Code ein? Ich hoffe, ich habe dich falsch verstanden.

na was soll ich denn sonst machen? Im Code kann HTML und JavaScript z.B. onclick vorkommen. Wenn ich diesen durch htmlspecialchars laufen lassen geht überhaupt nichts mehr. Nicht einmal das Copyright vom Hersteller wird angezeigt und eine Abmahnung kann und möchte ich mir nicht leisten, da diese sehr teuer werden kann.

Also vertraue ich darauf was die Jungs und Mädels in der IT-Abteilung vom jeweiligen Lieferanten eintragen und hoffe darauf, dass diese kein scheiß machen.

[Gunnar Bittersmann]

@@Sara

Du fügst aber nicht die Daten von deinem Lieferanten unbehandelt in deinen HTML-Code ein? Ich hoffe, ich habe dich falsch verstanden.

na was soll ich denn sonst machen? Im Code kann HTML und JavaScript z.B. onclick vorkommen.

Aua.

Also vertraue ich darauf was die Jungs und Mädels in der IT-Abteilung vom jeweiligen Lieferanten eintragen und hoffe darauf, dass diese kein scheiß machen.

AUA.

Ihr habt natürlich mit all euren Lieferanten vertraglich festgelegt, wer im Fall von Schäden auf eurer Website an euren Kunden (dazu gehört auch Privatsphäre und Datenschutz) haftbar ist?

Und euren Rechtsanwalt prüfen lassen, dass diese Festlegungen im Vertrag nicht etwa unwirksam sind, weil sie gegen andere gesetzlichen Regelungen verstoßen?

LLAP 🖖

[Sara]

Hallo,

Ihr habt natürlich mit all euren Lieferanten vertraglich festgelegt, wer im Fall von Schäden auf eurer Website an euren Kunden (dazu gehört auch Privatsphäre und Datenschutz) haftbar ist?

bei <strong> <bold> usw.. kann wohl kaum etwas passieren, genauso wenn man ein onclick anwendet um eine Info anzeigen lässt. Wir wissen was wir von unseren Lieferanten bekommen, dazumal sind es Lieferanten die schon sehr lange im Geschäft sind.

Lass das bitte unsere Sorge sein. Dieses steht hier nicht zur Diskussion.

[woodfighter]

Tach,

bei <strong> <bold> usw.. kann wohl kaum etwas passieren, genauso wenn man ein onclick anwendet um eine Info anzeigen lässt.

oder um beliebiges weiteres Javascript nachzuladen und auszführen…

Wir wissen was wir von unseren Lieferanten bekommen

Das wisst ihr nur, wenn ihr jedesmal genau (von Hand) draufschaut.

dazumal sind es Lieferanten die schon sehr lange im Geschäft sind.

So lange wie Google, denen passiert das nämlich auch noch? http://blog.emsisoft.com/2014/02/25/caphaw-trojan-found-in-youtube-ads/ https://en.wikipedia.org/wiki/Malvertising

Lass das bitte unsere Sorge sein. Dieses steht hier nicht zur Diskussion.

Du kannst entscheiden, dich nicht an der Diskussion zu beteiligen, aber nicht, was wir diskutieren.

mfg
Woodfighter

[Sara]

Du kannst entscheiden, dich nicht an der Diskussion zu beteiligen, aber nicht, was wir diskutieren.

Dann sollte es ein Button geben nicht mehr informiert zu werden, denn ihr kennt die Lieferanten nicht, ihr kennt unser System nicht und ihr kennt nicht unsere User. Solche Diskussionen machen einen Beitrag kapput und nervt gewaltig weil ich immer wieder schauen muss was geschrieben wurde und führt zu keinem Ergebnis.

Das wisst ihr nur, wenn ihr jedesmal genau (von Hand) draufschaut.

Warum sollte sich ein Lieferant selber schädigen?

So lange wie Google, denen passiert das nämlich auch noch?

Selbstverständlich. Herd Verlag, einer unserer Verlage ist seit 1990 mit dabei, da dachte nur kein Mensch an Google.

[woodfighter]

Tach,

Das wisst ihr nur, wenn ihr jedesmal genau (von Hand) draufschaut.

Warum sollte sich ein Lieferant selber schädigen?

das muss nicht er selber sein, das kann genauso ein Dritter sein und darauf hast du keinerlei Einfluss.

So lange wie Google, denen passiert das nämlich auch noch?

Selbstverständlich. Herd Verlag, einer unserer Verlage ist seit 1990 mit dabei, da dachte nur kein Mensch an Google.

Dass die Firma länger existiert heißt trotzdem nicht, dass sie mehr Erfahrungen haben und auf die Erfahrung eurer Kunden kommt es ja auch nicht an, sondern auf eure und da halte ich Javascript von externen Quellen einbinden für eine mindestens sportliche Herausforderung.

mfg
Woodfighter

[Auge]

Hallo

Dann sollte es ein Button geben nicht mehr informiert zu werden

Die Diskussion hatten wir schon. Beachte bitte bezüglich der technischen Anforderungen den Verlauf der Diskussion.

Solche Diskussionen machen einen Beitrag kapput und nervt gewaltig …

Nur, weil dir solche Diskussionen nicht passen, machen sie (d)einen Thread mitnichten kaputt. Sie ergänzen die Diskussion um bisher nicht berücksichtigte Punkte. In diesem Fall sogar um einen sehr wichtigen Punkt. Der Thread bleibt im Archiv und auch wenn du der Meinung bist, deine Lieferanten zu kennen und einschätzen zu können, wäre es mehr als fahrlässig, einem unbedarften Neuling, der die Diskussion im Archiv finden wird, solche Sicherheitslücken anzuempfehlen.

… weil ich immer wieder schauen muss was geschrieben wurde …

Tut mir leid, aber der Thread, auch wegen deines Problems von dir gestartet, ist nicht dein Eigentum. Er befindet sich in einem quasiöffentlichen Raum und bleibt, wie schon gesagt, dauerhaft im Archiv. Er sollte deshalb, wenn möglich, alle Aspekte, oder zumindest so viele als möglich, beleuchten.

… und führt zu keinem Ergebnis.

Doch, das Ergebnis ist, dass es im Allgemeinen keine gute Idee ist, Daten, deren Struktur nicht vollständig bekannt ist, unbehandelt auszugeben. Das ist völlig unabhängig von deiner Einstellung dazu. Wenn du der Meinung bist, deinen Lieferanten trauen zu können, ist es deine Entscheidung, das Risiko einzugehen. Dennoch ist es wichtig, das Risiko als solches zu benennen.

Tschö, Auge

[dedlfix]

Tach!

Du kannst entscheiden, dich nicht an der Diskussion zu beteiligen, aber nicht, was wir diskutieren.

Dann sollte es ein Button geben nicht mehr informiert zu werden, denn ihr kennt die Lieferanten nicht, ihr kennt unser System nicht und ihr kennt nicht unsere User. Solche Diskussionen machen einen Beitrag kapput und nervt gewaltig weil ich immer wieder schauen muss was geschrieben wurde und führt zu keinem Ergebnis.

Bitte übersieh nicht, dass das Forum nicht allein der Beantwortung der Fragen Einzelner dient, sondern auch einen allgemeinen Wissenszuwachs für Mitlesende und Mitdiskutierende bieten möchte. Es ist ein stückweit egoistisch, nur die eigenen Belange zu berücksichtigen. Das kann man erwarten, wenn man sich an einen professionellen Dienstleister wendet. Hier in einem öffentlichen Forum hingegen, bringen sich die Teilnehmer nach eigenem Gutdünken ein und das ist auch gut so - meistens jedenfalls.

Dass du persönlich aus bestimmten Diskussionsthemen keinen Erkenntnisgewinn ziehen möchtest, kann das Forum nicht wissen. Genausowenig wie die Werbeindustrie nicht weiß, dass mich ihre Angebote kalt lassen und mich trotzdem immer weiter zu bombardieren versucht. So ist das eben, dass man ungewünschte Information bekommt. Da muss jeder durch.

dedlfix.

[Sara]

Hallo,

Dass du persönlich aus bestimmten Diskussionsthemen keinen Erkenntnisgewinn ziehen möchtest, kann das Forum nicht wissen. Genausowenig wie die Werbeindustrie nicht weiß, dass mich ihre Angebote kalt lassen und mich trotzdem immer weiter zu bombardieren versucht. So ist das eben, dass man ungewünschte Information bekommt. Da muss jeder durch.

von möchtest war NIE die Rede. Ich habe immer gesagt der Code kommt von extern, ich habe darauf KEINEN Einfluss und darf auch NICHTS ändern.

Ein anderes Beispiel, der JavaScript Code von Google für adwords, analytics und adsense darf ich auch nicht ändern. Dieser kommt ebenfalls aus einer Datenbank und MUSS 1zu1 so ausgegeben werden, das gleiche gilt für unserer Werbung die wir auf unserer Seite platzieren.

Kommt mal bitte alle wieder runter und überlegt was für Ratschläge ihr so verteilt. Ihr kennt nur den Hintergrund, ihr kennt 0 die Anforderung aber erlaubt euch solche Ratschläge zu verteilen. Die armen User die das alles lesen müssen, den Fehler von euch 1zu1 umsetzten und dann sich wundern warum durch Google nicht geloggt wird.

[woodfighter]

Tach,

von möchtest war NIE die Rede. Ich habe immer gesagt der Code kommt von extern, ich habe darauf KEINEN Einfluss und darf auch NICHTS ändern.

als jemand mich in einem vorherigen Job zu Dingen zwingen wollte, die ich nicht machen wollte, bin ich gegangen, als man nicht auf meine Argumente hören wollte; niemand muss schlechte Dinge umsetzen.

Kommt mal bitte alle wieder runter und überlegt was für Ratschläge ihr so verteilt. Ihr kennt nur den Hintergrund, ihr kennt 0 die Anforderung aber erlaubt euch solche Ratschläge zu verteilen. Die armen User die das alles lesen müssen, den Fehler von euch 1zu1 umsetzten und dann sich wundern warum durch Google nicht geloggt wird.

Lehn dich bitte einmal zurück und erinnere dich, dass unsere Erfahrungen deutlich größer sind als deine (sonst würdest du ja nicht zum Fragen hierher kommen). Und dass das Einbinden von externen Scripten immer ein Sicherheitsrisiko ist (ja auch wenn es Google oder ein sonstiges CDN ist), ist vielen nicht bewußt, deswegen halte ich es für nötig, das jedesmal zu erwähnen.

mfg
Woodfighter

[Sara]

als jemand mich in einem vorherigen Job zu Dingen zwingen wollte, die ich nicht machen wollte, bin ich gegangen, als man nicht auf meine Argumente hören wollte; niemand muss schlechte Dinge umsetzen.

Wenn jemand auf einen externen Dienstleister angewiesen ist, dann wird er sich dran halten ob es ihm passt oder nicht. Aber ich sehe, diese Diskussion bringt nichts, da ihr ja eh alles besser wisst.

Daher ist die Diskussion für MICH beendet!

[Gunnar Bittersmann]

@@Sara

Aber ich sehe, diese Diskussion bringt nichts, da ihr ja eh alles besser wisst.

Aus „Gunnar weiß ja eh alles besser“ ist nun schon „ihr wisst eh alles besser“ geworden …

Daher ist die Diskussion für MICH beendet!

Die PLONKs sind so laut, dass ich sie bis hier höre – eins nach dem anderen.

LLAP 🖖

[Gunnar Bittersmann]

@@dedlfix

Bitte übersieh nicht, dass das Forum nicht allein der Beantwortung der Fragen Einzelner dient, sondern auch einen allgemeinen Wissenszuwachs für Mitlesende und Mitdiskutierende bieten möchte.

Das ist der Grund, warum ich mich an manchen Threads weiter beteilige, auch wenn zu erkennen ist, dass das für den Fragenden (oder mit dem Fragenden – je nach Perspektive) wenig Aussicht auf Erfolg hat.

LLAP 🖖

[Camping_RIDER]

Aloha ;)

$_POST['tagesPreis'] = "";

Die Befüllung des $_POST-Arrays (dessen Sinn es ist, von außen kommende Werte aufzunehmen) mit Werten von innen halte ich für keinen guten Programmierstil.

Ich würde dir zustimmen, wenn es sich tatsächlich um Werte von innen handeln würde. Wenn aber, wie hier, nur im Fall eines nicht-vorhandenen Eintrags der Leerstring gesetzt wird, halte ich das je nach Kotext für legitim. Es handelt sich dabei mMn weniger um ein Füllen mit Daten als viel mehr um eine Konvertierung der Information in ein anderes (für das Programm günstigeres) Format - in dem Sinne, dass ein Fehlen des Eintrags bedeutet, dass die Checkbox nicht angewählt wurde, und diese Information, die ja durchaus von außen kommt, im Sinne des Programms dann als Leerstring dargestellt wird.

Grüße,

RIDER

[1unitedpower]

Zusätzlich zu den bisherigen Antworten: Du solltest dir vielleicht das Umkopieren sparen:

Finde ich nicht. Den Array-Zugriff $_POST['tagesPreis'] zu wiederholen ist langatmig und fehleranfällig. Wenn sich der Array-Schlüssel mal ändern sollte, oder wenn man den Code später über den Schlüssel verallgmeinern möchte, dann müssen sämtliche Zugriffe geändert werden. Speichert man dagegen das Ergebnis direkt in einer Variablen, gibt es nur einen Punkt mit Änderungsbedarf. Außerdem sind PHPs assoziative Arrayzugriffe wegen des String-typisierten Schlüssels schon für sich anfällig für Tippfehler. Und das sind wirklich bösartige Fehler, weil PHP dann nicht sofort mit einem lauten Krach darauf aufmerksam macht, sondern versucht das "Beste" aus der Situation zu machen, so kann der Fehler lange unbemerkt bleiben und durch die Anwendung propagieren. Gut gemeint ist eben nicht gut gemacht.

Außerdem sollte man tunlichst vermeiden PHPs $_POST-Array selber zu beschreiben. Der Schein trügt, dass es nur einen gerinfügigen Unterschied mache, ob ein $_POST-Element den leeren String enthält oder gar nicht gesetzt ist. Das zeigt dieser Fall sogar besonders deutlich: Array-Element nicht gesetzt bedeutet, dass die Checkbox nicht ausgewählt wurde. Array-Element gesetzt bedeutet, dass die Checkbox ausgewählt wurde, und zwar unabhängig vom Wert, der drin steht. Gegenteiliger könnte die Semantik kaum sein.

[dedlfix]

Tach!

Zusätzlich zu den bisherigen Antworten: Du solltest dir vielleicht das Umkopieren sparen:

Finde ich nicht. Den Array-Zugriff $_POST['tagesPreis'] zu wiederholen ist langatmig und fehleranfällig. Wenn sich der Array-Schlüssel mal ändern sollte, oder wenn man den Code später über den Schlüssel verallgmeinern möchte, dann müssen sämtliche Zugriffe geändert werden.

Man kann da auch mit YAGNI argumentieren.

Speichert man dagegen das Ergebnis direkt in einer Variablen, gibt es nur einen Punkt mit Änderungsbedarf.

Wenn man refakturiert, muss man zwangsläufig aufmerksam sein, auch wenn man sich das Leben (angeblich) vereinfacht hat. Wer sagt denn, dass sich nur der Feldbezeichner ändert und nicht stattdessen der Variablenname, oder gar beides? Ich halte das für kein allgemeingültiges Argument.

Außerdem sind PHPs assoziative Arrayzugriffe wegen des String-typisierten Schlüssels schon für sich anfällig für Tippfehler. Und das sind wirklich bösartige Fehler, weil PHP dann nicht sofort mit einem lauten Krach darauf aufmerksam macht, sondern versucht das "Beste" aus der Situation zu machen, so kann der Fehler lange unbemerkt bleiben und durch die Anwendung propagieren. Gut gemeint ist eben nicht gut gemacht.

Das passiert bei falsch geschriebenen (und damit nicht existenten) Variablen ebenso. In beiden Fällen gibt es nur eine Notice-Meldung. Und diese sind unterdrückt, wenn man sie nicht explizit freikonfiguriert.

"Das "beste" aus dieser Situation" zu machen, ist schlicht die Rückgabe von null. Was du vermutlich meinst, ist das Weglassen der Anführungszeichen. Denn dann wird gutmütigerweise angenommen, man meine gar keine Konstante, wenn eine solche nicht existiert, sondern einen String.

Außerdem sollte man tunlichst vermeiden PHPs $_POST-Array selber zu beschreiben. Der Schein trügt, dass es nur einen gerinfügigen Unterschied mache, ob ein $_POST-Element den leeren String enthält oder gar nicht gesetzt ist. Das zeigt dieser Fall sogar besonders deutlich: Array-Element nicht gesetzt bedeutet, dass die Checkbox nicht ausgewählt wurde. Array-Element gesetzt bedeutet, dass die Checkbox ausgewählt wurde, und zwar unabhängig vom Wert, der drin steht. Gegenteiliger könnte die Semantik kaum sein.

Dem kann man mit !empty() statt isset() abhelfen.

dedlfix.

[1unitedpower]

Finde ich nicht. Den Array-Zugriff $_POST['tagesPreis'] zu wiederholen ist langatmig und fehleranfällig. Wenn sich der Array-Schlüssel mal ändern sollte, oder wenn man den Code später über den Schlüssel verallgmeinern möchte, dann müssen sämtliche Zugriffe geändert werden.

Man kann da auch mit YAGNI argumentieren.

Kann man, meine Erfahrung ist allerdings, dass es sich lohnt in vorrauschauender Weise Abkürzungen im Quelltext zu platzieren. Man kann damit auch Mal daneben liegen, aber wo wäre dann dann der Nachteil gegenüber der sich selbst wiederholenden Variante?

Speichert man dagegen das Ergebnis direkt in einer Variablen, gibt es nur einen Punkt mit Änderungsbedarf.

Wenn man refakturiert, muss man zwangsläufig aufmerksam sein, auch wenn man sich das Leben (angeblich) vereinfacht hat. Wer sagt denn, dass sich nur der Feldbezeichner ändert und nicht stattdessen der Variablenname, oder gar beides? Ich halte das für kein allgemeingültiges Argument.

Zumindest ist es kein gutes Argument. Trotzdem halte ich es für besser Array- und Objekt-Zugriffe nicht zu wiederholen. Es ist sicher auch ein Stück weit persönliche Abwägungssache, doch je länger der Zugriffspfad wird, desto eher wird man wohl dazu tendieren eine Variable als Abkürzung verwenden. Ich denke niemand würde bspw. $foo->bar['baz']->lorem->ipsum['dolor']['sit']->amet() gerne häufig wiederholen müssen. Und dann hängt es natürlich auch davon ab, wie oft man die Zeile schreiben müsste. Ich folge da lieber dem DRY-Prinzip.

Außerdem sind PHPs assoziative Arrayzugriffe wegen des String-typisierten Schlüssels schon für sich anfällig für Tippfehler. Und das sind wirklich bösartige Fehler, weil PHP dann nicht sofort mit einem lauten Krach darauf aufmerksam macht, sondern versucht das "Beste" aus der Situation zu machen, so kann der Fehler lange unbemerkt bleiben und durch die Anwendung propagieren. Gut gemeint ist eben nicht gut gemacht.

Das passiert bei falsch geschriebenen (und damit nicht existenten) Variablen ebenso. In beiden Fällen gibt es nur eine Notice-Meldung. Und diese sind unterdrückt, wenn man sie nicht explizit freikonfiguriert.

Das stimmt, bei Variablen können einem allerdings Code-Quality-Werkzeuge und IDEs weiter entgegenkommen, weil Variablenbezeichner von statischer Code-Analyse erfasst werden können.

"Das "beste" aus dieser Situation" zu machen, ist schlicht die Rückgabe von null.

„I call it my billion-dollar mistake. It was the invention of the null reference in 1965.“ – Tony Hoare

Was du vermutlich meinst, ist das Weglassen der Anführungszeichen. Denn dann wird gutmütigerweise angenommen, man meine gar keine Konstante, wenn eine solche nicht existiert, sondern einen String.

Darauf wollte ich eigentlich nicht hinaus.

Außerdem sollte man tunlichst vermeiden PHPs $_POST-Array selber zu beschreiben. Der Schein trügt, dass es nur einen gerinfügigen Unterschied mache, ob ein $_POST-Element den leeren String enthält oder gar nicht gesetzt ist. Das zeigt dieser Fall sogar besonders deutlich: Array-Element nicht gesetzt bedeutet, dass die Checkbox nicht ausgewählt wurde. Array-Element gesetzt bedeutet, dass die Checkbox ausgewählt wurde, und zwar unabhängig vom Wert, der drin steht. Gegenteiliger könnte die Semantik kaum sein.

Dem kann man mit !empty() statt isset() abhelfen.

Mit empty() kannst du auf unterschiedliche falsy-Werte gleichzeitig testen, aber du kannst dadurch nicht die Semantik zurückgewinnen, dass eine Checkbox ausgewählt wurde, nachdem du das $_POST-Array selber beschrieben hast.

[dedlfix]

Tach!

Finde ich nicht. Den Array-Zugriff $_POST['tagesPreis'] zu wiederholen ist langatmig und fehleranfällig. Wenn sich der Array-Schlüssel mal ändern sollte, oder wenn man den Code später über den Schlüssel verallgmeinern möchte, dann müssen sämtliche Zugriffe geändert werden.

Man kann da auch mit YAGNI argumentieren.

Kann man, meine Erfahrung ist allerdings, dass es sich lohnt in vorrauschauender Weise Abkürzungen im Quelltext zu platzieren. Man kann damit auch Mal daneben liegen, aber wo wäre dann dann der Nachteil gegenüber der repitiven Variante?

Wenn das Programm umfangreicher wird, wird man sicherlich irgendwann nicht mehr die Eingabedaten direkt verarbeiten, sondern sie aus diesen in Model-Objekte übertragen, so dass die eigentliche Geschäftslogik mit diesem Model arbeitet und von den Gegebenheiten auf dem Übertragungsweg nichts wissen muss. Auch das ist mehr oder weniger nur eine 1:1-Kopie, aber hier lässt sie sich gut begründen. Die Geschäftslogik wird nicht immer nur mit Eingabedaten arbeiten müssen, sondern auch mit Daten aus anderen Quellen, und dafür wird man die Daten quellenunabhängig vorliegen haben wollen.

Anders sieht es jedoch bei vielen Wald- und Wiesen-Scripten aus. Da spielt sich der Request innerhalb weniger Codezeilen ab. Oftmals verwendet man den Wert nur einmal, und das Umkopieren bringt nur Mehraufwand rein. Der Nutzen ist hierbei reichlich beschränkt.

Ob Vorteil oder Nachteil ergibt sich immer aus der Aufgabenstellung, und deswegen mag ich keine Pauschalaussagen, die eine bestimmte Methode als generell vorteilhafter als eine andere darstellt.

Trotzdem halte ich es für besser Array- und Objekt-Zugriffe nicht zu wiederholen. Es ist sicher auch ein Stück weit persönliche Abwägungssache, doch je länger der Zugriffspfad wird, desto eher wird man wohl dazu tendieren eine Variable als Abkürzung verwenden. Ich denke niemand würde bspw. $foo->bar['baz']->lorem->ipsum['dolor']['sit']->amet() gerne häufig wiederholen müssen. Und dann hängt es natürlich auch davon ab, wie oft man die Zeile schreiben müsste. Ich halte es eben lieber straff.

Die bessere Vorgehensweise in einem solchen Fall ist vermutlich nicht die Einführung einer Variable, sondern eher die Umstrukturierung von Daten und Verarbeitung, dass sich solche Monster erst gar nicht ergeben. Auch das muss man konkret für den Anwendungsfall entscheiden.

Das passiert bei falsch geschriebenen (und damit nicht existenten) Variablen ebenso. In beiden Fällen gibt es nur eine Notice-Meldung. Und diese sind unterdrückt, wenn man sie nicht explizit freikonfiguriert.

Das stimmt, bei Variablen können einem allerdings Code-Quality-Werkzeuge und IDEs weiter entgegenkommen, weil Variablenbezeichner von statischer Code-Analyse erfasst werden können.

PhpStorm beispielsweise kann auch bei Array-Keys eine solche Unterstützung bieten. Allerdings ist diese Hilfe bei PHP in beiden Fällen eingeschränkt, weil sich bestimmte Dinge erst zur Laufzeit ergeben und statisch analysiert aufgrind des Prinzips nicht erkannt werden können.

"Das "beste" aus dieser Situation" zu machen, ist schlicht die Rückgabe von null.

„I call it my billion-dollar mistake. It was the invention of the null reference in 1965.“ – Tony Hoare

Was du vermutlich meinst, ist das Weglassen der Anführungszeichen. Denn dann wird gutmütigerweise angenommen, man meine gar keine Konstante, wenn eine solche nicht existiert, sondern einen String.

Darauf wollte ich eigentlich nicht hinaus.

Dann verstehe ich nicht, was das Beste sein soll. Die Rückgabe von null, wenn man auf etwas nicht vorhandenes zugreift, ist für mich eher eine Notlösung. Schon eher in die Nähe des Besten käme, wenn PHP mitzudenken versucht, und das ausführt, was der Nutzer eigentlich will. Auch wenn solche Magie in manchen Fällen ungewünscht ist.

dedlfix.

[Tabellenkalk]

Hallo,

Ich denke niemand würde bspw. $foo->bar['baz']->lorem->ipsum['dolor']['sit']->amet() gerne häufig wiederholen müssen.

Wenn man oft genug Blindtexte geschrieben hat, kriegt man das dann aber auch auswendig hin :)

Gruß
Kalk

[Matthias Apsel]

Hallo 1unitedpower,

Außerdem sollte man tunlichst vermeiden PHPs $_POST-Array selber zu beschreiben. Der Schein trügt, dass es nur einen gerinfügigen Unterschied mache, ob ein $_POST-Element den leeren String enthält oder gar nicht gesetzt ist. Das zeigt dieser Fall sogar besonders deutlich: Array-Element nicht gesetzt bedeutet, dass die Checkbox nicht ausgewählt wurde. Array-Element gesetzt bedeutet, dass die Checkbox ausgewählt wurde, und zwar unabhängig vom Wert, der drin steht. Gegenteiliger könnte die Semantik kaum sein.

Ja, das ist mir bewusst. Eine Konstruktion wie

if(!isset($_POST['tagesPreis'])) {
	$tagesPreis = "";
}else {
  $tagesPreis = $_POST["tagesPreis"];
}

lässt aber darauf schließen, dass nicht zwischen angehakt und nicht angehakt unterschieden werden soll. Das habe ich in meiner Antwort auch berücksichtigt. Wenn also auf fehlende Benutzereingaben reagiert werden muss, ist meine Variante nicht zielführend.

Bis demnächst
Matthias

[dedlfix]

Tach!

Eine Konstruktion wie [...] lässt aber darauf schließen, dass nicht zwischen angehakt und nicht angehakt unterschieden werden soll. Das habe ich in meiner Antwort auch berücksichtigt. Wenn also auf fehlende Benutzereingaben reagiert werden muss, ist meine Variante nicht zielführend.

Beim ersten Satz verstehe ich nicht, was du damit sagen möchtest. Zum letzten wäre zu sagen, dass es weder eine Three-State-Checkbox in HTML gibt, noch dass man einen dritten Status auf Serverseite erkennen könnte. Die Checkbox sendet ihren value bei angeklickt und ist ansonsten gar nicht vorhanden. Man kann da nicht zwischen nicht angekreuzt und Nutzer hat gar nichts gemacht unterscheiden. Für solche Fälle kann man sich nur mit Radiobuttons behelfen.

dedlfix.

[pl]

Zusätzlich zu den bisherigen Antworten: Du solltest dir vielleicht das Umkopieren sparen:

In meiner Welt war das noch nie in Thema. Es ist unwichtig. Und es würde sich in Luft auflösen, wenn Parameter nicht aus einem Array gelesen sondern von einer Funktion/Methode geliefert werden:

my $preis = $self->param('preis');

Wobei die param()-Methode so intelligent gemacht werden kann, dass sie bei mehreren gleichnamigen Parametern gleich alle Werte als Array liefert. Und kompatibel zu SOAP, XML-PRC... sein kann ;)

[woodfighter]

Tach,

Zusätzlich zu den bisherigen Antworten: Du solltest dir vielleicht das Umkopieren sparen:

In meiner Welt war das noch nie in Thema. Es ist unwichtig.

nein, auch in perl sprechen die selben Gründe wie in PHP gegen das Umkopieren.

Und es würde sich in Luft auflösen, wenn Parameter nicht aus einem Array gelesen sondern von einer Funktion/Methode geliefert werden

Nein, würde es nicht.

Wobei die param()-Methode so intelligent gemacht werden kann, dass sie bei mehreren gleichnamigen Parametern gleich alle Werte als Array liefert.

Solange man sich von Listen fernhält… (Kontext)

mfg
Woodfighter

[pl]

hi,

Solange man sich von Listen fernhält… (Kontext)

Ne, nicht fernhalten, sondern richtig damit umgehen!

Aber ansonsten sehe ich das mindestens genauso respektlos wie Du.

[woodfighter]

Tach,

Ne, nicht fernhalten, sondern richtig damit umgehen!

das Sprachfeature ist kaputt, weil es aussieht wie etwas, aber anders funktioniert; das führt dazu, dass immer wieder Leute in die selben Fallen tappen werden. Schlechtes Design lässt sich nicht durch den Hinweis aufs Manual ersetzen.

mfg
Woodfighter

[pl]

Tach,

Ne, nicht fernhalten, sondern richtig damit umgehen!

das Sprachfeature ist kaputt, weil es aussieht wie etwas, aber anders funktioniert; das führt dazu, dass immer wieder Leute in die selben Fallen tappen werden. Schlechtes Design lässt sich nicht durch den Hinweis aufs Manual ersetzen.

Abgesehen davon, dass es sich tatsächlich lohnt, über einen eigenen Parser nachzudenken und CGI.pm komplett zu streichen (siehe mein Post vorhin, Hinweise auf eine intelligente param()-Methode ):

Ein Webentwicklr sollte schon wissen, wann auf einen Parameter ein Wert oder mehrere Werte zu erwarten sind. Ich hab das noch nach der alten Schule gelernt, von der Pike auf sozusagen. Dazu gehört u.a. auch der richtige Umgang mit Schlüsselparametern. Da ist heute alles Mangelwissen. CGI.pm ist ok. CGI.pm ist NICHT das Sicherheitsloch. Es ist bemerkenswert, wie sich Perl-Halbwissende immer wieder auf dieses Thema stürzen und von einer angeblichen Sichrheitslücke reden, die gar nicht von CGI.pm ausgeht, sondern von fehlenden Grundlagenwissen.

[woodfighter]

Tach,

Ein Webentwicklr sollte schon wissen, wann auf einen Parameter ein Wert oder mehrere Werte zu erwarten sind.

der Webentwickler muss immer erwarten, dass er mehr oder weniger Werte erhält, als er geplant hat.

Ich hab das noch nach der alten Schule gelernt, von der Pike auf sozusagen. Dazu gehört u.a. auch der richtige Umgang mit Schlüsselparametern. Da ist heute alles Mangelwissen. CGI.pm ist ok. CGI.pm ist NICHT das Sicherheitsloch.

Die Doku von CGI.pm sagte etwas anderes als die Implementation tat und wenn man sich auf die Doku verließ, hatte man eine potentielle Sicherheitslücke. Also kam der Bug klar von CGI.pm.

mfg
Woodfighter

[pl]

Die Doku von CGI.pm sagte etwas anderes als die Implementation tat und wenn man sich auf die Doku verließ, hatte man eine potentielle Sicherheitslücke. Also kam der Bug klar von CGI.pm.

Nochmal nur für Dich: Das beschriebene Verhalten ist kein Bug in CGI.pm und hat mit CGI.pm auch gar nichts zu tun. Mehr darüber findest Du auf http://www.perl-community.de aber Du kannst Dich gerne auf Youtube profilieren, das ist dann Deine Entscheidung.

[pl]

Die Doku von CGI.pm sagte etwas anderes als die Implementation tat und wenn man sich auf die Doku verließ, hatte man eine potentielle Sicherheitslücke. Also kam der Bug klar von CGI.pm.

Nochmal nur für Dich: Das beschriebene Verhalten ist kein Bug in CGI.pm und hat mit CGI.pm auch gar nichts zu tun. Mehr darüber findest Du auf http://www.perl-community.de aber Du kannst Dich gerne auf Youtube profilieren, das ist dann Deine Entscheidung.

Btw., die Doku CGI.pm http://search.cpan.org/~leejo/CGI-4.22/lib/CGI.pod gibt einen Hinweis auf mögliche Probleme (Warning - calling param() in list context can lead to vulnerabilities ....). Wies hier immer so schön heißt: Kontextwechsel beachten.

[woodfighter]

Tach,

Btw., die Doku CGI.pm http://search.cpan.org/~leejo/CGI-4.22/lib/CGI.pod gibt einen Hinweis auf mögliche Probleme (Warning - calling param() in list context can lead to vulnerabilities ....).

Der Text davor lautet: „Pass the param() / multi_param() method a single argument to fetch the value of the named parameter. If the parameter is multivalued (e.g. from multiple selections in a scrolling list), you can ask to receive an array. Otherwise the method will return a single value.“

Also, was muss ich tun, um ein Array zurückzubekommen? Ich würde davon ausgehen, dass ich einen weiteren Parameter übergeben muss, nicht dass ich in einem impliziten Zustand bin, der mehrere Paremater akzeptieren kann. Und selbst dann bekomme ich eben kein Array zurück, sonst würde ja ein Hash um einen Paramater (nämlich das Array) erweitert werden und nicht die zurückgegebene Liste den Hash in unerwarteter Weise vergößern.

@array = ['foo','bar'];
@list = (1,2,3);
%hash = ('a' => @array, 'b'=>@list);
print $hash{'a'}."\n".$hash{'b'}."\n".$hash{'2'}."\n";

Ausgabe:

ARRAY(0x1456d48)
1
3

Ich würde das erwarten, was a zugewiesen wird, aber nicht das was in b zugewiesen wird und erst recht nicht, dass etwas der 2 zugewiesen wird.

mfg
Woodfighter

[Gunnar Bittersmann]

@@Sara

if ($_POST['tagesPreis'] == "") {
	$tagesPreis = "";
}else {
  $tagesPreis = $_POST["tagesPreis"];
}

Abgesehen davon, dass diese IF-Abfrage nicht das tut, was du willst, macht sie auch nicht wirklich Sinn.
Wenn $_POST['tagesPreis'] == "", dann setze $tagesPreis auf "", also auf den Wert von $_POST['tagesPreis'];
andernfalls auf den Wert von $_POST['tagesPreis']?

$tagesPreis = $_POST['tagesPreis']; hätte dasselbe bewirkt.

Wie bereits behandelt bewirkt isset() mehr als ==.

if(!isset($_POST['tagesPreis'])) {
	$tagesPreis = "";
}else {
  $tagesPreis = $_POST["tagesPreis"];
}

Du konntest dich noch nicht an diese Schreibweise gewöhnen?

Die bietet sich immer dann an, wenn im THEN- und im ELSE-Zweig eine Zuweisung zur selben Variablen mit unterschiedlichen Werten erfolgt:

$tagesPreis = !isset($_POST['tagesPreis']) ? '' : $_POST['tagesPreis'];
wäre dasselbe in kompakt.

Zum Umkopieren hatte Matthias ja schon was gesagt.

Noch was zur Schreibweise: Warum schreibst du einmal $_POST['tagesPreis'], ein anderess Mal $_POST["tagesPreis"]?

Einfache und doppelte Anführungszeichen haben in PHP unterschiedliche Bedeutung. In aller Regel willst du einfache verwenden.

LLAP 🖖

[Sara]

Hallo,

Du konntest dich noch nicht an diese Schreibweise gewöhnen?

nach langer Überlegung habe ich mich dagegen entschieden. Zum einen weil deine Schreibweise nur sehr schwer zu lesen ist und zweitens wir im Team arbeiten. Wenn jeder etwas anderes schreibt entsteht nur Chaos.

Noch was zur Schreibweise: Warum schreibst du einmal $_POST['tagesPreis'], ein anderess Mal $_POST["tagesPreis"]?

Einfache und doppelte Anführungszeichen haben in PHP unterschiedliche Bedeutung. In aller Regel willst du einfache verwenden.

Das liegt daran, wie ich es schreibe. Wenn ich faul bin schreibe ich in Sublime Text 2 nur post und drücke die Tab - Taste, dann wird mit der Code vervollständigt. Wenn ich den Code von Hand schreibe und ich $_POST[ schreibe, wird mir ebenfalls der Code ergänz allerdings hier nur mit einem ' und im ersten Fall mit "

[Auge]

Hallo

Du konntest dich noch nicht an diese Schreibweise gewöhnen?

nach langer Überlegung habe ich mich dagegen entschieden. Zum einen weil deine Schreibweise nur sehr schwer zu lesen ist und zweitens wir im Team arbeiten. Wenn jeder etwas anderes schreibt entsteht nur Chaos.

In diesem Fall sollte sowieso ein Styleguide vorgegeben oder verabredet sein/werden.

… [Einfache und doppelte Anführungszeichen] …

Das liegt daran, wie ich es schreibe. Wenn ich faul bin schreibe ich in Sublime Text 2 nur post und drücke die Tab - Taste, dann wird mit der Code vervollständigt. Wenn ich den Code von Hand schreibe und ich $_POST[ schreibe, wird mir ebenfalls der Code ergänz allerdings hier nur mit einem ' und im ersten Fall mit "

Das ist suboptimal. Das sollte sich aber im Programm einstellen lassen. Eine einheitliche Schreibweise, welche das schlussendlich auch sein wird, ist von Vorteil.

Tschö, Auge