Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PHP + Ajax + progress meter
1 view
Skip to first unread message
Martin
Apr 26, 2012, 4:21:58 AM4/26/12
to
Hej,
Er det muligt at lave en progress bar ved ajax kald.
Lad mig give et eksempel, min PHP gør som sådan ikke noget men der er 4
funktioner som udskriver en tekst.
// ajax.php
<?php
class Dosomething {
public function __construct() {
echo self::test1();
sleep(5);
echo self::test2();
sleep(5);
echo self::test3();
sleep(5);
echo self::test4();
}
static private function test1() { echo 25; }
static private function test1() { echo 50; }
static private function test1() { echo 75; }
static private function test1() { echo 100; }
}
new Dosomething;
Nu vil jeg så gerne have mit ajax til ikke at stoppe med at lytte indtil
det får 100 retur - er det muligt på en eller anden måde?
Er det muligt at lave en progress bar ved ajax kald.
Lad mig give et eksempel, min PHP gør som sådan ikke noget men der er 4
funktioner som udskriver en tekst.
// ajax.php
<?php
class Dosomething {
public function __construct() {
echo self::test1();
sleep(5);
echo self::test2();
sleep(5);
echo self::test3();
sleep(5);
echo self::test4();
}
static private function test1() { echo 25; }
static private function test1() { echo 50; }
static private function test1() { echo 75; }
static private function test1() { echo 100; }
}
new Dosomething;
Nu vil jeg så gerne have mit ajax til ikke at stoppe med at lytte indtil
det får 100 retur - er det muligt på en eller anden måde?
Jonathan Stein
Apr 26, 2012, 11:36:22 AM4/26/12
to
Den 26-04-2012 10:21, Martin skrev:
> Nu vil jeg så gerne have mit ajax til ikke at stoppe med at lytte indtil
> det får 100 retur - er det muligt på en eller anden måde?
Det har ikke så meget med PHP at gøre, så jeg har ændret FUT til
> Nu vil jeg så gerne have mit ajax til ikke at stoppe med at lytte indtil
> det får 100 retur - er det muligt på en eller anden måde?
clientside gruppen.
Men overordnet skal du:
- Lave dit request asynkront.
- Når dit objekt skifter readyState til 3 (LOADING), skal du begynde at
kigge på responseText. Brug "onreadystatechange" til at detektere når
objektet skifter state. Brug setTimeout til at holde pause.
responseText indeholder hele det modtagne svar, så for hver timeout,
skal du se, om den er ændret.
Du bør nok holde øje med, om readyState ændrer sig, så dit script ikke
bliver ved med at vente på "100", hvis der opstår en fejl.
Alternativt skal du jævnligt lave et kald til serveren for at høre hvor
langt, den er nået.
M.v.h.
Jonathan
Anders Wegge Keller
Apr 26, 2012, 1:06:45 PM4/26/12
to
Jonathan Stein <jst...@image.dk> writes:
> Den 26-04-2012 10:21, Martin skrev:
>
> > Nu vil jeg så gerne have mit ajax til ikke at stoppe med at lytte indtil
> > det får 100 retur - er det muligt på en eller anden måde?
>
> Det har ikke så meget med PHP at gøre, så jeg har ændret FUT til
> clientside gruppen.
Der er lige en enkelt server-side betragtning. I Chrome bliver
> Den 26-04-2012 10:21, Martin skrev:
>
> > Nu vil jeg så gerne have mit ajax til ikke at stoppe med at lytte indtil
> > det får 100 retur - er det muligt på en eller anden måde?
>
> Det har ikke så meget med PHP at gøre, så jeg har ændret FUT til
> clientside gruppen.
responseText kun opdateret løbende, hvis Content-Type er sat til noget
andet end text/html. Jeg skal ikke kunne sige om der er andre værdier
der også giver ballade, men det virker ihvertfald fortriligt, hvis man
sætter den til application/x-text:
header("Content-Type: application/x-text");
> Men overordnet skal du:
>
> - Lave dit request asynkront.
>
> - Når dit objekt skifter readyState til 3 (LOADING), skal du begynde
> at kigge på responseText. Brug "onreadystatechange" til at detektere
> når objektet skifter state. Brug setTimeout til at holde pause.
skal man ikke gøre andet end at læne sig tilbage og vente.
--
/Wegge
Leder efter redundant peering af dk.*,linux.debian.*
Birger Sørensen
Apr 26, 2012, 1:24:11 PM4/26/12
to
Anders Wegge Keller skrev:
W3C's dokumentation
http://www.w3.org/TR/XMLHttpRequest/
er stadig kun et draft, så man skla nok ikke forvente at browserne
reagerer ens.
Så ved redaySTate alt andet end 4, ville jeg ikke regne med data -
uanset om de læses fra responseXML, responseText eller responseBody.
Har også betænkeligheder ved at bruge onreadystatechange til en
progressbar.
Det rigtige for spørgeren må stadig være, at udstyre det PHP object der
udfører opgaven, med en funktion der kan fortælle hvor langt det er
nået, og så læse den med et (andet) AJAX-kald.
Birger
--
http://varmeretter.dk - billig, sund og hurtig mad
http://skippersevent.dk
http://www.w3.org/TR/XMLHttpRequest/
er stadig kun et draft, så man skla nok ikke forvente at browserne
reagerer ens.
Så ved redaySTate alt andet end 4, ville jeg ikke regne med data -
uanset om de læses fra responseXML, responseText eller responseBody.
Har også betænkeligheder ved at bruge onreadystatechange til en
progressbar.
Det rigtige for spørgeren må stadig være, at udstyre det PHP object der
udfører opgaven, med en funktion der kan fortælle hvor langt det er
nået, og så læse den med et (andet) AJAX-kald.
Birger
--
http://varmeretter.dk - billig, sund og hurtig mad
http://skippersevent.dk
Anders Wegge Keller
Apr 26, 2012, 1:41:39 PM4/26/12
to
Birger Sørensen <s...@bbsorensen.com> writes:
> W3C's dokumentation http://www.w3.org/TR/XMLHttpRequest/ er stadig
> kun et draft, så man skla nok ikke forvente at browserne reagerer
> ens. Så ved redaySTate alt andet end 4, ville jeg ikke regne med
> data - uanset om de læses fra responseXML, responseText eller
> responseBody.
Det er korrekt. Omvendt har responseText været i dokumentet siden den
> W3C's dokumentation http://www.w3.org/TR/XMLHttpRequest/ er stadig
> kun et draft, så man skla nok ikke forvente at browserne reagerer
> ens. Så ved redaySTate alt andet end 4, ville jeg ikke regne med
> data - uanset om de læses fra responseXML, responseText eller
> responseBody.
første draft, og i alle tilfælde - som jeg lige kan se det - udstyret
med en MUST. Så sandsynligheden for at den forsvinder i den enedelige
standard, er nok ikke så stor.
Birger Sørensen
Apr 26, 2012, 4:02:57 PM4/26/12
to
Anders Wegge Keller sendte dette med sin computer:
selv, når readyState er andet end 4.
Og under alle omstændigheder, så handler det om output - altså hvor
meget PHP har sendt - og ikke hvor langt scriptet er.
> Birger Sørensen <s...@bbsorensen.com> writes:
>
>> W3C's dokumentation http://www.w3.org/TR/XMLHttpRequest/ er stadig
>> kun et draft, så man skla nok ikke forvente at browserne reagerer
>> ens. Så ved redaySTate alt andet end 4, ville jeg ikke regne med
>> data - uanset om de læses fra responseXML, responseText eller
>> responseBody.
>
> Det er korrekt. Omvendt har responseText været i dokumentet siden den
> første draft, og i alle tilfælde - som jeg lige kan se det - udstyret
> med en MUST. Så sandsynligheden for at den forsvinder i den enedelige
> standard, er nok ikke så stor.
Jeg er ikke sikker på at der returneres meget andet end readyState
>
>> W3C's dokumentation http://www.w3.org/TR/XMLHttpRequest/ er stadig
>> kun et draft, så man skla nok ikke forvente at browserne reagerer
>> ens. Så ved redaySTate alt andet end 4, ville jeg ikke regne med
>> data - uanset om de læses fra responseXML, responseText eller
>> responseBody.
>
> Det er korrekt. Omvendt har responseText været i dokumentet siden den
> første draft, og i alle tilfælde - som jeg lige kan se det - udstyret
> med en MUST. Så sandsynligheden for at den forsvinder i den enedelige
> standard, er nok ikke så stor.
selv, når readyState er andet end 4.
Og under alle omstændigheder, så handler det om output - altså hvor
meget PHP har sendt - og ikke hvor langt scriptet er.
Anders Wegge Keller
Apr 26, 2012, 4:15:34 PM4/26/12
to
Birger Sørensen <s...@bbsorensen.com> writes:
> Anders Wegge Keller sendte dette med sin computer:
> > Birger Sørensen <s...@bbsorensen.com> writes:
> >
> >> W3C's dokumentation http://www.w3.org/TR/XMLHttpRequest/ er stadig
> >> kun et draft, så man skla nok ikke forvente at browserne reagerer
> >> ens. Så ved redaySTate alt andet end 4, ville jeg ikke regne med
> >> data - uanset om de læses fra responseXML, responseText eller
> >> responseBody.
> >
> > Det er korrekt. Omvendt har responseText været i dokumentet siden den
> > første draft, og i alle tilfælde - som jeg lige kan se det - udstyret
> > med en MUST. Så sandsynligheden for at den forsvinder i den enedelige
> > standard, er nok ikke så stor.
> Jeg er ikke sikker på at der returneres meget andet end readyState
> selv, når readyState er andet end 4.
Så skal du nærlæse dokumentet. Det er lidt gemt, men så snart
> Anders Wegge Keller sendte dette med sin computer:
> > Birger Sørensen <s...@bbsorensen.com> writes:
> >
> >> W3C's dokumentation http://www.w3.org/TR/XMLHttpRequest/ er stadig
> >> kun et draft, så man skla nok ikke forvente at browserne reagerer
> >> ens. Så ved redaySTate alt andet end 4, ville jeg ikke regne med
> >> data - uanset om de læses fra responseXML, responseText eller
> >> responseBody.
> >
> > Det er korrekt. Omvendt har responseText været i dokumentet siden den
> > første draft, og i alle tilfælde - som jeg lige kan se det - udstyret
> > med en MUST. Så sandsynligheden for at den forsvinder i den enedelige
> > standard, er nok ikke så stor.
> Jeg er ikke sikker på at der returneres meget andet end readyState
> selv, når readyState er andet end 4.
readystate er 3 eller 4, skal responseText indeholde det der allerede
er modtaget fra serveren, medmindre det dokument der sendes kommer med
en XML-content type.
> Og under alle omstændigheder, så handler det om output - altså hvor
> meget PHP har sendt - og ikke hvor langt scriptet er.
Birger Sørensen
Apr 26, 2012, 6:04:27 PM4/26/12
to
Anders Wegge Keller kom med følgende:
Hvor mange gange sendes data fra PHP - er det styret af tid eller
mængde, størrelsen på en buffer, et eller andet sted?
Jeg ved ikke om PHP har en output buffer man kan styre, så kan man
måske ad den vej. Ellers bliver det som jeg ser det, en temmelig
tilfældig opdatering af progress baren.
Og der må også bliver nogle problemer clientside, med at holde styr på
hvor mange data der er modtaget, og sortere dem fra - med mindre
readyState 3 giver mulighed for at se den nys modtagne delmængde...
> Birger Sørensen <s...@bbsorensen.com> writes:
>
>> Anders Wegge Keller sendte dette med sin computer:
>>> Birger Sørensen <s...@bbsorensen.com> writes:
>>>
>>>> W3C's dokumentation http://www.w3.org/TR/XMLHttpRequest/ er stadig
>>>> kun et draft, så man skla nok ikke forvente at browserne reagerer
>>>> ens. Så ved redaySTate alt andet end 4, ville jeg ikke regne med
>>>> data - uanset om de læses fra responseXML, responseText eller
>>>> responseBody.
>>>
>>> Det er korrekt. Omvendt har responseText været i dokumentet siden den
>>> første draft, og i alle tilfælde - som jeg lige kan se det - udstyret
>>> med en MUST. Så sandsynligheden for at den forsvinder i den enedelige
>>> standard, er nok ikke så stor.
>
>> Jeg er ikke sikker på at der returneres meget andet end readyState
>> selv, når readyState er andet end 4.
>
> Så skal du nærlæse dokumentet. Det er lidt gemt, men så snart
> readystate er 3 eller 4, skal responseText indeholde det der allerede
> er modtaget fra serveren, medmindre det dokument der sendes kommer med
> en XML-content type.
Du mener det dokument, der endnu kun er draft?
>
>> Anders Wegge Keller sendte dette med sin computer:
>>> Birger Sørensen <s...@bbsorensen.com> writes:
>>>
>>>> W3C's dokumentation http://www.w3.org/TR/XMLHttpRequest/ er stadig
>>>> kun et draft, så man skla nok ikke forvente at browserne reagerer
>>>> ens. Så ved redaySTate alt andet end 4, ville jeg ikke regne med
>>>> data - uanset om de læses fra responseXML, responseText eller
>>>> responseBody.
>>>
>>> Det er korrekt. Omvendt har responseText været i dokumentet siden den
>>> første draft, og i alle tilfælde - som jeg lige kan se det - udstyret
>>> med en MUST. Så sandsynligheden for at den forsvinder i den enedelige
>>> standard, er nok ikke så stor.
>
>> Jeg er ikke sikker på at der returneres meget andet end readyState
>> selv, når readyState er andet end 4.
>
> Så skal du nærlæse dokumentet. Det er lidt gemt, men så snart
> readystate er 3 eller 4, skal responseText indeholde det der allerede
> er modtaget fra serveren, medmindre det dokument der sendes kommer med
> en XML-content type.
>
>> Og under alle omstændigheder, så handler det om output - altså hvor
>> meget PHP har sendt - og ikke hvor langt scriptet er.
>
> Øh?
Kan godt se, den ikke kom rigtigt ud :/
>> Og under alle omstændigheder, så handler det om output - altså hvor
>> meget PHP har sendt - og ikke hvor langt scriptet er.
>
> Øh?
Hvor mange gange sendes data fra PHP - er det styret af tid eller
mængde, størrelsen på en buffer, et eller andet sted?
Jeg ved ikke om PHP har en output buffer man kan styre, så kan man
måske ad den vej. Ellers bliver det som jeg ser det, en temmelig
tilfældig opdatering af progress baren.
Og der må også bliver nogle problemer clientside, med at holde styr på
hvor mange data der er modtaget, og sortere dem fra - med mindre
readyState 3 giver mulighed for at se den nys modtagne delmængde...
Anders Wegge Keller
Apr 26, 2012, 6:32:34 PM4/26/12
to
Birger Sørensen <s...@bbsorensen.com> writes:
> Anders Wegge Keller kom med følgende:
>> Så skal du nærlæse dokumentet. Det er lidt gemt, men så snart
>> readystate er 3 eller 4, skal responseText indeholde det der allerede
>> er modtaget fra serveren, medmindre det dokument der sendes kommer med
>> en XML-content type.
> Du mener det dokument, der endnu kun er draft?
Ja, og som er grundlaget for at vi overhovedet kan tale om Ajax. Og
som sagt, en formulering der har været i samtlige drafts i de sidste
seks år.
> Kan godt se, den ikke kom rigtigt ud :/ Hvor mange gange sendes data
> fra PHP - er det styret af tid eller mængde, størrelsen på en
> buffer, et eller andet sted?
Det er noget der styres af webserveren. I php kan man bruge flush()
til at "tvinge"[1] output ud til klienten.
> Jeg ved ikke om PHP har en output buffer man kan styre, så kan man
> måske ad den vej. Ellers bliver det som jeg ser det, en temmelig
> tilfældig opdatering af progress baren.
Det er korrekt. Omvendt giver en one-shot poll fra clientside heller
ingen garanti for at der ikke kommer nogle gevaldige ryk, medmindre
man poller ofte. Så i de tilfælde hvor det kan lade sig gøre, giver
det en langt mere flydende opdatering end enkeltstående requests kan
gøre, og til en praktisk taget gratis belastning på serveren. Der står
jo under alle omstændigheder en php-tråd og gør et eller andet.
> Og der må også bliver nogle problemer clientside, med at holde styr
> på hvor mange data der er modtaget, og sortere dem fra - med mindre
> readyState 3 giver mulighed for at se den nys modtagne delmængde...
Jeg ville gøre noget i retning af dette:
var Processed = 0;
...
xhr.onprogress = function (e) {
if (e.loaded > Processed) {
do_processing(e.target.responseText.subString(Processed, e.loaded);
Processed = e.loaded;
}
}
(Med forbehold for typoer og ting)
Er man til closures og anonyme funktioner, kan man med fordel tilføje
Processed til det XMLHttpRequest man er i gang med, så den værdi ikke
hænger og flagrer i det globale scope.
1. Omend der muligvis kan opstå nogle spændende situationer, hvis man
skal gennem en proxy.
> Anders Wegge Keller kom med følgende:
>> Så skal du nærlæse dokumentet. Det er lidt gemt, men så snart
>> readystate er 3 eller 4, skal responseText indeholde det der allerede
>> er modtaget fra serveren, medmindre det dokument der sendes kommer med
>> en XML-content type.
> Du mener det dokument, der endnu kun er draft?
som sagt, en formulering der har været i samtlige drafts i de sidste
seks år.
> Kan godt se, den ikke kom rigtigt ud :/ Hvor mange gange sendes data
> fra PHP - er det styret af tid eller mængde, størrelsen på en
> buffer, et eller andet sted?
til at "tvinge"[1] output ud til klienten.
> Jeg ved ikke om PHP har en output buffer man kan styre, så kan man
> måske ad den vej. Ellers bliver det som jeg ser det, en temmelig
> tilfældig opdatering af progress baren.
ingen garanti for at der ikke kommer nogle gevaldige ryk, medmindre
man poller ofte. Så i de tilfælde hvor det kan lade sig gøre, giver
det en langt mere flydende opdatering end enkeltstående requests kan
gøre, og til en praktisk taget gratis belastning på serveren. Der står
jo under alle omstændigheder en php-tråd og gør et eller andet.
> Og der må også bliver nogle problemer clientside, med at holde styr
> på hvor mange data der er modtaget, og sortere dem fra - med mindre
> readyState 3 giver mulighed for at se den nys modtagne delmængde...
var Processed = 0;
...
xhr.onprogress = function (e) {
if (e.loaded > Processed) {
do_processing(e.target.responseText.subString(Processed, e.loaded);
Processed = e.loaded;
}
}
(Med forbehold for typoer og ting)
Er man til closures og anonyme funktioner, kan man med fordel tilføje
Processed til det XMLHttpRequest man er i gang med, så den værdi ikke
hænger og flagrer i det globale scope.
1. Omend der muligvis kan opstå nogle spændende situationer, hvis man
skal gennem en proxy.
Birger Sørensen
Apr 26, 2012, 6:45:31 PM4/26/12
to
Anders Wegge Keller formulerede Friday:
Det kommer så lidt an på, hvad der egentlig foretages i det oprindelige
kald. Går ud fra at de fire linier i det oprindelige spørgsmål blot er
et eksempel...
Er det blot databehandling eller andet der ikke producerer noget
output, kan det ikke rigtig bruges. Med mindre man lægger i koden, at
der skal outputtes et eller andet med jævne mellemrum...
>
>> Og der må også bliver nogle problemer clientside, med at holde styr
>> på hvor mange data der er modtaget, og sortere dem fra - med mindre
>> readyState 3 giver mulighed for at se den nys modtagne delmængde...
>
> Jeg ville gøre noget i retning af dette:
>
> var Processed = 0;
>
> ...
>
> xhr.onprogress = function (e) {
> if (e.loaded > Processed) {
> do_processing(e.target.responseText.subString(Processed, e.loaded);
> Processed = e.loaded;
> }
> }
>
> (Med forbehold for typoer og ting)
>
> Er man til closures og anonyme funktioner, kan man med fordel tilføje
> Processed til det XMLHttpRequest man er i gang med, så den værdi ikke
> hænger og flagrer i det globale scope.
>
> 1. Omend der muligvis kan opstå nogle spændende situationer, hvis man
> skal gennem en proxy.
Ser fornuftigt ud ^^
> Birger Sørensen <s...@bbsorensen.com> writes:
>
>> Anders Wegge Keller kom med følgende:
>
>>> Så skal du nærlæse dokumentet. Det er lidt gemt, men så snart
>>> readystate er 3 eller 4, skal responseText indeholde det der allerede
>>> er modtaget fra serveren, medmindre det dokument der sendes kommer med
>>> en XML-content type.
>
>> Du mener det dokument, der endnu kun er draft?
>
> Ja, og som er grundlaget for at vi overhovedet kan tale om Ajax. Og
> som sagt, en formulering der har været i samtlige drafts i de sidste
> seks år.
>
>> Kan godt se, den ikke kom rigtigt ud :/ Hvor mange gange sendes data
>> fra PHP - er det styret af tid eller mængde, størrelsen på en
>> buffer, et eller andet sted?
>
> Det er noget der styres af webserveren. I php kan man bruge flush()
> til at "tvinge"[1] output ud til klienten.
>
>> Jeg ved ikke om PHP har en output buffer man kan styre, så kan man
>> måske ad den vej. Ellers bliver det som jeg ser det, en temmelig
>> tilfældig opdatering af progress baren.
>
> Det er korrekt. Omvendt giver en one-shot poll fra clientside heller
> ingen garanti for at der ikke kommer nogle gevaldige ryk, medmindre
> man poller ofte. Så i de tilfælde hvor det kan lade sig gøre, giver
> det en langt mere flydende opdatering end enkeltstående requests kan
> gøre, og til en praktisk taget gratis belastning på serveren. Der står
> jo under alle omstændigheder en php-tråd og gør et eller andet.
Kan godt se pointen.
>
>> Anders Wegge Keller kom med følgende:
>
>>> Så skal du nærlæse dokumentet. Det er lidt gemt, men så snart
>>> readystate er 3 eller 4, skal responseText indeholde det der allerede
>>> er modtaget fra serveren, medmindre det dokument der sendes kommer med
>>> en XML-content type.
>
>> Du mener det dokument, der endnu kun er draft?
>
> Ja, og som er grundlaget for at vi overhovedet kan tale om Ajax. Og
> som sagt, en formulering der har været i samtlige drafts i de sidste
> seks år.
>
>> Kan godt se, den ikke kom rigtigt ud :/ Hvor mange gange sendes data
>> fra PHP - er det styret af tid eller mængde, størrelsen på en
>> buffer, et eller andet sted?
>
> Det er noget der styres af webserveren. I php kan man bruge flush()
> til at "tvinge"[1] output ud til klienten.
>
>> Jeg ved ikke om PHP har en output buffer man kan styre, så kan man
>> måske ad den vej. Ellers bliver det som jeg ser det, en temmelig
>> tilfældig opdatering af progress baren.
>
> Det er korrekt. Omvendt giver en one-shot poll fra clientside heller
> ingen garanti for at der ikke kommer nogle gevaldige ryk, medmindre
> man poller ofte. Så i de tilfælde hvor det kan lade sig gøre, giver
> det en langt mere flydende opdatering end enkeltstående requests kan
> gøre, og til en praktisk taget gratis belastning på serveren. Der står
> jo under alle omstændigheder en php-tråd og gør et eller andet.
Det kommer så lidt an på, hvad der egentlig foretages i det oprindelige
kald. Går ud fra at de fire linier i det oprindelige spørgsmål blot er
et eksempel...
Er det blot databehandling eller andet der ikke producerer noget
output, kan det ikke rigtig bruges. Med mindre man lægger i koden, at
der skal outputtes et eller andet med jævne mellemrum...
>
>> Og der må også bliver nogle problemer clientside, med at holde styr
>> på hvor mange data der er modtaget, og sortere dem fra - med mindre
>> readyState 3 giver mulighed for at se den nys modtagne delmængde...
>
> Jeg ville gøre noget i retning af dette:
>
> var Processed = 0;
>
> ...
>
> xhr.onprogress = function (e) {
> if (e.loaded > Processed) {
> do_processing(e.target.responseText.subString(Processed, e.loaded);
> Processed = e.loaded;
> }
> }
>
> (Med forbehold for typoer og ting)
>
> Er man til closures og anonyme funktioner, kan man med fordel tilføje
> Processed til det XMLHttpRequest man er i gang med, så den værdi ikke
> hænger og flagrer i det globale scope.
>
> 1. Omend der muligvis kan opstå nogle spændende situationer, hvis man
> skal gennem en proxy.
Stig Johansen
Apr 27, 2012, 2:58:54 AM4/27/12
to
Anders Wegge Keller wrote:
> Så skal du nærlæse dokumentet. Det er lidt gemt, men så snart
> readystate er 3 eller 4, skal responseText indeholde det der allerede
> er modtaget fra serveren, medmindre det dokument der sendes kommer med
> en XML-content type.
Nu er det godt nok nogle år siden jeg lavede mine Ajax funktioner.
> Så skal du nærlæse dokumentet. Det er lidt gemt, men så snart
> readystate er 3 eller 4, skal responseText indeholde det der allerede
> er modtaget fra serveren, medmindre det dokument der sendes kommer med
> en XML-content type.
Intentionen var at følge readystate fra 0 til 4 med forskellige
eventhandlers, men jeg opgav, da det kun var 4 der var implementeret i de
browsere jeg brugte (dengang).
Så jeg er lidt tilbøjelig til at holde med Birger, og kun bruge 4.
--
Med venlig hilsen
Stig Johansen
Anders Wegge Keller
Apr 27, 2012, 3:20:56 AM4/27/12
to
Stig Johansen <wop...@gmail.com> writes:
> Intentionen var at følge readystate fra 0 til 4 med forskellige
> eventhandlers, men jeg opgav, da det kun var 4 der var implementeret
> i de browsere jeg brugte (dengang).
Det ender vel med at jeg bliver nødt til at klytte noget sammen, så
> Intentionen var at følge readystate fra 0 til 4 med forskellige
> eventhandlers, men jeg opgav, da det kun var 4 der var implementeret
> i de browsere jeg brugte (dengang).
vi kan få et overblik over hvilke browsere der kan håndtere en
ukomplet overførsel.
Jonathan Stein
Apr 27, 2012, 12:44:41 PM4/27/12
to
Den 26-04-2012 19:06, Anders Wegge Keller skrev:
>> - Når dit objekt skifter readyState til 3 (LOADING), skal du begynde
>> at kigge på responseText. Brug "onreadystatechange" til at detektere
>> når objektet skifter state. Brug setTimeout til at holde pause.
>
> Er det nødvendigt? Hvis al processering foregår fra onreadystate(),
> skal man ikke gøre andet end at læne sig tilbage og vente.
Om setTimeout er nødvendig?
>> - Når dit objekt skifter readyState til 3 (LOADING), skal du begynde
>> at kigge på responseText. Brug "onreadystatechange" til at detektere
>> når objektet skifter state. Brug setTimeout til at holde pause.
>
> Er det nødvendigt? Hvis al processering foregår fra onreadystate(),
> skal man ikke gøre andet end at læne sig tilbage og vente.
Objektet skifter jo ikke readyState før svaret er komplet, så hvis vi
ikke laver en timeout, skal vi lave et loop, der konstant ser, om
responseText er ændret i forhold til den hidtil modtagne tekst - og
sådan et loop uden timeout plejer at suge al kraft ud af browseren.
Jeg tror desværre ikke det kan gøres simplere.
M.v.h.
Jonathan
Anders Wegge Keller
Apr 27, 2012, 1:08:14 PM4/27/12
to
Jonathan Stein <jst...@image.dk> writes:
> Den 26-04-2012 19:06, Anders Wegge Keller skrev:
>
> >> - Når dit objekt skifter readyState til 3 (LOADING), skal du begynde
> >> at kigge på responseText. Brug "onreadystatechange" til at detektere
> >> når objektet skifter state. Brug setTimeout til at holde pause.
> >
> > Er det nødvendigt? Hvis al processering foregår fra onreadystate(),
> > skal man ikke gøre andet end at læne sig tilbage og vente.
> Om setTimeout er nødvendig?
Ja, jeg fejllæste dig lidt, men jeg kan ikke se hvornår det er
> Den 26-04-2012 19:06, Anders Wegge Keller skrev:
>
> >> - Når dit objekt skifter readyState til 3 (LOADING), skal du begynde
> >> at kigge på responseText. Brug "onreadystatechange" til at detektere
> >> når objektet skifter state. Brug setTimeout til at holde pause.
> >
> > Er det nødvendigt? Hvis al processering foregår fra onreadystate(),
> > skal man ikke gøre andet end at læne sig tilbage og vente.
> Om setTimeout er nødvendig?
nødvendigt at lave et timeout for at polle en XMLHttpRequest. Enten
venter man på at onreadystate siger done, eller også tager vi tinene
som de kommer i state 3 med onprogress.
> Objektet skifter jo ikke readyState før svaret er komplet, så hvis
> vi ikke laver en timeout, skal vi lave et loop, der konstant ser, om
> responseText er ændret i forhold til den hidtil modtagne tekst - og
> sådan et loop uden timeout plejer at suge al kraft ud af browseren.
gang der sker noget.
> Jeg tror desværre ikke det kan gøres simplere.
aftes?
Birger Sørensen
Apr 27, 2012, 3:53:08 PM4/27/12
to
Følgende er skrevet af Jonathan Stein:
Objektet kalder onreadystate, hver gang der er modtaget noget fra
serveren - og så undervejs i funktionaliteten (hvis der sendes noget),
og også selvom svaret ikke er komplet.
Så en timeout er inderligt overflødig, hvis man lader readystate=3
opdatere progressbaren...
serveren - og så undervejs i funktionaliteten (hvis der sendes noget),
og også selvom svaret ikke er komplet.
Så en timeout er inderligt overflødig, hvis man lader readystate=3
opdatere progressbaren...
Stig Johansen
Apr 30, 2012, 4:17:26 AM4/30/12
to
Anders Wegge Keller wrote:
> Stig Johansen <wop...@gmail.com> writes:
>
>> Intentionen var at følge readystate fra 0 til 4 med forskellige
>> eventhandlers, men jeg opgav, da det kun var 4 der var implementeret
>> i de browsere jeg brugte (dengang).
>
> Det ender vel med at jeg bliver nødt til at klytte noget sammen, så
> vi kan få et overblik over hvilke browsere der kan håndtere en
> ukomplet overførsel.
Vi har alle forskellige coding styles, men her er min implementering af
> Stig Johansen <wop...@gmail.com> writes:
>
>> Intentionen var at følge readystate fra 0 til 4 med forskellige
>> eventhandlers, men jeg opgav, da det kun var 4 der var implementeret
>> i de browsere jeg brugte (dengang).
>
> Det ender vel med at jeg bliver nødt til at klytte noget sammen, så
> vi kan få et overblik over hvilke browsere der kan håndtere en
> ukomplet overførsel.
Ajax.
Bemærk at jeg undgår brugen af closures, da det medfører memory overflow (i
visse browsere - nævner ikke navnet;-))
Den er renset for states andet end 4, da det (dengang ikke virkede), men er
struktureret som:
1) prolog
2) XMLHTTPrequest
3) epilog
I javascript overrides funktioner ved at erklære dem sidst.
// --------------- Global call ------------------------ //
function
callXMLHTTPRequest(getpost,URI,URIdata,Bodydata,callBackfunction,callBackdata,async,toAnsi,headers)
{
var cXMLHTTPRequest ;
try { cXMLHTTPRequest = new XMLHttpRequest(); }
catch (e) {
try { cXMLHTTPRequest = new ActiveXObject("Msxml2.XMLHTTP"); }
catch (e) {
try { cXMLHTTPRequest = new ActiveXObject("Microsoft.XMLHTTP");
}
catch (e) {
alert ('Error: unable to create XMLHTTPRequest!');
return false;
}
}
}
for (var i=0; i<URIdata.length; i++) URIdata[i] =
encodeURIComponent(URIdata[i]) ;
for (var i=0; i<Bodydata.length; i++) Bodydata[i] =
encodeURIComponent(Bodydata[i]) ;
// conver to Ansi ?
if ( toAnsi == true ) {
for (var i=0; i<URIdata.length; i++) URIdata[i] = uriutf8toansi
(URIdata[i],0) ;
for (var i=0; i<Bodydata.length; i++) Bodydata[i] = uriutf8toansi
(Bodydata[i],0) ;
}
// make an uri from array
var fullURI = URI ;
for (var i=0; i<URIdata.length; i++) {
if ( i % 2 == 0 ) fullURI = fullURI + ((i==0) ? '?':'&') +
URIdata[i] ; else fullURI = fullURI + '=' + URIdata[i] ;
}
// make body data from array
var urlencodedBodydata ='';
for (var i=0; i<Bodydata.length; i++) {
if ( i % 2 == 0 ) urlencodedBodydata += ((i==0) ? '':'&') +
Bodydata[i] ; else urlencodedBodydata += '=' + Bodydata[i] ;
}
var oldKonqueror = '' ; // "=true&"; // just dummy
urlencodedBodydata = oldKonqueror + urlencodedBodydata + '
'; // filler to extra header length
cXMLHTTPRequest.open( getpost, fullURI , async); //+ (debug ?
'?/&debug='+debug:'') , async); /////// <---- to here
// open skal kaldes før resdystate sættes, da IE sletter den tidligere ved
open.
if ( !async && window.navigator.appName.indexOf( 'Netscape') > -1 ) {
cXMLHTTPRequest.onload = function () {
if ( cXMLHTTPRequest.readyState == 4 ) {
callBackfunction(cXMLHTTPRequest.responseText,
callBackdata,callBackProlog (cXMLHTTPRequest),cXMLHTTPRequest);
callBackEpilog (cXMLHTTPRequest);
}
}
} else {
cXMLHTTPRequest.onreadystatechange = function () {
if ( cXMLHTTPRequest.readyState == 4 ) {
callBackfunction(cXMLHTTPRequest.responseText,
callBackdata,callBackProlog (cXMLHTTPRequest),cXMLHTTPRequest);
callBackEpilog (cXMLHTTPRequest);
}
}
}
// ------> moved up cXMLHTTPRequest.open( getpost, fullURI
+'&debug='+debug , async);
for (var i=0; i<headers.length / 2 ; i++) {
cXMLHTTPRequest.setRequestHeader( headers[i*2],headers[i*2+1]);
}
if (getpost == 'post') {
cXMLHTTPRequest.setRequestHeader("Content-type",
"application/x-www-form-urlencoded;");
// cXMLHTTPRequest.setRequestHeader("Content-length",
urlencodedBodydata.length ); // 'patch gammel konq
}
cXMLHTTPRequest.send(urlencodedBodydata);
return true;
}
function callBackProlog (lXMLHTTPRequest) {
if ( lXMLHTTPRequest.status != 200 && lXMLHTTPRequest.status != 100 &&
lXMLHTTPRequest.status != 304 ) {
if (confirm( 'Error XMLHTTPRequest ' + lXMLHTTPRequest.status +
'\r\nOpen debug window?')){
var debugWindow = window.open('','Debug_data');
debugWindow.document.open("text/html", "replace");
debugWindow.document.write(lXMLHTTPRequest.responseText);
debugWindow.document.close();
}
return false ;
}
return true ;
}
function callBackEpilog (lXMLHTTPRequest) {
lXMLHTTPRequest = null ;
Jonathan Stein
May 1, 2012, 4:59:13 AM5/1/12
to
Den 27-04-2012 19:08, Anders Wegge Keller skrev:
> Det er jo det der er pointen med onprogress. Det event fyrer hver
> gang der sker noget.
"onprogress" ser interessant ud, men var ikke med i den dokumentation,
> Det er jo det der er pointen med onprogress. Det event fyrer hver
> gang der sker noget.
jeg kiggede på. Jeg er i tvivl om hvor bredt, det er understøttet.
M.v.h.
Jonathan
Jonathan Stein
May 1, 2012, 5:05:41 AM5/1/12
to
Den 27-04-2012 21:53, Birger Sørensen skrev:
> Objektet kalder onreadystate, hver gang der er modtaget noget fra
> serveren - og så undervejs i funktionaliteten (hvis der sendes noget),
> og også selvom svaret ikke er komplet.
Det er ikke en funktionalitet, jeg ville satse på. Jf.
> Objektet kalder onreadystate, hver gang der er modtaget noget fra
> serveren - og så undervejs i funktionaliteten (hvis der sendes noget),
> og også selvom svaret ikke er komplet.
http://www.w3.org/TR/XMLHttpRequest/#events bliver "readystatechange"
kun sendt, når readyState skifter.
"progress" bliver derimod sendt løbende, men som jeg lige skrev til
Anders, er jeg i tvivl om hvor udbredt, det er.
M.v.h.
Jonathan
Anders Wegge Keller
May 1, 2012, 5:12:20 AM5/1/12
to
testet mig frem til at det virker i Chrome og Firefox, men jeg har
ikke haft tid til at lave en testside jeg vil udsætte andre for.
0 new messages