[jQuery] .ajax () faalt in IE

[PeaceNlove]

Ik heb een heel raar probleem met een een van onze klanten in mijn JavaScript.

Ik doe met jQuery een ajax-request naar mijn server en in mijn IE9 werkt het wel gewoon, ook met de browser mode teruggezet naar IE7. Ik krijg gewoon netjes de response terug.
Nu zat ik eerst te denken dat de security instellingen van de klant te strak staan afgesteld, maar dan zouden mijn eerdere ajax-requests ook gewoon falen, maar die doen het wel bij de klant. Het is dus niet dit issue: http://stackoverflow.com/...uery-and-activex-security
Het is dus niet het probleem dat IE7 ActiveX nodig heeft om fatsoenlijk Ajax requests te doen.
Cross domain zou ook geen probleem mogen zijn, want alles draait in hetzelfde subdomein.
Het irritante is alleen dat ik het probleem zoals de klant dat heeft niet kan reproduceren door de beveiligingsinstellingen van mijn IE zodanig aan te passen dat de ene request wel werkt en de andere niet.

JavaScript:

var data = Gadget.SimgroLayer.getFullRequestString({
                    REQUEST: "GetFeatureInfo",
                    EXCEPTIONS: "text/xml",
                    BBOX: Gadget.Map.getExtent().toBBOX(),
                    X: evt.xy.x,
                    Y: evt.xy.y,
                    INFO_FORMAT: "text/plain",
                    QUERY_LAYERS: layers,
                    WIDTH: Gadget.Map.size.w,
                    HEIGHT: Gadget.Map.size.h
                });
                var url = Gadget.url + "wms.ashx?";
                data = data.substring(url.length);
                $.ajax({
                    type: 'POST',
                    url: url,
                    data: data,
                    success: function (response) { Gadget.ShowChart(response, evt); }
                });

De data variabele:

code:

