Új hozzászólás Aktív témák
-
ArchElf
addikt
válasz Sk8erPeter #2157 üzenetére
Ajax tipikusan webalkalmazásokra jó, ahol a felhasználónak úgysem kell nyomgatnia a back gombot (ha pedig megnyomja az neked le kell kezelni, különben szerencsétlen nem tudja, honnan hova került)... Akkor is érdemes lehet használni, ha valamiért nem szeretnéd, hogy letöltött oldal bekerüljön a history-ba (pl dinamikusan generált URL esetén), de ez is csak szépségtapasz, hiszen magában az oldal kódjában benne van a link (de legalább a hálózati forgalomból elcsíphető), úgyhogy ha valaki nagyon vadászik az URL-re, akkor azt úgyis meg tudja szerezni.
AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
válasz Sk8erPeter #2159 üzenetére
Mondjuk az Ajax és a PHP két külön dolog (php szerver oldali kód, míg az ajax kliens oldali). AJAX: Asynchronous Javascript And XML. Tehát kliens oldalion kérsz le a szerverről XML dokumentumot (ami az esetek nagy részében XHTML), és belerakod egy kiválasztott HTML DOM elembe.
Pl egy levelezőrendszer webes megvalósításánál előnyös lehet, lásd OWA (Outlook Web access): az egyik frame-ben látod a leveleid, az alatta levő frame-ben megnyílik az épp kiválasztott levél. Ilyenkor az egész oldalt - levelező mappák, levelek listája, megnyitott levél - újratölteni tejesen felesleges, ráadásul a teljes újratöltés valószínűleg eléggé frusztrálná a felhasználót is - persze van erre más megoldás is az ajax-on kívül (link megnyitása másik frame-be).
Aztán van az az eset, amikor egy legördülő menü kiválasztott eleme alapján töltjük fel a következő legördülő menüt. Ha mindent letöltesz egyszerre, az több legördülő menünél és terebélyesebb adatmenyiségnél elég nagy plusz méretet jelent. Viszont ha csak mindig azt töltöd le, ami a választásod alapján releváns, sávszélességet lehet spórolni (ez mind kliens, mind szerver oldalon fontos lehet). Webalkalmazások esetében súgó funkcióknál is szokták ez alkalmazni (tooltip szerű lebegő div a kurzor mellett, ami pl az adott mező funkcióját tárgyalja). Ha az összes elemre készítenél külön tooltip-div-et, akkor szintén sokkal terebélyesebb lenne a letöltendő oldalad.AE
[ Szerkesztve ]
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
válasz Sk8erPeter #2161 üzenetére
Most hogy válaszoltál, rájöttem, hogy egy alapvető felhasználási módot kifelejtettem.
Ez már (kicsit) a webservice kategóriájába tartozik: amennyiben adatot kérsz le egy szerverről ami nagy számítási vagy adatfeldolgozási igénnyel bír, lehet, hogy nem férsz bele a HTTP/Adatbázis/stb. timeout-ba. Ez ki lehet küszöbölni rendszeres asszinkron js http státusz lekérésekkel, és amikor kész az eredmény azt letöltöd az előzőekben leírt módon.
Nagyjából így néz ki:
1 - elküldöd a kérést a szervernek (általában adatot POST-olsz fel) asszinkron módon (ergo nem frissíted a lapot)
2 - beraksz egy folyamatjelzőt (mondjuk progress bar-t) a felhasználónak, hogy lássa hol tart a folyamat
3 - rendszeresen lekérsz (szintén asszinkron módon) egy oldalt ami az aktuális lekérés státuszát mutatja (ezt szerver oldalon kell folyamatosan frissíteni) - az abban található adatok alapján frissíted a felhasználói felületet (progress bart)
4 - amikor készre vált a státusz a szerveren, a kliens a státuszlekérés helyett lekéri (szintén ajax) az elkészült adattartalmat, amit megjeleníti.AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
válasz Sk8erPeter #2163 üzenetére
Sajnos az adatbázis kezelője problémázza el neked a dolgot. Ugyanis a háttérben a feltöltés tovább tart, mint az adatbázis kérés.
Nagyjából az alábbi lehetőségek vannak az tábla zárolására, hogy megvárd a feltöltési tranzakciót:
- feltöltéskor tábla szintű lock - ha zárod a táblát, akkor amíg valaki hozzászólást tölt fel, a táblát nem lehet lekérni a művelet befejezéséig (tábla feltöltése + indexek frissítése)
- feltöltéskor rekord szintű lock - amikor zárolod a táblát, akkor amíg valaki hozzászólást tölt fel, a táblának azt a sorát nem lehet lekérni. Ha ez is beleesik a lekérésbe akkor, jobb esetben várakozik a lekérés a zárolás idejére, illetve ha ez sokáig eltart, dob valami hibát.Legegyszerűbb azonban az, hogy az üzenet adatbázisba feltöltése után váratsz a felhasználóval 3-5 mp-et (valami "A lap 5mp-en belül átirányításra kerül, ha ez mégsem történne meg, nyomja meg a tovább gombot."). Ezalatt az adatbázis-művelet nagy valószínűséggel ténylegesen lezajlik.
AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
válasz Sk8erPeter #2163 üzenetére
Progress bar:
http://www.raditha.com/php/php-upload.php
http://hup.hu/node/64958
http://development.finetooth.com/?p=11AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
Ha van kedved leprogramozni, legegyszerűbb egymásba ágyazott table objektumokat használni. A table sorai könnyen eltüntethetők, megjeleníthetők (JS DOM hívásokkal), 1-2 óra alatt PHP-ban össze lehet dobni. Előre elkészített csomagot sajnos nem tudok ajánlani.
AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
Szerintem nagyobb mozgást igénylő MySQL adatbázisokban (free web szolgáltatóknál) ezt csinálják:
Table locking is also disadvantageous under the following scenario: A session issues a SELECT that takes a long time to run. Another session then issues an UPDATE on the same table. This session waits until the SELECT is finished. Another session issues another SELECT statement on the same table. Because UPDATE has higher priority than SELECT, this SELECT waits for the UPDATE to finish, after waiting for the first SELECT to finish.The following items describe some ways to avoid or reduce contention caused by table locking: Start mysqld with --low-priority-updates. For storage engines that use only table-level locking (MyISAM, MEMORY, MERGE), this gives all statements that update (modify) a table lower priority than SELECT statements. In this case, the second SELECT statement in the preceding scenario would execute before the UPDATE statement, and would not need to wait for the first SELECT to finish.
AE
[ Szerkesztve ]
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
Viszont $_REQUEST használata esetén a beküldött GET/POST/COOKIE adatok lehet, hogy ütni fogják egymást. Standard telepítés mellett a prioritás a következő:
EGPCS (Environment, Get, Post, Cookie, and Server)
Tehát, ha átadsz egy változót GET metódussal, de megadod ugyanazt COOKIE-ban is, akkor a $_REQUEST változóban a magasabb prioritású (Cookie) fog szerpelni. Persze a $_GET és a $_COOKIE tömbökben a megfelelő értékek lesznek bent. Ez azért okozhat feldolgozási problémákat...AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
válasz Gyomman #2215 üzenetére
Fényújság html tag-et csak az IE ismeri...
<MARQUEE>...</MARQUEE>
Más böngészőkben ez csak scriptelve eldható meg.http://www.htmlcodetutorial.com/weird.html
AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
válasz Sk8erPeter #2220 üzenetére
Oké, ismeri, de nem hivatalos HTML tag, és a támogatottság is bármikor kikerülhet a nem-IE böngészőkből.
AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
Kb így képzelném el:
alap div+ek: statikus mapping
mouseover div-ek: hidden
alap div + onmouseover: pozícionálás+láthatóság a mouseover div-nek
mouseover div + onmouseout: a mouseover div elrejtése.
így a mouseover div-ekből típusonként is csak egyet kell betölteni (kisebb a kód is)AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
Új hozzászólás Aktív témák
- Amlogic S905, S912 processzoros készülékek
- RETRO beárazás (mobil, PC, konzol)
- Íme az új Android Auto!
- Mini-ITX
- Revolut
- Windows 11
- HiFi műszaki szemmel - sztereó hangrendszerek
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- LEGO klub
- További aktív témák...
- ThinkPad X13 Gen 4 13.3" FHD+ IPS i5-1345U 16GB 512GB NVMe ujjlolv IR kam gar
- ThinkPad T14 Gen2 14" FHD IPS i5-1135G7 16GB 256GB NVMe ujjlolv IR kam., gar
- Avaya VSP 7024XLS B2F 24 portos 10GbE SFP+
- P15 Gen2i 15.6" FHD IPS i7-11850H T1200 32GB 512GB NVMe ujjlolv., gar
- Brocade 6505 24 port 16Gb FC SAN switch
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest