Hi!
ich wollte ja hier gar keine gemüter erregen. ich mache das eigentlich nur, weil der dem die firma gehört ansonsten keinen kennt der's kann und er mir halt optisch vertraut. egal. danke für die vielen kommentare.
Mach dir mal keine Sorgen um uns. Manchmal muss man unter Wissenden "ausfechten" wie man dieses Wissen am besten zur Weitergabe aufbereitet.
also beide codesegmente der php. und der html code stehen in ein und dem selben dokument. das eine im head das andere eben im body.
Der PHP-Code kann komplett vor dem HTML-Teil stehen. Das ist vor allem für solche Fälle wichtig, wenn mit HTTP-Header-beeinflussenden Funktionen gearbeitet wird (z.B: setcookie(), header()). Zudem kommst du damit dem EVA-Prinzip ein Stück näher. Erst _E_ingabedaten auf fachlich gültigen Inhalt testen (gegebenenfalls vorher aus einer Transportsicherung befreien - ist bei PHP meist nicht nötig). Anschließend die _V_erarbeitung, also das was man auch als Geschäftslogik bezeichnet. In dem Teil werden beispielsweise Datenbanken befragt oder Daten gespeichert und die für die Ausgabe relevanten Werte zusammengetragen. Zum Schluss kommt die _A_usgabe und die ermittelten Werte werden in feststehende Textteile eingebettet.
anscheinend ist das tutorial dass ich verwendet habe ja wohl nicht das beste. kennt noch jemand eines das besser funktioniert und mir vielleicht umfangreicher erklärt was ich da gerade in den dreamweaver tippe?
Formmailer sind eine sehr häufig verwendete Funktionalität. Da sollte sich einiges finden lassen. Der Formmailer-Beitrag in SELFHTML aktuell ist gerade nicht verfügbar, weil der Server defekt ist.
Als allgemeine Qualitätsmerkmale würde ich heranziehen:
- unnötiges Umkopieren von $_POST-Werten in einfache Variablen unterbleibt
- veraltete Funktionen
- das Tutorial erklärt den Aufbau anhand der Vorgehensweisen EVA-Prinzip und Affenformular
- Kontextwechsel werden beachtet
- Es können immer Fehler auftreten. Eine robustes Script/Programm berücksichtigt das und wertet sie aus. Zudem sollte die Alternative im Fehlerfall für den Anwender einen Nutzen bringen und ihm aufzeigen, wie er doch noch ans Ziel kommt. Fehlerbehandlung ist mitunter umfangreicher als die eigentliche Geschäftslogik und sprengt leicht den Tutorial-Rahmen. Zumindest angedeutet sollte sie sein und Erklärungen, was hauptsächlich schief gehen kann, sollten vorhanden sein.
- Verzicht auf eine umfangreiche Email-Format-Prüfung. Die schließen meist gültige Adressen aus und helfen nicht die Bohne gegen ungültige Adressen im validen Format.
ps. mir ist schon aufgefallen dass im tutorial von einem code-typ zum anderen gewechselt wird. und das kam mir auch spanisch vor. habe bloß kein einfacheres gefunden.
Das html.de-Tutorial, das du im OP verlinkt hast, wechselt genau einmal. Aber anscheinend ist das nicht das, was du meinst, denn du hast anderen Code in deinem OP. Die Frage ist, was mit dem Wechsel bezweckt wird. Erklärt das Tutorial eher mit Augenmerk auf eine gute Script-Struktur oder mehr anhand der Abläufe aus Anwendersicht oder mit einer anderen Herangehensweise? Oder missachtet es alle guten Prinzipien und wirft wirklich alles durcheinander?
Lo!