Java og Javascript er ikke det samme, hvornår lærer folk det....
--
Fint.. men det løser så ikke mit problem
--
#0 prøv at stille spørgsmålet inde på stackoverflow.com ;)
--
Men måske kunne du indføre noget timestamp? enten på hver status, eller endnu bedre: have en særskilt tabel med timestamp for seneste ændring af en hvilken som helst status. Så skal du bare checke om den er nyere end forrige opdatering, og hvis den er, SÅ henter du alle status'erne igen ;)
(hvis jeg har forstået dit koncept korrekt)
--
#4
Timestamp dur ikke, da der sagtens kan være 10 klienter på.
Og så skal jeg igen til at have et array liggende med timestamps for hver klient som så skal sammenlignes med db data.
Og så er jeg lige vidt.
Men ja, stackoverflow var en mulighed. - tak.
--
At hente 48 rækker hvert sekund er ihvertfald ikke at anbefale..
Og det skal hver eneste klient vel gøre eller hva? ;)
--
Var det en idé at bruge noget websocket måske? (direkte forbindelser mellem klienterne)
Så kunne du fjerne nødvendigheden for de konstante db-kald.
F.eks pusher.com eller hydna.com
På den måde kan du sørge for at klienterne kun henter nye status hvis der er ændret en status
--
Hvad er problemet?? du skriver selv svaret.
Du ved vel hvilket index hver status har, så det jo bare at sammenligne med det gamel array med en masse if'er.
Og ja, kan heller ikke helt se hvorfor det er nødvendig at kalde Db'en 48 gange :/
--
YEAH, har fundet på noget vildt sejt at skrive HER... damn, har bare glemt det ;P
Hvor tit bliver en status ændret ca... Er det meget tit?
--
#8
Jeg har nok formuleret det forkert.
Jeg mener at jeg kender løsningen på problemet, bare ikke metoden til at løse det :) (dog kunne der være nogle som havde en mere elegant løsning)
Ved check kalder jeg en php side som henter statuser, men hvordan får jeg dem sammenlignet med den 'gamle' status fra mit php array ?
Jeg skal vel over i noget json_encode ? eller er det ikke nødvendigt ?
Kan jeg i javascript direkte sammenligne med et php array, ex. på samme måde som ren php med array_diff ?
#9
Normalt ikke så ofte, så der kan sagtens være mange tusinde checks inden der sker en ændring, men omvendt kan der også være flere ændringer ved et check.
Det skal bruges til at aktivere/monitore nogle porte/lys/mm via nogle io relæ moduler.
--
Husk at javascript er client side mens php er server side.
Det du vil er at have den til at opdatere hvert sekund. Samtidig vil du ha den til gemme gammel data.
Du skal altså over i at PHP hver gang den bliver requested viser den nyeste status samt skriver den til en database. så kan du bruge PHP til sammenligning ved at hente data fra tabellen.
Data opdateres lettest ved at force et reload af siden (husk for guds skyld at få whitelistet dig selv så du undgår bans af forskellig slags.)
force reload:
$page = $_SERVER['PHP_SELF'];
$sec = "1";
header("Refresh: $sec; url=$page");
--
Yes, I am a newbie
#10 så vil jeg da bestemt holde fast i at du skal lave en tabel hvis eneste indhold er et timestamp for hvornår en hvilken som helst status er blevet ændret.. og hvis hvis noget er ændret siden sidste check, SÅ henter du alle statusfelter og viser dem flot
Det vil skære en masse kald, array-sjov og sammenligninger væk. Og din database vil elske dig for det ;)
--
Og når en status skal ændres, så opdaterer du også bare dit timestamp i dén tabel også
--
#11 & #12
Det var sådan jeg startede i version 0.1 af koden :)
Problemet med denne løsning er at man kan se at siden står og refresher, og det ser ikke for kønt ud desværre !
Derfor jeg gik over til at opdatere enkelte divs på siden med setinterval funktionen på nogle bestemte id'er.
Det giver ikke sammen 'flimren' da det kun er selv det felt som statuserne er i som bliver opdateret.
--
if (@mysql_result(@mysql_query("SELECT COUNT(1) FROM statussenestopdateret WHERE timestamp>'$timestampforsenesteændring'"-
;), 0) > 0) {
// timestamp feltet er blevet ændret siden sidst. hent hele møllen
}
--
#13
Timestampsene bliver jo nødt til at være serverside da der er flere klienter hvis ure sikkert ikke stemmer overens.
Samtidigt med at det KAN være mig som har ændret status, men det KAN også være noget andet software fra relæerne som har ændret dem.
Og så er jeg jo alligevel ude i at jeg skal have en timestamp liggende client-side som skal sammenlignes med den server-side timestamp
--
#17 ja serverside. men du bruger jo i forvejen php og mysql til at både ændre og hente status'erne?
Timestampet vil være det samme på alle klienterne, da det laves af serveren
--
#16 I see your point.
Så kan man da nøjes med en var istedet for et array, og samtidigt kan jeg bibeholde den kode jeg har i forvejen til at opdatere siden med..
Tænke tænke.. kunne godt være i den retning jeg skulle.
Eneste lille detalje er at jeg på den måde opdatere alt og ikke bare den ene status, men det burde også kunne løses...
--
#19 "Eneste lille detalje er at jeg på den måde opdatere alt og ikke bare den ene status, men det burde også kunne løses"
Jeg er ikke med?
Du opdaterer status'er præcis som du har gjort. Men nu smider du bare en lille opdatering af timestamp tabellen ind samtidig ;)
--
Timestamp tabellen er adskilt fra tabellen med alle status'erne ;)
--
#20#21
Yes, det var mere min html visning som vil blive fuld opdateret hver gang der sker en ændring, fremfor kun den status/div som er ændret
--
#22 ah.. ja ok. men bruger du ikke i forvejen jquery til at hente/ændre tabellen med status'erne?
--
jo det gør jeg, og der henter jeg dem enkeltvis dvs. et kald per status for at hente alle felter.
og man kan sige ved at bruge dit forslag kan jeg reducere mine kald betydelig sådan jeg kun har de 48+1 kald ved ændringer og eller bare 1kald/sec
Men hvis jeg lige fandt en måde til kun at opdatere den enkelte div, ville jeg kunne komme ned på 1+1kald ved ændringer.
--
page refresh?!?! hvad tror i det er 1998?
lav et .php script der henter samtlige data i én query... og skriver dem ud i json format. Brug så jQuery.getJSON() (
http://api.jquery.com[...] ) til at hente data ned i et objekt én gang i sekundet. Loop igennem objektets rækker med javascript og sammenlign den relevante variabel for ændringer med dem der pt. er lagret i sidens DOM objektet.
Det er ikke mega effektivt - men hvis din host er almindeligt okay og du ikke har mange tusinde brugere tror jeg ikke det vil være et problem. Ellers skal du ud i noget multiplexer og socketforbindelser og så skal du bruge noget applet fis.
--
Fun: PIIX6 1100T, AsR970 Ex4, Asus 560Ti 448c, 12GB HypX, Intel SSD 160GB, Dfine R3, 30" Dell U3011
Work: 17" MacBook Pro + ASUS N55SF #25
page refresh har nu ikke været en løsning, kun del refresh med div/jquery.
Men det ser ud til at der er lidt læsestof til mig i det du skriver :) - tak.
Ang. host, så er det ikke noget problem, da det bliver hostet lokalt, på en mere eller mindre dedikeret wamp server.
--
Ok, lidt svært uden at have set koden ;)
Men, du skal ikke lave så mange kald (som det lyder til at du gør)
Min tanke var sådan her:
jquery checker databasen via php med ét kald (tabellen med timestamp) om tidspunktet for seneste ændring er senere end ved forrige ændring
Hvis tidspunktet er ændret, så hiver du tidspunktet ud (så det kan bruges til sammenligning ved næste kald) og så henter du alle felterne med status (også med kun ét kald, men alle felterne samlet i et json array) og det array spyttes så bare ud med jquery i de forskellige divs. Der er vel ingen grund til at checke om hver enkelt status er ændret på dét plan. Bare skift alle divs ud med de nye opdaterede værdier
Når du skal ændre en status:
Opdatér feltet for den pågældende status. + opdatér timestamp feltet i tabellen med det felt
--
#27
enig, også det der skal ændres, grunden til at jeg startede med at lave en for hver istedet for alle på en gang var måden jeg byggede siden op, da jeg kunne gøre den mere dynamisk med mine statuser.
Men taget i betragtning af antallet af querys, så kan det ikke retfærdiggøres.
Tak til alle for inputs, jeg vil lige igang med læse lidt på json/jquery/javascript.
Vender nok lige tilbage når jeg er kommet lidt længere med implementeringen af det :)
--
Jeg forstår ikke helt hvorfor et timestamp er vigtigt.
Hvorfor ikke bare hente alle værdierne med et synkront kald, og så opdatere dine divs.
Hvis du så har lyst kan du jo sende et tidspunkt med sammen med statuserne, så du kan udskrive hvornår data senest er sendt fra serveren.
--
Gæstebruger, opret dit eget login og få din egen signatur. #29 Den metode er selvfølgelig nemmest at kode.. Men med den måde vil der blive hentet 48 rækker hvert eneste sekund på op til 10 klienter samtidig (plus div. ændringer af databasen løbende. og tabellen bliver jo låst når der ændres i den). Det er overkill og overload, og sikkert også ustabilt i længden. Jeg kunne nemt forestille mig at databasen begynder at ophobe kald i kø som den aldrig når til og på et tidspunkt ikke kunne følge med
Med et timestamp i en seperat tabel skal der kun checkes ét sølle tal i sekundet (på hver klient), og først hvis det tal er ændret hentes alle rækkerne. Det er en væsentlig optimering ;)
--
#30
Nu kan vi jo spekulere vidt og bredt om hvilke krav der stilles til løsningen fra #0 ;D så om det er overkill/overload kommer jo an på hvor tit værdierne i databasen opdateres, hvor mange klienter der er, hvor hurtigt web- og databaseserveren kører.
Hvis tingene er tidskritiske og samtidig kører asynkront skal man jo også holde styr på at svar kan komme tilbage til klienten i "forkert" rækkefølge.
og hvorfor optimerer før man ved om det er nødvendigt, så "over-ingeniører" man jo sin løsning?
--
Gæstebruger, opret dit eget login og få din egen signatur. #26 ...jo det blev nævnt i #11 :P
--
Fun: PIIX6 1100T, AsR970 Ex4, Asus 560Ti 448c, 12GB HypX, Intel SSD 160GB, Dfine R3, 30" Dell U3011
Work: 17" MacBook Pro + ASUS N55SF
#30 ...480 rækker pr. sekund er jo ca. absolut ingenting for en sql database? Jeg kan godt se det principielle i det, men kan ikke se et reelt problem ved mindre der skal skaleres meget dramatisk.
--
Fun: PIIX6 1100T, AsR970 Ex4, Asus 560Ti 448c, 12GB HypX, Intel SSD 160GB, Dfine R3, 30" Dell U3011
Work: 17" MacBook Pro + ASUS N55SF
#1 hold mund, du fatter jo udemærket godt hvad han spørg om. Grow up.
--
#33 som du selv siger så skalere det bare a lort med så mange requests :)
--
Yes, I am a newbie