abzuschickende Werte einer <form> auflisten

[Felix Riesterer]

Liebe Forumsgemeinde,

ich versuche mich gerade an einem Workaround für den IE beim Benutzen von <button type="submit">, wo der IE bekanntlich nicht nur das innerHTML anstatt des Inhalts des value-Attributes als Wert übermittelt, sondern bei mehreren vorhandenen Submit-Buttons dieser Art bei gleichem name-Wert nur das innerHTML des im Formular zuletzt notierten sendet.

Beispiel:

<button type="submit" name="aktion" value="anzeigen"><i>Anzeige</i></button>  
<button type="submit" name="aktion" value="loeschen"><img src="delete.gif" alt="" />L&ouml;schung</button>  
<button type="submit" name="aktion" value="abmelden"><strong>Logout</strong></button>

--> IE sendet _immer_ [aktion] => <strong>Logout</strong>

Für den Fall, dass kein Javascript verfügbar ist, habe ich bereits eine serverseitige Ersetzung, die aus den <button>-Elementen <input>-Elemente macht. Das Unschöne daran ist, dass die Werte in den value-Attributen zwar "sprechende" Werte sind, diese aber immernoch relativ technisch (z.B. "user_aendern") anmuten. Die Lösung mit dem <button>-Element ist optisch einfach wesentlich reizvoller, da man hier zwischen der Button-Beschriftung und dem zu sendenden Wert unterscheiden kann, von einer Bebilderung mittels <img>-Elementen und der leichteren Gestaltung per CSS ganz zu schweigen (Hintergrundbild bei <input> ist im IE extrem aufwendig: entweder inline-styles oder viele CSS-Klassen, denn der IE kann keine attributbedingte Formatierung wie input[type=submit]!).

Ich suche nun nach einer Möglichkeit, mir die zu übermittelnden Werte in Javascript ausgeben zu lassen, um den Wert für den betätigten Submit-Button auf den im value-Attribut notierten zurückzusetzen. Dazu habe ich mir einmal alle Objekt-Elemente des <form>-Elementes in eine <textarea> schreiben lassen - eine sehr unüberschaubare Menge an Eigenschaften und Unter-Objekten war die Folge. Außerdem werden ja nicht alle im Formular enthaltenen Buttons gesendet, sondern nur einer...

Formular-Elemente onsubmit überprüfen kann ich (stehen ja im DOM-Tree), aber das löst mein Problem nicht. Wie kann ich mir also in einem onsubmit-Event alle _zu sendenen Werte_ ausgeben lassen (stehen vermutlich in irgendeinem Objekt)?

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[wahsaga]

hi,

Die Lösung mit dem <button>-Element ist optisch einfach wesentlich reizvoller, da man hier zwischen der Button-Beschriftung und dem zu sendenden Wert unterscheiden kann,

Was hat man davon?
Wenn ich auf einem Submit-Button (über input realisiert) "Die Kuh macht Muh" stehen haben möchte - dann kann ich doch auch serverseitig abfragen, ob dieser Wert übergeben wurde ...?

OK, jetzt kommt dein Argument, bei einer mehrsprachigen Seite möchtest du vielleicht jeweils unterschiedliche Beschriftungen benutzen - aber das natürlich nicht in der Scriptlogik berücksichtigen müssen ...
Na gut, dann verwende doch unterschiedliche Namen für die Submit-Inputs - und entscheide serverseitig anhand des übergebenen Namens, welcher Button benutzt wurde ...

von einer Bebilderung mittels <img>-Elementen und der leichteren Gestaltung per CSS ganz zu schweigen (Hintergrundbild bei <input> ist im IE extrem aufwendig

<input type="image"> ...?

gruß,
wahsaga

[Felix Riesterer]

Lieber wahsaga,

Danke für Deine Tipps!

von einer Bebilderung mittels <img>-Elementen und der leichteren Gestaltung per CSS ganz zu schweigen (Hintergrundbild bei <input> ist im IE extrem aufwendig

<input type="image"> ...?

Nur weil ich ein Icon _mit_ auf den Button setzen möchte, will ich doch nicht gleich eine Komplettgrafik als Ersatz! Gerade beim Argument der Mehrsprachigkeit setze ich bewusst auf Icons in Verbindung mit _Text_ auf meinen Buttons. Von daher scheidet <input type="image" /> aus.

Die Idee mit den verschieden benamsten <inputs> ist nett - aber das hatte ich schon. Da muss ich dann auf jeden Button einzeln prüfen, ob es einen gleichnamigen Index im $_POST-Array gibt. Und nur, weil der IE zu dämlich ist, weiche ich diesesmal nicht von einer sinnvollen und übersichtlicheren Programmierung ab.

Inzwischen habe ich für den IE ein Javascript geschrieben, welches am Ende des Formulars ein <input type="hidden" /> verwendet, in welches die Buttons bei onclick ihre value-Werte hineinschreiben, sodass beim Abschicken der unsinnige Wert automatisch durch das versteckte Input-Feld überschrieben wird.

Diese Methode arbeitet zuverlässig. Warum sollte ich also noch ein einziges Fünkchen mehr darüber nachdenken, wie ich meine standardkonforme Seite für den IE noch gefälliger und altmodischer benutzbar mache?

Bei ausgeschaltetem Javascript übersendet der IE einen Wert, der serverseitig alle Buttons durch unansehnliche Input-Elemente ersetzt.

Und jetzt mag ich nimmer! Das soll aber nicht die Diskussion beenden, sondern nur meinen heutigen Tag.

Ach ja: Ist der 7er in dieser Hinsicht geheilt worden?

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[wahsaga]

hi Felix,

Warum sollte ich also noch ein einziges Fünkchen mehr darüber nachdenken, wie ich meine standardkonforme Seite für den IE noch gefälliger und altmodischer benutzbar mache?

Nun, die Einstellung, für den IE nicht mehr mehr Aufwand zu betreiben als nötig, ist ja inzwischen recht verbreitet (und ich teile sie auch weitgehend) -

Inzwischen habe ich für den IE ein Javascript geschrieben, welches am Ende des Formulars ein <input type="hidden" /> verwendet, in welches die Buttons bei onclick ihre value-Werte hineinschreiben, sodass beim Abschicken der unsinnige Wert automatisch durch das versteckte Input-Feld überschrieben wird.

Bei ausgeschaltetem Javascript übersendet der IE einen Wert, der serverseitig alle Buttons durch unansehnliche Input-Elemente ersetzt.

• aber wenn das dann darauf hinausläuft, mit Javascript o.ä. Workarounds zu basteln, die wieder zusätzlichen Aufwand bedeuten (und noch mal extra welchen, wenn JS nicht zur Verfügung steht) - dann weiß ich nicht, ob ich das noch so sinnvoll finden kann.

Mir kommt gerade noch eine Idee:
Man könnte in den Inhalt des Buttons ja noch einen Span mit hineinpacken, der dann per CSS unsichtbar gemacht wird - und auch noch mal den Value-Inhalt als Textinhalt enthält.

Bezogen auf dein Beispiel:

<button type="submit" name="aktion" value="anzeigen"><i>Anzeige</i><span>anzeigen</span></button>  
<button type="submit" name="aktion" value="loeschen"><img src="delete.gif" alt="" />L&ouml;schung<span>loeschen</span></button>  
<button type="submit" name="aktion" value="abmelden"><strong>Logout</strong><span>abmelden</span></button>

Ordentliche Browser übermitteln nach wie vor die Values "anzeigen", "loeschen" oder "abmelden".

Wenn der IE dir innerHTML des Buttons schickt - dann kommen "anzeigen", "loeschen" oder "abmelden" auf jeden Fall auch mit darin vor - man bräuchte also nur noch abfragen, ob der übermittelte Wert "anzeigen", "loeschen" oder "abmelden" _irgendwo_ enthält (natürlich ist dafür zu sorgen, dass _diese_ Wörter nicht noch in anderen Buttoninhalten vorkommen).

Das wäre auch weitgehend sprachunabhängig - wenn du die Beschriftung des ersten Buttons von "Anzeige" in "Show" ändern willst, lässt du einfach den <span>anzeigen</span> trotzdem bestehen - der User sieht ihn ja nicht, aktiviertes CSS vorausgesetzt.

Um das von Sven angesprochene Problem, dass der IE die Werte _aller_ Buttons übermittelt - mirgeht's da wie Sven, ich hab's bisher auch nur gelesen, aber noch nicht selber verifiziert - hülfe dieser Workaround aber wohl trotzdem nicht herum :-(

gruß,
wahsaga

[Felix Riesterer]

Lieber wahsaga,

interessant, was Du da so schreibst:

Nun, die Einstellung, für den IE nicht mehr mehr Aufwand zu betreiben als nötig, ist ja inzwischen recht verbreitet (und ich teile sie auch weitgehend) -

• aber wenn das dann darauf hinausläuft, mit Javascript o.ä. Workarounds zu basteln, die wieder zusätzlichen Aufwand bedeuten (und noch mal extra welchen, wenn JS nicht zur Verfügung steht) - dann weiß ich nicht, ob ich das noch so sinnvoll finden kann.

Ich bin mit meinem sowohl serverseitigen, als auch JavaScript-seitigen Aufwand sehr klein geblieben. Serverseitig prüfe ich auf den Inhalt eines übermittelten Wertes ($_POST["Internet-Explorer"]). Lautet er nicht "ok", dann kommt ein einziges preg_replace() auf den kompletten auszuliefernden HTML-Code, das die Ersetzung vornimmt.

Das Javascript, das ich in Zukunft wieder einzusetzen gedenke, ändert den Wert von $_POST["Internet-Explorer"] auf "ok" und hängt ein neues verstecktes Input-Element ans Ende des Formulars. Dann versieht es alle Submit-Buttons mit einem Eventhandler, der den Inhalt des neuen versteckten Inputs mit dem value-Wert seines angeclickten Buttons füllt.

Damit das nur im IE abläuft, setze ich in den HTML-Templates alles in einen Conditional Comment:

<--[if lt IE 7]>  
<input type="hidden" name="Internet-Explorer" value="leider" id="Internet-Explorer" />  
<script type="text/javascript" src="internet-explorer.js"></script>  
<![endif]-->

War das wirklich so umständlich? Anschauen kann man es bei meinem eigenen Online-Bookmarkmanager

Mir kommt gerade noch eine Idee:
Man könnte in den Inhalt des Buttons ja noch einen Span mit hineinpacken, der dann per CSS unsichtbar gemacht wird - und auch noch mal den Value-Inhalt als Textinhalt enthält.
Das wäre auch weitgehend sprachunabhängig - wenn du die Beschriftung des ersten Buttons von "Anzeige" in "Show" ändern willst, lässt du einfach den <span>anzeigen</span> trotzdem bestehen - der User sieht ihn ja nicht, aktiviertes CSS vorausgesetzt.

Das kommt mir nun wieder umständlich vor. Aber das ist sicherlich Ansichtssache. Ich möchte auf sinnvolle Art standardkonform entwickeln. Wenn der IE dann einen schweren Defekt hat (das kann man doch hier wohl so nennen, oder?!), dann bügle ich den mit IE-Mitteln wieder gerade. Serverseitig habe ich ja sehr geringen Aufwand für diese Korrektur...

Deine vorgeschlagene Lösung schmeckt mir einfach weniger gut!

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Felix Riesterer]

Anschauen kann man es bei meinem eigenen Online-Bookmarkmanager

Falls es jemand wirklich ausprobieren will (IE sieht noch übel aus!)...

User: selfhtml
Passwort ist (noch) leer...

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[wahsaga]

hi,

Anschauen kann man es bei meinem eigenen Online-Bookmarkmanager

Falls es jemand wirklich ausprobieren will (IE sieht noch übel aus!)...

Tja, siehste - da haben wir die Nachteile von solchen Javascript-Workarounds:
Gibt bei mir im IE 5 einen Javascript-Fehler, Abschicken kann ich das Fomurlar danach zwar noch, aber Reaktion gibt es keine, ich sehe immer wieder die gleiche Seite.

(Die Meldung des IE selber über den Ort des Fehlers ist mal wieder nonsense, aber der Javascript-Debugger meldet mir den Fehler in linklist.js, die Zeile

alle_ordner.push({ 'stamm' : alle_uls[i], 'ordner' : ordner});

mag der IE 5.01 nicht, weil der Array.push() noch nicht kennt.
Hat zwar jetzt nichts direkt mit deinem Button-Workaround zu tun - aber weil vorher ein Fehler auftrat, kommt der jetzt auch nicht mehr zum Zuge ...)

gruß,
wahsaga

[Felix Riesterer]

Lieber wahsaga,

Gibt bei mir im IE 5 einen Javascript-Fehler, Abschicken kann ich das Fomurlar danach zwar noch, aber Reaktion gibt es keine, ich sehe immer wieder die gleiche Seite.

Auf die Unterunarten des IEs habe ich noch nicht erschöpfend getestet (hast das Ergebnis von gestern abend soeben ausprobiert)...

(Die Meldung des IE selber über den Ort des Fehlers ist mal wieder nonsense, aber der Javascript-Debugger meldet mir den Fehler in linklist.js, die Zeile

alle_ordner.push({ 'stamm' : alle_uls[i], 'ordner' : ordner});
mag der IE 5.01 nicht, weil der Array.push() noch nicht kennt.

Vielen Dank für den wertvollen Hinweis! Werde das umarbeiten müssen.

Hat zwar jetzt nichts direkt mit deinem Button-Workaround zu tun - aber weil vorher ein Fehler auftrat, kommt der jetzt auch nicht mehr zum Zuge ...)

Das ist richtig. Da stört ein unangepasstes Script (das zum Falten der Ordner) ein anderes. Muss das einmal überarbeiten, denn die Ordner-Faltungen brauche ich auch auf einer anderen Seite.

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Felix Riesterer]

Lieber wahsaga,

der Javascript-Debugger meldet mir den Fehler in linklist.js [...]

alle_ordner.push({ 'stamm' : alle_uls[i], 'ordner' : ordner});
mag der IE 5.01 nicht, weil der Array.push() noch nicht kennt.

Problem jetzt behoben. Ich hatte keine Lust, für jeden IE ein eigenes CSS zu schreiben, daher sieht es im 5.01er immernoch seltsam aus, in den anderen beiden (5.5 + 6.0) ist die Darstellung nun aber akzeptabel. Daher stecke ich nun keine Energie mehr in dieses Projekt, es sei denn es werden noch Bugs in der Funktionsweise offensichtlich.

Dir nocheinmal Danke für das Aufzeigen des Problemkerns!

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[wahsaga]

hi,

War das wirklich so umständlich?

Nun ja, es war ja auch noch von einem serverseitigen Fallback für JS-Lose IE-Nutzer die Rede, der dann wiederum normale Inputs generiert - das erscheint mir schon umständlicher (weniger vom Aufwand her, mehr vom Prinzip ...).
Zumal es ja erst mal einen Durchlauf Request-Response-Request erfordert, bevor du überhaupt halbwegs sicher wissen kannst, ob ich Javascript aktiviert habe oder nicht.

Das kommt mir nun wieder umständlich vor. Aber das ist sicherlich Ansichtssache.

War nur 'ne Idee auf die schnelle.
Was der goldene Mittelweg wäre, überlege ich gerade selber noch ...

gruß,
wahsaga

[Felix Riesterer]

Lieber wahsaga,

Zumal es ja erst mal einen Durchlauf Request-Response-Request erfordert, bevor du überhaupt halbwegs sicher wissen kannst, ob ich Javascript aktiviert habe oder nicht.

nö. Mein serverseitiges Script reagiert in seiner switch-Schleife per default. Daher ist es mir herzlich egal, ob der Client Javascript hat, oder nicht. Sendet er beim ersten Request einen entsprechenden Wert, dann "filtert" mein Script die Buttons von <button> zu <input>. End of story.

Klar, dass der allererste Request der Seitenaufruf an sich ist. Aber ob der mit oder ohne Javascript stattfindet (ist nur ein einziger "login"-Button vorhanden) ist wegen des default-Zweiges serverseitig absolut wurschd.

Was der goldene Mittelweg wäre, überlege ich gerade selber noch ...

Das ist sicherlich völlig von den Anforderungen des jeweiligen Projektes abhängig.

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Sven Rautenberg]

Moin!

sondern bei mehreren vorhandenen Submit-Buttons dieser Art bei gleichem name-Wert nur das innerHTML des im Formular zuletzt notierten sendet.

Sicher? Meine Informationen (die ich noch nicht selbst im Test bestätigt habe) besagen, dass der IE _ALLE_ Buttons sendet, nicht nur den letzten.

Benutzt du PHP zur Auswertung? Dann wäre deine Feststellung erklärlich, weil PHP auf identische Namen mit dem Überschreiben der zuerst enthaltenen Felder durch die nachfolgenden reagiert. Mach mal stattdessen:
<button type="submit" name="aktion[]" value="anzeigen"><i>Anzeige</i></button>
und so weiter.

- Sven Rautenberg

[Felix Riesterer]

Lieber Sven,

sondern bei mehreren vorhandenen Submit-Buttons dieser Art bei gleichem name-Wert nur das innerHTML des im Formular zuletzt notierten sendet.

Sicher? Meine Informationen (die ich noch nicht selbst im Test bestätigt habe) besagen, dass der IE _ALLE_ Buttons sendet, nicht nur den letzten.

diese Information hatte ich auch. In meiner provisorischen Testumgebung schien er aber nicht alle Buttons zu senden...

Benutzt du PHP zur Auswertung?

Ja.

Mach mal stattdessen:
<button type="submit" name="aktion[]" value="anzeigen"><i>Anzeige</i></button>

Das kenne ich. Dann erhalte ich ein Array mit allen tatsächlich gesendeten Werten. Aber ich meine gelesen zu haben, dass das nicht unbedingt standardkonform (zu HTTP?) ist. Aber ich wüsste jetzt nicht, wie man es für PHP sonst bei z.B. Mehrfachauswahlen machen sollte.

Wie lösen das eigentlich andere Scriptsprachen wie Perl oder ASP? (Will mich in diese jetzt nicht einarbeiten und google daher nicht danach - is au net so wichtig)

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[wahsaga]

hi,

Das kenne ich. Dann erhalte ich ein Array mit allen tatsächlich gesendeten Werten. Aber ich meine gelesen zu haben, dass das nicht unbedingt standardkonform (zu HTTP?) ist.

HTTP interessiert erst mal nicht, sondern erst mal HTML - und da hat das name-Attribut von Formularfeldern den Inhaltstyp CDATA, darf als [ und ] problemlos enthalten.

HTTP kommt ins Spiel, wenn dieses Formular dann verschickt wird - und da ist es Sache des Browser, den Feldnamen ggf. URL-gerecht zu kodieren. Stellt bei [ und ] auch kein Problem dar.
(Ich hatte letzte Tage eine Diskussion darüber mit Tobias(?), welche Zeichen im name-Attribut von Formularfeldern praktikabel sind, da ging es auch um fremdsprachige Sonderzeichen. Er hatte sehr interessant ausgeführt, an welchen Stellen da mit Kodierung etc. was schiefgehen könnte - aber die eckigen Klammern sind wirklich unproblematisch.)

