nicht angemeldet
ssi aus formular
hallo zusammen!
ich möchte ein ssi (datum) mit einem html-formular übertragen.
die anzeige auf der formular-seite klappt auch mittels <input type="text" name="datum" size=20 value="<!--#echo var="DATE_LOCAL" -->">
nur leider scheint das onSubmit nicht beim server anzukommen-
bzw: ich weiss nicht so genau, ob mein perl-script das evtl. nicht korrekt dekodiert ($datum=param(‚datum')
kann mir da mal jemand einen tipp geben?
greetings
bernd
-
use Mosche;
($datum=param(?datum')
Du willst nur _Hockkommas_ verwenden (oder Anführungszeichen):
my $datum = param('datum');
my $datum = param("datum");use Tschoe qw(Matti);
-
moinmoin-
das ist ein tippfehler HIER- nicht im script (sorry).my $datum = param('datum');
my $datum = param("datum");das läuft nämlich so gerade nicht.
greetings
bernd-
use Mosche;
das ist ein tippfehler HIER- nicht im script (sorry).
Es bringt nichts, wenn du hier Codeschnippsel postet, die du nicht selber ausprobiert hast: Code immer per Copy&Paste posten (fürs nächste Mal).
my $datum = param('datum');
my $datum = param("datum");das läuft nämlich so gerade nicht.
Was läuft da nicht? Was für eine Fehlermeldung kommt?
Prinzipiell ist es mit SSI erstmal so: der Server ruft die Seite auf, ersetzt alle SSI-Tags durch ihre entsprechenden Werte und schickt sie an den Client. Wenn der Client submitted, hat er feste Werte (und keine dynamischen, wie man vielleicht durch SSI denken würde). Er schickt die Werte, die per SSI gesetzt wurden, als neue Anfrage an den Server. Dort kann man sie zB mit Perl und dem CGI Modul auswerten. Wo in dieser Kette liegt der Fehler? Hat der Client den korrekten Wert?
use Tschoe qw(Matti);
-
nun denn,
wenn es der wahrheitsfindung dient (wollte die frage möglichst kurz halten). aber no prob- der code ist business as usual:use CGI ('param');
use CGI::Carp ('fatalsToBrowser');
use strict;
my ($betreff, $name, $datum, $nachricht, $mail);$datum=param('datum');
$betreff=param('betreff');
$name=param('name');
$nachricht=param('nachricht');
$mail=param('mail');$nachricht=~ s/(?:\015\012?|\012)/<br>/g;
open (IN, ">>../../bernds/test.txt");
print IN "$betreff\t $name\t $datum\t $mail\t $nachricht\n";
close IN;und: fehlermeldung gibt es keine, es wird lediglich das datum nicht ins flat-file eingetragen (alles andere läuft korrekt). client sieht zumindest für meinen geschmack gut aus, denn das datum wird dort wie gesagt angezeigt.
greetings
bernd-
use Mosche;
und: fehlermeldung gibt es keine, es wird lediglich das datum nicht ins flat-file eingetragen (alles andere läuft korrekt). client sieht zumindest für meinen geschmack gut aus, denn das datum wird dort wie gesagt angezeigt.
Ich habe im Code keinen Fehler finden können. Hast du mal in die Error-Logs geschaut. Wenn $datum (bzw. param('datum')) undef ist, wird das in das Error-Log geschrieben. Probier mal was wie
print "datum: '$datum'";
Es könnte vielleicht sein, dass dein entsprechendes Input-Feld einen falschen Namen hat (großgeschrieben, ...). Prüf mal in diese Richtung.
use Tschoe qw(Matti);
-
hi,
muss ich leider mal dumm fragen :-}Hast du mal in die Error-Logs geschaut.
wo findet man denn die?
Probier mal was wie
print "datum: '$datum'";
tu ich sowieso: die zweite hälfte des scripts liest es wieder nach <STDOUT> (in html) aus.
wenn ich serverseitig über mein script $datum mit localtime() belege klappt das...Es könnte vielleicht sein, dass dein entsprechendes Input-Feld einen falschen Namen hat (großgeschrieben, ...).
ist leider nicht der fall (wär ja schön einfach, gell?)
tja
bernd
-
-
-
-
-
-
Hi Bernd,
ich möchte ein ssi (datum) mit einem html-formular
übertragen.das klingt zumindest schon mal ziemlich mißverständlich
- nämlich so, als würdest Du glaube, daß der Client
serverseitige Includes auflösen kann.
die anzeige auf der formular-seite klappt auch
mittels <input type="text" name="datum" size=20
value="<!--#echo var="DATE_LOCAL" -->">Das bedeutet, Du kannst im HTML-Quelltext der Seite
mit dem Formular drin im Browser sehen, daß bereits
korrekt ein Datumswert eingetragen wurde?
(D. h. die Formular-Seite ist ein SSI-Dokument.)nur leider scheint das onSubmit nicht beim server
anzukommenDiesen Satz verstehe ich nicht.
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael-
hi michael,
das klingt zumindest schon mal ziemlich mißverständlich
- nämlich so, als würdest Du glaube, daß der Client
serverseitige Includes auflösen kann.
möglicherweise glaube ich sowas laienhaftes: deswegen muss ich nochmal fragen, was du mit "auflösen" meinst- versenden?
Das bedeutet, Du kannst im HTML-Quelltext der Seite
mit dem Formular drin im Browser sehen, daß bereits
korrekt ein Datumswert eingetragen wurde?ja- bei aufruf der html-seite ist im browser an der richtigen stelle das richtige datum zu sehen.
nur leider scheint das onSubmit nicht beim server
anzukommenwie unten beschrieben möchte die daten aus dem formular via perl in flat-file schreiben. klappt alles, bis auf das datum...
greetings
bernd-
Hallo Bernd,
das klingt zumindest schon mal ziemlich mißverständlich
- nämlich so, als würdest Du glaube, daß der Client
serverseitige Includes auflösen kann.
möglicherweise glaube ich sowas laienhaftes: deswegen muss ich
nochmal fragen, was du mit "auflösen" meinst- versenden?Nein, nicht versenden. Michael wollte sagen, dass der Browser keine
SSI-Direktiven versteht. Die setzt der Server um.ja- bei aufruf der html-seite ist im browser an der richtigen
stelle das richtige datum zu sehen.Sind die HTML-aktiven Zeichen maskiert?
Gruesse,
CK-
hi christian,
Sind die HTML-aktiven Zeichen maskiert?
weiss nicht so genau, ob ich das als nicht-informatiker jetzt richtig verstehe, deswegen hier noch mal der entsprechende code aus dem formular:
<input type="text" name=datum size=20 value="<!--#echo var="DATE_LOCAL" -->">
ok so?gruß & dank
bernd-
Hi Bernd,
Sind die HTML-aktiven Zeichen maskiert?
weiss nicht so genau, ob ich das als nicht-
informatiker jetzt richtig verstehe, deswegen
hier noch mal der entsprechende code aus dem formular:
<input type="text" name=datum size=20 value="<!--#echo var="DATE_LOCAL" -->">genau dieser COde beantworten Christians Frage _nicht_.
Relevant für das, was beim CGI-Skript ankommt, ist das,
was _nach_ der Interpretation des SSI-Statements im
Formular stand.
Wenn im Wert von DATE_LOCAL - welches ja wiederum in
einem uns nicht bekannten Format eingesetzt wurde! -
irgend ein "lästiges" Zeichen steht (beispielsweise
ein Hochkomma oder ein ">"-Zeichen oder ...), dann
enthält Dein Formular ggf. keinen korrekten HTML-Code
mehr.Hast Du Deine Formular-Seite mal durch den Validator
gejagt?Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael-
hi michael,
das versteh ich doch schonmal besser und reiche also die formatierung nach.
hab ich so erledigt:
<!--#config timefmt="%d.%m.%y, %T"-->irgendwas problematisches zu sehen?
anyway:
dank für gründliche erklärung schonmal
bernd-
Hi Bernd,
<!--#config timefmt="%d.%m.%y, %T"-->
Das ist immer noch nicht der HTML-Code, den Du bei "view-source"
in Deinem Browser siehst. Und es ist auch keine Aussage darüber,
ob diese generierte HTML-Seite validen Code enthält.Laß Dir doch nicht alles einzeln aus der Nase ziehen ...
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael-
moin michael,
Das ist immer noch nicht der HTML-Code, den Du bei "view-source"
so sieht das netscape:
<input type="text" name=datum size=20 value="19.06.02, 09:10:40">
Laß Dir doch nicht alles einzeln aus der Nase ziehen ...
hat damit definitiv nix zu tun- bin weit entfernt von irgendwelcher geheimniskrämerei.
ich programmier halt noch nicht solange...beste grüße
bernd-
Hi Bernd,
Das ist immer noch nicht der HTML-Code, den Du bei "view-source"
so sieht das netscape:
<input type="text" name=datum size=20 value="19.06.02, 09:10:40">Na also, geht doch. ;-)
(Probleme beschreiben zu können will halt auch gelernt
sein - manchmal ist das der halbe Weg zur Lösung.)Abgesehen davon, daß ich um die Werte von "name=" und
"size=" noch ein paar Gänsebeine, äh ... -füße drum
legen würde, sieht das nicht so arg verkehrt aus.Folglich sollte das Problem wohl eher auf der Seite des
CGI-Decodierers liegen und von SSI völlig unabhängig sein.Wie sieht denn der entsprechende URL innerhalb des
Logfiles Deines Servers aus?
Da müßte jetzt der Wert entsprechend URL-encoded drin
stehen, wenn der Browser alles richtig gemacht hat ...Das ist überhaupt die Methode, mit der man Fehler
findet: Nach jedem Schritt nachsehen, ob das Zwischen-
Ergebnis wirklich noch so aussieht, wie es sollte.Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael-
hallo michael,
was lange währt...
...wird endlich ein tipp, mit dem auch ein rookie was anfangen kann. besten dank schonmal.
trotzdem noch eine frage hierzu:Wie sieht denn der entsprechende URL innerhalb des
Logfiles Deines Servers aus?
Da müßte jetzt der Wert entsprechend URL-encoded drin
stehen, wenn der Browser alles richtig gemacht hat ...ich habe auch nach gründlicher fahndung bei meinem provider keine files mit "log" in namen oder suffix finden können. gibts da einen speziellen ablageort (den ich nicht kenne) oder liegt das am "service"?
gruß & dank
bernd-
Hi bernd,
ich habe auch nach gründlicher fahndung bei meinem
provider keine files mit "log" in namen oder suffix
finden können. gibts da einen speziellen ablageort
(den ich nicht kenne)das ist konfigurierbar.
oder liegt das am "service"?
Schon eher.
Bei meinem Webspace hatte ich ursprünglich auch nur
ein access_log - das error_log zu bekommen hat mich
etwas Überzeugungsarbeit gekostet (ich mußte dem
Provider klar machen, daß bestimmt nicht _er_ meine
CGI-Skripte und .htaccess-Konfigurationen debuggen
will und ich dafür ein error_log dringend brauche).Viele Grüße
Michael-
hallo michael,
das war ein wichtiger hintergrund- dank dafür.
in puncto verhandlungen gibt's wohl in meinem falle nicht sehr viel zu holen, schließlich kann man kaum meckern, wenn es zum kostenfreien webspace auch noch einen offenen cgi-bin dazu gibt...
aber: fragen kostet schließlich auch nix ;-)beste grüße
bernd-
Hi bernd,
das war ein wichtiger hintergrund- dank dafür.
in puncto verhandlungen gibt's wohl in meinem falle
nicht sehr viel zu holen, schließlich kann man kaum
meckern, wenn es zum kostenfreien webspace auch noch
einen offenen cgi-bin dazu gibt...
aber: fragen kostet schließlich auch nix ;-)doch - Zeit. Überlege Dir einfach, wieviele Euro Du
während dieses Threads verbraten hast und ob es Dir
das wert war, auf einen Billigprovider zu setzen.You get what you pay for.
Viele Grüße
<img src="http://www.schroepl.net/projekte/gzip_cnc/gzip_cnc.gif" border=0 alt=""> Michael
-
-
-
-
-
-
-
-
-
- nämlich so, als würdest Du glaube, daß der Client
- nämlich so, als würdest Du glaube, daß der Client
- nämlich so, als würdest Du glaube, daß der Client