Variable Formular-Action

[Andreas Vogt]

Hallo, ich habe ein Formular mit Textfelder, einer Checkbox und Submit Button. Jetzt möchte ich wenn die Checkbox geklickt wurde dass die Formularaction auf eine andere Datei zeigt. Ich denke das geht per Javascript? Das getElementByID bekomm ich schon hin, aber weiter weiss ich nicht.

Gruß Andreas

[hotti]

Hallo, ich habe ein Formular mit Textfelder, einer Checkbox und Submit Button. Jetzt möchte ich wenn die Checkbox geklickt wurde dass die Formularaction auf eine andere Datei zeigt.

Das action-Attribut zeigt nicht auf Dateien. Es möchte auf einen URL zeigen.

MfG

[Andreas Vogt]

Hallo

Das action-Attribut zeigt nicht auf Dateien. Es möchte auf einen URL zeigen.

Danke für die umfassende Antwort. Hat mir bei meiner Problemstellung sehr weitergeholfen.

Habs aber inzwischen selbst gelöst: <script type="text/javascript"> function changeAction(){ if(document.getElementById('chk1').checked){ document.getElementById('form1').action='Test2.html'; } else { document.getElementById('form1').action='Test1.html'; } } </script>

Gruß Andreas

[Felix Riesterer]

Lieber Andreas Vogt,

Deine Lösung ist vom funktionalen Design her nicht gut. Ein Formular wird von einem server-seitigen Script ausgewertet. Dazu übermittelt es Parameter. Warum sollte nun plötzlich ein anderes Script die Parameter auswerten, nur weil Du eine Checkbox aktiviert hast?

function changeAction(){

Es ist gut, dass Du die Funktionalität in eine Funktion kapselst.

  if(document.getElementById('chk1').checked){
  	document.getElementById('form1').action='Test2.html';
  } else {
  	document.getElementById('form1').action='Test1.html';
  }

Warum nicht so:

var url = "Test1.html";

if (document.getElementById('chk1').checked) {
    url = "Test2.html";
}

document.getElementById('form1').action = url;

Liebe Grüße,

Felix Riesterer.

[Andreas Vogt]

Hallo, danke für die Tipps, werde ich umsetzen.

Gruß Andreas

[Der Martin]

Hallo,

Warum nicht so:

var url = "Test1.html";

> 
> if (document.getElementById('chk1').checked) {
>     url = "Test2.html";
> }
> 
> document.getElementById('form1').action = url;

weil das eigentlich ein Paradebeispiel für den ternären Operator wäre:

document.getElementById('form1').action
  = document.getElementById('chk1').checked
  ? "Test2.html"
  : "Test1.html";

Ciao,  Martin

[Felix Riesterer]

Lieber hotti,

Das action-Attribut zeigt nicht auf Dateien. Es möchte auf einen URL zeigen.

will jetzt auch einmal Korinthen ......: Das action-Attribut zeigt mit seinem Wert (ein URL) auf eine Resource, welche die Formulardaten verarbeiten soll.

Man kann aber auch ein Formular zu Navigationszwecken "missbrauchen", wenn man das will und dazu auch JavaScript einsetzt.

Liebe Grüße,

Felix Riesterer.

[hotti]

Lieber Felix,

Das action-Attribut zeigt nicht auf Dateien. Es möchte auf einen URL zeigen.

will jetzt auch einmal Korinthen ......: Das action-Attribut zeigt mit seinem Wert (ein URL) auf eine Resource, welche die Formulardaten verarbeiten soll.

Eigentlich bin ich eher dafür, das action-Attribut einfach wegzulassen. Dann ist endlich Schluss mit dieser Korinthenkackerei ;)

Man kann aber auch ein Formular zu Navigationszwecken "missbrauchen", wenn man das will und dazu auch JavaScript einsetzt.

Stimmt. Warum nicht gleich alles mit JavaScript machen, da brauchen wir auch keine Formulare mehr. Tscheckboxn und Eingabefelder, evntl. contenteditable lassen sich wunderbar im Text verteilen und zwischendrin ein Speichern-Knöpfchen schadet auch nicht, solange der Delinquent beim Draufdrücken oder Reinziehen von Dateien nicht flüchtet. Am Besten die Eingaben gleich speichern beim KeyUp oder Klick, dann brauchen wir auch das Speichern-Knöpfchen nicht. Wir brauchen dann nur noch ein Eingaben-Senden Button, der ganz unten sichtbar wird, wenn alles richtisch eingegeben wurde.

Bis dahin kann ja der Browser die Daten speichern. Auf gehts ;)

Schöne Grüße.

[Robert R.]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

wozu überhaupt noch Buttons o. ä.? Einfach alle Tastatureingaben mitschneiden und beim kleinstmöglichen Anlass eine Willenserklärung daraus ableiten.

