---

Hejsa Alle :)

Jeg har en side hvor jeg ud fra en db henter nogle navne, når jeg så klikker
tilføj, så kører knappen en:

onClick="doTransfer();"

Og den tager info med ind i doTransfer fra en select box, det virker super.
Men, hvis jeg klikker på knappen 2 gange, så sker der INTET anden gang hvis
jeg ikke har ændret markeringen i førnævnte select box..
Men hvis jeg ændre markeringen i select boksen, så kører den fint scriptet
igen.

Hvorfor det? og kan man få den til at køre min doTransfer() selv om der ikke
er ændret i select boksen??

Jeg håber i forstår hvad jeg mener..

Det her hvad der bliver kaldt i min .js fil.

function doTransfer(){
var url = "backend2.php?navn=" + document.getElementById('return1').value;
url += "&holdid=" + document.getElementById('holdid').value;
http.open("GET", url, true);
http.onreadystatechange = handleHttpResponse3;
http.send(null);
}

function handleHttpResponse3(){
if(http.readyState == 4){
document.getElementById('list').innerHTML = http.responseText;
}
}


Grunden til at jeg har brug for at den kører scriptet uden ændring er, at
ellers giver det invalide data på skærmen fra sidste gang den kørte
doTransfer(), og så kan man ikke se hvad man har ændret med de andre
funktioner jeg har på siden..

Jeg håber i kan gi mig et bud, har taget mig en evighed at gennemskue at det
er fordi den ikke kører scriptet, men bare tager det info den fik ud af
scriptet sidste gang det blev kørt, når man klikker på knappen igen...

Mvh
Morten

---

Mr J.. wrote:
> Hejsa Alle :)
>
> Jeg har en side hvor jeg ud fra en db henter nogle navne, når jeg så klikker
> tilføj, så kører knappen en:
>
> onClick="doTransfer();"
>
> Og den tager info med ind i doTransfer fra en select box, det virker super.
> Men, hvis jeg klikker på knappen 2 gange, så sker der INTET anden gang hvis
> jeg ikke har ændret markeringen i førnævnte select box..
> Men hvis jeg ændre markeringen i select boksen, så kører den fint scriptet
> igen.
>
> Hvorfor det? og kan man få den til at køre min doTransfer() selv om der ikke
> er ændret i select boksen??
>
> Jeg håber i forstår hvad jeg mener..
>
> Det her hvad der bliver kaldt i min .js fil.
>
> function doTransfer(){
> var url = "backend2.php?navn=" + document.getElementById('return1').value;
> url += "&holdid=" + document.getElementById('holdid').value;
> http.open("GET", url, true);
> http.onreadystatechange = handleHttpResponse3;
> http.send(null);
> }

Prøv at smide en http = null; ind - kan være fordi dit ajax objekt
allerede er benyttet... Så derfor afinitialiserer man altid sine ting :)

En anden ting, kan være caching, din browser kan cache et eller andet.

Har du prøvet med firefox, og installer firebug, så du kan se hvad der
bliver kaldt af diverse ting og sager :)

---

>> function doTransfer(){
>> var url = "backend2.php?navn=" +
>> document.getElementById('return1').value;
>> url += "&holdid=" + document.getElementById('holdid').value;
>> http.open("GET", url, true);
>> http.onreadystatechange = handleHttpResponse3;
>> http.send(null);
>> }
>
> Prøv at smide en http = null; ind - kan være fordi dit ajax objekt
> allerede er benyttet... Så derfor afinitialiserer man altid sine ting :)

er det ikke allerede det jeg gør her:
http.send(null);
??

> En anden ting, kan være caching, din browser kan cache et eller andet.

Ja måske, hvordan cleare man det..

> Har du prøvet med firefox, og installer firebug, så du kan se hvad der
> bliver kaldt af diverse ting og sager :)

Hmm måske en ide :D

Mvh
Morten

---

"Mr J.." <Nomail@nomail.dk> skrev i en meddelelse
news:4746985c$0$90268$14726298@news.sunsite.dk...
>>> function doTransfer(){
>>> var url = "backend2.php?navn=" +
>>> document.getElementById('return1').value;
>>> url += "&holdid=" + document.getElementById('holdid').value;
>>> http.open("GET", url, true);
>>> http.onreadystatechange = handleHttpResponse3;
>>> http.send(null);
>>> }
>>
>> Prøv at smide en http = null; ind - kan være fordi dit ajax objekt
>> allerede er benyttet... Så derfor afinitialiserer man altid sine ting :)
>
> er det ikke allerede det jeg gør her:
> http.send(null);
> ??
>
>> En anden ting, kan være caching, din browser kan cache et eller andet.
>
> Ja måske, hvordan cleare man det..
>
>> Har du prøvet med firefox, og installer firebug, så du kan se hvad der
>> bliver kaldt af diverse ting og sager :)
>
> Hmm måske en ide :D
>
> Mvh
> Morten
>

http.send( null) fortæller bare at du ikke sender data med requesten (andet
end via "kommandolinien" - hvilket er hvad man gør med GET...)
Nogle af os lidt ældre programmører, initialiserer alting før de bruges, og
fjerner dem igen, når de ikke længere skal bruges.
Det er måske lidt gammeldags (og tidsspilde), og ikke nødvendigt i mange
"moderne" sprog.
I et sprog som Java, findes noget der kaldes en "garbage-collector", der
fjerner variable og objecter, når de ikke længere skal bruges.
Hvordan det er i javascript, har jeg aldrig set hverken dokumenteret eller
omtalt.
Til gengæld, så er det meget nemt at oprette objecter i javascript - og der
er ikke rigtigt nogen metoder til at fjerne dem igen, så jeg har aldrig
gjort det, men antaget at en "garbage-collector" tog sig af den slags.

Man kan som Martin foreslår, sætte et object = null. Det er dog ikke den
rigtige vej at gå. Objecter har metoder (constructor)der kaldes ved
opretning, der sørger for at allokere den nødvendige hukommelse, sætte
pointere og tildele andre værdier. Når et object fjernes, skal specielt den
allokerede hukommelse frigives igen, og dette gøre ved kald af en
"destructor". Blot at sætte variablen=null, gør ikke disse ting (at sætte
den lig null, kan dog godt aktivere en garbage collector).

Der er rent principielt ikke noget i vejen for at kalde samme funktion 2
gange.
Det eneste du så skal passe på, er ikke at starte det andet kald, før det
første er helt færdigt.
Du kan forhindre det, ved at sætte 3. parameter i http.open til false - så
venter programmet med at fortsætte, til requesten er foretaget.
http.open("GET", url, false);
(Et alternativ, som måske er mere brugervenligt, men kræver mere - eller i
hvert fald lidt mere kompliceret - programmering, er at oprette et object
til hver request).

Men jeg tror ikke det er det, der er dit problem.
Du ville få nogle meget alvorligere fejl...

Jeg ved ikke hvordan du har bygget tingene op.
Umiddelbart tænkte jeg, at du brugte en "onchange" et eller andet sted - den
bliver først aktiveret, hvis noget ændres - og selv om man går ind og vælger
det samme som allerede er valgt, bliver onchange ikke kaldt.
Men du skriver om en knap - og så kan jeg faktisk ikke forstå at tingene
ikke virker - med mindre det er som Martin siger, at siden hentes fra cache.
Du kan prøve, at indsætte følgende 2 linier
http.setRequestHeaders( 'Pragma', 'no-cache');
http.setRequestHeaders( 'Cache-Control', 'no-cache');
mellem http.open() og http.send()
De skulle være sådan pr. default - men det kan ikke skade at sikre sig.
I øvrigt har forskellige browsere, forskellige muligheder for at sætte hvor
tit en given side skal checkes for "ny version".

Jeg bruger FireFox med Firebrug, som Martin også anbefaler, til udvikling -
det er et utroligt godt værktøj, og kan varmt anbefales - og jeg sætter
desuden min FF til slet ikke at bruge cache, så er den slags ikke noget
problem.

En sidste bemærkning om din scripting, skal være at du bør encode dine
parametre til dine requests:
var url = "backend2.php?navn=" + document.getElementById('return1').value;
url += "&holdid=" + document.getElementById('holdid').value;
bør hedde :
var url = "backend2.php?navn=" + encodeURIComponent(
document.getElementById('return1').value);
url += "&holdid=" + encodeURIComponent(
document.getElementById('holdid').value);

Birger

---

For det første, må jeg sige at jeg nyder dine svar Birger, dem er der sq
noget gods i, tak :)

> Jeg ved ikke hvordan du har bygget tingene op.
> Umiddelbart tænkte jeg, at du brugte en "onchange" et eller andet sted -
> den bliver først aktiveret, hvis noget ændres - og selv om man går ind og
> vælger det samme som allerede er valgt, bliver onchange ikke kaldt.
> Men du skriver om en knap - og så kan jeg faktisk ikke forstå at tingene
> ikke virker - med mindre det er som Martin siger, at siden hentes fra
> cache.

Ok, en lille udpensling :)
Jeg har et <text> felt, den aktiveres via onkeyup, og dens output kommer til
en <select>, og det virker super fint, <select> boksen bliver løbende
opdateret hvis man ændre teksten i den første <text>. så det spiller 100%
Efter <Select>'en er der så en button, som laver en
onClick=\"doTransfer();\" og det virker godt nok, intputtet fra denne
<select> bliver kastet over i en ny <select> den kalder vi så <select1> for
ikke at forvirre for meget :D
Tingene kommer fint fra <s> til <s1> intet problem her.
Hver gang ting kommer fra <s> til <s1> bliver de via php og ajax smid i en
database, og det virker også super fint.
<s1> bliver lavet i php scriptet og echo'et ud i en div, som hedder list.

næste del af siden er at man skal kunne fjerne personer fra <s1> delen igen,
så nå <s1> kommer frem, så kommer der også en [fjern person] knap frem.
denne kører: onClick=\"doRemove();\" og det virker også 100%

Nu kommer problemet:
Hvis man nu har til føjet 5 navne til <s1>, og så fjerner 2 igen, så er <s1>
under list diven, opdateret fint nok med de 3 navne der er tilbage.
MEN hvis jeg nu klikker oppe på den knap der skal tilføje en ny person til
listen og <s> IKKE er ændret siden sidst jeg gjorde det, så bliver <s1>
opdateret med det som min doTransfer() lavede af output sidst!! dvs nu er
alle 5 personer igen på listen. Så AJAX har ikke været nede og tage fat i
php scriptet, men bruger bare det output den funktion sidst kom med..
Men HVIS jeg har ændret <s> dvs valgt et andet navn, og klikker på min
tilføj knap, så bliver <s1> opdateret som den skal, og viser det som faktisk
er i min database..

Konklution: hvis man IKKE tager nye gets med så bliver php scriptet bagved
IKKE kørt :(

Gav den forklaring mere mening?

> Du kan prøve, at indsætte følgende 2 linier
> http.setRequestHeaders( 'Pragma', 'no-cache');
> http.setRequestHeaders( 'Cache-Control', 'no-cache');
> mellem http.open() og http.send()

Hehe så fejler javascriptet bare :(
"Objektet understøtter ikke denne egenskab eller metode"

> Jeg bruger FireFox med Firebrug, som Martin også anbefaler, til
> udvikling - det er et utroligt godt værktøj, og kan varmt anbefales - og
> jeg sætter desuden min FF til slet ikke at bruge cache, så er den slags
> ikke noget problem.

Ja men kan jo ikke sætte min browser til andet end std, skal jo vide hvordan
det vil reagere andre steder :/
Men vil da prøve det nymodens FF ;D

> En sidste bemærkning om din scripting, skal være at du bør encode dine
> parametre til dine requests:
> var url = "backend2.php?navn=" +
> document.getElementById('return1').value;
> url += "&holdid=" + document.getElementById('holdid').value;
> bør hedde :
> var url = "backend2.php?navn=" + encodeURIComponent(
> document.getElementById('return1').value);
> url += "&holdid=" + encodeURIComponent(
> document.getElementById('holdid').value);

Er rettet, det gav ingen ændring..

Mvh
Morten

---

"Mr J.." <Nomail@nomail.dk> skrev i en meddelelse
news:4746d4b3$0$90266$14726298@news.sunsite.dk...

Jeg skal prøve at se på din udredning i morgen.
Er lidt travl lige nu.

Kan dog lige sige :
Der indsneg sig en fejl (kan man få fartbøde i nyhedsgrupperne?) - der skal
ikke s på setRequestHeader()

Så du kan prøve, at indsætte følgende 2 linier
http.setRequestHeader( 'Pragma', 'no-cache');
http.setRequestHeader( 'Cache-Control', 'no-cache');
mellem http.open() og http.send()
;>)

encodeURIComponent skulle helst heller ikke give anledning til anderledes
funktion. Den indkoder karakterer, som ellers kan give problemer i de data
der overføres (mellemrum, de danske, &, ? og flere andre), og man bruger
den, for ikke at skulle bekymre sig om den slags problemer.
Du ville have bemærket det, hvis der havde været brug for den slags før du
tilføjede den.

Birger

---

Birger wrote:

> Jeg skal prøve at se på din udredning i morgen.
> Er lidt travl lige nu.

Jeg er ikke nede i materien i denne her tråd, men som du selv skriver, så er
vi nogle, der initialiserer vores ting.

En metode er at en ændring af en given property kalder en bagvedliggende
'setter' metode. Denne 'setter' metode sårger så for bagvedliggende
initialiseringer.

Med det i tankerne kan jeg godt forestille mig, at 'setter' metoden opdager,
at der ikke er ændring i propertien (url), og dermed 'glemmer' at nulstille
readystate.

Hov.. jeg tjekker lige spec's ovre hos w3c ....
<hmm>
If open() is called when readyState is 4 (Loaded) the entire object MUST be
reset.
</hmm>

Når jeg kigger lidt tilbage i tråden ser det ud som om Morten bruger den her
?Blød browser, så der er ikke umuligt at den ikke _overholder_
standarderne.

Morten kunne prøve det der høkertrick med at tilføje en dummy variabel, så
URI'en altid er forskellig. Altså noget ala
'&dummy=EtEllerAndetForskelligtTal' - Ahh jeg elsker lange variabelnavne.

--
Med venlig hilsen
Stig Johansen

---

> Når jeg kigger lidt tilbage i tråden ser det ud som om Morten bruger den
> her
> ?Blød browser, så der er ikke umuligt at den ikke _overholder_
> standarderne.
>
> Morten kunne prøve det der høkertrick med at tilføje en dummy variabel, så
> URI'en altid er forskellig. Altså noget ala
> '&dummy=EtEllerAndetForskelligtTal' - Ahh jeg elsker lange variabelnavne.

Hej Stig.

Hmm interssant teori, jeg vil afprøve det med at sætte et tidsstempel på :)

vender tilbage mandag :)

Mvh
Morten

---

"Stig Johansen" <stig_johansen_it_at_=(@)hotmail.com> skrev i en meddelelse
news:4747c325$0$90273$14726298@news.sunsite.dk...
> Birger wrote:
>
>> Jeg skal prøve at se på din udredning i morgen.
>> Er lidt travl lige nu.
>
> Jeg er ikke nede i materien i denne her tråd, men som du selv skriver, så
> er
> vi nogle, der initialiserer vores ting.
>
> En metode er at en ændring af en given property kalder en bagvedliggende
> 'setter' metode. Denne 'setter' metode sårger så for bagvedliggende
> initialiseringer.
>
> Med det i tankerne kan jeg godt forestille mig, at 'setter' metoden
> opdager,
> at der ikke er ændring i propertien (url), og dermed 'glemmer' at
> nulstille
> readystate.
>
> Hov.. jeg tjekker lige spec's ovre hos w3c ....
> <hmm>
> If open() is called when readyState is 4 (Loaded) the entire object MUST
> be
> reset.
> </hmm>
>
> Når jeg kigger lidt tilbage i tråden ser det ud som om Morten bruger den
> her
> ?Blød browser, så der er ikke umuligt at den ikke _overholder_
> standarderne.
>
> Morten kunne prøve det der høkertrick med at tilføje en dummy variabel, så
> URI'en altid er forskellig. Altså noget ala
> '&dummy=EtEllerAndetForskelligtTal' - Ahh jeg elsker lange variabelnavne.
>

Jeg initialiserer da også altid.
Og fjerner igen, i hvert fald i Delphi (Pascal). De andre, kan selv...

W3C's DRAFT til standarden er vist stort set bygget over den faktiske udgave
fra de små bløde.
Derfor kan du godt have ret - hvis værdien er den samme, er der ingen grund
til at sætte den, hvorved resten af initialiseringen godt kunne blive
sprunget over.

I M$ dokumentation om XMLHttpRequest, står desuden :
"Microsoft Internet Explorer caches the results of HTTP GET requests in the
Temporary Internet Files (TIF) folder. In most cases, caching improves
performance for data that will not change frequently. To guarantee that the
results are not cached, use POST."


Tror måske Morten vil stå sig i at være sikker på at hver request, bruger
sit eget object.
doTransfer() funktionen - og andre der snakker med serverside - bør oprette
et nyt object, hver gang. Det burde sikre at der ikke anvendes værdier fra
tidligere requests. For at være sikker på at omgå cache i IE (ikke anvende
den), bør requesten så også udføres som en POST i stedet for en GET.

Birger

---

> Tror måske Morten vil stå sig i at være sikker på at hver request, bruger
> sit eget object.
> doTransfer() funktionen - og andre der snakker med serverside - bør
> oprette et nyt object, hver gang. Det burde sikre at der ikke anvendes
> værdier fra tidligere requests. For at være sikker på at omgå cache i IE
> (ikke anvende den), bør requesten så også udføres som en POST i stedet for
> en GET.

Er der forskel på POST og GET's opsætning når vi snakker AJAX? (ud over det
elvanelige)eller er det bare at ændre fra get til post?

Mvh
Morten

---

"Morten Juel" <xSnAbElAstarchild.dk> skrev i en meddelelse
news:4747f31c$0$90265$14726298@news.sunsite.dk...
>> Tror måske Morten vil stå sig i at være sikker på at hver request, bruger
>> sit eget object.
>> doTransfer() funktionen - og andre der snakker med serverside - bør
>> oprette et nyt object, hver gang. Det burde sikre at der ikke anvendes
>> værdier fra tidligere requests. For at være sikker på at omgå cache i IE
>> (ikke anvende den), bør requesten så også udføres som en POST i stedet
>> for en GET.
>
> Er der forskel på POST og GET's opsætning når vi snakker AJAX? (ud over
> det elvanelige)eller er det bare at ændre fra get til post?
>
> Mvh
> Morten
>

I scriptet skal du ændre fra POST til GET.
Rent principielt, bør du også flytte data til at blive sendt i send() -
hvilket vil betyde, at du også skal ændre $_GET til $_POST i PHP.
Umiddelbart ville jeg forsøge, blot at ændre fra GET til POST i open(), uden
at ændre andet. Hvis det er IE der cache'er når/fordi du GET'ter, burde det
løse problemet.
(Tidligere debatteret - desuden viser test at det fungerer fint at putte
parametrene i URL'en, selv om man faktisk POST'er..)

Birger

---

Birger wrote:

> (Tidligere debatteret - desuden viser test at det fungerer fint at putte
> parametrene i URL'en, selv om man faktisk POST'er..)

Jeps, men lige for at udpensle:
En <a href..> genererer en GET.
En <form> genererer en POST.

De parametre man propper i URL'en er de samme som man ellers ville have
proppet i <a href..> eller i *action* delen af <form>

*Indholdet* af den tilsvarende <form..>, input,textarea osv. er de data man
propper ned i 'send' delen.

Til en vis grænse er der fri bevægelighed, men der er typisk begrænsninger
på _størrelsen_ af en URI.

Jeg spørger lige Google om nogle tal.. (url size limit)...
Jo, det er faktisk ret specifikt for en given 'browser'(2048/2083):
<http://support.microsoft.com/kb/208427>

Bemærk dog at der er en lille smutter i artiklen, de skriver:
...These pairs are transferred in the header and not in the URL. ..
Det er ikke korrekt, de bliver sendt i body delen, og ikke i header delen.

Andre nævner begrænsninger helt ned til 255 osv.

--
Med venlig hilsen
Stig Johansen

---

Birger wrote:

> Jeg initialiserer da også altid.
> Og fjerner igen, i hvert fald i Delphi (Pascal). De andre, kan selv...

WTF? Er du så'n en?

--
Med venlig hilsen
Stig Johansen
(MS Pascal -> Polypascal -> Turbo Pascal -> Delphi/Kylix ...)

---

"Stig Johansen" <stig_johansen_it_at_=(@)hotmail.com> skrev i en meddelelse
news:4749112f$0$90269$14726298@news.sunsite.dk...
> Birger wrote:
>
>> Jeg initialiserer da også altid.
>> Og fjerner igen, i hvert fald i Delphi (Pascal). De andre, kan selv...
>
> WTF? Er du så'n en?
>
> --
> Med venlig hilsen
> Stig Johansen
> (MS Pascal -> Polypascal -> Turbo Pascal -> Delphi/Kylix ...)
>

Jamen jo da.

Birger
CB64 -> MS Basic -> Turbo Basic -> Turbo Pascal -> Delphi

---

> CB64 -> MS Basic -> Turbo Basic -> Turbo Pascal -> Delphi

Programmerede mit afgangs projekt på HTX tilbage i 1997 i Turbo Pascal :D

Mvh
Morten

---

Birger wrote:

> Birger
> CB64 -> MS Basic -> Turbo Basic -> Turbo Pascal -> Delphi

CB64, hvad er det? Det kan da ikke have været 64 bit?
For 1/4 århundrede siden rodede jeg mest med COBOL m.v., og 'jern' man
nærmest kunne gå på skovtur i, så det var først i '85-'86 jeg også begyndte
at kigge på PC'ere.

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <stig_johansen_it_at_=(@)hotmail.com> skrev i en meddelelse
news:474a5501$0$90264$14726298@news.sunsite.dk...
> Birger wrote:
>
>> Birger
>> CB64 -> MS Basic -> Turbo Basic -> Turbo Pascal -> Delphi
>
> CB64, hvad er det? Det kan da ikke have været 64 bit?
> For 1/4 århundrede siden rodede jeg mest med COBOL m.v., og 'jern' man
> nærmest kunne gå på skovtur i, så det var først i '85-'86 jeg også
> begyndte
> at kigge på PC'ere.
>
> --
> Med venlig hilsen
> Stig Johansen

Commodore Business Machines 64 - bør vel så hedde CBM64
64 står for hukommelsen - 64 Kbyte.
Den kunne programmeres i noget der lignede BASIC - 6 kommandoer.
Det var dengang en ung mand ved navn Bill Gates udtalte at "et program der
fylder mere end 12Kbyte, er ikke værd at beskæftige sig med."
Som tiden dog går... ;>)

Birger

---

> Det var dengang en ung mand ved navn Bill Gates udtalte at "et program der
> fylder mere end 12Kbyte, er ikke værd at beskæftige sig med."
> Som tiden dog går... ;>)

Hehe ville gerne se en 12Kbyte version af vista, det kan kun blive til
logoet :D

Mvh
Morten

---

> Morten kunne prøve det der høkertrick med at tilføje en dummy variabel, så
> URI'en altid er forskellig. Altså noget ala
> '&dummy=EtEllerAndetForskelligtTal' - Ahh jeg elsker lange variabelnavne.

url += "&time=" + getTime();

Det vil den ikke, så laver mit javascript bare en fejl.. ihh er sq ikke
venner med JS....

Mvh
Morten

---

Stig Johansen <stig_johansen_it_at_=(@)hotmail.com> writes:

> Birger wrote:
>
>> (Tidligere debatteret - desuden viser test at det fungerer fint at putte
>> parametrene i URL'en, selv om man faktisk POST'er..)

Det afhænger udelukkende af serveren. Den får URL'en som del af
HTTP-kommandoen og POST-parametrene senere i HTTP-body.
Hvis den vælger at parse begge og gøre dem tilgængelige på serversiden,
så virker det. Hvis den vælger ikke at parse URL'en på en POST-
kommando, så gør det ikke. Jeg gætter på at de fleste serverside-
teknologier parser så meget som muligt.

> Jeps, men lige for at udpensle:
> En <a href..> genererer en GET.
> En <form> genererer en POST.

Mere præcist: En <form action="..." method="POST"> genererer en POST,
mens en <form action="..." method="GET"> genererer en GET.
Hvis man ikke angiver method-attributten er default GET!

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

Lasse Reichstein Nielsen wrote:

> Det afhænger udelukkende af serveren. Den får URL'en som del af
> HTTP-kommandoen og POST-parametrene senere i HTTP-body.
> Hvis den vælger at parse begge og gøre dem tilgængelige på serversiden,
> så virker det. Hvis den vælger ikke at parse URL'en på en POST-
> kommando, så gør det ikke. Jeg gætter på at de fleste serverside-
> teknologier parser så meget som muligt.

Jeg tror også, at de fleste servere parser URI'en på POST, men en af de ting
Birger var ude i var at sende en body del sammen med en GET. Her tror jeg
til gengæld de fleste servere stopper ved headerne, og ignorer body'en.

--
Med venlig hilsen
Stig Johansen

---

"Birger" <sdc@bbsorensen.com> writes:

> Commodore Business Machines 64 - bør vel så hedde CBM64
> 64 står for hukommelsen - 64 Kbyte.
> Den kunne programmeres i noget der lignede BASIC - 6 kommandoer.

*Ligneded* BASIC?!? Det var skam BASIC: Commodore BASIC 2.0,
som var baseret på Microsoft BASIC>
(Der er heldigvis ingen standard for BASIC, så alt der kalder sig
BASIC er BASIC :)

For en der kom fra Spectrum-BASIC var det noget af et tilbageskridt ...
men den havde bedre lyd og grafik, og det var jo det der vandt :)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

TADAAA det virker hvis jeg sætter en GET dummy ind..

url += "&time=" + Math.random();

Perfekt :)

Mange tak for alt jeres gode hjælp.

Mvh
Morten