---

Hejsa

Jeg har brug for en måde hvorpå jeg kan hente indhold fra andre
sider, og vise det i forskellige div's på min side (side1=div1,
side2=div2, side3=div3 etc.) samtidig med at mine div's refreshes
hvert sekund.

Har fundet et Ajax-script, som umiddelbart lader til at klare
ærterne... dog kan det åbenbart kun bruges én gang på min side,
da jeg har forsøgt at kopiere det hver gang jeg har en div hvori
indholdet skal hentes fra en anden side og opdatere sig selv,
hvilket har resulteret i at det kun er én div ud af dem alle hvor
scriptet har en effekt.

AJAX-SCRIPT:
<script>
function Ajax(){
var xmlHttp;
try{xmlHttp=new XMLHttpRequest();}
catch (e){
try{xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");}
catch (e){
try{xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");}
catch (e){
alert("No AJAX!?");
return false;}}}
xmlHttp.onreadystatechange=function(){
if(xmlHttp.readyState==4){
document.getElementById('divId').innerHTML=xmlHttp.responseText;
setTimeout('Ajax()',1000);}}
xmlHttp.open("GET","http://side.html",true);
xmlHttp.send(null);}
window.onload=function(){
setTimeout('Ajax()',1000);}
</script>

Kan nogen evt. tilrette scriptet her så det kan lade sig gøre at
hente indhold til mere end en div, fra mere end en side?

Venligst
Ace

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ace tastede følgende:
> Hejsa
>
> Jeg har brug for en måde hvorpå jeg kan hente indhold fra andre
> sider, og vise det i forskellige div's på min side (side1=div1,
> side2=div2, side3=div3 etc.) samtidig med at mine div's refreshes
> hvert sekund.
>
> Har fundet et Ajax-script, som umiddelbart lader til at klare
> ærterne... dog kan det åbenbart kun bruges én gang på min side,
> da jeg har forsøgt at kopiere det hver gang jeg har en div hvori
> indholdet skal hentes fra en anden side og opdatere sig selv,
> hvilket har resulteret i at det kun er én div ud af dem alle hvor
> scriptet har en effekt.
>
> AJAX-SCRIPT:
> <script>
> function Ajax(){
> var xmlHttp;
> try{xmlHttp=new XMLHttpRequest();}
> catch (e){
> try{xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");}
> catch (e){
> try{xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");}
> catch (e){
> alert("No AJAX!?");
> return false;}}}
> xmlHttp.onreadystatechange=function(){
> if(xmlHttp.readyState==4){
> document.getElementById('divId').innerHTML=xmlHttp.responseText;
> setTimeout('Ajax()',1000);}}
> xmlHttp.open("GET","http://side.html",true);
> xmlHttp.send(null);}
> window.onload=function(){
> setTimeout('Ajax()',1000);}
> </script>
>
> Kan nogen evt. tilrette scriptet her så det kan lade sig gøre at
> hente indhold til mere end en div, fra mere end en side?
>
> Venligst
> Ace

Først, burde der være en type i script elementet.
Dernæst er din kode temmelig uoverskuelig...

<script type="text/javascript">
function Ajax(){
   var xmlHttp;
   try {
      xmlHttp=new XMLHttpRequest();
      }
   catch (e){
      try {
         xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
         }
      catch (e) {
         try {
            xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
            }
         catch (e) {
            alert("No AJAX!?");
            return false;
            }
         }
      }
   xmlHttp.onreadystatechange=function() {
      if(xmlHttp.readyState==4) {
         document.getElementById('divId').innerHTML=xmlHttp.responseText;
         setTimeout('Ajax()',1000);
         }
      }
   xmlHttp.open("GET","http://side.html",true);
   xmlHttp.send(null);
   }

window.onload=function(){
   setTimeout('Ajax()',1000);
   }
</script>

Så hjælper det lidt på det.
Der er lidt mangler, måske, men umiddelbart, er der ikke noget der
forhindrer at den genbruges.
Du vil skulle rette "divID", "side.html" og timeouten til, for hver
funktion, og du vil også skulle sætte en timer for hver af dem i
window.onload
Man kunne godt forestille sig en hel del simplificering/optimering -
men så vidt jeg lige kan se, burde der ikke være noget der hindrer det
i at virke..
Umiddelbart er det eneste, at open - i hvert fald en gang i tidernes
morgen - skulle være den første metode der kaldes på objectet, så måske
skal du sætte den foran onreadystatechange.
Endelig checkes der på readySatate == 4. Det betyder at kommunikation
med serveren er afsluttet. Det betyder ikke at denne nødvendigvis var
vellykket - men dit program lader som ingenting, hvilket kan resultere
i besynderligheder...
Noget i retning af

if ( xmlHttp.readyState == 4) {
if ( xmlHttp.status == 200) {
document.getElementById('divId').innerHTML=xmlHttp.responseText;
}
else {
alert( 'AJAX fejl:\n'+'Status: '+xmlHttp.status+'\nBeskr:
'+xmlHttp.statusText);
}
setTimeout('Ajax()',1000);
}

ville kurere det..
Desuden vil denne tilpasning også fortælle dig, hvis noget går galt, af
den ene eller anden årsag.

Birger

---

Birger Sørensen skrev:

> <script type="text/javascript">
> function Ajax(){
>    var xmlHttp;
>    try {
>       xmlHttp=new XMLHttpRequest();
>       }
>    catch (e){
>       try {
>          xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
>          }
>       catch (e) {
>          try {
>             xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
>             }
>          catch (e) {
>             alert("No AJAX!?");
>             return false;
>             }
>          }
>       }
>    xmlHttp.onreadystatechange=function() {
>       if(xmlHttp.readyState==4) {
>          document.getElementById('divId').innerHTML=xmlHttp.responseText;
>          setTimeout('Ajax()',1000);
>          }
>       }
>    xmlHttp.open("GET","http://side.html",true);
>    xmlHttp.send(null);
>    }
>
> window.onload=function(){
>    setTimeout('Ajax()',1000);
>    }
> </script>
>
> Så hjælper det lidt på det.
> Der er lidt mangler, måske, men umiddelbart, er der ikke noget der
> forhindrer at den genbruges.
> Du vil skulle rette "divID", "side.html" og timeouten til, for hver
> funktion, og du vil også skulle sætte en timer for hver af dem i
> window.onload

Okay, jeg er med på at det er nødvendigt at ændre divId og url til at
passe til de respektive div's og sider, men skal jeg derudover også ændre
setTimeOut-værdien i henholdsvis xmlHttp.responseText;
setTimeout('Ajax()',1000); og window.onload=function(){
setTimeout('Ajax()',1000); for hver gang jeg vil hente indhold til en
div?.. i såfald, vil det så sige at alle mine div's ikke kan opdateres
hvert sekund?

Et andet spørgsmål (lidt i forlængelse): Kan man ikke på en eller anden
måde spare sig, at skulle genbruge scriptet om og om igen, ved at samle
det hele i ét script der kan hente indhold fra alle siderne til alle
div'erne på én gang?

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ace kom med denne ide:
> Birger Sørensen skrev:
>
>> <script type="text/javascript">
>> function Ajax(){
>>    var xmlHttp;
>>    try {
>>       xmlHttp=new XMLHttpRequest();
>>       }
>>    catch (e){
>>       try {
>>          xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
>>          }
>>       catch (e) {
>>          try {
>>             xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
>>             }
>>          catch (e) {
>>             alert("No AJAX!?");
>>             return false;
>>             }
>>          }
>>       }
>>    xmlHttp.onreadystatechange=function() {
>>       if(xmlHttp.readyState==4) {
>>          document.getElementById('divId').innerHTML=xmlHttp.responseText;
>>          setTimeout('Ajax()',1000);
>>          }
>>       }
>>    xmlHttp.open("GET","http://side.html",true);
>>    xmlHttp.send(null);
>>    }
>>
>> window.onload=function(){
>>    setTimeout('Ajax()',1000);
>>    }
>> </script>
>>
>> Så hjælper det lidt på det.
>> Der er lidt mangler, måske, men umiddelbart, er der ikke noget der
>> forhindrer at den genbruges.
>> Du vil skulle rette "divID", "side.html" og timeouten til, for hver
>> funktion, og du vil også skulle sætte en timer for hver af dem i
>> window.onload
>
> Okay, jeg er med på at det er nødvendigt at ændre divId og url til at
> passe til de respektive div's og sider, men skal jeg derudover også ændre
> setTimeOut-værdien i henholdsvis xmlHttp.responseText;
> setTimeout('Ajax()',1000); og window.onload=function(){
> setTimeout('Ajax()',1000); for hver gang jeg vil hente indhold til en
> div?.. i såfald, vil det så sige at alle mine div's ikke kan opdateres
> hvert sekund?
>
> Et andet spørgsmål (lidt i forlængelse): Kan man ikke på en eller anden
> måde spare sig, at skulle genbruge scriptet om og om igen, ved at samle
> det hele i ét script der kan hente indhold fra alle siderne til alle
> div'erne på én gang?


Nej, dine divs kan godt opdateres hvert sekund - i hvert fald så længe
rugeren har resourcer nok, og serveren ikke bliver overbelastet.. ;>)

Det der bestemmer, hvilken side der hentes, er parametren i open :
xmlHttp.open("GET", *"http://side.html"*,true);
Som du har sat tingene sammen, er det nødvendigt at have en funktion
for hver side.
Her skal du så tilpasse den div du vil have resultatet vist i, siden
der skal hentes, og funktionen der skal kaldes i timeouten - som jo er
den der sørger for at opdatere hvert sekund..

---

Birger Sørensen:
> Ace kom med denne ide:
>> Birger Sørensen skrev:
>>
>>> <script type="text/javascript"> function Ajax(){    var xmlHttp;    try {
>>>       xmlHttp=new XMLHttpRequest();       }    catch (e){       try {          xmlHttp=new
>>> ActiveXObject("Msxml2.XMLHTTP");          }       catch (e) {          try {
>>>             xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");             }          catch (e) {
>>>             alert("No AJAX!?");             return false;             }          }       }
>>>    xmlHttp.onreadystatechange=function() {       if(xmlHttp.readyState==4) {
>>>          document.getElementById('divId').innerHTML=xmlHttp.responseText;
>>>          setTimeout('Ajax()',1000);          }       }
>>>    xmlHttp.open("GET","http://side.html",true);    xmlHttp.send(null);    }
>>> window.onload=function(){    setTimeout('Ajax()',1000);    } </script>
>>> Så hjælper det lidt på det. Der er lidt mangler, måske, men umiddelbart,
>>> er der ikke noget der forhindrer at den genbruges. Du vil skulle rette
>>> "divID", "side.html" og timeouten til, for hver funktion, og du vil også
>>> skulle sætte en timer for hver af dem i window.onload
>>
>> Okay, jeg er med på at det er nødvendigt at ændre divId og url til at
>> passe til de respektive div's og sider, men skal jeg derudover også ændre
>> setTimeOut-værdien i henholdsvis xmlHttp.responseText;
>> setTimeout('Ajax()',1000); og window.onload=function(){
>> setTimeout('Ajax()',1000); for hver gang jeg vil hente indhold til en
>> div?.. i såfald, vil det så sige at alle mine div's ikke kan opdateres
>> hvert sekund?
>>
>> Et andet spørgsmål (lidt i forlængelse): Kan man ikke på en eller anden
>> måde spare sig, at skulle genbruge scriptet om og om igen, ved at samle
>> det hele i ét script der kan hente indhold fra alle siderne til alle
>> div'erne på én gang?
>
>
> Nej, dine divs kan godt opdateres hvert sekund - i hvert fald så længe
> brugeren har resourcer nok, og serveren ikke bliver overbelastet.. ;>)
>
> Det der bestemmer, hvilken side der hentes, er parametren i open :
> xmlHttp.open("GET", *"http://side.html"*,true);
> Som du har sat tingene sammen, er det nødvendigt at have en funktion for hver
> side.
> Her skal du så tilpasse den div du vil have resultatet vist i, siden der skal
> hentes, og funktionen der skal kaldes i timeouten - som jo er den der sørger
> for at opdatere hvert sekund..


Ved ikke lige hvad der skete her, men jeg fortsætter bare som ingenting
var hændt...

Dit andet spørgsmål, går på om det ikke kan gøres i en enkelt funktion.
Og jo, det kan det.
Du skla så bare have et par array's der indeholder navne på sider og
div's der hører sammen, og med en variabel vælge hvilken der opdateres.
Eller styre det med simple variable, som her :

<script type="text/javascript">
function makeAjax(){
var xmlHttp;
try {
xmlHttp=new XMLHttpRequest();
}
catch (e){
try {
xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e) {
try {
xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
}
catch (e) {
alert("No AJAX!?");
            xmlHttp = null;
}
}
}
   return xmlHttp;
   }

function HentX( x) {
   var side = '';
   var   divId = '';
   switch ( x) {
      case 1 :
         side = 'side1.html';
         divID = 'div1';
         break;
      case 2 :
         side = 'side2.html';
         divID = 'div2';
         break;
      //... indsæt selv så mange du har brug for
      default :
         side = '';
      }
   if ( side != ''){
      var xmlHttp = makeAjax();
      if ( xmlHttp != null) {
       xmlHttp.open( "GET", side, true);
       xmlHttp.onreadystatechange = function() {
            if ( xmlHttp.readyState == 4) {
               if ( xmlHttp.status == 200) {
                  document.getElementById( divId).innerHTML=xmlHttp.responseText;
                  }
               else {
                  alert( 'AJAX fejl:\n'+'Status: '+xmlHttp.status+'\nBeskr:
'+xmlHttp.statusText);
                  }
               }
            setTimeout( function() { HentX( x); }, 1000);
       }
       xmlHttp.send(null);
         }
      }
}

window.onload=function(){
setTimeout( function() { HentX( 1), 1000);
setTimeout( function() { HentX( 2), 1000);
   //... indsæt selv flere som nødvendigt
}

</script>


Bemærk, at det er ikke testet.
Spørg hvis det ikke gør, eller hvis du vil have forklaring.

Birger

---

Birger Sørensen skrev:

> <script type="text/javascript">
> function makeAjax(){
> var xmlHttp;
> try {
> xmlHttp=new XMLHttpRequest();
> }
> catch (e){
> try {
> xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
> }
> catch (e) {
> try {
> xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
> }
> catch (e) {
> alert("No AJAX!?");
>             xmlHttp = null;
> }
> }
> }
>    return xmlHttp;
>    }
>
> function HentX( x) {
>    var side = '';
>    var   divId = '';
>    switch ( x) {
>       case 1 :
>          side = 'side1.html';
>          divID = 'div1';
>          break;
>       case 2 :
>          side = 'side2.html';
>          divID = 'div2';
>          break;
>       //... indsæt selv så mange du har brug for
>       default :
>          side = '';
>       }
>    if ( side != ''){
>       var xmlHttp = makeAjax();
>       if ( xmlHttp != null) {
>        xmlHttp.open( "GET", side, true);
>        xmlHttp.onreadystatechange = function() {
>             if ( xmlHttp.readyState == 4) {
>                if ( xmlHttp.status == 200) {
>                   document.getElementById( divId).innerHTML=xmlHttp.responseText;
>                   }
>                else {
>                   alert( 'AJAX fejl:\n'+'Status: '+xmlHttp.status+'\nBeskr:
> '+xmlHttp.statusText);
>                   }
>                }
>             setTimeout( function() { HentX( x); }, 1000);
>        }
>        xmlHttp.send(null);
>          }
>       }
> }
>
> window.onload=function(){
> setTimeout( function() { HentX( 1), 1000);
> setTimeout( function() { HentX( 2), 1000);
>    //... indsæt selv flere som nødvendigt
> }
>
> </script>
>
>
> Bemærk, at det er ikke testet.
> Spørg hvis det ikke gør, eller hvis du vil have forklaring.

Som sådan ser scriptet ud til at være i stand til at kunne lige præcis dét jeg
efterspørger... men desværre sker der overhovedet ingenting efter jeg har ændret
divId'erne og url'erne - ved ikke hvad årsagen til det er, for der kommer heller
ikke nogen fejlmeddelelse.

Er det her ikke rigtig nok?
<script type="text/javascript">
function makeAjax(){
var xmlHttp;
try {
xmlHttp=new XMLHttpRequest();
}
catch (e){
try {
xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e) {
try {
xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
}
catch (e) {
alert("No AJAX!?");
xmlHttp = null;
}
}
}
return xmlHttp;
}

function HentX( x) {
var side = '';
var divId = '';
switch ( x) {
case 1 :
side = 'http://clubace.dk/chatAlert.php';
divID = 'chatAlert';
break;
case 2 :
side = 'http://clubace.dk/rss/dr_rssFeeds.php';
divID = 'rssFrame';
break;
case 3 :
side = 'http://clubace.dk/rss/dr_news1.php';
divID = 'dr_news1Frame';
break;
//... indsæt selv så mange du har brug for
default :
side = '';
}
if ( side != ''){
var xmlHttp = makeAjax();
if ( xmlHttp != null) {
xmlHttp.open( "GET", side, true);
xmlHttp.onreadystatechange = function() {
if ( xmlHttp.readyState == 4) {
if ( xmlHttp.status == 200) {
document.getElementById( divId).innerHTML=xmlHttp.responseText;
}
else {
alert( 'AJAX fejl:\n'+'Status: '+xmlHttp.status+'\nBeskr:
'+xmlHttp.statusText);
}
}
setTimeout( function() { HentX( x); }, 1000);
}
xmlHttp.send(null);
}
}
}

window.onload=function(){
setTimeout( function() { HentX( 1), 1000);
setTimeout( function() { HentX( 2), 1000);
setTimeout( function() { HentX( 3), 1000);
//... indsæt selv flere som nødvendigt
}
</script>

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ace:
....
> window.onload=function(){
> setTimeout( function() { HentX( 1), 1000);
> setTimeout( function() { HentX( 2), 1000);
> setTimeout( function() { HentX( 3), 1000);
> //... indsæt selv flere som nødvendigt
> }
> </script>

Der mangler nogle flere tuborg...

setTimeout( function() { HentX( 1); }, 1000);
setTimeout( function() { HentX( 2); }, 1000);
setTimeout( function() { HentX( 3); }, 1000);

der er også noget med variabelnavnet for divID - enten stort eller småt
- men ens skal det være...

....
var divId = '';
switch ( x) {
case 1 :
side = 'http://clubace.dk/chatAlert.php';
divID = 'chatAlert';
....
check også getElementById( ...)

Kan se fejlene også er i mit forslag - sådan går det nogen gange for
hurtigt... ;>)


Birger

---

Birger Sørensen skrev:

> Der mangler nogle flere tuborg...
>
> setTimeout( function() { HentX( 1); }, 1000);
> setTimeout( function() { HentX( 2); }, 1000);
> setTimeout( function() { HentX( 3); }, 1000);
>
> der er også noget med variabelnavnet for divID - enten stort eller småt
> - men ens skal det være...
>
> ....
> var divId = '';
> switch ( x) {
> case 1 :
> side = 'http://clubace.dk/chatAlert.php';
> divID = 'chatAlert';
> ....
> check også getElementById( ...)
>
> Kan se fejlene også er i mit forslag - sådan går det nogen gange for
> hurtigt... ;>)

Det helt i orden
Okay, jeg har nu tilføjet de ekstra tuborgklammer, sørget for at divId står
ens alle steder, og forsøgt mig med 'divId' i getElementById-parentesen...
men endnu uden held. Stadig kommer der intet indhold i div'erne.

Nu kommer der dog følgende fejlmeddelelse.
AJAX fejl:
Status:0
Beskr: Unknown

... aner desværre bare ikke hvad det betyder.

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ace formulerede tirsdag:
> Birger Sørensen skrev:
>
>> Der mangler nogle flere tuborg...
>>
>> setTimeout( function() { HentX( 1); }, 1000);
>> setTimeout( function() { HentX( 2); }, 1000);
>> setTimeout( function() { HentX( 3); }, 1000);
>>
>> der er også noget med variabelnavnet for divID - enten stort eller småt
>> - men ens skal det være...
>>
>> ....
>> var divId = '';
>> switch ( x) {
>> case 1 :
>> side = 'http://clubace.dk/chatAlert.php';
>> divID = 'chatAlert';
>> ....
>> check også getElementById( ...)
>>
>> Kan se fejlene også er i mit forslag - sådan går det nogen gange for
>> hurtigt... ;>)
>
> Det helt i orden
> Okay, jeg har nu tilføjet de ekstra tuborgklammer, sørget for at divId står
> ens alle steder, og forsøgt mig med 'divId' i getElementById-parentesen...
> men endnu uden held. Stadig kommer der intet indhold i div'erne.
>
> Nu kommer der dog følgende fejlmeddelelse.
> AJAX fejl:
> Status:0
> Beskr: Unknown
>
> .. aner desværre bare ikke hvad det betyder.

I getElementById() skal variabelnavnet stå uden apostroffer - bare for
at være sikker.

Hvilken Browser bruger du?
Der er noget med at FF ikke kan håndtere visse interne fejl i AJAX
objektet. (Laver faktisk en fejl under fejlhåndtering - og det vil
resultere i en fejl med Status 0, som vist ellers ikke bør forekomme..)

Ellers er FF en god ide - specielt en version med FireBug (som endnu
ikke virker i 3'eren), er god til udvikling af AJAX, fordi man faktisk
kan se kaldene, og den finde js-fejl.

Et link til siden, måske?

Birger

---

Birger Sørensen skrev:

> Hvilken Browser bruger du?
> Der er noget med at FF ikke kan håndtere visse interne fejl i AJAX
> objektet. (Laver faktisk en fejl under fejlhåndtering - og det vil
> resultere i en fejl med Status 0, som vist ellers ikke bør forekomme..)
>
> Ellers er FF en god ide - specielt en version med FireBug (som endnu
> ikke virker i 3'eren), er god til udvikling af AJAX, fordi man faktisk
> kan se kaldene, og den finde js-fejl.
>
> Et link til siden, måske?

Jeg bruger IE7 og har lige lavet en lille test af scriptet her:
http://clubace.dk/AJAX.htm

Men tænkte forresten på om makeAjax() ikke også skal tilegnes en setTimeOut?

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ace har bragt dette til verden:
> Birger Sørensen skrev:
>
>> Hvilken Browser bruger du?
>> Der er noget med at FF ikke kan håndtere visse interne fejl i AJAX
>> objektet. (Laver faktisk en fejl under fejlhåndtering - og det vil
>> resultere i en fejl med Status 0, som vist ellers ikke bør forekomme..)
>>
>> Ellers er FF en god ide - specielt en version med FireBug (som endnu
>> ikke virker i 3'eren), er god til udvikling af AJAX, fordi man faktisk
>> kan se kaldene, og den finde js-fejl.
>>
>> Et link til siden, måske?
>
> Jeg bruger IE7 og har lige lavet en lille test af scriptet her:
> http://clubace.dk/AJAX.htm
>
> Men tænkte forresten på om makeAjax() ikke også skal tilegnes en setTimeOut?


Hmmm...
Lidt hurtigt og ligefremt, og uden at være ude på at nedgøre eller
fornærme nogen, vil jeg sige, at det ser ikke ud somom du har nogen som
helst ide om hvad det er du laver.

Script skal stå i header sektionen af en html side. Og der hører
faktisk en header sektion til...

Der er bøvl med tuborgerne i makeAjax() - og nej, der skal ikke være en
timer til den - den kaldes af HentX().

Jeg har rettet de øvrige svipsere - uden at jeg her vil komme ind på
hvad og hvorfor, fordi jeg tror ikke det siger dig noget - og lagt en
side - som ikke er korrekt html, men fungerer med AJAX og det du havde
tænkt dig at gøre - op på mit eget domæne :
http://ajax_test.bbsorensen.dk
Der kan du hente den, og se om du kan blive lidt klogere

Du skal være opmærksom på, at man kan ikke hente med AJAX på tværs af
domæner - og hvis man skriver stien til filen der hentes fuldt ud, skal
man skrive den rigtigt http://... - ikke http.//... ^^

Jeg hjælper gerne som hjælp til selvhjælp.
Det kræver at du selv er i stand til at gøre lidt - men det er du vist
ikke rigtigt.
Jeg laver det også gerne for dig - hvis vi kan blive enige om en
fornuftig timepris.

Birger

---

Birger Sørensen wrote:

> http://ajax_test.bbsorensen.dk
> Der kan du hente den, og se om du kan blive lidt klogere

Jeg får denne her:
AJAX fejl:
Status: 304
Beskr: Not Modified

Det er vel egentlig ikke en fejl ?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen har bragt dette til verden:
> Birger Sørensen wrote:
>
>> http://ajax_test.bbsorensen.dk
>> Der kan du hente den, og se om du kan blive lidt klogere
>
> Jeg får denne her:
> AJAX fejl:
> Status: 304
> Beskr: Not Modified
>
> Det er vel egentlig ikke en fejl ?

Jeg ændrer jo ikke på indholdet i de to filer der hentes, så det
betyder vel blot at indholdet ikke er ændret siden sidst filen blev
hentet.
Men det er jo "de sædvanlige" http fejlkoder for kommunikationen - og
dem kender du vist bedre end jeg gør :')
Jeg har aldrig selv set den i forbindelse med AJAX, og får den heller
ikke selv på siden.
Hænger måske sammen med cache eller opdateringsindstillinger i
browseren?

Egentlig burde den jo ikke blive vist.
Kan du se om AJAX returnerer indholdet af filen, eller blot giver
beskeden?
Jeg tænker på, om man skal skille status 304 fra - og om man så
kan/skal opdatere feltet alligevel, eller droppe det også.

Birger

---

Birger Sørensen wrote:

> Jeg har aldrig selv set den i forbindelse med AJAX, og får den heller
> ikke selv på siden.

Jeg har lige tjekket med IE6 og FF3 på Windows.
IE6 henter siderne uanset hvad, da den tilsyneladende ikke benytte
if-modified-since/if-none-match headeren.

FF3 får en 304 Not modified på selve HTML'et, og viser de to div'er MEN jeg
kan se i min proxytrace, at den ikke opdaterer hvert sekund.

Det kunne se ud som om den ikke rigtig får startet timeout'erne - ?

> Hænger måske sammen med cache eller opdateringsindstillinger i
> browseren?

Min Konqueror derimod benytter sig af de ovenstående headere (=cache), så
der kommer to dialogbokse hvert sekund.
Jeg skal skynde mig at trykke ok,ok og hurtigt alt+f4 for at komme ud af
loopet.

Da jeg har haft den oppe før, ligger html'et også i cachen og det bevirker
at siden er blank.
Så anden gang jeg kigger får jeg en hvid side og disse dialogbokse hvert
sekund.

> Egentlig burde den jo ikke blive vist.
> Kan du se om AJAX returnerer indholdet af filen, eller blot giver
> beskeden?

Når det er en 304 Not modified følger der intet indhold med fra serveren,
kun headerne.
Det er meningen at klienten selv skal huske - og genbruge - det, der ligger
i cachen.

> Jeg tænker på, om man skal skille status 304 fra - og om man så
> kan/skal opdatere feltet alligevel, eller droppe det også.

Jeg ved ikke lige hvordan man løser det her problem (statiske filer),
bortset fra at tilføje noget random data til url'en.
Det har den ulempe, at brugerens cache bliver fyldt med de her kald.

Alternativt kan man lægge dem som php/asp sider, hvor der ikke er nogen
Last-modified header fra serveren.

Årsagen til du ikke har set det, er måske fordi du bruger php filer?

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen har bragt dette til verden:
> Birger Sørensen wrote:
>
>> Jeg har aldrig selv set den i forbindelse med AJAX, og får den heller
>> ikke selv på siden.
>
> Jeg har lige tjekket med IE6 og FF3 på Windows.
> IE6 henter siderne uanset hvad, da den tilsyneladende ikke benytte
> if-modified-since/if-none-match headeren.
>
> FF3 får en 304 Not modified på selve HTML'et, og viser de to div'er MEN jeg
> kan se i min proxytrace, at den ikke opdaterer hvert sekund.
>
> Det kunne se ud som om den ikke rigtig får startet timeout'erne - ?
>
>> Hænger måske sammen med cache eller opdateringsindstillinger i
>> browseren?
>
> Min Konqueror derimod benytter sig af de ovenstående headere (=cache), så
> der kommer to dialogbokse hvert sekund.
> Jeg skal skynde mig at trykke ok,ok og hurtigt alt+f4 for at komme ud af
> loopet.
>
> Da jeg har haft den oppe før, ligger html'et også i cachen og det bevirker
> at siden er blank.
> Så anden gang jeg kigger får jeg en hvid side og disse dialogbokse hvert
> sekund.
>
>> Egentlig burde den jo ikke blive vist.
>> Kan du se om AJAX returnerer indholdet af filen, eller blot giver
>> beskeden?
>
> Når det er en 304 Not modified følger der intet indhold med fra serveren,
> kun headerne.
> Det er meningen at klienten selv skal huske - og genbruge - det, der ligger
> i cachen.
>
>> Jeg tænker på, om man skal skille status 304 fra - og om man så
>> kan/skal opdatere feltet alligevel, eller droppe det også.
>
> Jeg ved ikke lige hvordan man løser det her problem (statiske filer),
> bortset fra at tilføje noget random data til url'en.
> Det har den ulempe, at brugerens cache bliver fyldt med de her kald.
>
> Alternativt kan man lægge dem som php/asp sider, hvor der ikke er nogen
> Last-modified header fra serveren.
>
> Årsagen til du ikke har set det, er måske fordi du bruger php filer?


Det vil så sige, at man bør filtrere 304 fra, og ikke opdatere
indholdet, skulle den komme.
Prøve lige at lægge det i koden...
Man burde jo egentlig også, forhindre at der er mere end een alert. Men
det bliver ikke nu... :/

Jeg har siden kørende her i IE7 og FF3 - og på FF 2.0.0.16 på den
bærbare.
Ingen af dem giver 304 fejl.

Ja - jeg bruger normalt php, så det kan jo være derfor.
Men det her er html. Og de gør det heller ikke.

Jeg syntes også, at opdatering af flere sider hvert sekund, måske er
lidt voldsomt.
Men det var præmisserne, så sådan blev det.

Timere startes i selve script-tagget direkte, så det burde ikke give
problemer, med mindre det tager så længe at loade siden, at de fyrer
før den er færdig. Så kendes diverne der skal opdateres ikke - og det
burde give js-fejl (som man godt kan forestille sig blot bliver
ignoreret...), og de vil ikke blive genstartet.
Så de skal nok i en onload igen.
Det var bare lige nemmere at teste uden - men de er i onload igen.
Den burde da fyre, også selvom der hentes fra cache...

Birger

---

Birger Sørensen skrev:

> Hmmm...
> Lidt hurtigt og ligefremt, og uden at være ude på at nedgøre eller
> fornærme nogen, vil jeg sige, at det ser ikke ud somom du har nogen som
> helst ide om hvad det er du laver.
>
> Script skal stå i header sektionen af en html side. Og der hører
> faktisk en header sektion til...
>
> Der er bøvl med tuborgerne i makeAjax() - og nej, der skal ikke være en
> timer til den - den kaldes af HentX().
>
> Jeg har rettet de øvrige svipsere - uden at jeg her vil komme ind på
> hvad og hvorfor, fordi jeg tror ikke det siger dig noget - og lagt en
> side - som ikke er korrekt html, men fungerer med AJAX og det du havde
> tænkt dig at gøre - op på mit eget domæne :
> http://ajax_test.bbsorensen.dk
> Der kan du hente den, og se om du kan blive lidt klogere
>
> Du skal være opmærksom på, at man kan ikke hente med AJAX på tværs af
> domæner - og hvis man skriver stien til filen der hentes fuldt ud, skal
> man skrive den rigtigt http://... - ikke http.//... ^^
>
> Jeg hjælper gerne som hjælp til selvhjælp.
> Det kræver at du selv er i stand til at gøre lidt - men det er du vist
> ikke rigtigt.
> Jeg laver det også gerne for dig - hvis vi kan blive enige om en
> fornuftig timepris.

Du må undskyld min idioti i denne sammenhæng, var en ren svipser... var virkelig
ikke min hensigt, at få dig til at føle, at din hjælp blev udnyttet på baggrund
af min ringe viden om JavaScript og Ajax.
Er usigelig taknemmelig for enhver håndsrækning jeg måtte få, og din har på
ingen måde været en undtagelse. Så et stort tak for din hjælp udi til sidst at
udfærdige et komplet og fuldt ud fungerende script... samt ikke mindst din kæmpe
tålmodighed med mig.

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Ace formulerede onsdag:
> Birger Sørensen skrev:
>
>> Hmmm...
>> Lidt hurtigt og ligefremt, og uden at være ude på at nedgøre eller
>> fornærme nogen, vil jeg sige, at det ser ikke ud somom du har nogen som
>> helst ide om hvad det er du laver.
>>
>> Script skal stå i header sektionen af en html side. Og der hører
>> faktisk en header sektion til...
>>
>> Der er bøvl med tuborgerne i makeAjax() - og nej, der skal ikke være en
>> timer til den - den kaldes af HentX().
>>
>> Jeg har rettet de øvrige svipsere - uden at jeg her vil komme ind på
>> hvad og hvorfor, fordi jeg tror ikke det siger dig noget - og lagt en
>> side - som ikke er korrekt html, men fungerer med AJAX og det du havde
>> tænkt dig at gøre - op på mit eget domæne :
>> http://ajax_test.bbsorensen.dk
>> Der kan du hente den, og se om du kan blive lidt klogere
>>
>> Du skal være opmærksom på, at man kan ikke hente med AJAX på tværs af
>> domæner - og hvis man skriver stien til filen der hentes fuldt ud, skal
>> man skrive den rigtigt http://... - ikke http.//... ^^
>>
>> Jeg hjælper gerne som hjælp til selvhjælp.
>> Det kræver at du selv er i stand til at gøre lidt - men det er du vist
>> ikke rigtigt.
>> Jeg laver det også gerne for dig - hvis vi kan blive enige om en
>> fornuftig timepris.
>
> Du må undskyld min idioti i denne sammenhæng, var en ren svipser... var
> virkelig ikke min hensigt, at få dig til at føle, at din hjælp blev udnyttet
> på baggrund af min ringe viden om JavaScript og Ajax.
> Er usigelig taknemmelig for enhver håndsrækning jeg måtte få, og din har på
> ingen måde været en undtagelse. Så et stort tak for din hjælp udi til sidst
> at udfærdige et komplet og fuldt ud fungerende script... samt ikke mindst din
> kæmpe tålmodighed med mig.

Og det var ikke min hensigt at skælde ud :D

Det illustrer på en eller anden måde, at tanken om at man bare kan
kopiere et eller andet, og bruge selv, er lidt at bygge luftkasteller.
Man kan sikkert godt "låne" - men det med at tilpasse til eget brug,
går ikke altid efter intentionerne.
Og i den sidste ende, er det både hurtigere og nemmere, selv at skrive
det man har brug for - så passer det til ens egne behov, frem for at
være noget tilpasset, der egentlig er beregnet til noget andet...
Og jo, det kræver at man har viden om det man gør. Og hvis man ikke har
det, er det måske smartere at lade være - eller at sætte sig ind i det
- eller søge hjælp hos den ekspertise, der kan det man har brug for.
Der er en grund til at man skal have kørerort for at køre bil. Eller
være læge for at reparere mennesker.

Det sagt, så kan jeg godt forsikre dig, at jeg føler mig ikke udnyttet.
Hvis jeg ikke havde haft lyst til at kaste mig over udfordringen, havde
jeg ikke gjort det B-)
Endelig kan du måske af resten af tråden se, at jeg også er blevet
klogere af det, og at andre også har haft gavn af det.
Og det er helt som *det* skal være

Birger

---

Birger Sørensen wrote:

> Det vil så sige, at man bør filtrere 304 fra, og ikke opdatere
> indholdet, skulle den komme.
> Prøve lige at lægge det i koden...
> Man burde jo egentlig også, forhindre at der er mere end een alert. Men
> det bliver ikke nu... :/

He - Birger, det er ikke for at angribe dit script, det er squ da af rent
egoistiske årsager
Jeg fedtede selv med 304 engang, men kom væk fra det, og fik det aldrig løst
i bund, så jeg så chancen for at finde en løsning.

Jeg kom i tanke om, at det kunne være, at XMLHTTPRequest rent faktisk
returnerede de cachede data i responseText, og det _gør_ den faktisk i
Konqueror.
Så her må løsningen være at sidestille en 304 med en 200, og ikke frasortere
304.

> Jeg har siden kørende her i IE7 og FF3 - og på FF 2.0.0.16 på den
> bærbare.
> Ingen af dem giver 304 fejl.

Den FF3 kan jeg ikke lige greje.
Jeg har den her proxytrace, som viser server kald og response linie for
linie (wire data).
Her kan man følge med, og se at der bliver genereret 2 kald hvert sekund -
bortset fra FF3.
Den henter hoved html'et og intet mere (fra serveren), ikke engang side1 + 2
første gang.
Da indholdet bliver vist, må det betyde at AJAX'en bliver kørt, men
udelukkende fra cachen.

Her vil jeg tilføje, at jeg har bemærket af FF er ret grim til at genbruge
cachen uden at spørge serveren.
Normalt ville man forvente som minimum et tjek op mod Last-modified, men FF
spørger slet ikke serveren.

Jeg opdagede det under test af en af mine hjemmestrikkede servere.
Når jeg kaldte den fra FF blev data vist som de skal MEN jeg havde squ nogle
gange glemt at starte serveren efter lidt programrettelser.
Først ved refresh fandt FF ud af, at serveren slet ikke eksisterede.
Og det er hele lortet, HTML, CSS, IMG samt .js

Det er sikkert lavet af performancemæssige årsager, men jeg stoler ikke
rigtig på at FF skal afgøre hvornår siden skal 'opdateres' i stedet for at
spørge serveren - det er trods alt kun dér oplysningerne ligger.

Man kan muligvis finde en eller anden tweak i FF, men man bliver nødt til at
tage udgangspunkt i standardindstillingerne.

Nok om FF, et helt andet problem med IE6.
Jeg var måske lidt træt, og forlod IE6 med siden åben.
Her til morgen stod Windows og brokkede sig over den _meget_ gerne ville
expande virtuel memory.
Det viste sig, at IE havde gnavet 275MB af hukommelsen i nattens løb.

Jeg ved ikke om det kun er IE6, men der er i hvert fald noget Garbage
Collection, der ikke virker - eller er konstrueret forkert.

> Ja - jeg bruger normalt php, så det kan jo være derfor.
> Men det her er html. Og de gør det heller ikke.

Jeg bruger ASP eller min egen, så jeg har heller ikke rigtig set det - det
var nok derfor det røg over i den der bog hvor ham altz... er forfatter :)

> Jeg syntes også, at opdatering af flere sider hvert sekund, måske er
> lidt voldsomt.
> Men det var præmisserne, så sådan blev det.

Enig, men min interesse var at få forsket lidt videre i 304'eren.

> Timere startes i selve script-tagget direkte, så det burde ikke give
> problemer, med mindre det tager så længe at loade siden, at de fyrer
> før den er færdig.

Det er ikke load tiden ( har 8/2 Mbps, så det burde række).

> Så kendes diverne der skal opdateres ikke - og det
> burde give js-fejl (som man godt kan forestille sig blot bliver
> ignoreret...), og de vil ikke blive genstartet.
> Så de skal nok i en onload igen.

Ud fra ovenstående ser det ud som om det virkere alligevel, blot fra cachen
og ikke via kommunikation med serveren. Jeg konkloderede bare (måske lidt
for hurtigt), at når der ikke var traffik, så virkede det ikke.

> Det var bare lige nemmere at teste uden

Jeg tager hatten af for du overhovedet gider ;)

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen sendte dette med sin computer:
> Birger Sørensen wrote:
>
>> Det vil så sige, at man bør filtrere 304 fra, og ikke opdatere
>> indholdet, skulle den komme.
>> Prøve lige at lægge det i koden...
>> Man burde jo egentlig også, forhindre at der er mere end een alert. Men
>> det bliver ikke nu... :/
>
> He - Birger, det er ikke for at angribe dit script, det er squ da af rent
> egoistiske årsager
> Jeg fedtede selv med 304 engang, men kom væk fra det, og fik det aldrig løst
> i bund, så jeg så chancen for at finde en løsning.
>
> Jeg kom i tanke om, at det kunne være, at XMLHTTPRequest rent faktisk
> returnerede de cachede data i responseText, og det _gør_ den faktisk i
> Konqueror.
> Så her må løsningen være at sidestille en 304 med en 200, og ikke frasortere
> 304.
>
>> Jeg har siden kørende her i IE7 og FF3 - og på FF 2.0.0.16 på den
>> bærbare.
>> Ingen af dem giver 304 fejl.
>
> Den FF3 kan jeg ikke lige greje.
> Jeg har den her proxytrace, som viser server kald og response linie for
> linie (wire data).
> Her kan man følge med, og se at der bliver genereret 2 kald hvert sekund -
> bortset fra FF3.
> Den henter hoved html'et og intet mere (fra serveren), ikke engang side1 + 2
> første gang.
> Da indholdet bliver vist, må det betyde at AJAX'en bliver kørt, men
> udelukkende fra cachen.
>
> Her vil jeg tilføje, at jeg har bemærket af FF er ret grim til at genbruge
> cachen uden at spørge serveren.
> Normalt ville man forvente som minimum et tjek op mod Last-modified, men FF
> spørger slet ikke serveren.
>
> Jeg opdagede det under test af en af mine hjemmestrikkede servere.
> Når jeg kaldte den fra FF blev data vist som de skal MEN jeg havde squ nogle
> gange glemt at starte serveren efter lidt programrettelser.
> Først ved refresh fandt FF ud af, at serveren slet ikke eksisterede.
> Og det er hele lortet, HTML, CSS, IMG samt .js
>
> Det er sikkert lavet af performancemæssige årsager, men jeg stoler ikke
> rigtig på at FF skal afgøre hvornår siden skal 'opdateres' i stedet for at
> spørge serveren - det er trods alt kun dér oplysningerne ligger.
>
> Man kan muligvis finde en eller anden tweak i FF, men man bliver nødt til at
> tage udgangspunkt i standardindstillingerne.
>
> Nok om FF, et helt andet problem med IE6.
> Jeg var måske lidt træt, og forlod IE6 med siden åben.
> Her til morgen stod Windows og brokkede sig over den _meget_ gerne ville
> expande virtuel memory.
> Det viste sig, at IE havde gnavet 275MB af hukommelsen i nattens løb.
>
> Jeg ved ikke om det kun er IE6, men der er i hvert fald noget Garbage
> Collection, der ikke virker - eller er konstrueret forkert.
>
>> Ja - jeg bruger normalt php, så det kan jo være derfor.
>> Men det her er html. Og de gør det heller ikke.
>
> Jeg bruger ASP eller min egen, så jeg har heller ikke rigtig set det - det
> var nok derfor det røg over i den der bog hvor ham altz... er forfatter :)
>
>> Jeg syntes også, at opdatering af flere sider hvert sekund, måske er
>> lidt voldsomt.
>> Men det var præmisserne, så sådan blev det.
>
> Enig, men min interesse var at få forsket lidt videre i 304'eren.
>
>> Timere startes i selve script-tagget direkte, så det burde ikke give
>> problemer, med mindre det tager så længe at loade siden, at de fyrer
>> før den er færdig.
>
> Det er ikke load tiden ( har 8/2 Mbps, så det burde række).
>
>> Så kendes diverne der skal opdateres ikke - og det
>> burde give js-fejl (som man godt kan forestille sig blot bliver
>> ignoreret...), og de vil ikke blive genstartet.
>> Så de skal nok i en onload igen.
>
> Ud fra ovenstående ser det ud som om det virkere alligevel, blot fra cachen
> og ikke via kommunikation med serveren. Jeg konkloderede bare (måske lidt
> for hurtigt), at når der ikke var traffik, så virkede det ikke.
>
>> Det var bare lige nemmere at teste uden
>
> Jeg tager hatten af for du overhovedet gider ;)


Jeg har så lige leget lidt.
Sat opdatering ned til 5 sekunder, og tilføjet en div mere til
opdatering. (Og lagt side og divId i arrays...)
Den nye div får så random indhold, så man kan se at der faktisk sker
noget. Og den er php - man kan jo ikke lave dynamik i HTML.
div2 er desuden også ændret til PHP fra HTML.

Ingen af dem (IE7, FF3, FF2.0.0.26) giver status 304 (har fjernet trap
fra programmeringen, så den vil vises igen).
Men FF 2.0.0.16, opdaterer ikke HTML. Selv om siden faktisk ændres på
serveren, viser FF2.0.0.16 stadig den som den henter første gang. Ikke
engang ved opdatering af siden (hverken klik på knappen eller ctrl R),
checkes mod serveren. Faktisk hjælper det heller ikke at lukke tab'en
og åbne den igen. Ikke engang at lukke browseren helt og genåbne, får
den til at checke om siden faktisk er ændret på serveren.
Firebug (som er den egentlige årsag til FF2.0.0.16 findes her endnu -
den virker ikke i FF3) viser kommunikationen, og det lader til at den
er OK - bortset fra at den altså for HTML kommunikerer med sin egen
cache, i stedet for serveren - den tekst der returneres er den samme
som den der allerede står på skærmen - og uheldigvis *ikke* den der
står i filen på serveren!
Der er ingen status i response headeren (Firebug). Der er en date - som
er lige nu - og en Last-Modified, som er helt i skoven (ligner den
dato/tid filen sidst blev hentet fra serveren - det er *ikke* den
dato/tid filen på serveren er blevet ændret)!
FF3 gør nøjagtigt det samme - læser HTML fra cacheen, uden check på
serveren. (Har ikke værktøj til check af kommunikationen).
IE7, gør som den skal her. Har dog ingen værktøjer til check - kan blot
konstatere at display ændres som det burde, ved ændring i HTML filen på
serveren.

Opdatering af indhold fra PHP virker som det skal i alle 3 browsere.

Karaktersæt.
HTML'en er ISO-8859-1 ( burde måske være -15 så man kan bruge ¤ Euro,
men er det sltså ikke).
AJAX kommunikerer utf8.
HTML skrevet i ISO-8859-1 har altså et problem med danske karakterer
(div1).
I PHP konverteres resultater til utf8 [utf8_encode()], og dukker op
rigtigt på siden - AJAX konverterer altså tilsyneladende selv fra utf8
til HTML karaktersættet efter modtagelsen.

Birger

---

Birger Sørensen wrote:

> FF3 gør nøjagtigt det samme - læser HTML fra cachen, uden check på
> serveren. (Har ikke værktøj til check af kommunikationen).

Det er lidt noget p*s at den gør sådan - i virkeligheden kan man ikke rigtig
stole på, at det man sér, er dét man ser.

MHT værktøj, så ligger proxytrace her:
<http://www.pocketsoap.com/tcptrace/pt.aspx>

Det er en lille .exe fil man starter op, og default port er 8080.
Ved at konfigurere browser(ne) til at kommunikere via denne proxy kan man
følge med i 'wire data'.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen har bragt dette til verden:
> Birger Sørensen wrote:
>
>> FF3 gør nøjagtigt det samme - læser HTML fra cachen, uden check på
>> serveren. (Har ikke værktøj til check af kommunikationen).
>
> Det er lidt noget p*s at den gør sådan - i virkeligheden kan man ikke rigtig
> stole på, at det man sér, er dét man ser.
>
> MHT værktøj, så ligger proxytrace her:
> <http://www.pocketsoap.com/tcptrace/pt.aspx>
>
> Det er en lille .exe fil man starter op, og default port er 8080.
> Ved at konfigurere browser(ne) til at kommunikere via denne proxy kan man
> følge med i 'wire data'.

TY

Birger

---

> > Den FF3 kan jeg ikke lige greje.
> > Jeg har den her proxytrace, som viser server kald og response linie for
> > linie (wire data).
> > Her kan man følge med, og se at der bliver genereret 2 kald hvert sekund -
> > bortset fra FF3.
> > Den henter hoved html'et og intet mere (fra serveren), ikke engang side1 + 2
> > første gang.
> > Da indholdet bliver vist, må det betyde at AJAX'en bliver kørt, men
> > udelukkende fra cachen.

Da jeg i sin tid brugte et lignende Ajax script satte jeg en parmeter på filen
således at mit script hentede fil.htm?id=datoen

Altså "fil.htm?id=" +date()

På den måde var det en ny fil hver gang jeg skulle hente den.

Jeg ved godt at det er lidt overdrevet da den jo bare giver 304 i de tilfælde
hvor der ingen ændringer er, men en måde at løse det på.

Christian

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Christian Kragh wrote:

> Altså "fil.htm?id=" +date()
>
> På den måde var det en ny fil hver gang jeg skulle hente den.

Der er den ulempe (for brugeren) jfr. tidligere indlæg:
> Jeg ved ikke lige hvordan man løser det her problem (statiske filer),
> bortset fra at tilføje noget random data til url'en.
> Det har den ulempe, at brugerens cache bliver fyldt med de her kald.

--
Med venlig hilsen
Stig Johansen

---

Birger Sørensen wrote:

> Ingen af dem (IE7, FF3, FF2.0.0.26) giver status 304 (har fjernet trap
> fra programmeringen, så den vil vises igen).

Min Konqueror tjekker stadig på indholdet, og giver en 304.
Jeg har gemt dit html lokalt og ændret til:
if ( xmlHttp.status == 200 || xmlHttp.status == 304 ) {
og så virker det som det skal.

> HTML skrevet i ISO-8859-1 har altså et problem med danske karakterer
> (div1).

Så vidt jeg kan se er HTML'et udelukkende ASCII tegn, og ikke nogle danske
tegn.
Div1 står rigtigt her, men..

> I PHP konverteres resultater til utf8 [utf8_encode()], og dukker op
> rigtigt på siden - AJAX konverterer altså tilsyneladende selv fra utf8
> til HTML karaktersættet efter modtagelsen.

Ikke her, nok er min Konqueror lidt irriterende - standardoverholdende -,
men til gængæld ser men 'meget'.
Din server leverer alting med "Content-Type: text/html" hvilket pr.
definition er iso-8859-1 (-15 tager vi når/hvis vi går over til ?).
Da det jfr. rfc'en er styrende vises det resterende indhold som eks.
Tilfældigt indhold :
og
Indhold div2
Ã? Ã~ Ã? æ ø Ã¥

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen kom med denne ide:
> Birger Sørensen wrote:
>
>> Ingen af dem (IE7, FF3, FF2.0.0.26) giver status 304 (har fjernet trap
>> fra programmeringen, så den vil vises igen).
>
> Min Konqueror tjekker stadig på indholdet, og giver en 304.
> Jeg har gemt dit html lokalt og ændret til:
> if ( xmlHttp.status == 200 || xmlHttp.status == 304 ) {
> og så virker det som det skal.
>
>> HTML skrevet i ISO-8859-1 har altså et problem med danske karakterer
>> (div1).
>
> Så vidt jeg kan se er HTML'et udelukkende ASCII tegn, og ikke nogle danske
> tegn.
> Div1 står rigtigt her, men..
>
>> I PHP konverteres resultater til utf8 [utf8_encode()], og dukker op
>> rigtigt på siden - AJAX konverterer altså tilsyneladende selv fra utf8
>> til HTML karaktersættet efter modtagelsen.
>
> Ikke her, nok er min Konqueror lidt irriterende - standardoverholdende -,
> men til gængæld ser men 'meget'.
> Din server leverer alting med "Content-Type: text/html" hvilket pr.
> definition er iso-8859-1 (-15 tager vi når/hvis vi går over til ?).
> Da det jfr. rfc'en er styrende vises det resterende indhold som eks.
> Tilfældigt indhold :
> og
> Indhold div2
> Ã? Ã~ Ã? æ ø Ã¥

Kan man bruge decodeURI() til at konvertere fra utf8 så?

Har haft den der - men jeg kan ikke se forskel her.
Det må vel egentlig skyldes forskelle i AJAX objectet?

Birger

---

Birger Sørensen wrote:
> Kan man bruge decodeURI() til at konvertere fra utf8 så?

I første omgang kan du sætte din server op til at levere det, du leverer.
dvs:
Content-Type: text/html ; charset=UTF-8

Det er vist noget med en header(et.eller.andet) i php.

> Har haft den der - men jeg kan ikke se forskel her.
> Det må vel egentlig skyldes forskelle i AJAX objectet?

Det er nok nærmere forskellen mellem tilgivende og ikke tilgivende browsere
(og tilhørende AJAX objekt).
Måske er jeg lidt skør, men standarden er helt klar på det område - alt
andet end iso-8859-1 skal angives med det karaktersæt man leverer.

Lidt ævl fra RFC'en:
<quote>
Some HTTP/1.0 software has interpreted a Content-Type header without
charset parameter incorrectly to mean "recipient should guess."
Senders wishing to defeat this behavior MAY include a charset
parameter even when the charset is ISO-8859-1 and SHOULD do so when
it is known that it will not confuse the recipient.

Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender; and those user agents that have
a provision to "guess" a charset MUST use the charset from the
content-type field if they support that charset, rather than the
recipient's preference, when initially displaying a document.
</quote>

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev den 27-08-2008:
> Birger Sørensen wrote:
>> Kan man bruge decodeURI() til at konvertere fra utf8 så?
>
> I første omgang kan du sætte din server op til at levere det, du leverer.
> dvs:
> Content-Type: text/html ; charset=UTF-8
>
> Det er vist noget med en header(et.eller.andet) i php.
>
>> Har haft den der - men jeg kan ikke se forskel her.
>> Det må vel egentlig skyldes forskelle i AJAX objectet?
>
> Det er nok nærmere forskellen mellem tilgivende og ikke tilgivende browsere
> (og tilhørende AJAX objekt).
> Måske er jeg lidt skør, men standarden er helt klar på det område - alt
> andet end iso-8859-1 skal angives med det karaktersæt man leverer.
>
> Lidt ævl fra RFC'en:
> <quote>
> Some HTTP/1.0 software has interpreted a Content-Type header without
> charset parameter incorrectly to mean "recipient should guess."
> Senders wishing to defeat this behavior MAY include a charset
> parameter even when the charset is ISO-8859-1 and SHOULD do so when
> it is known that it will not confuse the recipient.
>
> Unfortunately, some older HTTP/1.0 clients did not deal properly with
> an explicit charset parameter. HTTP/1.1 recipients MUST respect the
> charset label provided by the sender; and those user agents that have
> a provision to "guess" a charset MUST use the charset from the
> content-type field if they support that charset, rather than the
> recipient's preference, when initially displaying a document.
> </quote>

Der er mange ting i det her... Jeg har læst og eksperimenteret lidt.

Hvis man ser på http://www.w3.org/TR/XMLHttpRequest/ - som stadig kun
er et draft, men et eller andet er man jo nødt til at rette sig efter -
kan man ændre headere for AJAX-kommunikationen. Og hvis man læser igen,
ser man at en hel stribe headere ikke kan ændres af sikkerhedsgrunde.
Det er altså ikke muligt gennem AJAX at fortælle serveren at man vil
have svaret i en bestemt encoding.
Ligeledes kan man - det gjorde jeg i hvert fald - nå frem til, at hvis
der ikke er et charset i Content-Type (som man altså ikke kan få
anderledes end default), vil AJAX levere responseText i utf-8.

Og problemet er så, at teksten står i ISO.. på serveren, og ikke bliver
konverteret - skal man have danske karakterer der, skal man altså bruge
entities, selvom man skriver i ISO.. for at det bliver leveret rigtigt
gennem AJAX.

Selve HTML siden, hvor teksten indsættes har charset ISO.. (<meta..>)
og står også sådan på serveren.
Danske karakterer OK.
Jeg har prøvet at gemme filerne i utf-8 på serveren.
Først med den der hentes ( side1.html vises i div1). Så vises danske
karakterer rigtigt også uden entities.
Også selvom der stadig står ISO i <meta> i index.html
Har så gemt index.html som utf-8, og tingene virker stadig.
Ændret <meta> til utf-8 - og det gør ikke en dyt forskel.

Så herfra hvor jeg sidder, ser det ud somom, at det er trekvart
ligegyldigt om man bruger ISO eller utf-8, undtagen for AJAX - der skal
kodefiler være i utf-8, for at komme rigtigt ud på den endelige side -
og det igen uanset om man bruger IOS eller utf-8 i index.

Er der noget hold i det?

(Har så ikke prøvet at involvere databaser og dens 3 karaktersæt
indstillinger - for der er da rigeligt her, til at blive rundtosset
af...)

Birger

---

"Birger Sørensen" <sdc@bbsorensen.com> wrote in message
news:48b6838b$0$90272$14726298@news.sunsite.dk...
> Der er mange ting i det her... Jeg har læst og eksperimenteret lidt.

Ja det er lidt noget rod, tegnsæt altså, ikke din side.

> Det er altså ikke muligt gennem AJAX at fortælle serveren at man vil
> have svaret i en bestemt encoding.

Nej, men det jeg mente var, at sætte serveren til at levere det man leverer.
Dvs. sammenhæng mellem Content-Type og indhold.

> Ligeledes kan man - det gjorde jeg i hvert fald - nå frem til, at hvis
> der ikke er et charset i Content-Type (som man altså ikke kan få
> anderledes end default), vil AJAX levere responseText i utf-8.

Det er lidt noget rod - igen -, for når man snakker XML, så er default
utf-8, og ikke iso-8859-1.
Vi står over for den problemstilling, at html'et er default iso-8859-1
hvorimod det html der hentes via _XML_httprequest er default utf-8.
En køn sammenblanding...

> Og problemet er så, at teksten står i ISO.. på serveren, og ikke bliver
> konverteret - skal man have danske karakterer der, skal man altså bruge
> entities, selvom man skriver i ISO.. for at det bliver leveret rigtigt
> gennem AJAX.

En måde at gøre det på (hvis man holder sig til iso-8859-1, som jeg
foretrækker) er at levere indholdet som xml.
Her har man muligheden for at angive encoding i prologen, jeg bruger f. eks.
<?xml version="1.0" encoding="iso88591"?>
samment med (i ASP):
Response.ContentType="text/xml"
Response.Charset = "ISO-8859-1"

Det giver den ønskede header samt funktionalitet.
Alle 'danske tegn' bliver vist korrekt, og det hele er iso-8859-1.

Når ting skal sendes fra f.eks et textarea har vi den omvendte
problemstilling.
Her har jeg lavet en lille Q&D JS funktion der konverterer fra utf-8 til
ansi før data sendes til serveren.
Serveren vil derfor modtage ansi (iso-8859-1) - ingen utf-8 involveret.

Så alle 'danske' tegn står korrekt, eller som du selv (næsten) skriver:
Keine hexerei, nur lurendreierei.

Disse ting virker her på IE6/Win2K,FF3/Win2k samt Konqueror/Linux.

> Selve HTML siden, hvor teksten indsættes har charset ISO.. (<meta..>)
> og står også sådan på serveren.
> Danske karakterer OK.
> Jeg har prøvet at gemme filerne i utf-8 på serveren.
> Først med den der hentes ( side1.html vises i div1). Så vises danske
> karakterer rigtigt også uden entities.
> Også selvom der stadig står ISO i <meta> i index.html
> Har så gemt index.html som utf-8, og tingene virker stadig.
> Ændret <meta> til utf-8 - og det gør ikke en dyt forskel.
>
> Så herfra hvor jeg sidder, ser det ud somom, at det er trekvart
> ligegyldigt om man bruger ISO eller utf-8, undtagen for AJAX - der skal
> kodefiler være i utf-8, for at komme rigtigt ud på den endelige side -
> og det igen uanset om man bruger IOS eller utf-8 i index.
>
> Er der noget hold i det?

Den side du har lavet bliver vist korrekt(?) i FF3 + IE6, men ikke i min
Konqueror.
Korrekt med (?) fordi - hvis man tager hensyn til (utf-8) meta tagget -, så
er de første ÆØÅæøå _ikke_ korrekte utf-8 tegn, men de bliver alligevel vist
korrekt, eller rettere som man ønsker at se det.

Konqueror derimod forholder sig til (RFC) standarden og anerkender, at
indholdet er leveret som iso-8859-1 og viser det som angivet.

Det betyder at alle multibyte karakterer bliver vist som eks.
Ã? Ã~ Ã? Ã| Ã? Ã¥, som er korrekt visning af indholdet i forhold til
iso-8859-1, men ikke det ønskede.

--
Med venlig hilsen/Best regards
Stig Johansen

---

Stig Johansen skrev:
> "Birger Sørensen" <sdc@bbsorensen.com> wrote in message
> news:48b6838b$0$90272$14726298@news.sunsite.dk...
>> Der er mange ting i det her... Jeg har læst og eksperimenteret lidt.
>
> Ja det er lidt noget rod, tegnsæt altså, ikke din side.
>
>> Det er altså ikke muligt gennem AJAX at fortælle serveren at man vil
>> have svaret i en bestemt encoding.
>
> Nej, men det jeg mente var, at sætte serveren til at levere det man leverer.
> Dvs. sammenhæng mellem Content-Type og indhold.
>
>> Ligeledes kan man - det gjorde jeg i hvert fald - nå frem til, at hvis
>> der ikke er et charset i Content-Type (som man altså ikke kan få
>> anderledes end default), vil AJAX levere responseText i utf-8.
>
> Det er lidt noget rod - igen -, for når man snakker XML, så er default
> utf-8, og ikke iso-8859-1.
> Vi står over for den problemstilling, at html'et er default iso-8859-1
> hvorimod det html der hentes via _XML_httprequest er default utf-8.
> En køn sammenblanding...
>
>> Og problemet er så, at teksten står i ISO.. på serveren, og ikke bliver
>> konverteret - skal man have danske karakterer der, skal man altså bruge
>> entities, selvom man skriver i ISO.. for at det bliver leveret rigtigt
>> gennem AJAX.
>
> En måde at gøre det på (hvis man holder sig til iso-8859-1, som jeg
> foretrækker) er at levere indholdet som xml.
> Her har man muligheden for at angive encoding i prologen, jeg bruger f. eks.
> <?xml version="1.0" encoding="iso88591"?>
> samment med (i ASP):
> Response.ContentType="text/xml"
> Response.Charset = "ISO-8859-1"
>
> Det giver den ønskede header samt funktionalitet.
> Alle 'danske tegn' bliver vist korrekt, og det hele er iso-8859-1.
>
> Når ting skal sendes fra f.eks et textarea har vi den omvendte
> problemstilling.
> Her har jeg lavet en lille Q&D JS funktion der konverterer fra utf-8 til
> ansi før data sendes til serveren.
> Serveren vil derfor modtage ansi (iso-8859-1) - ingen utf-8 involveret.
>
> Så alle 'danske' tegn står korrekt, eller som du selv (næsten) skriver:
> Keine hexerei, nur lurendreierei.
>
> Disse ting virker her på IE6/Win2K,FF3/Win2k samt Konqueror/Linux.
>
>> Selve HTML siden, hvor teksten indsættes har charset ISO.. (<meta..>)
>> og står også sådan på serveren.
>> Danske karakterer OK.
>> Jeg har prøvet at gemme filerne i utf-8 på serveren.
>> Først med den der hentes ( side1.html vises i div1). Så vises danske
>> karakterer rigtigt også uden entities.
>> Også selvom der stadig står ISO i <meta> i index.html
>> Har så gemt index.html som utf-8, og tingene virker stadig.
>> Ændret <meta> til utf-8 - og det gør ikke en dyt forskel.
>>
>> Så herfra hvor jeg sidder, ser det ud somom, at det er trekvart
>> ligegyldigt om man bruger ISO eller utf-8, undtagen for AJAX - der skal
>> kodefiler være i utf-8, for at komme rigtigt ud på den endelige side -
>> og det igen uanset om man bruger IOS eller utf-8 i index.
>>
>> Er der noget hold i det?
>
> Den side du har lavet bliver vist korrekt(?) i FF3 + IE6, men ikke i min
> Konqueror.
> Korrekt med (?) fordi - hvis man tager hensyn til (utf-8) meta tagget -, så
> er de første ÆØÅæøå _ikke_ korrekte utf-8 tegn, men de bliver alligevel vist
> korrekt, eller rettere som man ønsker at se det.
>
> Konqueror derimod forholder sig til (RFC) standarden og anerkender, at
> indholdet er leveret som iso-8859-1 og viser det som angivet.
>
> Det betyder at alle multibyte karakterer bliver vist som eks.
> Ã? Ã~ Ã? Ã| Ã? Ã¥, som er korrekt visning af indholdet i forhold til
> iso-8859-1, men ikke det ønskede.

Så det du siger er, at jeg skal holde mig til ISO'en i html, med
undtagelse af de sider, der ønskes overført med AJAX - de skal gemmes
på serveren i utf-8.
Det er også det der tiltaler mig mest - med det er sådan set noget rod,
at skulle gemme filer i forskellige karaktersæt, for at få tingene til
at virke....

Jeg mangler en js konvertering fra utf-8 til ISO. Den skal kun bruges
ved overførsel af html (eller txt) filer via AJAX. Ellers skal jeg til
at lære at behandle HTML og alm. tekst som XML....

Den anden vej - fra browsr til server - har jeg altid PHP som modtager.
PHP har funktioner til at konvertere til ISO, og jeg gemmer også data
som ISO, så der har jeg ingen problemer.

---

Birger Sørensen wrote:

> Så det du siger er, at jeg skal holde mig til ISO'en i html,

Nej, Birger jeg siger intet om hvad du skal, men blot hvad jeg foretrækker.
En af årsagerne jeg, og sikkert mange andre, ikke gider utf-8 på andet end
wiredata er det variable antal bytes.
Jeg tænker her på Delphi, som du vist kender.

Normalt kan man sige at
'søen' består af 4 bytes, og kan opfattes som array[1..4] of char eller
string med længden 4.
pga man har brugt den første bit til at flække på, så vil alle tegn fra
128..255 bruge 2 bytes (op til 6-8 bytes) for andre 'eksotiske' tegn.
Dvs. nu bstår 'søen' af 5 bytes, men kun 4 'karakerer'.
Jeg vil hellere have alt som Ansi/iso-8859-1, så jeg ikke skal lave
konverteringer frem og tilbage alle mulige steder - bortset fra wiredata
til omverdenen.

> med
> undtagelse af de sider, der ønskes overført med AJAX - de skal gemmes
> på serveren i utf-8.

Jeg må indrømme, at jeg ikke lige har testet statiske sider/filer via AJAX,
kun dynamiske (ASP/Delphi ISAPI).

Men det har jeg tænkt mig at gøre, nu emnet er oppe.
For en god ordens skyld, så har jeg naturligvis tænkt mig at hugge en kopi
af din test til test

Det er noget jeg selv gerne vil have på plads, så jeg vender tilbage med
resultatet.

> Det er også det der tiltaler mig mest - med det er sådan set noget rod,
> at skulle gemme filer i forskellige karaktersæt, for at få tingene til
> at virke....

Præcis, og det er derfor jeg holder mig til iso-8859-1 alle steder, så er
der ingen forvirring.

Man kan selvfølgelig også vælge alt i utf-8, men så afleder det en masse
bøvl med databaser og Delphi (og andre Native værktøjer).

> Jeg mangler en js konvertering fra utf-8 til ISO. Den skal kun bruges
> ved overførsel af html (eller txt) filer via AJAX. Ellers skal jeg til
> at lære at behandle HTML og alm. tekst som XML....

Jeg har en, men jeg skal lige teste om det er nødvendigt, så vender jeg
tilbage.

> Den anden vej - fra browsr til server - har jeg altid PHP som modtager.
> PHP har funktioner til at konvertere til ISO, og jeg gemmer også data
> som ISO, så der har jeg ingen problemer.

Jeg har også lave ASP funktioner til konvertering frem og tilbage.
Men jeg er sådan en servermand fra start 80'erne, hvor det var en kunst, og
behov, at optimere servere(svartider), så det ligger lidt i blodet

Derfor fandt jeg den løsning med XML'et, så man helt undgår konvertering fra
server til browser.

På samme måde lavede jeg en JS konvertering fra utf-8 til Ansi, så serveren
undgår konvertering af karaktersæt, altså flytte 'byrden' til klienten.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Jeg må indrømme, at jeg ikke lige har testet statiske sider/filer via
> AJAX, kun dynamiske (ASP/Delphi ISAPI).
>
> Men det har jeg tænkt mig at gøre, nu emnet er oppe.
> For en god ordens skyld, så har jeg naturligvis tænkt mig at hugge en kopi
> af din test til test
>
> Det er noget jeg selv gerne vil have på plads, så jeg vender tilbage med
> resultatet.


Nå, grimme billeder dukker op
Nu kan jeg godt huske det.
En html fil med iso-8859-1 vises korrekt via Ajax i min Konqueror.
Men både FF og IE konverterer til 'unicode', dor får alle specialtegn den
samme værdi, så de originale data er allerede smadret i .responseText.
Jeg har taget en kopi af din side og lagt den her:
<http://w-o-p-r.dk/tips/birger/bbtest.html>
Som den ser ud nu, så har jeg lagt en side1.xml ud på serveren (UnoEuro) og
anført iso-8859-1 i xml prologen.
Det er dog ikke wellformed xml, men det kan man tage op senere.
Denne metode virker i FF, men _ikke_ i IE6.
Jeg har ikke IE7, men mon ikke selv William er kommet med på vognen?
Hvad viser <div1> i IE7 ?, evt Opera m.m.

--
Med venlig hilsen
Stig Johansen

---

Den 29-08-2008, skrev Stig Johansen:
> Stig Johansen wrote:
>
>> Jeg må indrømme, at jeg ikke lige har testet statiske sider/filer via
>> AJAX, kun dynamiske (ASP/Delphi ISAPI).
>>
>> Men det har jeg tænkt mig at gøre, nu emnet er oppe.
>> For en god ordens skyld, så har jeg naturligvis tænkt mig at hugge en kopi
>> af din test til test
>>
>> Det er noget jeg selv gerne vil have på plads, så jeg vender tilbage med
>> resultatet.
>
>
> Nå, grimme billeder dukker op
> Nu kan jeg godt huske det.
> En html fil med iso-8859-1 vises korrekt via Ajax i min Konqueror.
> Men både FF og IE konverterer til 'unicode', dor får alle specialtegn den
> samme værdi, så de originale data er allerede smadret i .responseText.
> Jeg har taget en kopi af din side og lagt den her:
> <http://w-o-p-r.dk/tips/birger/bbtest.html>
> Som den ser ud nu, så har jeg lagt en side1.xml ud på serveren (UnoEuro) og
> anført iso-8859-1 i xml prologen.
> Det er dog ikke wellformed xml, men det kan man tage op senere.
> Denne metode virker i FF, men _ikke_ i IE6.
> Jeg har ikke IE7, men mon ikke selv William er kommet med på vognen?
> Hvad viser <div1> i IE7 ?, evt Opera m.m.

http://bbsorensen.dk/ajax_test/aj_stig.jpg
Uden at gå i detaljer, så er der noget forkert, hvis du har kopieret
hele min side.
Det er ikke det hele der vises - og det er forskelligt i browserne.
Jeg får også fejl 500 - man kan ikke (må ikke kunne) hente på tværs af
domæner med AJAX.
Fandt i øvrigt ud af i går, at FF(både2.0.0.16 og 3) blokerer (svjh.
intern js fejl - ikke adgang til object data), hvis man forsøger at
sætte de "forbudte" headere i XMLHTTPrequest objectet.
IE7 lader dem passere, men sender ikke de modificerede headere.

Ifølge
http://www.w3.org/TR/XMLHttpRequest/#text-response-entity-body
(pkt 5+7) vil responseText altid komme ud som utf-8, med mindre
headeren's content type indeholder en character definition.
Det kan man selvfølgelig fikse, fra asp eller php.
Men det går ikke med "statiske" - en txt eller HTML, der skal hentes
til noget eksisterende.

Og det er noget fis.
En fil eller tekst kan godt bruges flere steder. Men den skal være i
forskelligt format f.eks. til include og ajax.
Har løst det på bbsorensen.dk - som jo henter alting med ajax - ved at
have en php, der konverterer en fil til utf-8, og tager filnavn som
parameter. Det kan jeg kalde via ajax. Og så kan jeg bruge samme fil
til begge dele.
Undtagen i din Konqueror/Linux, åbenbart...

Birger

---

Birger Sørensen wrote:

> http://bbsorensen.dk/ajax_test/aj_stig.jpg
> Uden at gå i detaljer, så er der noget forkert, hvis du har kopieret
> hele min side.

Kopiere hele siden er nok så meget sagt, kun html'et + side1.html/xml.

> Det er ikke det hele der vises - og det er forskelligt i browserne.

Egentlig underligt, men fokus var udelukkende på den statiske fil (side1).
Den viser dog, at Opera tager hensyn til encoding i xml prologen, hvor IE
stadig ikke gør det.
Derfor står ÆØÅ rigtigt i Opera under Div1 mens IE ikke står rigtigt.

> Jeg får også fejl 500 - man kan ikke (må ikke kunne) hente på tværs af
> domæner med AJAX.

Nej det ved jeg godt. Det er derfor jeg (forsøger at) henter de andre 2
div's via serverside XMLHTTPRequest.
Url'en fra sourcen, eksempelvis:
'bbtest.asp?URL=http://ajax_test.bbsorensen.dk/side2.php'
kalder bbtest.asp på samme doæne, som så henter side2.php fra dit.
Det er bare et par utestede linier, så det er ikke umuligt den giver en 500.
Det burde dog ikke være browserspecifikt, da det sker serverside.

> Fandt i øvrigt ud af i går, at FF(både2.0.0.16 og 3) blokerer (svjh.
> intern js fejl - ikke adgang til object data), hvis man forsøger at
> sætte de "forbudte" headere i XMLHTTPrequest objectet.
> IE7 lader dem passere, men sender ikke de modificerede headere.

Jeg er ikke sikker på jeg kan følge dig her. Jeg snakker udelukkende om de
headere der kommer fra serveren, og ikke fra klienten - ?.

> Ifølge
> http://www.w3.org/TR/XMLHttpRequest/#text-response-entity-body
> (pkt 5+7) vil responseText altid komme ud som utf-8, med mindre
> headeren's content type indeholder en character definition.

Næsten, og det er præcis det jeg prøver at skrive hele tiden.
Næste som: Hvis du også ser pkt 3+4, så skelnes der mellem text/xml og
text/html.
Nu henvises der godt nok til HTML5, men det har 'altid' været sådan, at hvis
men kun sender MIME typen uden charset, så betyder det:
text/html ==> ISO-8859-1
text/xml ==> UTF-8
Det betyder at en AJAX request mod en statisk fil der returnerer text/html
burde respektere default tegnsæt.
Det gør min Konqueror, men det gør de andre ikke, dérfor forskellen.

Nu findes der et væld af andre metoder til at udveksle XML ud over HTTP, og
demed uden MIME type.

Derfor kan man specificere en alternativ encoding i prologen (default =
UTF-8).
Det respekterer Firefox, og Opera(jfr. dit dump) mens IE, undskyld
udtrykket, rent ud sagt skider på det.
Netop denne 'feature' har givet anledning til mange
diskussioner/frustrationer omkring årtusindeskiftet, hvor vi rigtig
begyndte med XML/SOAP/Webservices.

Alle andre end MS kunne håndtere encodings, så min påstand er, at MS er med
til at hæmme udviklingen.

> Det kan man selvfølgelig fikse, fra asp eller php.
> Men det går ikke med "statiske" - en txt eller HTML, der skal hentes
> til noget eksisterende.

Den her lille 'grundforskning' gik ud på hvad man har af muligheder på et
standard webhotel.
Hvis man har kontrol over sin egen server kan man bare lave nogle ekstra
mapninger, eksempelvis:
..xmli ==> text/xml; charset=ISO-8859-1
..htmlu ==> text/html; charset=utf-8
osv.
Så kan man bruge statiske filer og undgå serverloadden med at parse via
ASP/PHP.

> Og det er noget fis.

Gu er det så, og jeg tror det er fordi xml og html har haft parallelle
udviklingsforløb, og nu skal man 'merge' de to ting.

> En fil eller tekst kan godt bruges flere steder. Men den skal være i
> forskelligt format f.eks. til include og ajax.

Ikke hvis du selv kan kontrollere dine MIME types på din server.

> Har løst det på bbsorensen.dk - som jo henter alting med ajax - ved at
> have en php, der konverterer en fil til utf-8, og tager filnavn som
> parameter. Det kan jeg kalde via ajax. Og så kan jeg bruge samme fil
> til begge dele.
Det er også den metode jeg ville anbefale hvis man ikke kan kontrollere
serveren.
MEN
> Undtagen i din Konqueror/Linux, åbenbart...

Det er i virkeligheden min Konqueror der håndterer det korrekt.
Du sender det som text/html, hvilket er ISO-8859-1, men indholdet er utf-8.
I din php kan du sætte headeren op med (klip fra en anden post):
    header('Content-Type: text/html; charset=UTF-8');

Så burde det virke i alle browsere, da der vil være konsistens mellem MIME
type og faktisk indhold.

--
Med venlig hilsen
Stig Johansen