Formulargenerator - Thema zu spezifisch?

[Christian Seiler]

Hallo Forum,

In </archiv/2002/12/32299/> hatte ich ein Konzept vorgestellt und wollte Meinungen dazu hören, jedoch ist der Thread unbeantwortet im Archiv gelandet.

Daher jetzt meine Frage(n): War das Thema zu spezifisch? Habe ich vielleicht auch nur den falschen Zeitpunkt erwischt? (Samstag abend) Habe ich an der äußeren Form des Postings etwas falsch gemacht? War es zu lang(weilig)? Hat keiner Interesse an so etwas? Ich habe mich nämlich etwas gewundert, dass niemand, aber auch gar niemand geantwortet hat, zumal einige in dem in dem Thread verwiesenem älteren Thread (tolle Grammatik ;)) Interesse an so etwas bekundet hatten.

Grüße,

Christian

[Achim Schrepfer]

Hi,

In </archiv/2002/12/32299/> hatte ich ein Konzept vorgestellt und wollte Meinungen dazu hören, jedoch ist der Thread unbeantwortet im Archiv gelandet.

puh, ganz schöner Happen. Ich würde sagen, das Ding war einfach zu fett! Ich würde sowas nie durchlesen. Vielleicht solltest Du mal eine Zusammenfassung schreiben ;-)

viele Grüße
Achim Schrepfer

PS: read your mail

[Christoph]

Hi Christian,

´habs mir mal durchgelesen, klingt uninteressant jetzt für mich, weil ich mich frage wieso brauchst du einen Formulargenerator?

Danke

Gruß Christoph

[Christian Seiler]

Hallo Christian,

weil ich mich frage wieso brauchst du einen Formulargenerator?

</archiv/2002/10/27058/#m148597> beschreibt die Gründe ganz gut. (Ignoriere bitte meine Antwort, damals war ich noch etwas verblendet. ;))

Grüße,

Christian

[Thomas Schmieder]

Hi Christian,

ich habe Deinen Thread gelesen. Ich finde das Thema auch nach wie vor interessant. Allerdings hast Du gleich beim ersten Mal soviel Stoff geleifert, dass man den erstmal verdauen muss.

Du solltest vielleicht einen etwas leichteren Einstieg geben. Worum geht es überhaupt, welcher Workflow besteht und wie wird der erreicht?

Ich bin selber gerade in das Thema eingestiegen und habe mit den Abbildungsverfahren von HTML-Daten auf MySQL und zurück begonnen. Das ist ja letztlich das, was Du da auch baust.

So ist eine <Select><Option>... (nicht multiple) z.B. auf Datenbankebene identisch mit <input type=radio> und ein <select multiple><option>... identisch mit <input type="checkbox">

Du hast also mehrere Schichten

Anzeige/Eingabe
Post-Post-formatierung
Validierung
Verarbeitung
Pre-Save-Formatierung
Save

und andersherum:

Pre-Select Formatierung
Select-Format
Post-Select Formatierung
Verarbeitung
Pre-Response-Formatierung
Response, Anzeige

Liebe Grüße aus http://www.braunschweig.de

Tom

[Christian Seiler]

Hallo Thomas,

ich habe Deinen Thread gelesen.
Ich finde das Thema auch nach wie vor interessant.

Danke, das hat meinem Selbsbewußtsein geholfen... ;)

Allerdings hast Du gleich beim ersten Mal soviel Stoff geleifert, dass man den erstmal verdauen muss.

Oh. Hoffentlich hast Du keinen Durchfall bekommen...

Ich bin selber gerade in das Thema eingestiegen und habe mit den Abbildungsverfahren von HTML-Daten auf MySQL und zurück begonnen.
Das ist ja letztlich das, was Du da auch baust.

Nicht so ganz... Ich sehe schon, ich habe Kommunikationsschwierigkeiten...

Du solltest vielleicht einen etwas leichteren Einstieg geben. Worum geht es überhaupt, welcher Workflow besteht und wie wird der erreicht?

Ähm, ja, Du hast Recht. Jetzt fasse ich mich mal *extrem* kurz als Einstieg:

Mein Formulargenerator funktioniert wie folgt:

* Auf der PHP-Seite werden verschiedene Klassen instantiert, um die Struktur des Formulars abzubilden.
 * Wenn das PHP-Script aufgerufen wird, aber das Formular noch nicht abgeschickt worden  ist, dann wird das leere Formular angezeigt.
 * Wenn das PHP-Script aufgerufen wird, und das Formular abgeschickt wird, dann passiert folgendes:
     - die Eingabedaten werden gemäß der Formularstruktur validiert
     - wenn das Formular nicht validiert, dann wird es noch einmal angezeigt
     - ansonsten kann das Script entscheiden, was mit den Daten passieren soll (Datenbank, Mail senden, etc.)

Das ist der Standard-Workflow, den ich mir für den Formulargenerator überlegt habe. Der Formulargenerator nimmt dem Script praktisch die ganze Arbeit, die da drinnen steckt, ab. Eine Abweichung vom Standard-Workflow ist aber durchaus möglich, die Aktionen sind möglichst abgekapselt.

Grüße,

Christian

[Thomas Schmieder]

Hallo zurück,

ja, so habe ich das auch verstanden, als ich mir den thread von molily (?) angeschaut habe.

Im Prinzip läuft das dan irgendwann mal darauf hinaus, dass auf der einen Seite das Speichermedium (Datanbank, tabellen, Dateien...) steht und auf der anderen Dein leerer Bildschirm. Du besorgst Dir die Liste der Datenfelder, positionierst das feld mit der Maus auf dem Bildschirm, gibst die Attribute an und die Eigenschaften sowie die Gültigkeitsregeln, sofern diese noch nicht in der DB vermerkt sind und speicherst die Parameter in einer Tabelle ab.

Dann generierst Du beim datenzugriff das HTML-File, das zugehörige CSS-File und das empfangene PHP-Script mittels Generator aus dieser Tabelle.

Datenkopplung kann sooo schön einfach sein, wenn das erstmal funktioniert.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Christian Seiler]

Hallo Thomas,

ja, so habe ich das auch verstanden, als ich mir den thread von molily (?) angeschaut habe.

Nee, der war auch von mir. ;) Mathias hat nur darauf geantwortet.

Im Prinzip läuft das dan irgendwann mal darauf hinaus, dass auf der einen Seite das Speichermedium (Datanbank, tabellen, Dateien...) steht und auf der anderen Dein leerer Bildschirm. Du besorgst Dir die Liste der Datenfelder, positionierst das feld mit der Maus auf dem Bildschirm, gibst die Attribute an und die Eigenschaften sowie die Gültigkeitsregeln, sofern diese noch nicht in der DB vermerkt sind und speicherst die Parameter in einer Tabelle ab.

Jain:

1. So "benutzerfreundlich" wollte ich die Lösung nicht machen.
2. Ich wollte es möglichst abstrakt und flexibel halten und es deswegen eben *nicht* an bestimmte Abläufe binden, sondern diese nur vorschlagen.

Du kannst aber das ganze gerne erweitern, wenn Du Lust hast...

Datenkopplung kann sooo schön einfach sein, wenn das erstmal funktioniert.

Das meiste (fast das ganze Grundsystem) läuft ja schon, wenn Du willst, schicke ich Dir mal den Source, das einzige Problem, das ich noch habe, ist die Lizenz.

Das Problem ist, dass ich noch kein richtiges Konzept für tabellarische Formulare habe, da würde ich gerne mal ein paar Anregungen haben. (Wie gesagt, ich schicke jedem interessierten mal den SourceCode zu, aber ich veröffentliche erst, wenn ich mir mit der Lizenz im klaren bin)

Grüße,

Christian

[Thomas Schmieder]

ReHallo,

1. So "benutzerfreundlich" wollte ich die Lösung nicht machen.
2. Ich wollte es möglichst abstrakt und flexibel halten und es deswegen eben *nicht* an bestimmte Abläufe binden, sondern diese nur vorschlagen.

Du kannst aber das ganze gerne erweitern, wenn Du Lust hast...

Das könnte eines Tages schon passieren...

Das Problem ist, dass ich noch kein richtiges Konzept für tabellarische Formulare habe, da würde ich gerne mal ein paar Anregungen haben.

Ich hatte Dir mal eine Definitionsdatei aus einem Turbo-Pascal-PC-Projekt geschickt. Da stganden schon fast alle Parameter für die Felddefinitionsliste drin. Man muss das bei HTML dann eben aufteilen ind en HTML-Teil und den CSS-Teil. Dann wird richtig elegant.

Feldname
Feldformat
Feldpostition
Feldgröße
Feldfarbe
...

Du erinnserst Dich?

Das Einzige, was bei HTML eben nicht ohne JavaScript funktioniert, ist ein Dirty-Flag. Nur wenn das gesetzt ist, muss das Feld verarbeitet werden. Das spart auf dem Server sehr viel Zeit.

Wenn Felder gegeneinander verkoppelt werden müssen, dann müssen sie alle gegengeprüft wrden. Das bedeutet, dass Du ohne Session-Vwerarbeitung nicht zum Ziel kommst, da Du wissen musst, welche Werte Du an den Client unter der Vorgangsnummer abgeschickt hast. Am Client ist schließlich alles fakeable.

Weihnachtsgrüße aus http://www.braunschweig.de

Tom

[Christian Seiler]

ReHallo,

Hallo Thomas,

Das Problem ist, dass ich noch kein richtiges Konzept für tabellarische Formulare habe, da würde ich gerne mal ein paar Anregungen haben.

Ich hatte Dir mal eine Definitionsdatei aus einem Turbo-Pascal-PC-Projekt geschickt. Da stganden schon fast alle Parameter für die Felddefinitionsliste drin. Man muss das bei HTML dann eben aufteilen ind en HTML-Teil und den CSS-Teil. Dann wird richtig elegant.

Hmmm, mir ging es nicht so sehr um die Benutzerschnittstelle, als um die interne Realisierung. Trotzdem danke.

Du erinnserst Dich?

Dunkel...

Grüße,

Christian

[molily]

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...)

[Christian Seiler]

Hallo Mathias,

Zuerst einmal ist die Klassenaufteilung nachvollziehbar und die Anwendung leuchtet mir sofort ein,

Dann habe ich mein Hauptziel erreicht: ein gutes Konzept. :)

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.
deine momentane Lösung ist *zu* flexibel,

Ich wollte die Lösung halt möglichst flexibel gestalten und halt auch Formulare abdecken, die hardgecodet werden, wie z.B. Loginformulare.

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.

Warum denn? Die Fehlermeldungen werden vom Validator-Objekt automatisch generiert. Du brauchst nichts weiter tun als $form_objekt->validate () aufzurufen und die Validierung geht von statten und die Fehlermeldungen werden automatisch zu den entsprechenden Formularfeldern eingefügt.

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,

Ich kann gerne noch eine Funktion schreiben, die ein Array einliest und dann ein paar Standardklassen verwendet, um das Formular zu konstruieren. Diese Funktion gibt dann das Formular zurück.

»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.

Hmmm. Ich habe eigentlich vier Parameter für die Validatorklasse vorgesehen: das Locale, der Minimumwert/Minimumlänge (je nachdem), der Maximumwert/Maximumlänge und die Übersetzungsfunktion. Einzig die Klasse für generische Zahlen hat noch mehr, aber die könnte ich auch aus dem Konstruktor rausnehmen und direkt die Variablen des Objektes verwenden.

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...?

Ich bisher nur Standardtexteingabefelder und Passworteingabefelder über FormField und FormFieldValidator realisiert. Checkboxen werde ich so realisieren, dass das Formularfeld beim "validieren" einfach nur prüft, ob die POST-Variable gesetzt worden ist und den Wert dann entsprechend auf true oder false setzt. (brauchen keine Validatorklasse, das könnte die Checkbox-Formularfeldklasse selbst übernehmen) Radiobuttons und Auswahllisten werden (in Zukunft) so validiert, dass eine Liste mit möglichen Eingaben übergeben wird, und geprüft wird, ob die Eingabe darunter ist. Datumsauswahllisten/Zeitauswahllisten werde ich ähnlich behandeln, warscheinlich in Kombination mit einem Integer-Validator.

Das würde womöglich ein heilloses Durcheinander an Objekten,

Wieso? Man muss sich nur selbst zwingen, die Objekte möglichst abstrakt zu halten, dass man nicht unnötig viele braucht.

welche im Bezug auf das ineffiziente, einzelne Überprüfen der GET- oder POST-Parameter zwar einen höheren Abstraktionsgrad erlauben, aber keine Codeersparnis bieten.

Warum keine Codeersparnis? Ich denke, dass mein jetztiges Konzept mir doch schon etwas Code erspart, beim Login-Formular vielleicht nicht, aber so ab 4 oder 5 Feldern kann das durchaus eine Ersparnis sein.

Ich habe auch eine Möglichkeit vermisst, sich den Code anzuschauen.

Ich schicke ihn Dir gerne zu, Mail kommt gleich.

Wieso der Code nicht unter der GPL oder LGPL veröffentlicht werden kann, ist mir unverständlich.
[Lizenzen & Co]

Full ACK im Prinzip, aber CZ hat mich im anderen Thread davor gewarnt, und daher beruhen meine Überlegungen, ich bin leiber einmal zu vorsichtig, als dass meinem armen Code was passiert...

Grüße,

Christian

[Simon Reinhardt]

Hi!

Ich muss zugeben, ich hab mir nicht alles durchgelesen, aber ich hab mir den Thread zumindest gebookmarked, da ich das Thema schon interessant finde. Denn - das könnte mir beim Design einer meiner Ideen weiterhelfen.
Hast Du schon mal daran gedacht, mit Deinen Formularen auch hierarchische Strukturen abzubilden? Bei Datenbanktabellen ist es noch relativ einfach: man nimmt die Spaltenköpfe als Formularfelder. Wenn aber die Formulardaten in einer XML-Datei abgespeichert werden sollen, müssen auch die Formularfelder entsprechende Namen haben, um hier den Überblick zu behalten (zum Beispiel "root:childelem:attribute").
Wofür ich das brauche? Ich hatte irgendwann mal angefangen, mir ein CMS auf XML-Basis auszudenken und nach ziemlich langer Hin- und Herbastelei bin ich auf eine erstaunlich einfache Struktur gekommen.
In groben Zügen: der Inhalt einer Webseite wird einer XML-Datei gespeichert (Web Content File nenne ich das :) und daraus wird dann per XSLT oder PHP oder sonstwas die HTML-Seite generiert. So weit ist das nichts Neues, aber mich haben halt die bisherigen viel zu speziellen XML-Lösungen gestört. So sieht man zum Beispiel immer wieder sowas hier:
<page>
  <headline>...</headline>
  <teaser>...</teaser>
  <body>...</body>
</page>
Mein Ansatz geht einen ziemlich allgemeinen und abstrakten Weg: die Datenfeldnamen bestimmen nicht die Tagnamen, sondern nur deren ID.
Eine Inhaltsseite sieht dann zum Beispiel so aus:
<page>
  <text id="headline">...</text>
  <text id="teaser">...</text>
  <text id="body">...</text>
  <set id="linkszumthema">
    <set id="link1">
      <text id="url">http://...</text>
      <text id="label">...</text>
    </set>
    ...
  </set>
</page>
Die beiden Tags "text" und "set" reichen vollkommen aus, um Inhalt und Struktur der Daten zu speichern. Das Template übernimmt dann die Aufgabe, dem einen Sinn und eine Form zu geben (also zum Beispiel: das Set "linkszumthema" ist eine Liste und das Set "link1" ist ein Eintrag in dieser Liste, welcher die zu diesem Eintrag gehörenden Daten zusammenfasst - in früheren Versionen hatte ich hier noch eine Trennung, die Tags hießen dann "list" und "entry").
Anhand der ID eines Elements kann der Formularname leicht zusammengebastelt werden (z.B. "linkszumthema:link1:label"). Da aber ID kein required-Attribut ist (im Beispiel wäre die Bezeichnung link1,link2,...,linkn ziemlich überflüssig), können Elemente auch über ihre Nummer, sprich ihre Position in einer Liste angesprochen werden ("linkszumthema:[1]:label" oder so). Letztendlich ist die Zugriffssyntax ein sehr, sehr stark vereinfachtes XPath.

Hm, ich hab wohl ein wenig weit ausgeschweift und wahrscheinlich ist das für Dich alles uninteressant, aber vielleicht solltest Du hierarchische Datenstrukturen bei Deinem Formulargenerator nicht ganz außer Acht lassen.

VG Simon

[Christian Seiler]

Hallo Simon,

[Interessanter Ansatz für ein XML-CMS, den ich mir später mal genauer zu Gemüte führen werde]

Hm, ich hab wohl ein wenig weit ausgeschweift und wahrscheinlich ist das für Dich alles uninteressant,

Warum uninteressant? Ich bin prinzipiell an allem interessiert, und immer wenn ich selbst das Wort "uninteressant" verwenden sollte, dann heißt das nur, das ich das jetzt im Moment nicht interessant finde.

aber vielleicht solltest Du hierarchische Datenstrukturen bei Deinem Formulargenerator nicht ganz außer Acht lassen.

Inwiefern beziehst Du Dich jetzt auf hierarchische Datenstrukturen? Ich habe schon an Hierarchien gedacht, man kann Prima

Formular
  |- Fieldset
  |    |- Field
  |    - Field   |- Field   |- Fieldset   |    |- Fieldset   |    |    |- Field   |    |    - Field
  |    |- Field
  |    - Fieldset   |         |- Field   |         |- Field   |         - Field
  |- Field
  `- Field

in meinem Konzept abbilden. Oder meinst Du jetzt etwas anderes?

Grüße,

Christian

[Simon Reinhardt]

Hi!

Inwiefern beziehst Du Dich jetzt auf hierarchische Datenstrukturen? Ich habe schon an Hierarchien gedacht, man kann Prima

...

in meinem Konzept abbilden. Oder meinst Du jetzt etwas anderes?

Nö, datt isset! ;-)
Ich sag ja, so genau hab ich mir Deinen Code nicht angeguckt.
Wie stellst Du denn dann solche Formulare dar? Ich meine: sowas muss ja für den Benutzer auch klar und einfach eingebbar sein.

VG Simon

[Christian Seiler]

Hallo Simon,

Wie stellst Du denn dann solche Formulare dar? Ich meine: sowas muss ja für den Benutzer auch klar und einfach eingebbar sein.

Ich poste noch mal einen Ausschnitt aus meinem Beispielcode, vielleicht wird das ganze dadurch klarer.

$login_form =& new Form ("loginform", "Login", $npo);

$login_fieldset =& new FormFieldSet ($login_form, "Login", $npo);
$u_fieldset =& new FormFieldSet ($login_form, "Username", $login_fieldset);
$p_fieldset =& new FormFieldSet ($login_form, "Password", $login_fieldset);

$login_field =& new FormField (&$login_form, "username", "Username", $username_validator, $u_fieldset, 20, 32);
$password_field =& new FormField (&$login_form, "password", "Password", $password_validator, $p_fieldset, 15, 32);

Das Beispiel ist jetzt natürlich etwas doof, aber es würde so eine Struktur entstehen:

Formular
   - Fieldset: Login         |- Fieldset: Benutzername         |    Feld: Benutzername
        - Fieldset: Passwort              Feld: Passwort

Grüße,

Chrsitian