AJAX script evt. med DOM istedet for innerHTML ?

Jeg kan desværre ikke give dig et eksempel "MED KODE". :)

Men jeg ved, at mange oplever netop dét problem med IE's caching. Det kan løses ved at indsætte en randomværdi i en querystring på den url, du henter via AJAX. F.eks. hvis du henter siden getinfo.php så kan du i stedet hente den med adressen getinfo.php?rnd=[indsæt tilfældigt tal her]

Så narres IE nemlig til at cache hver gang.

DOM er rigtig godt at bruge, men det kræver, at man skriver sin kode om.

Med innerHTML kan man være doven og bare indsætte en stor klump HTML-string på siden.
Med DOM bliver man nødt til at oprette HTML-elementerne et for et og sætte deres attributter og indhold. Det er derfor ikke en løsning for dovne, men tilgengæld er det meget rigtigere.

Man bør, for at undgå caching, lave AJAX kald med POST i stedet for GET.

okay.. kan mit script laves rimelig let med post istedet for get?:)

Hey Zonic

Jeg svarede for nyligt på et spørgsmål som minder lidt om dette: http://www.eksperten.dk/spm/843550

spørgsmålet gik ud på at lave et Ajax-kald til serveren (PHP/ASP) som så opdatere et element på siden.

dét du skal lave om fra : LoadURL("GET", "?URL=" + query, null, GetUrlHandler, true);
er f.eks. til dette : LoadURL("POST", "?", "recordID=5", GetUrlHandler, true);

LoadURL(  //funktion som henter data fra en adress
"POST",  // POST|GET fortæller hvor dataene ligger Querstring eller Body
"data.php",    // URL adressen
"recordID=5",  // POST-BODY som kan være en querystring eller null
GetUrlHandler, // din modtager funktion af datene fra serveren
false          // fortæller om vi modtager XML eller HTML
);


din modtager funktion skal så skrives om til dette formål:

function GetUrlHandler(html)
{
    if(html != "0")
    {
        document.getElementById("output") = html;
    }
}

herved kan du opdatere elementet når output er forskellig fra "0" som w13 siger.

Lad være med at lytte for meget til Olebole, hans innerHTML korstog driver nogle af os til vandvid... og uden grund.

når du bruger innerHTML skal du have nogle facts i ménte som du kan læse på min Blog : http://blog.mdk-photo.com/post/innerHTML-The-design-pattern.aspx

- en artikel som forklare hvordan man bør benytte sig af innerHTML

endnu en artikel: http://blog.mdk-photo.com/post/The-most-versatile-httpRequest-function.aspx

doh... rettelse:

function GetUrlHandler(html)
{
    if(html != "0")
    {
        document.getElementById("output").innerHTML = html;
    }
}

<ole>

montago >> For at opfatte mine indevendinger mod brugen af innerHTML til seriøse applikationer som værende et veritabelt korstog, må man vist være skidt fagligt funderet - eller temmelig paranoid. Måske er det, der menes med, at visse brugere skule være blevet drevet til vanvid(?)
På den anden side har du jo før erkendt, at det ikke er substansen i min argumentation, men selve min person, der skaber problemer for dig  =)

I din blog-artikel drager du forøvrigt igen fejlagtige slutninger/påstande - formodentlig, fordi du ikke tester, hvad du laver.

Bruger jeg således det, du kalder for "Worlds fastest stringbuffer for Javascript", tager det i IE dobbelt så lang tid at konkatenere 20.000 strenge på ca. 90 tegn, som hvis jeg brugte syntaksen:

var oBuffer = [];
for (var i=0; i<20000; i++) {
    oBuffer.push("En eller anden streng, som skal konkateneres med en hel masse kloner af samme streng ...");
}
var s = oBuffer.join("");

- og fire gange så lang tid som:

var oBuffer = [];
for (var i=0; i<20000; i++) {
    oBuffer[i] = "En eller anden streng, som skal konkateneres med en hel masse kloner af samme streng ...";
}
var s = oBuffer.join("");

På den anden side er det korrekt, at disse to syntakser stinker i FF - ligesom alm. streng konkatenering stinker i FF. At kalde din metode for "Worlds fastest stringbuffer for Javascript", synes dog at være en middelsvær overdrivelse/unøjagtighed!

Hvordan man kan kalde et XMLHttpRequest script, som ikke tager højde for de seneste mange års udvikling, for "The most versatile httpRequest function", kan jo også undre. Vi andre er nu oppe i XMLHttp-version 6  =)

Desuden viser du i dit såkaldte 'Ajax' eksempel, du ikke har fattet det allerførste af, hvad Ajax handler om - nemlig asynkron kommunikation mellem klient og server. Det er ligefrem en del af navnet på teknikken: Asynchronous Javascript And XML(HttpRequest)!

- hvorfor i alverden viser du så et eksempel på en _synkron_ XMLHttpRequest, som gør det stik modsatte af meningen med Ajax (du lammer browseren, til responsen er returneret!) ...?!???!!!

- og hvorfor i alverden bruger du dog onreadystatechange event'en, når du forespørger synkront? Det giver absolut ingen mening!

Vis, du har styr på det mest fundamentale - og så forhold dig til substansen i andres argumentation, fremfor deres person. I et forum som Eksperten er det den faglige/saglige substans, som er interessant ... ikke tilfældige personpræferencer  ;o)

/mvh
</bole>

Hey ole.

der er ingen grund til at advare imod brugen af innerHTML, istedet kan du give et link til mit design pattern, så folk lære at bruge innerHTML rigtigt... evt læse det selv...

FStringCat er en variant af den jeg fant på CodeProject: http://www.codeproject.com/KB/scripting/Exsead11.aspx
som i deres test, gav bedre resultat med varieret input, end alm string concat og Array.push/insert... hvis man opsætter en benchmark hvor alle inputs er lige lange, vil de 2 eksempler du kommer med, give et andet resultat.

At jeg havde glemt at sætte "async" til true, er en mindre fejl jeg har overset. tak fordi du gjorde mig opmærksom på det.

*LoL* Der findes ingen 'rigtig' måde at anvende en invalid property ... længere er den ikke!

Desuden har jeg masser af gange vist, at innerHTML ikke er uhensigtsmæssig at bruge - og at den ofte performer dårligere end DOM - og du har aldrig formået at argumentere mod substansen i de debatter. Jeg kan ikke rigtig se, noget skulle have forandret sig siden  =)

Jeg er sådan set ikke interesseret i, hvilke benchmarks codeproject.com har lavet. For mig er mine egne test naturligvis det, jeg forholder mig til - og det, der viser mig, om deres evt. antagelser er korrekte. Det kan jeg ikke sige, jeg er overbevist om - tværtimod!

Hvilke test har du selv lavet - og hvordan faldt de ud?

Jeg har lige testet din tese om at FStringCat skulle være langsom


console.time("push");
var oBuffer = [];
for (var i=0; i<20000; i++) {
    oBuffer.push("En eller anden streng, som skal konkateneres med en hel masse kloner af samme streng ...");
}
var s = oBuffer.join("");
console.timeEnd("push");


console.time("insert");
var oBuffer = [];
for (var i=0; i<20000; i++) {
    oBuffer[i] = "En eller anden streng, som skal konkateneres med en hel masse kloner af samme streng ...";
}
var s = oBuffer.join("");
console.timeEnd("insert");


console.time("FStringCat");
var oBuffer = new FStringCat();
for (var i=0; i<20000; i++) {
    oBuffer.push("En eller anden streng, som skal konkateneres med en hel masse kloner af samme streng ...");
}
var s = oBuffer.value();
console.timeEnd("FStringCat");


Resultat (Firefox2):

push: 1203ms
insert: 1141ms
FStringCat: 828ms

læs evt:

http://blog.mdk-photo.com/post/Worlds-fastest-HTML-Render.aspx

Kunne du ikke i det mindste læse, hvad jeg skriver - i stedet for at være så pokkers forblændet af dit had til min person? Jeg skriver jko _netop_, at din metode er hurtigst i FF. Min Gud, hvor er du dog tung at danse med ...!!!

Det var IE, jeg skrev om ...! Test i IE ...! Læs, hvad folk skriver til dig ...! Du er langt mindre interessant end du tror - og det gælder også dine meninger, sålænge du ikke gider lytte efter andre!

Vis i det mindste os andre så meget respekt, at du gider læse, hvad vi skriver!

du skriver at IE er langsommere end dine egne eksempler, men ikke at min metode er hurtigere i FF og ikke IE...

du er vidst lige så tung at danse med :-)

desuden er jeg pænt ligeglad med hvad IE gør og ikke gør, ide der nu er 3 versioner af IE som hver især er elendige på 3 forskellige måder...

så jeg her sådan set droppet at teste i IE, med mindre vi snakker basal funktionalitet (Events og CSS)

Jeg kan kun gentage: Læs, hvad jeg skriver! Jeg skrev:
    "Bruger jeg således det, du kalder for "Worlds fastest stringbuffer for Javascript", tager det i IE dobbelt så lang tid at konkatenere 20.000 strenge på ca. 90 tegn, som hvis jeg brugte syntaksen: [... her følger syntaksen ...]".

- hvad er det dog, du ikke kan læse i dén kommentar? Skriver jeg ikke højt og tydeligt, at dit script tager betydeligt længere tid om samme opgave? Hvem er så tung at danse med?

- og i øvrigt burde du ikke takke mig for at påpege, du havde lavet et synkront kald i dit såkaldte Ajax-eksempel. Du burde i stedet skamme dig over, du fylder WWW op med utestet junk!

Jeg er professionel programmør, så jeg har ikke råd til amatørbetragtninger om hvilke browsere, hvem ønsker at droppe

Jeg erkender dog, at jeg måske ikke tog stavepladen frem, da jeg skrev:
    "På den anden side er det korrekt, at disse to syntakser stinker i FF - ligesom alm. streng konkatenering stinker i FF [...]"

- men det burde trods alt ikke volde de store intellektuelle udfordringer at uddrage meningen af dén kommentar  =)

uuuhhh... du er professionel...  det betyder jo bare at du får penge for at kode...

professionel er måske et relativt begreb ?

jeg er måske ikke professionel nok til at have en mening ?

montago >> som sædvanligt: Hold dig til substansen! Jeg gider ikke lege med dig!

damn... IE6 er dælme hurtig til concat !

Jeg kan ikke lige se pointen i at diskuttere hastigheden på StringConcat, når IE6 er 50gange hurtigere, næsten uanset hvilken metode man vælger:

Firefox2
push:1188
insert:1141
fstringcat:890


Explorer6
push:78
insert:47
fstringcat:63

Så hvis man er så sindssyg at konkattenere en streng 20.000 gange med teksten: "En eller anden streng, som skal konkateneres med en hel masse kloner af samme streng ..."
Så er det derfor IE6 man skal bruge :-P

Firefox's 890ms er derfor trendsætteren som man skal veje sin sides performance på, og ikke IE's 63ms.

Men for at vende tilbage til diskussionen omkring innerHTML vs XML-DOM, så er vi tilbage til square one. Det nytter ikke noget at hjælpe noobs, ved at fortælle dem at de skal bruge XML-DOM, uden at vise dem hvordan... idet de ikke aner hvordan man kommer igang !

Din hjælp er derfor ubrugelig.

Hvis man ikke er 'sindsyg' nok til at konkatenere 20.000 strenge, har man intet at udtale sig på baggrund af. Gør man ikke det, er man nede på så korte tider, at usikkerheden bliver så stor, at resultaterne ikke giver mening - samtidig med, der bliver risiko for, at det er alle mulige andre forhold, der influerer på resultatet. Undskyld, men det er højtlæsning for pygmæer!

Derudover ved jeg ikke helt, hvad det er, du ikke kan finde ud af ved at lave en hel elementær test. Når jeg tester med nedenstående kode får jeg følgende resultater:

FF 2:
foo: 2062 msec
bar: 2141 msec
fooBar: 1500 msec

IE 6:
foo: 40 msec
bar: 70 msec
fooBar: 130 msec

IE 7:
foo: 31 msec
bar: 62 msec
fooBar: 110 msec

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Test</title>
<style type="text/css">
html, body {
    height: 100%;
    margin: 0;
    padding: 0;
    font: 0.85em verdana, sans-serif;
}
</style>
<script type="text/javascript">
function FStringCat(){
    var accum = '';
    var list = [];
    this.push = function(what){
        accum += what;
        if(accum.length>2800){
            list.push(accum);
            accum = '';
        }
    };
    this.value = function(){
        list.push(accum);
        accum = '';
        list = [ list.join("") ];
        return list[0];
    };
}


function foo() {
    var oBuffer = [];
    var nStartTime = new Date().getTime();
    for (var i=0; i<20000; i++) {
        oBuffer[i] = "En eller anden streng, som skal konkateneres med en hel masse kloner af samme streng ...";
    }
    var s = oBuffer.join("");
    oBuffer = null;
    var nEndTime = new Date().getTime();
    alert(nEndTime-nStartTime)
}
function bar() {
    var oBuffer = [];
    var nStartTime = new Date().getTime();
    for (var i=0; i<20000; i++) {
        oBuffer.push("En eller anden streng, som skal konkateneres med en hel masse kloner af samme streng ...");
    }
    var s = oBuffer.join("");
    oBuffer = null;
    var nEndTime = new Date().getTime();
    alert(nEndTime-nStartTime)
}
function fooBar() {
    var oBuffer = new FStringCat();
    var nStartTime = new Date().getTime();
    for (var i=0; i<20000; i++) {
        oBuffer.push("En eller anden streng, som skal konkateneres med en hel masse kloner af samme streng ...");
    }
    var s = oBuffer.value();
    oBuffer = null;
    var nEndTime = new Date().getTime();
    alert(nEndTime-nStartTime)
}
</script>
</head>
<body>

<button onclick="foo()">TEST</button>
<button onclick="bar()">TEST 2</button>
<button onclick="fooBar()">TEST 3</button>

</body>
</html>

- og hvis du vil have større nøjagtighed, kan du i stedet vælge at indsætte 200.000 strenge (men gør det kun i IE, da der ikke skal meget til at knække FF), hvilket i IE giver:

IE 6:
foo: 461 msec
bar: 801 msec
fooBar: 1683 msec

IE 7:
foo: 375 msec
bar: 687 msec
fooBar: 1547 msec

De store antal gennemløb af løkken har intet med sindsyge at gøre, men er en statistisk nødvendighed, hvis resultatet skal være signifikant!

Uagtet, der naturligvis altid vil være en vis indbyrdes afvigelse mellem tallene (også selvom den kan mindskes ved at forøge antal gennemløb af løkken og dermed øge den statistiske sikkerhed), kan jeg ikke få din funktion til at performe bedre i IE. Hvad er det mon, du gør, for at opnå de viste resultater?

Hvad blev der forøvrigt af påstandene i kommentaren(07/09-2008 17:12:09) om, at forskellen skulle skyldes 'varieret input'? Kan du ikke elaborere lidt på dén antagelse - og evt. give et eksempel?

"Men for at vende tilbage til diskussionen omkring innerHTML vs XML-DOM, så er vi tilbage til square one. Det nytter ikke noget at hjælpe noobs, ved at fortælle dem at de skal bruge XML-DOM, uden at vise dem hvordan... idet de ikke aner hvordan man kommer igang !"

>> Det har jeg vist masser af eksempler på, men åbenbart ikke på et niveau, hvor du har evnet at forstå, hvad der blev skrevet. Can't win 'em all!  =)

Der er ikke ret meget, der er af mindre interesse end, hvad du måtte mene om brugbarheden af min hjælp. Der er masser, der i tidens løb har haft begavelse nok til at gøre udstrakt brug af den. At din 'klogskab' i dén grad står i vejen for din udvikling er dog en hel anden ting, som du nok burde passe lidt på, ikke at rode sammen med alt muligt andet  ;o)

Jeg kan se dine taster bevæge sig, men det eneste jeg læser er BLA BLA BLA...

kom nu dit kvaj... vis hvordan Zonic skal løse sit problem med XML-DOM ;-)

ny version af FStringCat :

function FStringCat(){
    var accum = '';
    var list = [];
    var index = 0; //IE Speedup
    var isIE = !!document.attachEvent;
   
    this.push = function(what){
        if(isIE){
            list[index++] = what;
        }else{
            accum += what;
            if(accum.length>2800){
                list.push(accum);
                accum = '';
            }
        }
    };
 
    this.value = function()
    {
        if(isIE){
            return list.join("");
        }else{
            list.push(accum);
            accum = '';
            list = [ list.join("") ];
            return list[0];
        }
    };
}

forskellen på din concat-værdi's længde kan du læse på
http://www.softwaresecretweapons.com/jspwiki/javascriptstringconcatenation

og det første link jeg gav : http://www.codeproject.com/KB/scripting/Exsead11.aspx

hvor #2 viser fordelen ved at konkattenere strenge af længden 2800 chars
og #1 viser at små strenge er hurtigere end store.

Nej, da du ikke er i nærheden af dem, kan du ikke se min taster bevæge sig - og hvis du mener at kunne læse, jeg har skrevet "Bla Bla Bla ...", kan jeg garantere dig, at du har nået loftet med hensyn til de stoffer, du formodentlig sidder og fylder dig med!

Der er intet nyt i dine links - men det er da rart, at det endelig er gået op for dig, det ikke er klogt at skrive "Worlds fastest stringbuffer for Javascript" om sit eget tvivlsomme produkt, når man ikke er særlig stærk i kodning - men for 'klog' til at mene det nødvendigt at teste sine koder af. Det skrev jeg allerede i mit allerførste indlæg. Ih, guder - hvor er du dog tung at danse med!

Men du har stadig ikke gjort rede for dine påstande i (07/09-2008 17:12:09) om, at _varierende_ længde af strengene skulle have indflydelse på resultatet. Du skriver f.eks:
    "hvis man opsætter en benchmark hvor alle inputs er lige lange, vil de 2 eksempler du kommer med, give et andet resultat."
Det er klart at lange strenge tager længere tid end korte (og forskellen er ikke lineæer), men hvad ændrer det, at man bruger varierende længder - og hvorfor? Det fortæller dine links intet om. (Hvis du havde testet lidt videre, ville du iøvrigt vide, at der i visse sitationer/browsere ligger endnu et 'knæk' ved 4048 tegn).

- og så synes jeg faktisk, du skulle tage og stikke en finger i jorden og finde ud af, hvor du er henne! Det, at Admin netop har lukket et af dine spørgsmål, fordi du ikke evner at overholde E's helt simple regler ved oprettelse af et spørgsmål, burde vel få dig til at begynde at tænke dig lidt om.

