nicht angemeldet
Variablen deklarieren
Hallo, ist es möglich eine Variable in JavaSript anhand eines HTML-Formulars zu deklarieren? Also:
Ich habe ein Formular:
<form action=doku2.html method=post>
<input type=text name=xyz><p<
<input type=submit>
</form>
Dieses Formular will ich jetzt auf der neuen Seite "doku2.html" auswerten und anschließend per Email versenden.
Ist es mir jetzt möglich irgendwie den eingetragenen Text als "Value" in ein neues Formular auf der Seite "doku2.html" anzeigen zu lassen? Also in etwa so:
<input type=text name=abc value=$xyz>
mfg
Dirk
-
Hallo,
mit js ist das möglich, aber unfein...
wenn du keinen server benutzt kannst du dein form nicht mit get oder post abschicken, dies funktioniert nur, wenn die seite über einen server abgerufen wird...(serverseitige auswertung wäre sowieso anzuraten...
in deinem fall müßte man das faken...
per button eine neue seite aufrufen, die per
opener.formname.inputname.value inhalte abruft und ins aktuelle document schreibt...z.B. document.formname.inputname.value = opener.document.formname_vorher.inputname_vorher.value;
oder du generierst in der ersten seite per button einen aufruf an die zu übergebende seite und hängst die variablen manuell als querystring an...
diese kannst du mit location.seatch in der folgenden seite auswerten...
übrigens: sauberes html--> attribute gehören in "
Odium-
Aloha!
mit js ist das möglich, aber unfein...
wenn du keinen server benutzt kannst du dein form nicht mit get oder post abschicken, dies funktioniert nur, wenn die seite über einen server abgerufen wird...(serverseitige auswertung wäre sowieso anzuraten...
Das stimmt nicht. Mit GET kann man das Formular sehr wohl mit Javascript auswerten. GET-Formulare schreiben die Formulardaten URL-encoded in die URL mit rein - hinter das Fragezeichen. Javascript kann mit location.search darauf zugreifen. Der Aufwand des Dekodierens der URL-Zeile ist auch eher gering (decodeURI - funktioniert nicht in Opera, oder unescape - ansonsten gibts dazu sicherlich was in den Feature-Artikeln), man muß "nur" den langen String zerpflücken.
per button eine neue seite aufrufen, die per
opener.formname.inputname.value inhalte abruft und ins aktuelle document schreibt...z.B. document.formname.inputname.value = opener.document.formname_vorher.inputname_vorher.value;
Das kann ja schon deswegen nicht klappen, weil die alte Seite inklusive des Formulars weg ist, wenn die neue Seite geladen wurde - es sein denn, die zwei Seiten sind in einem Frameset parallel angezeigt.
- Sven Rautenberg
-
Hallo,
ich schrieb nicht, dass das auswerten per location.search nicht funktioniert...was ich sagte war: bei einer lokal getesteten seite ist ein abschickens des form in keiner methode möglich, dies geht nur, wenn die seite über einen server aufgerufen wurde...
zu deiner zweiten bemerkung: da steht:
per button eine neue seite aufrufen,
deswegen ist die alte noch nicht weg, das erklärt auch meinen vorschlag des zugriffs per opener
wenn ich frames gemeint hätte, würde da auch sowas wie: top.frames[x] sthen...
das nächste mal bitte genauer lesen...
Odium
-
Aloha!
ich schrieb nicht, dass das auswerten per location.search nicht funktioniert...was ich sagte war: bei einer lokal getesteten seite ist ein abschickens des form in keiner methode möglich, dies geht nur, wenn die seite über einen server aufgerufen wurde...
Stimmt nicht - gerade getestet! Man kann per GET abgeschickte Formulare auch dann mit JS auswerten, wenn die Datei mit file:// aufgerufen wurde.
zu deiner zweiten bemerkung: da steht:
per button eine neue seite aufrufen,
deswegen ist die alte noch nicht weg, das erklärt auch meinen vorschlag des zugriffs per opener
opener gilt, wenn per Javascript ein Popup aufgemacht wird. Davon ist hier nicht die Rede gewesen. Wenn von einer Seite aus per Link oder Formularabschicken eine neue Seite aufgerufen wird, dann ist zuerst die alte Seite weg (schon bei onunload kann man nicht mehr auf die Seitenelemente zugreifen), und dann erst kommt die neue Seite.
Wäre es so einfach, wie du sagst: Warum macht man sich dann den Aufwand mit URL-Parametern?
wenn ich frames gemeint hätte, würde da auch sowas wie: top.frames[x] sthen...
das nächste mal bitte genauer lesen...
Ebenso!
- Sven Rautenberg
-
Hi Sven,
Stimmt nicht - gerade getestet! Man kann per GET abgeschickte
Formulare auch dann mit JS auswerten, wenn die Datei mit file://
aufgerufen wurde.sorry, aber ich kann Deiner Argumentation auch nicht folgen.
GET ist eine HTTP-Methode - und die findet nicht dort statt, wo
JavaScript auch nur das Geringste davon mitbekommen würde ...Grübelnde Grüße
Michael-
Aloha!
Stimmt nicht - gerade getestet! Man kann per GET abgeschickte
Formulare auch dann mit JS auswerten, wenn die Datei mit file://
aufgerufen wurde.sorry, aber ich kann Deiner Argumentation auch nicht folgen.
GET ist eine HTTP-Methode - und die findet nicht dort statt, wo
JavaScript auch nur das Geringste davon mitbekommen würde ...Aber der Erfolg gibt mir recht. :) (getestet in IE, Opera und Netscape 4)
Und das ist für mich auch ganz erklärlich. Denn was macht der Browser, wenn er ein GET-Formular abschicken will? Er nimmt den Inhalt des Formulars, codiert diese Daten ein wenig, nimmt die action-Angabe als neue URL (basierend auf der alten URL) und hängt hinter einem Fragezeichen die Formulardaten an.
Dann fordert er diese neue URL an. Und zwar wahlweise über das Protokoll http:// (sofern das Formular vom Server kommt), oder über das Protokoll file:// (wenn die Datei aus dem lokalen Dateisystem kommt).
Und in dieser Datei kann Javascript dann auf location.search zugreifen, weil Javascript auf die angezeigte URL zugreift, und nicht auf das, was irgendein Server mal gekriegt zu haben glaubt. Javascript kriegt ja garnicht mit, was der Server alles im GET-Request empfangen hat, denn der meldet es dem Browser nicht zurück. Der Javascript-Zugriff ist dadurch möglich, weil der Browser sich merkt, welchen URL-Parameter er gesendet hat.
Der Zugriff via file:// erfolgt ganz offenbar so, daß der Parameter schlicht ignoriert wird. Das gleiche passiert ja auch, wenn man HTML-Ressourcen vom Server anfordert, die mit dem Query-String nichts anfangen können. Es ist egal, ob ich eine "index.html" oder eine "index.html?param=23" anfordere - sofern das eine schlichte HTML-Datei ohne Programmlogik ist, wird das Ergebnis identisch sein.
Wers nicht glaubt, mache bitte den Test:
<html>
<head>
<title>Formtest</title>
<meta name="author" content="Sven Rautenberg">
<meta name="generator" content="Ulli Meybohms HTML EDITOR">
<link rel="stylesheet" href="screen.css" type="text/css" media="screen">
</head>
<body >
<form action="test.htm">
<input type="text" name="eintext">
</form>
<script type="text/javascript">
alert(location.search);
</script>
</body>
</html>Diese Datei lokal speichern und aufrufen. Es kommt ein leerer Alert. Dann etwas ins Textfeld schreiben und mit Return abschicken. Der Alert zeigt den URL-Parameter.
- Sven Rautenberg
-
Hallo,
ich kann deine Argumente nicht nachvollziehen...
du hast mich ganz unsicher gemacht, aber eben getestet:
<html>
<head>
<title>Formtest</title>
</head>
<body >
<form action="test.htm" method="get">
<input type="text" name="eintext">
<input type="submit" name="submit">
</form>
</body>
</html>1. diese seite lokal aufgerufen (ohne server)
das wort "inhalt" im textfeld abgeschickterhaltene URL:
..test.htm
.. bedeutet hier, dass ich den vorderen teil der url weggelassen hab...
2. die seite über meinen server aufgerufen
ansonsten alles gleich:
erhaltene URL:..test.htm?eintext=inhalt&submit=Anfrage+senden
also ein querystring ist vorhanden...
ich hatte auch mal im selfhtml gelesen, dass es nur bei aufruf über einen server funktioniert, ich finds aber grad nimmer...
also wenn du bei lokalem aufruf einen querystring erhältst muss das dein browser alleine machen (andere browser kann ich grad nicht testen... (das war IE)) oder du hast eben nicht lokal aufgerufen...
hier steht doch noch was zu get, leider nicht das was ich suchte, aber auch ganz ok
Selfhtml/cgiperl/intro/formularverarbeitung.htm#get_post:GET
In einem HTML-Formular erzwingen Sie diese Methode durch die Angabe von method="get" im einleitenden <form>-Tag. Bei dieser Angabe werden die ausgefüllten Formulardaten zuerst an die Server-Software übertragen und von dieser in einer bestimmten Umgebungsvariablen mit dem Namen QUERY_STRING zwischenspeichert.das ich in js einen querystring auch ohen server auswerten kann ist schon klar, denn könnte man ja auch manuell zusammenbauen, bei method="get" wird dieser automatisch angelegt...
Odium
-
Aloha!
- diese seite lokal aufgerufen (ohne server)
das wort "inhalt" im textfeld abgeschickt
erhaltene URL:
..test.htm
- die seite über meinen server aufgerufen
ansonsten alles gleich:
erhaltene URL:
..test.htm?eintext=inhalt&submit=Anfrage+senden
Mag sein, daß es bei deinem Browser nur über den Server funktioniert (siehe weiter unten). Allerdings würde ich nicht unbedingt der URL-Anzeige vertrauen, sondern nur dem, was location.search dir sagt.
ich hatte auch mal im selfhtml gelesen, dass es nur bei aufruf über einen server funktioniert, ich finds aber grad nimmer...
Du suchst das hier:
"Sie können bei action= auch eine HTML-Datei angeben. Diese wird bei Absenden des Formulars aufgerufen und kann die Formulardaten z.B. mit JavaScript weiterverarbeiten. Das ist beispielsweise für mehrseitige Formulare interessant. Berücksichtigen Sie dabei aber, dass JavaScript nur dann Zugriff auf Daten hat, wenn die Methode get verwendet wurde. Bei einigen Browsern, z.B. bei Opera, funktioniert das Übergeben von Formulardaten zwischen HTML-Dateien auch nur in HTTP-Umgebung, also nicht lokal ohne Serverkommunikation."Wie gesagt: Mein Opera (6), IE (5.0) und Netscape (4) haben es geschafft.
also wenn du bei lokalem aufruf einen querystring erhältst muss das dein browser alleine machen (andere browser kann ich grad nicht testen... (das war IE)) oder du hast eben nicht lokal aufgerufen...
Ich habe ganz sicher lokal aufgerufen.
hier steht doch noch was zu get, leider nicht das was ich suchte, aber auch ganz ok
Selfhtml/cgiperl/intro/formularverarbeitung.htm#get_post:Es ist doch aber so: HTTP kennt nur zwei Methoden, um eine Ressource anzufordern (neben diversen anderen Methoden, die etwas anderes erledigen): GET und POST.
Bei POST wird die URL des Scriptes mitgeschickt ("POST /script" - einfach mal in ein Logfile reingucken), und die Daten werden im Prinzip als eine Seite an den Request drangehängt. Sie reisen im Body des Requests mit, und da dieser Body im Prinzip beliebig lang sein darf, kann man mit POST megabytegroße Dateien zum Server schicken.
GET ist die normale Methode zum Anfordern einer Ressource. Alle Seiten werden mit GET geholt. Der URL-Parameter ist dabei absolut nichts besonderes, der ist eben mal nicht vorhanden, und mal doch. Es ist für den Server absolut kein Unterschied, ob der URL-Parameter nun in einem Link drinsteckt, oder ob die Daten aus einem Formular kommen. Die Vorgehensweise von Browser und Server (sobald der Link mit Parameter zusammengesetzt ist) ist immer gleich.
Jetzt kann man zweierlei sagen:
1. Da es egal ist, ob die Ressource inkl. Parameter aus einem Link oder einem Formular stammt, wird sich der Browser immer gleich verhalten - egal, ob er per HTTP eine Ressource aus dem Netz zieht, oder per file:// eine Datei aus dem Dateisystem.
2. Der einzige Verhaltensunterschied kann nur darin bestehen, daß der Browser bei file://-Zugriff grundsätzlich dem Javascript keinen Zugriff auf den Parameter (mit location.search) gibt. Dann dürfen aber weder Links noch Formulare funktionieren.
Ich gebe zu: Eine gewisse Unsicherheit, ob es denn wirklich funktioniert, beschleicht mit bei lokal getesteten Seiten immer. Ein Server reagiert mir da doch wesentlich beständiger, und Javascript ist IMO die vollkommen falsche Idee, um ein Formular oder einen Parameter-Link zu verarbeiten - jedenfalls dann, wenn Javascript eine wichtige Aufgabe zu erledigen hätte, und JS zwingend für den Zugriff ist.
- Sven Rautenberg
- diese seite lokal aufgerufen (ohne server)
-
-
-
-
-
-
-