Schemafrage: Formular mit vielen Auswahlmöglichkeiten

[split.s]

Hallo,

habe hier mal eine Frage wie ihr folgendes umsetzen würdet:

Aufgrund der Vielzahl eines <select>-Tags will ich die enzelnen Items in eine externe Datei auslagern. Welches Dateiformat würdet ihr hier nehmen? JSON oder XML?

Beispiel eines HTML-Templates anhand von Pseudocode:

<select name="typen"><LOOP><option value="%p">%s</option></LOOP></select>

Die Items will ich extern speichern, da es sich um eine große Auswahl handelt.
Bisher dachte ich da an soetwas wie:

JSON:

typen: [
   {value: 'foo1', content: 'bar1'},
   {value: 'foo2', content: 'bar2'}
]

Meine Frage ist also eigentlich recht kompakt: Würdet ihr es auch so machen wenn ihr große Formulare mit vielen Auswahlmglichkeiten hättet?

[Alexander (HH)]

Moin Moin!

Aufgrund der Vielzahl eines <select>-Tags will ich die enzelnen Items in eine externe Datei auslagern.

Warum?

HTML hat mit Tonnen von select-Elementen kein Problem, Browser auch nicht. Warum willst Du Dir eine zusätzliche Abhängigkeit von Javascript und vermutlich auch noch AJAX schaffen?

Alexander

[ChrisB]

Hi,

Aufgrund der Vielzahl eines <select>-Tags will ich die enzelnen Items in eine externe Datei auslagern.

Warum?

Ca-ching?

MfG ChrisB

[split.s]

Versteh ich nicht.

[split.s]

Weil ich keinen Bock habe, jedes einzelne <option> zu schreiben! Bin ic denn bekloppt. Will außerdem Schreibfehler vermeiden und das hinzufügen neuer <option>-Tags vereinfachen.
Das ganze ist auch nicht Clientseitig, sondern es geht hier um ein Serverseitiges Template-System (HTML::Template::Compiled)

[Alexander (HH)]

Moin Moin!

Weil ich keinen Bock habe, jedes einzelne <option> zu schreiben!

Ctrl-C, Ctrl-V ...

Bin ic denn bekloppt.

Möchtest Du eine ehrliche Antwort?

Will außerdem Schreibfehler vermeiden und das hinzufügen neuer <option>-Tags vereinfachen.
Das ganze ist auch nicht Clientseitig, sondern es geht hier um ein Serverseitiges Template-System (HTML::Template::Compiled)

Und warum sagst Du das nicht gleich?

HTML::Template::Compiled nutzt Perl, da bietet es sich an, Datenstrukturen zu nutzen, die Perl leicht lesen kann und die ein Mensch leicht ändern kann. YAML erscheint mir auch im zehnten Anlauf völlig konfus, kann aber relativ leicht gelesen werden (YAML::Any), XML ist bürokratischer Schreibkrampf und verlangt nach fetten Libraries (XML::LibXML), JSON ist mager und mit etwas zusätzlichem White Space auch für Menschen leicht les- und änderbar (JSON::XS). Wenn Dir gar nichts besseres einfällt und Du der einzige Benutzer bist, schreib einen Hash in Perl-Notation in eine Datei und lies den per do, require oder notfalls String-eval. Du könntest auch DBI nutzen und die Daten in eine Datenbank Deiner Wahl packen, SQLite (DBD::SQLite) spart den Server, PostgreSQL (DBD::Pg) hat richtig Dampf, um auch gleich alle anderen Daten zu verwursten, Oracle (DBD::Oracle) statt PostgreSQL, wenn Du zu viel Geld hast, MS SQL oder Access (beide via DBD::ODBC), wenn Du auf Schmerzen stehst und zu viel Geld hast, MySQL (DBD::mysql), wenn Du auf Schmerzen stehst, Dir aber weder MS noch Domina leisten kannst.

Alexander

[Tabellenkalk]

Bin ic denn bekloppt.

Möchtest Du eine ehrliche Antwort?

war es eine Frage?

[Der Martin]

Hallo,

Weil ich keinen Bock habe, jedes einzelne <option> zu schreiben!
Ctrl-C, Ctrl-V ...

oder für die Traditionalisten: Ctrl-Ins, Shift-Ins. Konnte ich mir von Anfang an besser merken als die Ctrl-Buchstabe-Kombinationen, und geht mir auch leichter von der Hand (Gewöhnung). Der letzte im Tripel ist noch Shift-Del (Cut).
Diese Tastenkombis werden zwar heute nur noch sehr selten propagiert, aber zum Glück immer noch von allen mir bekannten GUIs und Applikationen unterstützt.

Bin ic denn bekloppt.
Möchtest Du eine ehrliche Antwort?

*fg*

Ciao,
 Martin