Danke. Du hast natürlich recht. Frag mich nicht wieso ich der Meinung war ich brauch nochmals ein focus (für Tastatur) und ein weiteres click für die entsprechenden Labels. Kam mir wohl einfach zu einfach vor ;). Dabei hab ich das sicher mehrmals getestet - auf x browsern. Komisch, jetzt funktioniert das überall…. naja soll vorkommen.

Nochmals Danke für die Klarstellung - und sorry für die leicht Off-Topic.

Beim change Event hält sich der IE übrigens eher an den W3C Standard als andere Browser (Ausnahme: select-DropDowns bei Tastaturbenutzung). Die Spezifikation des change Events ist soetwas von …

Wenn es um ein change bei checkboxen und radiobuttons geht. Sollte eigentlich ein click-Event ausreichen. Du brauchst hier also kein zusätzliches change/focus-Event. Damit sollte dein Problem behoben sein.

Ich setze hier in der Firma ein custom-Change-Event ein, welches ein intuitives, cross-browser-taugliches change-Event einführt. Wenn ich etwas Zeit habe, poste ich das mal…

Zu.: options
Nein, das Script macht das nicht. Das war ein Kopierfehler in der Doku. Aber ich ziehe hier das Script mal am Wochenende nach, weil macht ja wirklich Sinn.

Beispiel: warenkorb-Forumlar. Bei jeder Änderung (Anzahl, zusatz Optioen,..) soll ein Request geschickt werden. Leider funnktioniert das (dank IE) nicht mit $(element).change(). Ich brauch also noch andere (nicht eindeutige) trigger (focus,click). Damit jetzt nicht ständig der selben Warenkorb aktualisieret wird (problemlos, aber eben auch sinnlos), prüfe ich auf den _letzten_ (auch wenn der schon 10 sec alt und fertig war). Könnt ich natürlich auch auserhalb des managers machen, aber wenn ich schon einen “Manager” habe - hatte schon öffters diese Situation.

Macht natürlich nur bei “abortOld” bzw. “sync” Sinn.

——-

Noch was:
Laut doc soll $.ajaxManager “jQuery-Ajax-Options” annehmenen.
Soweit ich sehe ist das aber nicht der Fall:

var am = $.manageAjax({type: ‘POST’,manageType: …});
am.add({data: “something”,…});
//macht eine default GET-Abfrage

..oder ich hab den Sinn darin nicht verstanden

Werstehe ich dich richtig, wenn request a ausgelöst wurde, dann ein request b und dann wieder ein request a, dann soll der 2. request a nicht geblockt werden, obwohl der 1. noch gar nicht beantwortet wurde?

Für welchen usecase, brauchst du das? Oder ist dort ein Bug verborgen?

Thx, for pointing this out. I had already fixed this issue, but had no time to update my plugins. I will try to do this this weekend.

…
manageAjax: function(o){
o = $.extend({
manageType: ‘normal’,
maxReq: 0,
blockSameRequest: false,
blockSameLastRequest: false,
lastRequest: false,
global: true
}, o);
…
…
if (s.blockSameLastRequest) {
var lr = this.lastRequest;
if (lr && lr.data === cD && lr.url === o.url && lr.type === o.type) {
return false;
}
}
this.lastRequest = q[quLen] = {
…

q[num].fnError.apply($, q[num].error);

but it should be:

q[num].fnError.apply(q[num], q[num].error);

In original ajax requests from jQuery ‘this’ in callback functions points to options not to jquery object.

danke für die Blumen. jQuery hat das wahrscheinlich deshalb nicht im Core, weil Ajax - entgegen des Hypes - im täglichen JS-Geeschäft relativ selten genutzt wird und bei Verwendung häufig unsinnige Doppelrequests, überholende Requests vernachlässigt werden.

Es kann aber sehr gut sein, dass soetwas ähnliches entweder im jQuery-Core oder im UI-Core landen wird. Eine zukünftige Version von jQuery wird ein Autocomplete/Combobox-Plugin beinhalten. Das autocomplete-Plugin von Jörn Zäfferer (http://bassistance.de/2008/06/25/release-autocomplete-plugin-101/) wird hier wahrscheinlich Grundlage sein und dieses setzt wiederum das Ajax-Queue-Plugin (http://plugins.jquery.com/project/ajaxqueue).

danke fuer deine Arbeit! Habe dein Plugin erfolgreich im Einsatz,
es klappt super! Eigentlich sollte jQuery diese Funktionalitaet
im Core haben, denn mehrere parallelle Ajax-Requests sind mitunter
ja keine Seltenheit…

Gruss,

Falk