|
|
 | AJAX Shoutbox revisited
Fra : Rune Jensen |
Dato : 24-12-07 14:49 |
|
http://runejensen.dk/tips/ajax/shoutbox.asp
Her ligger min shoutbox. Jeg har fulgt anvisningen fra Birger - tak for den
iøvrigt - så at den nu kan vise en tekst fra en .txt-fil. Imidlertid kan jeg
ikke få den til at hente det serverside-script, som lægger ny tekst til
filen. Foreløbig er serversiden lavet, så der automatisk tilføjes den samme
tekst (This text will be added to end of file"), og efter råd fra Stig -
også tak - så virker den del. Men problemet er altså at JSen ikke vil kalde
scriptet. Hva hulen gør jeg galt???
--
"Studie 88, fordi Danmark ikke gider høre de samme 10 lokalhits om og om
igen!"
- Kim Schumacker, Studie 88
http://kimschumacher.dk/
| |
 Erik Ginnerskov (24-12-2007)
| Kommentar
Fra : Erik Ginnerskov |
Dato : 24-12-07 16:45 |
|
Rune Jensen wrote:
> problemet er altså at JSen ikke vil kalde scriptet. Hva hulen gør jeg
> galt???
Jeg forstår ikke, hvorfor dit input-textarea og din submit ikke er lagt i en
formular, hvor dit serverside-script er adresseret i formularens action. Det
er muligvis fordi jeg ikke har fattet ajax, men sådan ville jeg altså lave
det.
Dit serverside-script skal så slutte af med igen at kalde din side, som så
automatisk vil indeholde den tilføjede tekst.
--
Med venlig hilsen
Erik Ginnerskov
http://hjemmesideskolen.dk/ - http://ginnerskov.dk/
http://html-faq.dk
| |
Rune Jensen (25-12-2007)
| Kommentar
Fra : Rune Jensen |
Dato : 25-12-07 00:13 |
|
"Erik Ginnerskov" skrev...
> Jeg forstår ikke, hvorfor dit input-textarea og din submit ikke er lagt i
> en formular, hvor dit serverside-script er adresseret i formularens
> action. Det er muligvis fordi jeg ikke har fattet ajax, men sådan ville
> jeg altså lave det.
>
> Dit serverside-script skal så slutte af med igen at kalde din side, som så
> automatisk vil indeholde den tilføjede tekst.
I så fald vil den vel gentegne hele siden...? Meningen er, den alene skal
gentegne boksen med "chatteksten", når man trykker "send", og ikke andet på
siden.
Forstod dog ikke helt Birger og Stigs forklaringer ang. dette, så muligt,
jeg har misforstået noget, og du alligevel har ret. Ville i hvert fald gerne
have en uddybning fra en eller anden med AJAX-indsigt.
MVH
Rune Jensen
| |
Stig Johansen (25-12-2007)
| Kommentar
Fra : Stig Johansen |
Dato : 25-12-07 09:27 |
|
Rune Jensen wrote:
> http://runejensen.dk/tips/ajax/shoutbox.asp
>
> Her ligger min shoutbox. Jeg har fulgt anvisningen fra Birger - tak for
> den iøvrigt - så at den nu kan vise en tekst fra en .txt-fil. Imidlertid
> kan jeg ikke få den til at hente det serverside-script, som lægger ny
> tekst til filen. Foreløbig er serversiden lavet, så der automatisk
> tilføjes den samme tekst (This text will be added to end of file"), og
> efter råd fra Stig - også tak - så virker den del. Men problemet er altså
> at JSen ikke vil kalde scriptet. Hva hulen gør jeg galt???
Der er en del fejl Rune.
Jeg er i gang med en lokalt tilrettet version, hvor indlæsningen virker, men
den 'dør' ved klik på send tasten. Nu har jeg sat mig for at få det til at
virke i min Konqueror, men der kun 'fattigmandsdebugging' aka en masse
alerts.
Jeg er gået lidt død i overblikket, så jeg fortsætter en anden gang - hvis
du ikke har fået 'hul' igennem.
Men her er et par ting, jeg har fundet ud af indtil videre (du må selv finde
stederne, jeg har mistet overblikket).
* Textarea skal sættes med .value og ikke .innerHTML
* Et eller andet sted har brugt Text i stedet for Tekst - eller omvendt.
* Du har glemt "id" et sted, der var kun "name"
* url'er skal være absolutte, altså incl http:// osv.
* GET af .txt filen giver en 304 Not modified, så vi skal bruge
høkertrikket, jeg har brugt:
<body
onload="HentFil(' http://runejensen.dk/shoutbox.txt?dummy='+Math.random());"
>
Det skal nok omstruktureres, så 'vi' bruger Hentfil efter tryk på 'Send'.
Giv lige et praj hvis du får rettet nogle af disse ting.
--
Med venlig hilsen
Stig Johansen
| |
Rune Jensen (26-12-2007)
| Kommentar
Fra : Rune Jensen |
Dato : 26-12-07 01:19 |
|
"Stig Johansen" skrev...
<SNIP>
> Men her er et par ting, jeg har fundet ud af indtil videre (du må selv
> finde
> stederne, jeg har mistet overblikket).
Jeg har nu kigget på det en 4 timers tid, og der er fremskridt
> * Textarea skal sættes med .value og ikke .innerHTML
Jeg lavede det om til en DIV for at få mulighed for at lave styling af
teksten indeni.
> * Et eller andet sted har brugt Text i stedet for Tekst - eller omvendt.
Stavefejl. Er rettet
> * Du har glemt "id" et sted, der var kun "name"
Er rettet
> * url'er skal være absolutte, altså incl http:// osv.
Jeg fik det til at virke med relative URLs. Men er der en særlig grund til,
man anbefaler absolut URL?
> * GET af .txt filen giver en 304 Not modified, så vi skal bruge
> høkertrikket, jeg har brugt:
> <body
> onload="HentFil(' http://runejensen.dk/shoutbox.txt?dummy='+Math.random());"
Der er udvidet lidt med en timer.
> Det skal nok omstruktureres, så 'vi' bruger Hentfil efter tryk på 'Send'.
Ja, jeg fik det inkluderet
> Giv lige et praj hvis du får rettet nogle af disse ting.
Både dig og Birger er geniaaaale - bliv endelig ved 
Det ser ud til at virke efter hensigten nu. To ting irriterer, dog:
1. Jeg har stadig ikke fattet forskellen på synkron/asynkron og get/post i
AJAX
2. Den dér math/høkertricket... Det må jeg lige kigge på. Jeg synes, jeg er
kommet udom det før, men godt nok ikke med JS. Kan man få JS til at Flushe
cashen? Jeg tænker på, om cashen ikke ellers hurtigt bliver fyldt op?
Desuden, så er koden jo lavet ved "trial and error", hvilket vil sige, der
er ingen synlige fejl (ser ud til at virke i både IE og FF) - men logisk
opbygget er den til gengæld nok ikke
Optimering: Der kaldes jo læsaffil hvert 1/4 sekund, og hele filen læses, og
DIVen opdateres. I stedet vil jeg nok lave, som én foreslog, at man checker,
om filen er opdateret først, og hvis ikke, så lade være med at opdatere
DIVen.
MVH
Rune Jensen
| |
 Stig Johansen (26-12-2007)
| Kommentar
Fra : Stig Johansen |
Dato : 26-12-07 08:20 |
|
Rune Jensen wrote:
> "Stig Johansen" skrev...
> <SNIP>
>
>> Men her er et par ting, jeg har fundet ud af indtil videre (du må selv
>> finde
>> stederne, jeg har mistet overblikket).
>
> Jeg har nu kigget på det en 4 timers tid, og der er fremskridt
Lyder godt. Jeg havde sat mig for at 'huske' hvad jeg havde rettet - men
tror du jeg noterede det undervejs? Næh rigtige mænd skriver da ikke ned -
de glemmer. Jeg kunne simpelthen ikke finde ud af hvad der var 'dit' og
hvad der var 'mit'
>> * Et eller andet sted har brugt Text i stedet for Tekst - eller omvendt.
>
> Stavefejl. Er rettet
Yep, men i min version var det rettet, så jeg kunne ikke finde den igen.
>
>> * Du har glemt "id" et sted, der var kun "name"
>
> Er rettet
Godt - svaret var af samme årsag som overfor.
>> * url'er skal være absolutte, altså incl http:// osv.
>
> Jeg fik det til at virke med relative URLs. Men er der en særlig grund
> til, man anbefaler absolut URL?
Undskyld - Rune, det var ikke en anbefaling, det var 'the easy way out for
mig' - det var for at udelukke en fejlkilde, så kunne vi altid tage den
relative senere.
>
>
>> * GET af .txt filen giver en 304 Not modified, så vi skal bruge
>> høkertrikket, jeg har brugt:
>> <body
>>
onload="HentFil(' http://runejensen.dk/shoutbox.txt?dummy='+Math.random());"
>
> Der er udvidet lidt med en timer.
Pas lidt på når du laver timere, altså hvis du vil have 'Linuxfolket' med.
Der er et lille 'problem' med Linux. Her regner man i sekunder og
mikrosekunder og ikke millisekunder. Jeg har ikke lige mine kildetekster
(Ej javascript, men problemstillingen er det samme) ved hånden.
Det er noget med heltal(integers) og division med 1000.
Som heltal er 250/1000 = 0.
Du har 250 millisekunder, og min Konqueror går i 'infinite' loop -
garanteret pga denne fejl.
Så mit råd er til dig - og andre - gå aldrig under 1000 millisekunder -
heller ikke ved low level socket programmering - 'Linger' comes to my mind.
> Både dig og Birger er geniaaaale - bliv endelig ved
Jeg
kan ikke tale for Birger, men jeg er ikke genial, jeg har bare prøvet nogle
ting hist og pist.
> Det ser ud til at virke efter hensigten nu. To ting irriterer, dog:
>
> 1. Jeg har stadig ikke fattet forskellen på synkron/asynkron og get/post i
> AJAX
Det er en svær en at gøre pædagogisk, jeg er sikker Birger kender til
Blocked vs Non-blocked I/O, så det kan være han også lige kan byde ind.
Jeg prøver denne her:
Der var engang ham her Rune.
Han har lyst til at lave æbleskiver til sine venner her til jul.
Men han bliver nødt til at ringe til sin mor, for det er hende der har
opskriften.
Man kan så lave 2 udfaldsrum på historien.
1) Rune starter med at ringe til sin mor, og kan ikke komme videre i
æbleskiveprojektet før han har opskriften osv. Han vælger derfor at blive
hængende i røret mens mor finder opskriften og læser den op for ham.
2) Rune ved at han skal bruge æbleskivepande, skåle osv, men han kender ikke
den præcise opskrift. Men også her starter Rune med at ringe til sin mor,
men denne her gang siger Rune - 'Jeg skal bruge din berømte opskrift på
æbleskiver, gider du finde den og ringe tilbage?'. Mens Rune venter på
tilbagemelding fra moren,går Rune i gang med at finde grej frem, så han er
klar når moren ringer tilbage.
Uanset om det er udfalsdrum 1 eller 2 er Rune afhængig af *opskriften*.
Forskelle er, at i tilfælde 2 udnytter Rune sin 'tid' mens han venter.
Altså lidt oversat: Udfald 1 = synkron, og Udfald 2= Asynkron.
Valget af metode går groft sagt ud på om 'man har noget at lave i
mellemtiden'.
> 2. Den dér math/høkertricket... Det må jeg lige kigge på. Jeg synes, jeg
> er kommet udom det før, men godt nok ikke med JS. Kan man få JS til at
> Flushe cashen? Jeg tænker på, om cashen ikke ellers hurtigt bliver fyldt
> op?
Der er (nu) 2 ting med 'høkertricket'.
1) Minimum requesten burde være at tjekke for opdatering, som egentlig
'bare' er en datosammenligning. Men vores kære ven MS har en - desværre -
standardindstilling, hvor der _ikke_ tjekkes _hver_ gang, men blot ukritisk
bruger cachen. Det er en browserindstilling hos brugeren, som du ikke kan
påvirke på nogen måde. Og jo, det *er* en lorteløsning, fordi hvert opslag
udvider cachen, men 'Herrens og Williams veje er uransagelige'.
Den anden, som er tilfældet her er, at det er din server, der returnerer
'NOT modified". Det kan ligeså godt være min Konqueror, der ikke sender en
'rigtig' request, men jeg *orkede* ikke at sætte monitorering op, så det
var nok også lidt 'the easy way out for mig'.
> Optimering: Der kaldes jo læsaffil hvert 1/4 sekund
Pas lidt på med 1/4 sekund jfr. ovenstående - men også af hensyn til din
serverload.
--
Med venlig hilsen
Stig Johansen
| |
Birger (27-12-2007)
| Kommentar
Fra : Birger |
Dato : 27-12-07 11:23 |
|
"Rune Jensen" <runeofdenmark@hotmail.com> skrev i en meddelelse
news:476fb8cb$0$15009$456a7185@news.cirque.dk...
>
> http://runejensen.dk/tips/ajax/shoutbox.asp
>
> Her ligger min shoutbox. Jeg har fulgt anvisningen fra Birger - tak for
> den iøvrigt - så at den nu kan vise en tekst fra en .txt-fil. Imidlertid
> kan jeg ikke få den til at hente det serverside-script, som lægger ny
> tekst til filen. Foreløbig er serversiden lavet, så der automatisk
> tilføjes den samme tekst (This text will be added to end of file"), og
> efter råd fra Stig - også tak - så virker den del. Men problemet er altså
> at JSen ikke vil kalde scriptet. Hva hulen gør jeg galt???
>
>
> --
> "Studie 88, fordi Danmark ikke gider høre de samme 10 lokalhits om og om
> igen!"
> - Kim Schumacker, Studie 88
> http://kimschumacher.dk/
>
Et par småting, her torsdag morgen.
I DoSend() har du :
req.onreadystatechange = TextSent;
req.open( 'post', 'shoutbox_update.asp?' + ptext , true);
og den går ikke.
open() initialiserer objectet, og _skal_ være det første der kaldes. De to
linier skal derfor byttes om.
Desuden er der noget principielt der er forkert - kan så ikke lige overskue
hvor og hvorfor.
I DoSend, genbruger du req (AJAX_objectet).
Det er fint nok, men ambitiøst, da du ikke kan være sikker på at det er
færdigt med det, det er i gang med, fordi du bruger asynkron kommunikation.
Når du bruger asynkron kommunikation, fortsætter scriptet efter send() er
kaldt.
Det er derfor muligt, at du starter en ny kommunikation, inden den første er
forbi. Hvis det skal gå godt, er du nødt til at oprette et nyt object, eller
afbryde den igangværende, eller på anden vis være sikker på at objectet ikke
bruges længere (readyState skal være 4, og callback funktionen kaldt). Det
samme object kan ikke håndtere 2 kommunikationer på een gang.
Det kan så være at timingen i det hele er sådan at det ikke sker hos dig -
men en bruger med kortere eller længere responsetider kan få problemer du
aldrig ser.
Et alternativ er at bruge synkron kommunikation. Det stopper afviklingen af
script, indtil kommunikationen er slut.
Problemet ved det er, at det også stopper anden funktionalitet i browseren.
Man kan altså f.eks. ikke indtaste noget, mens kommunikationen er i gang.
Du bruger også det samme object til både at sende og hente beskeder.
Principielt kan du godt risikere, at der bliver byttet om på reponses fra
din ASP, hvis en besøgende sender en meddelelse, samtidig med at systemet
henter nye meddelelser.
Birger
-----
http://bbsorensen.dk
| |
Rune Jensen (27-12-2007)
| Kommentar
Fra : Rune Jensen |
Dato : 27-12-07 13:54 |
|
"Birger" skrev...
> Et par småting, her torsdag morgen.
>
> I DoSend() har du :
> req.onreadystatechange = TextSent;
> req.open( 'post', 'shoutbox_update.asp?' + ptext , true);
> og den går ikke.
> open() initialiserer objectet, og _skal_ være det første der kaldes. De to
> linier skal derfor byttes om.
er gjort
> Desuden er der noget principielt der er forkert - kan så ikke lige
> overskue hvor og hvorfor.
Layoutet er lavet lidt pænere, så det er nemmere at overskue
> I DoSend, genbruger du req (AJAX_objectet).
> Det er fint nok, men ambitiøst, da du ikke kan være sikker på at det er
> færdigt med det, det er i gang med, fordi du bruger asynkron
> kommunikation.
Jeg har forsøgt at lave nyt object til send. Nu virker send ikke
> Du bruger også det samme object til både at sende og hente beskeder.
> Principielt kan du godt risikere, at der bliver byttet om på reponses fra
> din ASP, hvis en besøgende sender en meddelelse, samtidig med at systemet
> henter nye meddelelser.
Der skal være to objecter, som jeg har forstået det, et til hent, et til
gem. Problemet er, den ikke vil acceptere mit nye object. Som det er i
øjeblikket, bliver der ikke gemt, fordi det nye object reqs er null - selvom
det skulle være initialiseret.
Jeg kan ikke se fejlen umiddelbart.
Kigger lige på det igen her efter frokot.
MVH
Rune Jensen
| |
Birger (27-12-2007)
| Kommentar
Fra : Birger |
Dato : 27-12-07 14:12 |
|
"Rune Jensen" <runeofdenmark@hotmail.com> skrev i en meddelelse
news:47739efd$0$15008$456a7185@news.cirque.dk...
> "Birger" skrev...
>
>> Et par småting, her torsdag morgen.
>>
>> I DoSend() har du :
>> req.onreadystatechange = TextSent;
>> req.open( 'post', 'shoutbox_update.asp?' + ptext , true);
>> og den går ikke.
>> open() initialiserer objectet, og _skal_ være det første der kaldes. De
>> to linier skal derfor byttes om.
>
> er gjort
>
>> Desuden er der noget principielt der er forkert - kan så ikke lige
>> overskue hvor og hvorfor.
>
> Layoutet er lavet lidt pænere, så det er nemmere at overskue
>
>> I DoSend, genbruger du req (AJAX_objectet).
>> Det er fint nok, men ambitiøst, da du ikke kan være sikker på at det er
>> færdigt med det, det er i gang med, fordi du bruger asynkron
>> kommunikation.
>
> Jeg har forsøgt at lave nyt object til send. Nu virker send ikke
>
>> Du bruger også det samme object til både at sende og hente beskeder.
>> Principielt kan du godt risikere, at der bliver byttet om på reponses fra
>> din ASP, hvis en besøgende sender en meddelelse, samtidig med at systemet
>> henter nye meddelelser.
>
> Der skal være to objecter, som jeg har forstået det, et til hent, et til
> gem. Problemet er, den ikke vil acceptere mit nye object. Som det er i
> øjeblikket, bliver der ikke gemt, fordi det nye object reqs er null -
> selvom det skulle være initialiseret.
>
> Jeg kan ikke se fejlen umiddelbart.
>
> Kigger lige på det igen her efter frokot.
>
>
> MVH
> Rune Jensen
>
Det eneste jeg kan se, er at du sender data med både i URL og i reqs.send(
'ptext').
Når du bruger get og sætter data i send(), bliver de data tilføjet til
URL'en med et ? foran.
Din ASP får dermed dobbelte data - og det er vel der tingene går galt?
Der er i øvrigt scriptfejl i både TextSent() og AJAXDone() (linierne 164 og
213) - element asp er ikke defineret.
Birger
-----
http://bbsorensen.dk
| |
Rune Jensen (27-12-2007)
| Kommentar
Fra : Rune Jensen |
Dato : 27-12-07 14:39 |
|
"Birger" skrev...
> Det eneste jeg kan se, er at du sender data med både i URL og i
> reqs.send( 'ptext').
> Når du bruger get og sætter data i send(), bliver de data tilføjet til
> URL'en med et ? foran.
> Din ASP får dermed dobbelte data - og det er vel der tingene går galt?
>
> Der er i øvrigt scriptfejl i både TextSent() og AJAXDone() (linierne 164
> og 213) - element asp er ikke defineret.
rettet og virker... Tak, Birger. Det løste også et par andre problemer.
MVH
Rune Jensen
| |
Rune Jensen (27-12-2007)
| Kommentar
Fra : Rune Jensen |
Dato : 27-12-07 19:50 |
|
"Birger" skrev...
> I DoSend, genbruger du req (AJAX_objectet).
> Det er fint nok, men ambitiøst, da du ikke kan være sikker på at det er
> færdigt med det, det er i gang med, fordi du bruger asynkron
> kommunikation.
Jeg er lidt i tvivl her. Må man så ikke lave det som jeg har gjort med en
variabel til funktionen for at kalde forsk. filer? Jeg bruger den godt nok
kun til at hente chattext, men ville være smart, om den kunne udnyttes til
brugere online også.
For som det er nu, så laver jeg helt separate dele for hver del, og det
bliver immervæk nogle gentagelser, når der er oprettelse af og check af
objecter med videre (næsten samme kode) til 4 forsk. ting, hent fil
(chattext), gemfil (gem chatttext), hentbrugereonline, og så den sidste som
jo så skal laves for opdatering af brugere (også en gem fil)
Er der slet ikke noget, som kan optimeres???
MVH
Rune Jensen
| |
Birger (27-12-2007)
| Kommentar
Fra : Birger |
Dato : 27-12-07 20:50 |
|
"Rune Jensen" <runeofdenmark@hotmail.com> skrev i en meddelelse
news:4773f261$0$15016$456a7185@news.cirque.dk...
> "Birger" skrev...
>
>> I DoSend, genbruger du req (AJAX_objectet).
>> Det er fint nok, men ambitiøst, da du ikke kan være sikker på at det er
>> færdigt med det, det er i gang med, fordi du bruger asynkron
>> kommunikation.
>
> Jeg er lidt i tvivl her. Må man så ikke lave det som jeg har gjort med en
> variabel til funktionen for at kalde forsk. filer? Jeg bruger den godt nok
> kun til at hente chattext, men ville være smart, om den kunne udnyttes til
> brugere online også.
>
> For som det er nu, så laver jeg helt separate dele for hver del, og det
> bliver immervæk nogle gentagelser, når der er oprettelse af og check af
> objecter med videre (næsten samme kode) til 4 forsk. ting, hent fil
> (chattext), gemfil (gem chatttext), hentbrugereonline, og så den sidste
> som jo så skal laves for opdatering af brugere (også en gem fil)
>
> Er der slet ikke noget, som kan optimeres???
>
>
> MVH
> Rune Jensen
>
Jo, optimeres kan det da.
F.eks.
function makeReqObj() {
areq = null;
.... // resten din eksisterende kode
return areq;
}
De to ( tre?) steder du opretter objecter skriver du så bare
req = makeReqObj(); og
reqs = makeReqObj();
reqsu = makeReqObj();
Så har du kun een funktion, der generer AJAX objecter - og kan genbruges så
meget du har lyst til ;>)
Og en funktion, f.eks.
function CheckAjax( ajaxObj, CallOnOk) {
if ( ajaxObj.readyState == 4) {
if ( ajaxObj.status != 200) {
alert( 'Fejl ved AJAX request : Status '+ajaxObj.status+' returneret.');
}
else {
if ( CallOnOk) { CallOnOk( ajaxObj.responseText) };
}
}
kan kombineres med alle dine callback, så den del af koden også kun er
nødvendig een gang.
F.eks. i din HentFil()
....
if ( nav.indexOf( 'Netscape') > -1) {
req.onload = function( ) { CheckAjax( req, AJAXDone); };
}
else {
req.onreadystatechange = function( ) { CheckAjax( req, AJAXDone); };
}
....
hvor checket for kommunikationen er taget ud, og teksten overføres som
parameter.
- så din AJAXDone ser sådan ud:
function AJAXDone( aTxt) {
document.getElementById('asp').innerHTML = aTxt;
switchTime();
scrollToBottom();
}
Skal så lige sige, at den sidste har drillet mig lidt, da jeg forsøgte.
Havde heller ikke rigtigt brug for det, så jeg gik ikke i dybden med
hvorfor - og jeg havde nogle andre fejl samtidig...
Du kan sætte de to (tre?) funktioner der kalder AJAX sammen til een, og
overføre parametre til dem som parametre til funktionen.
Altså Ajaxobject, url, data og callback funktion.
F.eks.:
function DoAjax( aObj, url, data, callBack) {
aObj = makeReqObj();
if ( aObj != null) {
aObj.open( 'get', url, true);
aObj.setRequestHeader( 'Content-Type',
'application/x-www-form-urlencoded');
aObj.setRequestHeader( 'Accept-Charset', 'iso-8859-1, utf-8');
aObj.setRequestHeader( 'Accept-Language', 'da');
nav = window.navigator.appName;
if ( nav.indexOf( 'Netscape') > -1) {
req.onload = function( ) { CheckAjax( aObj, callBack); };
}
else {
req.onreadystatechange = function( ) { CheckAjax( aObj, callBack); };
}
aObj.send(data);
}
}
For f.eks. at hente filen (meddelelserne) bruger du så
DoAjax( req, '/shoutbox.txt', 'dummy='+Math.random(), AJAXDone);
hente brugere
DoAjax( reqsu, '/shoutboxusers.txt','dummy='+Math.random(), AJAXDoneSU);
for den sidste, skal du selvfølgelig rette AJAXDoneSU til på samme måde som
AJAXDone ovenfor...
Håber det er forståeligt ;>)
Birger
-----
http://bbsorensen.dk
| |
Stig Johansen (28-12-2007)
| Kommentar
Fra : Stig Johansen |
Dato : 28-12-07 06:27 |
|
Rune Jensen wrote:
[snip]
Jeg har ikke lige kunnet finde et sted at placere indlægget, så jeg lægger
det her.
Birger har redegjort for asynkron hentning m.v.
Men du har en yderligere udfordring i forhold til din timer.
Nede i din timer funktion har du:
HentFil('/shoutbox.txt?dummy='+Math.random());
HentFilUsers('/shoutboxusers.txt?dummy='+Math.random());
umiddelbart herefter starter du en ny timer.
Udfordringen er, at dine 'Hent' kun _igangsætter_ forespørgslerne.
Det betyder, at din 'effektive' timer Te = T - R , hvor T er dit interval,
og R er responsetiden.
vi sætter T til 1000.
Det betyder for R eksempelvis:
R = 250 => Te = 750
R = 500 => Te = 500
R = 750 => Te = 250
R = 1000 => Te = 0
R = 1250 => Te = -250
Hvis Te < 0 får du igangsat nye forespørgsler inden de forrige er færdige.
Du må sel 'fedte' lidt med strukturen, men humlen er at du først bør
aktivere timeren når readystate = 4 på 'alle' udestående requests.
HOV! - vent lige lidt, jeg kommer lige pludselig i tanker om, at det kan
meget vel være _det_, der skete i min Konqueror.
Jeg bruger primært min yndlingsmaskine - 350 MHz fra sidste årtusinde, så
det meget vel tænkes, at den er 'meget' længere en 1/4 sekund om at
opdatere skærmen. Det er med andre ord muligt, at vi skal lave en 'undo' på
min kommentar om afrunding til 0. Den oplevelse jeg havde med 0'et var en
given implementering af sockets (Til Birger: = Synapse/Kylix), og gælder
ikke Linux generelt.
--
Med venlig hilsen
Stig Johansen
| |
Rune Jensen (28-12-2007)
| Kommentar
Fra : Rune Jensen |
Dato : 28-12-07 14:44 |
|
"Stig Johansen" ...
> Du må sel 'fedte' lidt med strukturen, men humlen er at du først bør
> aktivere timeren når readystate = 4 på 'alle' udestående requests.
Timeren var nok det sidste jeg tænkte på som egentligt problem Mon det
kan kombineres et check af readystate og så Birgers forslag til forennkling
af koden - den vil jeg kigge på.
> HOV! - vent lige lidt, jeg kommer lige pludselig i tanker om, at det kan
> meget vel være _det_, der skete i min Konqueror.
I FF, så blinker boksen med brugere online. Måske er dette en årsag.
> Jeg bruger primært min yndlingsmaskine - 350 MHz fra sidste årtusinde, så
> det meget vel tænkes, at den er 'meget' længere en 1/4 sekund om at
> opdatere skærmen. Det er med andre ord muligt, at vi skal lave en 'undo'
> på
> min kommentar om afrunding til 0. Den oplevelse jeg havde med 0'et var en
> given implementering af sockets (Til Birger: = Synapse/Kylix), og gælder
> ikke Linux generelt.
Jeg laver en undo på teksten på hjemmesiden. Og så kigger jeg på
timer-problemet, når jeg kommer hjem.
Noget helt andet, det er selve chatboksen, den må ikke scrolle til bund,
hvis musen er over denne. Har forsøgt med mouseover og mouseout, men dels er
det jo netop ikke sikkert, eventen er indtrådt på f.eks. mouseout, dels
svarer ingen af dem helt til mine ønsker, eller er faktisk det modsatte af
en mouseevent.
Funktion Check om musen hover over chatboksen med id=asp
hvis dette IKKE er tilfældet
scroll til bunden af boksen med id=asp
end hvis
end check
....meningen er selvfølgelig en mulighed for at læse tilbage i chatten uden
at blive afbrudt af irriterende scroll-down hvert sekund.
Tak for hjælpen til jer begge. Meget af det ville jeg nok ikke kunne løse
ved at kigge på nettet alene
MVH
Rune Jensen
| |
Birger (28-12-2007)
| Kommentar
Fra : Birger |
Dato : 28-12-07 15:13 |
|
"Rune Jensen" <runeofdenmark@hotmail.com> skrev i en meddelelse
news:4774fc56$0$15016$456a7185@news.cirque.dk...
8X
> Noget helt andet, det er selve chatboksen, den må ikke scrolle til bund,
> hvis musen er over denne. Har forsøgt med mouseover og mouseout, men dels
> er det jo netop ikke sikkert, eventen er indtrådt på f.eks. mouseout, dels
> svarer ingen af dem helt til mine ønsker, eller er faktisk det modsatte af
> en mouseevent.
>
> Funktion Check om musen hover over chatboksen med id=asp
> hvis dette IKKE er tilfældet
> scroll til bunden af boksen med id=asp
> end hvis
> end check
>
> ...meningen er selvfølgelig en mulighed for at læse tilbage i chatten uden
> at blive afbrudt af irriterende scroll-down hvert sekund.
8X
Faktisk gør timeren at det er umuligt at scrolle op og vise indhold før det
der er synligt, og det kan være ret irriterende.
Faktisk kunne man argumentere for, at du slet ikke skal hente noget, hvis
musen er over feltet (eller det ikke er scrollet i bund), da den besøgende
ikke vil kunne se det alligevel.
Tror det er nemmere at have en boolean du sætter false ved mouseover og true
ved mouseout på elementet, end det er at finde ud af om musen er over et
givet element lige på det aktuelle tidspunkt - og bruge den boolean til at
afgøre om der må scrolles eller ej.
var allowScroll = true;
....
if (allowScroll) { scrollToBottom( document.getElementById( 'asp')); }
....
<div id="asp" onmouseout="allowScroll=false;"
onmouseout="allowScroll=true;">...</div>
Birger
-----
http://bbsorensen.dk
| |
Rune Jensen (28-12-2007)
| Kommentar
Fra : Rune Jensen |
Dato : 28-12-07 18:00 |
|
"Birger" skrev...
> Tror det er nemmere at have en boolean du sætter false ved mouseover og
> true ved mouseout på elementet, end det er at finde ud af om musen er over
> et givet element lige på det aktuelle tidspunkt - og bruge den boolean til
> at afgøre om der må scrolles eller ej.
>
> var allowScroll = true;
> ...
> if (allowScroll) { scrollToBottom( document.getElementById( 'asp')); }
> ...
>
> <div id="asp" onmouseout="allowScroll=false;"
> onmouseout="allowScroll=true;">...</div>
Det enkle er tit det vanskeligste at forestille sig Jeg havde vistnok
forsøgt lign. og var ved at rode mig ud i alt muligt med flere
underfunktioner.
Men joh - nøjagtigt sådan skal det virke, som du skriver. Jeg lader nu også
selve timeren chekke, om der er allowScroll, og i så fald hentes intet.
Virker som en drøm. Så nu vil jeg kigge på readystate mv.
MVH
Rune Jensen
| |
Birger (28-12-2007)
| Kommentar
Fra : Birger |
Dato : 28-12-07 19:39 |
|
"Rune Jensen" <runeofdenmark@hotmail.com> skrev i en meddelelse
news:47752a36$0$14995$456a7185@news.cirque.dk...
8X
> Det enkle er tit det vanskeligste at forestille sig Jeg havde vistnok
> forsøgt lign. og var ved at rode mig ud i alt muligt med flere
> underfunktioner.
>
> Men joh - nøjagtigt sådan skal det virke, som du skriver. Jeg lader nu
> også selve timeren chekke, om der er allowScroll, og i så fald hentes
> intet. Virker som en drøm. Så nu vil jeg kigge på readystate mv.
Hvis man kan forestille sig det, kan det lade sig gøre.
Ofte er mulighederne for at realisere drømmen, omvendt proportional med
drømmens kompleksitet.
Det er bare lige det med at finde den simple løsning ;>)
Eftersom alt hvad der sker, er styret af events, er det simplere at bruge
dem, end selv at skulle til at finde ud af om musen befinder sig i et givet
element på et givet tidspunkt.
Det kan sikkert godt lade sig gøre, men... (har vist aldrig forsøgt).
Sådan som du skrev din beskrivelse af funktionaliteten, tænkte jeg at jeg
ville lige dele min mening om hvordan det nok løses simplest ;>)
Birger
-----
http://bbsorensen.dk
| |
Stig Johansen (29-12-2007)
| Kommentar
Fra : Stig Johansen |
Dato : 29-12-07 06:24 |
|
Rune Jensen wrote:
> Så nu vil jeg kigge på readystate mv.
En uddybning - just in case:
Du har overordnet:
HentFil => AJAXDone (1)
HentFilUsers => AJAXDoneSU (2)
Det du skal tage højde for er, at du ikke kan være sikker på rækkefølgen af
completion.
Det kan ligeså godt være 1 og derefter 2, som det kan være 2 og derefter 1.
Du kan lave 2 globale statusfelter, lad os kalde dem status1 og status2 jfr.
ovenstående.
I din timedCount() funktion sætter du så
status1=0
status2=0
hent.... osv..
her skal du _ikke_ starte timeren igen.
Jeg ser lige du har hent.... i din TextSent()
Her skal du stoppe en igangværende timer og sætte status1 og status2 til 0.
Det er muligt du skal stoppe timeren allerede i din DoSend().
I din AJAXDone() (status1) kan du lave en tilføjelse:
........ kode
document.getElementById('asp').innerHTML = req.responseText;
// først her er den færdig, tjek om 'den anden er færdig', og sæt status
if status2=1 => 'start timer'
status1=1
Tilsvarende i din AJAXDoneSU() (status2)
........ kode
document.getElementById('users').innerHTML = reqsu.responseText;
// først her er den færdig, tjek om 'den anden er færdig', og sæt status
if status1=1 => 'start timer'
status2=1
Det er muligt det er lidt for overordnet, men jeg er slet - slet ikke så
langt inde i Javascript syntax som 'visse andre'.
--
Med venlig hilsen
Stig Johansen
| |
Birger (29-12-2007)
| Kommentar
Fra : Birger |
Dato : 29-12-07 09:00 |
|
"Stig Johansen" <stig_johansen_it_at_=(@)hotmail.com> skrev i en meddelelse
news:4775da6d$0$90265$14726298@news.sunsite.dk...
> Rune Jensen wrote:
>
>> Så nu vil jeg kigge på readystate mv.
>
> En uddybning - just in case:
> Du har overordnet:
> HentFil => AJAXDone (1)
> HentFilUsers => AJAXDoneSU (2)
>
> Det du skal tage højde for er, at du ikke kan være sikker på rækkefølgen
> af
> completion.
>
> Det kan ligeså godt være 1 og derefter 2, som det kan være 2 og derefter
> 1.
>
> Du kan lave 2 globale statusfelter, lad os kalde dem status1 og status2
> jfr.
> ovenstående.
>
> I din timedCount() funktion sætter du så
> status1=0
> status2=0
> hent.... osv..
> her skal du _ikke_ starte timeren igen.
>
> Jeg ser lige du har hent.... i din TextSent()
> Her skal du stoppe en igangværende timer og sætte status1 og status2 til
> 0.
> Det er muligt du skal stoppe timeren allerede i din DoSend().
>
> I din AJAXDone() (status1) kan du lave en tilføjelse:
> ....... kode
> document.getElementById('asp').innerHTML = req.responseText;
> // først her er den færdig, tjek om 'den anden er færdig', og sæt status
> if status2=1 => 'start timer'
> status1=1
>
> Tilsvarende i din AJAXDoneSU() (status2)
> ....... kode
> document.getElementById('users').innerHTML = reqsu.responseText;
> // først her er den færdig, tjek om 'den anden er færdig', og sæt status
> if status1=1 => 'start timer'
> status2=1
>
> Det er muligt det er lidt for overordnet, men jeg er slet - slet ikke så
> langt inde i Javascript syntax som 'visse andre'.
>
> --
> Med venlig hilsen
> Stig Johansen
Der blev jeg vist borte...
Der er da ikke noget i vejen for, at hente begge dele - meddelelser og
brugere - på samme tid?
Den ene opdaterer meddelelserne, den anden online brugere.
Så længe det ikke er det samme object der udfører kommunikationen (eller der
anvendes synkron kommunikation - hvilket er valgt fra, fordi det "disabler"
browseren mens kommunikationen foregår), er der da ingen grund til at
afbryde eller vente på det ene for at gøre det andet?
XMLHttpRequest objectet holder selv styr på onreadystatechange (onload), og
kalder selv den rigtige.
Så rækkefølgen af kald der returnerer, er lige så underordnet som
rækkefølgen de foretages i.
Måske går det galt, hvis der kaldes to gange det samme (for kort interval) -
fordi det oprindelige object bliver "ødelagt", når der oprettes et nyt.
Til det kan man bruge objectets readyState.
F.eks. i HentFil():
if ( !req || req.readyState != 4 || req.readyState == 0) {
// Start en ny - den forrige er slut
}
else {
// der må ikke startes ny - den forrige er ikke slut
}
Men umiddelbart kan jeg ikke se problemet - timeren startes først når den
forrige er afsluttet, så det kan kun gå galt, hvis HentFil() af en eller
anden årsag kaldes 2 gange...
Birger
-----
http://bbsorensen.dk
| |
Stig Johansen (30-12-2007)
| Kommentar
Fra : Stig Johansen |
Dato : 30-12-07 07:29 |
|
Birger wrote:
> Der blev jeg vist borte...
Undskyld, men det er sk*de svært at forklare uden en whiteboard.
> Der er da ikke noget i vejen for, at hente begge dele - meddelelser og
> brugere - på samme tid?
Der er intet i vejen med at hente begge dele på samme tid, men _timingen_
kan være et problem.
Scenarie 1:
Vi sætter den igang med at hente meddelser og brugerer og vælger at starte
ny timer når _meddelserne_ er klar.
Meddelser tager 100 mS - men - brugerne tager 1200 mS
Her får vi sat en ny hent af _brugere_ igang inden den 'første' er færdig.
=> loop
Scenarie 2:
Vi sætter den igang med at hente meddelser og brugerer og vælger at starte
ny timer når _brugerne_ er klar.
Brugerne tager 100 mS - men - meddelserne tager 1200 mS
Her får vi sat en ny hent af _meddelserne_ igang inden den 'første' er
færdig. => loop
Det, der er vigtigt at huske på er, at tiden inkluderer et roundtrip til
serveren, og selvom der normalt er kort responstid, kan der i perioder
sagtens forkomme 'forhøjet' load på serveren. Det er med andre ord ikke kun
afviklingshastigheden på _klienten_ der er afgørende.
En opkobling på et 28.8 Kbps vil nok også give lidt længere svartider.
> Men umiddelbart kan jeg ikke se problemet - timeren startes først når den
> forrige er afsluttet, så det kan kun gå galt, hvis HentFil() af en eller
> anden årsag kaldes 2 gange...
Ja, når den forrige _timer_ er afsluttet, ikke når 'HentFil()' er afsluttet.
Et tænkt tidsforløb (Timer=1000):
0 ms: Timer trigges
1 mS: HentFil() kaldes
15 mS: HentFilUsers() kaldes
50 mS: Ny timer startes, T-1000 and counting
.....noget andet...
100mS: En 'GET /shoutbox.txt' udføres i baggrunden , T-950 and counting
200mS: En 'GET /shoutboxusers.txt' udføres i baggrunden , T-850 and counting
..... noget andet
500mS: 'GET /shoutboxusers.txt' er klar, readystate = 4, T-550 and counting
600mS: document.getElementById('users').innerHTML = reqsu.responseText; er
klar, T-450 and counting
950mS: 'GET /shoutbox.txt' er klar, readystate = 4, T-100 and counting
1050mS: T-0 reached, lift off, nyt kald af timer ('timedCount()')
1100mS: document.getElementById('asp').innerHTML = req.responseText; er
klar, men nu har vi allerede kaldt en ny 'HentFil()'
--
Med venlig hilsen
Stig Johansen
| |
Birger (30-12-2007)
| Kommentar
Fra : Birger |
Dato : 30-12-07 12:13 |
|
"Stig Johansen" <stig_johansen_it_at_=(@)hotmail.com> skrev i en meddelelse
news:47773b4a$0$90265$14726298@news.sunsite.dk...
> Birger wrote:
>
>> Der blev jeg vist borte...
>
> Undskyld, men det er sk*de svært at forklare uden en whiteboard.
>
>> Der er da ikke noget i vejen for, at hente begge dele - meddelelser og
>> brugere - på samme tid?
>
> Der er intet i vejen med at hente begge dele på samme tid, men _timingen_
> kan være et problem.
>
> Scenarie 1:
> Vi sætter den igang med at hente meddelser og brugerer og vælger at starte
> ny timer når _meddelserne_ er klar.
> Meddelser tager 100 mS - men - brugerne tager 1200 mS
> Her får vi sat en ny hent af _brugere_ igang inden den 'første' er færdig.
> => loop
>
> Scenarie 2:
> Vi sætter den igang med at hente meddelser og brugerer og vælger at starte
> ny timer når _brugerne_ er klar.
> Brugerne tager 100 mS - men - meddelserne tager 1200 mS
> Her får vi sat en ny hent af _meddelserne_ igang inden den 'første' er
> færdig. => loop
>
> Det, der er vigtigt at huske på er, at tiden inkluderer et roundtrip til
> serveren, og selvom der normalt er kort responstid, kan der i perioder
> sagtens forkomme 'forhøjet' load på serveren. Det er med andre ord ikke
> kun
> afviklingshastigheden på _klienten_ der er afgørende.
> En opkobling på et 28.8 Kbps vil nok også give lidt længere svartider.
>
>> Men umiddelbart kan jeg ikke se problemet - timeren startes først når den
>> forrige er afsluttet, så det kan kun gå galt, hvis HentFil() af en eller
>> anden årsag kaldes 2 gange...
>
> Ja, når den forrige _timer_ er afsluttet, ikke når 'HentFil()' er
> afsluttet.
>
> Et tænkt tidsforløb (Timer=1000):
> 0 ms: Timer trigges
> 1 mS: HentFil() kaldes
> 15 mS: HentFilUsers() kaldes
> 50 mS: Ny timer startes, T-1000 and counting
> ....noget andet...
> 100mS: En 'GET /shoutbox.txt' udføres i baggrunden , T-950 and counting
> 200mS: En 'GET /shoutboxusers.txt' udføres i baggrunden , T-850 and
> counting
> .... noget andet
> 500mS: 'GET /shoutboxusers.txt' er klar, readystate = 4, T-550 and
> counting
> 600mS: document.getElementById('users').innerHTML = reqsu.responseText; er
> klar, T-450 and counting
> 950mS: 'GET /shoutbox.txt' er klar, readystate = 4, T-100 and counting
> 1050mS: T-0 reached, lift off, nyt kald af timer ('timedCount()')
> 1100mS: document.getElementById('asp').innerHTML = req.responseText; er
> klar, men nu har vi allerede kaldt en ny 'HentFil()'
>
> --
> Med venlig hilsen
> Stig Johansen
Så er jeg med igen.
Troede da at der var en timer til hvert af forløbene.
Løsningen på det problem, er vel egentlig at bruge een til hver, og undlade
at blande forløbene sammen, eller at lade et af forløbene styre begge,
kombineret med et check på readyState, til at afgøre om forrige hentning er
afsluttet og en ny må startes.
Ser ud somom Rune faktisk har implementeret den sidste, og at det virker...
Rune :
Du har defineret en global variabel areg, der ikke anvendes.
makeReqObj() bruger til gengæld en areq til det nyoprettede object.
Det ligner lidt en slåfejl.
Og hvis det er det, skal du endelig ikke rette den.
Det object du opretter i makeReqObj() må ikke være globalt.
Hvis det er det, vil makeReqObj() ødelægge det forrige objecter der blev
genereret, hver gang der skal oprettes et nyt. Og det er ikke meningen.
Faktisk kunne du i en eller anden initialiseringsrutine oprette de 3
objecter du bruger (requ som du har defineret globalt, bruges vist heller
ikke til noget), og genbruge dem, frem for at oprette et nyt hver gang.
(open() og send() skal kaldes hver gang, og der er også forskellige data -
men objectet kan godt genbruges.)
En template kunne være
if( req == null) {
req = makeReqObj();
req.onreadystatechange = ..;
....
}
if ((req.readyState == 0) || (req.readyState == 4)) {
req.open(...);
req.send(...);
}
Her vil objectet blive oprettet første gang. De efterfølgende vil genbruge
det eksisterende.
Det skulle gå en anelse hurtigere, og spare lidt på resourcerne - sikkert
ingen af delene nok til at det bemærkes, men alligevel ;>)
Og så er jeg nødt til at rette mig selv - onreadystatechange må godt kaldes
før open().
Har læst en gang, at open() skulle være den første der kaldtes, fordi den
var en del af object initialiseringen.
Men det må være noget tidligere, noget andet, eller ændret - selv M$ sætter
onreadystatechange før open() kaldes.
http://msdn2.microsoft.com/en-us/library/ms534308(VS.85).aspx
så den skulle være god nok.
Birger
-----
http://bbsorensen.dk
| |
Stig Johansen (31-12-2007)
| Kommentar
Fra : Stig Johansen |
Dato : 31-12-07 07:30 |
|
Birger wrote:
> Så er jeg med igen.
> Troede da at der var en timer til hvert af forløbene.
Godt at høre.
Jeg kom i tanker om det der med whiteboardet.
Når jeg skal illustrere disse slags problemstillinger plejer jeg at tegne en
tidslinie (X-akse).
Så deler vi det op i forskellige 'tråde', der hver har deres eget 'liv'.
Den første tråd er hovedtråden, som eksisterer som en ubrudt streg henover
tid.
Så kan vi tage timeren. Den lever sit eget liv i eksakt 1000 mS fra
'fødslen'. Den illustreres med en streg med præcis 1000mS længde.
'Brugertråden' bliver 'født' ved HentFilUsers og lever sit liv indtil
skærmen er færdigopdateret[1] i AJAXDoneSU.
Den illustreres med en streg med tilfældig/variabel længde.
'Meddelelsestråden' bliver født ved HentFil og lever sit liv indtil skærmen
er færdigopdateret[1] i AJAXDone.
Den illustreres også med en streg med tilfældig/variabel længde.
I virkeligheden har vi en 5. tråd, der 'fødes' fra hovedtråden ved tryk på
send. Den afslutter sit liv i TextSent, MEN den starter ukritisk de 2 andre
tråde uanset om de er i gang eller timeren er ved at starte dem.
Igen illustreres den også med en streg med tilfældig/variabel længde.
[1] Færdigopdateret, forstået på den måde at innerHTML er sat.
> Løsningen på det problem, er vel egentlig at bruge een til hver, og
> undlade at blande forløbene sammen, eller at lade et af forløbene styre
> begge, kombineret med et check på readyState, til at afgøre om forrige
> hentning er afsluttet og en ny må startes.
Der er sikker mange løsninger på problemet. Men jeg tror det er en god ide
at sætte sig ned og 'lege' med de forskellige streger og længder. På en
whiteboard er det nemt at justere, men en blyant og viskelæder burde også
kunne gøre det.
--
Med venlig hilsen
Stig Johansen
| |
Stig Johansen (29-12-2007)
| Kommentar
Fra : Stig Johansen |
Dato : 29-12-07 07:27 |
|
Stig Johansen wrote:
[snip en masse ævl]
Apropos timer og langsomme maskiner.
Jeg kom lige i tanke om, at på min royter er der en lille rulleboks med
forskellige refresh intervaller.
Det kunne måske være en ide hvis du lavede så'n en lille en, så os der kører
på 'gamle dampmaskiner' kan ændre intervallet.
Evt. kombineret med en cookie.
--
Med venlig hilsen
Stig Johansen
| |
Rune Jensen (01-01-2008)
| Kommentar
Fra : Rune Jensen |
Dato : 01-01-08 17:26 |
|
On 30 Dec. 2007, 12:12, "Birger" <s...@bbsorensen.com> wrote:
> Så er jeg med igen.
> Troede da at der var en timer til hvert af forløbene.
Nej - men det er måske en god idé. Jeg tænker det måske er mest
logisk?
> Løsningen på det problem, er vel egentlig at bruge een til hver, og undlade
> at blande forløbene sammen, eller at lade et af forløbene styre begge,
> kombineret med et check på readyState, til at afgøre om forrige hentning er
> afsluttet og en ny må startes.
> Ser ud somom Rune faktisk har implementeret den sidste, og at det virker....
Jeg er ikke helt sikker... I FF, der blinker boksen med AtiveBrugere.
Det var egentlig grunden til, jeg tænkte, der måske er noget om det,
Stig skrev. Ærligt, så er i vidst begge en tand over mig, og lige nu
er jeg ikke i stand til at gøre mere. Men jeg kigger på det i morgen,
når jeg er frisk.
Det er også mærkeligt, at i FF, der virker ScrollToBottom _både_ på
chatboksen selv (som den skal), men _også_ på AktiveBrugere... Det
sidste er ikke meningen
> Rune :
> Du har defineret en global variabel areg, der ikke anvendes.
> makeReqObj() bruger til gengæld en areq til det nyoprettede object.
> Det ligner lidt en slåfejl.
Ja, det er det
> Og hvis det er det, skal du endelig ikke rette den.
> Det object du opretter i makeReqObj() må ikke være globalt.
> Hvis det er det, vil makeReqObj() ødelægge det forrige objecter der blev
> genereret, hver gang der skal oprettes et nyt. Og det er ikke meningen.
> Faktisk kunne du i en eller anden initialiseringsrutine oprette de 3
> objecter du bruger (requ som du har defineret globalt, bruges vist heller
> ikke til noget), og genbruge dem, frem for at oprette et nyt hver gang.
> (open() og send() skal kaldes hver gang, og der er også forskellige data -
> men objectet kan godt genbruges.)
> En template kunne være
>
> if( req == null) {
> req = makeReqObj();
> req.onreadystatechange = ..;
> ....
> }
> if ((req.readyState == 0) || (req.readyState == 4)) {
> req.open(...);
> req.send(...);
> }
>
> Her vil objectet blive oprettet første gang. De efterfølgende vil genbruge
> det eksisterende.
> Det skulle gå en anelse hurtigere, og spare lidt på resourcerne - sikkert
> ingen af delene nok til at det bemærkes, men alligevel ;>)
Det lyder fornuftig overordnet set forståeligt nok, jeg er bare ikke
helt med på statusserne endnu. Det må blive i morgen
> Og så er jeg nødt til at rette mig selv - onreadystatechange må godt kaldes
> før open().
> Har læst en gang, at open() skulle være den første der kaldtes, fordi den
> var en del af object initialiseringen.
> Men det må være noget tidligere, noget andet, eller ændret - selv M$ sætter
> onreadystatechange før open() kaldes. http://msdn2.microsoft.com/en-us/library/ms534308(VS.85).aspx
> så den skulle være god nok.
Jeg skal vidst have læst op på de forskellige former for 'status' på
objecter, for at forstå det fuldt ud, kan jeg godt se, for det lader
til at være et sted, det halter for mig. Vel egentlig også ved min
forståelse i Stigs forklaring. Nu tager jeg et grundigt kig på jeres
svar, så må jeg vende tilbage med spørgsmål lidt ad gangen.
Godt nytår til jer begge, og til hvem som nu måtte læse med
MVH
Rune Jensen
| |
Stig Johansen (02-01-2008)
| Kommentar
Fra : Stig Johansen |
Dato : 02-01-08 08:09 |
|
Rune Jensen wrote:
> Ærligt, så er i vidst begge en tand over mig, og lige nu
> er jeg ikke i stand til at gøre mere. Men jeg kigger på det i morgen,
> når jeg er frisk.
Tag dig god tid til at kigge.
Vi er ude i multitasking problemstillinger, og selv ovre i
udviklingsgrupperne er det _meget_ svært fordøjeligt.
Jeg tager hatten af for at du overhovedet 'tør' kaste dig ud i den slags, så
lad endelig være med at 'give op'.
--
Med venlig hilsen
Stig Johansen
| |
Rune Jensen (03-01-2008)
| Kommentar
Fra : Rune Jensen |
Dato : 03-01-08 08:37 |
|
On 2 Jan., 08:09, Stig Johansen <stig_johansen_it_at_=(@)hotmail.com>
wrote:
> Tag dig god tid til at kigge.
> Vi er ude i multitasking problemstillinger, og selv ovre i
> udviklingsgrupperne er det _meget_ svært fordøjeligt.
Det med whiteboardet minder vel lidt om et funktionsdiagram, som man
også laver til styringer af cylindre (f.eks.)
> Jeg tager hatten af for at du overhovedet 'tør' kaste dig ud i den slags, så
> lad endelig være med at 'give op'.
Heller ikke sikkert, det går godt
Men jeg har foreløbigt lavet 2 uafhængige timere, og det ser ud, som
om opdateringshastigheden nu er rigtig (før var den for hurtig i
forhold til det, jeg havde sat den til). For sjov skyld også tilføjet
valgfri refresh rate.
En ting, som så kom ud af det er, at selve chatfeltet opdaterer i ryk.
Som om, det opdaterer et afsnit ad gangen i scrollToBottom afhængig af
refresh rate. Sjov virkning, men nok lidt irriterende, når chatten
bliver stor
Men ellers ser det ud, som en forbedring, ja.
Overvejer nu, om det er nødvendigt med den global variable, du
snakkede om for at standse timerne, når der hentes og gemmes?
Stig, du skrev, du havde en lokal kopi af en lign. chat. Noget, man må
se?
Igen tak til jer begge. Uvurderlig hjælp. Noget godt er kommet ud af
det her avancerede - nu brillerer jeg med det mere simple som
getElementById og mouseevents helt fra hukommelsen...
MVH
Rune Jensen
| |
Stig Johansen (04-01-2008)
| Kommentar
Fra : Stig Johansen |
Dato : 04-01-08 06:50 |
|
Rune Jensen wrote:
> Stig, du skrev, du havde en lokal kopi af en lign. chat. Noget, man må
> se?
Desværre Rune.
Det var en lokal kopi af _din_ side, så jeg kunne afprøve og rette - Ah nu
dæmrer det, det var *derfor* jeg måtte bruge absolutte URI'er, beklager
forvirringen.
Jeg har ikke rigtig noget på lager, du kan bruge.
--
Med venlig hilsen
Stig Johansen
| |
|
|