- Milyen okostelefont vegyek?
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Android alkalmazások - szoftver kibeszélő topik
- Apple iPhone 16 Pro - rutinvizsga
- Motorola Edge 50 Pro - több Moto-erő kéne bele
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Az Oppo Find X8 Ultra lett a legvékonyabb kameramobil
- One mobilszolgáltatások
- Eurós árlista a Google Pixel 10 telefonokhoz
- Amazfit Active 2 NFC - jó kör
Új hozzászólás Aktív témák
-
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
-
#2224
ArchElf
addikt
Sk8erPeter
#2220
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
-
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
-
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
-
ArchElf
addikt
-
#2166
ArchElf
addikt
Sk8erPeter
#2163
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
-
#2165
ArchElf
addikt
Sk8erPeter
#2163
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
-
#2162
ArchElf
addikt
Sk8erPeter
#2161
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
-
#2160
ArchElf
addikt
Sk8erPeter
#2159
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
-
#2158
ArchElf
addikt
Sk8erPeter
#2157
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
Új hozzászólás Aktív témák
Hirdetés
- Milyen okostelefont vegyek?
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Linux kezdőknek
- Milyen légkondit a lakásba?
- Úgy tér vissza a Commodore 64, ahogy titkon mindenki várja
- Luck Dragon: Asszociációs játék. :)
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Kompakt vízhűtés
- Milyen videókártyát?
- Android alkalmazások - szoftver kibeszélő topik
- További aktív témák...
- Apple iPhone 14 Plus 128GB, Kártyafüggetlen, 1 Év Garanciával
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 4070 Ti Super GAMER PC termékbeszámítással
- HPE Apollo 4200 Gen9 2U rack szerver, 1x E5-2620v4, 64GB RAM, 24x3.5" 2U-ban! ÁFA-s számla, garancia
- Samsung Galaxy A36 5G 128GB dobozos 12 hónap garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest