Brugere Online!

Jeg gider ikke lige forklare hvordan man kan gøre det, for en halv time senere (ca.) kommer en eller anden med et færdigt script, som du vælger at bruge.

Tager jeg fejl, kan du bare sige til.

Du får nok de bedste med en db :/

myplacedk> Jeg ville gerne give ham scriptet hvis han satte pointantallet ned til 15 eller 30...

Der er en her:
http://www.asp.dk/sources.asp?mode=view_source&cat_id=0&id=1494&tech_id=2

Jeg ved ikke om den bruger database eller noget, men du kan jo tjekke den ud...

Jeg vil gerne høre det myplacedk hvis du gider?

Ok... Jeg sætter det ned. Kan dog ikke se hvorfor...

okay... det kan man så ikke... Lige meget så....

aslan > OK, du får den korte, sig til hvis du ikke selv kan fylde alle hullerne ud.

For det første kan det slet ikke lade sig gøre at se, hvor mange der er online. Du kan kun se hvornår folk går ind på en side, ikke hvornår den bliver forladt igen.

Derfor er den rigtige betegnelse egenlig \"Antal unikke brugere de sidste 10 minutter\", eller hvilken tid man nu vælger (kommer lidt an på indholdet).

Hver gang nogen ser en side skriver du så ned hvornår det var, og et eller andet der kan identificere den besøgende. Det kan godt bare være ip-adressen. Det kan være i en database, en fil, eller noget helt andet. Men databasen er det nemmeste, hvis man har muligheden.
Hvis brugeren allerede er skrevet, er det bedst at overskrive. Ellers skal man huske at fjerne \"dubletter\" senere.

Når du skal bruge tallet henter du så bare antal (unikke) brugere, hvor tidstemplet ikke er mere end fx. 10 minutter gammelt.

Husk at slette \"de gamle brugere\" en gang i mellem. Fx. hver gang der kommer en ny. Det gør ikke noget at de er der (hvis du kun ser på de nyeste), men med tiden vil det fylde godt op.

guybrush_lj > Når emnet er uddebateret lægger du selv et svar. Under \"accepter svar\" kan du så vælge hvor mange point der skal gå til hver. Der giver du højest 60 point pr. person, og resten til dig selv.

Formålet er, at undgå inflation i pointsystemet.

Hvad hvis en bruger beslutter sig for at blive i længere tid end \" 10 min\" så er han på den måde du forklarer det på \"ikke\" online?

\"blive i længere tid\" ...på den samme side, that is. Hver gang man går ind på en ny side \"nulstilles tælleren\".

Men ja, du kan ikke gøre andet end at gætte hvor lang tid man gennemsnitligt er på en side, og så bruge det tal.

ahh got it! Sålænge personen roder rundt inde på hjemmesiden må han jo stadig være der:)Tak for en god forklaring!

myplacedk> Du kan da sagtens se hvornår folk forlader en side. Kender du funktionen onunload?

Det var så lidt. :)
Og den forklaring holder uanset om man bruger PHP, ASP, JSP, Perl eller hvad det nu ellers kan være.

el_barto > Ja. Og hvis du lægger den slags ind på en side jeg bruger meget, så brækker jeg nakken på dig! ;-)
Det er en *meget* uprofessionel løsning, og træls for brugerne. Den har ingen fordele som er store nok til at opveje de enorme ulemper.

myplacedk> hvilke ulemper ser du ved onunload? Og hvad er det der er \"træls\" for brugerne?

el_barto > Argh...
Så vidt jeg ved er det nødvendigt at lave en popup. Man kan gøre den lille, og man kan få den til at forsvinde meget hurtigt igen. Men det er møg-træls at se på.

En anden ting er, at du lader klienten give dig oplysninger. Man kan *ikke* stole på oplysninger fra klienten. Du kan i det hele taget ikke stole på overhovedet af få nogen oplysninger.

Hold det serverside, så har du styr på hvad der sker.

el_barto > Forresten, onUnload bliver aktiveret uanset om du forlader sitet, eller bare går til en anden side. For at undgå det må du bruge frames.
Frames? Need I say more?

myplacedk> Nu vil du vel også rakke ned på frames?

