Re: Formular mit mehreren Submit-Buttons: Welcher angeklickt?

Gregor Kofler wrote:

Gibt es eine Möglichkeit (habe ich eine Property eines Elementes
übersehen?), im Submit-Handler eines Formulars den gewählten
Submit-Button zu ermitteln?

Ja. Die einzige Möglichkeit, die mir einfällt, ist, per click-Listener des
Submit-Buttons eine global verfügbare Eigenschaft zu setzen, die Du dann im
submit-_Listener_ des Formulars ausliest. Da reicht auch schon eine globale
Variable (die eine Eigenschaft des Globalen Objekts ist -- dieses bitte
standardkonform und nicht über `window' referenzieren). Das click-Event des
input-Elements findet AIUI auf jeden Fall vor dem submit-Event des
Formularelements statt.

Da das click-Event in allen DOMs blubbert, reicht sehr wahrscheinlich
sogar ein Event-Listener für alle Submit-Buttons; den könnte man dann
sinnvollerweise ebenfalls im <form>-Tag unterbringen oder in einem
fieldset-Nachfahren. Ein bisschen proprietär aber bis jetzt cross-browser
(kennt jemand eine standardkonforme Alternative?) übergibt man dort dann mit
`event' eine Referenz auf das jeweilige Event-Objekt und mit dessen target-
bzw. srcElement-Eigenschaft eine Referenz zum Event-Ziel, d.h. dem
auslösenden Objekt.

Und: Wenn ich einen Listener an den Submit-Handler hänge, bleibt ein
return false; in ebendiesem wirkungslos und das Formular wird jedenfalls
submitted.

Verständlich, denn der Rückgabewert wird nicht an den Event-Handler
weitergereicht, wie das mit einer return-Anweisung in einem
Event-Handler-Attributwert der Fall wäre.

Augenblicklich verhindere ich dies durch das Überschreben von
form.onsubmit wie unten angeführt. Geht das eventuell eleganter?

Nochmal ja:

<form ... onsubmit="return checkForm(this);">
<script type="text/javascript">
function checkForm(f)
{
// ...
return false;
}
</script>
...
</script>

Wo sich das script-Element bzw. der Script-Code befindet, spielt keine Rolle
(solange er nur referenziert wird), da die Variableninstantiierung (d.h.
hier die Erzeugung des Function-Objekts) bei ECMAScript-Implementationen
immer vor der Ausführung kommt. Ich finde diese Anordnung als Kindelement
des form-Elements aber kompakter und damit wartungsfreundlicher als andere
Lösungen. Das Script gehört zu seinem Formular (ein weiterer Beweis,
weshalb "Unobtrusive JavaScript" reiner Blödsinn ist -- aber ich schweife ab).

script type="text/javascript"

window.onload = function() {
document.forms[0].onsubmit = function() {return false;};

Event.addEvent(document.forms[0], "submit", function(e) {
...
});
}
/script

*(kopf)schüttel*

Event.addEvent() ruft je nach DOM addEventListener() oder attachEvent()
auf. Nachdem ich dzt. nur bastle, teste ich nur im FF; Hinweise auf zu
erwartende Inkompatibilitäten sind willkommen.

Die onload-Eigenschaft ist proprietär, ebenso die onsubmit-Eigenschaft.
Event.addEvent dürfte eigentlich gar nicht funktionieren, allenfalls
Event.prototype.addEvent, proprietär ist es ausserdem. Inkompatibilitäten
sind so buchstäblich vorprogrammiert. Standardkonform wäre:

document.forms[0].addEventListener(
"submit",
function e()
{
// ...
},
false
);

MSHTMLs attachEvent() will man wegen des this-Problems und der beliebigen
Ausführungsreihenfolge vermeiden, also bleibt dort nur die Zuweisung an die
jedoch ebenfalls proprietäre onsubmit-Eigenschaft. Wenn man dann unbedingt
diesen ganzen "Unobtrusive JavaScript"-Mist machen will. Der schlösse dann
nämlich auch Experimente mit Event:reventDefault() und Konsorten ein, was
im Vergleich zu der obigen konventionellen Lösung ziemlich *igitt* wäre.


HTH

PointedEars
--
Du fragst Leute, die normalerweise gern Information weitergeben, wie Du
Information verheimlichen kannst? Ist das nicht ein bisschen ... nunja ...
seltsam? (Ulrich 'Droeppez' Kritzner zu einem Quelltextsperrer in
http://selfhtml.de/forum/zeigebeitra...4&thread=39241)

Thomas 'PointedEars' Lahn wrote:

Gregor Kofler wrote:
Event.addEvent() ruft je nach DOM addEventListener() oder attachEvent()
auf. [...]

[...]
Event.addEvent dürfte eigentlich gar nicht funktionieren, allenfalls
Event.prototype.addEvent, proprietär ist es ausserdem. Inkompatibilitäten
sind so buchstäblich vorprogrammiert. Standardkonform wäre:

document.forms[0].addEventListener(
[...]

Sorry, da habe ich Deine Erklärung nicht richtig gelesen. Ich bleibe aber
dabei, dass `Event' hier allenfalls einen Konstruktor bezeichnen sollte.
Und auch

[...]
MSHTMLs attachEvent() will man wegen des this-Problems und der beliebigen
Ausführungsreihenfolge vermeiden,

ist hier relevant. Hier noch der entsprechende URI:

http://www.quirksmode.org/blog/archi...nt_consid.html


PointedEars
--
Der erfahrene IE-Fahrer weiß, daß man Slalom am besten im ersten Gang fährt,
weil schnelles Lenkradumreißen bei IE zum Lenkradabreißen führt. Wer
sportlich fahren will, muß Netscape fahren und hin und wieder auch mal
anschieben. ;-) --Georg Maaß, dcljs, <amuqrl$91i3q$1 (AT) ID-3551 (DOT) news.dfncis.de>

Gregor Kofler wrote:

Thomas 'PointedEars' Lahn meinte:
Gregor Kofler wrote:
Gibt es eine Möglichkeit (habe ich eine Property eines Elementes
übersehen?), im Submit-Handler eines Formulars den gewählten
Submit-Button zu ermitteln?
Ja. Die einzige Möglichkeit, die mir einfällt, ist, per click-Listener des
Submit-Buttons eine global verfügbare Eigenschaft zu setzen, die Du dann im
submit-_Listener_ des Formulars ausliest. Da reicht auch schon eine globale
Variable (die eine Eigenschaft des Globalen Objekts ist -- dieses bitte
standardkonform und nicht über `window' referenzieren). Das click-Event des
input-Elements findet AIUI auf jeden Fall vor dem submit-Event des
Formularelements statt.

Nachdem es für mich ohnedies wünschenswert ist, diese
AJAX-Funktionalität "näher" an das serverseitige Framework zu binden
habe ich testhalber dem Form-Element die beiden Handler verpasst.

form action="foo.php" method="POST"

onsubmit="if(typeof(XHRForm) == 'object' && typeof(XHRForm.submit) ==

`typeof' ist ein Operator, keine Methode, und sollte entsprechend
geschrieben werden.

'function') { return XHRForm.submit(this); } else { return true; }"

Etwas hypscher und zuverlässiger ist

onsubmit="if (/\b(object|function)\b/i.test(typeof XHRForm) && XHRForm) {
return XHRForm.submit(this); } else { return true; }"

Da submit() aber hier wahrscheinlich eine benutzerdefinierte (und keine
AOM/DOM-)Methode ist, sollte ein Vergleich mit "function" genügen:

onsubmit="if (typeof XHRForm == "function") { return XHRForm.submit(this);
} else { return true; }"

Zudem sollte der Listener-Code in eine eigene Methode ausgelagert werden, um
solcherlei Spaghetticode zu vermeiden.

onclick="if(typeof(XHRForm) == 'object' && typeof(XHRForm.getSubmit) ==
'function') { return XHRForm.getSubmit(event); } else { return true; }"

Siehe oben. Hier solltest Du ausserdem noch `typeof event != "undefined'
testen, bevor Du auf den Wert zugreifest. Sonst wird der User mit einer
ReferenceError-Exception beworfen, falls `event' wider Erwarten nicht
definiert sein sollte.

[...]
/form

(die XHRForm-Methoden setzen dzt. einfach informative Alerts ab.)

Noch so ein Fall, wo die Bezeichner nicht den Programmierkonventionen
entsprechen.

Ich bin total fertig: Das klappt auf Anhieb im IE und FF und Opera.

Das ist die Schönheit von DOM Level 0. Sollte sogar mit KHTML-DOM, d.h. in
Konqueror, und Apple WebCore, d.h. in Safari, klappen.

Alter Schwede... Das die übergabe des event-Objekts im Handler so
problemlos klappt, erstaunt mich.

Das hatte mich auch erstaunt (die Idee kam IIRC von Georg Maaß), bisher bin
ich aber nicht enttäuscht worden.

Da bin ich jetzt eher wie ein Skript-Kiddie unterwegs...

Etwas weniger Spaghetticode wäre ein erster Schritt, um dem abzuhelfen.

Unabhängig davon würde mir statt `event' eine spezifizierte standardkonforme
vollkompatible Alternative auch besser gefallen. Bisher jedoch Fehlanzeige.


PointedEars

Thomas 'PointedEars' Lahn wrote:

Gregor Kofler wrote:
onsubmit="if(typeof(XHRForm) == 'object' && typeof(XHRForm.submit) ==
[...]
'function') { return XHRForm.submit(this); } else { return true; }"

Etwas hypscher und zuverlässiger ist

onsubmit="if (/\b(object|function)\b/i.test(typeof XHRForm) && XHRForm) {
return XHRForm.submit(this); } else { return true; }"

Äh. Quark.

onsubmit="if (typeof XHRForm == 'object' && XHRForm &&
/\b(object|function)\b/i.test(typeof XHRForm.submit) && XHRForm.submit) {
return XHRForm.submit(this); } else { return true; }"

Da submit() aber hier wahrscheinlich eine benutzerdefinierte (und keine
AOM/DOM-)Methode ist, sollte ein Vergleich mit "function" genügen:

onsubmit="if (typeof XHRForm == "function") { return XHRForm.submit(this);
} else { return true; }"

onsubmit="if (typeof XHRForm == 'object' && XHRForm && typeof
XHRForm.submit == "function") { return XHRForm.submit(this); } else { return
true; }"

Zudem sollte der Listener-Code in eine eigene Methode ausgelagert werden, um
solcherlei Spaghetticode zu vermeiden.
[...]

Der Vollständigkeit halber:

function submitForm(f)
{
if (typeof XHRForm == 'object' && XHRForm
&& typeof XHRForm.submit == "function")
{
return XHRForm.submit(f);
}
else
{
return true;
}
}

onsubmit="return submitForm(this);"


PointedEars
--
Mozilla ist ein Webbrowser. Das ist ein Programm, dass es ermoeglicht,
Webseiten anzusehen. Das ist nicht sowas wie ein Programm, das es
Webdesignern erlaubt, den Nutzer zu belaestigen, indem man seine
Arbeitsumgebung unsinnig manipuliert. -- Boris 'pi' Piwinger in dcljs

Thomas 'Ingrid' Lahn wrote:

