Sammen med ASP i en chat

Kliklyden kan du ikke gøre noget ved.

Hvad er det helt præcis du gerne vil have hjælpe til i den der iframe?

Du bruger iframen til at hente chatbeskeder siden sidste opdatering af chatvinduet, eller hvad? Hvad har du i hovedvinduet som skal opdateres?

<ole>

iframen skal bare opdateres med location.reload(true), så giver IE ikke lyd fra sig  :)

/mvh
</bole>

- og så er Applications ikke en god idé, hvis man er interesseret i performance ... og performance er jo uden sammenligning det aller vigtigste parameter, når man skriver en chat  ;o)

I så fald undskylder jeg min hurtige konklusion :)

Ok. Det vil sige at det er hurtigere at skrive og hente fra en DB frem for Applications.??????  Havde da bestemt troet at det var lige modsat..??


Når men så lad os da antage at jeg bruger DB istedet.
Hvordan får jeg så det lille skjulte iframe til at vide når der er skrevet en ny besked, og opdatere main framet..???

Det er du nok nød til at spørge serveren om i et rimeligt interval, dvs. genindlæse iframen...

Hvis du skal skrive noget til Application er du nød til at kalde Application.Lock for at være sikker på at der ikke er andre som skriver oveni det du lige have opdateret. Application.Lock låser altså adgang til hele application-objektet mens der bliver skrevet beskeder i det, hvilket jo kan være katastrofalt for performance, idet dem der gerne vil skrive så må stille sig i én lang kø...

Ja det er rigtigt nok.
Men hvis man så bruger Db kan bruge noget JavaScripts med innerHTML, getElementById osv...
Men de eksempler jeg fandt på det var med PHP, og det sprog fatter jeg ikke så meget af...

Anyway! Hvis vi skal snakke konkrete løsningsforslag, så kunne jeg forestille mig at du på serveren registrere hvilket rum den aktuelle bruger er logget ind i (f.eks. i en session-variabel), samt hvornår brugeren sidst har hentet chatbeskeder fra databasen. Disse informationer skal du bruge til at hente de beskeder som brugeren skal have at se ved næste opdatering...

Siden som genindlæses i iframen kunne så indeholde noget javascript som (på onload-eventet) kalder tilbage til parent-framen, til en funktion som sørger for at aflæse de nye værdier (f.eks. variable i den frame der lige er blevet indlæst) og opdatere dit chat-miljø...

Forældervinduet sætter så næste tidspunkt for opdatering af iframen når vinduet er opdateret -  og hele processen starter forfra.

Har du erfaring med nogen server-teknologier overhovedet, f.eks. ASP?

Ja jeg har en del erfaring med ASP, det er javascripts jeg er lidt nybegynder på

De klient-scripts, du skal anvende, er præcis de samme under PHP og ASP. Det er vigtigt, du ikke formaterer en hel masse HTML på serveren. Du skal kun sende data ned til browseren - og så lade denne formatere HTML'en og indsætte den med DOM.

Skal du lave en ordentlig chat, kræver det, du er rigtig stærk i JavaScript, CSS og DOM  :)

Hehe, Ja så får jeg et problem, har aldrig hørt om DOM

Ja, det har du i højeste grad  :)

Ok, men hvis der ikke er forskel på måden i ASP og PHP, er der så nogen der vil oversætte det her til ASP..??

'<?while($row = mysql_fetch_array($getmsg)){print $row[sender].": ".$row[msg];}?>';
Taget fra spørgsmål 367872 ... Hvis den metode virker i PHP, så må den efter det i siger også virke i ASP, jeg kan bare ikke se hvordan ...

Det er sådan set det eneste jeg vil. Jeg vil bare have at det skjulte iframe jeg har der opdatere hver 3 sec, selv finder ud af hvornår det er tid til at updatere main iframet

Jeg er ikke PHP-programmør, men det betyder vel bare

do while not rs.eof
  response.write rs("sender") & ": " & rs("msg") & "<br>"
  rs.movenext
loop

Ja det tænkte jeg også på, men så tænkte jeg igen at hvordan skulle man kunne Loope en string og så få et JavaScript uden Loop til at udskrive det. Det er jo kun stringen der Loopes, og for hver gang den laver en Loop ændre den samme string værdi, uden at den forrige værdi udskrives... Så kan ikke få det til at hænge sammen

chatHTML = '<?while($row    <<<<--- Det er jo bare en JavaScript String

Såvidt jeg kan se på den kode (i det andet spørgsmål) du henviser til, så bliver det der genereres i dette loop lagt i en variabel, der så i din helhed bliver lagt i et HTML-element (et span). I den process bliver det til den tekst der udgør chatteksterne i chatten...

10/11-2005 23:20:52: Ja, men det er de næste 3 linier der er interessante ifht. opdatering af chatvinduet...

Ja det ved jeg. Men stringen ChatHTML skal jo have den rigtige værdi for at updatere

Men, men, men ... Måske er den Loop i PHPen en erstatning på Selecet top 1 fra SQL.
Ved ikke om den findes med MySQL. For som det ser ud, så vil det jo være den sidste record i databasen der bliver værdien i ChatHTML

Det er netop den måde, man ikke bør lave en chat. På serveren udskriver han en streng af HTML og sender den tilbage til browseren.
Her kaldes et script i en synlig frame med HTML-strengen som argument. Denne funktion skriver så strengen ind i siden med noget 'innerHTML' ... men det er som sagt en skidt måde at gøre det på

Nu er formateringen af chatteksterne i dette eksempel ret simpel og det er vel ikke mere krævende at sende disse informationer til klienten, end f.eks. at lave et js-array som man kan arbejde med på klienten. Du skal vel bruge en eller anden form for struktur i de data du sender for at det er til at arbejde videre med og denne form er da ret simpel (som sagt :))...

Ang. "For som det ser ud, så vil det jo være den sidste record i databasen der bliver værdien i ChatHTML", så afhænger det vel lidt af hvormange beskeder der bliver postet i det tidsrum som chatten venter på næste opdatering - mange brugere kan nå at skrive meget på 3 sekunder :)

Ole >> Hvis den måde er meget dårlig, hvilken metode er så god.???

I bund og grund handler det om at minimere resurseforbruget på serveren og på linien og det gør du ved at lave så lidt som muligt på serveren og sende så lidt som muligt på linien... med andre ord, så skal du forestille dig et dataformat til kommunikationen af data mellem server og klient der er så tæt på de essentielle informationer som muligt.

essentielle informationer er det der er behov for at vide om aktuelle chattere, beskeder, herunder tidspunkter, afsender, evt. modtager osv.

Ja men jeg forstår stadig ikke hvordan.
Det er nemt at få ting til at opdatere på bestemte tidspunkter, HVIS det er EN client vi snakker om ad gangen. Men når en client skal skrive, samtidig med at de andre clienter skal have besked om det, så er der ikke noget længere der hedder Sessions, eller Response.Redirect eller noget som helst andet. For alt det vil kun virke på den client som skriver beskeden. Og det er der jeg går tabt. Hvordan får jeg en client til at give andre clienter besked. Serveren giver jo ikke besked før de updatere, og det er jo det der skal køre pr. automatik

I den løsning jeg forestiller mig, spørger hver klient serveren (i et givent interval) om der er sket noget siden sidste opdatering. Denne forspørgsel er baseret på et "checkpoint", som opdateres for hver forspørgsel til serveren. Det betyder at alle nye beskeder siden sidste opdatering hentes og sendes (sammen med et nyt checkpoint) tilbage til klientens skjulte iframe, hvorfra klienten kan aflæse data og opdatere chatvinduet i overensstemmelse med de krav og behov der er for præsentation.

Et checkpoint kan være et en dato/tid angivelse, et fortløbende nummer eller noget andet som kategoriseres kronologisk. Det er vigtigt at det er serveren der udsteder dit checkpoint, da du kan være nogenlunde sikker på at klienterne IKKE er synkroniseret :)

Faktisk bør du nok have dit checkpoint liggende i en session-variabel, da din iframe jo bare bliver genindlæst og derfor ikke kan bære data med tilbage til serveren... men det ændrer som sådan ikke på den funktionalitet jeg snakker om ovenfor.

ja den del har jeg prøvet.
Jeg støder på en mærkelig fejl ved det.
Jeg sætter den til at finde den sidste post ID i basen, og samligner den med en Session der har den tidligere Post ID. Hvis ikke opdateres Main, og den nye ID lægges i den Session.... Problemet er bare at mit skjulte Iframe stopper med at opdatere i det øjeblik jeg gemmer den nye ID i Sessionen. Hvis jeg fjerner den del hvor IDen gemmes i min session, så opdatere den hele tiden. Men så stopper den til gengæld ikke selvom det er den samme post som tidligere

Nu er jeg ny med JavaScripts. Men i forhold til ASP er det jo et Client sprog, der har den mulighed at konstant afvikle sig uden updatering fra serveren.

Er det så ikke muligt at lave en JS kode som tjekker om der er sket ændringer, og så få KUN det lille stykke kode til at konstant afvikle hvert 3 sec f.eks...???

JS kan jo afvikles uden at resten af siden behøver at refreshe

<script language="JavaScript">
function UpdateFrame() {

parent.ChatMain.location = 'Main.asp';
test()

}


function test() {
setTimeout('UpdateFrame()',3000);
}
</script>

Nu har jeg afprøvet noget her, og det virker fint. Kan man ikke bruge det på en måde så..????

Eller det kan man vel ikke med mindre JS havde muligheden for at tjekke en DB :(

Jo, det ser ikke helt forkert ud, men hvis du ville undgå kliklyden, så skulle du måske benytte reload(true) på location i stedet for...:

<script language="JavaScript">
function UpdateFrame() {
  parent.ChatMain.location.reload(true);
  test();
}

function test() {
  setTimeout('UpdateFrame()',3000);
}
</script>


Med denne metode kan du risikere to forspørgsler bliver sendt til serveren oveni hinanden (hvis en forspørgsel tager lang tid pga. en travl server)...

...hvis altså det er ChatMain der spørger serveren om hvad der er sket siden sidst.

Ja men det er jo også ligemeget om der kommer to oveni.
Sagen er at hvis man nu kørte en JS som tjekkede den sidste ID i databasen, og den ikke stemte overens med den i en String/Session eller noget andet, så opdaterede den main. Om der så imellem tiden kommer en mere så betyder det ikke noget, for main ville stadig blive opdateret, også begge nye beskeder ville stå der.

F.eks.

Den gemte string eller noget har en værdi på 1
Den ny hentede ID har en værdi på 2
Den ID der kom oveni har en værdi på 3.... Ville ikke betyde noget da den første og den hentede på 1 og 2 ikke stemmer overens. Og skulle det overlappe på en meget usansynlig måde, så opdatere den jo alligevel efter 3sec. igen

Men jeg kan se at det er muligt med JS og MySQL. Så er det bare lige om Access også virker sammen med

Først og fremmest er det ikke ligemeget om der bliver lavet to requests oveni hinanden, da du risikerer at miste beskeder, hvis klienten ikke når at opdatere de data der er på vej igennem...

En client kan vel bruge en DB samtidig med en anden..???? På samme tid..???
Ellers har folk med flere 100 brugere da et problem...

Det har ikke noget med databasen at gøre. Det har noget med session-variablen at gøre, for hvis den er opdateret og beskeder er på vej til klienten, og så du opdaterer din iframe inden data er nået helt frem, så mister du de data (idet session-variablen er opdateret med det nye id på dette tidspunkt) - derfor.

Ja, men dette opdateres jo stadig igen efter 3 sec.
Sådan vil det hele tiden være. Ligemeget hvad. Hvis man bruge et skjult Iframe som opdatere hvert 3 sec, og holder på en eller anden måde øje med hvornår main skal opdatere, kan du risikere at man lige nøjagtig mister en besked i samme øjeblik som main opdateres

Hvormeget information har du tænkt dig at hente ved hver opdatering?

IDen fra den sidste record

Kan ikke se hvordan jeg ellers skal forklare de andre clienter at deres main ikke er up to date

Jeg synes ikke helt jeg kan følge den løsning du snakker om... vi tager muligvis ikke udgangspunkt i samme arkitektur (synes jeg noget kunne tyde på). Såvidt jeg kan se, så kommer du da til at mangle dine beskeder hvis du kun vil hente ID fra serveren...?

Jeg forestiller mig noget i stil med dette på serveren:

databasen indeholder en tabel med beskeder med flg. opbygning:
  beskeder =
      ID
    + besked
    + afsender

min chat serverkode skal i bund og grund kunne 2 ting:

1. hente beskeder siden et checkpoint
2. indsætte en besked via nogle form-felter + pkt. 1


På klienten forestiller jeg mig flg. setup:

En formular som indeholder et textarea til at indtaste beskeder og en submitknap til at sende beskeden til serveren. Derudover er der et chatområde som indeholder beskeder skrevet indtil nu (siden logon f.eks.).
Sidste men ikke mindst er der en iframe som sørger for at sende og hente beskeder til hhv. fra serveren.

Når man skriver en besked i tekstfeltet, og trykker send, så postes den aktuelle form til iframe-elementet og serveren modtager beskeden om at der skal indsættes data (hvilket den så gør). Derefter redirecter den siden til den funktion der henter data og returnerer dette til iframe-elementet. Data hentes ved at aflæse session("lastread"), som indeholder det sidste ID der blev læst fra databasen og så læser den alle beskeder med et ID der er større end det og genererer data til klienten ud fra disse. Der kan godt være tale om mange beskeder, så det genereres i en løkke. Til sidst opdateres session("lastread") med det sidste ID som blev læst i denne omgang og siden sendes.

Klienten modtager data i iframe-elementet og den side som lige er loaded i iframe-elementet kalder en funktion (via et script som sendes med i den side som serveren genererer) på klientens chatside, som sørger for at hente data ud af den side som lige er indlæst i iframe-elementet. Disse data opdateres chatsiden så med. Til sidste sættes næste timeout for opdatering af chatvindue og så er der bare at vente til næste opdatering starter hele møllen igen...

Som jeg ser det, arbejder internet på to vejs kommunikation.
Browseren sender en request til serveren, som sender en response til Browseren.
Det vil sige at begge parter kan snakke sammen. Så må det også være muligt for en server at give en browser besked om at det er tid til at den opdatere, uden brug af Refresh og skjulte frames metoder.

Og selvf er det muligt. Mange store sider bruger det. Sagen er bare hvilke sprog der har mulighed for det....

Men fandt en forløbig mulighed til det skjulte frame.
Når en besked indtastes opdateres en ID i en Application....

Det må gå intil videre....

Men smid et svar. og så takker jeg for din tid :)

Naturligvis kan det lade sig gøre, men med et traditionelt klient/webserver-setup er det ikke normalt...

Man kan sagtens lave en server (f.eks. chat) som kan snakke sammen med en eller flere klienter, men så er du ude i noget med en java-class (og altså ikke noget javascript som du lagde op til i dit spørgsmål) på klienten og en server som hver især lytter til porte og registrerer IP-adresser for at kunne kontakte hinanden efter behov - altså ikke den sædvanlige afkoblede måde en webserver fungerer på.

Tja jeg ved at Java og javascripts slet ikke har noget med hinanden at gøre. Jeg ved ikke helt hvordan det udover det, men tror ikke lige det er noget jeg kommer ind på forløbig...

Jeg står selv overfor samme udfordring, men har også i første omgang valgt at basere chatsystemet på javascript og HTML i samspil med et alm. webserver-setup (ASP på serveren). Jeg synes dog det kunne være spændende at kaste sig ud i en Java-class der spiller sammen med noget .NET på serveren... :)

Anyway! Tak for point :)