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

Lenki · 16.07.2010, 22:02

Hallo zusammen,

ich habe etwa folgende Situation...
Ich habe ein Form-Objekt, bei dem ich über register() Form-Elemente registrieren kann.
Und ich habe Datenobjekte, die in eine Datenbanktabellenzeile repräsentieren und in denen grundsätzlich auch genug Infos hinterlegt sind, um daraus ein passenden Form-Element zu erzeugen:

PHP-Code:

  // Form::register(FormElement $element)

$form = new Form('form_identifier');

$form->register(new InputField('...'));

$obj = new SomeDataObject();

// und die die magische Zeile...

Naja, und jetzt suche ich nach einer Best Practise Lösung für ein solch artiges Problem. Ich habe hier neben mir Head First Design Patterns liegen und mal durchgeblättert. Ich möchte hier nicht auf Teufel komm raus irgendein Pattern anwenden, aber ich habe mir gedacht, dass es für sowas doch sicher schon einen guten Weg gibt.
Die Pattern, bei denen ich Länger als eine Sekunde überlegt habe, waren das Adapter-Pattern, aber ich möchte ja das Daten-Objekt nicht wie ein Form aussehen lassen. Das Decorator-Pattern würde ja zum Form-Objekt zusätzliche Funktionalität hinzufügen, aber ich möchte ja nicht Funktionalität dranhängen, sondern quasi Daten. Joa, und der Rest ist eigentlich sofort ausgeschieden.
Dann habe ich mal selbst meinen Kopf angestrengt, wie man das am Besten angeht.
Eine Methode a la addElementsFromDataObject() am Form-Objekt wäre mMn nicht gut, da dann ja das Form-Objekt weiss, welche Objekte es hat - aktuell weiss es ja nur, dass es FormElement-Objekte hat.
Ich habe noch an ein Translator-Klasse gedacht, die das Form-Objekt und das Daten-Objekt übergeben bekommt, und dann am Form-Objekt die Form Elemente anhängt, aber irgendwie bin ich davon auch noch nicht überzeugt.
Die letzte Idee war am Daten-Objekt eine Methode hinzuzufügen, die ein Array (oder ein Collection-Objekt mit Objekte, Stilfrage, oder?) mit den entsprechenden FormElement-Objekten erzeugt und zurückgibt. Danach entweder über eine Schleife am Form registriert werden oder mit einer registerFromArray()-Methode

Wie würdet ihr das angehen, damit die Objekte nicht mehr wissen, als sie wissen müssen.

Danke und viele Grüße!

nikosch · 16.07.2010, 22:55

SOrry, aber was genau DU willst, hast Du noch nicht beschrieben.

Lenki · 16.07.2010, 23:20

Ok, sorry, ich versuch nochmal nachzulegen...

Zitat:

Zitat von Lenki

Naja, und jetzt suche ich nach einer Best Practise Lösung für ein solch artiges Problem.

Das Problem, bzw. ehr die Fragestellung ist im Wesentlichen, wen ich sinnvoller weise die FormElement-Objekte erzeugen lasse: Also entweder das Daten-Objekt, das Form-Objekt oder eine Art Übersetzer-Objekt.
Ich habe ja oben schon für die eine und die andere Lösung "argumentiert" und tendiere gerade zum Übersetzer-Objekt.
Habe ich hier irgendetwas übersehen, einen Aspekt vergessen?

dr.e. · 16.07.2010, 23:52

Meiner Ansicht nach krankt der Ansatz an der Trennung der Zuständigkeiten. Für mich sollte Präsentation eines Formulars und die Logik getrennt werden. Initialisierung eines Formulars sollte man entweder durch "intelligente" Formular-Elemente realisieren, die ein Bindung zur Datenquelle injiziert bekommen oder von aussen - z.B. per MVC-Controller - steuern. Letzteres ist einfacher, da generischer umzusetzen.

