- Apple Watch Sport - ez is csak egy okosóra
- Nem várt platformon a OnePlus Nord 5
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Megérkezett a Google Pixel 7 és 7 Pro
- Samsung Galaxy Watch6 Classic - tekerd!
- Garmin Instinct – küldetés teljesítve
- Google Pixel 9 Pro XL - hét szűk esztendő
- Samsung Galaxy Watch7 - kötelező kör
- iPhone topik
- Motorola Edge 50 Neo - az egyensúly gyengesége
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
"nem talál egy oldalt, akkor exception-t dobjon, amikor az egy belekalkulált működés, szerintem; az exception számomra egy kerülő megoldás, ahol ide-oda ugrálunk a kódban.
Itt tulajdonképpen arról van szó, hogy milyen 'hiba' vagy kivételes eset fordulhat elő többször, amire számítani kell, és mi a valódi hiba (ez utóbbi esetben érdemes kivételt használni). Nem láttam még olyan keretrendszert, ami kivételdobásokra alapozta volna a működését."Akkor az általad használt Kohana egy szar, mert pl. minden egyes HTTP status code-ra létezik benne exception?
Vegyük az említett példának megfelelőt: HTTP_Exception_404.
Aztán itt bal oldalt láthatod szépen a többit is, ami pl. validálás kapcsán említésre méltó, az a Validation_Exception.
Aztán ott a Kohana_Exception, a Kohana_Request_Exception és a Kohana_View_Exception.Azt hiszem, abban egyetérthetünk, hogy valószínűleg a Kohana alapvetően nem átgondolatlan struktúrára épül.
Hadd említsek egy másik példát: remélem abban is egyetértünk, hogy a Symfony nem egy tákolmány keretrendszer, és valószínűleg nem érdemtelenül népszerű.
Egy - számomra legalábbis - elég meggyőző érv még a témában:
[link]
"Symfony really relies on PHP exceptions for error reporting, which is much better than the way PHP 4 applications work. For instance, the 404 error can be triggered by an sfError404Exception."Akkor most már láthattál egy keretrendszert, ami kivételdobásokra alapozta a működését.
-
modder
aktív tag
válasz
Sk8erPeter #8997 üzenetére
Most már nem fogok mindenre reagálni, leírtam az érveimet. Felőlem mindenki olyan esetekben dobál exception-t a kódjában, ahol akar.
Csak egy pár dolog:
Azt hiszem érthető voltam, de akkor leírom érthetőbben: amikor refaktorálod (átírod, javítod) a kódot, nem fogod tudni, hol dobtad az exceptiönt, amíg tényleg nem dobtál egyet.
Például van a form validáló osztályod, ami dobhat 4féle exception-t, te meg szeretnéd tudni, hol dobja, akkor legjobb esetben is ctrl+ffel keresel rá. Ha pedig a stacktrace-t akarod használni, ahhoz generálnod kell egy olyan hibát, ami ezt az exceptiont dobja.Aztán kiderül, hogy basszus, nem is $functionReturnValue['status'] a megfelelő vizsgálandó visszatérési érték indexe, hanem mondjuk $functionReturnValue['result'].
Nyilván, ha valaki idiótán programoz, arra nincsen mentség.Aki pedig azt állatja, hogy minden függvényt azzal kezd, hogy /** */, az biztos ráér programozni
-
modder
aktív tag
válasz
PazsitZ #8996 üzenetére
PHP-ban valszeg nem olyan költséges, mint pl. c++-ban.
Ne értsetek félre, jó dolog az exception olyan hibák kezelésében, amik tényleg az elvárt futástól különböző esetekre vannak.
Ezen kívül azonban, amikor a program funkcionalitásába belekalkulált dolgokról van szó, mint például: S8erPeter-nek volt egy form validálós, feldolgozós példája, ahol hiba esetén kivételt dob, illetve a fentebb tárgyalt esetben, hogy nem talál egy oldalt, akkor exception-t dobjon, amikor az egy belekalkulált működés, szerintem; az exception számomra egy kerülő megoldás, ahol ide-oda ugrálunk a kódban.
Itt tulajdonképpen arról van szó, hogy milyen 'hiba' vagy kivételes eset fordulhat elő többször, amire számítani kell, és mi a valódi hiba (ez utóbbi esetben érdemes kivételt használni). Nem láttam még olyan keretrendszert, ami kivételdobásokra alapozta volna a működését.Nekem ez az álláspontom. Nem éles a határ, hogy mikor érdemes kivételeket használni, nem egyértelmű eldönteni, de én ott például, ahol user input validálást csinálok, számítok rá, hogy rossz lesz az input, és nem fogok kivételeket dobálni rossz inputra.
Egyébként meg mindenki úgy programoz, ahogy akar.
...A dokumentálás meg egyáltalán nem alap, gyors fejlesztési ütemben pedig mindig elmarad, de aki megtanul tiszta kódot írni, az a többi fejlesztő munkáját megkönnyíti.
-
Sk8erPeter
nagyúr
"Kivételkezelést akkor érdemes használni, amikor egy mély hívássorozat alján keletkezik valahol egy kivételes hiba, és ezt sokkal fentebbi függvényben akarod lekezelni. Ilyen például az adatbázis absztrakciós rétegekben egy mysql hiba, ami, ha jó a kódod, ritkán fordul elő, és általában elég csak annyira foglalkozni vele, hogy loggolod."
1.) Nem értem, ez miért változtat azon az állításomon, hogy átláthatóság szempontjából mindenképp jobb. Azt hittem, a privátban kitárgyalt kód meggyőző volt ennek alátámasztására.
2.) A MySQL-hiba jobb esetben - pl. elég ritka, hogy az adatbázishoz tartozó service lehal - valóban ritkán fordul elő. De azért ne csináljunk úgy, mintha csak ennyire szélsőséges esetekre lehetne alkalmazni a kivételeket."Ha a kivételkezelést általános programozási gyakorlattá teszed, annak megvan az a hátránya, hogy később, ha ránézel a kódra, nem biztos, hogy fogod tudni, hogy a kivételedet hol dobod (ahogy említetted, amíg ténylegesen nem történt ilyen exception, akkor stacktrace), és amikor refaktorálod a kódot, fogni fogod a fejed."
Ezt pontosan azért nem értem, mert az előző hozzászólásomban éppen azt hoztam fel a kivételek egyik előnyeként, hogy a lehető legegyszerűbb kideríteni, honnan származik a kivétel, és naplózás esetén nálam legalábbis alap, hogy a kivételek forrását is naplózom: melyik fájlban keletkezett a kivétel, melyik függvényben, a fájlnak pontosan melyik sorában, mikor, stb. Ezeket az exceptionökből a lehető legegyszerűbb feladatok egyike kideríteni, így pontosan ezért nem értem, miért is lenne érv jelen esetben az, hogy "nem biztos, hogy fogod tudni, a kivételedet hol dobod" - dehogynem, pontosan fogom tudni: lásd pl. getFile(), getLine(), getTrace() vagy épp getTraceAsString() függvények...Régen, mielőtt a kivételkezelést egyáltalán alkalmaztam volna, pontosan az volt a bajom, hogy sok esetben nehezen visszakövethető, hogy konkrétan hol is történt a hiba, és milyen jellegű is volt. Most meg pl. ránézek a naplóra, és egész pontosan meg tudom nézni, hol és mi is történt, valamint a kivétel mikor keletkezett.
"Ha az osztályodat majd újra fel akarod használni, nem szabad megfeledkezni arról, hogy milyen kivételeket dobhat. Amíg jól van dokumentálva a kódod, addig nem biztos, hogy fejtörést fog okozni, de ha már kevesebb időt töltesz a dokumentálással, valahol újra fel akarod használni a kódodat, szintén fogni fogod a fejed, mert fejlesztés során olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak, ahogy az osztályod egyre többet tud."
Kezdjük azzal, hogy szerintem a rossz dokumentáció egyik esetben sem segít a későbbi fejlesztésekben, ebből a szempontból teljesen lényegtelen, hogy most kivételeket dobálsz, vagy az adott esetben túlságosan is kövérre hízó, macerás if-else blokkokat alkalmazod.
Ha pedig említetted az error tömbök visszaadását: ha épp a szar dokumentáció és az újrafelhasználás a példa, akkor hogyan emlékezz vissza, hogy mi is volt a megfelelő hibakezelési mód? Pl. hogy az error tömböd milyen formában érkezik, vegyünk egy példát:
$functionReturnValue = $myClass->myMethod();
if( $functionReturnValue['status'] == FALSE ){
......
}
else {
....
}Aztán kiderül, hogy basszus, nem is $functionReturnValue['status'] a megfelelő vizsgálandó visszatérési érték indexe, hanem mondjuk $functionReturnValue['result'].
Ha viszont eldobsz egy kivételt a hiba forrásánál, az garantált, hogy itt minél előbb megtudod, hol keletkezett a hiba (pl. ha fent van egy Xdebug extension, akkor az még szép táblázatos formában ki is írja neked), és nem próbálod folytatni a programkódot a rossz visszatérési értékekkel, stb.De hogy még reagáljak arra is érdemben, hogy "olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak":
erre röviden az az egyszerű reakció, hogy ha az egész try-catch blokkod legvégére a kivételosztályok ősosztályának elkapását is elintézed, akkor nyilván nem mondok újat azzal, hogy így minden kivételt elkapsz, azt is, ami specifikusan nem volt lekezelve.
Ezeket pedig szintén naplózhatod, és akkor tudod, hogy még milyen kivétel nincs lekezelve.
Pl.:
try {
$stuff = new MyClass();
// exceptiont fogsz eldobni, mégpedig így:
// throw new MyNewException( 'asdasd' );
$stuff->myMethod();
} catch ( MyOldException $e ){
...
} catch ( AnyOtherException $e ){
...
} catch ( Exception $e ){
...
// itt elkapod a többit!!!
}Így tehát azt az esetet is lekezelted, amit előre nem láttál - a másik esetben sokkal nehezebb ennyire általános receptet adni az "egyéb" kategóriába eső hibák megfelelő kezelésére és naplózására.
-
PazsitZ
addikt
Nem értem ezt az exception költséges dolgot.
Az oop is költséges, főképp korábbi php verziókban.
De valamit valamiért.
Az meg hogy ilyenekkel nyersz 1 századmásodpercet, nem hiszem, hogy mérvadó.(#8995) modder:
Nem értem mi a problémád az exceptionnel?
Avagy mivel váltod ki, ami szerinted jobb/átláthatóbb?nem biztos, hogy fogod tudni, hogy a kivételedet hol dobod
A kivételed jobb esetben megmondja mi a hiba, így illene tudnod, hol dobod. A modul vagy egyéb logikai egységhez dedikált kiterjesztett kivételosztályról nem is beszélve, ami teljesen egyértelművé teszi, miért és hol használod. Legrosszabb esetben egyébként pedig egy stacktrace meg nehogy már ördögtől való körülményes találmány legyen.
Az hogy dokumentálsz alap, plusz egy exception annotációba - amit jobb esetben az IDE kapásból kigenerál neked- nem kellene belehalni.A kivételek öröklődése és funkcionális kiterjeszthetősége (pl. logolás), amit említettek is, meg csak hab a tortán a használata mellett.
-
modder
aktív tag
válasz
Sk8erPeter #8994 üzenetére
Én csak ezzel nem értek egyet:
a kivételkezelés akkor is ezerszer átláthatóbb hibakezelési formaKivételkezelést akkor érdemes használni, amikor egy mély hívássorozat alján keletkezik valahol egy kivételes hiba, és ezt sokkal fentebbi függvényben akarod lekezelni. Ilyen például az adatbázis absztrakciós rétegekben egy mysql hiba, ami, ha jó a kódod, ritkán fordul elő, és általában elég csak annyira foglalkozni vele, hogy loggolod.
Vissza a fenti mondathoz. Ha a kivételkezelést általános programozási gyakorlattá teszed, annak megvan az a hátránya, hogy később, ha ránézel a kódra, nem biztos, hogy fogod tudni, hogy a kivételedet hol dobod (ahogy említetted, amíg ténylegesen nem történt ilyen exception, akkor stacktrace), és amikor refaktorálod a kódot, fogni fogod a fejed.
Még egy dolog.
Ha az osztályodat majd újra fel akarod használni, nem szabad megfeledkezni arról, hogy milyen kivételeket dobhat. Amíg jól van dokumentálva a kódod, addig nem biztos, hogy fejtörést fog okozni, de ha már kevesebb időt töltesz a dokumentálással, valahol újra fel akarod használni a kódodat, szintén fogni fogod a fejed, mert fejlesztés során olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak, ahogy az osztályod egyre többet tud.Ezt a Dependency Injectionhöz tudom hasonlítani. Ott arról van szó, hogy bizonyos műveleteknek vannak előfeltételei, előfeltétel objektumai, és addig átlátható, amíg a függvények bemenetein megjelennek ezek az előfeltételek, mert addig nyomonkövethető a kdóban az előfeltétel.
Egy szó, mint száz. Nem érdemes általános gyakorlattá tenni a kivételek dobálását. Form validálásnál még talán elmegy. De ezt is lehet hit kérdéssé tenni, nem muszáj rám hallgatni
-
Sk8erPeter
nagyúr
"csak amennyire tudom szeretném elkerülni a kivételeket"
Szerintem ez egyáltalán nem indokolt. Még ha a futási időhöz hozzá is teszel párszázadmásodpercnyit, a kivételkezelés akkor is ezerszer átláthatóbb hibakezelési forma, mint pl. a hatezer soros if-else blokkok. A kivételkezelésnél ezenkívül a saját kivételosztályaidat is felhasználhatod, az Exception osztály felülbírálásával, amibe tetszőleges kódot pakolhatsz, többek közt pl. naplózást, ami igen fontos lehet, és esetfüggő lehet, mit, hogyan és hova szeretnél naplózni. Viszont egy form esetén pl. nyilván nem naplózol, ha egy mezőt nem töltöttek ki. Ha az if-else blokkos megoldást választod, akkor viszont naplózási igény esetén azt valahogy bele kell tákolnod a blokkjaidba, nem marad egy szeparált helyen, ahogy pl. a kivételosztályaidat kigyűjtheted egy teljesen különálló fájlba. Nem beszélve arról, hogy a kivétel forrása (melyik sorban, melyik fájlban dobódott, stb.) nagyon könnyen felderíthető a kivétel elkapásakor, teljesen mindegy, hol, melyik függvényen belül dobtad el, azt a try-catch blokkban elkapod, majd lenyomozod, mi is volt a baj.
Egy szó, mint száz: a kivételkezelés szerintem épp, hogy nem egy kerülendő dolog, hanem érdemes alkalmazni.Egyébként pl. a PDO-nál is lehet "hagyományos úton" is hibákat kezelni, meg lehet úgy is inicializálni, hogy megmondod neki, hogy kivételeket dobjon, ne visszatérési értékeket kelljen vizsgálgatni, ami csak feleslegesen csinál a kódodból spagettikódot. Nem tudom, hogy vagytok vele, de én maradok a kivételkezelésnél.
-
Speeedfire
félisten
válasz
Sk8erPeter #8984 üzenetére
Nem rossz megoldás, egyszer ha lesz hozzá kedvem lehet, hogy nekiesek és megpróbálom megoldani, mert jópofa és a usernek is segít.
mobal: F12? -
modder
aktív tag
szerintem ez, hogy kivételt dobsz, vagy hogy kezeled le azt, ha nem talál a keretrendszered egy oldalt, az rajtad múlik. Általában ugye úgy működik egy mvc architektúrájú keretrendszer, hogy megkeresi az url vagy route alapján ráillő kontrollert.
Lehet az, hogy nincs meg a kontroller vagy nincs meg a kontroller által kiszolgálandó erőforrás, például cikk, termék.
Ha nem találja a kontrollert vagy az adott oldalt, cikket, akármit, amit beírt a felhasználó az url-be, akkor akár helyben is -- ott ahol kiderült, hogy nincsen sehol a kérdéses erőforrás -- küldhetsz az outputra egy 404-et, majd "szép leállást" produkálsz pl. zárod a logokat. Erre csinálhatsz egy függvényt vagy beleraod a response osztályodba, és hívsz egy iylet, hogy $this->response->out_404();
Így meg mindegy, hogy exception-t dobsz-e vagy helyben egy függvényen belül kezeled-e le a dolgokat, mert hiba esetén meghívni egy exception-t vagy egy függvényt ugyanannyi kódolás minden esetben, bár utóbbinál legalább nem operálsz exceptionökkel.
-
válasz
Sk8erPeter #8982 üzenetére
Jó csak amennyire tudom szeretném elkerülni a kivételeket. De akkor ezekszerintjólgondoltam!
-
Sk8erPeter
nagyúr
válasz
Speeedfire #8983 üzenetére
Az ötlet jó, egy ilyen jellegű megoldás pl. ehhez hasonló lehet: [link]
Ez a cikk írójának saját megoldásával korábbi Drupal-verzióhoz azt csinálta, hogy a request URI-t felbontotta, és eszerint futtatott le egy keresést. Ezt a keresést mondjuk be kellene helyettesíteni egy alias-kereséssel, ráadásul itt nem gondol az ékezetes karaktereket tartalmazó URL-ekre, amiből manapság már bőven van (lásd pl. drupal.hu).
Persze ez most a felvetésedre nem megoldás, szóval nem egy kész, hűdefasza kód, de legalább valaki próbált nyekeregni egy kicsit erőltetetten a témában, azért linkeltem.
Igazából én is csak most kerestem rá, eddig nem jutott eszembe alias szerint keresgélni és javaslatokat mutatni, de tényleg jó ötlet lehet, főleg, hogy az aliasok jobb helyeken adatbázisban, külön erre szentelt táblában találhatók, így normális indexeléssel egy ilyen táblában való kutakodás elég gyors lehet. -
Speeedfire
félisten
Korrekt! A jobb framework-ök, cms-ek is ezt csinálják. De ami a legjobban bejött és nem láttam még kész megoldást rá.
pl valaki erre linkel, hogy http://valami.hu/kis-suti-eves-volt-pesten
erre dobja, hogy 404, de olyat talál az adatbázisban, hogy:
http://valami.hui/nagy-suti-eves-volt-pesten vagy http://valami.hui/kis-suti-eves-volt-gyorben és felajánlja neked, hogy nem ezt akartad?
Jóféle dolog, de gondolom valami alapján felbontja a requert url-t és úgy keresgél az adatbázisban vagy valami ilyesmi. -
Sziasztok!
Az úgy jó megoldás, ha nem talál az oldal mondjuk egy bejegyzést, akkor dob egy 404 es kivételt, amit a framework lekezel, és megjeleníti a hozzá tartozó hibakóddal az hiba oldalát?
-
modder
aktív tag
válasz
spammer #8977 üzenetére
szerintem is, kukis az biztos működni fog, és viszonylag egyszerű is, ha csak cikkszámok listájáról van szó. esetleg megnézhetsz valami LocalStorage dolgot (keress rá). ez asszem ilyen HTML5-ös szabvány.
Ha nincs DB, még a cikkszámra kattintva akár egy AJAX-os megoldással (hogy ne töltődjön újra az oldal) session változóba is mentheted a cikkszámokat.
-
spammer
veterán
Na szakik, lenne egy kérdésem, bár nem tudom, kivitelezhető-e, amit akarok
- Van egy megrendelőlap (php) form, textfield, textarea stb. ami emailben küldi el az adatokat.
- Aztán van egy terméklista oldal, képekkel, cikkszámmal stb, szintén php.Meg lehet-e oldani azt, hogy a terméklistás oldalon mondjuk egy termék kódjára/cikkszámára kattintva azt a kódot beírja a megrendelőlap megfelelő "rovatába" (textarea).
Nincs adatbázis, szóval valamilyen cookie-s megoldásra gondoltam, így több terméket is rá lehetne küldeni a megrendelőlapra, és nyilván kellene egy "törlés" opció is, ha netán mégis más termék kellene, akkor ne ragadjon be cookie miatt.
Megoldható ilyen módszerrel?
-
raczger
őstag
válasz
Sk8erPeter #8975 üzenetére
sikerült megoldanom és végül nem ezzel volt a probléma... egy-két fájlt nem töltött fel/le rendesen, ebből adódott a probléma, korábban volt hasonló problémám, azt hittem ugyanez lesz a baja de nem, köszi a segítséget
-
Sk8erPeter
nagyúr
válasz
raczger #8974 üzenetére
.htaccess fájlba tetted? Mondjuk gondolom igen. Elég furcsa, hogy nem működik. Végül is lehet, hogy az Options direktíva buzerálását le tudja tiltani a szolgáltató, mondjuk eléggé hülyeség lenne a részükről.
[link]
Pedig ez olyan opció, ami állítható.De inkább közelítsük meg másfelől a kérdést: akkor a rewrite rule-lal lehetne valamit babrálni.
Vegyük példának a Drupalt, ott is minden egyes kérés, ami nem fájlrendszerben létező fájlra vagy könyvtárra vonatkozik, ráfut az index.php-re:# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
### ...........
# Pass all requests not referring directly to files in the filesystem to
# index.php. Clean URLs are handled in drupal_environment_initialize().
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]
</IfModule>A drupal_environment_initialize() függvény kezeli a továbbiakat.
A korábbi, 6-os verziónál még így nézett ki:
# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>Tehát itt explicite a q paraméternek adódott át a kérés, ezt a Drupal pedig lekezelte magának.
-
raczger
őstag
válasz
Sk8erPeter #8973 üzenetére
köszönöm, de ez nálam nem működik... lehetséges, hogy a szolgáltató ezt tudja korlátozni, az ilyen beállításokat?
-
Sk8erPeter
nagyúr
-
raczger
őstag
Remélem ide még elfér egy htaccess probléma. A gondom az, hogy az alábbi url rwerite apache 2.0-nál tökéletesen működik, 2.2-nél viszont nem:
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) index.php [QSA]
Mindössze az a célom, hogy bármely nem létező url-nél az index.php-t hozza be. Valamiért a 2.2-nél, ha pl a /tagok/lista url-t szeretném behozni, ez automatikusan a /tagok/lista.php-t tölti be (miért adja hozzá automatikusan a kiterjesztést???), de ha a /tagok/lista.php-t szeretném direktbe behívni, akkor nem érzékeli mint létező fájlt, ezért az index.php-t tölti be. -
modder
aktív tag
válasz
Sk8erPeter #8969 üzenetére
Ó, ezt nem tudtam. Köszönöm a kiegészítést!
-
Sk8erPeter
nagyúr
Érdekesség, hogy ez a szintaxis a PostgreSQL-lel való kompatibilitás miatt került bele:
SELECT Syntax - LIMIT clause
"For compatibility with PostgreSQL, MySQL also supports the LIMIT row_count OFFSET offset syntax."Egyébként:
"LIMIT takes one or two numeric arguments, which must both be nonnegative integer constants (except when using prepared statements).
With two arguments, the first argument specifies the offset of the first row to return, and the second specifies the maximum number of rows to return. The offset of the initial row is 0 (not 1):
SELECT * FROM tbl LIMIT 5,10; # Retrieve rows 6-15
To retrieve all rows from a certain offset up to the end of the result set, you can use some large number for the second parameter. This statement retrieves all rows from the 96th row to the last:SELECT * FROM tbl LIMIT 95,18446744073709551615;
With one argument, the value specifies the number of rows to return from the beginning of the result set:SELECT * FROM tbl LIMIT 5; # Retrieve first 5 rows
In other words, LIMIT row_count is equivalent to LIMIT 0, row_count."A phpMyAdmin is utóbbi szintaxist használja.
Persze teljesen jó az említett OFFSET-et tartalmazó szintaxis, meg talán kifejezőbb is a query általa, de említésre méltó az idézett változat is, hátha valaki azt ismeri jobban - MySQL query-knél én utóbbit gyakrabban szoktam látni kész kódokban (nyilván a másikra is bőven akad példa). -
modder
aktív tag
A paginálás nem egyszerű dolog. Gyakorlatilag kell egy olyan osztály, ami képes egy k : [1,n] (ahol k az oldal száma) egész számot leképezni az adatbázis által visszaadott rekordok intervallumaira.
page 1 -> mysql sorok(0,10)
page 2 -> mysql sorok(11, 20)
...Itt a mysql lekérdezésben a LIMIT és az OFFSET-tel szoktak operálni (MySQL-ben), vagy ha az adatbázis interfészed tud ilyen funkcionalitást megvalósító fv-eket, akkor azzal.
kb ez úgy néz ki, hogy ha tudod, hogy 1 oldalon 30 elemet akarsz megjeleníteni, akkor osztályod úgy készíti el az adatbázis lekérdezést az elemeidre, amiket meg akarsz jeleníteni, hogy:
$sql .= ' ORDER BY ido DESC LIMIT 30 OFFSET ' . $page * 30 . ';';
van nagyon sok működő megoldás neten, csak keresgélj.
-
Helló!
Segítsetek! Hogyan tudnám megoldani legegyszerűbben a lapozás témát?
Pl.:
http://my-website.com/archive/2012/03/page/1
Erre gondolok. Milyen jó megoldás létezik rá? És esetleg olyan amit több függvényre is rá lehet húzni?
Pl.:
http://my-website.com/archive/2012/03/page/1
http://my-website.com/articles/2012/03/page/1Két külön metódus, egy kontrollerbe - archive és articles - de maga a "page" generálo dolog ugyan az.
Köszi!
mobal
-
cAby
tag
válasz
Sk8erPeter #8938 üzenetére
Köszi, akkor körülnézek majd AJAX témában.
-
Sk8erPeter
nagyúr
válasz
Peter Kiss #8963 üzenetére
Jaja, vágesz, szerencsére szép lassan fejlődget a PHP. Most moddert UTÁNOZVA (
) feliratkoztam én is a PHP Internals levlistára, ott éppen arról tárgyalnak, hogy a C#-os getter-setterhez hasonló metódusokat a __get() helyett vagy mellett be lehetne tenni a core-ba.
Egyetértek, totál semmi értelme annak a kódnak, amit írt. Igazából ezt most ezzel együtt már harmadjára írom le.
De megmondom őszintén, annak az eval()-os példának sincs túl sok, amit imént írtál.Beraktad egy stringbe, kiértékelted, és?
-
Peter Kiss
őstag
válasz
Sk8erPeter #8954 üzenetére
Az első forma karcolja a hülyeség fogalmát, és valóban nem fordul le minden nyelven.
PHP 5.3 óta egyébként van egyszerűsített is:
$tmp = $someVariable ?: "Hello world";Ha $someVariable létezik, és true-t ad a kiértékelés folyamán, akkor az ő értékét veszi fel a $tmp, egyébként "Hello world" lesz. Ha a $someVariable nem létezik, error.
---
#8961: __call-lal nincs kódkiegészítés, és nyilván szar ötlet eval()-lal használni, de lehetséges. Bár látszólag csak overhead-et pakol a kódba, ha ilyet használ valaki.
-
modder
aktív tag
válasz
Peter Kiss #8959 üzenetére
jajj
el lehet játszani ilyenekkel, de ugyanehhez a funkcionalitáshoz elég csak egy __call() fv-t használni -
Peter Kiss
őstag
-
modder
aktív tag
válasz
Sk8erPeter #8956 üzenetére
ez esetben csak vicceltem!
amúgy én lehet, hogy "picsahülye vagyok az egészhez", de valamelyik programnyelvben akkor is hibát dobott a példakódra
(C vagy Java talán vagy mind2)
-
Speeedfire
félisten
válasz
Sk8erPeter #8954 üzenetére
Igyekszem megjegyezni.
-
modder
aktív tag
válasz
Sk8erPeter #8954 üzenetére
nem beszélve arról, hogy emlékeim szerint le sem fordul így
isset($_POST['hirlevel']) ? $hirlevel = 'igen' : $hirlevel = 'nem';(talán lehet vele trükközni, hogy kapcsos zárójelbe teszed, de lehet, hogy akkor is kell az egyes ágaknak visszatérési érték)
-
Sk8erPeter
nagyúr
válasz
Speeedfire #8943 üzenetére
Ezt már korábban írtam, de ennek ebben a formában nem sok teteje van:
isset($_POST['hirlevel']) ? $hirlevel = 'igen' : $hirlevel = 'nem';Így tulajdonképpen nem indokolt, hogy miért ne használd inkább az if-else formát.
Akkor már itt is leírom úgy, ahogy még értelme is van ezt a formát használni:
$hirlevel = isset($_POST['hirlevel']) ? 'igen' : 'nem';
Így még teljesíti is azt a célt, hogy érdemben lerövidíti a kódot, és nem kell ugyanazt a változónevet ismételgetni (ahogy pl. egy if-else feltételvizsgálatnál). Meg utóbbi formában gyorsan átlátható, milyen értéket szeretnél egyből hozzárendelni, és milyen feltételtől teszed azt függővé. -
Közvélemény kutatás: ki milyen php frameworköt használ?
-
PazsitZ
addikt
válasz
Speeedfire #8949 üzenetére
A modelleknek CActiveRecord van egy isNewRecord property-je, ami alapján meg tudja állapítani insert vagy update művelet szükséges.
Bár ez a property állítható, de ebben az esetben még a primaryKey hibás értékre mutat.
Tehát a setPrimaryKey-vel az elsődleges kulcsot is állítanod kell a helyes működéshez.A fent említett módszer helyett viszont sokkal inkább ajánlott a költségesebb, de helyes működést garantáló new Model(); létrehozás, minden új sor beszúrásánál.
-
modder
aktív tag
válasz
Speeedfire #8947 üzenetére
Beállította magának, hogy update lesz? Te lehet, hogy jobban vágod a YII működését, de nem hiszem, hogy intuíció alapján csinál dolgokat
Szerintem ha újat akarsz hozzáadni, minden iterációban példányosíts egy új Items-t.
(Én Kohanával dolgoztam, és ott úgy van az ORM modell, hogy egy példány<-->egy rekord az adatbázisban, persze komplexebb modelleknél, ahol több táblába akarsz egyszerre menteni meg blabla, felül lehet definiálni a működést, de alapból így van)
-
Speeedfire
félisten
Aha, minden egyes ciklus lefutásnál meglestem és hát valóban, ő beállította magának, hogy ha ilyen sok van akkor ez biza update lesz.
A fene a p*ofáját, hogy ennyire okos.
Már csak meg kell neki mondani, hogy ez nem update, hanem insert lesz. Keresgélek, de szerintem menni fog.
Nem igazán tudom, hogy lehetne hozzáadni a modellhez, szóval... -
modder
aktív tag
válasz
Speeedfire #8941 üzenetére
úgy tűnik, yii-t használsz, úgyhogy elég speckó a kérdésed. én azzal még nem foglalkoztam. kéne tudni, hogy működik az new Items nevű modelled.
Ami amúgy egyből feltűnik a fileHandler függvényedben, hogy itt
$model->name = $fullImgName;
$model->size = $instance->size;
$model->type = $type;ugyanarra az objektumra állítod be mindig az értékeket, és utána elmented. Ha ez egy ORM-es cucc, akkor az első mentés után generál egy id-t a PRIMARY KEY-hez, majd ugyanazt a rekordot módosítja újra és újra minden iterációban. (Nem tudom, mi az az $instance, meg ezek, de nem látom, hogy a modellben lenne valami belső léptetés az új elemeknek).
Remélem elég sugallatot adtam
-
modder
aktív tag
ez számtalan helyen elromolhat. kezdve attól, hogy nem jó a javascript XMLHTTPRequest küldés, nem jó a feldolgozó php (bár ezt kétlem), nem jól nyered ki a requestből az adatot.
Szóval lehetnél specifikusabb, hogy mi nem jó.
Egybként ami feltűnik, hogy relatív útvonalat használsz az XMLHttpRequestben, a HTML fájlod pedig a html mappában van, tehát a request az a hostnev/html/apn.php -ra fog irányulni, első meglátásra.
tegyél az url elé egy per jelet, hogy a hostod gyökerétől mérje az url útvonalát: "/apn.php?blabla"
Azt pedig, hogy hogy kell a problémát megkeresni, hagy ne kelljen elmondani
mind chrome-ból vagy firefoxból nyomon tudod követni a javascripted futását, és kiírja a hibákat, érdemes nézni a böngészőből a request-responseokat is, mert ott látod, hogy egyáltalán elment-e a kérés és milyen válasz jött rá
-
spammer
veterán
válasz
Speeedfire #8943 üzenetére
A 2. módszerrel csináltam, működik! Nagyon szépen köszönöm!
-
Speeedfire
félisten
válasz
spammer #8942 üzenetére
Van egy checkboxod, pl ez:
<input type="checkbox" name="hirlevel" value="igen" />Amikor feldobozod akkor meg:
isset($_POST['hirlevel']) ? $hirlevel = 'igen' : $hirlevel = 'nem';
//vagy
if(isset($_POST['hirlevel'])) { $hirlevel = 'igen';} else { $hirlevel='nem';}Majd a "nagyok" megmondják, hogy melyik a jobb.
-
spammer
veterán
Van egy megrendelőlapom, textarea, textfield stb.. ezeket szépen elküldi mailben, eddig oké. Viszont van egy checkbox, aminek az értékét el kellene küldeni. Pl. ha vásároló bepipálja, akkor mondjuk elküldi az igen szót, ha nem pipálja be, akkor elküldi a nem szót.
Hogy lehet ezt rohadt egyszerűen megoldani?
Mert $_POST dolgokkal próbáltam, textfieldnél működik, de checkboxnál nem.
-
Speeedfire
félisten
Hogy lehet egy adott adatbázis modellbe több ugyan olyan tartalmat beilleszteni?
Egy fájlfeltöltést szeretnék, ahol több képet és több videót is lehet feltölteni. A fájlokat szépen fel is tölti ellenben, az adatoknál csak egy-et tölt fel az adatbázisba. Megnéztem a modell-t és hát, csak egy bejegyzés van benne. Így nem is csodálom, hogy csak 1x van ott.public function myFileHandler($model, $imgFieldNameArr){
foreach($imgFieldNameArr as $attribute){
$instances = CUploadedFile::getInstances($model, $attribute);
$i=0;
foreach ($instances as $instance) {
if($instance){
$fullImgName = md5(time().$i).'.'.$instance->getExtensionName();
if($attribute=='image') { $type = 1; $tipus = 'kepek'; }
if($attribute=='video') { $type = 2; $tipus = 'videok'; }
$fullImgSource = Yii::getPathOfAlias('webroot').'/assets/'.$tipus.'/'.$fullImgName;
$model->name = $fullImgName;
$model->size = $instance->size;
$model->type = $type;
/*if($model->save()) {
$instance->saveAs($fullImgSource);
}*/
}
$i++;
}
}
var_dump($model); exit;
return true;
}public function actionCreate()
{
$model=new Items;
// Uncomment the following line if AJAX validation is needed
//$this->performAjaxValidation($model);
if(isset($_POST['Items']))
{
$model->attributes=$_POST['Items'];
if($model->validate(array('image','video'))) {
if($this->myFileHandler($model, array('image','video'))) {
$this->redirect(array(Yii::app()->baseUrl));
}
}
}
$this->render('create', array('model'=>$model));
}Próbáltam már, hogy csak a végén mentem a modell-t, úgy is hogy minden egyes fájl után, de valami nem stimmel nála.
-
Jim-Y
veterán
Na hali, van egy rövid kódom, és nem akar működni
kérlek nézzetek rá, nagyon alap, úgyhogy nem lesz nehéz válaszolni, de én süket vagyok most ehhez:/
Először is: fastruktúra
[root]
---[css]
------mystyle.css
---[html]
------popup.html
---[js]
------apns.js
manifest.json
apn.phppopup.html:
<html>
<head>
<link rel="stylesheet" type="text/css" href="../css/mystyle.css" />
<script type="text/javascript" src="../js/apns.js"></script>
</head>
<body>
<div id="popup_container">
<p id="apn_result">APN result here...</p>
</div>
<button type="button" onclick="loadXMLDoc()">Change Content</button>
</body>
</html>apns.js:
function loadXMLDoc()
{
var xmlhttp;
if (window.XMLHttpRequest) {
xmlhttp=new XMLHttpRequest();
} else {
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.onreadystatechange=function() {
if (xmlhttp.readyState==4 && xmlhttp.status==200){
document.getElementById("apn_result").innerHTML=xmlhttp.responseText;
}
}
alert(xmlhttp.responseText);
xmlhttp.open("GET","apn.php?q=checkapn",true);
xmlhttp.send();
}apn.php:
<?php
$q=$_GET["q"];
if ($q == "checkapn")
{
$response="Your APN is ...";
}
else
{
$response="No APN-s found";
}
echo $response;
?>Megj: ugye ez azt csinálná, hogy ha rákattintok a gombra, akkor az felvenné a kapcsolatot a php kóddal, url-hez hozzácsapná, hogy "checkapn".
A PHP leelenőrzi, és ha url-ben "checkapn" jött, akkor response-ban tök minden, hogy mit, de visszaküld valamit, amit a javascript hozzácsap az egyik HTML taghez.De nem megy:/
megj2: az apn.php-t az összes mappába bemásoltam, hátha az utvonal nem megfelelő, de még mindig semmi..
[ Módosította: 7 ]
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #8938 üzenetére
Kifejtem kicsit, miért írtam, hogy picit "gányolás" a második megoldás. Önmagában természetesen a különböző azonosítóval ellátott id-khoz ugrálás egyáltalán nem gány, sőt, gyakran alkalmazott módszer, gondolom ezzel nem mondtam újat (lásd akár Wikipédia, stb.).
Az említett módszer viszont nem minden esetben működik. Vegyük azt az esetet, hogy a formot egy teljesen más feldolgozó fájlba irányítjuk, majd a feldolgozó fájlból PHP segítségével (header fv.-nyel) visszairányítjuk, a visszairányítás után a megfelelő üzeneteket kiírjuk, stb... Ebben az esetben hiába rakjuk a feldolgozó fájl neve mögé a hashmarkos fragmentet, azt a szerveroldal nem fogja megkapni, tehát nem is tudjuk beállítani a visszairányítós részhez.
Erre is van azonban kerülő megoldás: ha a formba beleteszünk pl. egy hidden mezőt, amiben eltároljuk annak a div-nek (vagy más HTML-elemnek) az azonosítóját, amihez majd ugrani szeretnénk a form feldolgozása után, és így állítjuk össze a címet, amihez szeretnénk átirányítani a felhasználót:
(legegyszerűbb példával)// visszairányítás
$filepath = 'test_jump.php';
$id_of_div = $_POST['id_of_div'];
header('Location: '.$filepath.'?#'.$id_of_div);
die();Ebben az esetben (ha már nem AJAX-szal küldjük el a formot) viszont figyelni kell arra is, hogy a form validálása/feldolgozása után kiírt üzenetek (ez vagy az a mező hiányzott, stb.) is a meghatározott id-jű div-be kerüljenek. Persze az is megoldható, hogy csakis hiba esetén írjon ki valamit, és akkor viszont annak megfelelően módosítjuk a fragmentet...
Na, ezek miatt írtam, hogy alaposan megbonyolítja a kódot, és innentől akár már nevezhető gányolásnak is. Bár lehet, hogy erős szó rá. -
Sk8erPeter
nagyúr
Igen, AJAX-szal.
Persze lehet gányolni is, pl. úgy, hogy egyes bekezdéseknek id-t adsz, majd megoldod, hogy odaugorjon a feldolgozást követően a böngésző, ahogy itt ebben a példában ugrabugrál a linkekre kattintva: [link], formhoz úgy lehet megoldani, ha pl. ha a hash-sel kiegészített cím van az action attribútumban.
Pl. action="test_jump.php?#blabla" -
cAby
tag
Sikerült megcsinálni, mostmár normálisan működik!
Mostmár csak annyi bajom lenne, hogyha olyan elemet akarok betenni kedvencnek, amihez görgetni kell lefelé az oldalon, akkor miután megnyomom, hogy kedvenc az oldal tetejére ugrik.Meg lehet azt csinálni, hogy az oldal állása ugyan az legyen, mint kattintás előtt?
-
Egy lehetséges megoldás. Kiveszed a bannaereket, belerakod egy tömbbe, mindegyikhez hozzárendelsz egy értéket - hogy mennyi az esélye mojduk, hogy ő lesz a következő banner, majd hozzáadsz egy bónuszt. Mondjuk + 10, és a prioritás értékével megszorzod. Pl.:
$banner = array(
'1' => '10',
'2' => '15',
'3' => '20',
...
);és akkor a végén így fog kinézni:
- első: 10 + 4 * 10
- második: 15 + 1 * 10
- harmadik: 20 + 2 * 10egyenlőség esetén, meg megint random döntesz
remélem érthető voltam
-
CSorBA
őstag
Ha már ilyen jól pörög a topik, eszembe jutott nekem is valami. (bár igazából sql-es kérdéseim is lennének, de szépen sorban
)
Tegyük fel vannak bannerjeim. Adatbázisban tárolom az adatokat hozzá. A megjelenítés pedig random. No de, szeretnék prioritást.
Mondjuk van egy oszlopom, priortiy, és benne 1-2-3 értékek. Azt szeretném, hogy az 1es mondjuk kétszer olyan sűrűn jelenjen meg, mint a kettes, a hármasnál pedig 4szer. (ugye kb 8ból 4szer (1es prioritás), 2szer (2es prioritás), 1szer (3as prioritás), vagy ahogy tetszik).Hogy tudnám ezt megoldani egy gyors lekéréssel. Lehet-e esetleg pusztán sql-el?
Én arra gondoltam, hogy csinálok egy tömböt, amiben vannak számok, előfordulás szerint. pl. $elofordulasok = array ('1', '1', '1', '1', '2, '2', '3') és innen választok random egy számot, majd az sql lekérdezésben berakom feltételnek ezt (WHERE priority=$elofordulasok[rand(0,7)]). Ennél jobb ötlet? -
Peter Kiss
őstag
válasz
Sk8erPeter #8927 üzenetére
Mint mondtam: ha kellenek a bejegyzések, akkor semmi értelme. De én csak odáig jutottam, hogy nem kellenek, és csak az kell, van-e. Arra írtam ezt. És nem, az eredeti query-t nem szabadna módosítani COUNT(*)-gal.
-
-
modder
aktív tag
Hála a jó istennek
Annyit kell csinálnod, hgoy a formba teszel egy hidden mezőt aminek a neve pl. fav_id, értéke értelemszerűen a favoritod id-ja.
Amikor pedig megnézed, hogy van-e del vagy add, akkor azt is megvizsgálod a ciklusban, hogy a fav_id megegyezik-e az aktuális iterációban vizsgált favoritoddal.Egyébként nem is értem, hogy ez a hiba nálad miért nem jelentkezett. Gondolom volt egyetlen favoritod, és örültél, hogy arra megy
-
cAby
tag
válasz
Sk8erPeter #8929 üzenetére
(#8928) modder és (#8929) Sk8erPeter:
Áááh, nagy nehezen leesett már, hogy mi is ezzel az egésszel a probléma!
(Pedig tök egyértelmű a hiba.)Átgondolom mégegyszer/kétszer az egészet és már menni fog szerintem.
Köszi szépen nektek!
-
Sk8erPeter
nagyúr
Na, akkor most kezdd elölről, egy másik sessionnel. Küldj rá egy session_destroy-t, majd kezdd elölről a folyamatot.
Nagyon nagy csoda lenne valóban, ha a PHP csak úgy magától kitalálná, hogy te melyik azonosítójú elemet is szeretted volna kedvencek közé menteni, mivel szerveroldalon a form elküldése után csak annyi látszik, hogy létezik mondjuk a $_POST['add'], vagy épp a $_POST['del'], tehát megnyomtad a hozzáadó gombot, vagy megnyomtad a törlő gombot, de annak SEMMI nyoma nincs, hogy te most melyik azonosítóhoz tartozó hozzáadó-törlő gombot nyomtad meg. Mégis honnan a büdös francból kellene látnia a szerveroldalnak, hogy mi a szándékod?A CIKLUSON BELÜL van egy ilyen részed:
if ( $_POST['add'] )
{
$_SESSION['fav' . $row['id']] = 'true';
}
if ( $_POST['del'] )
{
$_SESSION['fav' . $row['id']] = 'false';
}Ergo az $sql = "SELECT * FROM items WHERE sitelink = '" . $site_link . "'"; query-d összes eredményén végigrohangászol, majd ha épp létezik szerveroldalon a $_POST['add'] vagy a $_POST['del'], akkor az aktuális cikluslépés sorazonosítójához tartozó sessionváltozóba eltárolod a "true" értéket.
Így ha egyszer megnyomtad azt a szaros gombot, akkor elméletben mindegyik adatbázisban megtalált azonosítóhoz tartozó session-változónál true lesz az érték.De lassan kifogyunk a magyarázat-kombinációkból.
Szerk.:
... és ahogy látom, modder nagyjából ugyanazt írta le közel egyidőben, mint én, más szavakkal.Egyébként könnyebb lenne látnod az egész eredményét, ha mondjuk adott felhasználóhoz nemcsak sessionbe mentenéd a kedvenceit, hanem úgy, ahogy van is értelme, adatbázisba. Mert így csak a munkamenet erejéig fognak élni a kedvencek.
-
modder
aktív tag
Lehet, hogy én vagyok a figyelmetlen, és nem veszek észre valamit a kódban, amiből kiderülhetne az, amire kíváncsi vagyok.
menjünk sorba:index.php:
1) végigiterálsz az adatbázisból szedett favoritokon, mindegyikhez tartozik egy session változó, aminek az értéke true vagy false OK
1.1) kiíratod mindegyik favorithoz, hogy
"<form action='' method='post'>
<input class='fav_false' type='submit' name='add' value=' ' />" . " " . $row['item_name'] . "
</form>
...illetve a del párjátattól függően, hogy a sessionváltozóban true vagy false van-e OK
1.2) mindegyik favoritnál megnézed, hogy $_POST['add'] vagy $_POST['del'] kérés jött-e a fönti formból. NEM OK --> Honnan látod szerver oldalon, hogy az add vagy a del melyik favorit elemre vonatkozik? Hogy jobban megértsd, és nekem is választ tudj adni a kérdésemre, elmondom, hogy szerintem a következőképpen működik az index.php: add vagy del változó megjelenése esetén az összes favorit elemre beállítja a true-t vagy false-t. -
Sk8erPeter
nagyúr
válasz
Peter Kiss #8925 üzenetére
Minél lehet gyorsabb?
Annál kétlem, hogy gyorsabb, mintha ráküldesz egy COUNT(*)-ot az eredeti táblára, az eredeti WHERE feltételekkel, mint az, ha subquery-be teszed az eredeti query-t, max. egyszerűbb megírni.
De ez a számolgatásra történő optimalizálás továbbra sem értem, hogy jön ide.
Ha ráküldesz egy SELECT-et a bejegyzésekre, és lószart sem ad vissza, akkor abból elég egyértelmű, hogy nincs egy darab bejegyzés sem. A megadott dátumok meg eleve korlátozást jelentenek a bejegyzésekre, így nem mindent kérünk le egyszerre, és csak utána szűrünk. A szűrt feltételeknek megfelelő bejegyzéseket lekérjük, és ezután már tudni fogjuk, hogy van-e eredménye a lekérdezésnek.
Azt is lehetne csinálni, hogy először szépen lekérdezed, hogy van-e egyáltalán a feltételeknek megfelelő bejegyzés, majd ha van, akkor egy újabb query-vel ismét lekéred a feltételeknek megfelelő bejegyzéseket, de ekkor már pl. ki is íratod őket, de szerintem teljesen felesleges kétszeri query-t ráküldeni, ha a feladat úgyis csak az, hogy jelenítsük meg az adott dátumhoz tartozó postokat. Ha nincs ilyen, akkor azt jelezzük. -
Peter Kiss
őstag
válasz
Sk8erPeter #8923 üzenetére
Query machinálás query() metódusban:
SELECT COUNT(*) AS resultSetCount
FROM IDE_JÖN_AZ_EREDETI_QUERY AS t0Ebben az esetben 1 darab mző jön le az adatbázisból, és emiatt jóval gyorsabb lehet, ha tényleg csak a rekordok száma érdekel.
---
Én pl. csináltam magamnak Any()-t, ami hasonló a fentihez, de nem csinál sub query-t, hanem berak egy LIMIT-et a végére. Ha jön vissza valami, true, ha nem, false. De van még egy pár ilyen, a teljesség igénye nélkül így oldottam meg a Max(), Min(), Average() hívásokat is.
-
cAby
tag
válasz
Sk8erPeter #8922 üzenetére
(#8919) mobal: Mit kell néznem?
Van sok változó, pl:
fav1 = true; // 1-es azonosítójú kedvenc
fav12 = false; //12-es azonosítójú nem kedvenc
fav3 = true; // 3-as azonosítójú kedvencNekem ez még mindig egyértelműen azonosítja. :\
(#8922) Sk8erPeter:
Ha kiíratom az elem id-ját az is egyértelműen meghatározza. (Plusz több adat is ki van írva, csak, hogy egyszerűbb példa legyen, kivettem a felesleget.)Záró- és nyitó tag azért maradt úgy ott, mert a teljes index.php-ban a 2 rész között szerepel még más is és ezt már külön nem töröltem ki.
-
Sk8erPeter
nagyúr
válasz
Peter Kiss #8921 üzenetére
"Keress egy nagy adatbázist, és számoltasd meg valamilyen feltétel után, hány darab rekord van benne. Utáne tedd meg ugyanezt EXISTS-cel. Na, látod?! "
Ez nem tudom, hogy jön ide.
Ha van egy archívum, amiből csak az adott napra eső bejegyzéseket szeretnéd megjeleníttetni, ráküldesz egy SELECT-et. Akkor már megvan, hány bejegyzést is sikerült lekérni, ezt megtudni pedig nem egy erőforrásigényes feladat a lekérés után."Nyilván, ha kell neki minden post, és nem csak az, hogy van-e benne, akkor okés, csak nem nyálaztam vissza, mi volt a lényeg, csak odáig láttam, hogy true / false jön ki belőle."
Akkor indokolatlan a kötekedés."Egyébként, ha én ORM-et fejlesztek, akkor akár azt ics megcsinálhatom, hogy módosítom on-the-fly a query-t, hogy az adatbázis számolja össze az összes sort, ne pedig a memóriában történjen meg ugyanez."
Ezt kifejthetnéd bővebben is. -
Sk8erPeter
nagyúr
Basszus, adj már egy értelmezhető nevet is a kedvenceidnek... Pl. az adattábládban a különböző azonosítók mellé vegyél fel még egy mezőt, aminek az a neve, hogy mondjuk "fav_name", vagy hasonló, és aztán lekéréskor pedig írasd ki, hogy melyik azonosítót is adtad hozzá a kedvencekhez. Akkor meglátod, hogy valóban jól működik-e.
Nézd is meg, mit csinálsz, ne csak azt csekkold, hogy egy azonosító a sok közül kedvencek közé lett mentve.
Pl. ha a hozzáadható kedvencek a következők: alma, béka, cékla, dió, eke, és én épp a békát szeretném kedvencek közé menteni, akkor nem szeretném, ha helyette ekét kapnék az arcomba.Az index.php-det egyébként így kezded:
<?php
session_start();
?>
<?php
$sql = ......
ahelyett, hogy a tökéletesen felesleges záró- és nyitótaget kiszednéd:
<?php
session_start();
$sql = ...... -
Peter Kiss
őstag
válasz
Sk8erPeter #8911 üzenetére
Keress egy nagy adatbázist, és számoltasd meg valamilyen feltétel után, hány darab rekord van benne. Utáne tedd meg ugyanezt EXISTS-cel. Na, látod?!
Nyilván, ha kell neki minden post, és nem csak az, hogy van-e benne, akkor okés, csak nem nyálaztam vissza, mi volt a lényeg, csak odáig láttam, hogy true / false jön ki belőle.
Egyébként, ha én ORM-et fejlesztek, akkor akár azt ics megcsinálhatom, hogy módosítom on-the-fly a query-t, hogy az adatbázis számolja össze az összes sort, ne pedig a memóriában történjen meg ugyanez. Tetszik érteni?
-
-
cAby
tag
Ez a teljes kód, ami ide tartozik:
index.php
<?php
session_start();
?>
<?php
$sql = "SELECT * FROM items WHERE sitelink = '" . $site_link . "'"; /* $site_link = lekérem az oldal címét, majd olyan formában ahogy nekem kell átadom ennek a változónak*/
$sql_v = mysql_query($sql);
while($row = mysql_fetch_assoc($sql_v))
{
if ( $_SESSION['fav' . $row['id']] == '' )
{
$_SESSION['fav' . $row['id']] = 'false';
}
if ( $_POST['add'] )
{
$_SESSION['fav' . $row['id']] = 'true';
}
if ( $_POST['del'] )
{
$_SESSION['fav' . $row['id']] = 'false';
}
if ( $_SESSION['fav' . $row['id']] == 'false' )
{
echo "<form action='' method='post'>
<input class='fav_false' type='submit' name='add' value=' ' />" . " " . $row['item_name'] . "
</form>";
}
elseif ( $_SESSION['fav' . $row['id']] == 'true' )
{
echo "<form action='' method='post'>
<input class='fav_true' type='submit' name='del' value=' ' />" . " " . $row['item_name'] . "
</form>";
}
}
?>fav.php
<?php
session_start();
?>
<?php
include('sql_connect.php');
$sql_count = "SELECT count(id) FROM items";
$sql_count_result = mysql_query($sql_count);
$row_count_items = mysql_fetch_row($sql_count_result);
$sum_items = $row_count_items[0];
for ($i = 1; $i <= $osszes_szallas; $i++)
{
if ( $_SESSION['fav_' . $i] == 'true' )
{
$sql = "SELECT * FROM items WHERE id='" . $i . "'";
$sql_v = mysql_query($sql);
while($row = mysql_fetch_assoc($sql_v))
{
echo $row['item_name'];
}
}
}
?>Nekem ezzel működik. De már kezdem azt hinni, hogy csak vmi csoda miatt...
-
modder
aktív tag
Itt kiraksz egy formot, de magában a formban egy darab azonosítót nem rejtesz el (mondjuk egy hidden inputtal, vagy másképp), így nem tudom, honnan szeded, hogy mondjuk épp az 5-ös azonosítójút szeretném eltárolni a kedvencek közé.
De ebből még mindig nem tudod szerver oldalon, hogy melyik form lett elküldve, melyik azonosítójú elemet akarod betenni favoritba. Az eddigi kódrészletek alapján így néz ki
//pszeudo
for( $row in $rows){
if( $_POST['add'])
$_SESSION['fav_' . $row['id']] = 'true';
}mivel nincsen semmilyen más favorit azonosító, amit elküldesz a formból a szervernek, nem tudom, honnan kéne tudni szerver oldalon, hogy arra az egy bizonyos favorit elemre vonatkozik a hozzáadás
-
cAby
tag
válasz
Sk8erPeter #8913 üzenetére
Így fogom megtudni, hogy melyiket, mert így csinál egy egyedi session változót, amit true/false-ra állít, és ezt vizsgálja a fav.php oldalon.
if ( $_POST['add'] )
{
$_SESSION['fav_' . $row['id']] = 'true';
}if ( $_POST['del'] )
{
$_SESSION['fav_' . $row['id']] = 'false';
}Először lekérem, hogy mennyi elem van az ab-ban és azt kapja meg a $sum_items.
Nemsokára berakom az erre vonatkozó egész kódot, hogy normálisan látni lehessen.
-
válasz
Sk8erPeter #8911 üzenetére
Igen! Így sikerült is megoldani, reggel már fel is töltöttem
-
Sk8erPeter
nagyúr
"Index.php-ben is nyilván van ilyen ciklus"
Szerintem ez a kódod alapján nem annyira nyilvánvaló."Így működik ahogy akarom, felveszi a listába és onnan el lehet küldeni e-mail-ben."
Honnan fogod tudni, MELYIKET kell felvenni a listába?
Hadd "idézzek" a kódodból:if ( $_SESSION['fav_' . $row['id']] == 'false' )
{
echo "<form action='index.php' method='post'>
<input type='submit' name='add' value='add' />
</form>";
}
elseif ( $_SESSION['fav_' . $row['id']] == 'true' )
{
echo "<form action='index.php' method='post'>
<input type='submit' name='del' value='del' />
</form>";
}Itt kiraksz egy formot, de magában a formban egy darab azonosítót nem rejtesz el (mondjuk egy hidden inputtal, vagy másképp), így nem tudom, honnan szeded, hogy mondjuk épp az 5-ös azonosítójút szeretném eltárolni a kedvencek közé.
Egyébként itt az if-elseif vizsgálat nem túl ésszerű - inkább azt kéne vizsgálnod, hogy mondjuk true értéke van-e, ha igen, kirakod a törlőformot, KÜLÖNBEN (simán else) a hozzáadó formot.Amúgy ha mutatsz egy hasonló kódot, akkor nem ártana a teljeset, hogy el tudjuk dönteni, valamilyen kód indokolt-e egyáltalán.
Az például nem túl szép megoldás, hogy az ismeretlen eredetű $sum_items mennyiségig végigmész az elemeken, és egyesével, cikluslépésenként kéred le adatbázisból a különböző azonosítójú elemeket.További tipp: ha azt szeretnéd, hogy egy form ugyanoda legyen elküldve, ahol ki is van írva, akkor érdemes az action attribútumot inkább üresen hagyni a formnál (action=""), ez egy valid megoldás, és könnyebben "költöztethető" - tehát ha az index.php helyett megváltoztatod a fájl nevét asdasdasd.php-re, akkor is működni fog.
-
cAby
tag
válasz
Sk8erPeter #8911 üzenetére
Tudom, hogy ocsmány. Még nem csináltam ilyet, tehát most próbálkozom összehozni valamit.
Ezért is érdekel más véleménye/tanácsa.Index.php-n a $row['id'] visszaadja az adott elem azonosítóját. Mert ugye listázva vannak az elemek ab-ból, tehát így simán visszaadja az azonosítót, majd csinál egy pl. fav_1 session változót.
fav.php-ban meg megvizsgálja változókat és ha van egyező, tehát van fav_1 és true-n van akkor kiírja."(A fav.php-dben van egy $row az adatbázis-lekérés eredményét megjelenítő cikluson belül, de annak ehhez köze nincs.)"
Index.php-ben is nyilván van ilyen ciklus, csak az kimaradt a kódból és onnan jön a $row['id']Így működik ahogy akarom, felveszi a listába és onnan el lehet küldeni e-mail-ben.
De akkor egy ilyet, hogyan/milyen technikával lenne célszerű megoldani?
-
Sk8erPeter
nagyúr
válasz
Peter Kiss #8910 üzenetére
Nem igazán értem, miért kellene feltétlenül limitálni. Sehol nem írta, hogy az example.com/archive/2011/01/27 oldal megnyitására csak egyetlen darab postnak kellene megjelenni - na meg miért is feltételezzük, hogy aznap csak egyetlen cikk íródott...
"Nem tudom, hogy a count() mit csinál a háttérben"
Nem Kohanáztam soha, de nem nehéz kitalálni, hogy a count a query által visszaadott vagy érintett sorok számát jelenti...
És ja, kb. 5 másodperces Guglizás alapján ki is derül: [link].A lényeg: mivel egy napon nem feltétlenül csak egy cikk készülhetett, ezért nem hiszem, hogy korlátozni kellene a lekérdezés eredményét (legalábbis eddig erről nem volt szó), így a count teljesen jó annak eldöntésére, hogy van-e egyáltalán eredménye a lekérdezésnek...
===
(#8909) cAby : finoman szólva ocsmány a kód (Te kérdezted meg a publikumot
), és azt sem értem, mitől működik nálad úgy, ahogy akarod (sanszos, hogy nem is úgy működik, ahogy kellene), amikor teljesen indefinit, hogy a form elküldésével melyik valamit akarod a kedvencek közé tenni.
Az index.php-dben meg vidáman használod a $row['id']] változót, ami számomra teljesen ismeretlen, hogy honnan kéne, hogy valami valós értéket kapjon. (A fav.php-dben van egy $row az adatbázis-lekérés eredményét megjelenítő cikluson belül, de annak ehhez köze nincs.) -
Peter Kiss
őstag
Nem tudom, hogy jól értem-e. Csak az a lényeg, hogy valamit akkor csinálsz meg, ha ad vissza valamit egy query? Mert akkor limitálni kellene a result set méretét 1 darabra, ne adjon vissza X darabot (ami akár lehetne X is). Nem tudom, hogy a count() mit csinál a háttérben, de érdemes lenne megfontolni a limitálást (MySQL: LIMIT, MSSQL: TOP).
Ilyen módon, ha visszajön 1 darab, akkor true, ha nem, akkor false.
-
cAby
tag
Hali!
Egy olyat szeretnék csinálni, hogy a kilistázott elemek közül (index.php) be lehessen jelölni azt az elemet kedvencnek amelyiket akarjuk. Ekkor annak az elemnek a neve megjelenik egy fav.php oldalon.Megcsináltam és működik ahogyan kell, de ha jól gondolom nem ez a legjobb/legoptimálisabb megoldás. Valakinek esetleg van egy kis tanácsa, hogy lehetne ezt jobban/szebben megcsinálni?
Index.php:
if ( $_SESSION['fav_' . $row['id']] == '' )
{
$_SESSION['fav_' . $row['id']] = 'false';
}
if ( $_POST['add'] )
{
$_SESSION['fav_' . $row['id']] = 'true';
}
if ( $_POST['del'] )
{
$_SESSION['fav_' . $row['id']] = 'false';
}
if ( $_SESSION['fav_' . $row['id']] == 'false' )
{
echo "<form action='index.php' method='post'>
<input type='submit' name='add' value='add' />
</form>";
}
elseif ( $_SESSION['fav_' . $row['id']] == 'true' )
{
echo "<form action='index.php' method='post'>
<input type='submit' name='del' value='del' />
</form>";
}fav.php:
for ($i = 1; $i <= $sum_items; $i++)
{
if ( $_SESSION['fav_' . $i] == 'true' )
{
$sql = "SELECT * FROM items WHERE id='" . $i . "'";
$sql_v = mysql_query($sql);
while($row = mysql_fetch_assoc($sql_v))
{
echo $row['item_name'];
echo "<br />";
}
}
}Köszi.
-
-
modder
aktív tag
válasz
Speeedfire #8904 üzenetére
akkor gondold át
-
modder
aktív tag
válasz
Speeedfire #8902 üzenetére
nem ott szeretted volna!
Gondolom tisztában vagy vele, hogy amikor a modelledhez hozzáadod a napot, a belső ciklusnak csak az utolsó iterációja fog megjelenni a $nap változóban
-
modder
aktív tag
ezt a kérdést pontosabban is megfogalmazhattad volna, főleg stackoverflow-on
Mit jelent a jó és mit jelent a rossz bemenet?
Egyébként a modelledben a keresés csak akkor fog false-szal visszatérni, ha hiba van az adatbázis lekérdezésben (nem éred el az adatbázist, vagy szintaktikailag helytelen lesz a generált sql)
De ezek csak tippek, számomra nem nyilvánvaló a kérdés
Új hozzászólás Aktív témák
Hirdetés
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Szeged és környéke adok-veszek-beszélgetek
- Milyen autót vegyek?
- Honda topik
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- Apple Watch Sport - ez is csak egy okosóra
- Milyen billentyűzetet vegyek?
- Elektromos cigaretta 🔞
- Nem várt platformon a OnePlus Nord 5
- Két új Ryzen közül választhatnak a kézikonzolok
- További aktív témák...
- GOPRO Hero 11 BLACK - 5.3k akciókamera - 2 akku, tartozékok (5.)
- DJI AVATA 2 Fly More Combo 1 akku - drón szett DJI Goggles N3 FPV szemüveggel
- Sony PlayStation 5 ( PS5 ) Sony PlayStation VR2 Csomag
- Dell Precision 7680 Eco FHD+ 13600HX 14C / 16G D5 / 1T G4 workstation
- Gigabyte GA-Z68A-D3-B3 LGA 1155 alaplap
- Azonnali készpénzes INTEL CPU AMD VGA számítógép felvásárlás személyesen / postával korrekt áron
- Xiaomi Redmi Note 11 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- Csere-Beszámítás! Olcsó RTX Gamer Laptop játékra! I5 11400H / RTX 3050Ti / 16GB DDR4 / 512GB SSD
- LG 32GQ850-B - 32" NANO IPS ATW / 2560x1440 / 260Hz 1ms / NVIDIA G-Sync / AMD FreeSync / HDR 600
- REFURBISHED - HP USB-C Dock G4 docking station (L13899-001)
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest