A segítségeteket szeretném kérni.
Üzeneteket jelenítek meg a weboldalamon. Az üzeneteket adatbázisban tárolom. Az üzeneteket egy x-el lehet bezárni, ami javascript segítségével eltünteti az üzenetet.
Na már most. Az adatbázisban van egy active mező ami arra szolgál, hogyha az értéke nulla akkor az üzenetet nem listázza ki az oldal.
Van egy php függvényem ami megváltoztatná az üzenethez tartozó mező értékét nullára, ha bezárjuk az x-el az üzenetet.
Ehhez kérném a segítségeteket. Hogyan tudnám megvalósítani, hogy az x-re kattintva eltűnik az üzenet majd az adatbázisban is megváltoztatom az értéket?
Kaptam segítséget, hogy használjak egy reqwest függvénytárat ajaxra, viszont a gondom még mindig a következő. Fogalmam sincs hogyan kezdjek bele.
function off_message($type){ $sqlmsgs = "UPDATE messages SET active=0 WHERE id='".$_SESSION['id']."' AND type='".$type."'"; $row = mysql_query($sqlmsgs); }
Közben megnézem azt az 5 módot ajax kapcsolódáshoz.
Tényleg nem kötekedésnek szánom, de amit mondasz, az jQuery-vel egy sor
És amikor te meghívod azt az egy sort, akkor még mennyit futtat a háttérben? De igazad van, a processzor ideje nem drága, nyugodtan terhelhetjük más prociját.
"És még az se fordulhat elő, hogy két egymás utáni gyors kattintásból csak az egyik kezelődik le. "
Kivéve, ha még az első nem futott le.
Csak éppen az enyém alatt összesen ennyi indul el:
window.hely.location.href='lekapcs.php?id=LekapcsolandóID'
Ami "kicsit" gyorsabban fut le, mint a jquery $.get('lekapcs.php?id=LekapcsolandóID'); és ami mögötte van.
Ha meg már elküldte a kódom a szervernek, akkor szinte abban a pillanatban indíthatjuk a másodikat, mivel a szervernek egymás után megy el.
"de azzal jó esetben nem kell foglalkoznia a programozónak."
[off] (és nem csak emiatt)
Azért érdekes, ha a fejlesztő által használt operációs rendszer, fejlesztő eszköz csinál plusz műveleteket és ezzel terheli a pocit, lassítja a programot, akkor a fejlesztő fel van háborodva.
Ha a fejlesztő program csinál valamit 10-20-... lépésben, amit 1-ben lehet, akkor azzal meg "jó esetben nem kell foglalkozni".
És ez nem csak a mostani esetre vonatkozik, hanem a prog.hu tele van ilyennel, hogy a jquery-ben milyen "jó", "szép" csak éppen hosszabb és lassabb, mint a html vagy alap js megoldás.
És amikor te meghívod azt az egy sort, akkor még mennyit futtat a háttérben? De igazad van, a processzor ideje nem drága, nyugodtan terhelhetjük más prociját.
Ilyen erővel ne használjunk semmi absztrakciós réteget, mert mindegyik több kódot futtat, mintha kézzel írtad volna... Még meg is érteném, ha éppen prímszámokat keresnénk vagy titkosítanánk, de itt most arról van szó, hogy 0.005sec helyett 0.05sec-ig terheljük a kliens CPU-ját.
Kivéve, ha még az első nem futott le.
Ezt most nem értem. Nyilván aszinkron kérésről beszélünk, a második kérés nem szakítja meg az elsőt.
Lehet egy post is és akkor még js se kell
Igen, csak így meg újratölti az egész oldalt, ami gyors szerver esetén is egy villanásként fog látszani a kliensnél. Nem nagy gond, csak manapság nem ez a menő.
Azért érdekes, ha a fejlesztő által használt operációs rendszer, fejlesztő eszköz csinál plusz műveleteket és ezzel terheli a pocit, lassítja a programot, akkor a fejlesztő fel van háborodva.
Ha a fejlesztő program csinál valamit 10-20-... lépésben, amit 1-ben lehet, akkor azzal meg "jó esetben nem kell foglalkozni".
Úgy is fel lehet tenni a kérdést, hogy gyorsan kell a program, vagy gyors program kell. Amikor a program az idő nagy részében nem számol, hanem a userre vár, akkor kb. mindegy, hogy mennyi CPU-t visz el abban a kis időben, amíg dolgozik. Ha nem így lenne, akkor nem lennének szkriptnyelvek, és mindenki C-ben meg assemblyben fejlesztene, mert ugye ezekben lehet a lehető legjobb CPU-kihasználást elérni...
szerk: Most jut eszembe, a villogást el lehet kerülni, ha a szerver egy "204 No Content" státuszú választ küld. Így is kicsit lassabb lesz, mint az AJAX, mert a böngészőnek meg kell várnia a választ, de szerintem elegánsabb, mint a láthatatlan iframe.
Ilyen erővel ne használjunk semmi absztrakciós réteget, mert mindegyik több kódot futtat, mintha kézzel írtad volna...
Így van.
Szerintem egy szakmai oldalon nem azt kellene minden áron javasolni, hogy jquery, jquery, ilyen csomag, olyan az, főleg ha majdnem ugyan olyan hosszban, gyorsabb és kevésbé memóriaigényes dolgot lehet csinálni.
Persze már kérdés, ha a "programozó" nem tudja megírni, vagy jelentősen több idő megírni.
Ennél akérdésnél persze lehet az első, de nem igazán lehet a második. Ha egy programozónak érdemben tovább tart megírni az én kódomat, akkor inkább ne foglalkozzon számítástechnikával.
De biztos "menő" manapság hogy programozás címszó helyett kész dobozokat rak össze valaki.
És főleg ilyenkor igaz, ha a fejlesztő kapja a "dobozos" lassú alkalmazást (mert "célszerűbb" mint rendesen és gyorsra megírni), akkor az zavarja, de ha ő adja ki a kezéből, akkor az ugyebár "a gyors fejlesztés" célja miatt van.
Igen, csak így meg újratölti az egész oldalt, ami gyors szerver esetén is egy villanásként fog látszani a kliensnél. Nem nagy gond, csak manapság nem ez a menő
Miért is? Mitől villan? Bocs, de nem ártana megnézned, hogy mit is tölt újra egy rejtett iframe irányított űrlap. (Van egyébként hibája, de nem ez , és azt se egészen tudom hogy egy komoly támadó szándék ellen miért véd jobban egy post, mint egy get)
a második kérés nem szakítja meg az elsőt.
Csak éppen a kérdés az, hogy amíg az első tényleges küldés nem kezdődött el (mert a jquery még csak értelmezi az $.get-et), addig tényleg jó-e ha indul a második.
Úgy is fel lehet tenni a kérdést, hogy gyorsan kell a program, vagy gyors program kell.
Miért is gyorsabb attól a program megírása, hogy egy 1 soros jquery-t írsz, vagy egy 1 soros js-t és egy egy soros html-t?
Ha nem így lenne, akkor nem lennének szkriptnyelvek, és mindenki C-ben meg assemblyben fejlesztene, mert ugye ezekben lehet a lehető legjobb CPU-kihasználást elérni...
Most ugye ne nézzük, hogy mi is volt a js kialakításának az oka, de aranyos, hogy azt hasonlítod össze, hogy valaki repülőt vagy kerékpárt (C-t vagy js-t) használ. Más a céljuk.
De egy direkt js (vagy html) sort kiváltani egy több lépcsős js sorral az kb. olyan, mintha a
valtozo=valtozo+10
helyett
valtozo=valtozo+1
valtozo=valtozo+1
valtozo=valtozo+1
...
Vagy egy 1-el növelést ciklusba szervezve ajánlanál.
Sőt olyan mintha, a
x=1
y=2
z=x+y
helyett, mivel valaki már megírt egy
function osszead(a,b)
{
return a+b
}
függvényt azt javasolnád, hogy legyen:
x=1
y=2
z=osszead(x,y)
---
De igaz, inkább a programozó dolgozzon 1 perccel kevesebbet, és minden látogató gépe 10* annyit dolgozzon, minthogy a programozó gyors programot írjon.
--- de szerintem elegánsabb, mint a láthatatlan iframe.
Ja, ha elegáns és nem rövid, gyors programot akarunk írni egy szakmai fórumon, az más. Akkor legyen jquery.
Azért kíváncsi lennék, hogy hány rejtett iframe ellenes használ pl. tinymce-t vagy olyan jquery feltöltést, ami a háttérben tölti fel a fájlt
De biztos "menő" manapság hogy programozás címszó helyett kész dobozokat rak össze valaki.
De az is lehet, hogy a feladata több részből áll, és nem akar minden részletnek a legaljára túrni. Pont a héten volt olyan feladatom, hogy a webapp egy kis része a háttérben tudjon frissülni, de az adat, amit frissíteni kell, egy webservice-től érhető el HTTP-n. Igen, a szerveroldalon a kapott XML-t feldolgozhattam volna SAX-szal, mert az gyorsabb, mint a DOM és az XPath. A válasz JSON-t is összefűzögethettem volna magam egy sztringbe, mert hát a json.org-os kód plusz ellenőrzéseket végez feleslegesen. És a kliensen is megírhattam volna magamnak az AJAX kéréseket meg a JSON parse-olást. Csak ha mindezt megcsinálom, akkor kétszer annyi idő megírni, és utána nehezebb karbantartani. Nekem elég volt a logika, ami egyik dobozban sincs benne, mert a feladat egyedi részét képezi.
Miért is? Mitől villan? Bocs, de nem ártana megnézned, hogy mit is tölt újra egy rejtett iframe irányított űrlap.
Bocsi, nem vettem észre a target attribútumot, szóval amit a villogásról mondtam, az hülyeség volt, bocsi és azt se egészen tudom hogy egy komoly támadó szándék ellen miért véd jobban egy post, mint egy get
Nem azért mondtam a POST-ot, mert bármitől jobban megvédene, mint a GET. Azért mondtam, mert az RFC szerint a GET-nek nem ajánlott, hogy mellékhatása legyen, hanem az csak információ lekérésére való. A POST való olyan műveletre, ami állapotot változtat. Egy ideális világban, ahol mindenki betartaná az RFC-t, a böngésző nyugodtan előtölthetne linkeket az aktuális oldalról, mert úgysincs mellékhatása.
Csak éppen a kérdés az, hogy amíg az első tényleges küldés nem kezdődött el (mert a jquery még csak értelmezi az $.get-et), addig tényleg jó-e ha indul a második.
Eddigi ismereteim szerint a JS egy szálon fut, vagyis lehetetlen az, hogy egy oldalon egyszerre két JS kód fusson. Amíg az első $.get nem tér vissza, a második garantáltan nem tud elkezdődni.
Miért is gyorsabb attól a program megírása, hogy egy 1 soros jquery-t írsz, vagy egy 1 soros js-t és egy egy soros html-t?
Ebben a példában nincs nagy különbség, ezt elismerem. Azt hittem, általánosságban beszélünk, hogy frameworköt használjon az ember, vagy írjon meg mindent kézzel...
Most ugye ne nézzük, hogy mi is volt a js kialakításának az oka, de aranyos, hogy azt hasonlítod össze, hogy valaki repülőt vagy kerékpárt (C-t vagy js-t) használ. Más a céljuk.
Azt hittem, a szövegkörnyezetből kiderült, hogy nem a C-t és a JS-t vetettem össze, hanem a "gyorsan megvan és lassú" megoldásokat a "sokáig tart megírni de gyors" megoldásokkal. A CPU kímélése korántsem az elsődleges szempont sok esetben, és ott a "gyorsan megvan és lassú"-nak van létjogosultsága. És még egyszer mondom, nem ezt a konkrét példát kell csak nézni, mert itt tényleg nincs nagy különbség.
De egy direkt js (vagy html) sort kiváltani egy több lépcsős js sorral az kb. olyan...
OK, megkíméled a user processzorát, de az igazi kérdés az, hogy érdekli-e ez a usert. Jött már oda hozzád user, hogy de tök jó lett, hogy 5ms-kel gyorsabban reagálnak a gombok az oldaladon?
1 blokkra:
Igen, de gondolom te se azért tudtad megírni, mert az "elemi" műveletekhez mindig csomagokat használtál.
2. blokkra: Ok, semmi baj, velem is előfordult, már, hogy egy rövid rész kimaradt, és úgy reagáltam.
A 2. része igaz
3. Pont ezért mondtam, az én megoldásom (szinte) azonnal végrehajtásra kerül, a jquery-s lassabban. És eredetileg erre gondoltam.
4. "Azt hittem, általánosságban beszélünk, hogy frameworköt használjon az ember, vagy írjon meg mindent kézzel..."
Nem, én itt gondoltam. Természetesen nagyon sok olyan van, amikor én is valami készet használok, de az is, hogy ugyan a kész (esetleg már) be is van töltve, de sebeség (vagy egyéb okból) inkább a saját js-t használom.
Azt hittem, a szövegkörnyezetből kiderült, ...
Én meg azért erre reagáltam: "nem lennének szkriptnyelvek, és mindenki C-ben meg assemblyben fejlesztene"
De akkor bocsi itt meg én értettem félre.
OK, megkíméled a user processzorát, de ...
Igazán én azt tanítom, hogy ne szokjuk meg a lassabb, vagy erőforrás igényesebb módszert (főleg a míg tanulunk ), mert az utána a gyakorlatban is elég ragadós lesz.
A prog.hu elve meg, hogy tanítson és nem a copy/paste kód (persze néha az rövidebb, mintha elmagyarázzuk ), akkor meg azért lássa mindegyik előnyét és hátrányát.
Nehogy olyan legyen, hogy "akinek csak kalapácsa van, azt mindent szögnek lát"
Igen, de gondolom te se azért tudtad megírni, mert az "elemi" műveletekhez mindig csomagokat használtál.
Ezt a mondatot nem értem. A legtöbb "elemi" részét a feladatnak (keep-alive HTTP kérés küldése, XML parse-olás, dátum parse-olása timestamp-re) nem írtam meg soha magamnak, és sok munka lenne magamnak megírni. (Nem mondom, hogy nem tudnám, biztosan megvan minden szükséges irodalom a Google-ön, de a jelenlegi tudásommal nem lennék képes rá.) Abban szerintem egyetértünk, hogy hasznos ezeknek az építőkockáknak a működési elvét, illetve a futási komplexitását nagy vonalakban ismerni, de a használatukhoz nem kell őket teljesen megérteni, vagy magadnak leimplementálni.
A prog.hu elve meg, hogy tanítson és nem a copy/paste kód (persze néha az rövidebb, mintha elmagyarázzuk ​),
akkor meg azért lássa mindegyik előnyét és hátrányát.
Na ebben igazad van, elfelejtettem az oldal oktató jellegét. Én inkább úgy viszonyulok az oldalhoz, hogy problémamegoldó portál, de tényleg innen tanulnak sokan.
Akkor neked arról válaszolok, hogy jelenleg idáig jutottam a jquerival. Minden klappol. Olvasásra, működésben viszont a post nem fut le, ezáltal nem tűnik el a doboz és nem frissül az adatbázis.
Neked is válaszolok. :)
Köszönöm a válaszod, holnap megpróbálkozom ezzel a megoldással, mert a jquery egy pillanatra elakadt. Amelyiket előbb sikerül megoldanom azt fogom használni.
Az egyik, ami remélem így kiemelve már feltűnik, hogy kimaradt az attr() függvény záró zárójele. A másik, hogy az attr()-nek simán az attribútum nevét kell megadni, nem tudom, honnan jött neked a kettőskereszt.
Amit még érdemes lenne megnézni, hogy a callbackedben kapott this biztosan ugyanaz-e, mint amit a click kezelőben látsz. A this értéke ugyanis attól függ, hogy hogyan hívták meg a függvényedet, és ezt ebben a konkrét helyzetben nem tudod. Egyébként is a click kezelőben direkt létrehoztál egy "item" nevű változót, nem lenne egyszerűbb azt használni a callbackben is?
$.post("message-off.php", {id: item.attr("id")}, function (data) {if (data.success) {$(this).parents("div").filter(":first").fadeOut("slow");}}, "json").error is not a function (?)() handle() a = Object { originalEvent=Event click, type="click", timeStamp=1328374087282, több...} ab()
Sehová tovább?
Firebugon és Firephp-n kívül tudok valamit hibakeresésre? A konzolon kívül van ott más lehetőség, hogy hibát keressek? Vagy innen már tudnom kéne mi a gond? :)
Ebben segíthetnél, hogyan tudom azt megnézni?
Eddig én csak azokat a bővítményeket használtam amit írtam, a konzolban nézegettem a hibákat. Hogyan nézzem meg amit mondasz?
A console.log() a barátod, és hiszen használtad is a bemásolt kódodban. Gondoltam, innen már világos, hogy a callback-ben kiírasd a this értékét console.log()-gal.