Beide Varianten erfordern jedoch eine bessere Abstraktion deines Formular-Objekts, denn so wie ich das Interface wahrnehme, lässt die Möglichkeit der Formatierung zu wünschen übrig.

robo47 · 17.07.2010, 08:14

Schau dir doch mal z.b. sfForm (Symfony 1.4) oder Zend_Form (Zend Framework) an, beide arbeiten mit Dekoratoren die sich austauschen lassen.

Dabei gibt es dann einen Dekorator für die Form und welche für jedes Element.
Der Dekorator der Form bestimmt dann "die Umgebung" des Formulars, ob das ne Tabelle, ne Liste oder sonstwas ist.
Die der Felder dann wie das Feld angelegt wird, wo die potentiellen Fehlermeldungen der Validierung positioniert werden, ... .

Rein theorhetisch lässt sich das also auch umschreiben dass damit ein PDF-Formular oder rein theoerhetisch mit gdlib/imagemagick ein Bild erstellt wird

nikosch · 17.07.2010, 13:00

Ein Decorator klingt schon ganz sinnvoll. Du darfst nicht vergessen, dass Datentypen durchau mit mehreren Formelementen dargetellt werden können - z.B. mit Selections oder Radioboxes, mit Multi-Selects oder Checkboxgruppen...

Im Endeffekt wäre das eine Möglichkeit:

PHP-Code:

  FF = new FormFactory;
Form = new Form;

while (set = fetch_DB) {
  Form->addElement (FF->create (set , Form));
}

wobei FF->create () ein Formelement erzeugt und diesen mit einem Formelement-Decorator dekoriert zurückgibt.

Lenki · 17.07.2010, 13:29

Zitat:

Zitat von dr.e.

Meiner Ansicht nach krankt der Ansatz an der Trennung der Zuständigkeiten. Für mich sollte Präsentation eines Formulars und die Logik getrennt werden.

Wo siehst du denn bei meinem Ansatz eine Vermischung von beidem? Wie das Formular angezeigt wird, ist hier noch nicht festgelegt. Oder findest du hier das InputField-Objekt zu einengend? Habe hier auch schon mit dem Gedanken gespielt, die Methode als eine Art FormElement-Factory zu verwenden und einfach nur einen String mit der Info zum Form-Element zu übergeben und den Rest der Factory zu überlassen (ähnlich, wie es bei Zend_Form möglich ist)

Zitat:

Zitat von dr.e.

Initialisierung eines Formulars sollte man entweder durch "intelligente" Formular-Elemente realisieren, die ein Bindung zur Datenquelle injiziert bekommen oder von aussen - z.B. per MVC-Controller - steuern. Letzteres ist einfacher, da generischer umzusetzen.

Wenn ich das richtig verstehe, ist genau das meine Frage. Also doch eine Art Mittler-Objekt?

Zitat:

Zitat von dr.e.

Beide Varianten erfordern jedoch eine bessere Abstraktion deines Formular-Objekts, denn so wie ich das Interface wahrnehme, lässt die Möglichkeit der Formatierung zu wünschen übrig.

Auf welche Ebene würdest du denn das ganze abstrahieren? Ich kann vom Grundgedanken her keinen Unterschied von meiner Abstraktion zu der von Zend_Form erkennen.

Zitat:

Zitat von robo47

Dabei gibt es dann einen Dekorator für die Form und welche für jedes Element.
Der Dekorator der Form bestimmt dann "die Umgebung" des Formulars, ob das ne Tabelle, ne Liste oder sonstwas ist.

Mh, daran habe ich auch schon gedacht. Das möchte ich mir grundsätzlich offen lassen, aber noch nicht implementieren. Wenn ich Dekoratoren richtig verstanden habe, kann man sie doch eh immer "vorne drauf setzen" (aufs Form-Objekt und dadurch neue Funktionalitäten hinzufügen) Nichtsdestodrotz weiss das Formular-Objekt ja vorher schon (vor dem Dekorator), wieviele FormElemente es beinhaltet und mit welchen Datne sie gefüllt sind, nur nicht, wie diese FormElemente dann letzten Endes dargestellt werden, oder?

Zitat:

Zitat von nikosch

Ein Decorator klingt schon ganz sinnvoll. Du darfst nicht vergessen, dass Datentypen durchau mit mehreren Formelementen dargetellt werden können - z.B. mit Selections oder Radioboxes, mit Multi-Selects oder Checkboxgruppen...

Im Endeffekt wäre das eine Möglichkeit:

PHP-Code:

  FF = new FormFactory;

Form = new Form;

 
while (set = fetch_DB) {

  Form->addElement (FF->create (set , Form));

}

wobei FF->create () ein Formelement erzeugt und diesen mit einem Formelement-Decorator dekoriert zurückgibt.

Ok... hier wäre der Decorator dann aber "auf" dem Objekt, dass eine bestimmten Teil meines Datenobjektes (wenn das Datenobjekt eine Tabellenzeile wäre, also auf dem Objekt, dass die Tabellenzelle repräsentiert) repräsentiert, oder?
Der Ansatz gefällt mir...

nikosch · 17.07.2010, 14:38

Eigentlich nicht. Du schreibst oben, die DB-Datensätze enthalten genug Informationen um zu bestimmen, welcher Elementtyp sinnvoll ist. Aus der Übergabe von set (==Datensatz) oben würde die Factory
1) diese Information auswerten
2) einen passenden Elementtyp erstellen
3) einen Decorator für diesen Elementtyp mit einem gegebenen Feldwert/Auswahlwert aus set erstellen.
4) diesen Decorator den Form zuordnen

Ich habe ähnliches schon versucht, deshalb sei hier gleich auf die Problematiken für Gruppenelemente hingewiesen:
Aus Objektsicht haben gruppierte Elemente eine andere Struktur, sie sind quasi zweidimensional. Das „beißt“ sich aber mit relationalen Datenbanken, die jeden Wert quasi-atomar liefern. Damit musst DU
1) Elementgruppen als komponiertes Objekt erstellen (außen Gruppe, innen Item-Objekte)
2) Diese Objekte in der Factory vorhalten (von create zu create wird ja u.U. das gleiche Gruppenobjekt bestückt).
Warum man die Elemente nicht einzeln behandeln kann:
1) spätestens bei Selections mit der HTML-seitigen Schachtelung wird das klar (aber auch bei gut gemachten Radio-Gruppen, die bspw. durch fieldset gruppiert sind)
2) die Zuordnung eines Vorgabe/Returnwertes muss ja irgebndwie zentral erfolgen (i.A. an ein Objekt, das durch das html-seitige name-Attribut repräsentiert wird). Damit nþzen Dir Einzelobjekte bspw. für <option> nicyt viel.

Ein Ausweg - IMHO aber kein eleganter - könnte sein, die Factoryprodukte alle in ein Array zu schreiben und nachträglich auf Grundlage des name-Members zu gruppieren. Hierbei muss man dann natürlich Spezialitäten wie name[1], name[47] berücksichtigen...

Zitat:

Ok... hier wäre der Decorator dann aber "auf" dem Objekt, dass eine bestimmten Teil meines Datenobjektes (wenn das Datenobjekt eine Tabellenzeile wäre, also auf dem Objekt, dass die Tabellenzelle repräsentiert) repräsentiert, oder?

Nochmal kurz zurück zum Grundproblem. Das Problem an der ganzen Sache ist, dass Du auf beiden Seiten (Dateneingabe vs. Datendarstellung) verschiedene Datentypen hast - eindimensionale und mehrdimensionale. Das abzubilden ist enorm schwierig, weil Du auf keine Seite eine einheitliche Schnittstelle hinbekommst, auf der das andere Objekt aufbauen kann.

dr.e. · 17.07.2010, 23:30

Hallo Lenki,

nach Nikosch' Post muss ich denke ich nicht mehr im Datail auf deinen Post eingehen. Er hat sehr treffend beschrieben wo die Tücken einer derartigen Vorgehsweise liegen. Deshalb propagiere ich einen anderen Ansatz als beispielsweise Zend_Form: ein Formular ist auch nichts anderes als ein Template mit "Formular-sensitiven" Elementen, die durch die Tag-Struktur nach der Analyse als echte Objekt-Struktur zur Verfügung steht. Dadurch hast du sowohl die Möglichkeit, die Elemente sehr einfach zu formatieren und zu platzieren als auch eine saubere Objekt-Struktur, die du entsprechend adressieren, befüllen und manipulieren kannst.

Den Overhead mit Decoratoren und Gruppierungs-Elementen nimmt dir immer Flexibilität, die spätestens bei komplexeren Aufgaben notwendig ist.

xm22 · 19.07.2010, 08:10

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

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

16.07.2010, 22:02
Lenki Benutzer Registriert seit: 14.01.2010 Beiträge: 69 PHP-Kenntnisse: Fortgeschritten	Form-Objekt mit Form-Elementen aus Daten-Objekt anreichen Hallo zusammen, ich habe etwa folgende Situation... Ich habe ein Form-Objekt, bei dem ich über register() Form-Elemente registrieren kann. Und ich habe Datenobjekte, die in eine Datenbanktabellenzeile repräsentieren und in denen grundsätzlich auch genug Infos hinterlegt sind, um daraus ein passenden Form-Element zu erzeugen: PHP-Code: `// Form::register(FormElement $element) $form = new Form('form_identifier'); $form->register(new InputField('...')); $obj = new SomeDataObject(); // und die die magische Zeile...` Naja, und jetzt suche ich nach einer Best Practise Lösung für ein solch artiges Problem. Ich habe hier neben mir Head First Design Patterns liegen und mal durchgeblättert. Ich möchte hier nicht auf Teufel komm raus irgendein Pattern anwenden, aber ich habe mir gedacht, dass es für sowas doch sicher schon einen guten Weg gibt. Die Pattern, bei denen ich Länger als eine Sekunde überlegt habe, waren das Adapter-Pattern, aber ich möchte ja das Daten-Objekt nicht wie ein Form aussehen lassen. Das Decorator-Pattern würde ja zum Form-Objekt zusätzliche Funktionalität hinzufügen, aber ich möchte ja nicht Funktionalität dranhängen, sondern quasi Daten. Joa, und der Rest ist eigentlich sofort ausgeschieden. Dann habe ich mal selbst meinen Kopf angestrengt, wie man das am Besten angeht. Eine Methode a la addElementsFromDataObject() am Form-Objekt wäre mMn nicht gut, da dann ja das Form-Objekt weiss, welche Objekte es hat - aktuell weiss es ja nur, dass es FormElement-Objekte hat. Ich habe noch an ein Translator-Klasse gedacht, die das Form-Objekt und das Daten-Objekt übergeben bekommt, und dann am Form-Objekt die Form Elemente anhängt, aber irgendwie bin ich davon auch noch nicht überzeugt. Die letzte Idee war am Daten-Objekt eine Methode hinzuzufügen, die ein Array (oder ein Collection-Objekt mit Objekte, Stilfrage, oder?) mit den entsprechenden FormElement-Objekten erzeugt und zurückgibt. Danach entweder über eine Schleife am Form registriert werden oder mit einer registerFromArray()-Methode Wie würdet ihr das angehen, damit die Objekte nicht mehr wissen, als sie wissen müssen. Danke und viele Grüße!


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

16.07.2010, 22:55
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.256 PHP-Kenntnisse: Fortgeschritten	SOrry, aber was genau DU willst, hast Du noch nicht beschrieben. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

