Dat idee had ik net ook weer toen ik een tijd ernaar keek. Maar speel maar een beetje met in en uitloggen en bijde browsers open. Op een gegeven moment gaat ie vaag doen.
[edit]
Het probleem met het verkrijgen van oude data is verholpen!! IE heeft een unieke url nodig die naar de server gestuurd wordt. Ik plak nu met Math.random() een uniek cijfer achter de url en dat werkt prima
Dit werkt prima. Heb 2 timers lopen die 'tegelijk' ieder een bepaalde div in de pagina updaten. Maar als ik dat stukje in mijn ander code verwerk. Krijg ik in FF alleen de gamers geupdate, en status update werkt niet (zou steeds een . erbij moeten komen) En in IE loopt de status vrolijk vol met puntjes... en op een gegeven moment komen de gamers er pas bij. Zit er nog een soort van timing probleem met ajax ofzo?
Laat ik OF update gamers OF update status uit. Wekt het prima
oké, goed dat het werkt, kan nu mijn uitleg ook geven en ook een tip, want dit is idd niet een al te goeie oplossing.
Dus die var "http" is dus een object die op het internet achter een site gaat. Terwijl dat object nog bezig is met op het internet te zoeken. Zet je dat hij een andere site moet gaan bezoeken. Hier zit dan ook het probleem. De site is nog niet geladen als je het object vraagt om een andere site te gaan halen.
Nu heb ik dit opgelost met elke keer een nieuwe "http"-object aan te maken (dit is slecht). Hiervan zou ik oftewel drie objecten van maken (voor elke request die je om de 1 seconde doet) oftewel een http-manager maakt. Die slaat dan op welke urls er nog bezocht moeten worden en bezoekt ze één voor één (nadat de vorige is ingeladen).
Ik laat het voorlopig nog even zo. Het is idd zoals we alle 2 zeggen niet de meest nette oplossing. Maar zo kan ik voorlopig wel verder gaan knutselen hiermee
Uiteindelijk zijn er een aantal opties om dit netjes af te handelen:
1. Per update functie een eigen http object (+ evt manager)
2. Een 'http-object' pool. Oftewel. Zorg dat er voldoende (niet TE veel) http objecten beschikbaar zijn en 'deel' deze uit aan de functie die ze nodig heeft.
3. Maak 1 http-object manager die 1 of meerdere http-objecten heeft en die zorgt voor een nette afhandeling (evt met priority en een wachtrij).
De eerste oplossing is het gemakkelijkst, maar het minst mooi. De tweede oplossing is het moeilijkst en zou ik niet doen. (Wat als je te weinig http-objecten hebt). Dus blijft de laatste alleen over.
Ik kies dit omdat de data die je hierdoor verkrijgt niet dringend is. De data moet gewoon up2date zijn, maar als er een happering van een paar seconden inzit is het geen probleem. Hiervoor zou ik alleen een wachtrij maken. (priority is overbodig denk ik)
//aangezien je toch redelijk wat kan scripten, zal ik het niet helemaal zelf schrijven.
var http = createRequestObject();
var wachtlijst = Array();
var status = "idle";
function sendrequest(url)
{
wachtlijst[wachtlijst.length] = url;
manager();
}
function manager()
{
if(status == "idle" && wachtlijst.length != 0)
{
//kom in actie
status = "busy";
http.open('get', wachtlijst.shift());
http.onreadystatechange = handleResponse;
http.send(null);
function handleResponse() {
if(http.readyState == 4) {
//doe iets met de data
//zetten dat hij klaar is => volgende beginnen.
status = "idle";
manager();
}
}
}
}
//aangezien je toch redelijk wat kan scripten, zal ik het niet helemaal zelf schrijven.
Ja dat programmeren lukt me wel.
Opzich is die 2e oplossing wel de meest nette oplossing in mijn ogen. Je moet het systeem dan zo slim maken dat het altijd een aantal http-objecten over houdt. Heeft ie er op een gegeven moment teveel, verwijderd ie er een aantal. Zijn er tekort, maakt hij nieuwe bij.
Dit zie je veel in de wat groteren software projecten. Heb het zelf ooit gebruikt in een asp.NET webapp waarbij artsen in een ziekenhuis patientdata kunnen opvragen. Dit ging soms door zoveel artsen tegelijk, dat de server het moeilijk had door de vele requests. Dan is een pool erg handig en nuttig. Je kan die objecten dan ook een verloopdatum meegeven, zodat je patientobject wel uptodate is
Dit zal echter voor deze eenvoudige site niet nodig zijn.