- Akciófigyelő: Humble Games Bundle - Nightdive FPS Remasters
- Call of Duty: Modern Warfare III - Új szezon, újabb ingyenes hétvége jön
- Hunt: Showdown - Jön az engine csere, befutnak az újgenerációs verziók
- Steamre tart a Crime Boss: Rockay City
- The Witcher - Befutott a TV sorozat folytatásának első rövid kedvcsinálója
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #17006 üzenetére
COUNT-tal könnyen tudod ellenőrizni, hány rekord van, ami a feltételeknek megfelel:
$stmt = $mysqli->prepare('SELECT COUNT(*) FROM users WHERE username = ? OR email = ?');
$stmt->bind_param('ss', $username, $email);
$stmt->execute();
// a $numberOfUsers változó fogja tárolni a prepared statement eredményét a fetch után
$stmt->bind_result($numberOfUsers);
$stmt->fetch();
if($numberOfUsers > 0) {
// para, van már ilyen felhasználó, tehát nem regisztrálhat ezekkel az adatokkal
// kivételdobás, stb.
}
// egyébként mehet tovább...Ja, még annyi, hogy a die() létezését inkább felejtsd el, dobj kivételt, kezeld is le valahol tisztességesen, stb.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #17009 üzenetére
Pedig akkor egészen biztos, hogy valami nem stimmel. Mutass komplett kódot, amivel csinálod.
(#17010) Flashback:
Első körben próbáld meg azt, hogy még a <!DOCTYPE elé rakd be az említett sort (igen, ott van a meta tagben, de nem biztos, hogy elég):
<?php header('Content-Type: text/html; charset=utf-8'); ?>
<!DOCTYPE ...
(nyilván az alsó sor nélkül, csak hogy egyértelmű legyen)
Egyébként mivel gyaníthatóan most alakítod ki az oldalt, lehetőleg ne XHTML 1.0 Strict legyen, hanem HTML5-ös, van jópár igen hasznos feature, amit így kihasználhatsz (az mellékes, hogy a böngésző sokszor engedékeny, és más doctype ellenére is esetleg használhatsz HTML5-től létező dolgokat, de legyen szabályos). Az meg csak annyiból áll, hogy a szokásos tagek elé a
<!DOCTYPE html>
deklarációt rakod, és máris HTML5-ös a doksid. (Az xmlns és xml:lang attribútum ennek megfelelően itt már nem szükséges, csak XHTML-nél.)[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz tothjozsi96 #17013 üzenetére
Ennek egészen biztos, hogy SEMMI köze nincs ahhoz, hogy miért kaptál eredményt mégis úgy, hogy állításod szerint üres volt az egész adatbázis (?? akkor milyen táblát kérdeztél volna le? Ha pedig a táblára gondoltál, hogy üres, akkor miért adott volna vissza találatot?!). Ezzel erőforrásokat szabadítasz fel, de a problémáid oka tuti nem ez volt, közben valami mást is babrálhattál.
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz martin66 #17047 üzenetére
Ezek szerint van output még a header-kiküldési kísérlet előtt, ez így nem fog működni (pontosan ezzel kezdtem), úgyhogy ne legyen. A feldolgozás legyen teljesen különálló fájlban, ne legyen egybeömlesztve azzal, ahol kiíratod az űrlapot.
Ez a kód egyébként még borzalmasan hiányos, sehol sem validálod az űrlapot (nem ellenőrzöd, hogy egyáltalán léteznek-e az általad elvárt kulcsok a $_POST tömbben, illetve a felhasználó által megadott adatok megfelelnek-e bármilyen elvárt formátumnak), az ELSŐ feladat mindig az legyen, hogy elkészíted a felhasználótól kapott adatok ellenőrzésére szolgáló kódrészletet. Soha ne bízz meg felhasználótól kapott adatokban.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz martin66 #17049 üzenetére
Hát sorry, de másokhoz hasonlóan éppen adódó szabadidőmben látogatok csak fel, hobbiból, nincs tengernyi időm, konkrét hiba javításában, konkrét kérdés megválaszolásában szívesen segítek, de elölről megírni neked egy ilyet melós. Persze reméljük, hogy lesz lelkes önkéntes, aki bevállalja (amikor először kezdtem segítgetni a topicban, akkor még én is lelkes voltam, aztán rájöttem, hogy nem érdemes, az ember a kisujját nyújtja, akkor az esetek többségében az egész karja kell, és mindez véget nem érő folyamat, aminek az eredménye az, hogy nekem rengeteg időm elment, a másik meg copy-paste-el, aztán köszönés nélkül távozik ).
Rengeteg témához kapcsolódó, de az általad írtnál sokkal szebb megoldás, tutorial létezik, ha pár percig guglizol, biztos lehetsz benne, hogy kész megoldásokat kapsz. Persze főleg angol anyagokban érdemes keresni, "form validation php", "form processing php", stb. kulcsszavak segítségével...Sk8erPeter
-
Sk8erPeter
nagyúr
válasz fordfairlane #17052 üzenetére
Ja, és valóban, ott volt egy tök felesleges kódblokklezárás, majd üres sor, majd megint kódblokk-kezdés, észre se vettem. Mondjuk a kódban továbbra sincs egy sornyi validálás sem, szóval ez még mindig úgy, ahogy van, fos...
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz #68216320 #17057 üzenetére
Most, hogy engedélyezted, cseréld is le az összeset
https://gist.github.com/jankkhvej/1117678Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #17060 üzenetére
Korábban sem tiltotta senki, hogy engedélyezve legyen. Ízlés kérdése, én azért nem komálom, mert szerintem rontja az olvashatóságot, én feleslegesnek látom lespórolni azt a pár karaktert, számomra csúnyább tőle a kód, de ez tök szubjektív, a fejlesztőre vagy fejlesztőbrigádra van bízva ennek az eldöntése.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #17084 üzenetére
"Amúgy azért lenne fontos, mert pontokat kapnak a felhasználók bizonyos oldalak meglátogatásáért, és hogy ne legyen minden oldal töltésnél adatbázis művelet így úgy gondoltam, hogy letárolom cookieba és csak valamilyen időközönként tárolom le."
Hát pedig de, az ellenőrzést és szükség esetén a pontnövelést, és ezzel az adatbázis-műveletet azonnal az oldalletöltésnél, szerveroldalon végezd el, ilyen feladatokat semmiképp se rakj át kliensoldalra. Egy normálisan karbantartott adatbázisnál, nem feleslegesen agyonbonyolított query-knél ez nem szabadna, hogy gondot okozzon. Ha gyorsítani akarsz ezen, akkor ezt szerveroldalon végezd, ne úgy akarj gyorsítani, hogy azon töröd az agyad, hogy hogyan fogadj el megbízhatatlan adatforrást (minden adatforrás megbízhatatlan, ami a klienstől származik) valamilyen szinten megbízhatónak.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DNReNTi #17091 üzenetére
"Igazából még csak nem is plusz lekérdezés, ha ügyesen csinálod, akkor az egész felhasználó objektumodat annak minden tulajdonságával létre tudod hozni egyetlen lekérdezéssel. Kb nulla plusz terhelés."
Mármint úgy érted, hogy hozzácsapod egy joinnal az eredményhalmazhoz azt is, hogy mondjuk adott oldalon járt-e? Csak mert szerintem ez meg már a lekérdezést bonyolítaná agyon (ha valóban egyetlen lekérdezéssel akarsz mindent megoldani), és nem hiszem, hogy megéri azzal szemben, hogy plusz egy lekérdezést intézel, hogy megtudd, járt-e az adott oldalon. Elméletileg nem szabadna, hogy ezek a lekérdezések jelentsenek komoly szűk keresztmetszetet, ha igen, akkor érdemes vizsgálódni az adatbázisban például megfelelő indexelés hiánya miatt, és ezeken javítani.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DNReNTi #17108 üzenetére
Ebben a hsz.-ben azt írta, hogy adott oldalak látogatása után (is) kapna pontot. Tehát az oldal betöltésekor ellenőrizni kellene, hogy ennek az oldalnak a látogatásáért kapott-e már pluszpontot, ha nem, jóváírni, ha igen, akkor nem történne ponthozzáadás. A "naplót" abban az értelemben muszáj lesz vezetni, hogy járt-e már az adott oldalon, de a felhasználó pontjainak növelése egyből az oldal meglátogatása során történhetne (nem pedig pl. ütemezett feladattal, "majd valamikor"), hadd kapja meg a vállveregetést a felhasználó egyből, amint meglátogatta az oldalt.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #17112 üzenetére
Ha van cron a szolgáltatónál (és valóban műxik), akkor mi a kérdés, miért ne menne?
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #17117 üzenetére
"Nem nagyon bízok az ilyen html fájl megjelenítésénél bonyolultabb dolgok tényleges működésében."
De hát akkor a PHP interpreter működésében sem bízol.Hát ha a szolgáltatónál nem cseszték el a cron konfigurálását, és az időzített feladatként beállított scripted is hibátlanul működik, akkor nyilván menni fog.
A cron a háttérben futkorászik (daemon), és bizonyos beállított időzönként lefuttatja a kívánt folyamatokat. Igazából nagy mágia nincs a működésében.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #17119 üzenetére
Bevallom, nem igazán értem, hogy hogyan hasonlítható össze a Transmission nevű torrentkliens, amint az daemonként fut, annak esetleges hibáival, és a cron, mint egy ettől teljesen különálló, időzített feladat-ütemező, ami szintén daemonként fut. A kettőben a közös tényleg csak annyi, hogy mindkettő tud daemonként futni (pontosabban a cron csak úgy fut).
Na meg ilyen alapon bármi bármikor összeomolhat, elromolhat, történhet szolgáltatás-kiesés, ami valóban adott esetben éppen beleeshet az ütemezett feladat szükséges lefutásának időtartamába. Erre két kerülő megoldás van:
- magas garantált rendelkezésre állású tárhelyet választasz
- egyes oldalbetöltések végén megvizsgálod, hogy utoljára mikor futott az ütemezett feladat (ezek időpontját tárolod adatbázisban), és ha régebben, mint mondjuk 1 hét, akkor lefuttatod azt is.Sk8erPeter
-
Sk8erPeter
nagyúr
"Ez alapján próbálkozom perpill.."
Ez nagyon durva. És te ezt képes vagy hallgatni anélkül, hogy 1 perc után inkább le akarnád tépni a füledet? (én inkább azt választottam, hogy kilőttem a francba, egyébként még egy tákolmány is, amit összehoz)Látom a többi közben nagyjából megoldódott.
(#17127):
Ezt úgy illik, hogy a feldolgozás külön fájlban történik, nem ugyanott, ahol a megjelenítéshez tartozó dolgok."A form validálását is majd egybekötöm a submit button lenyomásával (ezt majd később JS-el megoldom)"
A validálást először SZERVEROLDALON írjuk meg, és csak UTÁNA kliensoldalon! A szerveroldali kódodban egy darab ellenőrzés sincsen, amíg ez nincs kész, addig tovább se lépj, először ezt oldd meg.A PHP-s hibák kijelzése be van állítva a php.ini-ben a fejlesztői gépen? Fejlesztés során mindig a legtöbb hibát kiíró hibabeállítás legyen meg, élesben kell csak elrejteni a hibákat, és azokat inkább naplózni.
Az alapján, amiket írtál, még azt sem tudhatjuk, hogy egyáltalán melyik kódsornál akadt el. Ezt tisztességes debuggolással illik kideríteni, de legalább akkor itt-ott kiíratásokkal derítsd már ki, melyik résznél van a probléma.Sk8erPeter
-
Sk8erPeter
nagyúr
Na pont ez egy tökéletes példa arra, hogy miért is egy rakás szar még mindig a w3schools, ahhoz képest, hogy sokan azt hiszik, ez a webfejlesztők referenciáinak alfája és omegája, miközben tele van okádmány példakódokkal, rossz praktikákkal.
Egy külön szekciót szentel annak, hogy elmagyarázza, miért csinálja ezt:
<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">
ahelyett, befejezné a szerencsétlenkedését, és ennyit írna:
<form method="post" action="">
üresen hagyva az action-attribútum értékét, ha már önmagára akarja irányítani a formot... Kész, probléma megoldva... De még véletlenül sem hívja fel a figyelmet, hogy amúgy nem igazán üdvös megoldás nem szétválasztani a megjelenítéshez tartozó kódot a kapott adatok feldolgozásához tartozó kódtól...
Az input fieldeknél meg még véletlenül se használna labelt az accessibility és könnyebb kezelhetőség jegyében (pl. labelre kattintva ugorjon bele a mezőbe, ezt a böngészők támogatják, ha a label tartalmazza az általa felcímkézett elemet, vagy össze van kapcsolva egy for attribútum segítségével), nem használ placeholdert, mert ugyan miért is lenne HTML5, töketlenkedik azzal, hogy egyesével adogatja át a $_POST tömbben szereplő változókat az indexszel azonos nevű változóknak validálás után, ahelyett, hogy jóval általánosabb és szebb módon oldaná meg, és így tovább... nem értem, miért nem tudják az embereket spagettikód írása helyett végre valami jóra is tanítani.
Szóval látom, a w3fools.com-nak sajnos még mindig van relevanciája."Itt találtam egy pár funkciót ami a hibakijelzésekre vonatkozik, igazából vakvilágban tapogatódzom, segítenél, hogy pontosan mely fájlokat kell a php.ini-ben bekapcsolni ahhoz, hogy kijelezze a php-s hibákat is?"
Jó helyen tapogatózol, de itt nem "fájlokat" kapcsolsz be (ezt nem is tudtam értelmezni), hanem opciókat állítgatsz be (a php.ini egy konfigurációs fájl).Hibajelzésekre:
PHP 5.4.0 fölötti változatoknál:
error_reporting=E_ALL
display_errors=On
PHP 5.4.0-nál régebbi esetén:
error_reporting=E_ALL|E_STRICT
display_errors=On"Majd ezt követően a debuggolás történhet pl. etc. Firebuggal, konzolon keresztül? (Perpill ugye ott nem ír ki semmit sem)."
Húha, itt alapvető fogalmi tévedések vannak. A kliensoldalnak semmi köze a szerveroldalhoz, attól még, mert kommunikálnak, azok fejlesztése, debuggolása, lehetőségei is totálisan eltérnek. Bármilyen böngészőbeli webfejlesztő panelen csak akkor látnád ezeket a hibákat, ha JavaScripttel kiíratnád őket explicite valahogy a konzolra (ez már a gányolás kategória).
Ezért kell megtanulni rendesen debuggolni, de ez egyelőre sztem még nehézkes lenne neked, gondolom most kezded tanulni a PHP-t."Tehát pl. hozzak létre egy contatform.php és külön csak abba legyen a kontaktformhoz tartozó php kód?"
Egy olyan fájlról beszélek, aminek elküldöd az űrlap adatait (ezt a fájlnevet az action-attribútumban adod meg), és aminek a megjelenítéshez semmi köze, nincs benne az űrlap kiírásáért felelős kód, stb. Megkapod az adatokat, validálod őket, gondolva az esetleges csúnyabácsikra, kezdesz az adatokkal valamit (jelen esetben küldesz egy mailt), aztán visszairányítod az egészet abba a fájlba (header() segítségével), amiből kiindultál (vagy valahova átirányítod a júzert, ahol jelzed neki, hogy milyen ügyes volt, és sikeresen elküldte a cuccát). Itt a feldolgozó fájlban a különböző, másik oldalon kiírt adatokat el lehet tárolni $_SESSION-változókban, de ha ez egyelőre magas, akkor maradj az eredeti megoldásodnál, amikor önmagára irányítod az űrlap adatait (üres action-attribútummal).
Vagy ha valakinek van türelme elmagyarázni, akkor az remek. Most látom, így is qrva sokat írtam.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DNReNTi #17132 üzenetére
"3. Kijavítanám Brian-t a hibajelzésekkel kapcsolatban:
Helyesen: ini_set('display_errors', '1');"
Mielőtt "javítasz" valamit, nem árt, ha meggyőződsz róla, hogy az eredeti információ valóban helytelen-e, vagy csak Te nem vágod, a másik miről beszél.
Amit írtam, az pont úgy helyes. Amit Te írtál, az értelemszerűen PHP-fájlban fog csak működni (egyébként az is helyes), a php.ini-be hiába írod bele... Én meg a php.ini módosításáról beszéltem, ha kicsit visszaolvasol.
Amit írtál, az minden alkalommal, amikor egy adott fájl (amiben a sorod szerepel) betöltésre kerül (már ha betöltődik egyáltalán), meg fog hívódni, nem egy globális beállítás, ami mindenhol érvényes (az összes PHP-kódra vonatkozóan a fejlesztői gépen).Tehát még egyszer: a php.ini konfigurációs fájlba mehetnek ezek a sorok:
PHP 5.4.0 fölötti változatoknál:
error_reporting=E_ALL
display_errors=OnPHP 5.4.0-nál régebbi esetén*:
error_reporting=E_ALL|E_STRICT
display_errors=On* magyarázat: http://php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
"In PHP 5 a new error level E_STRICT is available. Prior to PHP 5.4.0 E_STRICT was not included within E_ALL, so you would have to explicitly enable this kind of error level in PHP < 5.4.0. Enabling E_STRICT during development has some benefits. STRICT messages provide suggestions that can help ensure the best interoperability and forward compatibility of your code. These messages may include things such as calling non-static methods statically, defining properties in a compatible class definition while defined in a used trait, and prior to PHP 5.3 some deprecated features would issue E_STRICT errors such as assigning objects by reference upon instantiation."Egyébként nekem nem tűnt úgy, hogy le kell neki egyszerűsíteni az infót, nekem úgy jött le, hogy értette ő. Csak még utána kell néznie alapvető dolgoknak is.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz #81999360 #17156 üzenetére
Nagyon jól látod, igazából abban reménykedtem, hogy senki nem fog reagálni a baromságaira. Egy darabig naivan és kitartóan válaszolgattam neki én is (pl. CSS topic), aztán rájöttem, hogy tényleg reménytelen, pedig mindenkinek meg kell adni az esélyt, de ő már kicsit túl sokat kapott.
Sk8erPeter
-
Sk8erPeter
nagyúr
"Az echonál ok, hogy ugyanaz ()-el mint nélküle, de mi vihet valakit arra, ilyet írjon le?"
Mármint ezt hogy érted? Mi a baj vele?Amúgy zseniális, hogy honda még engem nevez tahó parasztnak, amikor hónapokon át a legkitartóbbak között voltam, akik segítettek neki az oltásokkal együtt. De ezzel a személyeskedő hozzászólásával (amire inkább nem is reagálok) elintézte, hogy innentől kezdve semmit ne segítsek neki többet.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Tele von Zsinór #17167 üzenetére
"esetleg az igény, hogy függvényhívásnak nézzen ki"
Jaja, és ez speciel még jobban is mutat. Ezért nem értettem, mi lenne a baj vele.Sk8erPeter
-
Sk8erPeter
nagyúr
1. a $mail->ErrorInfo-ból bővebb hibaüzenetet is ki tudsz nyerni, pakold ezt az errors tömbödbe fejlesztés erejéig, az éles kódban pedig az ilyesmit illik inkább naplózni, és nem a felhasználó tudtára adni mindenféle "belső" hibaüzenetet (mert rosszindulatú emberke számára minden információ jól jöhet).
2. javaslom, hogy használd ki, hogy a PHPMailer (is) képes inkább kivétel eldobására hiba esetén, azt pedig szépen el tudod kapni egy phpmailerException formájában, sokkal szebb és áttekinthetőbb megoldást eredményez, el tudod vele kerülni a csúnya if-else blokkokat:
http://phpmailer.worxware.com/index.php?pg=exampleamail
https://github.com/Synchro/PHPMailer/blob/master/examples/exceptions.phps
Szerk.: egyébként itt az exceptionök engedélyezéséhez a kulcs csak annyi, hogy true paraméterrel inicializálod a PHPMailert:
//Create a new PHPMailer instance
//Passing true to the constructor enables the use of exceptions for error handling
$mail = new PHPMailer(true);[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz cidalain #17192 üzenetére
"A mysql_real_escape_string() függvény nem jó [...]
Hogy kellene ezt kulturáltan megcsinálni?"
A legkulturáltabban úgy lehet megcsinálni, hogy átállsz PDO-ra vagy MySQLi-re, az összes adatbázis-művelettel kapcsolatos dolgot átírod ennek megfelelően, prepared statementeket használsz, a mysql_* kezdetű függvényeket meg inkább megpróbálod elfelejteni, és sosem nézel vissza rá. Csak a szenvedés van vele, és amúgy is régóta deprecated, ki is fog kerülni a későbbi PHP-verziókban, szóval ha jót akarsz magadnak (és az emberiségnek ), akkor még időben állj át alternatív módszerekre.Choosing an API:
http://php.net/manual/en/mysqlinfo.api.choosing.phpHa valami fos legacy kód, és tényleg nagyon rá vagy kényszerítve a használatára, akkor sorry, de muszáj volt megjegyeznem.
(#17194):
Javaslom, kapcsold be a legszigorúbb hibajelzést a fejlesztés erejéig:PHP 5.4.0 fölötti változatoknál:
error_reporting=E_ALL
display_errors=OnPHP 5.4.0-nál régebbi esetén:
error_reporting=E_ALL|E_STRICT
display_errors=OnAkkor rögtön látni fogod, hogy hibának számít az ilyen, mint amit írtál, hogy
$_REQUEST[head_end_script]
Gondolom a head_end_script nem egy konstans nálad, hanem egy sima string, akkor legyen is az, kár, hogy a PHP ilyen esetekben túl toleráns.Ha túl sokszor lett escape-elve a szöveg, akkor kénytelen vagy először unescape-elni (pl. stripslashes), majd újra elmenteni az adatbázisba.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #17219 üzenetére
Engem is nagyon érdekelne, hogy mit akarsz csinálni, ami miatt ilyen felmerült. És hogy miért nem más módszerrel csinálod - amúgy ha ez nem volt tiszta egyből, hogy ilyet konstruktorból nyilvánvalóan nem lehet, akkor nem ártana legalább egyszer szépen végigdebuggolnod egy példány létrehozásának folyamatát, azt, hogy mikor melyik metódusba ugrik bele, és így tovább, meg átnézni az OOP-t jobban, mert itt valami alapok nagyon hiányoznak.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Speeedfire #17222 üzenetére
Nem tiszta ennyiből a feladat, de akkor mondjuk annak a mindig meghívogatott metódusnak legyen egy default értékkel ellátott második paramétere is, ellenőrizd ezt a paramétert a metódus törzsében, és ha ez egy egyéb értékkel egyenlő, akkor csináld meg azt a másik esetet. Persze csak ha ez nem vezet gányoláshoz, de ennyi infóból ezt lehetett kihozni kerülő megoldásként, amivel még nincs is nagy para.
(#17223) Joci93:
Ez stringek tömbje? Tehát egy tömb, amiben több string is található?
Menj végig a tömbelemeken, és stringtartalom-keresős függvényekkel nézd meg, benne van-e az általad keresett string az aktuális elemben...[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #17225 üzenetére
Ja, strpos(), strstr() és társai, vagy multibyte stringeknél ezek megfelelői, tehát mb_strpos(), mb_strstr(), stb...
Amúgy ne vedd sértésnek, de azért mielőtt olyanokat állítasz, hogy "erre szerintem nincs beépített függvény", miközben ez eléggé alapvető elvárás, hogy beépített könyvtári függvény/metódus legyen egy stringben keresős módszer, nem árt utánanézni...
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #17229 üzenetére
"Igen tudom, bár javasoltam egy alternatív megoldást a problémára."
Ami hibás. Az str_split()-nek az egész tömböt adod át, nem indexelted. Egyébként van foreach-ciklus, ami ennél sokkal szebb kódot eredményez, és az ilyen jellegű indexeléssel sem kell foglalkoznod."Amúgy nem lehetséges, hogy néha az ilyen alternatív megoldás gyorsabb? Tegyük fel, hogy a kód
ugyan olyanugyanolyan hatékonysággal van megírva mint a függvényben, de mivel itt függvényhívás nélkül fut le, ezért valamivel gyorsabb."
Nem valószínű, mivel a PHP könyvtári függvényeit C-ben írják, aztán optimalizált kód lesz belőle a buildelés során, nagy eséllyel ez gyorsabban fog működni, mint a Te kódod, amit már PHP-ben írsz (a fenti kódodnál meg aztán végképp gyorsabban fog működni... ). Persze ettől még a különbséget nem biztos, hogy megérzed. (Na meg el lehet képzelni rossz implementációt is még a beépített függvényeknél is.)
Ha arra vagy kíváncsi, hogy azonos környezetben, azonos feltételekkel, ugyanolyan hatékonysággal van valóban megírva a kód, de még valaki hozzátesz egy függvényhívást is, akkor melyik lesz a győztes, akkor igen, jól sejted, ELMÉLETBEN az, amelyik nem teszi hozzá a függvényhívás overheadjét - a gyakorlat viszont megint más, mert ez már olyan minimális különbség, hogy nem fogod tudni mérni sem, hogy melyik a gyorsabb, sőt, aktuális szerverterheltségtől függően össze-vissza fog változni a különbség.
Szóval azon nem éri meg agyalni, hogy inkább a könyvtári függvényt használod, vagy feltalálod a spanyolviaszt.
Azon, hogy milyen overheadet teszel hozzá egy-egy függvényhívással, akkor éri meg agyalni, amikor pl. egy helyen ugyanazt az értéket kéred le többször is, tök feleslegesen. Rengetegen elkövetik azt a hibát, hogy egy értéket/referenciát/akármit eltárolhatnának egy változóban, és később felhasználhatnák, de ugyanazt a kódot leírják többször is (erre is vonatkozik a DRY (Don't Repeat Yourself) elv).
Na, kezdek elkalandozni, remélem, megválaszoltam a kérdésedet.Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Des1gnR #17232 üzenetére
Általános tanácsot nem lehet adni, mivel minden webshop más lehet, de mindenesetre az összes termékoldal összes HTML-kódját lementeni nyilván értelmetlen, ebből ki kell bányászni első letöltés után a szükséges adatokat, aztán eldobni a HTML-kimenetet. Vagy DOMDocument osztállyal, vagy erre/másra építő library-vel, mindenesetre valamilyen DOM-feldolgozó módszerrel.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DNReNTi #17239 üzenetére
Meg tudod mutatni a .htaccess vonatkozó részletét, ami a hibát okozta?
Hogy mitől lehet böngészőfüggő, de ez csak tippelgetés: ha ez a teszt az adatbázisba való beillesztésre csak simán be volt dobva egy akármilyen oldalra, tehát minden oldalbetöltéskor lefutott, akkor lehet akár a böngészőnek egy előtöltési mechanizmusa, tehát pl. amint beírtad a megnyitandó URL-t, máris elindulhatott egy előtöltés a teljesítmény növelése érdekében, pl. Chrome-nál van ilyen opció:
https://support.google.com/chrome/answer/1385029?hl=hu-HU
"Hálózati műveletek előrejelzése az oldalbetöltések teljesítményének növelése érdekében"
vagy angolul "Predict network actions to improve page load performance”
Ha minden egyes kérést figyelgetsz, akkor látható, hogy már abban a pillanatban elindul egy request, amikor csak bepötyögted az URL-t, vagy amint kiegészítette autocomplete segítségével a böngésző - tehát még meg sem nyomtad az Entert, máris megpróbál egy részletet előtölteni gyorsítótárba, hogy aztán amikor ténylegesen megnyitod, akkor gyorsabban betöltsön az oldal.
De most ez csak ötlet, a (század)másodpercre pontos adatokból, meg egyéb infókból lenne kideríthető, hogy pont ez lehetett-e az oka, vagy valami más.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz DNReNTi #17252 üzenetére
Vaze. Egyébként a favicon.ico fájl lekérése a gyökérből (amennyiben pl. nincs beállítva favicon egyéb módon) böngészőfüggő, van, amelyik cseszegeti érte a szervert, van, amelyik nem. Szóval ez esetben, tehát most, hogy kiderült, hogy többek közt a favicon.ico-ra irányuló requestek is lefuttatták az index.php-dben lévő adatbázis-tömködést, nem meglepő, hogy több beillesztés is történt, és hogy ez böngészőfüggő volt.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Joci93 #17285 üzenetére
cidalainnal értek egyet, van olyan feladat, ami eleve értelmetlen, így nem biztos, hogy megéri elvállalni, szépen türelmesen el kell magyarázni a megrendelőnek, hogy baromságot akar. Aztán hátha meggondolja magát, vagy tovább kell állni (már ha van választási lehetőség). Nem akar adatbázist valami degenerált indokból, de azért valahol mégis, meg szeretne query-ket is írni kézzel, amit ja, akár phpMyAdminban is megtehetne, ha ez a kattanása, de nem, ő a spanyolviaszt akarja felfedezni.
De ha már muszáj elvállalnod, és valahova menteni kell, illetve fel is kell tudni dolgozni a tárolt adatot, akkor a txt-t vagy bármi behányt szöveget azonnal felejtsd el, valami normálisan és hatékonyan feldolgozható formátumban mentsd el, legyen az JSON, XML, stb. Ha már az SQLite is szóba kerülhet, mint lokális, fájlba írós adatbázis, akkor már nem igazán értem, miért ne lehetne egy tisztességes adatbázis (nem lebecsülve az SQLite-ot, de nagyobb adatmennyiség esetén már nyilván nem ez a hatékony megoldás), onnantól már csak egy lépés.
Mi is pontosan az indoka a megrendelőnek arra, hogy nem lehet adatbázist használni?Amúgy ha már SQL parsert kell használnod, akkor nehogy elkezdd kézzel összetákolni, mert rohadt nagy szopás tud lenni egy parser, inkább használj fel egy kész könyvtárat:
https://code.google.com/p/php-sql-parser/
http://stackoverflow.com/questions/283087/php-mysql-sql-parser-insert-and-update/283115#283115Szerk.:
(#17290) PumpkinSeed: pont megelőztél. Amúgy egyetértek.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Things you must know about PHP7 --> hát ez a "spaceship operator" rettentő értelmes:
https://wiki.php.net/rfc/combined-comparison-operatorTehát most már tudok olyat csinálni, hogy
if( ($a <=> $b) === -1 || ($a <=> $b) === 0) { ... }Hát csodálatos.
Sk8erPeter
-
Sk8erPeter
nagyúr
Megnézted a fogadott JSON-adatokat, az alapján a kapott adatok helyesek? Kliensoldalon hogy jeleníted meg a chartot? Nekem kicsit furcsa, hogy behánysz össze nem illő adatokat egymás mellé, pl. dátumot a valamilyen downstream/upstream csatornák adataival, persze nem is ismerem a library API-ját, de mielőtt utánanéznék, nem ártana legalább egy kis példakimenet (a kapott JSON-adatok legalább egy része, hogy el tudjuk képzelni, milyen adatokat is akarsz megjeleníteni).
Amúgy angolul a data már eleve többesszám, nem kell odatenni még egy s-t is a végére, hogy az legyen...
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Mi a hozzá tartozó kliensoldali kódod?
Egyébként azt nézem, hogy az összes demóban dátumnál alapértelmezetten az 1970. január 1. óta eltelt milliszekundumok számát használják fel (pl. ennél a demónál, ebben a fájlban), szóval valszeg be kellene explicite állítanod, hogy te milyen dátumformátumot használsz, VAGY tök felesleges az adatbázis-oldali átalakításod (inkább utóbbira tippelek).
Szóval milyen JavaScript-kódot használsz hozzá?
Ja, és a dátumot hol, hogyan szeretnéd megjeleníteni?Szerk.:
http://api.highcharts.com/highstock#rangeSelector.inputDateFormat
Itt azt írja:
"inputDateFormat: String
The date format in the input boxes when not selected for editing. Defaults to %b %e, %Y. Defaults to %b %e %Y,."
Hogy most akkor melyik, azt nem tudom. Érdekes, hogy két formátum van.Még ezek lehetnek érdekesek:
inputDateParser: Function
A custom callback function to parse values entered in the input boxes and return a valid JavaScript time as milliseconds since 1970.inputEditDateFormat: String
The date format in the input boxes when they are selected for editing. This must be a format that is recognized by JavaScript Date.parse. Defaults to %Y-%m-%d.[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Itt úgy tűnik, hogy maga a dátum jól jelenik meg, felraktam a példádat:
http://jsfiddle.net/8vkse4bu/
Több adattal nem próbáltam ki, segítene, ha felraknál több adatot is mondjuk pastebinre, vagy ugyanígy bedobnád jsFiddle-példán, ami nálad rosszul jelenik meg.Amúgy az egyik hivatalos példában is ilyen bénán jelenik meg a dátum, ahogy említetted:
http://jsfiddle.net/gh/get/jquery/1.7.2/highslide-software/highcharts.com/tree/master/samples/stock/rangeselector/input-format/Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #17316 üzenetére
Bővítettem még tök random adatokkal, és itt is teljesen jól jelenik meg a dátum:
http://jsfiddle.net/8vkse4bu/1/Sk8erPeter
-
Sk8erPeter
nagyúr
Rakj fel kérlek egy olyan jsFiddle-példát, amit én is linkeltem neked, bővítsd az enyémet, vagy valami (aztán mentsd is el, és linkeld be ide), hogy látható legyen, a saját kódodnál mi is a gond, és milyen opciókat szeretnél pluszban betenni, mert az általam korábban mutatott kód működik. Amúgy ez már sokkal inkább a JavaScript topicba hajlik, folytathatjuk ott is.
Sk8erPeter
-
Sk8erPeter
nagyúr
válasz CSorBA #17344 üzenetére
Ha beépített megoldást is találnál rá, annak is végig kellene szaladnia a tömbön (igaz, a beépített megoldás minimálisan gyorsabb lehet, mint a saját kódod), szóval nem fogod tudni megspórolni, de nem túl bonyolult:
$testArray = array(
0 => array(
"id"=> "214",
"valami"=> "asd"
),
1 => array(
"id"=> "123",
"valami"=> "asd"
),
2 => array(
"id"=> "982",
"valami"=> "asd"
),
);$newArray = array();
foreach($testArray as $currentItem){
$newArray[$currentItem['id']] = $currentItem;
}Eredménye:
array (
214 =>
array (
'id' => '214',
'valami' => 'asd',
),
123 =>
array (
'id' => '123',
'valami' => 'asd',
),
982 =>
array (
'id' => '982',
'valami' => 'asd',
),
)Lehetne még array_walk segítségével is, de itt pár mérés alapján sokkal lassabb tud lenni, mint a foreach, úgyhogy inkább csak érdekességként mutatom:
$newArray = array();
array_walk($testArray, function($item, $key){
global $newArray;
$newArray[$item['id']] = $item;
});[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz Des1gnR #17369 üzenetére
Ha Windows Phone-ra szeretnél fejleszteni, akkor miért a PHP topicban vagy? A feladat megoldásának semmi köze nincs hozzá, a szervertől kapott választ kell feldolgoznod az általad használt nyelvvel. (A Te szempontodból teljesen mindegy, hogy a VOLÁN-nál milyen szerveroldali nyelvet használnak.)
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Önmagában az, hogy GET-metódussal vagy POST-tal küldöd az adatokat a szerver felé, az tökéletesen mindegy. Szóval nem értem, az eltérő metódus miatt miért változtatna a megoldáson. A válasz feldolgozása már érdekesebb. Valószínűleg pont olyan változóneveket várnak, ami az űrlap elemeinél látható, tehát ezt is lehet tudni. Ami viszont már valóban gondot jelenthet, az az, ha az adatok megjelenítése, az eredménytáblázat felépítése csak JavaScripttel történik, és nincs benne a törzsben az elvárható módon az adat, tehát a válasz kikotrása egyáltalán nem biztos, hogy triviális egy szarul felépített oldalnál.
Egyébként vicc, hogy nincs egy normális hivatalos API-ja a Volánnak.
(#17371) DS39:
Regexszel kiszedni a választ valami brutális overkill. Vannak rendes dokumentum-feldolgozó könyvtárak, azokat kell használni.Hogy Google Translate-hez minek csináltál ilyen regexes adatkiszedős valamit, az meg számomra rejtély, amikor van rendes API-ja (elég régóta).
[ Szerkesztve ]
Sk8erPeter
Új hozzászólás Aktív témák
- Házimozi belépő szinten
- Sony MILC fényképezőgépcsalád
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- Stellar Blade
- Azonnali VGA-s kérdések órája
- Vezetékes FÜLhallgatók
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Luck Dragon: Asszociációs játék. :)
- Bivalyerős lett a Poco F6 és F6 Pro
- Vicces képek
- További aktív témák...
- Üzletből, garanciával, Macbook Air Retina 13" 2020, 8GBRAM 256GB SSD magyar bill
- Lenovo ThinkStation P330 Workstation: 3D tervezésre (CAD), videó vágásra, animációk készítésére(DCC)
- ASUS ROG STRIX RTX 3070 8GB
- Eladó ASUS ROG STRIX SCAR II GL704G kishibás gamer notebook
- ÚJ! // ÁR ALATT! // Edifier S3000 MK II // Muziker garancia
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen