Form-Objekt mit Form-Elementen aus Daten-Objekt anreichen - Seite 2

nikosch · 19.07.2010, 08:24

Naja, ob bspw. die Factory ein Objekt dekoriert sollte man schon klären.

dr.e. · 19.07.2010, 10:37

Zitat:

Zitat von xm22

Es spricht ja nichts gegen eine Vermischung. Bei Bedarf nutzt man dann entweder einen Decorator zur Ausgabe oder schreibt eben plain html..

Plain HTML ist Blödsinn, da verzichtest du auf wichtige Features und programmierst diese mit Unmengen Template-Logik nach. Das hat weder etwas mit OO zu tun, noch ist das in nicht-Hobby-Projekten rentabel.

xm22 · 19.07.2010, 14:58

Zitat:

Plain HTML ist Blödsinn

Was ist daran bitte Blödsinn?! Hast Du schon mal ein Formular gehabt, dass auf diverse JS-Effekte wie Ajax-Hints und ähnliches zurück gegriffen hat? Oder auf eine spezielle Art und Weise gestaltet werden sollte?
Das, was das APF hier anbietet: Kontaktformular-Tutorial :: Adventure PHP Framework (APF)
Ist doch im Prinzip nichts weiter als die Validierung und Ausgabe des Formulars in einem Stück Code.. Da könnte man auch das Formular als eigenes Objekt mit allen Validierungen und was dazu gehört, instanziieren und die HTML-Ausgabe per Hand schreiben. Bei der Ausgabe gäbe es kaum einen Unterschied zu Deiner Lösung, außer, dass Du alles in spezielle Tags verpackst, die noch etwas Arbeit abnehmen..

Lenki · 30.07.2010, 20:21

Hallo zusammen,

es ist schon ein wenig her...

Ich muss gestehen, ich hatte die letzten Diskussionen nicht ganz folgen können, hatte dann aber einen, meiner Meinung nach, grandiosen Einfall, den ich dann unbedingt mal umsetzen wollte. Den möchte ich hier mal kurz skizzieren:

PHP-Code:

  $form = Form::getInstance('id');

if(!$form->hasElements()) { // Form wurde neu erzeugt, nicht aus Session

  $do = new PersonDataObject(3); // Holt das Personen-Objekt mit ID 3 mit Vor- und Nachname aus der Datenbank

  $provider = new DataObjectFormElementProvider($do); // Klasse, die Form Elemente aus dem Daten-Objekt bereitstellt

  $form->registerElementsFromProvider($provider);

}

if($form->submitted()) {

  if(!$form->valid()) {

    $errors = $form->getErrors();

    // Errors weiterverarbeiten

  } else {

    new SaveDataObjectFormDecorator($form)->save();

    // ok, der Teil ist noch wirklich nicht gut modeliert, ich weiß

  }

}

Die Form-Instanz würde an den View übergeben werden. Dort würden die Form Elemente mit einem HTML Form Element Decorator bestückt, der daraus ein HTML Element erzeugen kann.
Funktioniert soweit wunderbar (auch wenn der letzte Teil mit dem Speichern noch nicht schön ist...)

Da war ich echt begeistert und hab mir gedacht: Jetzt bearbeite mal zwei Personen-Datensätze in einem Formular. Und da war es dann: PENG!!!

Ich hätte dann zwei Form-Elemente mit dem HTML-Name-Attribute <form_prefix>_vorname und <form_prefix>_nachname. Doof gelaufen.

Und ich glaube, das ist genau das, wovor ihr gewarnt habt, oder?
Jetzt bin ich hier am Grübeln.
Mein aktueller Ansatz ist in etwa folgender: Ich bilde meine Form-Elemente in einer Art Baum ab. Jedes Form-Objekt hat von sich aus einen Root-Knoten. An diesem Knoten und potentiellen Kindknoten können Form-Elemente registriert werden. Knoten werden einfach über einen String wie ROOT/CHILD01/SUBCHILD02 angesprochen. Aber irgendwie ist das gnaze noch nicht so durchdacht. Ich habe einerseits den Ansatz versucht, wie ich das ganze in meinen Templates aufrufen wollen möchte. Hier hatte ich überlegt ein Pseudo-HTML Element einzufügen a la <node>, dass innerhalb eines <form>-Elements die darin angeforderten Elemente auf den angegebenen Knoten bezieht. Aber so wirklich habe ich auch noch nicht raus, wie ich zum Beispiel diese zwei Personen-Objekte dann angehe. Eigentlich wäre in diesem Ansatz jedes registrierte Daten-Objekt ein Knoten.
Es gäbe dann also eine Art Baum a la:

Code:

Root
+ PersonData
  + 3
    - Nachname
    - Vorname
  + 5
    - Nachname
    - Vorname
+ sind Knoten
- sind Attribute es Knoten

Hmm, aber so müsste ich sicherstellen, dass der Knoten PersonData nur die Unterknoten hat, die ein PersonDataObject abbilden. Hier wäre doch dann wieder das Problem, dass die Form-Elemente nicht wissen, dass sie an ein Daten-Objekt gebunden sind.

Hm, also das ganze muss auf jeden Fall noch reifen.
Würde mich freuen, wenn ihr Eure Meinung dazu gebt.
Dankeschön.

dr.e. · 30.07.2010, 21:26

Hallo Lenki,

die Diskussion ging vor deinem Post genu um das Thema Abstraktion und Abbildung von komplexeren Strukturen. Richtig ungemütlich wird es bei Multi-Selekt-Felder mit Gruppen. Hier muss der Provider eine Hierarchie von Daten verwalten und der Decorator auch speichern können. Letzterer ist eigentlich kein Decorator, denn ein solcher ist zur Präsentation eines Objekts gedacht, nicht zur Persistenz.

Auch die Verarbeitung von Validierungs-Fehlern und Filter-Mechanismen von Formular-Elementen zusammen mit einer generischen Datenquelle ist nicht besonders handlich zu implementieren. Ich verfechte deshalb den Ansatz des APF, dass ein Formular nichts anderes als ein Template bestehend aus Funktions-sensiblen Tags ist, die für dich Filterung, Presetting, Validierung etc. übernehmen und ebenfalls als Datenquelle und -Senke fungieren können. Die letzten beiden Aspekte sind im MVC-Pattern IMHO jedoch Aufgabe eines Controllers, der eine Formular-Repräsentation in ein Domänen-Objekt oder Model transfomiert und zur Persistenz bzw. weiteren Verarbeitung freigibt.

Weiterer Vorteil des Ansatzes des APF ist, dass die Formatierung nicht umständlich und sogar krankhaft mit Dekoratoren o.ä. implementiert werden muss, sondern es reicht, ein Formular-Feld in einem Formular zu platzieren und per CSS zu formatieren. Bei komplexeren Formularen kann dieses auch ganz einfach dynamisch erzeugt werden, sprich es ist mit demselben Konzept möglich, Formulare zur Laufzeit im Controller zu generieren und zu verarbeiten. Alle diese Funktionen hat das APF-Form-Tag schon an Board.

Ich leg dir deshalb ans Herz, dir die Umsetzung der Formular-Integration unter Formulare (ab Version 1.11) :: Adventure PHP Framework (APF) einmal durchzulesen und das für deinen Anwendungsfall durchzuspielen. Ich bin sicher, das ist deutlich einfacher zu handhaben und viel einfacher zu skalieren als der von dir gedachte Ansatz.

nikosch · 30.07.2010, 23:22

Was mich beim APF immer etwas gestört hat, war die Umsetzung der Validatoren. Ich sehe, das wurde umgestellt:

Zitat:

Code:

<form:listener control="email">  
  <div class="error-container">  
</form:listener>  
<form:listener control="email" validator="TextLengthValidator">  Please fill in the email field! </form:listener>  
<form:listener control="email" validator="EMailValidator">  Please fill in the email field with a correct email address! </form:listener>  
<form:listener control="email">  
  </div>  
</form:listener>  
<form:text name="email" />  
  <form:addvalidator  class="TextLengthValidator"  control="name"  button="send"  type="special"  />  
  <form:addvalidator  class="EMailValidator"  control="email"  button="send"  type="special"  />  
  <form:addvalidator  class="EMailValidator"  control="email"  button="send"  />  
<form:button name="send" value="Send" />

Ich versteh nur nicht, wie die an die Felder gebunden sind. Einzig durch die Position im Dokumentbaum oder wie? Oder nur durch die Bedingten „Anzeigen“ oben?

dr.e. · 31.07.2010, 14:33

Hallo nikosch,

in der Version 1.11 wurde das Konzept der Validatoren und Filter auf das Observer-Pattern umgestellt. D.h. du registrierst per Tag einen Listener (Validator oder Filter) auf ein Form-Control. Mit weiteren Tags kannst du die Validierungs-Meldungen ausgeben lassen, die seit dem 1.12 (aktuell RC1) auch spezielle Listener (also die Unterscheidung, ob ein Feld gefüllt ist und ob es eine valide E-Mail enthält).

Das binding funktioniert über die Referenz auf das DOM-Element (Name des Elements). In deinem Beispiel ist das das Feld email. Hast du also ein Form-Element mit dem Namen "email", so kannst du in einem Filter (<form:addfilter />) oder einem Validator (<form:addvalidator />) das Control mit dem control-Attribut ansprechen. Intern wird beim observe-Event (also dem Einhängen des Validators/Filters) das DOM-Element mit dem angegebenen Namen gesucht, der Validator/Filter erzeugt und an das Objekt gehangen.

Der Trigger ist der angegebene Button, der ebenfalls im DOM-Baum über den Namen des Buttons referenziert wird (button-Attribut). Ein Validator/Filter wird also nur ausgeführt, wenn der Trigger ausgelöst ist. Hierzu hat jeder Filter/Validator eine isActive()-Methode, die nur dann true zurückgibt, wenn das auslösende Ereignis auch stattgefunden hat. In der Standard-Implementierung ist das Ereignis der Button-Klick, möchtest du als Entwickler ein eigenes nutzen, kannst du das gerne in einem eigenen Validator/Filter durch Überschreiben der Methode so tun.

Das Konstrukt

Code:

<form:listener control="email">  
  <div class="error-container">  
</form:listener>

könnte man noch dahingehend vereinfachen, dass bei jeglichen Fehlern im Formular immer der Inhalt des Tags <form:error /> angzeigt wird. Möchte man also oben eine ensprechende Box anzeigen geht das auch so:

Code:

<form:error>  
   <div class="error-container">  
 </form:error>
<form:listener control="email">...</form:listener>
...
<form:error>
    </div>  
  </form:error>

Vorteil des Vorgehens ist - wie oben schon beschrieben -, dass du das Formular komplett per HTML und CSS ohne Einschränkung formatieren kannst. Man braucht keine Decorator/Provider/... um den Aufbau künstlich in den OO-Rahmen zu zwängen, sondern du schreibst ein Formular einfach wie ein Template, das jedoch alle Funktionen bereits kapselt. Im Document-Controller hast du dann mit

PHP-Code:

  $form = &$this->__getForm('registration');

vollen Zugriff auf die Objekt-Struktur, die aus den Tags aufgebaut und selbständig initialisiert wird. Liest du z.B. ein Feld aus, auf dem ein Filter registriert ist, wirst du immer schon den gefilterten Wert bekommen. Gleiches gilt für die Prüfung eines Formulars. Hierzu reicht ein einfaches

PHP-Code:

  if($form->isValid()){
   echo 'hurra!';
} else {
   echo 'das war wohl nix! :(';
}

Sofern du ein Formular vorbefülltn möchtest, kannst du das ebenso über den Zugriff auf die einzelnen DOM-Nodes. Hierzu bringt das Formular Methoden wie getFormElementByName() oder getFormElementById() mit. Von diesen erhälst du dann wieder ein Objekt und kannst dieses z.B. nach seinem (gefilteren) Inhalt fragen.

Beantwortet das deine Frage?

Lenki · 26.08.2010, 23:44

Hallo zusammen,

auch wenn das Thema jetzt schon ein bisschen älter ist, so beschäftigt es mich immernoch.

Zur Zeit habe ich alles nochmal über den Haufen geschmissen und gehe das ganze nochmal neu an. Dabei versuche ich das ganze mal unter test-first zu implementieren in der Hoffnung, dass das ein bisschen zu einer ordentlichen Struktur beiträgt (ist in der Hinsicht ein bisschen ein Experiment). Hier verfolge ich aber weiterhin den Ansatz mit den Knoten, den ich in meinem letzten Post beschrieben hatte, und bin bisher noch recht zuversichtlich, dass das klappen wird.

Klares Ziel ist natürlich, auch sauber so Sachen wir Radio-Button-Groups abzubilden und an Datenquellen zu binden, trotzdem aber noch "simple" Formulare auf möglichst einfache Weise bereitzustellen.

Ich halte euch auf dem Laufenden, vielleicht zeichne ich die Tage mal ein Klassendiagramm.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
POST form self PHP und direkt form Daten in URL übergeben	Rutor	PHP Tipps 2010	0	20.02.2010 17:56
Daten in HTML form aus einer Query anzeigen		PHP Tipps 2005	1	15.02.2005 21:03
Übergabe der Daten aus einer Form und übernahme in MySql		PHP Tipps 2004	5	16.07.2004 20:14

19.07.2010, 08:24
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.256 PHP-Kenntnisse: Fortgeschritten	Naja, ob bspw. die Factory ein Objekt dekoriert sollte man schon klären. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

30.07.2010, 20:21
Lenki Benutzer Registriert seit: 14.01.2010 Beiträge: 69 PHP-Kenntnisse: Fortgeschritten	Hallo zusammen, es ist schon ein wenig her... Ich muss gestehen, ich hatte die letzten Diskussionen nicht ganz folgen können, hatte dann aber einen, meiner Meinung nach, grandiosen Einfall, den ich dann unbedingt mal umsetzen wollte. Den möchte ich hier mal kurz skizzieren: PHP-Code: $form = Form::getInstance('id'); if(!$form->hasElements()) { // Form wurde neu erzeugt, nicht aus Session $do = new PersonDataObject(3); // Holt das Personen-Objekt mit ID 3 mit Vor- und Nachname aus der Datenbank $provider = new DataObjectFormElementProvider($do); // Klasse, die Form Elemente aus dem Daten-Objekt bereitstellt $form->registerElementsFromProvider($provider); } if($form->submitted()) { if(!$form->valid()) { $errors = $form->getErrors(); // Errors weiterverarbeiten } else { new SaveDataObjectFormDecorator($form)->save(); // ok, der Teil ist noch wirklich nicht gut modeliert, ich weiß } } Die Form-Instanz würde an den View übergeben werden. Dort würden die Form Elemente mit einem HTML Form Element Decorator bestückt, der daraus ein HTML Element erzeugen kann. Funktioniert soweit wunderbar (auch wenn der letzte Teil mit dem Speichern noch nicht schön ist...) Da war ich echt begeistert und hab mir gedacht: Jetzt bearbeite mal zwei Personen-Datensätze in einem Formular. Und da war es dann: PENG!!! Ich hätte dann zwei Form-Elemente mit dem HTML-Name-Attribute <form_prefix>_vorname und <form_prefix>_nachname. Doof gelaufen. Und ich glaube, das ist genau das, wovor ihr gewarnt habt, oder? Jetzt bin ich hier am Grübeln. Mein aktueller Ansatz ist in etwa folgender: Ich bilde meine Form-Elemente in einer Art Baum ab. Jedes Form-Objekt hat von sich aus einen Root-Knoten. An diesem Knoten und potentiellen Kindknoten können Form-Elemente registriert werden. Knoten werden einfach über einen String wie ROOT/CHILD01/SUBCHILD02 angesprochen. Aber irgendwie ist das gnaze noch nicht so durchdacht. Ich habe einerseits den Ansatz versucht, wie ich das ganze in meinen Templates aufrufen wollen möchte. Hier hatte ich überlegt ein Pseudo-HTML Element einzufügen a la <node>, dass innerhalb eines <form>-Elements die darin angeforderten Elemente auf den angegebenen Knoten bezieht. Aber so wirklich habe ich auch noch nicht raus, wie ich zum Beispiel diese zwei Personen-Objekte dann angehe. Eigentlich wäre in diesem Ansatz jedes registrierte Daten-Objekt ein Knoten. Es gäbe dann also eine Art Baum a la: Code: Root + PersonData + 3 - Nachname - Vorname + 5 - Nachname - Vorname + sind Knoten - sind Attribute es Knoten Hmm, aber so müsste ich sicherstellen, dass der Knoten PersonData nur die Unterknoten hat, die ein PersonDataObject abbilden. Hier wäre doch dann wieder das Problem, dass die Form-Elemente nicht wissen, dass sie an ein Daten-Objekt gebunden sind. Hm, also das ganze muss auf jeden Fall noch reifen. Würde mich freuen, wenn ihr Eure Meinung dazu gebt. Dankeschön.

30.07.2010, 21:26
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.633 PHP-Kenntnisse: Fortgeschritten	Hallo Lenki, die Diskussion ging vor deinem Post genu um das Thema Abstraktion und Abbildung von komplexeren Strukturen. Richtig ungemütlich wird es bei Multi-Selekt-Felder mit Gruppen. Hier muss der Provider eine Hierarchie von Daten verwalten und der Decorator auch speichern können. Letzterer ist eigentlich kein Decorator, denn ein solcher ist zur Präsentation eines Objekts gedacht, nicht zur Persistenz. Auch die Verarbeitung von Validierungs-Fehlern und Filter-Mechanismen von Formular-Elementen zusammen mit einer generischen Datenquelle ist nicht besonders handlich zu implementieren. Ich verfechte deshalb den Ansatz des APF, dass ein Formular nichts anderes als ein Template bestehend aus Funktions-sensiblen Tags ist, die für dich Filterung, Presetting, Validierung etc. übernehmen und ebenfalls als Datenquelle und -Senke fungieren können. Die letzten beiden Aspekte sind im MVC-Pattern IMHO jedoch Aufgabe eines Controllers, der eine Formular-Repräsentation in ein Domänen-Objekt oder Model transfomiert und zur Persistenz bzw. weiteren Verarbeitung freigibt. Weiterer Vorteil des Ansatzes des APF ist, dass die Formatierung nicht umständlich und sogar krankhaft mit Dekoratoren o.ä. implementiert werden muss, sondern es reicht, ein Formular-Feld in einem Formular zu platzieren und per CSS zu formatieren. Bei komplexeren Formularen kann dieses auch ganz einfach dynamisch erzeugt werden, sprich es ist mit demselben Konzept möglich, Formulare zur Laufzeit im Controller zu generieren und zu verarbeiten. Alle diese Funktionen hat das APF-Form-Tag schon an Board. Ich leg dir deshalb ans Herz, dir die Umsetzung der Formular-Integration unter Formulare (ab Version 1.11) :: Adventure PHP Framework (APF) einmal durchzulesen und das für deinen Anwendungsfall durchzuspielen. Ich bin sicher, das ist deutlich einfacher zu handhaben und viel einfacher zu skalieren als der von dir gedachte Ansatz. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

31.07.2010, 14:33
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.633 PHP-Kenntnisse: Fortgeschritten	Hallo nikosch, in der Version 1.11 wurde das Konzept der Validatoren und Filter auf das Observer-Pattern umgestellt. D.h. du registrierst per Tag einen Listener (Validator oder Filter) auf ein Form-Control. Mit weiteren Tags kannst du die Validierungs-Meldungen ausgeben lassen, die seit dem 1.12 (aktuell RC1) auch spezielle Listener (also die Unterscheidung, ob ein Feld gefüllt ist und ob es eine valide E-Mail enthält). Das binding funktioniert über die Referenz auf das DOM-Element (Name des Elements). In deinem Beispiel ist das das Feld email. Hast du also ein Form-Element mit dem Namen "email", so kannst du in einem Filter (<form:addfilter />) oder einem Validator (<form:addvalidator />) das Control mit dem control-Attribut ansprechen. Intern wird beim observe-Event (also dem Einhängen des Validators/Filters) das DOM-Element mit dem angegebenen Namen gesucht, der Validator/Filter erzeugt und an das Objekt gehangen. Der Trigger ist der angegebene Button, der ebenfalls im DOM-Baum über den Namen des Buttons referenziert wird (button-Attribut). Ein Validator/Filter wird also nur ausgeführt, wenn der Trigger ausgelöst ist. Hierzu hat jeder Filter/Validator eine isActive()-Methode, die nur dann true zurückgibt, wenn das auslösende Ereignis auch stattgefunden hat. In der Standard-Implementierung ist das Ereignis der Button-Klick, möchtest du als Entwickler ein eigenes nutzen, kannst du das gerne in einem eigenen Validator/Filter durch Überschreiben der Methode so tun. Das Konstrukt Code: <form:listener control="email"> <div class="error-container"> </form:listener> könnte man noch dahingehend vereinfachen, dass bei jeglichen Fehlern im Formular immer der Inhalt des Tags <form:error /> angzeigt wird. Möchte man also oben eine ensprechende Box anzeigen geht das auch so: Code: <form:error> <div class="error-container"> </form:error> <form:listener control="email">...</form:listener> ... <form:error> </div> </form:error> Vorteil des Vorgehens ist - wie oben schon beschrieben -, dass du das Formular komplett per HTML und CSS ohne Einschränkung formatieren kannst. Man braucht keine Decorator/Provider/... um den Aufbau künstlich in den OO-Rahmen zu zwängen, sondern du schreibst ein Formular einfach wie ein Template, das jedoch alle Funktionen bereits kapselt. Im Document-Controller hast du dann mit PHP-Code: `$form = &$this->__getForm('registration');` vollen Zugriff auf die Objekt-Struktur, die aus den Tags aufgebaut und selbständig initialisiert wird. Liest du z.B. ein Feld aus, auf dem ein Filter registriert ist, wirst du immer schon den gefilterten Wert bekommen. Gleiches gilt für die Prüfung eines Formulars. Hierzu reicht ein einfaches PHP-Code: `if($form->isValid()){ echo 'hurra!'; } else { echo 'das war wohl nix! :('; }` Sofern du ein Formular vorbefülltn möchtest, kannst du das ebenso über den Zugriff auf die einzelnen DOM-Nodes. Hierzu bringt das Formular Methoden wie getFormElementByName() oder getFormElementById() mit. Von diesen erhälst du dann wieder ein Objekt und kannst dieses z.B. nach seinem (gefilteren) Inhalt fragen. Beantwortet das deine Frage? __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

26.08.2010, 23:44
Lenki Benutzer Registriert seit: 14.01.2010 Beiträge: 69 PHP-Kenntnisse: Fortgeschritten	Hallo zusammen, auch wenn das Thema jetzt schon ein bisschen älter ist, so beschäftigt es mich immernoch. Zur Zeit habe ich alles nochmal über den Haufen geschmissen und gehe das ganze nochmal neu an. Dabei versuche ich das ganze mal unter test-first zu implementieren in der Hoffnung, dass das ein bisschen zu einer ordentlichen Struktur beiträgt (ist in der Hinsicht ein bisschen ein Experiment). Hier verfolge ich aber weiterhin den Ansatz mit den Knoten, den ich in meinem letzten Post beschrieben hatte, und bin bisher noch recht zuversichtlich, dass das klappen wird. Klares Ziel ist natürlich, auch sauber so Sachen wir Radio-Button-Groups abzubilden und an Datenquellen zu binden, trotzdem aber noch "simple" Formulare auf möglichst einfache Weise bereitzustellen. Ich halte euch auf dem Laufenden, vielleicht zeichne ich die Tage mal ein Klassendiagramm.