Malcolm Beck´s: Einfacher Formmailer

hi,

habe nun meinen Formmailer fertig, zumindest aus meiner Sicht.
Wenn es den einen oder anderen Interessierten gibt kann er es ja mal testen und berichten, wie es funktioniert.

http://start-navi.de/beispiele/kontakt-formular.rar
Im Einsatz

Ich habe alles mal in einer Datei zusamengefasst,
http://start-navi.de/beispiele/kontakt-formular.txt

Vielleicht kann sich das ja wer ansehen und auf fehler hinweisen.

grüße

--
I have a Dream...
Bugs erzeugen gegenbugs.
Wir müssen Bugs mit Bugs bekämpfen!
  1. hi,

    habe nun meinen Formmailer fertig, zumindest aus meiner Sicht.
    Wenn es den einen oder anderen Interessierten gibt kann er es ja mal testen und berichten, wie es funktioniert.

    Habs mir angeschaut. Da sind viel zu viele Felder. Für ein Formular, was einen (verwaltungs)technischen Hintergrund hat, mag das gerechtfertigt sein.

    Ein Kontaktformular jedoch sollte auch auf Besucher mit Berührungsängsten anziehend wirken und einfach auszufüllen sein.

    Mein Vorschlag: Maximal drei Felder,

    • eMail
    • Betreff [optional]
    • Text

    Für ein Kontaktformular, was auf eine _erste_ Kontaktaufnahme hinzielt, sollte das reichen.

    Viele Grüße,
    Hotte

    1. hi,

      Mein Vorschlag: Maximal drei Felder,

      • eMail
      • Betreff [optional]
      • Text
        Für ein Kontaktformular, was auf eine _erste_ Kontaktaufnahme hinzielt, sollte das reichen.

      Es geht ja um die funktionalität, man kann ohne weiteres die Felder, die man nicht haben möchte löschen, dann erscheinen diese auch nicht (nur halt auf die Pflichtfelder achten), und bei bedarf sogar noch erweitern.

      Danke trotzdem für den hinweis.

      grüße

      --
      I have a Dream...
      Bugs erzeugen gegenbugs.
      Wir müssen Bugs mit Bugs bekämpfen!
      1. Hallo

        Für meinen Geschmack ist alles was mit Konfiguration und Initialisierung zu tun hat, viel zu zerstreut.

        Im Grunde finde ich es gut, wenn dein Formmailer mehr bietet, als man braucht. Aber hier gehören konzentrierte Konfigurationsabschnitte und eine rationalere Behandlung der einzelnen Formmailer-"Module" hinzu.

        Die Gefahr besteht immer, dass ein solches Script eigentlich schlecht zu pflegen ist, weil die verschiedenen logischen Bereiche nicht klar vorliegen und man sich das Zeugs zusammensuchen muss.

        Vielleicht hat das spezifisch mit PHP zu tun, dass man eher entlang der "Content-Ausgabe-Logik" sein Programm schreibt, statt entlang einer Datenlogik, wie man das mit Perl instinktiv entweder prozedural oder via OOP/Module gewöhnlich macht.

        mfg Beat

        --
        Selber klauen ist schöner!
        1. hi,

          Die Gefahr besteht immer, dass ein solches Script eigentlich schlecht zu pflegen ist, weil die verschiedenen logischen Bereiche nicht klar vorliegen und man sich das Zeugs zusammensuchen muss.

          Im Grunde sind es 4 Funktionen, die, wenn man den Aufbau versteht sehr leicht zu pflegen sind.

          Ein beispiel für eine Funktion:

          function tsInput($feld) {  
           echo "<label for=\"$feld\">$feld</label>  
          <input type=\"text\" name=\"$feld\" id=\"$feld\" class=\"input_text_klasse\" ";  
            
            if(isset($_POST[$feld]) && $_POST[$feld]!=='')  
           echo 'value="'.htmlspecialchars($_POST[$feld]).'"';  
            
            elseif(isset($_POST[$feld]) && $_POST[$feld]=='')  
           echo  'value="'.htmlspecialchars($_POST[$feld]).'" ';  
            
           echo ' />';  
          }
          

          Wenn man ein wenig von HTML versteht, sollte klar sein, was hier passiert.

          Vielleicht hat das spezifisch mit PHP zu tun, dass man eher entlang der "Content-Ausgabe-Logik" sein Programm schreibt, statt entlang einer Datenlogik, wie man das mit Perl instinktiv entweder prozedural oder via OOP/Module gewöhnlich macht.

          Nein, in PHP werden normalerweise auch Funktion und Ausgabe getrennt, ich war aber der Ansicht, das es hier nicht nötig ist, da ja von vornherein feststeht, was passieren soll und einen Ersatz für input kenne ich nicht, daher brauche ich nicht zu fürchten, das ich in absehbarer zeit die Ausgabe an sich ändern müsste.

          Wenn man das Script richtig einsetzt braucht man nur noch auf der Kontakt Seite die Funktionen aufrufen, den rest erledigt das Script.

          <?php  
           tsInput("Nachname");  
           tsInput("Sonstiges");  
          ?>
          

          Und genau das war mein Ziel.

          grüße

          --
          I have a Dream...
          Bugs erzeugen gegenbugs.
          Wir müssen Bugs mit Bugs bekämpfen!
          1. Hi,

            function tsInput($feld) {

            echo "<label for="$feld">$feld</label>
            <input type="text" name="$feld" id="$feld" class="input_text_klasse" ";

            [...]

            }

              
            tsInput('PLZ/Ort');  
            tsInput('Straße und Hausnummer');  
            tsInput('1. Platz');  
              
            Führt alles zu invalidem Code. Insbesondere die Verwendung der Werte als ID, ohne diese gültig zu machen \*und mit einem klar definierten Prefix als Namespace zu versehen\*, halte ich für einen live-kritischen Bug. Auch andere Aspekte des HTML-Codes, insbesondere die Klassen, aber auch die grundsätzliche Struktur, sollten unbedingt konfigurierbar sein.  
              
            
            > Nein, in PHP werden normalerweise auch Funktion und Ausgabe getrennt, ich war aber der Ansicht, das es hier nicht nötig ist, da ja von vornherein feststeht, was passieren soll und einen Ersatz für input kenne ich nicht, daher brauche ich nicht zu fürchten, das ich in absehbarer zeit die Ausgabe an sich ändern müsste.  
              
            Von XForms und ähnlichem abgesehen mag es tatsächlich keinen Ersatz zu <input> zu geben. Es gibt jedoch Seiten, die als HTML anstatt XHTML aufgebaut sind, bei diesen ist der End-Slash falsch; und es gibt innerhalb des Codes diverse andere Entscheidungen, die absolut gültig aber von Dir nicht beachtet sind. Was ist, wenn ich das Formular als Tabelle oder Definition List aufbauen will?  
              
            
            > Und genau das war mein Ziel.  
              
            Wenn dieses Ziel beinhaltet, dass die Zielgruppe aus Dir besteht, hast Du es erreicht. Ansonsten nicht. Mir ist bereits unklar, warum Du diese offensichtlich objektbezogene Funktionalität ohne Objektorientierung implementiert hast.  
              
            Cheatah  
            
            -- 
            X-Self-Code: sh:( fo:} ch:~ rl:° br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|  
            X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html  
            X-Will-Answer-Email: No  
            X-Please-Search-Archive-First: Absolutely Yes
            
            1. hi,

              Insbesondere die Verwendung der Werte als ID, ohne diese gültig zu machen *und mit einem klar definierten Prefix als Namespace zu versehen*, halte ich für einen live-kritischen Bug.

              Du meinst sowas in der art wie <input tpype="text" id="Name_input">?
              Das wäre schnell gemacht.

              Auch andere Aspekte des HTML-Codes, insbesondere die Klassen, aber auch die grundsätzliche Struktur, sollten unbedingt konfigurierbar sein.

              Die Struktur als ganzes ist ja konfigurierbar, die Funktion an sich baut nur den input mit zugehörigem label zusammen, im HTML ist das also nur

              <label for="Nachname">Nachname</label>  
              <input type="text" name="Nachname" id="Nachname" class="input_text_klasse"  />
              

              Was noch machbar wäre, eine Auswahl ob label vor oder nach dem input eingefügt werden soll, steht auf der ToDo Liste. :)
              Um die Klassennamen mittels _einer_ Variable konfigurierbar zu machen muss ich erst noch ein wenig üben.

              Es gibt jedoch Seiten, die als HTML anstatt XHTML aufgebaut sind, bei diesen ist der End-Slash falsch;

              Der ToDo Liste hinzugefügt.

              und es gibt innerhalb des Codes diverse andere Entscheidungen, die absolut gültig aber von Dir nicht beachtet sind. Was ist, wenn ich das Formular als Tabelle oder Definition List aufbauen will?

              Meinst du damit, das <label> in einer Zelle und <input> in einer zweiten Zelle stehen?
              Wir wollen doch weg vom Table Design. :)

              Mir ist bereits unklar, warum Du diese offensichtlich objektbezogene Funktionalität ohne Objektorientierung implementiert hast.

              Nu gib mir doch eine Chance, hab erst vor einer Woche verstanden/gelernt wie man eine Function in PHP baut, das ist sozusagen mein einstieg in den Functionsbau.
              Ich hab noch viel mehr Ideen, was das Script später alles können soll, nur muss ich das langsam angehen.

              Danke jedenfalls für die hinweise.

              grüße

              --
              I have a Dream...
              Bugs erzeugen gegenbugs.
              Wir müssen Bugs mit Bugs bekämpfen!
          2. Hi,

            Ein beispiel für eine Funktion:

            function tsInput($feld) {

            echo "<label for="$feld">$feld</label>
            <input type="text" name="$feld" id="$feld" class="input_text_klasse" ";

            if(isset($_POST[$feld]) && $_POST[$feld]!=='')
            echo 'value="'.htmlspecialchars($_POST[$feld]).'"';

            elseif(isset($_POST[$feld]) && $_POST[$feld]=='')
            echo  'value="'.htmlspecialchars($_POST[$feld]).'" ';

            echo ' />';
            }

              
            das finde ich viel wie Cheatah viel zu viel und außerdem noch schlecht lesbar und größtenteils überflüssig.  
            - Es ist unflexibel, den gesamten HTML-Code von PHP zu generieren.  
            - Die Maskierungen machen den Code schlecht lesbar. [1]  
            - Die Abfrage auf Existenz ist überflüssig und zudem unsinnig, wenn das label trotzdem ausgegeben wird.  
            - Die Unterscheidung ob Daten vorhanden sind oder nicht ist überflüssig.  
              
            Kurzum, das geht kürzer z.B. so:  
            ~~~php
            function tsInput($field,$def='') {  
              echo 'name="',$field,'" value="';  
              if(!empty($_POST[$field])) echo htmlspecialchars($_POST[$field]);  
              elseif($def) echo htmlspecialchars($def);  
              echo '"';  
            }
            

            Dies trennt zum einen die Verarbeitung von der Ausgabe und im HTML kann dann ganz flexibel z.B. auch dies angeben:

            <dt><label for="strasse">Straße / Hausnummer:</label></dt>  
            <dd><input type="text" id="strasse" <?php tsInput("Strasse"); ?> /></dd>
            

            Übrigens musst Du htmlspecialchars() wirklich nicht auf fest integrierte Strings ohne kritische Zeichen im Code anwenden.

            [1] Statt echo "<label for=\"$feld\">$feld</label>" würde ich
            echo '<label for="',$feld,'">',$feld,'</label>' schreiben.

            freundliche Grüße
            Ingo

            1. hi,

              das finde ich viel wie Cheatah viel zu viel und außerdem noch schlecht lesbar und größtenteils überflüssig.

              • Es ist unflexibel, den gesamten HTML-Code von PHP zu generieren.
              • Die Maskierungen machen den Code schlecht lesbar. [1]
              • Die Abfrage auf Existenz ist überflüssig und zudem unsinnig, wenn das label trotzdem ausgegeben wird.
              • Die Unterscheidung ob Daten vorhanden sind oder nicht ist überflüssig.

              Ich werde das Script noch ein wenig verbessern, eure Vorschläge werde ich umsetzen, nur Pflichtfelder finde ich sind ein muss, wäre Doof wenn jemand auf die Kontakt Seite geht und versenden klickt, so würde ich ja auch leere Mails bekommen, das ist nicht Sinn der Sache.

              Kurzum, das geht kürzer z.B. so:

              function tsInput($field,$def='') {

              echo 'name="',$field,'" value="';
                if(!empty($_POST[$field])) echo htmlspecialchars($_POST[$field]);
                elseif($def) echo htmlspecialchars($def);
                echo '"';
              }

                
              Danke, auf diesen Code habe ich ja meine Funktionen aufgebaut und endlich mal den Funktionsbau verstanden.  
              Du hast den Stein ins rollen gebracht.  :)  
              Aber wie gesagt, Pflichtfelder möchte ich schon haben.  
                
              
              > Übrigens musst Du htmlspecialchars() wirklich nicht auf fest integrierte Strings ohne kritische Zeichen im Code anwenden.  
                
              Naja, kost ja nichts und sicher ist sicher, da ich auch nicht genau weiss, worauf ich achten muss sichere ich lieber alles ab.  
              Meinst du vielleicht die arrays für die Radiobuttons?  
                
              
              > [1] Statt `echo "<label for=\"$feld\">$feld</label>"`{:.language-php} würde ich  
              > `echo '<label for="',$feld,'">',$feld,'</label>'`{:.language-php} schreiben.  
                
              Das werde ich auch noch machen sobald ich wieder Zeit finde, hab zurzeit eine menge um die Ohren.  
                
              grüße  
              
              -- 
              [I have a Dream...](http://www.myvideo.de/watch/2503116/I_have_a_dream_Will_I_AM_feat_Common)  
                
              Bugs erzeugen gegenbugs.  
              Wir müssen Bugs mit Bugs bekämpfen!
              
              1. Hi,

                nur Pflichtfelder finde ich sind ein muss, wäre Doof wenn jemand auf die Kontakt Seite geht und versenden klickt, so würde ich ja auch leere Mails bekommen, das ist nicht Sinn der Sache.

                schon klar. Mein Hinweis bezog sich aber gar nicht auf Pflichtfelder, sondern auf Deine überflüssige Überprüfung:
                if(isset($_POST[$pflicht_feld]) && $_POST[$pflicht_feld]!=='')

                Übrigens solltest Du die Variablen $pflicht_feld_check und $pflicht_feld_check_1 initialisieren und Dich vielleicht auch mit den boolschen Werten true und false befassen.

                Übrigens musst Du htmlspecialchars() wirklich nicht auf fest integrierte Strings ohne kritische Zeichen im Code anwenden.

                Naja, kost ja nichts und sicher ist sicher, da ich auch nicht genau weiss, worauf ich achten muss sichere ich lieber alles ab.

                htmlspecialchars("Privat") ist z.B. absolut überflüssig und "<Privat>" oder ""Privat"" würdest Du hier wohl kaum eingeben, oder?

                freundliche Grüße
                Ingo

                1. hi,

                  schon klar. Mein Hinweis bezog sich aber gar nicht auf Pflichtfelder, sondern auf Deine überflüssige Überprüfung:
                  if(isset($_POST[$pflicht_feld]) && $_POST[$pflicht_feld]!=='')

                  Wie könnte ich sonst noch prüfen, ob das Feld ausgefüllt wurde?

                  Übrigens solltest Du die Variablen $pflicht_feld_check und $pflicht_feld_check_1 initialisieren und Dich vielleicht auch mit den boolschen Werten true und false befassen.

                  true und false kenne ich, nur schaffe ich es noch nicht, die Variablen aus den Funktionen Global zu verwenden, das habe ich noch nicht ganz verstanden.
                  Wenn ich das verstehe, kann ich zumindest einiges besser machen.

                  htmlspecialchars("Privat") ist z.B. absolut überflüssig und "<Privat>" oder ""Privat"" würdest Du hier wohl kaum eingeben, oder?

                  http://forum.de.selfhtml.org/archiv/2008/5/t171930/#m1126371
                  Der Beitrag auf den hier verlinkt ist, meine Antwort darauf und dann nochmal Volkers Beitrag.
                  Daher diese überflüssige Überprüfung.

                  grüße

                  --
                  I have a Dream...
                  Bugs erzeugen gegenbugs.
                  Wir müssen Bugs mit Bugs bekämpfen!
                  1. Hi,

                    schon klar. Mein Hinweis bezog sich aber gar nicht auf Pflichtfelder, sondern auf Deine überflüssige Überprüfung:
                    if(isset($_POST[$pflicht_feld]) && $_POST[$pflicht_feld]!=='')

                    Wie könnte ich sonst noch prüfen, ob das Feld ausgefüllt wurde?

                    an _dieser_ Stelle ist die Überprüfung doch gar nicht nötig. Du willst doch hier lediglich die Eingabe - soweit vorhanden - als value eintragen. Nichts spricht gegen value="", wenn das Feld noch nicht ausgefüllt wurde - siehe meinen Codeschnipsel.
                    Amn anderer Stelle würde sich einfach !empty() anbieten.

                    true und false kenne ich, nur schaffe ich es noch nicht, die Variablen aus den Funktionen Global zu verwenden, das habe ich noch nicht ganz verstanden.

                    $test=array(true,false);
                    var_dump($test); ergibt: array(2) { [0]=>  bool(true) [1]=>  bool(false) }
                    echo 'true="',$test[0],'", false="',$test[1],'"'; ergibt: true="1", false=""
                    jetzt etwas klarer? Wenn ja, dann noch ein Schrittchen weiter:
                    true=="true" - aber true!=="true" ;-)
                    Immer noch klar? Dann mal false:
                    false!="false"; false==0; false==""; - aber false!=="";

                    htmlspecialchars("Privat") ist z.B. absolut überflüssig und "<Privat>" oder ""Privat"" würdest Du hier wohl kaum eingeben, oder?

                    http://forum.de.selfhtml.org/archiv/2008/5/t171930/#m1126371
                    Der Beitrag auf den hier verlinkt ist, meine Antwort darauf und dann nochmal Volkers Beitrag.
                    Daher diese überflüssige Überprüfung.

                    wie Du sagst: überflüssig. Denn Du maskierst keine potentiell gefährlichen Usereingaben, sondern Deinen eigenen fest im Script stehenden Text. Das ist etwa so, als wenn Du strtolower("ohnehin kleingeschriebener text"); notierst.

                    freundliche Grüße
                    Ingo

                    1. hi,

                      Amn anderer Stelle würde sich einfach !empty() anbieten.

                      Achja, empty gibt es auch noch.

                      $test=array(true,false);
                      var_dump($test); ergibt: array(2) { [0]=>  bool(true) [1]=>  bool(false) }
                      echo 'true="',$test[0],'", false="',$test[1],'"'; ergibt: true="1", false=""
                      jetzt etwas klarer? Wenn ja, dann noch ein Schrittchen weiter:
                      true=="true" - aber true!=="true" ;-)
                      Immer noch klar? Dann mal false:
                      false!="false"; false==0; false==""; - aber false!=="";

                      Mit true und false kann ich schon was anfangen, es ging mir darum, das ich diese nicht Global bearbeiten kann, also aus der Funktion heraus.
                      http://www.php.net/global#language.variables.scope.global - Da hakt es noch ein wenig mit dem Verständnis.
                      Bzw. das Prinzip verstehe ich , kriege es aber nicht in mein Formular eingebaut.

                      http://forum.de.selfhtml.org/archiv/2008/5/t171930/#m1126371

                      Volkers Beitrag.

                      wie Du sagst: überflüssig. Denn Du maskierst keine potentiell gefährlichen Usereingaben, sondern Deinen eigenen fest im Script stehenden Text.

                      Das dachte ich mir Anfangs auch, bis mir Volker diese Nachricht geschrieben hatte, wobei mir immer noch schleierhaft ist, wie das gehen kann.

                      grüße

                      --
                      I have a Dream...
                      Bugs erzeugen gegenbugs.
                      Wir müssen Bugs mit Bugs bekämpfen!
                      1. Hi,

                        Mit true und false kann ich schon was anfangen, es ging mir darum, das ich diese nicht Global bearbeiten kann, also aus der Funktion heraus.
                        http://www.php.net/global#language.variables.scope.global - Da hakt es noch ein wenig mit dem Verständnis.
                        Bzw. das Prinzip verstehe ich , kriege es aber nicht in mein Formular eingebaut.

                        Sorry, aber ich verstehe Dein Problem nicht. true und false sind Schlüsselworte wie Konstanten, die Du über define anlegst. Die kannst Du einfach und überall verwenden.

                        wie Du sagst: überflüssig. Denn Du maskierst keine potentiell gefährlichen Usereingaben, sondern Deinen eigenen fest im Script stehenden Text.

                        Das dachte ich mir Anfangs auch, bis mir Volker diese Nachricht geschrieben hatte, wobei mir immer noch schleierhaft ist, wie das gehen kann.

                        wie was gehen kann? Einen fest im Script stehenden Text kann niemand beeinflussen, ohne das Script zu ändern.

                        freundliche Grüße
                        Ingo