nicht angemeldet
Auge
Auge
TS
Rolf B
tk
Rolf B
Matthias Scharwies
TS
Matthias Scharwies
Gunnar Bittersmann
TS
TS
Hallo Leute,
kann man in HTML, ohne JavaScript zu verwenden, das Action-Attribut in einem <form> noch ändern, bevor das Form abgeschickt wird?
Vielleicht sehe ich nur den Wald nicht mehr?
Ist ja auch kaum noch welcher da :-(
JürgenB<form action="url?param=1234#anker" method="POST">
<select ...>
<option value="1234">Datei 1234</option>
<option value="5678">Datei 5678</option>
...
</select>
<button name="send" value="show"
type="submit">Zeig es mir!</button>
<form>
Wenn jetzt 5678 ausgewählt wurde, soll sich das Action-Attribut entsprechend ändern.
Das Form soll auf jeden Fall per POST abgeschickt werden, weil in der neuen URL außer dem Query-String nebst Anker nur der Param erscheinen soll. Schickt man das Form nun per GET ab, erscheint auch der Button in der URL. Oder kann man das vermeiden?
am liebsten würde ich das neue Action-Attribut erst nach dem erfolgten <Select> erstellen.
Im Background läuft PHP. Damit werden auch die <form> und die <select> Elemente erzeugt.
Es gibt auch noch mehr Auswahlmöglichkeiten per POST, die aber nicht in der URL erscheinen dürfen, was GET ausschließt.
Dank PHP wären also eventuell auch noch mehr Manipulationen möglich.
Freue mich auf Response
Robert
Hallo
kann man in HTML, ohne JavaScript zu verwenden, das Action-Attribut in einem
<form>noch ändern, bevor das Form abgeschickt wird?
Nein.
<form action="url?param=1234#anker" method="POST"> <select ...> <option value="1234">Datei 1234</option> <option value="5678">Datei 5678</option> ... </select> <button name="send" value="show" type="submit">Zeig es mir!</button> <form>Wenn jetzt
5678ausgewählt wurde, soll sich das Action-Attribut entsprechend ändern.
Wie geschrieben, geht das nicht ohne JS und für den Fall, dass das JS-Skript nicht funktioniert, würde auch die Änderung des Ziels unterbleiben.
am liebsten würde ich das neue Action-Attribut erst nach dem erfolgten
<Select>erstellen.
Im Background läuft PHP.
Warum soll das überhaupt passieren? Vielleicht muss das, je nach konkretem Szenario, nicht geschehen. Du kannst im Ziel des Formulars (bei dir wohl ein PHP-Skript) anhand der übermittelten Werte schließlich auch innerhalb dieses Skripts in verschiedene Verarbeitungsprozesse verzweigen.
Tschö, Auge
Hallo Auge,
Warum soll das überhaupt passieren?
Das hatte ich geschrieben: Dem User soll eine gültige URL mit nur einem GET-Parameter nebst Fragment (Anker) passend zur aktuell dargestellten Seite angezeigt werden, aber nicht mehr.
Das Programm reagiert sowohl auf GET, als auch auf POST. Mit POST kann es mehr, aber nur mit Anmeldung. Diese Möglichkeiten dürfen aber nicht in der URL erscheinen.
Vielleicht muss das, je nach konkretem Szenario, nicht geschehen. Du kannst im Ziel des Formulars (bei dir wohl ein PHP-Skript) anhand der übermittelten Werte schließlich auch innerhalb dieses Skripts in verschiedene Verarbeitungsprozesse verzweigen.
Das wird auch so umgesetzt.
Aber die angezeigte neue URL soll per GET verwendbar sein.
Um die zu erzeugen, muss aber erst das Select durchgeführt werden. Dafür benötigt man aber, soweit ich weiß, das `<form>-Element.
Oder kann ich eine Auswahl aus einem <select> auch ohne '<form>` und ohne JavaScript an den Server übertragen?
Ich sag ja: Ich - Wald :-|
Grüße RR
Hallo
Warum soll das überhaupt passieren?
Das hatte ich geschrieben: Dem User soll eine gültige URL mit nur einem GET-Parameter nebst Fragment (Anker) passend zur aktuell dargestellten Seite angezeigt werden, aber nicht mehr.
Welche Seite ist mit „aktuell dargestellte[…] Seite“ gemeint? Die, in der sich das Formular befindet oder die, die nach dem absenden des Formulars aufgerufen wird?
Vielleicht muss das, je nach konkretem Szenario, nicht geschehen.
Das wird auch so umgesetzt.
Aber die angezeigte neue URL soll per GET verwendbar sein.
Die neue URL wird doch erst dann angezeigt, wenn die verarbeitung der Formulareingaben beendet und die dabei ermittelte Seite zurückgesendet wird, oder? Dann kannst du nämlich auch per PHP auf die ergebnisseite weiterleiten und dabei die Bestandteile der URL im Action-Attribut auswerten und dem Aufruf beifügen.
Um die zu erzeugen, muss aber erst das Select durchgeführt werden. Dafür benötigt man aber, soweit ich weiß, das `<form>-Element.
Du willst doch nicht etwa mittels dieses Formulars eine Navigation nachbauen?
Oder kann ich eine Auswahl aus einem
<select>auch ohne '<form>` und ohne JavaScript an den Server übertragen?
Nein. Du kannst zwar Formularelemente wild in einem Dokument verteilen, aber wenn sie auf die HTML-eigene Art an den Server gesendet werden sollen, bedürfen sie des Action-Attributs eines Formulars.
Tschö, Auge
Hello Robert,
freut mich, von Dir zu lesen. Ruf doch mal an. Meine Nr ist noch die alte.
Die Aufgabe habe ich schon mal gelöst (15 Jahre her, oder länger). Da gibt es in PHP sowas wie html_build_url() oder ähnlich.
Und um das POST/GET-Problem zu knacken hilft nur ein Roundturn mit header('location: ' . $new_url ) im POST-Zweig des Request-Routers.
Dann kommt zwar als POST-Respone noch kurz die alte URL wieder beim Client an, aber mit dem Wunsch, die neue per GET neu aufzurufen, was seit ca. 2007 bei meinen Kandidaten immer fehlerfrei funktioniert hat.
Und es funktioniert ohne JavaScript!
Glück Auf
Tom vom Berg
Hallo RR,
was du bräuchtest, wäre eine Festlegung des Übertragungsweges pro Form-Element. Also GET-Parameter für das select-Element und POST-Parameter für andere.
Es gibt zwar ein formmethod-Attribut, das man auf Form-Elementen setzen kann, aber das ist nur dafür gedacht, auf einem Submit-Button das method-Attribut des Form zu überschreiben. Man kann damit nicht pro Form-Element festlegen, ob es als Content oder in der URL gesendet werden soll.
Es ist ohnehin angebracht, bei einen POST-Request die Daten zwar serverseitig zu verarbeiten, aber dann mit einem Redirect auf die Seite zu antworten, die das Ergebnis anzeigt. Eine direkte Anzeige des Ergebnisses ist keine gute Praxis. Und zwar deshalb, weil der Anwender sonst zu schnell mit dem "Zurück" Button des Browsers auf das Formular zurückkommen und ggf. doppelt senden kann. Beim Erzeugen dieses Redirects kannst Du dann, so wie schon vorgeschlagen, die URL nach Bedarf aufhübschen.
Die Alternative ist JavaScript. Du müsstest den Wert des Select-Elements in den Action-Parameter übertragen, wenn das Element sich ändert. Das ist relativ trivial zu machen, aber ich denke, es ist nicht der ideale Weg.
Rolf
Moin,
Das Form soll auf jeden Fall per POST abgeschickt werden, weil in der neuen URL außer dem Query-String nebst Anker nur der Param erscheinen soll. Schickt man das Form nun per GET ab, erscheint auch der Button in der URL. Oder kann man das vermeiden?
Ja, lass das name-Attribut vom Button einfach weg. Wenn das Formular nur das Select samt Button enthält, kannst du das gewünschte Verhalten durch Umstellen auf method="get" erreichen.
Gruß
Tobias
Moin Tobias,
Das Form soll auf jeden Fall per POST abgeschickt werden, weil in der neuen URL außer dem Query-String nebst Anker nur der Param erscheinen soll. Schickt man das Form nun per GET ab, erscheint auch der Button in der URL. Oder kann man das vermeiden?
Ja, lass das name-Attribut vom Button einfach weg. Wenn das Formular nur das Select samt Button enthält, kannst du das gewünschte Verhalten durch Umstellen auf method="get" erreichen.
Checke ich gleich auch noch.
Die Idee mit dem POST und redirect mittels header() gefällt mir aber auch gut.
LG
RR
Hallo Wikischreiber,
für <select> fand ich in eurem Wiki übrigens nur ca. 1/4 der benöigten Infos.
Oder habe ich die nötigen Links übersehen?
Nix für Ungut. Aber ein bis drei Beispiele für das Zusammenspiel mit dem Server-Backend, zum Beispiel in PHP, wären schon hilfreich.
Ich habe mir da zwar jetzt was gebalstelt, aber ob das so gut ist, weiß nur der Requestteufel.
LG RR
Hallo RR,
also multiple, value und selected finde ich hier im Tutorial-Teil.
Im Referenzteil steht unter <select> multiple und unter <option> selected und value.
Wo hast Du geschaut?
Die PHP-Interaktion ist eine andere Sache, aber letztlich kommt der Wert von <select name="foo"> in PHP unter $_POST['foo'] an. Bei einem Select mit multiple-Option sagen Dir die Developer Tools deines Vertrauens, dass das im Content des Requests so aussieht:
foo=b&foo=c&foo=d
was in PHP dazu führt, dass Du nur das d siehst. Es ist daher notwendig, in diesem Fall <select name="foo[]"> zu schreiben, damit in $_POST['foo'] ein Array erscheint.
Aber das ist PHP, nicht HTML, und daher nicht so GANZ unsere Expertise. Trotzdem haben wir noch ein As im Ärmel…
Rolf
Hallo Rolf,
also multiple, value und selected finde ich hier im Tutorial-Teil.
Ich hatte schon vermutet, dass ich es einfach nicht gefunden habe.
Die Suche im Wiki brachte mich nur zu Elemente/Select und dort war die Beschreibung so dürftig, dass ich gleich wieder die Suchmaschinen bzw. die Moz-Doku bemüht habe.
Aber auch dort fand ich keine Praxilösung zu meiner Frage.
Früher hat man die Selfhtml-Doku aufgerufen, weil man dort kurze, knappe Antworten auf die Anwendungsfragen gefunden hat. Das Forum hat dann ungeheuer viele weitere Anregungen und Hacks vermittelt.
Das fehlt mir heute.
Ich wüsste aber auch nicht, wie man das in unserer heutigen Desinformationskultur besser aufziehen könnte.
Im Wiki könnten vielleicht mehr repräsentative Querverweise helfen, damit ich in Zukunft die Informationen selber finden kann. :-)
LG
Robert
Servus!
Die Suche im Wiki brachte mich nur zu Elemente/Select und dort war die Beschreibung so dürftig, dass ich gleich wieder die Suchmaschinen bzw. die Moz-Doku bemüht habe.
Aber auch dort fand ich keine Praxilösung zu meiner Frage.
Früher hat man die Selfhtml-Doku aufgerufen, weil man dort kurze, knappe Antworten auf die Anwendungsfragen gefunden hat. Das Forum hat dann ungeheuer viele weitere Anregungen und Hacks vermittelt.
Das fehlt mir heute.
Ich wüsste aber auch nicht, wie man das in unserer heutigen Desinformationskultur besser aufziehen könnte.
Screenshot der von dir aufgerufenen Seite:
Im Wiki könnten vielleicht mehr repräsentative Querverweise helfen, damit ich in Zukunft die Informationen selber finden kann. :-)
Sag uns bitte, wie wir das besser machen können.
Herzliche Grüße
Matthias Scharwies
Hello Matthias,
ich habe mir das auch angeschaut und war über den Einstieg:
selfHTML→wiki->suche->"select"
auf die Element-Seite von <select> gestoßen. Die hat mir leider auch keine intiale Erkenntnis gebracht, obwohl ich mich damit bereits seit über 15 Jahren beschäftigt habe. Der Blick auf die Links war mir auch nicht aufgefallen.
Mein Vorschlag wäre deshalb, mit dem großen Hammer zu beginnen in der ersten Darstellung, in dem dann die diversen Spielarten dieses Elementes farblich gekennzeichnet werden und dann nach und nach einzeln erläutert werden.
Man würde dann auf Anhieb sehen können, was alles geht, auch wenn man es (noch) nicht versteht, in der Sicherheit, dass es dann erklärt wird.
Unser momentaner Weg, erst einmal nur die minimalistischste Lösung darzustellen, und dann aufzubauen, ist vermutlich heutzutage publizistisch nicht mehr zielführend.
Ich bin jetzt bei der Projektidee "Messen und Anzeigen" mit Raspi, Linux, Apache, Python, PHP, HTML, CSS, SVG, usw. übrigens beim ca. fünfzehnten Zwischenschritt angekommen, und würde gerne wissen, ob noch das Interesse besteht, daraus einen Fach-Artikel zu machen?!
Die ganze SVG-Arie hierzu fehlt noch.
Und weitere Sicherheitsgschichten bitte per Telefon.
Glück Auf
Tom vom Berg
Hallo TS,
das Problem scheint mir zu sein, dass die Suche nach Select auf die Referenzseite zum Select-Element führt, und dass weder RR noch Du auf die Idee kamen, unter dem "Siehe Auch" Link "Auswahllisten" ein Tutorial mit ausführlicheren Erklärungen zu suchen.
Aber genau der ist doch eigentlich das, wonach ihr sucht. Es gibt Beispiele für Select ohne und mit multiple, es gibt eine Diskussion, warum für PHP im Name-Attribut [] stehen sollte.
/wiki/select ist eine Redirect-Seite. Man könnte
Wäre das hilfreich? Müsste man generell stärker zu Beginn von Artikeln Querverweise anbieten, um falsch abgebogene Sucher zu unterstützen? Meine Sorge ist, dass Einsteiger damit überfordert sind.
Rolf
Hello,
das Problem scheint mir zu sein, dass die Suche nach Select auf die Referenzseite zum Select-Element führt, und dass weder RR noch Du auf die Idee kamen, unter dem "Siehe Auch" Link "Auswahllisten" ein Tutorial mit ausführlicheren Erklärungen zu suchen.
Genau das wird das Problem sein.
Das werden dann aber auch bis zu 90% der übrigen Bensucher haben. Die meisten, die bei uns gucken, werden doch schon eine Grunderfahrung haben, und wollen durch unsere Darstellung nicht in ihrem Erfahrngsschatz zurückgestuft werden, sondern neue Inspeirationen gewinnen.
Versuche also doch bitte mal, dich in den Zustand eines 1/3-Wissenden mit Dunning-Kruger-Syndrom zu versetzen.
Schließlich sind wir doch alle "Spezialisten", bis wir behutsam zur Erleuchtung gebracht worden sind :-)
Glück Auf
Tom vom Berg
Hallo TS,
und welcher der 4 Lösungsansätze scheint dir der bessere? Hat du einen anderen?
Alles neu zu machen wird jedenfalls wedern realistisch noch nötig sein.
Rolf
Guten Morgen,
Projekt
Ich bin jetzt bei der Projektidee "Messen und Anzeigen" mit Raspi, Linux, Apache, Python, PHP, HTML, CSS, SVG, usw. übrigens beim ca. fünfzehnten Zwischenschritt angekommen, und würde gerne wissen, ob noch das Interesse besteht, daraus einen Fach-Artikel zu machen?!
Ja, natürlich!
EVA-Prinizp
Raspi, Linux, Apache
Wenn das (https://wiki-test.selfhtml.org/wiki/Raspberry) fertiggestellt wäre, könnte man im neuen Fach-Artikel damit anfangen, was du an den Raspi angeflanscht hat und was und wie du misst. (Eingabe)
Python, PHP,
Code-Beispiele, was in der Verarbeitung der Daten passiert.
HTML, CSS,
Ausgabe mit HTML → große, unübersichtliche Tabelle
Deshalb -> Datenvisualisierung
Die ganze SVG-Arie hierzu fehlt noch.
Da gibt es bereits: SVG/Tutorials/Datenvisualisierung
Das erste Kapitel ist leider noch nicht fertig.
Du benötigst wsl. Diagramme wie im 2. Kapitel oder etwas ganz neues. Was schwebt dir denn vor?
Herzliche Grüße
Matthias Scharwies
PS: Zu dem Thema Datenvisualisierung würden dann auch Linuchs', bzw. Franzsens Suche nach einem Stammbaum, bzw. Organigramm passen.
Hallo zusammen,
Da gibt es bereits: SVG/Tutorials/Datenvisualisierung
Das erste Kapitel ist leider noch nicht fertig.
Du benötigst wsl. Diagramme wie im 2. Kapitel oder etwas ganz neues. Was schwebt dir denn vor?
es gibt für Diagramme auch schon eine fertige Lösung mit automatischer Skalierung und Achsenbeschriftung: https://wiki.selfhtml.org/wiki/SVG/Tutorials/Funktionsplotter
Gruß
Jürgen
Servus!
Hallo zusammen,
Da gibt es bereits: SVG/Tutorials/Datenvisualisierung
Das erste Kapitel ist leider noch nicht fertig.
Du benötigst wsl. Diagramme wie im 2. Kapitel oder etwas ganz neues. Was schwebt dir denn vor?
es gibt für Diagramme auch schon eine fertige Lösung mit automatischer Skalierung und Achsenbeschriftung: https://wiki.selfhtml.org/wiki/SVG/Tutorials/Funktionsplotter
Stimmt - den hab' ich unterschlagen! Sorry! (Ich wollte den damals nicht gleich in SVG/Tutorials/Datenvisualiserung/... verschieben. Evtl. sollte man alles unter Datenvisualisierung einordnen und auf SVG + Tutorials nur über die Kategorien verlinken. Müsste man mal auf einem Live-Treffen in Ruhe bereden!)
Herzliche Grüße
Matthias Scharwies
Servus!
Hallo Wikischreiber,
für
<select>fand ich in eurem Wiki übrigens nur ca. 1/4 der benöigten Infos.
Oder habe ich die nötigen Links übersehen?
- Option Value
- Select Multiple
- Selected
Nix für Ungut. Aber ein bis drei Beispiele für das Zusammenspiel mit dem Server-Backend, zum Beispiel in PHP, wären schon hilfreich.
Du hast Dir grad ein <I> gekauft! 😀
Ich habe mir da zwar jetzt was gebalstelt, aber ob das so gut ist, weiß nur der Requestteufel.
Kannst ja testen und berichten!
Herzliche Grüße
Matthias Scharwies
@@RR
für
<select>fand ich in eurem Wiki übrigens nur ca. 1/4 der benöigten Infos.
- Select Multiple
Das Einzige, was es dazu zu sagen gibt, ist, dass man es nicht verwenden sollte.
🖖 Живіть довго і процвітайте
Hello Robert,
dank deines Anstoßes bin ich heute auch nochmal motiviert worden, in meinem kleinen Projekt weiter zu machen.
Ist das ungefähr das, was Du erreichen wolltest?
Glück Auf
Tom vom Berg
Hello Robert,
dank deines Anstoßes bin ich heute auch nochmal motiviert worden, in meinem kleinen Projekt weiter zu machen.
Ist das ungefähr das, was Du erreichen wolltest?
Da waren noch so viele kleine Fehler drin...
Mit der Fehlerbehandlung und -Suche in PHP ab 7.x stehe ich immer noch auf Kriegsfuß. Auch im Errorlog erscheinen nicht mehr die gewohnten Meldungen, sondern eine aufgeblähte Zeile mit viel Driss und wenig sinnvoller Info.
Aber nun sollte es laufen, inclusive Validator-Green-Light.
Glück Auf
Tom vom Berg