Skal der opdateres noget på selve siden, eller skal der bare udføres et kald til serveren uden noget returneres?
Hvis det blot er et simpelt kald til serveren (evt. med parametre) kan du nok klare det med denne kode:
setTimeout(opdater, 3000);
function opdater() { // virtuel sti til den side der skal kaldes var url = "/opdater.asp"; // find billedeelementet var img = document.getElementById("imgOpdater"); // skift "billedet" i billedeelementet ud med en opdateret sti // (timestamp skifter hver gang for at undgå at cachen benyttes) img.setAttribute("src", url + "?ts=" + (new Date()).getTime()); }
og så skal du lægge et billedeelement på siden som har id'et imgOpdater, dvs. noget i stil med:
Vil du generere html-koden til hele vægen på serveren og så blot opdatere et helt område på siden, eller vil du ud i noget med at nørkle med med DOM og oprette elementer dynamisk?
Med jQuery kan du rimelig let opdatere et område af din side, hvis indholdet er formateret som html fra serveren. Det kunne f.eks. se således ud:
olebole >> Jeg tror faktisk ikke på argumentet om, at serveren bliver betydelig mere belastet af at generere svaret som HTML frem for f.eks. JSON. Størstedelen af tiden på serveren går givetvis alligevel med at hente data fra en database.
Hvis der skulle være noget argument mod mit foreslag, så ligger det nok i, at der rent datamæssigt skal transporteres flere data, hvis svaret kommer som HTML frem for JSON.
Med udgangspunkt i et 80/20-princip, forsøger jeg at finde en løsning som er fornuftig, uden at være alt for omkostningsfuld at implementere, det mener jeg den løsning jeg skitserer er - også selvom det ikke er "rigtig" AJAX og superoptimal :-)
Reflektion: Hvis den HTML der genereres på serveren nu er XHTML, så er det vel AJAX i sin grundliggende form - endda mere end JSON... moralen må derfor være, at man bare skal generere XHTML for at det kan blive rigtig AJAX (iflg. definitionen Asynkron Javascript og XML) :-)
Fodnote til selve løsningen i #3: Hvis du vil optimere det lidt, kan du returnere en http statuskode 404, hvis der ikke er sket nogen ændring på vægen, så vil load ikke opdatere indholdet i browseren, men blot ignorere opdateringen. På den måde sikrer du dig at der ikke læses mere end allehøjst nøvendigt. Specielt interessant, set i lyset af den hyppige opdateringsfrekvens :-)
Jamen, jeg bygger skam ikke kommentaren på tro - det er et velafprøvet faktum =)
Vedr. dine refleksioner, taler jeg ikke nødvendigvis om XML, som jeg stort set aldrig bruger som data transport sprog. Jeg bruger JSON, som er native i PHP og som er fantastisk effektivt.
Selv ved den mest effektive måde at udskrive et recordset som en HTML streng, tager det mindst 4-5 gange længere tid, end hvis du udskriver samme recordset som en JSON streng. Er du i tvivl, kan du bare prøve.
Det er specielt interessant, set i lyset af den høje opdateringsfrekvens ;o)
Jeg har lige lavet en lille test på en tabel, der viser hits på en bestemt side. For at komme op på tider, der overhovedet er realistisk at regne på, har jeg trukket 300 rækker ad gangen. Koden er:
// Open database
$timeBeforeDB = microtime(true); $sql = "SELECT * FROM `hits` LIMIT 300"; $res = mysql_query($sql) or die (mysql_error()); $timeAfterDB = microtime(true);
Jeg er godt klar over at du er varm fortaler for JSON og jeg foretrækker da også selv denne protokol, men hvis JSON nu ikke er native i det serversprog man bruger, så skal det jo sammensættes på samme måde som (X)HTML i øvrigt.
Desuden er der stadig den faktor som omhandler behandling af data på klienten, når de returneres som JSON. Det er (for de fleste) stadig en noget mere kompleks opgave, at skulle bygge siden op via en masse DOM-massage, så det kan meget hurtig blive en dyr løsning i forhold til den jeg foreslår.
Med hensyn til den forbrugte tid i forbindelse med opslaget i databasen (i din test), så er det vel fordi der returneres en cursor til data og ikke de faktiske data, hvilket så først giver et hit på det tidspunkt, hvor du gennemløber data...?
Hvor mange gange har du prøvet at køre dette? Kunne det tænkes der sker en caching af resultatet efter gennemløbet hvor du genererer HTML-koden? Har du prøvet at bytte rundt på de to løkker, så JSON bliver genereret først?
En fair test ville vel være at generere JSON ligesom du genererer HTML-koden. Jeg antager meget af tiden i HTML-genereringen går med strengsammensætningen og opslag i dit recordset (eller hvad det nu hedder i PHP - jeg fatter ikke meget PHPsk).
Der kan gøres mange ting for at optimere mit løsningsforeslag, et foreslag er allerede givet, et andet kunne være blot at returnere HTML for de nye tags der er kommet siden sidst og så bare tilføje det til væggen (hvilket ikke er meget mere kompleks med jQuery, end det jeg allerede har vist) :-)
"Jeg er godt klar over at du er varm fortaler for JSON" >> Nej, jeg eer fortaler for den mest effektive løsning. Hvis det er JSON, er jeg fortaler for JSON.
"Det er (for de fleste) stadig en noget mere kompleks opgave, at skulle bygge siden op via en masse DOM-massage, så det kan meget hurtig blive en dyr løsning i forhold til den jeg foreslår." >> Det er en myte. En almindelig god frontend-koder bør ikke have problemer med den slags - og det bør man være, hvis omkostninger er et issue, for så er man jo professionel.
"Med hensyn til den forbrugte tid i forbindelse med opslaget i databasen (i din test), så er det vel fordi der returneres en cursor til data og ikke de faktiske data, hvilket så først giver et hit på det tidspunkt, hvor du gennemløber data...?" >> Ja, men det er jo helt ens for begge metoder/test.
"Hvor mange gange har du prøvet at køre dette" >> Masser - og andre Eksperten brugere har testet det samme i tidligere tråde ... selv folk, som elsker at hade mine holdninger omkring brugen af Ajax. Ydermere er det et faktum, som igen og igen er afprøvet i masser af artikler og forumtråden rundt om på WWW. Desuden ville det jo være intet mindre end en sensation, hvis en native funktion skulle være langsommere end noget, man selv sidder og fedter sammen i PHP ;o)
"En fair test ville vel være at generere JSON ligesom du genererer HTML-koden" >> Jamen, det ville jo nada mening give! Pointen er netop, at JSON udskrives med native kode ... i modsætning til HTML udskrivning. Præcis derfor er det langt bedre performende at returnere JSON, end det er at returnere HTML =)
"Jamen, det ville jo nada mening give! Pointen er netop, at JSON udskrives med native kode" >> min pointe er, at det ikke er native i alle frameworks, så derfor efterspørger jeg en test som bruger samme metode for begge...
I relation til databasetiderne: "Ja, men det er jo helt ens for begge metoder/test" >> jo, men hvis omkostningen for læsning af databasen først viser sig under selve gennemløbet af rækkerne, så er det jo stadig en omkostning som skal tilskrives databaseopslaget og ikke genereringen af strukturen (HTML eller JSON) - så det var for at pointere, at de "83 gange hurtigere", måske ikke er helt korrekt.
"min pointe er, at det ikke er native i alle frameworks, så derfor efterspørger jeg en test som bruger samme metode for begge..." >> Jamen, det giver jo absolut ikke mening! I PHP eksisterer en native funktion til udskrivning af JSON, hvorfor det naturligvis ville være komplet i hegnet at teste mod manuel udskrivning af JSON! I andre frameworks kan du installere komponenter, der udskriver JSON med ligeså stor hastighedsgevindst som i PHP. Har man mulighed for det, gør man det naturligvis. Såvidt jeg husker, er det endda også native i .net. Derimod er det højtlæsning for pygmæer, at hvis man er nødt til manuelt at udskrive en streng, er der ikke den store forskel på HTML og JSON =)
"Ang. innerHTML, så håber jeg" >> og indtil browserne ikke længere understøtter font- og center-tags, bruger du naturligvis også dem ... eller? =)
Jeg har lige lavet en ny test, hvor jeg lagde alle rækker i recordsettet ind i et alm. array i en while-løkke. Array'et blev efterfølgende brugt som recordset for de to udskrivninger. Det ændrede kun yderst marginalt på tiderne.
Din tese vedr, hvad der tager tid ved databasekaldet, synes med andre ord ikke at holde stik
Der findes vist desværre flere middelmådige udviklere end toptunede udviklere (som dig) i udviklerfaget. Og som repræsentant for en af de første, har jeg ofte den følelse, at jeg bare skal finde en løsning, som fungerer tilfredsstillende lige nu og så komme videre med alle de andre udfordringer...
Der er da overhovedet ingen tvivl om, at jeg til hver en tid vil vælge den løsning som er bedst (ifølge min aktuelle viden), men jeg er bare ikke så flittig som dig til at undersøge standarder og best practices for alt hvad jeg laver - det er jeg bare ikke intelligent nok til. Med den erkendelse, må jeg så nøjes med det jeg har tid til at lære og se om jeg kan klare mine opgaver på det grundlag :-)
[div]$sql = "SELECT `<tr><td>` + ip + `</td><td>` + ref + `</td></td>` + agent + `</td><td>` + stamp + `</td></tr>` AS htmldata FROM `hits` LIMIT 300"{/div] Du kan nok konsekvensrette sætningen, så det bliver MySQL'sk.
Her flyttes problemstillingen naturligvis bare længere ned/ind i serverarkitekturen (hvilket jo stadig ikke ønskværdigt), men bare for eksperimentets skyld - hvis du eller gider... :-)
Jeg har lavet nogle tests med ASP 3.0 med VBS op mod en SQL Server. Her kan man umiddelbart hente en del i forbindelse med generering af HTML-strengen, ved at kalde GetString på recordsetobjektet, dvs. en faktor 2½-3 i forhold til iterering med array og join (á la eksemplet fra indlæg #8 vedr. html-genereringen). Hvis jeg lagde noget af strenggenereringen over i SQL-sætningen i kombo med GetString, var tendensen, at der var en smule mere at hente (mellem 0 og 25% ifht. getstring på en normal feltliste, men givetvis ikke det store reelt set).
Jeg ved ikke om der findes en komponent til ASP 3.0, som kan generere outputtet i JSON, men man kan altså med standard serverkomponenter (ADO) også hente noget performance, trods alt :-)
- men det er stadig kun serverarbejdet, vi taler om. HTML strengen er væsentligt længere end JSON strengen - og hvis du vælger mysql_fetch_row, kan du endda spare feltnavnene i hver række (= en ofte meget stor andel af data, sparet). Det betyder væsentligt mindre transport.
Når vi ankommer til browseren, findes der som sagt ikke en valid metode til indsættelse af HTML på strengform. Metoden, som ikke er valid, men som trods alt virker, har en lang række uhensigtsmæssigheder, som i fremtiden binder koderen til at bruge jQuery til stort set alt - og det bliver vanskeligt at overskue, hvad han kan undlade at bruge jQuery til.
Det værste er dog, at koderen tvinger andre kodere, som evt. senere skal overtage koden, til at bruge ét bestemt library til al DOM-manipulation. Muligheden for udvidelser af koden ved brug af alm. DOM/JavaScript vil ofte være stærkt begrænset. Det er ikke, hvad jeg forstår ved god, hensigtsmæssig og professionel kode.
Jeg er som sagt ikke tilhænger af JSON. Jeg er modstander af kode, *) som bruger unødigt mange server ressourcer *) hvor data fylder (dramatisk) meget mere end nødvendigt under transport *) som involverer invalid kode *) som beværlig- og/eller umuliggør brug af valid og gængs kode, der burde forventes at kunne anvendes overalt *) som er så proprietært i sin syntaks, at det afholder brugeren fra efterhånden at lære at bruge alm. DOM og JavaScript
Endvidere bruger jQuery $ som navnet på dets mest centrale funktion. I følge ECMA bør $ ikke anvendes i funktions- og variablenavne, da det primært er forbeholdt maskinkode. Med det menes f.eks:
var s = "OleBole"; (/(le)/g).test(s); alert(RegExp.$1);
Det er ikke decideret ulovligt at bruge $ til andet, men langtfra hensigtsmæssigt.
Med alt det vil jeg gerne slå fast, at jeg ikke bare er religiøs modstander af innerHTML, eller religiøs tilhænger af JSON - men når jeg har mulighed for at vælge god og hensigtsmæssig kode, er valget let for mig ;o)
En frysepizza 'does the job' for 'kokken'. Den fylder sækken op hos den spisende, men er ikke noget, jeg forventer fra en rigtig kok på en ordentlig restaurant. I mine øjne er jQuery (og mange lign. libs) WWW's svar på frysepizzaen! =)
Jeg synes det er rigtig fint at være rendyrket og professionel i sin måde at lave tingene på og det har jeg stor respekt for.
Som jeg indikerede i et tidligere indlæg, er jeg ikke en af dem der har resurser til at gøre tingene 100% korrekt hver gang, men derimod er nød til at finde en løsning, som er tilfredsstillende under de aktuelle omstændigheder. Dette kan have mange årsager, men faktum er bare, at jQuery, for mit vedkommende, løser en masse udfordringer med crossbrowserkode, som jeg ellers skulle bruge en masse krudt på at fatte - det nedprioriterer jeg til fordel for en masse anden viden, som jeg også har brug for at tilegne mig og som jeg ikke har nogen umiddelbare løsninger til.
Det lyder som om du mener, at professionalisme alene er et spørgsmål om at vide alt om det du arbejder med.
Har det ingen betydning, hvordan man tilgår en opgave og har sans for situationen (herunder de begrænsninger man selv har og de rammer man arbejder indenfor)?
For mig omhandler professionisme i ligeså høj grad købmandsskab og evnen til at gennemskue opgaven og de behov som er strengt nødvendige at opfylde, samt hvilke ting der er rare at have og gøre, men ikke strengt nødvendige for at tingene kommer til at fungere.
Jeg er stor tilhænger af kode og arkitektur, som er let at vedligeholde og læse (hvem er ikke det?) og jeg forsøger da til stadighed at få min egen til at følge nogle standarder (ikke nødvendigvis officielle), som jeg kan leve med over tid.
Jeg er også stor tilhænger af optimale løsninger og bruger da også en del tid på at optimere de systemer jeg sidder og arbejder med til daglig. Jeg går dog sjældent en større omvej for at finde ud af, om en løsning kan give performanceproblemer (men jeg fornemmer det jo nok erfaringsmæssigt i mange tilfælde). Her vurderer jeg typisk, om det er noget som hurtigt vil blive et problem og om det er de ekstra timer værd at bekymre sig om det her og nu, eller om det skal på en todo-liste til senere. Ofte bestemmer jeg heller ikke selv om der skal bruges energi på en ting eller ej - uanset om jeg så anbefaler strakshandling på det kraftigste... :-)
Anyway! Nok klynkeri - det er vel rent faktisk snart hagger's tur til at give en tilbagemelding :-)
Kan man ikke lave en nogenlunde tilsvarende kode bare hvor man ikke kan se at den opdatere hvert 3. sekund? Og hvis i har koden vil det ikke gøre spor..
Hvis du rent faktisk mener at dit problem ikke blev løst og du ikke kan bruge den foreslåede løsning, så må du lige prøve at være lidt mere specifik om, hvorfor den løsning ikke kan bruges...
Det er dog en svært irritabel måde at svare på. Jeg spørger naturligvis efter en uddybning, fordi jeg netop mener, at det jeg foreslår i #3 rent faktisk giver dig et alternativ til det du efterspørger...
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