Under alle omstændigheder kan jeg fortælle dig, at du på Eksperten ikke er blandt de mennesker, du plejer at omgås, hvorfor du bedes tiltale folk lidt mere dannet, end du åbenbart er vandt til.
I denne tråd har du spildt bunker af både din og min tid - blot for endelig at teste dit script og derved finde ud af, at jeg havde ret i min allerførste kommentar - og blot for endelig at lave dit script om. En ting, du kunne have gjort forlængst!
På den baggrund virker det ikke blot primitivt, men også yderst uklogt at kalde _andre_ for 'kvaj'!

Nej, jeg skal ikke i en E-tråd skrive en lang tutorial om, hvordan man skriver DOM. Eksperten er og har altid været et site for hjælp til selvhjælp, så man må selv sætte sig ind i det grundlæggende.
Til gengæld kunne spørgeren og jeg på nuværende tidspunkt være kommet vældig langt med en løsning, hvis ikke du havde spildt vores tid. Din egen første kommentar er jo intet andet end et slet skjult forsøg på at få fyret op under en diskussion med undertegnede.
Denne tråd er jo ikke mundet ud i andet end, at vi for Gud ved hvilken gang har fundet ud af, at du kaster om dig med tomme påstande og koder, du ikke engang har gidet teste! Endnu engang har det eneste, du har forsøgt at opnå, været at få et måbende publikum til dine udskejelser. Præcis det, der også var årsagen til, at Admin lukkede dit andet 'spørgsmål'.

Tag nu og spænd hjelmen ...!

hej kvaj

1.
"Worlds fastest stringbuffer for Javascript" har jeg aldrig skrevet, artiklen hedder "Worlds fastest HTML-Render" og indeholder både StrinConcat/Array.slice og innerHTML+DOM

2.
En test hvori man konkattenere den samme streng 20K gange, som i IE6 er 50gange hurtigere end Firefox, beviser kun at ens script i værste fast vil performe 50gange dårligere i Firefox, hvis man ikke tester begge browsere.

3.
Et script som tager 500ms i IE, men som ikke eksekvere i Firefox er ubrugeligt.

4.
hvis du GAD læse hvad fanden der står på de links jeg giver dig, ville du finde ud af at string concat performer forskelligt afhængig af længden på inputs (hvilket viser sig i formålsfyldte apps) - netop derfor vælger man at push når strengen er 2800 chars.

5.
hvis man mener at man hjælper andre ved at gå over åen efter vand, så er man et kvaj. innerHTML virker i ALLE browsere, og performer afsindig godt, hvis man bruger den rigtigt --> derfor et design pattern.

6.
du kommer ikke med en løsning, men 'bjørne-tjenste råd' til noobs.

Jeg må naturligvis forvente, Admin hermed deaktiverer din brugerprofil. Man er - p.gr.a. dine altoverskyggende behov for at blive hørt, læst og set - fornylig blevet nødt til at lukke et 'spørgsmål' og en 'artikel', oprettet af dig. Jeg tvivler stærkt på, Admin endnu engang vil finde sig i, du giver Eksperten og dens reglement en barnlig finger!

skal JEG straffes, fordi DU skal bevise overfor alle, at du er "Professionel" ?

Nej, hvorfor i alverden skulle du dog det ...?!??!!!

DOH ... (o_O)

men så vi jo enige om jeg ikke skal deaktiveres.

!

jeg fik desværre ikke ret meget ud af jeres snak om performance, holdninger og had til hinanden, men kunne kun bruge w13's svar om at indsætte et random id i mit script, eller ændre til post istedet... havde dog håbet på at jeg kunne lære hvad DOM kunne gøre for mig i denne sammenhæng, men det virker til at være alt for omfattende til at gå igang med... w13 og erikjacobsen, vil I smide et svar...?

Ingen point til mig, tak.

Du bør ikke sætte et random id. Det kan lade sig gøre, men det bedste er, som Erik skrev, at bruge POST  ;o)

Jeg nærer absolut ikke noget had til montago, men vi har det med at tale voldsomt forbi hinanden - formodentlig fordi vi taler udfra to vidt forskellige baggrunde.

Lever man af at programmere, har man nødvendigvis en vis faglighed, som danner grundlaget for ens betragtninger og holdninger. I den situation er det lidt vanskelligt at diskutere med en person, som endnu ikke selv har haft noget somhelst fag - og dermed ingen idé om, hvad faglighed er for en størrelse.
At montago så reagerer voldsomt (og ret infantilt) på min kommentar om, at jeg som professionel ikke har råd til at fyre den ubetinget mest udbredte browser, må jeg gå udfra skyldes en meget ung alder  =)

Naturligvis har montago lov til at have en mening om programmeringsfaget. Han kan bare ikke forlange, at den tillægges nogen større vægt. Mit 7-årige barnebarn må også hellere end gerne have en mening om sex - men det er næppe noget, der giver dybere mening at diskutere med ham  =)

Hvad DOM angår, er du nok nødt til at sætte dig ind i de grundlæggende teknikker først. En CSS-, HTML- eller JavaScript-tutorial er heller ikke noget, man kan forvente i en Eksperten-tråd  =)

Jeg kan se, at hverken Ole eller jeg kommer med det sidste argument mht brugen af POST: Browsere kan finde på at cache i RAM de requests der laves med GET (selvfølgelig også med et randomid). Og hvis man ikke har noget at bruge det til, så skal man bruge POST.

"Lever man af at programmere, har man nødvendigvis en vis faglighed, som danner grundlaget for ens betragtninger og holdninger. I den situation er det lidt vanskelligt at diskutere med en person, som endnu ikke selv har haft noget somhelst fag - og dermed ingen idé om, hvad faglighed er for en størrelse."

Jeg finder det utroligt at du kommer med en så idiotisk kommentar, når du tydeligvis ikke undersøger (eller kan huske), at jeg er uddannet IT-Ingeniør og pt. arbejder som dette. At jeg sidder med et projekt til 1+ million på egen hånd lige nu, må så være noget jeg drømmer mig til...

Du ER et kvaj, fordi du i dit ego ikke finder plads til at tage fejl.

I Ajax har jeg svært ved at forestille mig et scenarium, hvor GET er mere brugbart end POST, så POST bør altid foretrækkes.

Der sker det i IE, at når man sætter en unik query-streng (f.eks. ved at medsende en unik ID), caches indholdet af response-dokumentet ikke. I hvertfald ikke i den forstand, at responsen vises næste gang, samme dokument kaldes.

Til gengæld gemmer IE alle resultaterne i hukommelsen, som derved laqngsomt ædes ved hver request. Derfor bruger man altid POST ved Ajax  =)

montago >> Jeg har kun dine indlæg her på Eksperten at bedømme din alder og faglighed udfra. Intet af det, jeg til dato har læst fra din hånd, har peget i retning af en alder over 16-17 år - og faglighed har jeg heller ikke set spor af. Måske, du finder kommentaren idiotisk, men den bygger som sagt udelukkende på dine egne implicitte informationer. Du bliver bedømt på din opførsel ... intet andet!

Som sagt må jeg stadig formode, at Admin ikke finder sig i dine konstante overtrædelser af E's reglement.

Hvad opblæst ego angår, så er det vist ikke mig, der fik lukket en artikel, fordi den ikke indeholdt andet end et link til en engelsksproget blogpost fra din hånd - samt et 'spørgsmål', som ikke indeholdt andet end dit nødråb om opmærksomhed og en bøn om at læse dine udgydelser!

Jeg husker klart og tydeligt at have fortalt dig om min profession, envidere har du jo kunnet læse om den på min hjemmeside (CV anno 2007)

Spørgsmål og artikel blev lukket fordi folk bitchede over at artiklen kostede 5 fiktive point og at spørgsmålet ikke var et spørgmål. Min hensigt var at udbrede et 'best practice' design pattern omkring brugen af innerHTML... At jeg så valgte en forkert taktik, må jeg så lære af.

-- men for sådan en som mig, kan det være svært at forstå, at en, der har læst til ingeniør, ikke kan forstå og følge Ekspertens regler (de er dog skrevet til at kunne forstås af teenagere ?-)

-- og det er mig helt uforståeligt, at du mener, at det fag, du åbenbart har, overhovedet ikke skal forholde sig til de kollektive spilleregler, og at du finder på ukritisk kraftigt at promovere metoder, antagelser og ideer, som strider lodret mod det grundlag noget af dit fag er bygget på ...

-- det er absolut ikke forbudt at være uenig, men det tyder absolut ikke på faglighed, hvis man finder på at kritisere uden at gøre opmærksom på, at det man nu udgyder er absolut udenfor alt det grundlag, der ellers findes (i dette tilfælde i SGML-ting !-)

-- er sådan noget som videnskabsteori ikke et emne, man kommer forbi i ingeniør-uddannelsen ?o]

Det var det da, da jeg læste på Sletten  =)

:)

roenving:

- at være ingeniør er én ting, at følge ret og regler er jo frivilligt og hænger derfor ikke nødvendigvis sammen.

- der er ingen regler som forbyder at bruge eller promovere 'innerHTML' (som er sagens kerne). Som udvikler har man jo ret til at benytte de værktøjer og metoder som er tilstede. Set i projekt sammenhænge giver det god mening at bruge de metoder og teknikker som bringer dig hurtigst til målet, til fordel for den som skal betale for tiden. DOM er kun nyttig hvis man har et framework til at hjælpe sig, og så længe Ole ikke kommer med dette framework, er innerHTML LANGT HELLERE en fordel for begyndere - DERFOR promovere jeg dels metoden og dels dét design pattern man skal benytte.

- jeg har ikke haft faget 'videnskabsteori', men kender vel til termerne i kraft af fagenes struktur og de datalogiske fremgangsmåder/beviser. Så her må jeg på en måde skuffe dig og sige, at man godt kan risikere at komme udenom...

-- men ikke på et videnskabeligt grundlag uden at gøre opmærksom på, at man altså lige her og nu bryder med de vedtagne kollektive regler ...

-- og det var jo sådan set essensen af mit indlæg:

-- Enten skriver du 'her snyder jeg lidt', hvis du vælger at bruge noget, der går ud over disse regler (eller gør opmærksom på, at du her laver noget nyt, banebrydende, som kan give dig en Nobel-pris !-)

-- eller også skal du enten erkende, at du ikke har tilstrækkelig viden om den virkelighed, du lige kigger på, eller realiserer, at du helst vil agere, som alle andre, der ikke kan finde ud af, at benytte det omgivende samfunds love og regler som udangspunkt for din aktivitet, ligesom f.eks. mafiaen og Al-Qaeda ...

-- ej, den sidste blev lidt grov, men egentlig ganske rammende !o]

-- og så må jeg jo alvorligt korrekse dig i, at det er frivilligt at følge ret og regler, præcis dette er grundlaget for vores civiliserede samfund, anarki har til alle tider kun kunnet omstøde samfund, ikke kunnet opbygge dem ...

)en helt anden ting er så, at man i visse filosofier, f.eks. anarkismen, har ment, at det nuværende samfund har så lidt at bidrage til menneskenes liv og udvikling, at selv en omstyrtelse af samfundet er et gode ,-(

"Som udvikler har man jo ret til at benytte de værktøjer og metoder som er tilstede." - bruger du innerhtml i professionel sammenhæng, er du nødt til i kontrakten at anføre, at du bruger metoder, der ikke er i overensstemmelse med W3C-standarder, og at de derfor ikke kan forventes at virke i alle fremtidige browsere (og egentlig ved du kun at innerhtml i dag virker i de fede browsere, der findes på almindelige PC-ere).

Om en kunde så vil købe dit produkt, vil være helt op til kunden.

Hvis du ikke giver kunden denne advarsel, så er du uprofessionel.

"DOM er kun nyttig hvis man har et framework til at hjælpe sig" >> Det er endnu en helt subjektiv betragtning, som masser af kodere, der koder DOM, ikke vil være enig i.
Jeg kender adskillige kodere, der koder ret store applikationer uden et egentligt DOM-framework - og nogle af dem er vanvittig hurtige!

Skal man kode til stat eller kommuner, _skal_ W3C's standarder være overholdt, så dér kan man i hvertfald ikke få lov at bruge innerHTML

roenving:

Web-standardernes implementering er netop anarki !

Derfor giver det ingen mening at snakke om at følge 'standarden'.

innerHTML ER en standard, hvis man snakker om faktisk implementering.

Tjah, som erik skriver, så ville jeg ikke skrive en 1 mio+-kontrakt med dig ,-(

-- og hvis jeg var offentlig indkøber, ville jeg miste retten til at gøre det, hvis jeg forssgte ...

montago >> Du må nok lære at finde dig i, vi andre smider den sorte hættetrøje og sølvringene i næsen, når vi koder  :D

Det ville dog nok være formålstjenligt, om du i fremtiden oplyser, at du bekender dig til anarki og ikke mener, det giver mening at følge W3C's standarder ... men gør det i begyndelsen af tråden, så forsvarsløse brugere, som ikke kender dig, kan få en chence for at bedømme lødigheden af dine udgydelser

Problemet er vel i bund og grund at innerHTML er en de facto standard, og ikke de jure.

Det svarer vel lidt til situationen med alm. programmer for nogle få år tilbage - det var normalt at folk havde administratorrettigheder og fuld kontrol (de facto), og derfor kodede folk typisk ud fra den antagelse - hvilket førte til mange programmer  der bare skrev en masse i HKEY_LOCAL_MACHINE og C:\Programmer.

De jure var dog at med mindre den handling man skulle udføre krævede de rettigheder (det er der trods alt nogle ting der gør), så skulle man ikke regne med det - og hvis en almindelig bruger skulle kunne gøre det, så skulle man lave en service der kørte med de nødvendige rettigheder, og kommunikere med den (et eksempel der bruger dette er Steam, i forbindelse med opdateringer).

Effekten af den holdning ser vi nu med UAC i Vista, fordi mange af de lidt ældre programmer enten skal en tur gennem Folder Redirection, eller eksplicit køres med administratorrettigheder.

(Enkelte dele i dette indlæg kan være overdrevede for forståelsens skyld.)

"innerHTML ER en standard, hvis man snakker om faktisk implementering." - ja, og så skriver du i kontrakten at der er elementer i dit system, som du kun ved virker i aktuelle, faktiske implementeringer - bør vel nævne dem ved navn. Så skulle det juridiske vel være på plads.

erikjacobsen.

Går du blindt ud fra at alt du koder, som angiveligtvis følger W3C, virker i alle eksisterende browsere samt fremtidige browsere ?

eller giver du dig tid til at teste det ?

endvidere vil jeg mene at du er en dårlig service udbyder, hvis du koder ting som følger standarden. Hvorefter du siger til kunden: "beklager det ikke virker i Explorer, men jeg kan jo ikke gøre for at Microsoft ikke følger W3C"

"Går du blindt ud fra at alt du koder, som angiveligtvis følger W3C, virker i alle eksisterende browsere samt fremtidige browsere ?" - det gør du jo.

Hovsa. Jeg skulle have klippet:

"Går du blindt ud fra at alt du koder, [...], virker i alle eksisterende browsere samt fremtidige browsere ?" - det gør du jo.

Men holder man sig til ting, der findes i standarderne, er der jo altså en større chance for at det virker. Og så behøver man ikke bruge det fra standarderne, der så ikke virker i udbredte browsere.

Hrm, det er da ret vildt, at du ikke forstår noget og fremturer voldsomt ...

-- selvfølgelig udvikler man ikke noget, der ikke virker i de pt. mest udbredte browsere (og det er jo så en kravspecifikation, der sætter niveauet !-), men det er mindst lige så skørt at udvikle noget, man med 100% sikkerhed ved ikke virker i fremtidige eksemplarer af racen (medmindre man har fået til opgave at udvikle en hjemmeside, der ikke _må_ virke i fremtiden !-)

Roenving:

hvorfra ved du med sikkerhed, at en ting som innerHTML ikke vil blive implementeret i fremtidige browsere ?

- Chrome har den
- IE8 har den (i alle compatibility modes)

hvor er argumentet i det udsagn ?

IE8 (jeg mente i ALLE modes)

montago >> nu, du er så interesseret i at vide, hvad erikjacobsen tager sig tid til - og ikke tager sig tid til - at teste, burde du måske overveje, om du selv tester nok.

Det er da ret pudsigt, at du ved sekstiden igår - en måned efter du har postet en artikel på din blog om bl.a. konkatenering - pludselig opdager, hvor hurtig IE er til konkatenering! Og kun en halv time efter, du fortalte de måbende brugere, du har droppet at teste i samme browser ... en browser, du tydeligvis (heller) ikke har testet særlig godt

- for ikke at tale om koden i din 'Ajax artikel', der sendte en _synkron_ forespørgsel. Det er nok også lidt sent at opdage over en måned efter, artiklen blev posted.

At teste er altid en god ting - og det mindste, man kan gøre for at vise sine sagesløse læsere en smule respekt

novra... jeg er helt benovet over hvor meget energi du lægger i at undersøge mine handlingsmønstre og gøremål... du må være min største fan! :-P

min ajax artikel er kun lidt over en uge gammel...

(09/09-2008 17:13:44) er præcis den type kommentar, jeg mener klinger langt mere i harmoni med bogstaverne SFO - end med DTU!

Nå, men for at slutte dagen lidt positivt, kan man da slå fast, at det, at du - og ovenikøbet på skrift - har turdet kalde dig for IT-ingeniør, må kunne indgyde Brian Mikkelsen nok mod til endelig at springe ud som R&B-sangerinde ... hvis han altså skulle blive træt af sin nye rolle i Lommeknivsministeriet  :D

"
hvorfra ved du med sikkerhed, at en ting som innerHTML ikke vil blive implementeret i fremtidige browsere ?
"

-- jeg ved med sikkerhed, at det ikke vil være implementeret i alle fremtidige browsere, da der garanteret en dag kommer en, der udnytter x(ht)mls mulighed for at skrive den meget slankere browser, så den kan indlejres i meget mindre forbruger-elektronik, og så er en ting, der strider lodret mod grundlaget i sgml og xml udelukket ...

-- og det var vist en repetition af udsagn, der tidligere er udgydt i denne tråd ...

roenving:

dit argument holder bare ikke

- forbruger elektronik (pda, mobil, andre lign) er allerede i dag så avancerede at man begynder at smide hele/halve frameworks på (.NET) og Operativsystemer (Symbian, Windows CE, OSX). Safari på iPhone kan således sagtens udskrive ting med innerHTML, og er den første og eneste mobil man rent faktisk GIDER bruge til internet.
De enheder som ikke har et kraftigt grundlag af understøttelse vil i forvejen have problemer med at vise store dele af siderne og sjældent blive medregnet som mål.

HVIS man endelig ønsker at udvikle til sådanne enheder, med begrænsede muligheder. så udvikler man jo selvfølgelig i standarder man VED virker på målgruppen.

Hvis målgruppen er de mest populære browsere, tester man selvfølgelig disse.

Jamen, så må du jo bare håbe, at ejermændene til de milliarder, der allerede er investeret i X(HT)ML, ikke har noget særlig kærligt forhold til penge. Ingen har som bekendt endnu implementeret en innerHTML-version, der f.eks. er kompatibel med namespaces.

Desuden ses den mest udbredte anvendelse idag i forbindelse med Ajax. Som jeg også adskillige gange har pointeret, er problemet i virkeligheden ikke så meget performance på klienten.

Derimod tager det adskillige gange længere tid at formatere data som HTML på serveren - i forhold til, hvorlang tid, det tager at formatere samme data som JSON. På længere sigt er jeg overbevist om, det kun vil være de ringeste programmører, der kan finde på helt frivilligt at belaste serveren tre-fire gange hårde, end det er nødvendigt ... hvis det da ikke allerede er sådan idag.

Jeg formoder også, at vandstanden i verdenshavene de kommende år vil stige - at Dronning Margrethe vil være ældre næste år, end hun er idag - og at Anders Fog ikke vil være statsminister i 2075.
Det er ikke usandsynligt, der er nogen, der tror noget andet, men det ødelægger på ingen måde min nattesøvn. Jeg er komfortabelt sikker på mine 'forudsigelser' - men sådan er folk jo så forskellige  =)

lige et lille spørgsmål inde i debatten, nu hvor så mange kloge mennesker er samlet ;)

kan det passe at det indhold jeg loader med det meget omdiskuterede innerHTML ikke kan bruge javascripts? :)

altså hvis jeg henter f.eks. en tilfældig  side.php ind.. så sker der intet når man trykker på de javascripts der måtte ligge i filen.. har prøvet at lægge script filerne i hovedfilen jeg loader siden fra, og også inde i siden jeg loader ind..?

Ja, det kan sagtens passe - men hvorfor i alverden indsætter du dog også en hel side? Du ved godt, at Ajax-indhold ikke uden videre kan findes af søgemaskiner, ikke?

det jeg bruger det til er noget livescore statistik, hvor indholdet, som egentlig er nogle tal, og så et par grafer, ligger i en fil for sig :) men jeg har lavet det så snildt (synes jeg selv ) at når jeg loader siden laver jeg filen som include først, og så kører jeg javascriptet bagefter.. så finder søgemaskinen det den skal...  :)

f.eks.
<div id="ajax">
<? include ("livestat.php"); ?>
<script type="text/javascript" language="javascript">
ajaxUpd('livestat.php','ajax',5); // skifter indholdet i div'en "ajax" ud og opdaterer hvert 5.sek
</script>
</div>

OMG... hvor relevant er det at hans side virker på en søgemaskine... undskyld jeg spørger !!!! et komplet tåbeligt spørgsmål efter min mening.

hey zonic... dit Javascript skal ligge udenfor det DIV du vil opdatere.

hvad tænker du på? altså det med at få javascriptet til at virke i det indhold jeg henter ind? :)

hvordan ser det indhold ud som du fylder i dit DIV ?...

hvis man med innerHTML indsætter html med inline events :

blabla.innerHTML = "<span onclick='noget()'>tingeling</span>"

så vil det virke..

men "function noget(){}" skal ligge udenfor div'et

sorry...

Jeg kunne simpelt hen ikke se hvorfra den søgemaskine skulle komme ind i billedet. Det indledende spørgsmål samt det linkede taler intet om at skulle være søgemaskinevenligt.

- men fuldstændig, som man kunne have forudsagt, flegner du naturligvis igen ud på din (heldigvis) helt unikke facon! Du er nu en pudsig, lille mandsling  :D

Jeg tror vist bare, at "-zonic-" skal skynde sig at acceptere svaret fra "w13" så vi kan få afsluttet dette spørgsmål ;)

Jeg har intet problem med at I diskuterer om hvordan tingene skal gøres (og ikke gøres), men jeg har et problem med at I ("olebole" og "montago") bliver personlige og skriver ting som ikke burde være sagt. Her tænker jeg på de 2 nedenstående kommentarer:

Kommentar: olebole 08/09-2008 12:49:32

"...du har nået loftet med hensyn til de stoffer, du formodentlig sidder og fylder dig med!"

Kommentar: montago 08/09-2008 15:48:09   

"hej kvaj..."

olebole: Jeg ved godt du ynder at kalde en spade for en spade, men i denne situation beder du altså godt nok selv om, at man skal smide noget tilbage i hovedet på dig.

Der må næsten gå noget forud for dette spørgsmål siden I meget hurtigt kommer op at toppes. Jeg vil helst ikke bede jer om at holde jer fra hinanden, men såfremt I slet ikke kan enes, og det er til skade for spørgsmålet, så må vi jo se på hvad vi så kan gøre. Så længe I holder det på et saglig plan og ikke blot prøver på at jorde den anden, så er I velkommen til at vise hver jeres måde at gøre tingene på.

God weekend til alle :)

Snowball / Admin

innerHTML er en del af det seneste HTML5 WD ;) http://www.w3.org/TR/html5/

Og WD betyder Working Draft - udkast. Dermed ikke nogen standard. Om HTML5 bliver til noget, og i givet fald om den overholder det link du giver, og om innerHTML i den form der beskrives er med, vides ikke.

Det kan være de opdager de grundlæggende semantiske problemer med innerHTML, når du nu forsøger at beskrive det, eller kommer op men en funktionelt reduceret udgave. Vi ser om 5 år ;)

Ups, ikke "når du nu forsøger at beskrive det", men "når de nu forsøger at beskrive det".

yep ;) hvis da 5 år kan gøre det ;D

Egentlig er det meget prisværdigt at de forsøger at standardisere "almindelig praksis" og browserfabrikantopfundne ting, som man vel kan sige innerHTML er.

Det kan der så komme een af flere ting ud af
1: De opdager, at det ikke semantisk giver mening, og reducerer anvendelse til HTML i retning af "<b>Agurk</b>" - dvs simple tags, men kun valid HTML.
2: De opdager ingenting, og browsere implementerer det med vidt forskellig semantik, når man bevæger sig lidt væk fra "<b>Agurk</b>"
3: De finder en "magic bullet", som gør at innerHTML fungerer som mange tror det gør ;)