16.07.2010, 23:52
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.633 PHP-Kenntnisse: Fortgeschritten	Meiner Ansicht nach krankt der Ansatz an der Trennung der Zuständigkeiten. Für mich sollte Präsentation eines Formulars und die Logik getrennt werden. Initialisierung eines Formulars sollte man entweder durch "intelligente" Formular-Elemente realisieren, die ein Bindung zur Datenquelle injiziert bekommen oder von aussen - z.B. per MVC-Controller - steuern. Letzteres ist einfacher, da generischer umzusetzen. Beide Varianten erfordern jedoch eine bessere Abstraktion deines Formular-Objekts, denn so wie ich das Interface wahrnehme, lässt die Möglichkeit der Formatierung zu wünschen übrig. __________________ 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! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

17.07.2010, 08:14
robo47 Moderator Registriert seit: 03.09.2004 Beiträge: 11.798 PHP-Kenntnisse: Fortgeschritten	Schau dir doch mal z.b. sfForm (Symfony 1.4) oder Zend_Form (Zend Framework) an, beide arbeiten mit Dekoratoren die sich austauschen lassen. Dabei gibt es dann einen Dekorator für die Form und welche für jedes Element. Der Dekorator der Form bestimmt dann "die Umgebung" des Formulars, ob das ne Tabelle, ne Liste oder sonstwas ist. Die der Felder dann wie das Feld angelegt wird, wo die potentiellen Fehlermeldungen der Validierung positioniert werden, ... . Rein theorhetisch lässt sich das also auch umschreiben dass damit ein PDF-Formular oder rein theoerhetisch mit gdlib/imagemagick ein Bild erstellt wird __________________ robo47.net - Blog, Codeschnipsel und mehr \| Caching-Klassen und Opcode Caches in php \| Robo47 Components - PHP Library extending Zend Framework

17.07.2010, 13:00
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.256 PHP-Kenntnisse: Fortgeschritten	Ein Decorator klingt schon ganz sinnvoll. Du darfst nicht vergessen, dass Datentypen durchau mit mehreren Formelementen dargetellt werden können - z.B. mit Selections oder Radioboxes, mit Multi-Selects oder Checkboxgruppen... Im Endeffekt wäre das eine Möglichkeit: PHP-Code: `FF = new FormFactory; Form = new Form; while (set = fetch_DB) { Form->addElement (FF->create (set , Form)); }` wobei FF->create () ein Formelement erzeugt und diesen mit einem Formelement-Decorator dekoriert zurückgibt. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

17.07.2010, 23:30
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.633 PHP-Kenntnisse: Fortgeschritten	Hallo Lenki, nach Nikosch' Post muss ich denke ich nicht mehr im Datail auf deinen Post eingehen. Er hat sehr treffend beschrieben wo die Tücken einer derartigen Vorgehsweise liegen. Deshalb propagiere ich einen anderen Ansatz als beispielsweise Zend_Form: ein Formular ist auch nichts anderes als ein Template mit "Formular-sensitiven" Elementen, die durch die Tag-Struktur nach der Analyse als echte Objekt-Struktur zur Verfügung steht. Dadurch hast du sowohl die Möglichkeit, die Elemente sehr einfach zu formatieren und zu platzieren als auch eine saubere Objekt-Struktur, die du entsprechend adressieren, befüllen und manipulieren kannst. Den Overhead mit Decoratoren und Gruppierungs-Elementen nimmt dir immer Flexibilität, die spätestens bei komplexeren Aufgaben notwendig ist. __________________ 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! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

19.07.2010, 08:10
xm22 Erfahrener Benutzer Registriert seit: 30.07.2008 Beiträge: 1.129 PHP-Kenntnisse: Fortgeschritten	Es spricht ja nichts gegen eine Vermischung. Bei Bedarf nutzt man dann entweder einen Decorator zur Ausgabe oder schreibt eben plain html..