Enhver programmeringsopgave er som alt andet arbejde her i livet. Man må gøre sig klart hvad man ønsker at opnå, og ikke skære nogle muligheder væk på forhånd. Det burde du da vide.

Frames kan være nyttige til mange ting, og sammen med onbodyunload kan det næstent alt det som du ikke kan lave serverside.

Serverside scripting afhænger af at en klient aktiverer det. Scripting på klientsiden er umuligt at komme udenom i f.eks. en chat der skal fungere bare nogenlunde hurtigt.

> Nu vil du vel også rakke ned på frames?

Frames er sådan set gode nok til det, man ikke kan gøre på andre måder.
Frames skal *kun* bruges, når det er absolut nødvendigt!
Oftest ødelægger frames *meget* mere, end det gavner.

> ikke skære nogle muligheder væk på forhånd.

Det gør jeg skam heller ikke. Næsten ikke. Visse ting er udelukket fra starten.
Ligesom gaffatape hos mekanikeren. Det skal altså svejses, skrues osv. Hvis alt andet mislykkes, *så* kan man vende tilbage til tapen. Men godt bliver det aldrig.

> Serverside scripting afhænger af at en klient aktiverer
> det. Scripting på klientsiden er umuligt at komme udenom

Lige præcis. Bare omvendt. Det var en fejl, ik\'?

> i f.eks. en chat der skal fungere bare nogenlunde hurtigt.
A hva\'?

gå nu i seng med dig. Jeg mente det jeg skrev, og hvert et ord.

Medmindre du har råd til cron jobs kan serverside scripting da kun aktiveres af en bruger.

Og jeg mener stadig at DHTML er umuligt at komme udenom hvis du skal lave en chat der ikke flimrer osv. At du ikke forstår hvad jeg skriver må skyldes dine manglende evne til at forstå og bearbejde informationer.

Jeg er mundlam!!

> Jeg mente det jeg skrev

Okay, så prøver vi igen.

> Serverside scripting afhænger af at en klient aktiverer
> det.

Nej. Det er bare én måde at aktivere det. Det kan gøres med cron, at el. lign, det kan gøres med email osv. Kun fantasien sætter grænser.

> Scripting på klientsiden er umuligt at komme udenom

Scripting på klientsiden er det eneste du overhovedet kan komme uden om. Og det er helt vildt nemt, da du jo altid har kildekoden. Og du kan enda redigere i det som du vil.
Det er så tæske-nemt at sige til server:
\"Hey, dette er *ikke* et program skrevet af en hacker, det er MS Internet Explorer der kommer på banen her! Og det javascript jeg hentede hos dig for et øjeblik siden (*fnis*) gav følgende resultat (og det er ikke noget jeg finder på)\"
Og serveren vil tro på det. Der er ingen måde serveren kan se forskel på.

Serveren der imod kan du kun pille ved, ved at cracke dig ind i den, eller ved at være admin.
Du har ingen adgang til programmerne på den, du kan ikke engang se kildekoden.
Alt dette selvfølgelig med undtagelse af, hvis admin lader dig.

> Medmindre du har råd til cron jobs kan serverside scripting da kun aktiveres af en bruger.
Råd til?
Anyway, hvis ikke der er en bruger, bliver der ikke udført noget som helst klientside. Og så er der ikke noget at vælge imellem.

> Og jeg mener stadig at DHTML er umuligt at komme udenom hvis du skal lave en chat der ikke flimrer osv.
Hver ting til sin tid. Visse ting kan kun gøres på klienten, og så skal det selvfølgelig gøres der. Der er skam ikke få sjov at clientside scripting overhovedet blev opfundet.

Jeg arbejder selv lidt på en chat, som er helt afhængig af javascript og dhtml. Netop fordi her en opgave, der skal løses på klienten.

Du tager sætninger ud af en kontekst, og så er det jo nemt at få det til at lyde som noget sludder.

Du fik sætningen

\"Serverside scripting afhænger af at en klient aktiverer det. Scripting på klientsiden er umuligt at komme udenom i f.eks. en chat der skal fungere bare nogenlunde hurtigt.\"

til at blive til

\"Serverside scripting afhænger af at en klient aktiverer det.\"

og

\"Scripting på klientsiden er umuligt at komme udenom\"

Er du selv stolt af det?

Næh, jeg ved ikke hvordan det ellers skulle forstås?