Wie lösen das eigentlich andere Scriptsprachen wie Perl oder ASP?

Die sind AFAIK "intelligenter" als PHP - wenn ein Name im Query-String mehrmals auftaucht, überschreiben sie nicht jeweils den vorherigen mit dem aktuellen, sondern stellen gleich alle - als Array oder wieauchimmer - zur Verfügung.

gruß,
wahsaga

[Felix Riesterer]

Lieber wahsaga,

HTTP kommt ins Spiel, wenn dieses Formular dann verschickt wird - und da ist es Sache des Browser, den Feldnamen ggf. URL-gerecht zu kodieren. Stellt bei [ und ] auch kein Problem dar.

Deshalb werden die Macher von PHP das wohl absichtlich so gelöst haben...

Wie lösen das eigentlich andere Scriptsprachen wie Perl oder ASP?

Die sind AFAIK "intelligenter" als PHP - wenn ein Name im Query-String mehrmals auftaucht, überschreiben sie nicht jeweils den vorherigen mit dem aktuellen, sondern stellen gleich alle - als Array oder wieauchimmer - zur Verfügung.

Danke für die Info!

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Tim Tepaße]

Hallo,

(Ich hatte letzte Tage eine Diskussion darüber mit Tobias(?) ...

Tim heisse ich ;)

... welche Zeichen im name-Attribut von Formularfeldern praktikabel sind, da ging es auch um fremdsprachige Sonderzeichen. Er hatte sehr interessant ausgeführt, an welchen Stellen da mit Kodierung etc. was schiefgehen könnte - aber die eckigen Klammern sind wirklich unproblematisch.)

Würde ich auch sagen.

Dies aber nur, weil bevor die Browser unisono auf UTF-8 zur Textkodierung in application/x-www-form-urlencoded gewechselt sind, ISO 8859-1 genutzt wurde. Die eckigen Klammern befinden sich bei ISO 8859-1 im US-ASCII gleichenden Teil des Zeichensatzes; die Besonderheit der Zeichenkodierung UTF-8 ist ja gerade, dass die Bytefolgen für die Zeichen aus US-ASCII mit den US-ASCII-Bytefolgen gleich sind.

(Hab ich schon erwähnt, dass ich es liebe, Leute mit Zeichenkodierungs-Krempel zu nerven? Du bist schon Nummer zwei heute ;)

Tim