Puh! Ich sah meine geistige Gesundheit sich bereits verabschieden. Aber jetzt habe ich den Fehler gefunden. Ich kam nur darauf, weil Firefox Schlüsselwörter im Seitenquelltext fett darstellt. Das hatte ich bisher für das Debugging total unterschätzt. Die Fähigkeit zu „Reparaturen“ auch. Im FORM-tag fehlte ein schließendes ". Anders als bei Klammern läßt sich das leider nicht sofort durch Syntax-Highlighting eines Editors erkennen. Sowohl Firefox als auch Konquerer in wiederum sowohl seinem Webkit-Modus als auch seinem KHTML-Modus gaben keinen Fehler aus, sondern „reparierten“ das HTML selbst. Und zwar so, daß möglichst viele Tags noch korrekt dargestellt wurden. Dafür wurde ein INPUT-tag geopfert. Mit einem verstecktem Eingabefeld war sogar egal, wo sich das befand. Nach dem Motto: „wer braucht schon ein verstecktes Feld“. Erst als ich das entfernt hatte, vergriff sich der Brauser am Feld für die Texteingabe. Inzwischen hatte ich so ziemlich jedes kleine Teilchen im Code herausgenommen und wieder hineingesetzt, ohne eine Änderung. Vielleicht sollte ich Hilfsmittel fürs Debugging suchen....
Ranma
Ich habe mir überlegt, daß Formulare eine Art Unterprogramm sein sollten. Wenn ich nur noch ein Formular habe, dann muß ich nur noch einmal darin alle Fehler finden und nur noch einmal alle Sicherungsmaßnahmen einbauen. Also brauche ich ein riesiges Formular, in das sämtliche Möglichkeiten für die Dateneingabe eingebaut werden, egal welcher Teil meines Skriptes diese wann brauchen wird. Beim Aufrufen des Formulares müssen dann immer die Teile herausgenommen werden, die gerade nicht gebraucht werden.
Aber welche Vorgehensweise ist empfehlenswert? Ich könnte die jeweils gerade nicht gebrauchten Felder verstecken. Dann können sie zugleich noch als Fallen für Spämbots dienen. Das könnte sich allerdings zu einem SEO-Problem auswachsen. Suchmaschinen mögen keine versteckten Sachen, weil menschliche Benutzer darauf anders reagieren als Bots. Das ist allerdings auch gerade der Sinn der Sache, wenn man Spämbots abwehrt. Vielleicht sollte ich die einzelnen Teile (INPUT-Felder und SELECT-Felder) in einer Datenbanktabelle ablegen? Da kann durch den Wert in einer weiteren Spalte festgelegt werden, wofür welche Teile geholt und in das Formular eingebaut werden. Klingt als wäre das langsam. Aber dafür leicht erweiterbar und die Tabelle sollte zu den kürzeren gehören. Für Beschriftungen ließen sich vielleicht noch Fremdschlüssel aus den Wörterbuchtabellen einsetzen, so daß das Skript leicht zu lokalisieren wäre. Vielleicht übersehe ich noch bessere Möglichkeiten.
Ursprünglich dachte ich mal, das HTML kommt am besten in eine extra Datei, damit es nicht mit PHP durcheinandergeht. Aber das Formular muß die Daten an eine PHP-Datei schicken und das geht am einfachsten, wenn sich das Formular an die Datei verschickt, in der es hineingeschrieben ist. Das ist außerdem die einzige Möglichkeit, die nicht allergisch auf Veränderungen von Pfad und Namen des Skriptes reagiert. Und die ändere ich ständig. Weil ich ständig am Fehler entfernen bin und jede Version mit Kommentaren dazu und auskommentierten Teilen vollstopfe....
Ranma
Ich habe mir überlegt, daß Formulare eine Art Unterprogramm sein sollten. Wenn ich nur noch ein Formular habe, dann muß ich nur noch einmal darin alle Fehler finden und nur noch einmal alle Sicherungsmaßnahmen einbauen. Also brauche ich ein riesiges Formular, in das sämtliche Möglichkeiten für die Dateneingabe eingebaut werden, egal welcher Teil meines Skriptes diese wann brauchen wird. Beim Aufrufen des Formulares müssen dann immer die Teile herausgenommen werden, die gerade nicht gebraucht werden.
Aber welche Vorgehensweise ist empfehlenswert?
Die Verwendung einer Formular-Klasse. Mit einer entsprechend definierten Methode kann man dann z.B. einzelne Formularfelder, die für das jeweilige Formular benötigt werden, diesem hinzufügen. (Versteckte) Felder, die immer benötigt werden, könnten dagegen automatisch hinzugefügt werden. Über die Suchbegriffe "php form class" lassen sich Klassen finden, die man als Vorlage verwenden kann (oder direkt einbinden lassen, wenn man das Rad nicht neu erfinden möchte)
Ein Formular ist schon dafür geeignet, ein Objekt daraus zu machen. Aber die umständliche Art wie man das in PHP umsetzt mit der vielen zusätzlichen Schreibarbeit zeigt mir, daß PHP nicht so für OOP geschaffen ist.
Ranma