nicht angemeldet
Neuer Artikel: Fortgeschrittener PHP-Formmailer
Moin!
Angesichts des Bedarfs, der hier im Forum immer wieder durch entsprechende Fragen dokumentiert wird, habe ich einen neuen Artikel zum fortgeschrittenen Mailen unter PHP veröffentlicht:
http://aktuell.de.selfhtml.org/artikel/php/form-mail-advanced/
Aus Gründen der Vergleichbarkeit ist die Funktionalität bewußt genau identisch zum einfachen Formmailer, aber ich gehe ein wenig auf die Vorteile ein, die die vorgeschlagene Bibliothek SwiftMailer bietet, wenn man mehr will.
- Sven Rautenberg
-
moin,
http://aktuell.de.selfhtml.org/artikel/php/form-mail-advanced/
Bis auf ein die() ist die Fehlerbehandlung soweit fortgeschritten, dass sie praktisch weg ist.
Hotti
-
Hi!
Einige Ergänzungen und Anmerkungen zu
http://aktuell.de.selfhtml.org/artikel/php/form-mail-advanced/
Man sollte vielleicht noch das Stichwort Fluent Interface als Kommentar in den Code stellen, damit interessierte Leser, die diese Art der Verkettung nicht kennen, sich mit passendem Stichwort auf die Suche begeben können. Oder man erläutert es kurz und dass weitere Methodenaufrufe an beliebigen Stellen eingefügt oder angehängt werden können.
Warum ist ($_SERVER['REQUEST_METHOD'] === "POST") ein typidentischer Vergleich? Was für andere Typen erwartest du denn in diesem Feld? Und welchen Nachteil/Vorteil hat es, wenn ein solcher kommt gegenüber einem normalen Vergleich?
Warum ist da eine Definitionsliste für die Felder des Formulars verwendet worden? Eine einfache Liste mit Label-Elementen wäre semantisch besser und hätte auch noch einen Nutzen für den Anwender. Ein Untereinander statt Nebeneinander (bei Checkboxen, Radios und Select) verlängert zwar die Code-Box, doch die damit erhöhte Übersichtlichkeit wiegt deutlich mehr.
Und die() ist keine Fehlerbehandlung. Das sollte man auch nicht der Einfachheit in Beispielen bringen. Beispiele haben Lehrcharakter und werden immer wieder als "so muss man es machen" angesehen. Deshalb sollte man dort besonders auf die Dinge achten, die man ansonsten immer bemängelt, weil sie schlecht sind.
Man könnte vielleicht auch noch eine Eingabevalidierung andeuten nebst alternativem Programmfluss, der bei Nichtbestehen die Mail nicht sendet. Vermutlich ist da gleich ein Umbau auf Affenformular gescheiter.
Lo!
-
hi,
Und die() ist keine Fehlerbehandlung.
Ist auch nicht angebracht, wenn eine Mail nicht gesendet werden kann. Ein Skript darf sterben, wenn es gar nicht anders geht und wenn ein Daten-GAU nicht mehr anders abzuwehren ist, was hier nicht der Fall ist.
Der Besucher erwartet aussagekräftige Informationen und eine Alternative, bsp. eine Telefonnummer...
@Sven, Du hast schon bessere Skripts geschrieben. Die Programmiertechnik "Affenformular" wäre hier zweckmäßig, also kein redirect() nach dem Submit, ein redirect() bedeutet immer ein die('hinsichtlich Fehlerbehandlung'), sowohl für den Anwender als auch für den Programmierer.
Machs doch so, wie mit dem "Affenformular", nach dem Submit wird das Formular wieder aufgerufen, mit Erfolgs- oder Fehlermeldungen an der "richtigen" Stelle, beispielsweise, wenn die Absenderadresse fehlt oder die Nachricht selbst gar nicht geschrieben wurde.
Erfolgsmeldung: Das Formular könnte eine neue Überschrift bekommen und die Eingabefelder werden disabled/redonly gesetzt.
Bei einem schwerwiegenden Fehler (Library nicht verfügbar, Mailserver weg o.ä.) könnte anstelle eines die() das Formular gegen eine entsprechende Fehlerseite komplett ausgetauscht werden, so dass der Besucher sofort sehen kann "hier kannste nichts schicken".
Und überhaupt: Die beiden Header
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printablerechtfertigen auch keine Library, wenn da nur ein Mailformular zu schreiben ist, für "quoted-printable" gibt es bestimmt auch in PHP eine Funktion, die das tut und ein Pipe-Handle auf sendmail geht auch mit PHP zu machen.
Hotti
-
Hi!
@Sven, Du hast schon bessere Skripts geschrieben. Die Programmiertechnik "Affenformular" wäre hier zweckmäßig, also kein redirect() nach dem Submit, ein redirect() bedeutet immer ein die('hinsichtlich Fehlerbehandlung'), sowohl für den Anwender als auch für den Programmierer.
Machs doch so, wie mit dem "Affenformular", nach dem Submit wird das Formular wieder aufgerufen, mit Erfolgs- oder Fehlermeldungen an der "richtigen" Stelle, beispielsweise, wenn die Absenderadresse fehlt oder die Nachricht selbst gar nicht geschrieben wurde.Dass man bei Erfolg trotz Affenformular auf eine andere Seite weiterleitet, hat auch einen technischen Grund. Denn auf der Seite kann der Anwender F5/Refresh drücken wie er will, ohne dass die Mail nochmal abgesendet wird. Deswegen war die Weiterleitung bei Erfolg kein prinzipieller Kritikpunkt von mir. Vielleicht kann man es dahingehend optimieren, dass man auf die selbe Seite + Parameter (wenn man nicht in einer Session vermerken kann, dass eine Erfolgsmeldung angezeigt werden soll) weiterleitet.
Erfolgsmeldung: Das Formular könnte eine neue Überschrift bekommen und die Eingabefelder werden disabled/redonly gesetzt.
Warum? Man kann sie ganz weglassen, weil sie keine Punkte mehr bringen. Stattdessen wäre eine Wiederholung des eingegebenen Textes (ohne dass er von einer Textarea begrenzt wird) sinnvoll, denn dann kann der Anwender sich die Seite zu Dokumentationszwecken ausdrucken.
Und überhaupt: Die beiden Header
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
rechtfertigen auch keine Library, wenn da nur ein Mailformular zu schreiben ist, für "quoted-printable" gibt es bestimmt auch in PHP eine Funktion, die das tut und ein Pipe-Handle auf sendmail geht auch mit PHP zu machen.Es geht gerade darum, die Arbeit des Maskierens zu sparen, denn je nach Stelle hat man unterschiedliche Verfahren anzuwenden. Es gibt selbstverständlich Funktionen für quoted-printable in PHP, doch damit hört es ja nicht auf. Dieses Mailer-Script soll ja die Grundlage bilden für weitere komplexe Szenarien, die man nicht zu Fuß erledigen will, weil sie mindestens mal sehr aufwendig sind. Eine Lib, die all dies und weitere Eventualitäten berücksichtigt, und die schon öfter als die eben fertig gestellte Eigenentwicklung auf Herz und Nieren getestet wurde, ist da eine sehr große Arbeitserleichterung und man kann sich schneller wichtigeren Dingen widmen.
Lo!
-
hi,
[..] Eine Lib, die all dies und weitere Eventualitäten berücksichtigt, und die schon öfter als die eben fertig gestellte Eigenentwicklung auf Herz und Nieren getestet wurde, ist da eine sehr große Arbeitserleichterung und man kann sich schneller wichtigeren Dingen widmen.
Full Ack. Das heißt aber auch: die Methoden der Lib konsequent einsetzen. Ein die() wenn die Lib eine Mail nicht senden kann, ist da ein bischen zu wenig.
Von einer Library, die Mails versenden kann, erwarte ich ein bischen mehr Details in Fehlerfällen, deren es mehrere geben kann und die im Programm/Script entsprechend pariert werden sollten. Dann ist auch ein redirect() OK, wenn 'Alles was schiefgehen kann' geprüft wurde (*).
Hotti
(*) Murphys Gesetze beachten ;)
-
Hi!
Ein die() wenn die Lib eine Mail nicht senden kann, ist da ein bischen zu wenig. Von einer Library, die Mails versenden kann, erwarte ich ein bischen mehr Details in Fehlerfällen, deren es mehrere geben kann und die im Programm/Script entsprechend pariert werden sollten.
Zumindest könnte man eine Fehlerauswertung jenseits von die() andeuten und im Artikel erwähnen, wo man nähere Informationen zu den möglichen Fehlermeldungen finden kann. Details müssen/sollten vom Script nicht veröffentlich werden, aber sie sollten einem Admin zugänglich gemacht werden.
Lo!
-
-
-
-