Thomas 'PointedEars' Lahn wrote:
Da submit() aber hier wahrscheinlich eine benutzerdefinierte (und keine
AOM/DOM-)Methode ist, sollte ein Vergleich mit "function" genügen:

onsubmit="if (typeof XHRForm == "function") { return XHRForm.submit(this);
} else { return true; }"

onsubmit="if (typeof XHRForm == 'object' && XHRForm && typeof
XHRForm.submit == "function") { return XHRForm.submit(this); } else { return
true; }"

Ich sollte so spät nicht mehr posten.

onsubmit="if (typeof XHRForm == 'object' && XHRForm && typeof
XHRForm.submit == 'function') { return XHRForm.submit(this); } else { return
true; }"


PointedEars

Gregor Kofler wrote:

Thomas 'PointedEars' Lahn meinte:
typeof XHRForm == 'object' && XHRForm ...

Wann würde eigentlich das typeof auf true evaluieren und XHRForm auf false?

XHRForm === null


PointedEars
--
Clientseitig geht das nicht wirklich, weil der Browser selbst keine
Mails verschicken kann und das Kooperieren mit Mailprogrammen eher
in ein Kollabieren entartet.
(Georg Maaß in dcljs <aoh6vi$mbrnu$4 (AT) ID-3551 (DOT) news.dfncis.de>)

Gregor Kofler wrote:

Thomas 'PointedEars' Lahn meinte:
Gregor Kofler wrote:
Thomas 'PointedEars' Lahn meinte:
typeof XHRForm == 'object' && XHRForm ...
Wann würde eigentlich das typeof auf true evaluieren und XHRForm auf false?
XHRForm === null

Ahja. Danke.

Gern geschehen. Es ist noch zu ergänzen, dass `typeof XHRForm' auch dann
"object" liefern, XHRForm nicht `null' liefern, und dennoch zu `false'
ausgewertet werden kann, wenn XHRForm ein Host-Objekt referenziert. Siehe
ECMAScript Ed. 3 Final, Abschnitte 8.6.2 und 11.4.3.


PointedEars
--
Aber das Sperren der rechten Maustaste hat auch seine Vorteile: so
bleibt uns der Anblick einer ganzen Menge dilettantisch und lieblos
zusammengewurstelten Quellcodes erspart. (Ulrich 'Droeppez' Kritzner in
http://selfhtml.de/forum/zeigebeitra...4&thread=31592)