Vertrag geschlossen, User bekannt, Konto plündern, Ende Gelände...

Spirituelle Grüße Euer Robert

[1UnitedPower]

Hakuna matata!

Man kann aber auch ein Formular zu Navigationszwecken "missbrauchen", wenn man das will und dazu auch JavaScript einsetzt.

Stimmt. Warum nicht gleich alles mit JavaScript machen, da brauchen wir auch keine Formulare mehr.

Formulare braucht man so oder so. Sie sind ein Einstiegspunkt für wichtige JavaScript-APIs wie FormData und Constraint-Validation.

Wir brauchen dann nur noch ein Eingaben-Senden Button, der ganz unten sichtbar wird, wenn alles richtisch eingegeben wurde.

Der Button sollte unbedingt die ganze Zeit über sichtbar sein, und auch aktiv sein. Beim Klick auf den Absendebutton wird nämlich das Formular auf Gültigkeit geprüft und dem Nutzer (insbesondere Nutzer von assstiver Software) ein Feedback mitgeteilt.

Bis dahin kann ja der Browser die Daten speichern. Auf gehts ;)

Macht er doch – im DOM.

JavaScript sollte das Benutzererlebnis verbessern und nicht auch noch erschweren. http://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript

[hotti]

Hakuna matata!

Formulare braucht man so oder so. Sie sind ein Einstiegspunkt für wichtige JavaScript-APIs wie FormData

FormData brauchn'mer auch nicht. Viel zu umständlich.

Bis dahin kann ja der Browser die Daten speichern. Auf gehts ;)

Macht er doch – im DOM.

Besser: In einem Objekt. Dann müssen wir vor dem Absenden nicht alles im DOM zusammensuchen, sondern nur noch das Objekt serialisieren. Von mir aus'n JSON oder XML. Oder'n Blob wenn Fotos dabei sind.

Parameter? Brauchen wir auch nicht. Die Default-Request-Method vom XHR-Objekt ist PUT:

xhr.open("", "", true);

macht ein PUT.

xhr.send("serialisiertes Objekt");

Sendet die Daten, die finden sich dann serverseitig in STDIN. XML, JSON, Blob, wo Du wolle. Daraus stellen wir das Objekt wieder her. Was mit den Daten gemacht werden soll, steht da auch drin. Natürlich nicht der Code, selber schuld, wer das tut.

JavaScript sollte das Benutzererlebnis verbessern und nicht auch noch erschweren. http://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript

Jaja, schon gut. Frauen wollen Schuhe, Politiker wollen geile Fotos.

Schöne Grüße.

[1UnitedPower]

Hakuna matata!

Formulare braucht man so oder so. Sie sind ein Einstiegspunkt für wichtige JavaScript-APIs wie FormData

FormData brauchn'mer auch nicht. Viel zu umständlich.

Bis dahin kann ja der Browser die Daten speichern. Auf gehts ;)

Macht er doch – im DOM.

Besser: In einem Objekt. Dann müssen wir vor dem Absenden nicht alles im DOM zusammensuchen, sondern nur noch das Objekt serialisieren.

Wenn es da doch nur irgendwas vorgefertigtes gäbe… lass mal überlegen… FormData vielleicht?

[hotti]

Hakuna matata!

Wenn es da doch nur irgendwas vorgefertigtes gäbe… lass mal überlegen… FormData vielleicht?

Na klar. FormData kannst du auch nehmen, da wirds halt ein POST:

xhr.open("POST", "", true); xhr.send(my_form_data_object);

Aber: FormData kennt nur Schlüssel-Werte-Paare, allenfalls bei mehreren gleichnamigen Parametern entsteht serverseitig ein Array. Die Daten sind nicht weiter strukturiert, sie sind nur aneinandergehängt.

Wenn Du z.B. einem Bild eine Beschreibung und einen Titel hinzufügen willst, werden das weitere Parameter, die in keiner Beziehung zum Bild stehen, das kannst Du nur infolge einer Vereinbarung der Parameternamen festlegen.

Kompakter wäre sowas:

REQUEST = {
   cv => {
     bin:    ArrayBuffer,
     type: 'application/pdf',
     title: 'Lebenslauf',
     descr: 'Eine glückliche Jugend im Zeichen der Technik'
   },
   person: {
     name:  String,
     vname: String,
     pp:    Blob,
     type:  'image/jpeg'
   },
   addr: {},
   control: {
     register: 1
   }
   // usw.
}

Und das geht eben nicht mit FormData. Beachte den Schlüssel 'control', da steht drin, was mit den im Objekt gesendeten Daten serverseitig gemacht werden soll. Solche Strukturen schaffen Transparenz, das Objekt hast Du quasi 1:1 client- wie serverseitig. Transparenz: Die Übertragung, der Transport ist durchsichtig. Es lohnt sich, darüber nachzudenken, weil es die Sache letztendlich sehr einfach und skalierbar macht. Was fehlt, sind kompatible Serializer, für oben gezeigte Objekt-Stuktur habe ich mir einen entwickelt, der damit erzeugte Dateien zwischen Perl und JavaScript kompatibel macht. Funktionierende Beispiele gibts auf meiner Site.

Schönes Wochenende.

[hotti]

Hakuna matata!

Wenn es da doch nur irgendwas vorgefertigtes gäbe… lass mal überlegen… FormData vielleicht?

Na klar. FormData kannst du auch nehmen, da wirds halt ein POST:

xhr.open("POST", "", true); xhr.send(my_form_data_object);

Aber: FormData kennt nur Schlüssel-Werte-Paare, allenfalls bei mehreren gleichnamigen Parametern entsteht serverseitig ein Array. Die Daten sind nicht weiter strukturiert, sie sind nur aneinandergehängt.

Wenn Du z.B. einem Bild eine Beschreibung und einen Titel hinzufügen willst, werden das weitere Parameter, die in keiner Beziehung zum Bild stehen, das kannst Du nur infolge einer Vereinbarung der Parameternamen festlegen.

Kompakter wäre sowas:

> REQUEST = {
>    cv => {
>      bin:    ArrayBuffer,
>      type: 'application/pdf',
>      title: 'Lebenslauf',
>      descr: 'Eine glückliche Jugend im Zeichen der Technik'
>    },
>    person: {
>      name:  String,
>      vname: String,
>      pp:    Blob,
>      type:  'image/jpeg'
>    },
>    addr: {},
>    control: {
>      register: 1
>    }
>    // usw.
> }
> 

Und das geht eben nicht mit FormData. Beachte den Schlüssel 'control', da steht drin, was mit den im Objekt gesendeten Daten serverseitig gemacht werden soll. Solche Strukturen schaffen Transparenz, das Objekt hast Du quasi 1:1 client- wie serverseitig. Transparenz: Die Übertragung, der Transport ist durchsichtig. Es lohnt sich, darüber nachzudenken, weil es die Sache letztendlich sehr einfach und skalierbar macht. Was fehlt, sind kompatible Serializer, für oben gezeigte Objekt-Stuktur habe ich mir einen entwickelt, der damit erzeugte Dateien zwischen Perl und JavaScript kompatibel macht. Funktionierende Beispiele gibts auf meiner Site.

Schönes Wochenende.

[hotti]

PS: Lass dich nicht verwirren von den Datentypen ArrayBuffer, Blob, String usw.. Wenn das serverseitig ankommt, sind das nur noch Bytes.

[1UnitedPower]

Hakuna matata!

PS: Lass dich nicht verwirren von den Datentypen ArrayBuffer, Blob, String usw.. Wenn das serverseitig ankommt, sind das nur noch Bytes.

Du wolltest in deinem Codebeispiel ArrayBuffer bestimmt nicht Am Anfang groß schreiben, denn dann erhälst du auf dem Server nur die Zeichenkette: "function ArrayBuffer() { [native code] }"

[hotti]

Hakuna matata!

PS: Lass dich nicht verwirren von den Datentypen ArrayBuffer, Blob, String usw.. Wenn das serverseitig ankommt, sind das nur noch Bytes.

Du wolltest in deinem Codebeispiel ArrayBuffer bestimmt nicht Am Anfang groß schreiben, denn dann erhälst du auf dem Server nur die Zeichenkette: "function ArrayBuffer() { [native code] }"

Selber schuld, wenn Du das Beispiel einfach nur kopierst ;)

Btw., die Idee, mehr Struktur in die Parameterliste zu bringen ist nicht neu und das funktioniert auch mit FormData:

fd.append('addr.name', 'Hesselbach'); fd.append('addr.vname', 'Horst'); fd.append('addr.portrait', file[0]);

in PHP fest verdrahtet als addr[name], addr[vname], addr[portrait] und beachte, dass PHP im Fall addr.name den Punkt leise, still, heimlich und unbemerkt in einen Unterstrich addr_name verwandelt, solltest Du in die Versuchung kommen, was Eigenes bauen zu wollen. Es ist nur so, dass der serverseitige Parser beim enctype="multipart/form-data" einiges zu tun hat, auch dann, wenn Du es nicht selbst programmierst (splitten an der boundary, temporäre Dateien anlegen). Und dann ist POST immer noch ein Request mit Parametern, wass ggf. weitere unliebsame Abhängigkeiten mit sich bringen kann (je nach Framework). Ein PUT ist wesentlich einfacher in der Handhabe, das ist völlig frei von Parametern.