Lad os for det første ikke håbe, der bliver to (eller flere) sideløbende standarder!

Hvis der kun bliver én, er jeg ikke i tvivl om, det bliver XHTML. Der er allerede bundet milliarder af dollars i XHTML og teknologier, som bygger derpå. Netop fordi XHTML er 'extensible markup', er der ikke ret meget af det, der ligger i HTML5 udkastet, som ikke også kan laves i XHTML - og resten kræver kun mindre udvidelser. Penge er næsten altid det, der taler højest, når en standard skal besluttes, så deeeeeeet ....

- men der er tale om tro  =)

Jo flere standarder, jo mere arbejde til os. Så vi vil have standarder, masser af standarder!

- ja, var det ikke noget med en pakning og en tolerance målt i 'måske tommer' eller 'måske millimeter', der gav en bunke ekstraarbejde til fejeholdet på Cape-Et-Eller-Andet, da Discovery skulle sendes op?  ;D

er der nogen der kan sige mig om man kan lave en onload javacommand i det man henter ind i innerHTML?

altså hvis jeg loader  test.php ind med mit script, så vil jeg gerne have at test.php skal udføre ex.    lavKaffe();  javascriptet så snart det er loaded ind... eller evt. med setTimeout... men synes ikke det virker?

Ja, det kan du gøre på mange forskellige måder. Dog med JavaScript og ikke Java. :)

det var også det jeg mente :P

hvordan gør jeg ? :)

function lavKaffe() {
    alert("Coffee ... but definitely not a cup of JAVA! =)");
}

window.onload = function(){
    // Først nu kan du være sikker på,
    // alle elementer i markup'en er loaded
    lavKaffe();
}

Ahhh ... browserne opfører sig forskelligt i forhold til script, indsat med innerHTML - men du kan jo bare skrive:
    ELEMENT.innerHTML = "En streng";
    lavKaffe();

hmm dét han mener er:

element.innerHTML = "<script> lavKaffe() </script>"

som i nogle tilfælde vil virke hvis man kringler den lidt :

element.innerHTML = "<scr"+"ipt> lavKaffe() </scr"+"ipt>"


det er dårlig kodeskik og et elendigt pattern. lidt i samme stil som Eval...

dét man hellere skal gøre, er at lave en parser som modtager nogle kommandoer fra dit Ajax, som derefter udføre dine kommandoer.

hvor er detr jeg skal skrive det der element.innerHTML ?

Der hvor du vil have det gjort. =)

men er det i denne fil?

www.skovbakken-badminton.dk/system/ajaxengine.js
omkring line 95?

Ja, det ser sådan ud.

"som i nogle tilfælde vil virke hvis man kringler den lidt" >> hvad er det for tilfælde, hvor:
    element.innerHTML = "<scr"+"ipt> lavKaffe() </scr"+"ipt>"

- vil virke? Er det bare mig, der mangler fantasien, eller er det noget vrøvl?

PS: der er væsentlig forskel på, hvad man kan med document.write og med innerHTML  ;o)

doh... så huskede jeg forkert.

Jeg har dog det eksempel på hvordan man dynamisk generere et script og lægger det op i <head>

http://mdk2002.dyndns.org/vector3_3/

i stedet for at lave loops, bliver alle loops lavet om til statiske funktioner som prototypes på et object - hvorefter man kalder disse nye funktioner :)

Flot - men for at noget kan bruges på WWW, bør det vel kunne anvendes i markedets ultimativt største browser  ;o)

Det er nu en lidt sjov idé, du har fået - hele tiden at insistere på at give dig selv den ene begmand efter den anden. Det er nok ikke lige på dén mark, anerkendelsen gror!  =)

jeg er igen på herrens mark... hvad skal jeg gøre for at det virker... I snakker i koder, drenge :D

ved at indsætte den i linie 91 får jeg "element not defined"...

ved at indsætte senere får jeg intet resultat...

element.innerHTML = '<script src="/tinymce/advanced.js" type="text/javascript"></script>';

Glem innerHTML. Du kan kikke i denne tråd, hvor jeg har vist et par små Ajax/PHP/JSON eksempler. Du kunne f.eks. returnere et script som en streng i en JSON-variabel og så køre den gennem eval:
    http://www.eksperten.dk/spm/817625

I det konkrete eksempel fra 11/10-2008 00:44:01 kan du jo blot putte den .js fil ind i din hovedside fra starten. Det du forsøger på, er en af de ting, der ikke er veldefinerede med innerHTML.

det der er problemet er, jeg har loaded scriptet i min hovedside... men men men.. .ved ikke om I kender TinyMCE, som er et script der ændrer alm tekstbokse til en slags editor tekstbox med wordlignende funktioner... men når jeg loader indholdet gennem innerHTML vil den ikke lave mine tekstbokse om.. der sker ganske simpelt intet med dem... :(

1) Nu forstår jeg slet ikke, hvad vi taler om. En online-editor er noget helt for sig - så måske, du skulle oprette en helt ny tråd, hvor du fortæller, hvad det faktisk er, du vil lave  =)

2) Bruger man innerHTML, kan der - som jeg efterhånden har anført et utal af gange - ske rigtig mange uforudsete ting, hvis ikke man har 100% styr på, hvad der foregår helt nede i hver kodedetalje

Jamen, så lad være med at loade indholdet gennem innerHTML. Følg eksemplerne fra TinyMCE.

det der er målet er at jeg har en side med en slags forum, hvor man skal kunne trykke "ret" indlæg, hvor den så med innerHTML skifter indlægget ud med en textboks med tinyMCE plugin på.. så derfor er det rimelig væsentligt at få loaded det med ind med innerHTML :)

jeg nægter at tro på at det ikke kan lade sig gøre.. jeg giver self gerne flere points, hvis det kan løses.. anyone? :)

Hvorfor innerHTML? Hvorfor ikke bare have tinyMCE-boksen liggende skjult? Når man så klikker "ret", skjules indlægget og tinyMCE-boksen vises.

det har jeg også lavet som det er nu.. problemet er bare at så tager siden bare en hel del længere tid at indlæse :(

Hvis du viser mig, hvad du før indsatte med innerHTML, kan jeg nok lave en gyldig JavaScript-kode, der gør det samme.