Formulardesigner speichern

[Forumsgast]

Hallo,

ich entwickle gerade einen Formulardesigner, mit dem ich Eingabefelder auf einer Seite per Maus platzieren kann. Diese Felder werden später inhaltlich mit Daten aus einer DB befüllt.

Ich überlege nun wie ich die Felder speichere. In einer DB mit x/y Koordinate, oder in einer Datei, die später in die HTML Seite includiert wird. Was findet Ihr besser?

lg ralf

[Forumsgast]

Ich würde nur die Reihenfolge und evtl. Ausrichtung (bei PLZ / Stadt oder Straße / Hausnummer Kombinationen) speichern.

[Forumsgast]

ok, d.h. alle eigenschaften (maxlength, x/y usw) in einer selbst erzeugten html datei, und den rest in ner db? sollte die ausrichtung etc. dann nicht sinnvollerweiße aber auch in html-datei stehen?

[Forumsgast]

Du solltest das trennen:

Benutzereingaben speichern
Benutzereingaben laden
Benutzereingaben bearbeiten/erweitern
Benutzereingaben exportieren (hier wäre der Punkt das HTML-Layout zu generieren)

Wenn bei dir "Benutzereingaben speichern" = "Benutzereingaben in HTML exportieren" gleichgesetzt ist, kannst du nicht mehr nachträglich bearbeiten/erweitern oder andere Exportvarianten (andere Layouts, für PDF statt HTML, ..) einbauen.

Wenn ich einen Formular-Generator benutze, möchte ich exakt festlegen, wie was auszusehen hat (und es gibt immer irgendwo Ausnahmen) und ich möchte vor allem nachträglich Änderungen machen können, ohne das ganze Formular neu einzutippern.

Hast du nur ein HTML-Layout, hast du bereits ein Ausgabeformat, dass du ohne Metainformationen nicht mehr ohne weiteres bearbeiten/einlesen kannst.

[Forumsgast]

d.h. alle Eigenschaften wie Art des Feldes (Text, Radio..), x/y, width, maxlength,...... stehen in der datenbank. ich mache mir nur sorgen um die performance, da es in dem system nachher hunderte von formularen geben wird, die mehrere user gleichzeitig aufrufen. der formulardesigner wird aufgebort werden, sodass es auch z.B. eine Buttonleiste oder Tabellen auf der Seite gibt, die der User Anpassen kann.

[Forumsgast]

Benutz einfach einen Cache, der die HTML-Exportvariante bei der ersten Erzeugung zwischenspeichert und bei einer Änderung wieder verwirft.

[Forumsgast]

dafür kann ich ja smarty nehmen

[Forumsgast]

Smarty braucht kein Mensch.

[Forumsgast]

Ein Thema über das ich nicht mehr Diskutiere http://www.phphatesme.com/blog/php/w...tieren-werden/

[Forumsgast]

Mag sein, aber deine Aussage, nur weil ich Caching angesprochen habe, ist halt die typische Argumentation, die Smarty-Freunde bei ähnlichen Punkten immer wieder aufführen.

Smarty kann dies, Smarty kann das, wow Smarty kann sogar PHP ausführen, Smarty kann cachen, Smarty kann Schleifen umsetzen und Datumsangaben formatieren. Klingt alles beeindruckend, kann halt PHP aber auch schon. Logischerweise kann Smarty aber nichts, was PHP nicht kann.

Mich würden wirklich mal echte Argumente interessieren, die tatsächlich einen konkurrenzlosen Mehrwert bieten. Und da siehts halt ziemlich mau aus bei Templateengines.

Aber gut.

Würde trotzdem ein Rohdatenformat in der DB speichern, wie du dann den Exporter gestaltest, ob mit Smarty oder direkt in PHP, ist dann ja egal und gerade der Vorteil von der Entkopplung.

[Forumsgast]

Hmm, ob Du nun HTML speicherst, XML oder ein anderes Templateformat (ohne PHP-Erweiterung) ist doch egal. Von daher sehe ich das jetzt nicht so kritisch. Templates sind halt eine Abstraktion (die tw. besser gelungen sind als native PHP-HTML-Ausgabelogik).


Zur Frage: Ist halt die Frage, wie man Ausnahmesituationen bewertet und abbildet (Postfach statt Straße + Hausnummer, überlange Zeilen die umgebrochen werden müssen...)

Ich finde eine Templatevariante vielleicht gar nicht so verkehrt. Oder halt XML. Was Du auf jeden Fall brauchst:
- erweiterte Attribute ggü. HTML: z.B. Feldtyp, CSS-Formate, Validierungsangaben
- variable Felder (s.o. Adresse mit Postfach, Angaben abhänging von der Zahlungsart o.ä.); das kann man natürlich auch mit Javascript erschlagen, das mit D'n'D zu konfigurieren wird allerdings schwierig. Da kannst Du vielleicht ein Baukastensystem basteln.

[Forumsgast]

Ich finde es unsinnig potentiell nachtraeglich zu bearbeitende Daten bereits im Zielformat abzuspeichern. Ist halt eine Einbahnstrasse in meinen Augen.

[Forumsgast]

Kommt drauf an, ob man HTML in dem Fall als Ausgabeformat oder als Templatesprache betrachtet. Parsen kannst Du es genauso gut. Bis auf den Punkt:

dass du ohne Metainformationen nicht mehr ohne weiteres bearbeiten/einlesen kannst.

Dem muss man dann mit Zusatzattributen Rechnung tragen (z.B. data). Was wäre denn Dein Ansatz?

[Forumsgast]

Naja eben ein Basisformat wählen, das allen belangen gerecht wird und formatunabhängig ist. Entweder XML oder Datenbank (könnte ein kompliziertes Schema werden). Dann kann man ein Formular-Objekt in PHP daraus zur Verfügung stellen und ein Exportskript als Decorator drüberstülpen, das dann die Ausgabe im gewünschten Format übernimmt.

[Forumsgast]

könnte ein kompliziertes Schema werden

In der Tat

JSON wäre vielleicht auch noch ne Überlegung wert.