Olen yrittänyt etsiskellä tietoa, millä tavalla olisi järkevintä toteuttaa uudesta viestistä ilmoittava vilkkuvalo sivuston yläreunaan. Ilmeisesti ajax ja javascript, tai jquery ovat ne ainakin helpoimmat, mutta niidenkin kanssa olen vähän ongelmissa, koska ainoa kokemus niistä sisältyy muutamaan javascript kikkareen copypastetukseen. Lisäksi kaikki esimerkit mitä olen löytänyt, eivät joko sisällä sivuston reaaliaikaista päivittämistä, tai ovat niin monimutkaisia että aivot menevät solmuun.
Tällähetkellä olen käyttänyt huonoa tapaa, eli valon paikalla on iframe, ja siihen ladataan sivu joka sisältää oheisen koodin:
<html><head><title>valo</title> <META HTTP-EQUIV="Refresh" CONTENT="10; URL="paivitysnappi.php"> </head><body marginheight="0" marginwidth="0" topmargin="0" leftmargin="0" bottommargin="0" rightmargin="0"> <?php session_start(); $viestinumero_last_read = ""; if (isset($_SESSION['viestinumero_last_read'])) $viestinumero_last_read = $_SESSION['viestinumero_last_read']; $viestinumero_last_insert = file_get_contents("lastinsert.txt"); if ($viestinumero_last_insert > $viestinumero_last_read){ $merkkivalo = "images/flashing.gif"; } else { $merkkivalo = "images/passive.gif"; } echo '<a href="index.php" target="_parent"><img src="'.$merkkivalo.'" width="28" height="28" border="0"></a>'; ?> </table></body></html>
Sivu päivittyy siis 10 sekunnin välein, ja vertaa sessioniin tallennettua viimeisimmän luetun viestin numeroa serverillä olevaan tekstitiedostoon, jossa on viimeisimmän lisätyn viestin numero. Jos tämä on kasvanut, eli on suurempi kuin luettu, aletaan sammuneen valon paikalla näyttämään vilkkuvaa valoa, ja sitä klikatessa sivu päivittyy.
Luulisin että tällainen yksinkertainen vertailu on helppo tehdä uusillakin ohjelmointikielillä, kunhan vain esimerkit olisivat yhtä yksinkertaisia. En vain ole päässyt asiassa oikein mitenkään liikkeelle vaikka olen pari iltaa asiaa pyöritellyt. Tietysti opiskelemalla javascriptit/jqueryt ja ajaxit homma selviää mutta kun minulla ei tällähetkellä ole tiedossa muuta käyttöä sivustolla näille, niin ajattelin kysellä vähän osviittaa etten lähde turhaan hakemaan ratkaisua väärältä suunnalta.
iframea nyt ei kannata varmaan alkaa haukkumaan, olisihan se ehkä ihan toimiva jos toimisi, mutta jostain syystä sonyn android puhelimen selain kaatuu jos kesken selailun iframe alkaa päivittämään itseään... Muutenkin sen vilkkuminen päivityksen yhteydessä ja hiiren tiimalasit alkavat kalvamaan hermoja.
Tässä nopeasti koodattu ja testaamaton ratkaisu.
Ajax tarkoittaa siis HTTP-kyselyiden tekemistä JavaScriptillä ilman sivun uudelleenlatausta. Näitä kyselyitä varten kannattaa tehdä erillinen PHP-tiedosto, joka ei tulosta HTML:ää vaan pelkästään JavaScriptin tarvitseman datan yksinkertaisessa muodossa. JSON on hyvä.
Tee tiedosto ajax.php:
<?php session_start(); $last_read = @$_SESSION['viestinumero_last_read']; $last_insert = file_get_contents("lastinsert.txt"); $lukematon_viesti = $last_insert > $last_read; header('Content-Type: application/json'); echo json_encode(array( 'lukematon_viesti' => $lukematon_viesti ));
Ota jQuery käyttöön:
<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
Korvaa iframe tällä:
<a href="index.php"><img id="merkkivalo" src="images/passive.gif" width="28" height="28"></a>
... ja lisää olla oleva koodi.
$(document).ready(function () {
setInterval(function () {
$.ajax({
url: "ajax.php",
success: paivitaMerkkivalo
});
}, 10000);
});
function paivitaMerkkivalo(tulos) {
var kuva = tulos.lukematon_viesti ? "images/flashing.gif" : "images/passive.gif";
$("img#merkkivalo").attr("src", kuva);
}Sehän toimi kun junan vessa. Syvä kumarrus, en odottanut pääseväni ihan näin helpolla.
Onko muuten väärin kun kopioin http://code.jquery.com/jquery-1.9.1.min.js sisällön luomaani jquery.js tiedostoon, jonka laitoin sitten omalle serverille. Tämä vain siitä syystä, että jotenkin oudoksuttaa se, että sivuston pitää hakea ulkopuoliselta serveriltä tietoa toimiakseen oikein.
Ei ole väärin.
On totta että ei ole väärin.
Näin puskista huudellen voisin kuitenkin mainita... laajasti käytettyjä javascript-kirjastoja kuten jQuery suositaan linkitettäväksi ulkopuoliselta palvelimelta, koska silloin on todennäköistä että se on jo aiemmin jonkin toisen sivun jäljiltä selaimen välimuistissa. Teoriassa nopeuttaa sivun latautumista ja käytännössä vähentää oman palvelimen kuormaa. Tämä kuitenkin on hifistelyä jolla on väliä vasta sitten kun sivulla on satoja tai tuhansia käyttäjiä päivittäin.
Toki, sen ulkopuolisen palvelimen tulee olla se palvelin jota "kaikki muutkin" käyttävät.
tommituura kirjoitti:
On totta että ei ole väärin.
Näin puskista huudellen voisin kuitenkin mainita... laajasti käytettyjä javascript-kirjastoja kuten jQuery suositaan linkitettäväksi ulkopuoliselta palvelimelta, koska silloin on todennäköistä että se on jo aiemmin jonkin toisen sivun jäljiltä selaimen välimuistissa. Teoriassa nopeuttaa sivun latautumista ja käytännössä vähentää oman palvelimen kuormaa. Tämä kuitenkin on hifistelyä jolla on väliä vasta sitten kun sivulla on satoja tai tuhansia käyttäjiä päivittäin.
Toki, sen ulkopuolisen palvelimen tulee olla se palvelin jota "kaikki muutkin" käyttävät.
Entäs jos kirjastoa ei saada ladattua syystä tai toisesta etältä... Riski on varsin pieni, mutta ei varmaan ole sen 0.1 sekunnin arvoinen kuitenkaan.. Niin ja onhan ko. kirjasto aika järkäle, peräti 90.4 kt.
qeijo kirjoitti:
Entäs jos kirjastoa ei saada ladattua syystä tai toisesta etältä...
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="path/to/your/jquery.js"><\/script>')</script>Kuten HTML5 Boilerplaten koodista näkyy, code.jquery.com ei ole ainoa CDN-palvelin, josta jQuery löytyy.
Mä oon kyl kans cdn-palvelimien kannalla. Sen verran monta megaa on itsekin joutunut työn puolesta kopioimaan samaa jQuery-tiedostoa eri asiakkaiden palvelimille.
Samalla tullut nähtyä kaikenlaisia palvelimia, niin 0.1 sekuntia tuntuu välillä kyllä yliammutulta, kun osalla asiakkaista on juuri jotain markan palvelimia, joiden tiedoston haku on juuri sitä luokkaa, että hyvä jos sekunnissakaan kerkiää yhden tiedoston löytämään, oli se sitten 90kt tai 9 megaa.
qeijo kirjoitti:
tommituura kirjoitti:
On totta että ei ole väärin.
Näin puskista huudellen voisin kuitenkin mainita... laajasti käytettyjä javascript-kirjastoja kuten jQuery suositaan linkitettäväksi ulkopuoliselta palvelimelta, koska silloin on todennäköistä että se on jo aiemmin jonkin toisen sivun jäljiltä selaimen välimuistissa. Teoriassa nopeuttaa sivun latautumista ja käytännössä vähentää oman palvelimen kuormaa. Tämä kuitenkin on hifistelyä jolla on väliä vasta sitten kun sivulla on satoja tai tuhansia käyttäjiä päivittäin.
Toki, sen ulkopuolisen palvelimen tulee olla se palvelin jota "kaikki muutkin" käyttävät.
Entäs jos kirjastoa ei saada ladattua syystä tai toisesta etältä... Riski on varsin pieni, mutta ei varmaan ole sen 0.1 sekunnin arvoinen kuitenkaan.. Niin ja onhan ko. kirjasto aika järkäle, peräti 90.4 kt.
Sivuston resurssien (kuvat, skriptit, tyylit) lataaminen rasittaa palvelinta enemmän kuin taustalla suoritettavan php-koodin ajaminen. Pyyntöjen minimointi on ihan hyvä tapa optimoida sivustoa palvelimen näkökulmasta vaikkei se juurikaan vaikuttaisi yksittäisen käyttäjän havaitsemaan suorituskykyyn. Toinen syy onkin oikeastaan juuri seurausta tästä http-pyyntöjen tappamisesta: monesti skriptit bundlataan palvelimelle yhteen tiedostoon sen sijaan, että jokainen kirjasto olisi erillisessä tiedostossa. Tällöin käyttäjä joutuu aluksi lataamaan melko suurenkin määrän dataa kerralla (luokkaa satoja kilotavuja), jolloin paljon js:ää käyttävä sivusto voi "bootata" hitaasti.
Kun yleisimmät kirjastot tulevat jostain keskitetystä cdn-verkosta, niin ei tarvitse bundlata niin paljoa kirjastoja ja se nopeuttaa myös lataamista. Netistä löytyy paljonkin tutkimuksia siitä, miten hitaasti latautuvat sivut aiheuttavat suuren mittakaavan yrityksille jopa miljoonien tulomenetyksiä. (tässä yksi)
jukkah kirjoitti:
Kuten HTML5 Boilerplaten koodista näkyy..
Oliko joku maininnut HTML5 Boilerplaten aikaisemmin tässä keskustelussa vai mistäs sä sen vedit?
Vastasin kysymykseen että ei ole väärin, koska kirjaston hostaus omalla palvelimella ei ole väärin.
Ymmärrän saavutettavan hyödyn (teoreettisen), enkä lähtökohtaisesti vastusta jQueryn lataamisen cdn:n kautta.
Kuitenkaan mikään ei ole täysin mustavalkoista, kuten voimme esim. tuolta käydä lukemassa.
The Alchemist kirjoitti:
Kun yleisimmät kirjastot tulevat jostain keskitetystä cdn-verkosta, niin ei tarvitse bundlata niin paljoa kirjastoja ja se nopeuttaa myös lataamista. Netistä löytyy paljonkin tutkimuksia siitä, miten hitaasti latautuvat sivut aiheuttavat suuren mittakaavan yrityksille jopa miljoonien tulomenetyksiä. (tässä yksi)
Just joo. Hieman perspektiiviä peliin.
The Alchemist kirjoitti:
Pyyntöjen minimointi on ihan hyvä tapa optimoida sivustoa palvelimen näkökulmasta
Jep, monet ei vain tajua, että selain ei oletuksena lataa kuin muutamia tiedostoja kerralla, joten jokainen "tiedoston haku" rokottaa oman aikansa.
edit:
Itse voisin pitää cdn:n käyttöä hyvänä myös ihan tuotantovaiheessa. Jqueryä ei tarvitse alkaa lataileen ja tallenteleen omalle palvelimelleen, vaan skriptan sijoittaminen onnistuu "aina saman rimpsun" copy/pasteemisella. Tietenkin tällöin pitää ottaa huomioon skriptien versiointi.
Lebe80 kirjoitti:
Itse voisin pitää cdn:n käyttöä hyvänä myös ihan tuotantovaiheessa. Jqueryä ei tarvitse alkaa lataileen ja tallenteleen omalle palvelimelleen, vaan skriptan sijoittaminen onnistuu "aina saman rimpsun" copy/pasteemisella. Tietenkin tällöin pitää ottaa huomioon skriptien versiointi.
Kytkemällä projekti kehitysvaiheessa riippuvaiseksi cdn - palvelimesta, teet työskentelyn offline tilassa hankalaksi. Puhumattakaan päättömistä "latest" - tyyppisistä hostauksista tuotantokäytössä.
Lopuksi, (puolitosissaan) sen verran foliohattugeeniä pitää olla, että harkitsee pari kertaa ennen kuin käyttää 3 osapuolen kikkareita. VARSINKIN kun kyseessä on esim. Google inc. cdn - palvelu.
Haluaako Google hyvää hyvyyttään tarjota ilmaisen palvelun jotta sivustosi olisi nopeampi, vai onko kaikki yhtä suurta trakkeri - salaliittoa! CIA lukee tämän viestin varmasti ja tulee hakemaan minut.
Summa summarum, nämä teoreettiset mikroskooppiset nopeuserot ovat meidän tasolla mielestäni hifistelyä.
Tässäkin esimerkissä on mahdottomasti iloa siitä, kun on vähennettu resurssien lataukset ulkoistamalla jQuery hostaus. Mahdollinen hyöty on ehkä 0.1 sekuntia, huom. vain jos cdn - hostaama kirjasto on jo välimustissa, ja ainoastaan ensimmäisellä sivulatauksella.
Putkan lähdekoodi kirjoitti:
<link rel="stylesheet" href="/css/perustyylit.css?t=20121026131208" type="text/css" /> <link rel="stylesheet" href="/css/asettelu.css?t=20120630170820" type="text/css" /> <link rel="stylesheet" href="/css/sivupalkki.css?t=20120915114611" type="text/css" /> <link rel="stylesheet" href="/css/viestit.css?t=20111224023600" type="text/css" /> <link rel="stylesheet" href="/css/varit-harmaa.css?t=20121026132929" type="text/css" /> <link rel="stylesheet" href="/css/koodit.css?t=20130209155005" type="text/css" /> <link rel="stylesheet" media="print" href="/css/print.css?t=20110731220319" /> <script src="/js-jquery/json2.min.js?t=20111213192743"></script> <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script> <script src="/js-jquery/ohjelmointiputka.js?t=20130217191718"></script> <script src="/js-jquery/sivupalkki.js?t=20120915114651" defer="defer"></script> <script src="/js-jquery/tyokalut.js?t=20111213140531" defer="defer"></script> <script src="/js-jquery/muotoilunapit.js?t=20130209160736" defer="defer"></script> <script src="/js-jquery/input.date.js?t=20111213191943" defer="defer"></script> <script src="/js-jquery/input.time.js?t=20111219175552" defer="defer"></script> <script src="/js-jquery/muotoilu.js?t=20120308180754" defer="defer"></script> <script src="/js-jquery/textarea.tabit.js?t=20111213140533" defer="defer"></script> <script src="/js-jquery/tuplalahetys.js?t=20121208115017" defer="defer"></script> <script src="/js-jquery/poistumisvahvistus.js?t=20121218192229" defer="defer"></script> <script src="/js-jquery/esikatselu.js?t=20121209131900" defer="defer"></script> <script src="/js-jquery/lainaus.js?t=20120404213126" defer="defer"></script> <script src="/js-jquery/muokkaus.js?t=20130115214401" defer="defer"></script> <script src="/js-jquery/ajaxpaivitys.js?t=20130406161623" defer="defer"></script> <script src="/js-jquery/korvausefekti.js?t=20130217194007" defer="defer"></script> <script src="/js-jquery/asetussivu.js?t=20111213172718" defer="defer"></script>
qeijo kirjoitti:
Kytkemällä projekti kehitysvaiheessa riippuvaiseksi cdn - palvelimesta, teet työskentelyn offline tilassa hankalaksi.
Voisitko kertoa, miksi minun pitää tehdä offline-tilassa töitä?
Lebe80 kirjoitti:
qeijo kirjoitti:
Kytkemällä projekti kehitysvaiheessa riippuvaiseksi cdn - palvelimesta, teet työskentelyn offline tilassa hankalaksi.
Voisitko kertoa, millä tavalla työskentely on hankalaa?
Kirjaston hakeminen cdn - palvelimelta voi osoittautua hankalaksi ilman verkkoyhteyttä. En siis nyt puhu mistään loppukäyttäjän HTML 5 offline asioista, vaan sovelluksen kehittämisestä offline - tilassa, eli työskentely ilman Internet yhteyttä.
Edit: hups luin viestisi väärin (jaa.. En lukenutkaan, muutit olennaisesti kysymystä vastaukseni jälkeen)
Lisäys
En näköjään ollutkaan ihan hullu(siinä asiassa), katso alkuperäistä lainausta.
Vastaus uuteen/muutettuun kysymykseen
Lebe80 kirjoitti:
qeijo kirjoitti:
Kytkemällä projekti kehitysvaiheessa riippuvaiseksi cdn - palvelimesta, teet työskentelyn offline tilassa hankalaksi.
Voisitko kertoa, miksi minun pitää tehdä offline-tilassa töitä?
Et mistään syystä koska se ei sinun setupilla onnistuisi.
Täytyy kyllä sanoa, että työskentely ilman nettiyhteyttä on yllättävän hankalaa. Totesin tänään sen kun tein läppärillä töitä bussissa ja olin unohtanut kännykän.
Itsehän käytän paikallisia kirjastoja kehitysympäristössä ja cdn:ää tuotannossa. Problem solved!
Lisäys:
qeijo kirjoitti:
The Alchemist kirjoitti:
Kun yleisimmät kirjastot tulevat jostain keskitetystä cdn-verkosta, niin ei tarvitse bundlata niin paljoa kirjastoja ja se nopeuttaa myös lataamista. Netistä löytyy paljonkin tutkimuksia siitä, miten hitaasti latautuvat sivut aiheuttavat suuren mittakaavan yrityksille jopa miljoonien tulomenetyksiä. (tässä yksi)
Just joo. Hieman perspektiiviä peliin.
Ihmisten täytyy ymmärtää syyt tekojen takana, jotta jokainen voi puntaroida, milloin kannattaa tehdä tiettyjä asioita. Tietynlaisen koodin tekemistä tekemisen vuoksi (koska joku muu teki niin ensin) kutsutaan cargo cult -koodaamiseksi. Vaikkei tämä ole suoranaisesti ohjelmointia, niin se liittyy hyvin olennaisesti sovelluskehitykseen ja järjestelmänhallintaan.
Omien pienten kotisivujen takia ei välttämättä jaksa lähteä säätämään joka kerta koodia päivittäessä "tuotantoon" eri filuja kehitysympäristöön verrattuna, mutta eikös meistä moni haluaisi isona ihan tehdä leipänsä koodaamalla? Silloin joutuu melkein automaattisesti (web-puolella) puljaamaan suurempien käyttäjämäärien kanssa, joten on hyvä tietää jotain optimoinnista.
qeijo kirjoitti:
jukkah kirjoitti:
Kuten HTML5 Boilerplaten koodista näkyy..
Oliko joku maininnut HTML5 Boilerplaten aikaisemmin tässä keskustelussa vai mistäs sä sen vedit?
Minä kahta riviä ylempänä. Koodi oli copy-pastea H5BP:stä.
Sen verran vielä rohkenen kysyä kiihtyneen keskustelun lomassa, että onko kellään ideaa, miten tuohon lisäisi vielä merkkiäänen. Ja vähän suurempi koodinmuokkaus tarvittaneen jos merkkiääni tulisi vielä jokaisesta viestistä uudestaan.
Pitäisi varmaan sessioon lisätä vielä muuttuja tyyliin 'viestinumero_last_beeped' jä käyttää sitä jotenkin näin "$piippaamaton_viesti = $last_insert > $last_beeped" Vai voisiko tuossa javascriptin puolella tehdä jotenkin niin että vilkutus jää päälle vaikka session lastread nostettaisiin aina piippauksen jälkeen samaksi kuin tekstitiedostossa oleva lastinsert.
Näyttää nälkä kasvavan syödessä :)
The Alchemist kirjoitti:
Itsehän käytän paikallisia kirjastoja kehitysympäristössä ja cdn:ää tuotannossa. Problem solved!
Lisäys:
qeijo kirjoitti:
The Alchemist kirjoitti:
Kun yleisimmät kirjastot tulevat jostain keskitetystä cdn-verkosta, niin ei tarvitse bundlata niin paljoa kirjastoja ja se nopeuttaa myös lataamista. Netistä löytyy paljonkin tutkimuksia siitä, miten hitaasti latautuvat sivut aiheuttavat suuren mittakaavan yrityksille jopa miljoonien tulomenetyksiä. (tässä yksi)
Just joo. Hieman perspektiiviä peliin.
Ihmisten täytyy ymmärtää syyt tekojen takana, jotta jokainen voi puntaroida, milloin kannattaa tehdä tiettyjä asioita. Tietynlaisen koodin tekemistä tekemisen vuoksi (koska joku muu teki niin ensin) kutsutaan cargo cult -koodaamiseksi. Vaikkei tämä ole suoranaisesti ohjelmointia, niin se liittyy hyvin olennaisesti sovelluskehitykseen ja järjestelmänhallintaan.
Omien pienten kotisivujen takia ei välttämättä jaksa lähteä säätämään joka kerta koodia päivittäessä "tuotantoon" eri filuja kehitysympäristöön verrattuna, mutta eikös meistä moni haluaisi isona ihan tehdä leipänsä koodaamalla? Silloin joutuu melkein automaattisesti (web-puolella) puljaamaan suurempien käyttäjämäärien kanssa, joten on hyvä tietää jotain optimoinnista.
Miksi ihmeessä asian tekeminen tietyllä tavalla koska joku muu teki niin ensin, liittyisi olennaisesti sovelluskehitykseen? Mielestäni tärkein asia sovelluskehityksessä on itsenäinen looginen päättelykyky. Yhtä lailla voidaan sanoa että paskan koodin tekeminen on myös olennainen osa sovelluskehitystä.
Pelottava ajatus että "cargo cult" - mentaliteetti on mielestäsi osa järjestelmähallintaa?
Ehkä en nyt vain oikein ymmärtänyt pointtiasi.
qeijohan on ottanut tämän aiheen ihan henkilökohtaisesti...
Lebe80 kirjoitti:
Putkan lähdekoodi kirjoitti:
<link rel="stylesheet" href="/css/perustyylit.css?t=20121026131208" type="text/css" /> ...
Nuo kannattaisi muuten pakata yhteen tiedostoon turhien sivulatausten välttämiseksi. Tämä on yleisesti käytetty tapa.
Lebe80 kirjoitti:
qeijohan on ottanut tämän aiheen ihan henkilökohtaisesti...
just cargo culting, mofos!
Lisäys: Tekeekö kone koodista parempaa?
kalamies kirjoitti:
Sen verran vielä rohkenen miten tuohon lisäisi vielä merkkiäänen. Ja vähän suurempi koodinmuokkaus tarvittaneen jos merkkiääni tulisi vielä jokaisesta viestistä uudestaan.
Propsit rohkeudesta! Putkan fanaatikot ovat välillä aika pelottavia.
Äänen toteutusta en nyt kommentoi, mutta muuten tarvittavat muutokset ovat ihan yksinkertaisia.
Palvelimelta kannattaa ensinnäkin palauttaa tarkempia tietoja:
echo json_encode(array( 'uusin_viesti' => $last_insert, 'luettu_viesti' => $last_read ));
JavaScript voi itse tehdä vertailun ja katsoa, löytyykö lukemattomia viestejä.
Viestikohtaiset toiminnot (kuten merkkiäänen) voi toteuttaa niin, että JavaScript tallentaa 'uusin_viesti'-arvon muuttujaan ja vertaa sitä joka kyselyn jälkeen.
var uusin_viesti = null;
function paivitaMerkkivalo(tulos) {
var kuva = tulos.uusin_viesti > tulos.luettu_viesti ? "images/flashing.gif" : "images/passive.gif";
$("img#merkkivalo").attr("src", kuva);
if (tulos.uusin_viesti !== uusin_viesti) {
// jee, viimeisten 10s aikana tuli uusi viesti
}
uusin_viesti = tulos.uusin_viesti;
}Kiitos vastauksesta, nyt tuo alkaa pikkuhiljaa aueta tuo logiikka, eli tuolla pystyy siirtäämään muutakin dataa kuin pelkkää "truea ja falsea". Toki varmaan tuo liikenne kannattaa pitää minimissään, etenkin jos tihentää tuota tarkistusväliä sekunnin tietämiin...
Pitääpäs joku ilta taas kikkailla ja testailla mitä kaikkea onnistun saamaan aikaan.. (muutakin kun erroreita ja warningeja... :)
kalamies kirjoitti:
Toki varmaan tuo liikenne kannattaa pitää minimissään, etenkin jos tihentää tuota tarkistusväliä sekunnin tietämiin...
Tähän tarkoitukseen on kehitetty SSE (Server Sent Events).
kalamies kirjoitti:
Kiitos vastauksesta, nyt tuo alkaa pikkuhiljaa aueta tuo logiikka, eli tuolla pystyy siirtäämään muutakin dataa kuin pelkkää "truea ja falsea".
Minkä tahansa merkkijonon voi lähettää. JSON on tapa muuttaa JavaScript-arvoja merkkijonoiksi ja takaisin. Se tukee mm. lukuja, merkkijonoja, taulukoita ja objekteja.
kalamies kirjoitti:
Toki varmaan tuo liikenne kannattaa pitää minimissään, etenkin jos tihentää tuota tarkistusväliä sekunnin tietämiin...
No joo, mutta ei kannata stressata turhaan. JSON ei vie paljoa tilaa, varsinkaan jos palvelin pakkaa sen.
jukkah kirjoitti:
Tähän tarkoitukseen on kehitetty SSE (Server Sent Events).
... jota IE ei tue ollenkaan.
Aihe on jo aika vanha, joten et voi enää vastata siihen.