|< 1 2 >| | 16 Einträge, 2 Seiten |
<input type="text" name="counter" />
1
2
3
4
5
map {
$dbh->quote( # ein wenig sicherheit, escape SQL-Sonderzeichen
$params{$_} # $_ ist key, also wert des entsprechenden feldes
)
} keys %mappings_form2db # gibt also die liste der keys fuer %params zurueck
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
my %element;
$element{liste} =
[
{ art => "textfield", name => "nachname",
bez => "Nachname:", size => 20},
{ art => "textfield", name => "vorname",
bez => "Vorname:", size => 20},
{ art => "popup_menu", name => "zimmerbett",
bez => "Zimmer/Bett:",},
{ art => "popup_menu", name => "anrede",
bez => "Anrede:",},
....
];
...
My $cgi = CGI->new();
My %params = $cgi->Vars();
My $sql = qq~INSERT INTO Kontakt (~
. join (',', values %element{name})
.qq~) VALUES (~
. join(',',map { $dbh->quote($params{$_} ) } keys %element{name}
.")";
1
2
3
4
5
6
7
8
9
my @fields = qw(nachname vorname adresse ort);
my $cgi = CGI->new();
my %params = $cgi->Vars();
my $sql = 'INSERT INTO tabelle ('
. join(', ', @fields)
. ') VALUES ('
. join(", ", map { $dbh->quote( $params{$_} ) } @fields )
. ')';
Quotelso wenn das mapping 1:1 ist, koenntest du auf die mapping-tabelle verzichten und z.B. mit einer Liste arbeiten:
Quotenur wuerde ich auf die Liste der DB-Felder nicht verzichten, weil es fuer einen Benutzer ja ein leichtes ist, weitere HTML-Felder hinzuzufuegen
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{...}
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" ...
Quotenur wuerde ich auf die Liste der DB-Felder nicht verzichten, weil es fuer einen Benutzer ja ein leichtes ist, weitere HTML-Felder hinzuzufuegen
my $aktion = lc (param ("aktion"));
|< 1 2 >| | 16 Einträge, 2 Seiten |