ugrás a tartalomhoz

div frissítés blokkolása ha a felhasználó görget

Magdianyus · Okt. 29. (K), 13.56
Sziasztok

Kicsit megakadtam (kicsit=nagyon).

Adott egy script, ami egy div-be bizonyos időközönként tartalmat hív be. A tartalom adatbázisból kér le adatokat, így oldal betöltés nélkül frissül az adat.
Ez a része működik is, viszont azt szeretném elérni, hogy ez a frissítés pihizzen amikor a felhasználó görget.
Számomra összetett a probléma mert, az nem jó megoldás ha görgetés közben áll a script, mert ha sokat akar görgetni a felhasználó de éppen megpihen, akkor újra frissít a script.
A lényeg az lenne, hogy amikor görgetésbe kezd akkor állítsa le a frissítést a script és egészen addig pihenjen amíg mondjuk a felhasználó vissza nem görget az oldal aljára.

A tanácsot, a segítséget, az építő jellegű negatív kritikát köszönöm és a helyes rávezetést 1 doboz sörrel vagy egy zacskó dunakaviccsal jutalmazom!!

Tehát a script:

<script   src="http://code.jquery.com/jquery-latest.min.js"></script>
<script type="text/javascript">
    function refresh_div() {
        jQuery.ajax({
            url:'adat.php',
            type:'POST',
            success:function(results) {
                jQuery(".cel").html(results);
            }
        });
    }


    t = setInterval(refresh_div,500);
</script>
 
1

Feltételek

Endyl · Okt. 29. (K), 14.59
Próbáld megfogalmazni pontosan, hogy mik azok a feltételek, amik megléte esetén lefuthat a frissítés. Ha ez megvan, nézz utána, hogy js-ben ezeket hogyan lehet ellenőrizni. Ha ez is megvan, akkor ezt az ellenőrzést beteszed valamilyen módon a refresh_div elejére, és ha nem teljesül, akkor csak kilépsz a függvényből az ajax hívás előtt.

Ha jól értem, akkor a frissítésnek csak akkor kell lefutnia, ha az oldal aljánál jár a felhasználó. Ezt viszonylag könnyű ellenőrizni, úgyhogy a módszer felkutatását rád bízom. Arra azért figyelni kell, hogy pontosan melyik html elem görgetődik, mert lehet olyan eset, amikor az első stackoverflows válasz nem feltétlenül működik.
2

átgondolás

Magdianyus · Okt. 29. (K), 16.40
azon gondolkodtam, hogy nem jobb megoldás-e számomra, ha csak akkor fut le a frissítés ha az adatbázis frissül.

Ugyanis egyszerűbb megoldás ha szabadon görgethet a felhasználó és akkor ugrik csak neki vissza amikor új adat "érkezett". Ez a megoldás jobban tetszene.

Ennek a megvalósítása szintén összetett, lenne egy fájl ami folyamatosan ellenőrzi az adatbázist. Amennyiben új adat érkezik, akkor pedig meghívja a frissítő scriptet egy másik oldalon egy post üzenettel.

A scripteket viszont még csak kapargatom, így az adatokat át tudom küldeni egyik lapról a másikra de a fogadása (és a script feltételhez kötése) probléma.

Összegezve nem tudom, hogy a php-ben használt if és else ág használata hogy működik scriptek esetében.

Egyébként a jelenlegi frissítő scripttel mint rájöttem az is probléma, ha kép kerül az adatbázisba mert ha azt is frissítgeti az eléggé furán néz ki
3

Mi a cél?

Pepita · Okt. 30. (Sze), 13.22
Ahogy Endyl is javasolta, az első lépés legyen az, hogy pontosan definiálod a feladatot.
Jó dolog az, ha fejlesztés közben is gondolkodsz rajta, de pont úgy lehet nagyon könnyen neverending storyba futni, ha nem egyértelmű a feladat, és emiatt amint lefejleszted a "valamit", máris nem az, amit szerettél volna és kezdheted elölről.

Érdemes szerintem átgondolni azt is, hogy mi a konkrét célja a frissülő div-nek, mit szeretnél elérni a látogatónál? Ha jól értem, az oldal alján van, és Te görgetsz oda neki ("akkor ugrik csak neki vissza" - de a js-ben nem látni ilyen kódot)? Ez elég zavaró is lehet.

A képekkel és a db-ben tárolt html tartalommal kapcsolatban nem tudok mit javasolni, mert nincs róla elég infó.

A "csak akkor frissüljön, ha változott a tartalom" - ra több megoldás is létezik.
1. A PHP crc32 függvénye remekül használható arra, hogy egy egész szám reprezentáljon egy (akár több kB-os) stringet. Nagy valószínűséggel két eltérő html tartalomnak eltérő lesz a crc összege is. Szóval annyi a feladat, hogy az adat.php lekérdezi a tartalmat úgy, mint eddig, "kiszámolja" a crc összeget is, és együtt a kettőt (pl json enkódolva) küldi ki a kliensnek. Js-ben pedig amikor kirakod a div-be a tartalmat, egy változóba tárolod a hozzátartozó crc-t is. A következő alkalommal összehasonlítod a szervertől kapot crc-t a változóddal, ha egyenlő: nem kell cserélni. A jquery doksijában pedig megtalálod, hogyan kell json adatokkal kommunikálni a szerverrel (érdemes megtanulni, mert nagyon ritka, hogy csak egyetlen adatot kelljen php-ból kiküldeni, json-ben meg tök kényelmesen lehet sokat).
2. Ha van session-kezelés, akkor az 1-et lehet úgy optimalizálni, hogy php-ban "jegyzed meg" az előző crc-t (sessionben tárolod), és ha nem változott, akkor pl üres stringet küldesz ki -> js pedig csak akkor cseréli, ha nem üres stringet kapott.
3. Természetesen az adatbázis ismeretében lehetne találni optimálisabb megoldásokat is, fenti 2 megoldás hibája, hogy minden egyes kérésre scanneli az adatbázist, nagy forgalmú oldalnál ez lehet gond teljesítményben.

Megjegyezném még, hogy a kódrészletben a "t" változónak az értéke nincs felhasználva, így lehet, hogy felesleges (ha valahol van clearInterval, akkor viszont kell).
Aztán a type:'POST' helyett elég a GET, mert nem küldesz be adatot, végül, de nem utolsó sorban nagyon gyakorinak tűnik a fél másodpercenkénti request és DOM módosítás. Gyengébb neten (pl mobil, utazás közben másodpercekig is lehet 0 sávszél) feltorlódhatnak a kérések, és amikor visszaáll, egyszerre érkezik a több válasz -> "ugrálni fog" a tartalom.