(PHP) Wie geht ihr bei der Verarbeitung von Formularen vor?

[Eddie]

Hallo allerseits,

meine Website ist eine einzige Formularhoelle, darum habe ich mir natuerlich irgendwann ein Verfahren ueberlegt, wie ich das am besten mache. Nur ob das so ideal ist, bleibt dahin gestellt.
Falls sich da also bei Euch ein Verfahren vollkommen bewaehrt hat, oder ihr mir grundsaetzlich was raten koennt, waere ich Euch sehr dankbar.

Folgendermassen mache ich es zur Zeit:

Klassen und Methoden heissen natuerlich anders, die Funktionsweise des Fehlerhandlings koennt ihr Euch hier ansehen (einfach nichts oder was fehlerhaftes eingeben): http://www.umdiewelt.de/Asien/Mittlerer-Osten/Katar/Reisebericht-46/Gaestebuch.html

Ich verwende PHP-Klassen. Nur meine Hauptdatei (z.B. gbIndex.php) ist keine Klasse, sondern steuert nur den Zugriff auf die Klassen.

Erhaelt die gbIndex.php keine Formulardaten:
if (sizeof($HTTP_POST_VARS) == 0))
   dann erzeuge ich ein Objekt GBEntry mit fehlenden Daten:
      newEntry = new GBEntry();
   Daraus lasse ich mir mittels der Methode buildForm($printErrors){...} ein Formular ohne Fehleranzeige (denn es sind ja eigentlich fehlende Daten vorhanden) erzeugen:
      newEntry->buildForm(false);

Sonst, falls also Formulardaten erhalten, erzeuge ich ein neues Objekt mit diesen Daten:
    newEntry = new GBEntry($name, $text, ...);
Falls die Daten ok und konsistent sind
    if (newEntry->readyForDB())
  kommt das Ganze in die Datenbank und ich gebe eine Erfolgsmeldung aus
      newEntry->safeToDB();
      newEntry->buildConfirmation();
  sonst erzeuge ich ein Formular mit Fehleranzeige und bereits (fehlerhaft) ausgefuellten Feldern:
      newEntry->buildForm(true);

Was haltet ihr davon? Dieses Verfahren bläht meine Klassen ganz schön auf, vor allem wegen dem ganzen Fehlerhandling. Aber die Fehlermeldungen sind dafuer spezifisch und (wie ich hoffe) hilfreich.
Gibt's was einfacheres, um dasselbe zu erreichen?

Danke für eure Hilfe,
Eddie

[Tom]

Hello Eddi,

was ich schon immer fragen wollte: ist Reise um die Welt eigentlich Deine Seite?

Zum Thema:

Was Du versuchst aufzubauen, ist eine vernünftige Vorgangsbearbeitung

dabei gibt es eine Staffelung

Request
  Vorgang
    Session
      User
        Login
          Rights
            db
              ...
                adminstration
                  ...

Wobei man sich über die Reihenfolge von Vorgang und Session trefflich streiten kann.
Jedenfalls stehen die DB-Funktionen sowweit es geht innen, damit sie von den anderen Klassen oder optionalen includes geschützt werden.

Jeder Vorgang kann aus einer Abfolger verschiedener Formulare am Client und Scriptfunktionen auf dem Server basieren. Außerdem erlauben bestimmte Vorgangsarten auch eine Reentranz, also einen parallelen Start mehrerer Instanzen einer Vorgangsart.

Man muss nun versuchen, sowohl die parallelen Vorgänge zu trennen, als auch deren Stati zu sortieren. Das schlimmste ist nämlich, das in der Sessiondatei jedesmal dieselben Variablen beschrieben werden, wenn ein Formular doppelt instanziiert und "abgeschickt" wird.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[XaraX]

Eddi grüßt Eddie *lach*

meine Website ist eine einzige Formularhoelle,

wie meinst Du das? So viel sind das nicht.

Im wesentlichen definiere ich mir immer alle Defaultwerte des Ausgansformulars und gleiche damit ab; ähnlich diesem Beispiel:

function abbruchfunktion();
    {
    bau_layout();
    exit();
    }

$a['formelement_name']='Ihr Name';
$a['formelement_name']='Ihre Mail-Adresse';
$a['formelement_name']='Ihre Telefonnummer';
$a['formelement_name']='Ihr Text';

foreach($_POST as $k=>$v)
   {
   if(isset($a[$k] && $a[$k]==$_POST[$k]) abbruchfunktion();
   }

umformatierung_und_ablegen();

Wie Du siehst, ist es mir rellativ egal, was mir wer zuschickt, da manchmal auch anonymes Motzen einen weiterpringen kann, wenn man nur genug Verständnis aufbringt. Das Script bricht auch automatisch ab, wenn mal wieder jemand Spielerchen machen will, und mir nunerwünschte $_POST-Daten zukommen lassen will.
Auch den ganzen Firlefanz, daß ich dem User seine Daten wieder an den Schirm ausgeben, mache ich nur noch für nicht private Auftragsarbeiten. Wer mit seinem Brower umgehen kann, weiß wo es "ZURÜCK" geht.

Allerdings verstehe ich den Ansatz "alles immer in eine DB" einzumeißeln so rein gar nicht. Textdatei in ein Verzeichnis ablegen, was umformatiert alles an Daten enthält. Der wird fortlaufent durch auslesen des Speicherverzeichnisses vergeben und wird als nicht freigegeben mit der Endung "_" (also z. B.: 687_) markiert.

Zum Ausgeben lese ich den Inhalt des Speicherverzeichnisses mit while ein und bringe es zur Anzeige. Mehr brauche ich nicht.
Leider ist, wie ich vor einer Woche sehen mußte, auch eine Site die ich gerne mal aufsuche mit eine DB gemacht. Es kam, wie es kommen mußte - nach ein paar clicks kaum auch schon ein DB-Error :\

(provokativ!) =>
Daher frage ich mich ab und an, wofür man Datenbanken braucht. Ich meine; jeder vernünftige Mensch setzt sich in EIN Auto und fährt damit von A nach B. Erstaunlicher Weise habe ich den Eindruck gewonnen, jeder zweite ist aber der Meinung, daß er für eine HP, die man auf eine Diskette packen könnte, DB-Applikationen basteln zu müsse, und fährt somit für meine Begriffe mit dem linken Bein auf einem Autotach und mit dem rechten Bein auf einem anderen Autodach. (Vierteilung mach da doch wirklich mehr Spaß ;)

Gruß aus Berlin!
eddi

[Eddie]

Eddi grüßt Eddie *lach*

Hallo Eddi (Warum nur 4? Goenn' Dir doch 5!),

meine Website ist eine einzige Formularhoelle,

wie meinst Du das? So viel sind das nicht.

Naja, "Hoelle" ist natuerlich uebertrieben. 17 verschiedene Formulare sind's, die meisten stehen nur Mitgliedern zu Verfuegung.

Auch den ganzen Firlefanz, daß ich dem User seine Daten wieder an den Schirm ausgeben, mache ich nur noch für nicht private Auftragsarbeiten. Wer mit seinem Brower umgehen kann, weiß wo es "ZURÜCK" geht.

Man muss halt immer die Balance finden zwischen Aufwand und Benutzerfreundlichkeit. Ich habe mich halt entschieden, den Besuchern so viel Hilfe wie moeglich an die Hand zu geben. Das kostet mitunter viel Zeit und viel Code. Aber ich verliere dafuer keine Besucher, weil mal was nicht gleich geht und sie es nicht verstehen.

Allerdings verstehe ich den Ansatz "alles immer in eine DB" einzumeißeln so rein gar nicht. Textdatei in ein Verzeichnis ablegen, was umformatiert alles an Daten enthält.

Hat alles Vor- und Nachteile. Mit Textdateien bist Du natuerlich unabhaengig von irgendwelchen DB-System. Und ggf. auch flexibler, weil Du Dir Dein eigenes Zeug zusammen basteln kannst. Auf der anderen Seite bekommst Du garantiert Probleme, sobald das Ganze etwas umfangreicher wird. Nimm mal an, Du hast ein paar tausend Gaestebucheintraege (bei mir sind's um die 900, zu Zeit kommen monatlich 100 dazu) und Du willst die nach bestimmten Kriterien anzeigen (z.B. Nr. 4500- 4520). Die muessen natuerlich rausgesucht werden. Also hast Du 2 Moeglichkeiten:
Beim Schreiben des Eintrags die ganze Datei sortieren (oder Indexdateien anlegen) ==> langsames Schreiben, schnelles Lesen.
Oder ungeordnet reinschreiben und beim Lesen alles durchsuchen ==> schnelles Schreiben, langsames Lesen.
Wenn das jetzt kein Gaestebuch ist, sondern was Aufwendigeres, wird's schnell eng.

Leider ist, wie ich vor einer Woche sehen mußte, auch eine Site die ich gerne mal aufsuche mit eine DB gemacht. Es kam, wie es kommen mußte - nach ein paar clicks kaum auch schon ein DB-Error :\

Das kann Dir aber auch mit Textdateien passieren.

... und fährt somit für meine Begriffe mit dem linken Bein auf einem Autotach und mit dem rechten Bein auf einem anderen Autodach.

Das kann Dir aber auch mit Textdateien passieren.

Gruesse, Eddie (mit fuenfen)

[XaraX]

Eddi grüßt Eddie *lach*

[Traurig guck] ich hab' nur vier ;(

meine Website ist eine einzige Formularhoelle,

wie meinst Du das? So viel sind das nicht.
Naja, "Hoelle" ist natuerlich uebertrieben. 17 verschiedene Formulare sind's, die meisten stehen nur Mitgliedern zu Verfuegung.

Ach so.

Man muss halt immer die Balance finden zwischen Aufwand und Benutzerfreundlichkeit. Ich habe mich halt entschieden, den Besuchern so viel Hilfe wie moeglich an die Hand zu geben. Das kostet mitunter viel Zeit und viel Code. Aber ich verliere dafuer keine Besucher, weil mal was nicht gleich geht und sie es nicht verstehen.

Das ist überaus löblich und begrüßenswert, im Gegensatz zu mir (, was ich auch ohne Wenn und Aber bewußt an so hinnehme)

Allerdings verstehe ich den Ansatz "alles immer in eine DB" einzumeißeln so rein gar nicht. Textdatei in ein Verzeichnis ablegen, was umformatiert alles an Daten enthält.
Hat alles Vor- und Nachteile. Mit Textdateien bist Du natuerlich unabhaengig von irgendwelchen DB-System. Und ggf. auch flexibler, weil Du Dir Dein eigenes Zeug zusammen basteln kannst. Auf der anderen Seite bekommst Du garantiert Probleme, sobald das Ganze etwas umfangreicher wird. Nimm mal an, Du hast ein paar tausend Gaestebucheintraege (bei mir sind's um die 900, zu Zeit kommen monatlich 100 dazu) und Du willst die nach bestimmten Kriterien anzeigen (z.B. Nr. 4500- 4520). Die muessen natuerlich rausgesucht werden. Also hast Du 2 Moeglichkeiten:
Beim Schreiben des Eintrags die ganze Datei sortieren (oder Indexdateien anlegen) ==> langsames Schreiben, schnelles Lesen.
Oder ungeordnet reinschreiben und beim Lesen alles durchsuchen ==> schnelles Schreiben, langsames Lesen.
Wenn das jetzt kein Gaestebuch ist, sondern was Aufwendigeres, wird's schnell eng.

Das ganze gliedere ich mal:

Kriterum (z.B. Nr. 4500- 4520)

Also sage ich der auslesen.php?4500=4520 und kann superein-
     fach auf die Dateien zugreifen (nur beispielhaft):

$a=eplode('=',$_SERVER['QUERY_STRING']);
     for($i=$a[0];$i<=$a[1];$i++)
        {
        if(file_exists($path.$i.'.txt') include($path.$i.'.txt');
        }

900+ Monatlich 100

Selbst mehrere 10000 Datein machen nicht wirklich viel aus.
     Aber auch da habe ich eine Lösung (noch nicht anwenden
     müssen) parat: Du läst nur neu Einträge in einzelne Dateien
     schreiben, die nach der Adminfreigabe in Dateien von 1000
     Beiträgen verschwinden läßt.
     Davon ausgehen, daß Du 1024 Byte in eine Zeile packen kannst,
     beschränkst Du beispiels einen Beitrag auf 5 kB Datengröße.

1. Zeile $name."\t".$mail."\t".$link.$usw;
        2. Zeile $textarea[0]
        3. Zeile $textarea[1]
        4. Zeile $textarea[2]
        5. Zeile $textarea[3]

$textarea werden beispielweise alle Umbrüche durch strings
     ersetzt, die mit hoher Wahrscheinlichkeit nicht im text vor
     kommen (bsw.: '¬¬¬'). Danach splittest Du das ganze nur noch
     alle 1024 Byte durch ein Umbruch.
     Setzt "endof($textarea)" vor Zeile fünf ein, wird diese ein-
     fach mit einem Umbruch gefüllt.

So bekommst Du eine Datei, mit 5000 Zeilen für die folgendes
     gilt:

$a=file($phat.'gaestebuchblock_0.txt');
     for($i=0;$i<5001;$i+=5)
        {
        $kopfdaten=explode("\t",$a[$i]);
        $text=$a[$i].$a[$i+1].$a[$i+2].$a[$i+3].$a[$i+4];
        $text=ich_mach_dich_zu_html($text);
        }

Eine Datenbank mach doch prinzipiell(!) auch nicht anderes ;)

Schreibe und Lesegeschwindigkeit

Warum sollte man die ganze Datei sortieren? Neuer Beitrag
     neue fortlaufende Nummer; d. h. für das grade dargelegte:
     fopen($path.'gaestebuchblock_3.txt','a');

Auslesen von Beitrag 4500-4520

(en==Ende an==Anfang)

$an=4500;
          $a=(int) substr($an,0,strlen($an)-3);
          $a=$a*5;
          $an=substr($an,-3);

$en=4520;
          $e=(int) substr($an,0,strlen($an)-3);
          $e=$e*5;

$x=file($path.'gaestebuchblock_'.$an.'.txt');

und dann wieder mit for() 20 mal auslesen, oder aber,
     wenn Du dabei wirklich feststellen solltest, das Dir die
     0,x Sekunden viel zu viel sind kannst du immer noch mit
     fopen() und fseek() an Funktionen arbeiten, sowie einer
     "Logdatei", in der die Datenzeiger auf die eizelnen Bei-
     träge abgelegt sind.

Über exklusivern Zugriffsschutz braucht man sich nicht
     groß zu unterhalten, Tom hatte dort ein vortreffliches
     Kollokvium erst kürzlich hier im Forum geführt.
     Abgesehen davon bist Du der einzige, der in diese Datein
     mit Adminscripten schreiben kann. Und dag würde sogar
     im Notfall von Hand ohne Scripte gehen, da Klartext und
     über FTP erreichbar.
     Wartungsfreuntlicher kann im Fehlerfall glaube ich kaum
     irgendetwas anderes sein.

Das kann Dir aber auch mit Textdateien passieren.

Ist mir noch nicht vorgekommen. Das eine DB aber bereits bei der Programmierung wesentlich mehr Aufmerksamkeit bindet, ist ansich ein Indiz für mögliche Fehlerquellen.

... und fährt somit für meine Begriffe mit dem linken Bein auf einem Autotach und mit dem rechten Bein auf einem anderen Autodach.
Das kann Dir aber auch mit Textdateien passieren.

Jo, aber ich bin mal so frech und behaupte, dann ist PHP ganz down, wenn das nicht einmal mehr lesen will ;)

Gruesse, Eddie (mit fuenfen)

Was soll ich tun? Meine Mutter hauen ;)

Gruß aus Berlin!
eddi