"filter=hsw&LAYERS=hsw.Absoluut.ActualEvapFromEPS.Average.Actueel.2011-06-12&VERSION=1.3.0&CRS=EPSG%3A28992&TRANSPARENT=true&FORMAT=image%2Fpng&EXCEPTIONS=text%2Fxml&SERVICE=WMS&REQUEST=GetFeatureInfo&STYLES=&BBOX=249191.6%2C555344.34%2C250253.36%2C555680.34&X=538&Y=145&INFO_FORMAT=text%2Fplain&QUERY_LAYERS=hsw.Absoluut.ActualEvapFromEPS.Average.Actueel.2011-06-12%2Chsw.Absoluut.ActualEvapFromEvap.Average.Actueel.2011-06-11%2Chsw.Absoluut.Scenario_Average.Average.Nothing.2011-06-22%2Chsw.Absoluut.Scenario_Average.Average.Nothing.2011-06-21%2Chsw.Absoluut.Scenario_Average.Average.Nothing.2011-06-20%2Chsw.Absoluut.Scenario_Average.Average.Nothing.2011-06-19%2Chsw.Absoluut.Scenario_Average.Average.Nothing.2011-06-18%2Chsw.Absoluut.Scenario_Average.Average.Nothing.2011-06-17%2Chsw.Absoluut.Scenario_Average.Average.Nothing.2011-06-16%2Chsw.Absoluut.Scenario_Average.Average.Nothing.2011-06-15%2Chsw.Absoluut.Scenario_Average.Average.Nothing.2011-06-14%2Chsw.Absoluut.Scenario_Average.Average.Nothing.2011-06-13%2Chsw.Absoluut.Scenario_Maximum.Maximum.Nothing.2011-06-22%2Chsw.Absoluut.Scenario_Maximum.Maximum.Nothing.2011-06-21%2Chsw.Absoluut.Scenario_Maximum.Maximum.Nothing.2011-06-20%2Chsw.Absoluut.Scenario_Maximum.Maximum.Nothing.2011-06-19%2Chsw.Absoluut.Scenario_Maximum.Maximum.Nothing.2011-06-18%2Chsw.Absoluut.Scenario_Maximum.Maximum.Nothing.2011-06-17%2Chsw.Absoluut.Scenario_Maximum.Maximum.Nothing.2011-06-16%2Chsw.Absoluut.Scenario_Maximum.Maximum.Nothing.2011-06-15%2Chsw.Absoluut.Scenario_Maximum.Maximum.Nothing.2011-06-14%2Chsw.Absoluut.Scenario_Maximum.Maximum.Nothing.2011-06-13%2Chsw.Absoluut.Scenario_Minimum.Minimum.Nothing.2011-06-22%2Chsw.Absoluut.Scenario_Minimum.Minimum.Nothing.2011-06-21%2Chsw.Absoluut.Scenario_Minimum.Minimum.Nothing.2011-06-20%2Chsw.Absoluut.Scenario_Minimum.Minimum.Nothing.2011-06-19%2Chsw.Absoluut.Scenario_Minimum.Minimum.Nothing.2011-06-18%2Chsw.Absoluut.Scenario_Minimum.Minimum.Nothing.2011-06-17%2Chsw.Absoluut.Scenario_Minimum.Minimum.Nothing.2011-06-16%2Chsw.Absoluut.Scenario_Minimum.Minimum.Nothing.2011-06-15%2Chsw.Absoluut.Scenario_Minimum.Minimum.Nothing.2011-06-14%2Chsw.Absoluut.Scenario_Minimum.Minimum.Nothing.2011-06-13%2Chsw.Absoluut.Strategy_1.Maximum.High.2011-06-22%2Chsw.Absoluut.Strategy_1.Maximum.High.2011-06-21%2Chsw.Absoluut.Strategy_1.Maximum.High.2011-06-20%2Chsw.Absoluut.Strategy_1.Maximum.High.2011-06-19%2Chsw.Absoluut.Strategy_1.Maximum.High.2011-06-18%2Chsw.Absoluut.Strategy_1.Maximum.High.2011-06-17%2Chsw.Absoluut.Strategy_1.Maximum.High.2011-06-16%2Chsw.Absoluut.Strategy_1.Maximum.High.2011-06-15%2Chsw.Absoluut.Strategy_1.Maximum.High.2011-06-14%2Chsw.Absoluut.Strategy_1.Maximum.High.2011-06-13%2Chsw.Absoluut.Strategy_2.Minimum.High.2011-06-22%2Chsw.Absoluut.Strategy_2.Minimum.High.2011-06-21%2Chsw.Absoluut.Strategy_2.Minimum.High.2011-06-20%2Chsw.Absoluut.Strategy_2.Minimum.High.2011-06-19%2Chsw.Absoluut.Strategy_2.Minimum.High.2011-06-18%2Chsw.Absoluut.Strategy_2.Minimum.High.2011-06-17%2Chsw.Absoluut.Strategy_2.Minimum.High.2011-06-16%2Chsw.Absoluut.Strategy_2.Minimum.High.2011-06-15%2Chsw.Absoluut.Strategy_2.Minimum.High.2011-06-14%2Chsw.Absoluut.Strategy_2.Minimum.High.2011-06-13%2Chsw.Absoluut.Strategy_3.Average.High.2011-06-22%2Chsw.Absoluut.Strategy_3.Average.High.2011-06-21%2Chsw.Absoluut.Strategy_3.Average.High.2011-06-20%2Chsw.Absoluut.Strategy_3.Average.High.2011-06-19%2Chsw.Absoluut.Strategy_3.Average.High.2011-06-18%2Chsw.Absoluut.Strategy_3.Average.High.2011-06-17%2Chsw.Absoluut.Strategy_3.Average.High.2011-06-16%2Chsw.Absoluut.Strategy_3.Average.High.2011-06-15%2Chsw.Absoluut.Strategy_3.Average.High.2011-06-14%2Chsw.Absoluut.Strategy_3.Average.High.2011-06-13%2Chsw.Absoluut.Strategy_4.Minimum.Low.2011-06-22%2Chsw.Absoluut.Strategy_4.Minimum.Low.2011-06-21%2Chsw.Absoluut.Strategy_4.Minimum.Low.2011-06-20%2Chsw.Absoluut.Strategy_4.Minimum.Low.2011-06-19%2Chsw.Absoluut.Strategy_4.Minimum.Low.2011-06-18%2Chsw.Absoluut.Strategy_4.Minimum.Low.2011-06-17%2Chsw.Absoluut.Strategy_4.Minimum.Low.2011-06-16%2Chsw.Absoluut.Strategy_4.Minimum.Low.2011-06-15%2Chsw.Absoluut.Strategy_4.Minimum.Low.2011-06-14%2Chsw.Absoluut.Strategy_4.Minimum.Low.2011-06-13%2Chsw.Absoluut.Strategy_5.Maximum.Low.2011-06-22%2Chsw.Absoluut.Strategy_5.Maximum.Low.2011-06-21%2Chsw.Absoluut.Strategy_5.Maximum.Low.2011-06-20%2Chsw.Absoluut.Strategy_5.Maximum.Low.2011-06-19%2Chsw.Absoluut.Strategy_5.Maximum.Low.2011-06-18%2Chsw.Absoluut.Strategy_5.Maximum.Low.2011-06-17%2Chsw.Absoluut.Strategy_5.Maximum.Low.2011-06-16%2Chsw.Absoluut.Strategy_5.Maximum.Low.2011-06-15%2Chsw.Absoluut.Strategy_5.Maximum.Low.2011-06-14%2Chsw.Absoluut.Strategy_5.Maximum.Low.2011-06-13%2Chsw.Absoluut.Strategy_6.Average.Low.2011-06-22%2Chsw.Absoluut.Strategy_6.Average.Low.2011-06-21%2Chsw.Absoluut.Strategy_6.Average.Low.2011-06-20%2Chsw.Absoluut.Strategy_6.Average.Low.2011-06-19%2Chsw.Absoluut.Strategy_6.Average.Low.2011-06-18%2Chsw.Absoluut.Strategy_6.Average.Low.2011-06-17%2Chsw.Absoluut.Strategy_6.Average.Low.2011-06-16%2Chsw.Absoluut.Strategy_6.Average.Low.2011-06-15%2Chsw.Absoluut.Strategy_6.Average.Low.2011-06-14%2Chsw.Absoluut.Strategy_6.Average.Low.2011-06-13&WIDTH=1264&HEIGHT=400"

Toelichting: getFullRequestString is een functie van OpenLayers die een complete GET-request opbouwt aan de hand van het WMSLayer object. Omdat ik veel parameters mee wens te geven doe ik het via POST ipv GET en daarvoor strip ik de url er weer uit, zodat ik de data overhoudt voor de jQuery POST.
Ik heb het ook met de OpenLayers Loadurl functie geprobeerd, maar die kan alleen GET doen en werkt ook niet. De rest van de ajaxrequests gebeuren overigens wel met OpenLayers Loadurl, maar zowel jQuery als OpenLayers gebruiken het ActiveX component om de ajaxrequest te doen.

Iemand een idee waar dit mis zou kunnen gaan?

[MueR]

Heb je ook ergens een foutmelding aan die klant weten te ontfutselen?

[PeaceNlove]

Nee, daar missen ze helaas de ict-intelligentie voor
Zou er wel een leuke message van kunnen maken, maar dan heb je alsnog dat het probleem verderop in jQuery voorkomt en daarom volgens mij niet de exacte message gaat geven met de fout. Correct me if I'm wrong...

[_naranya]

hang eens een error handler aan je call

JavaScript:

error: function(jqXHR, textStatus, errorThrown) { alert(errorThrown); }

[Voor 0% gewijzigd door _naranya op 14-06-2011 16:18. Reden: typo]

[PeaceNlove]

Heb de error toegevoegd en de gebruiker gemaild met de vraag een screenshot te maken van de foutmelding. Ik kom hier terug wanneer ik meer weet.

[Bosmonster]

Kun je niet beter dan even een debug-versie maken die de foutmeldingen gewoon naar een eigen server toe post?

Kun je er ook nog andere informatie bij meesturen (zoals useragent en vardump).

[Voor 27% gewijzigd door Bosmonster op 14-06-2011 16:16]

[noes]

Bosmonster schreef op dinsdag 14 juni 2011 @ 16:15:
Kun je niet beter dan even een debug-versie maken die de foutmeldingen gewoon naar een eigen server toe post?

Kun je er ook nog andere informatie bij meesturen (zoals useragent en vardump).

Goed idee, maar in dit geval niet handig: het probleem is dat de post nu niet werkt

[PeaceNlove]

De errormessage die ik heb toegevoegd ziet de klant helaas niet verschijnen, dus debugmessages naar de server sturen is geen optie, want ik zou dan niet weten waar in jQuery de logging naar de server ingebouwd zou moeten worden omdat de foutafhandeling in jQuery hier blijkbaar ook weinig mee kan...
Het enige wat ik nog kan doen is in mijn handler logging inbouwen om te checken of de POST uberhaupt gedaan wordt, maar ik ben bang dat ik met die kennis dan alsnog niet veel verder kom.

Toch jammer dat mijn V&A advertentie voor een magier die alle IE's over de hele wereld kon veranderen in een fatsoenlijke browser door de admins verwijderd is.

Bedankt voor het meedenken in ieder geval.

Ik ga de klant opdragen een fatsoenlijke browser te installerenhuilen en een memo schrijven voor de klant dat de huidige browser ongeschikt is ondanks uitvoerige testen van mij en dat ze het daar mee moeten doen.

[Voor 0% gewijzigd door PeaceNlove op 15-06-2011 10:43. Reden: typo]

[OkkE]

De $.ajax() functie van jQuery heeft een hoop callback-opties om het één en ander te achterhalen; zoals beforeSend, error, dataFilter, success en complete. Lijkt me sterk dat géén van deze functies je iets aan informatie opleveren...

[418O2]

Welk OS draai je? Ik zou even een VM maken (met win7 kan dat heel snel met de XP mode) en het dan native gaan testen.

Dit is geen doen natuurlijk. Mocht je eenmaal weten wat het probleem is, is het lastig oplossen omdat je het niet kan testen.

Welke jQuery versie gebruik je?

@OkkE: heeft IE geen issues met de fail callback van jQuery, daar staat me namelijk iets van bij.

[Voor 21% gewijzigd door 418O2 op 16-06-2011 17:22]

[R4gnax]

418O2 schreef op donderdag 16 juni 2011 @ 17:21:
@OkkE: heeft IE geen issues met de fail callback van jQuery, daar staat me namelijk iets van bij.

Deze zijn volgens mij al sinds de 1.4.x versies van jQuery verholpen. Met de rewrite van $.ajax() in de 1.5.x serie zijn ook resterende problemen met het aanroepen van abort() op een request verholpen. Daarnaast was er met de rewrite ook stevig werk gemaakt van issues met memory leaks in IE, als ik me goed herinner.

[beetle71]

't zou me ook niet verbazen als er in (of eigenlijk na) een eerder ajax request ergens iets fout gaat in de javascript laag waardoor de scripting disabled wordt. Aangezien je nu ook die foutmelding alert niet krijgt. Dan wordt de ajax call waar je het hier over hebt niet eens gestart.

[Anoniem: 402156]

Hoe kom je aan de evt variabelen (ik neem aan dat dit een Event object is?).

[PeaceNlove]

Anoniem: 402156 schreef op zondag 19 juni 2011 @ 14:56:
Hoe kom je aan de evt variabelen (ik neem aan dat dit een Event object is?).

Die evt wordt een eindje terug al aangemaakt en heeft niets te maken met dit hele verhaal
Verder ga ik hier nog terugkomen, maar had helaas het laatste deel van de week de sysadmin pet op

[PeaceNlove]

Het zal een raadsel blijven, want inmiddels mailt de klant dat het wel werkt. Misschien dat de browsercache ergens roet in het eten gooide ondanks dat ik de klant continue vertelde een complete refresh te doen...
Overigens gebruik ik jQuery 1.4.2, maar dat is mosterd na de maaltijd.

Overigens @beetle71: wat bedoel je daar precies mee? Niet alle scripting stond uit, want het hele project bestaat zo ongeveer alleen maar uit Javascript, met vanuit OpenLayers.js en jQuery.js een goede voorraad eventlisteners aan een heleboel mouseevents en de klant had me wel gemeld dat de rest ook zou hangen als de complete scripting was weggevallen.

[418O2]

Wat wel eens wil helpen, is willekeurige random-waardes meegeven in de URL, om te voorkomen dat IE of een proxy gaat cachen. Nu doe je een post dus zou dat in principe niet voor moeten komen, maar je kan het proberen.

[PeaceNlove]

418O2 schreef op maandag 20 juni 2011 @ 11:39:
Wat wel eens wil helpen, is willekeurige random-waardes meegeven in de URL, om te voorkomen dat IE of een proxy gaat cachen. Nu doe je een post dus zou dat in principe niet voor moeten komen, maar je kan het proberen.

Dank voor de tip. Doorgaans gebruik ik toch GET en mijn handlers zullen dingen als &Random=PEOP gewoon negeren

[R4gnax]

418O2 schreef op maandag 20 juni 2011 @ 11:39:
Wat wel eens wil helpen, is willekeurige random-waardes meegeven in de URL, om te voorkomen dat IE of een proxy gaat cachen. Nu doe je een post dus zou dat in principe niet voor moeten komen, maar je kan het proberen.

Zo'n cache buster heeft jQuery trouwens ook gewoon ingebouwd zitten:

JavaScript:

$.ajax({ cache: false })

[K-Jay]

Volgens mij heb ik ook wel eens gehad dat jQuery.ajax vreemd deed. Dat heb ik opgelost door jQuery.post() te gebruiken. Toen werkte het wel.

[R4gnax]

K-Jay schreef op woensdag 22 juni 2011 @ 12:38:
Volgens mij heb ik ook wel eens gehad dat jQuery.ajax vreemd deed. Dat heb ik opgelost door jQuery.post() te gebruiken. Toen werkte het wel.

jQuery.post is een shorthand syntax voor jQuery.ajax, welke door jQuery.post onder de kap ook gewoon nog gebruikt wordt. Het is dan ook niet zo 'dat jQuery.ajax vreemd doet'; je hebt het waarschijnlijk zelf gewoon verkeerd aangestuurd.

[Bosmonster]

In veel gevallen zul je de jQuery.ajax() ook niet nodig hebben, maar kun je prima uit de voeten met de (geoptimaliseerde) wrappers zoals get(), post(), getJSON(), etc.

Gebruik ajax() alleen als je specifieke extra functionaliteit nodig hebt en enigszins weet waar je mee bezig bent.

[R4gnax]

Bosmonster schreef op donderdag 23 juni 2011 @ 09:48:
In veel gevallen zul je de jQuery.ajax() ook niet nodig hebben, maar kun je prima uit de voeten met de (geoptimaliseerde) wrappers zoals get(), post(), getJSON(), etc.

Gebruik ajax() alleen als je specifieke extra functionaliteit nodig hebt en enigszins weet waar je mee bezig bent.

Eigenlijk ben ik van mening dat al die wrappers overboord gesmeten mogen worden. Het maakt de API alleen maar onnodig bloated. Het zijn wrappers die gewoon wat standaard waardes naar jQuery.ajax mee doorsturen, en dankzij die overhead per definitie minder efficient dan jQuery.ajax zelf. Verder ontbreekt bij allemaal ook nog eens een cruciaal element voor het ontwikkelen van een robuuste applicatie: ze ondersteunen geen van allen een error callback.

offtopic:
Je zou trouwens sowieso geen code moeten gaan schrijven als je niet weet waar je mee bezig bent.

[Voor 6% gewijzigd door R4gnax op 24-06-2011 09:09]

[YopY]

R4gnax schreef op vrijdag 24 juni 2011 @ 09:08:
[post]

* YopY post decomposen en ontkrachten doet

Eigenlijk ben ik van mening dat al die wrappers overboord gesmeten mogen worden. Het maakt de API alleen maar onnodig bloated.

Ik heb liever een bloated API dan dat ik zelf bloated code moet gaan schrijven om hetzelfde te doen.

Het zijn wrappers die gewoon wat standaard waardes naar jQuery.ajax mee doorsturen, en dankzij die overhead per definitie minder efficient dan jQuery.ajax zelf.

Cijfers? Feiten? Je neemt aan dat het minder efficient is, en d'r is dus een goeie kans dat je in het premature optimization-gat gaat vallen. Leesbare code schrijven is altijd belangrijker dan performance, zeker als je niet zeker kunt weten wat het performance-verschil is. Willekeurige schatting: De i/o, het afvuren van een AJAX-request en het verwerken van de respons, duren 100.000.000 keer langer dan de tijd die .post() neemt om .ajax() aan te roepen, zo niet oneindig meer. Ook is het een non-argument in moderne (lees: Javascript-geoptimaliseerde) browsers.

Meten == weten. Als je bij dit statement blijft wil ik graag harde cijfers die het schrijven van lelijke, bloated code t.o.v. het gebruiken van de facade methodes een overduidelijk performance-voordeel geven.