Dass PHP bei einem PUT oder POST (oder anderen beliebigen Request-Methoden) auch im $_GET Array Daten liefert, betrachte ich als eine fehlerhafte Implementierung einschlägiger RFCs betreff HTTP. Und ja, eigene Request Methoden wie FOO, BAR usw. sind durchaus möglich und funktional, es wird jedoch im Allgemeinen davon abgeraten.

MfG

[1UnitedPower]

Hakuna matata!

Aber: FormData kennt nur Schlüssel-Werte-Paare

In der Weiterverarbeitung kann daraus auch eine andere Datenstruktur abgeleitet werden, so wie es der application/json-Formularkodierungs-Algorithmus macht: Der nimmt sich ein FormData-Objekt und transformiert das in ein potenziell tief verschachteltes JSON-Objekt. Das ist lediglich eine weitere Abstraktionsschicht oben drauf. So erzielt man eine saubere Trennung der Verantwortlichkeiten. Die untere Schicht kann man sorglos für andere Kodierungs-Algorithmen wiederverwenden, so wird es ja auch gemacht: Für application/x-www-form-urlencoded, für multipart/formdata und für text/plain.

Bei deinem alternativen Entwurf kann ich keine so klare Strukturierung erkennen.

[hotti]

Hakuna matata!

Bei deinem alternativen Entwurf kann ich keine so klare Strukturierung erkennen.

Meine Datenstruktur entspricht dem Muster Entity Attribute Value. Ein Programmierer sollte sowas schon erkennen können ;)

MfG

[Felix Riesterer]

Lieber Andreas Vogt,

Jetzt möchte ich wenn die Checkbox geklickt wurde dass die Formularaction auf eine andere Datei zeigt.

warum? Täte es nicht auch ein anderes Formular, oder zumindest eine andere Gestaltung, dass Du wenigestens zwei verschiedene Submit-Buttons hast?

Ich denke das geht per Javascript? Das getElementByID bekomm ich schon hin, aber weiter weiss ich nicht.

Eine solche Lösung wäre ohne aktiviertes JavaScript nicht sinnvoll benutzbar und von daher zu verwerfen. Es ist meiner Meinung nach OK ein Formular mit JavaScript in seiner Funktionalität so umzugestalten, dass die Bedienung bequemer wird - aber ohne JS muss es zwingend benutzbar bleiben, es sei denn, man kommt ohne JavaScript erst gar nicht zum Formular.

Mit JavaScript kannst Du den Wert des action-Attributs verändern:

function changeAction (formID, URL) {
    var myForm = document.getElementById(formID);

    if (myForm) {
        myForm.action = "http://example.com/result.php";
    }
}

changeAction("die-ID-meines-Form-Elements", "http://example.com/result.php");

Liebe Grüße,

Felix Riesterer.

[Matthias Apsel]

Om nah hoo pez nyeetz, Andreas Vogt!

Hallo, ich habe ein Formular mit Textfelder, einer Checkbox und Submit Button. Jetzt möchte ich wenn die Checkbox geklickt wurde dass die Formularaction auf eine andere Datei zeigt.

Dafür gibt es seit HTML5 mehrere Möglichkeiten ohne JavaScript. Siehe Formulare absenden, formaction

Matthias

[Robert R.]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Dafür gibt es seit HTML5 mehrere Möglichkeiten ohne JavaScript. Siehe Formulare absenden, formaction

Tut mir leid. Steige ich nicht mehr durch. Die Klarheit des guten alten SelfHTML ist da nicht wiederzufinden.

Wenn der Widerwille, hier nochmal etwas vernünftig zu erklären, anhält, werde ich mir wohl einen anderen Erklärbär suchen müssen. Schade!

Spirituelle Grüße Euer Robert

[Matthias Apsel]

Om nah hoo pez nyeetz, Robert R.!

Tut mir leid. Steige ich nicht mehr durch. Die Klarheit des guten alten SelfHTML ist da nicht wiederzufinden.

Was aber nicht an SELFHTML liegt, sondern daran, dass die Dinge halt komplexer sind.

Wenn der Widerwille, hier nochmal etwas vernünftig zu erklären, anhält, werde ich mir wohl einen anderen Erklärbär suchen müssen. Schade!

Ich kann in meiner Antwort auch keinen Widerwillen erkennen. Ebenso nicht im verlinkten Artikel.

• Jedes Formular darf mehrere Submit-Buttons haben.
• Jeder Submit-Button darf dabei die Vorgaben des Formulars hinsichtlich des action-Attributes überschreiben.

Das ist, denke ich, im verlinkten Wiki-Artikel gut dargestellt.

Matthias

[hotti]

hi,

Das ist, denke ich, im verlinkten Wiki-Artikel gut dargestellt.

Isses auch!

Schöne Grüße.