Quotelso wenn das mapping 1:1 ist, koenntest du auf die mapping-tabelle verzichten und z.B. mit einer Liste arbeiten:
Gut Okay. Also würde das mit meinem Beispiel auch funktionieren
Quotenur wuerde ich auf die Liste der DB-Felder nicht verzichten, weil es fuer einen Benutzer ja ein leichtes ist, weitere HTML-Felder hinzuzufuegen
Wie will den ein User Felder hinzufügen? Das CGI-Script liegt doch auf dem Server.
Quoteqq~...~ oder qq/.../ oder qq{...} usw. enspricht "..."
q~...~ oder q/.../ oder q{...} usw. entspricht '...'
nur darf das trennzeichen dann in der zeichenkette nicht vorkommen.
wenn ich Zeichenketten habe, in denen z.B. " oder ' vorkommen, verwende ich lieber keine Anfuehrungszeichen, sondern qq oder q, damit ich die " bzw. ' im String nicht zu escapen brauche. In dem Fall von oben waere es egal, weil ja im String selbst keine Anfuehrungszeichen vorkommen.
Damian Conway empfiehlt im Buch "Practial Perl" uebrigens q{...} oder qq{...}
Wieder was gelernt.
Jedes mal wenn ihr mit so "Monsterschnipsel" ankommt denke ich immer ich wäre voll der noob. ;)
Quotezur Gueltigkeit: wenn informationen von extern kommen (z.B. von einem Benutzer), kann der da auch (absichtlich oder unabsichtlich) beliebigen Schrott eingeben, oder Pflichtfelder nicht befuellen.
Wenn z.B. eine Datumseingabe nicht im korrekten Format ist, fliegt einem wahrscheinlich das SQL um die Ohren. Meist ist es jedoch besser, die Daten vorweg zu ueberpruefen und bei Fehlern dem Benutzer die Moeglichkeit zu bieten, die falschen Eingaben zu korrigieren.
Oder wenn der Benutzer eine Email-Adresse eingeben soll und einfach reinschreibt: "keine", dann koennte es spaeter mal unnoetig probleme bereiten, wenn man versucht, an diese Mailadresse eine Mail zu senden.
oder wenn eine zahl erwartet wird und jemand schreibt rein "nix" ...
Gut. Das werde ich einbauen wenn das schreiben in die Datenbank endlich so funktioniert wie ich das möchte.