Verder ontbreekt bij allemaal ook nog eens een cruciaal element voor het ontwikkelen van een robuuste applicatie: ze ondersteunen geen van allen een error callback.

Welles. Sinds jQuery 1.6 (volgens mij) geven alle AJAX-functies een jqXHR-object terug, waar je alle handlers in kunt definieren als volgt:

JavaScript:

var jqXHR = $.post('bla', data);
jqXHR.success(function(data) { console.log(data) }
jqXHR.error(function(xhr, textStatus, errorThrown) { console.log(textStatus, errorThrown); }

[Bosmonster]

R4gnax schreef op vrijdag 24 juni 2011 @ 09:08:
[...]


Eigenlijk ben ik van mening dat al die wrappers overboord gesmeten mogen worden. Het maakt de API alleen maar onnodig bloated. Het zijn wrappers die gewoon wat standaard waardes naar jQuery.ajax mee doorsturen, en dankzij die overhead per definitie minder efficient dan jQuery.ajax zelf. Verder ontbreekt bij allemaal ook nog eens een cruciaal element voor het ontwikkelen van een robuuste applicatie: ze ondersteunen geen van allen een error callback.

offtopic:
Je zou trouwens sowieso geen code moeten gaan schrijven als je niet weet waar je mee bezig bent.

Ten eerste, zo'n wrapper doet niks meer dan het eenvoudiger maken de ajax-functie optimaal aan te roepen. De overhead is verwaarloosbaar, want dat is ongeveer de aanroep van een method.

Ten tweede, error-handling bij ajax is echt niet altijd nodig. Sterker nog, meestal heb je het niet nodig bij eenvoudige calls en hoef je alleen te weten of het goed gaat en dan iets te doen. Meestal komt het ook neer op eenvoudig wat json ophalen oid. De gebruiker wil je toch niet lastigvallen met foutmeldingen. Daarnaast geven de wrappers tegenwoordig ook gewoon het XHR-object terug en kun je dus alles uitlezen wat je wilt.

Je hebt het bovendien over "applicaties", maar als je applicaties wilt schrijven is het sowieso de vraag of jQuery je beste keuze is. De kracht van jQuery ligt voornamelijk in supersnel dynamiek toevoegen aan je website, niet in het ontwikkelen van complete applicaties. Dat eerste scenario is ook waar jQuery 9/10x voor gebruikt wordt.

Verder is je laatste statement natuurlijk ook onzin. jQuery is er juist om de drempel te verlagen van xbrowser development. Je hoeft echt geen XHR-koning te zijn om een stukje dynamische website te mogen ontwikkelen. Beetje arrogante houding.

Zelfs een ervaren developer wil snel en efficient kunnen ontwikkelen, ipv geforceerd de meest complexe oplossing te moeten kiezen. Als je zo door gaat redeneren kun je heel jQuery wel afschaffen, want dan is een framework gebruiken sowieso natuurlijk inefficient en amateuristisch volgens jou

[Voor 7% gewijzigd door Bosmonster op 25-06-2011 22:29]

[R4gnax]

YopY schreef op zaterdag 25 juni 2011 @ 20:29:
[...]

Cijfers? Feiten? Je neemt aan dat het minder efficient is, en d'r is dus een goeie kans dat je in het premature optimization-gat gaat vallen. Leesbare code schrijven is altijd belangrijker dan performance, zeker als je niet zeker kunt weten wat het performance-verschil is.

Lees even:

Bosmonster schreef op donderdag 23 juni 2011 @ 09:48:
In veel gevallen zul je de jQuery.ajax() ook niet nodig hebben, maar kun je prima uit de voeten met de (geoptimaliseerde) wrappers zoals get(), post(), getJSON(), etc.

Dit is geformuleerd op een wijze die doet denken dat de wrappers sneller zouden zijn dan de handmatige call. Dat is het enige wat ik wilde ontkrachten. Het handmatig aanroepen van jQuery.ajax zal inderdaad niet substantieel sneller zijn.

YopY schreef op zaterdag 25 juni 2011 @ 20:29:
Welles. Sinds jQuery 1.6 (volgens mij) geven alle AJAX-functies een jqXHR-object terug, waar je alle handlers in kunt definieren als volgt:

JavaScript:

var jqXHR = $.post('bla', data);
jqXHR.success(function(data) { console.log(data) }
jqXHR.error(function(xhr, textStatus, errorThrown) { console.log(textStatus, errorThrown); }

Wat ook werkt als de respons direct uit cache komt, omdat jqXHR met een promise patroon werkt. Dat klopt. Chapeau, hier had ik inderdaad nog niet aan gedacht.

Bosmonster schreef op zaterdag 25 juni 2011 @ 22:24:
Verder is je laatste statement natuurlijk ook onzin. jQuery is er juist om de drempel te verlagen van xbrowser development. Je hoeft echt geen XHR-koning te zijn om een stukje dynamische website te mogen ontwikkelen. Beetje arrogante houding.

Zelfs een ervaren developer wil snel en efficient kunnen ontwikkelen, ipv geforceerd de meest complexe oplossing te moeten kiezen. Als je zo door gaat redeneren kun je heel jQuery wel afschaffen, want dan is een framework gebruiken sowieso natuurlijk inefficient en amateuristisch volgens jou

Dat laatste statement is behoorlijk hyperbool, niet waar?

jQuery is wel bij uitstek geschikt om alle browser-specifieke narigheid te omkapselen en krom opgezette DOM APIs recht te trekken en met kortere, beter leesbare code aan te sturen. Dat verlaagt dan natuurlijk dus ook de drempel voor het werken met DOM en daarbij komende zaken.

Wat jaartjes geleden had je ook zo'n framework die voor de zelfstandige consument de drempel verlaagde voor het opbouwen van zijn eigen dynamische Personal HomePage. Juist ja; PHP. En de rans die voortvloeide uit mensen die klakkeloos stukjes slechte PHP code kopieerden (zolang het maar werktte, was het goed) was niet van de lucht. Daarom dus: mensen die niet weten waar ze mee bezig zijn, moeten niet code gaan schrijven. En zeker niet in een gevoelige omgeving zoals het web.

Dat wil niet zeggen dat beginners geen jQuery zouden moeten gebruiken, maar wèl dat ze wat tijd zouden moeten steken in het lezen van de APIs. Daarna kan dan bijvoorbeeld tot een geinformeerde conclusie gekomen worden of de shorthands of de volledige jQuery.ajax syntax gebruikt moeten worden.

Bosmonster schreef op zaterdag 25 juni 2011 @ 22:24:
Je hebt het bovendien over "applicaties", maar als je applicaties wilt schrijven is het sowieso de vraag of jQuery je beste keuze is. De kracht van jQuery ligt voornamelijk in supersnel dynamiek toevoegen aan je website, niet in het ontwikkelen van complete applicaties. Dat eerste scenario is ook waar jQuery 9/10x voor gebruikt wordt.

De lijn tussen applicatie en website wordt behoorlijk vaag bij grotere websites die veel interactie bevatten. Toch kun je dan nog niet kiezen voor een echt applicatie framework zoals ExtJS. jQuery is dan toch een goede keus, mits je goed gestructureerde en gesepareerde code er boven op schrijft.

[YopY]

jQuery als front-end applicatieframework zou ik niet echt aanprijzen, op het moment, o.a. omdat je, mits je niet uitkijkt, best wel ranzige, niet-modulaire code kunt krijgen. Een lichtgewicht alternatief voor een zwaargewicht als ExtJS is Backbone, een JS front-end MVC framework. Een iets lichter / onofficiëler alternatief is Sammy. Een convention-over-configuration laag bovenop Backbone (die in mijn ervaring niet goed werkt, overigens) is Faux.

JS frameworks springen (weer) als paddestoelen uit de grond, .

[Bosmonster]

Met YopY. jQuery is wel prima als basis (Sammy gebruikt ook jQuery en bij Backbone is het ook aangeraden), maar voor serieuzer applicatie-werk heb je er een laag boven nodig. Die kun je ook wel zelf ontwikkelen natuurlijk met wat kennis van design patterns. Maar het schaadt niet daar een extra uitbreiding voor te pakken.

Die laag heb je echter voor de gemiddelde website die je wilt voorzien van wat (custom) plugins niet nodig. Daar is de plugin-architectuur van jQuery ruim afdoende voor structuur.

[Voor 22% gewijzigd door Bosmonster op 27-06-2011 14:02]