Jquery gaat te snel in internet explorer

[Verwijderd]

Hoi,

Nu mijn website ver af is ben ik begonnen met het testen van de verschillende functies in verschillende browsers. Eerlijkheidshalve moet ik toegeven dat dit project mijn eerste website in combinatie met Jquery is en dat levert nu ook een probleem op.
Op een bepaalde pagina gebeurd het volgende.
- Bezoeker komt binnen
- Er wordt gekeken of er al een value aan de bezoeker vast zit. Zoniet krijgt bezoeker value '10'
- Bezoeker kan klikken op de button 10, 25, 50, 100 en op die manier wordt automatisch zijn value geupdate in de database en wordt de pagina automatisch vernieuwd naar value 'x'
- De value die vast zit aan de gebruiker is dikgedrukt.

Zodra de gebruiker op de button klikt gebeurt het volgende in volgerde:
1 - database wordt geupdate
2 - ouwe data fade out
3 - nieuwe data fade out.

In firefox gaat dit allemaal prima, maar in bijvoorbeeld internet explorer blijft de oude data 9 van de 10 keer staan en moet ik nog een keer drukken voordat hij de nieuwe dat laadt. Dat betekent dus dat IE nog de oude data laadt voor de nieuwe erin gezet is. Hieronder mijn jquery code:

JavaScript:

 $(document).ready(function () {
            $('#amount10').live('click', function () {
               $.post('includes/update.php', { value: '10' });
                 $("#main_results").fadeOut('fast').delay(250).load("includes/results.php" + "?" + new Date().getTime()).fadeIn("slow");
          $("#choose_amount").fadeOut('fast').delay(250).load("includes/amount.php" + "?" + new Date().getTime()).fadeIn("slow");
                        
            });
             $('#amount25').live('click', function () {
               $.post('includes/update.php', { value: '25' });
                 $("#main_results").fadeOut('fast').delay(250).load("includes/results.php" + "?" + new Date().getTime()).fadeIn("slow");
          $("#choose_amount").fadeOut('fast').delay(250).load("includes/amount.php" + "?" + new Date().getTime()).fadeIn("slow");
           
                
            });
             $('#amount50').live('click', function () {
                $.post('includes/update.php', { value: '50' });
                
                 $("#main_results").fadeOut('fast').delay(250).load("includes/results.php" + "?" + new Date().getTime()).fadeIn("slow");
          $("#choose_amount").fadeOut('fast').delay(250).load("includes/amount.php" + "?" + new Date().getTime()).fadeIn("slow");
           
                
            });
             $('#amount100').live('click', function () {
                 
                $.post('includes/update.php', { value: '100' });
                
                 $("#main_results").fadeOut('fast').delay(250).load("includes/results.php" + "?" + new Date().getTime()).fadeIn("slow");
          $("#choose_amount").fadeOut('fast').delay(250).load("includes/amount.php" + "?" + new Date().getTime()).fadeIn("slow");
                
            });
 
        });

De database wordt dus weldegelijk geupdate, maar het terug inladen gaat mis.

[Bosmonster]

IE is iets hardnekkiger met z'n cache. Zorg dus voor de juiste cache-headers.

[Jeldert]

Ajax (en dus je post) is asynchroon. Wat er dus gebeurt is dat je post niet altijd klaar is, terwijl je wel al een call doet om "nieuwe" data op te halen.
Wat je dus moet doen is wachten tot je post klaar is, en dan pas de nieuwe data ophalen. Dit kan eenvoudig met een callback:

JavaScript:

$.post('includes/update.php', { value: '10' }, function(data)) {
    $("#main_results").fadeOut('fast').delay(250).load("includes/results.php" + "?" + new Date().getTime()).fadeIn("slow"); 
    $("#choose_amount").fadeOut('fast').delay(250).load("includes/amount.php" + "?" + new Date().getTime()).fadeIn("slow");
});

Om caching te voorkomen kan je eenvoudig dit (1 maal) uitvoeren, zodat je niet overal zelf een random iets aan je URL toe te voegen:

JavaScript:

$.ajaxSetup({
    cache: false
});

[R4gnax]

Jeldert schreef op donderdag 27 oktober 2011 @ 14:28:
Ajax (en dus je post) is asynchroon.

En datzelfde geldt ook voor de load functie, dus kan het ook nog zo zijn dat de fadeIn animatie al start voordat die requests compleet zijn.

De TS zal inderdaad nog even moeten wennen aan het asynchrone model van jQuery. In het bijzonder wanneer je meerdere asynchrone sporen naast elkaar hebt lopen die wel op bepaalde punten moeten synchen kan dat lastig zijn. Of eigenlijk; kon dat lastig zijn. Met deferred objects en promises is dat allemaal een stukje makkelijker geworden...

JavaScript:

$
  .when(
    $.post( "includes/update.php", { value : 10 }),
    $( "#main_results" ).fadeOut( "fast" ).promise(),
    $( "#choose_amount" ).fadeOut( "fast" ).promise()
  )
  .then(function(){
    $
      .when(
        $.get( "includes/results.php" ),
        $.get( "includes/amount.php" ),
        $.Deferred( function( deferred ) { setTimeout( deferred.resolve, 250 ); })
      )
      .then( function( resultsArgs, amountArgs ) {
        $( "#main_results" ).html( resultsArgs[ 0 ]).fadeIn( "slow" );
        $( "#choose_amount" ).html( amountArgs[ 0 ]).fadeIn( "slow" );
      });
  });

Wat ik me afvraag is waarom je drie AJAX requests nodig hebt. Waarom zou je de resultaten van de includes/results.php en includes/amount.php requests niet terug kunnen sturen als de response op includes/update.php?

[Morphine]

R4gnax schreef op donderdag 27 oktober 2011 @ 20:47:
[...]


De TS zal inderdaad nog even moeten wennen aan het asynchrone model van jQuery. In het bijzonder wanneer je meerdere asynchrone sporen naast elkaar hebt lopen die wel op bepaalde punten moeten synchen kan dat lastig zijn. Of eigenlijk; kon dat lastig zijn. Met deferred objects en promises is dat allemaal een stukje makkelijker geworden...

indien nodig kan je bij ajax functies async op false zetten.

[R4gnax]

Morphine schreef op donderdag 27 oktober 2011 @ 20:50:
[...]


indien nodig kan je bij ajax functies async op false zetten.

En daarmee bevries je dan gelijk de hele pagina en in sommige gevallen de hele browser van de gebruiker, terwijl er gewacht wordt op antwoord van de server. Als de gebruiker dan ook nog een beetje schommelende kwaliteit verbinding heeft (bijvoorbeeld mobiel) kan deze ook nog wel eens 10 seconden of zo op een timeout gaan zitten wachten.

XmlHttpRequests in synchronous modus gebruiken zou nooit en te nimmer een optie moeten zijn. Jammer genoeg is het iets waar al snel op terug gevallen wordt door programmeurs voor welke asynchrone logica en synchronisatie buiten hun 'comfort zone' vallen.

"If all you have is a hammer, everything looks like a nail." zegt men dan heel mooi.

[ Voor 5% gewijzigd door R4gnax op 28-10-2011 08:55 ]

[Spockz]

Als je dan de requests toch synchroon wilt uitvoeren, kijk dan eens naar zogenaamde "AJAX Queues", zoals http://plugins.jquery.com/project/ajaxqueue. Je kan dit ook makkelijk zelf doen door een queue variabele bij te houden en de event functies die je normaal aan je ajax call meegeeft te wrappen in je eigen functies die de queue afhandelen.

[R4gnax]

Spockz schreef op vrijdag 28 oktober 2011 @ 09:25:
Als je dan de requests toch synchroon wilt uitvoeren, kijk dan eens naar zogenaamde "AJAX Queues", zoals http://plugins.jquery.com/project/ajaxqueue. Je kan dit ook makkelijk zelf doen door een queue variabele bij te houden en de event functies die je normaal aan je ajax call meegeeft te wrappen in je eigen functies die de queue afhandelen.

Omdat deze plugin nog op het oude ajax systeem (van voor jQuery 1.5) gebaseerd is, maakt deze intern ook nog gebruik van de oude success/error/complete callbacks. Die zullen in jQuery 1.7 formeel als deprecated gemarkeerd gaan worden. Vraag is of het dan slim is om deze plugin nog te gaan gebruiken.

Het is ook nergens voor nodig; jQuery heeft queuing en synchronization ingebouwd zitten dankzij de nieuwe promise interface die door ajax requests en queues (o.a. de 'fx' animatie queue, maar ook user-defined queues) geimplementeerd wordt. Alleen wordt dan wel van de programmeur verwacht dat deze een beetje de tijd neemt om zich deze APIs eigen te maken. Het is niet zo ''fire-and-forget' als een prefab plugin.