molily: Formulargenerator - Thema zu spezifisch?

Beitrag lesen

Hallo, Christian,

hm, ja, ich habe damals (urgs, es ist ein paar Tage her) natürlich den Thread aufmerksam gelesen, wusste aber nicht recht, woran ich anschließen sollte, wollte womöglich eine lange Antwort verfassen und mir dafür Zeit nehmen, aber da war Thread schon im Archiv und aus meinem Sinn.

Zuerst einmal ist die Klassenaufteilung nachvollziehbar und die Anwendung leuchtet mir sofort ein, aber, wie ich auch in meinem Posting im ersten Thread sagte, habe ich persönlich andere Ansprüche. Die von mir gewählte Lösung (ein verschachtelter Array) benötigt kein explizites Erzeugen von mehreren Objekten mit von Hand getipptem PHP-Code (wobei nichts dagegen spricht, dass die Arrayelemente Objekte sind), das mag kein großer Unterschied sein, da die Objekteigenschaften oder Unterarrayelemente sowieso irgendwo notiert sein müssen, der Punkt, auf welchen ich hinausmöchte, ist, dass ich, wie ich bereits einführte, stark dazu neige, die Formulardaten insgesamt in einer externen Datenstruktur unterzubringen als dass ich sie im PHP-Code von Hand als (Unter-)Objekte deklariere, welche aufeinander Bezug nehmen und einen Baum bilden (Form -> FormFieldSet -> FormField -> FormFieldValidator IIRC), wodurch im PHP-Code dutzende (bei einem umfangreichen Formular schätzungsweise 20-25) Variablen (Objekte) von Hand deklariert werden müssen.

Da ich mittlerweile die damals angesprochene Seite mehrmals überarbeitet habe (Seite ist momentan down, das verlinkte Script also nicht verfügbar), habe ich die Entscheidung getroffen, dass ich die Daten definitiv in einer XML-Datei ablegen werde, welche das einzig Variable am kompletten Mechanismus sein wird. Das, was mit deinen Klassen momentan über den PHP-Code gelöst wird, würde ich in einer anderen Datenstruktur vorab speichern. Mit dem Aufrufen des Formularhandlers würde der Rest automatisch ablaufen - es müsste nur angegeben werden, welche Datenquelle zur Validierung genutzt werden soll ($_GET, $_POST, $irgendein_array) und der Name der zugehörigen XML-Datei (und vielleicht einige andere Parameter, sofern sie überhaupt in den Code müssen). Natürlich sollte das System nicht an Flexibilität verlieren, aber deine momentane Lösung ist *zu* flexibel, sie wird bei komplexen Formularen nicht viel Zeit- und Codeersparnis bieten, denn die komplette Fehlerbehandlung muss mehr oder weniger in PHP per Hand realisiert werden. Das, was du als Testformular (Anwendungsbeispiel) vorgestellt hast, sollte meiner Meinung nach die Klasse leisten, nämlich das Erzeugen von Objekten aus einer externen Datenstruktur (XML->Array oder direkt Array) und das Behandeln des Formulars, hier ein Auszug:

if ($login_form->wasProcessed ()) {
   // validate it
   /* ... */
} else {
   $login_form->display ();
}

In dem Script, welches die Klassen anwendet, hat diese Grundkonstruktion meiner Meinung nach nichts zu suchen, ich würde sie in in einer Methode unterbringen, welche dann womöglich wie oben beschrieben neben den Includes der Klassen fast schon das Einzige wäre, was im Anwendungsscript nötig wäre.

Klammer auf. Das Hauptprogramm meines Scripts sieht beispielsweise folgendermaßen aus:

if (ueberpruefe_formulardaten()) {
 daten_eintragen();
 bestaetigungen_senden();
 erfolgsmeldung();
} else {
 fehlermeldung();
 formularausgabe();
}

Da alles ließe sich natürlich auch zusammenfassen. Ich wollten nur zeigen, dass dieses stereotypische Schema vereinfacht werden sollte. Klammer zu.

Deine Lösung erlaubt eine hohe Abstraktion und Organisation, aber ich erkenne, ausgehend von den mir bekannten Problemen, keinen Fall, in welchem dies (mir persönlich) eine Erleichterung bieten könnte.

Das für mich Unverständlichste ist, wie du dieses System in Richtung anderer Formularfeldtypen und damit Validierungsmöglichkeiten vervollständigen willst, ohne dass es komplett undurchsichtig wird. »Von dieser Klasse leiten sich alle weiteren Validierungsklassen ab, da werde ich noch ein paar schreiben« - ähm, es ist jetzt schon unübersichtlich, sich die Syntax des Konstruktors der vorhandenen Klasse zu merken. Wie willst du die Daten organisieren, wenn du multiple Auswahlboxen, Checkboxen handhaben musst und die Eingabe mittels verschiedener RegExps von verschiedenen Datentypen (was du ursprünglich vorhattest) validiert werden muss...? Das würde womöglich ein heilloses Durcheinander an Objekten, welche im Bezug auf das ineffiziente, einzelne Überprüfen der GET- oder POST-Parameter zwar einen höheren Abstraktionsgrad erlauben, aber keine Codeersparnis bieten.

Naja, soweit sind es nur Mutmaßungen, solange ich mit dem Code nicht arbeiten kann... Ich habe auch eine Möglichkeit vermisst, sich den Code anzuschauen.
Wieso der Code nicht unter der GPL oder LGPL veröffentlicht werden kann, ist mir unverständlich.
Es kann doch nicht stimmen, dass ein Programm mit PHP per se nicht frei sein kann, weil der komplette Quellcode von PHP unfrei ist und damit das Programm nicht auf unfreier Software basieren kann... Es gibt dutzende PHP-Projekte, welche eindeutig PHP4-Features und -Module nutzen und dennoch unter der GPL stehen. Deinen Erklärungen nach wäre es generell unmöglich, mit der Sprache PHP Freie Software zu schreiben, weil jedes noch so kleines Sprachkonstrukt aus einem PHP-Modul oder sogar der grundlegende Satz an Konstrukten und Funktionen unter einer unfreien Lizenz steht. Danach wäre es ein Lizenzbruch, ein »Hallo Welt«-Programm in PHP unter der GPL zu veröffentlichen...?! *fg* Äußerst absurd.
Ich kenne mich nicht aus, vor allem weiß ich nicht, wie es mit anderen Sprachen aussieht, schließlich beinhalten die die Compiler und Interpreter dutzende Basiskonstrukte, welche man auch nicht verwenden dürfte, wenn man damit Freie Software schreibt... Selbst mit Visual C++ etc. wird freie Software geschrieben, diese Libraries sowie die Standardfunktionen sind meines Wissens auch frei benutzbar, obwohl deren Quellcode closed-source ist und deren Verbreitung und Benutzung womöglich vom Compiler- und Modulautor auf zahlende Benutzer limitiert ist (zwangsläufig). Ich dachte eher, dass sich die PHP-Lizenz auf die direkte Nutzung des Quellcodes und nicht auf die Nutzung des Interpreters sowie deren kompilierte Bestandteile bezieht... Wie auch immer, wie gesagt, ich kenne mich nicht aus.

Grüße,
Mathias
(Vielleicht schreibe ich später mehr, jetzt erst einmal nur das...)