Új hozzászólás Aktív témák
-
válasz
modder
#15000
üzenetére
Igen, a Javához hasonlóan viselkedik, a primitív típusoknál és tömbnél működik a copy on write.
Csak a PHP tud olyat is, hogy objektumot adsz át & karakterrel:function test($var)
{
$var = (object) array('abc' => '123');
}
function test2(&$var)
{
$var = (object) array('def' => '456');
}
$foo = (object) array('bar' => 'baz');
print_r($foo);
test($foo);
print_r($foo);
test2($foo);
print_r($foo);Kimenet:
stdClass Object
(
[bar] => baz
)
stdClass Object
(
[bar] => baz
)
stdClass Object
(
[def] => 456
) -
-
#14993
Speeedfire
félisten
modder
#14992
-
#14893
rootkiller
őstag
modder
#14892
rootkiller
őstag
válasz
modder
#14892
üzenetére
Köszi!
Amúgy a Webes rendszerek programozása 1 c. tárgy előtt Programozási alapok 2 c. tárgy volt, ami JAVA-val foglalkozott, onnan az ismeret amit jelen esetben hibásan alkalmaznék.
Az volt az indíttatás hogy mielőtt nekiálltam átfaragni az oldalt if (empty($_GET['id'] { új_hozzáadás } else { módosítás } volt a szerkezet, nyilván form oldalon semmi/select-el, végrehajtási oldalon meg insert into/update-vel.Akkor fogom magam és kapnak új elnevezést ezek a paraméteres módosító függvények amik belekerülnek a controllerbe.
-
#14887
PumpkinSeed
addikt
modder
#14885
-
modder
aktív tag
válasz
modder
#14885
üzenetére
http://www.php.net/manual/en/mysqli-stmt.bind-param.php
Ezzel a paraméterek escapelve lesznek - ha jól tudom - így ha a $_GET['id'] változód bármit is tartalmaz, védve leszel az sql injection ellen.
Másik előnye, hogy így prepared statementet használsz, amit cache-el az adatbázis kezelő, ezért nem fogja ugyanarra a queryre újra és újra végrehajtani az optimalizációs eljárást, hanem elmenti a végrehajtási tervet. http://stackoverflow.com/questions/12286313/do-sql-bind-parameters-affect-performance
http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php -
#13186
Speeedfire
félisten
modder
#13184
Speeedfire
félisten
válasz
modder
#13184
üzenetére
Hát, ezt a view-ot inkább kihagynám. Inkább az attributomoknál a sima user táblára hivatkoznék. Azt még nem tudom hogyan, de remélem reggelre megálmodom.
DeltaPower: Minden yii rendszerben a userid definiálva kell, hogy legyen. Elvileg ez valóban csak egy kiegészítő tábla lenne a postázási adatokkal, de ezt már az alap rendszeremben is felvettem, így nem akarom még egyszer felvenni. Annyi, hogy nálam nincs country, de itt MO.-n nem kell ez...még.
-
#13183
Speeedfire
félisten
modder
#13182
Speeedfire
félisten
válasz
modder
#13182
üzenetére
Jól értem, hogy nem akarod az egész adatbázist közösen használni, csak a user managementet?
Nem teljesen. Lehet én fogalmazok rosszul.
Adott egy saját weboldal yii alapokon, szintén yii alapokon találtam egy extension-t, amivel shop-ot tudok készíteni. Viszont a shop-nak külön van egy user táblája erre a célra. Én a shop user táblája helyett a sajátomat akarom használni. Mind a 2 táblába nem akarok usereket felvenni.Viszont olyan megoldásra gondoltam, lehet hülyeség lenne, hogy a shop táblát lecserélem egy kapcsoló táblára, ahogy látom a kapcsolásokat, csak a shop user id részét használja.
Vagy ez így nagyon hülye megoldás lenne?
A mentés meg a törlés funkciókat felülírnám a sima User model adatival.mivel ha jól láttam a képről, a webshop user táblája össze van kötve a yii user táblájával
Nem, ott csak szemléltettem. A yii user a saját weblapom user táblája. A jobb oldali shopuser pedig a shop adatbázisa lenne.A shop táblája elég egyszerű. Nem egy túl bonyolult shop rendszer.
-
#13181
Speeedfire
félisten
modder
#13179
Speeedfire
félisten
válasz
modder
#13179
üzenetére
Igen, én is ezt szeretném, hogy egy adatbázis legyen csak inkább. Az authentikáció nem problémás, mert mind a kettő yii-re van írva, így ez menni fog.
A gondom, csak az, hogy nem tudom hogy álljak neki ennek az interface dolognak, mert csak ez lehet a megoldás rá szerintem. 2 táblában tárolni mindent felesleges lenne, mert elvileg meg lehetne oldani így a dolgot, de minek? Olvasok még erről, hátha van valami félkész megoldás, vagy nem tudom...elvileg a yii usermanager extension-nel együtt tud működni, szóval valami biztos van rá.
-
kkdesign
senior tag
válasz
modder
#12226
üzenetére
Elnézést de nem tudom ennyire szaknyelven még, hogy így output meg úgy, sajnos nem értem teljesen amit mondasz
magyarul jó helyen van ez így, hogy a bodyból a phpben ez az első ? már nagyon bele vagyok keveredve az egészbe, localhoston működött wampserverrel, de élesben már nem... -
-
cucka
addikt
válasz
modder
#12141
üzenetére
A tömbös példámat rosszul fogalmaztam meg. Nem arra akartam kilyukadni, hogy ha tömböt használsz az nem hatékony, hanem hogy ezzel a megoldással simán elszalad a ló a fejlesztővel, hogy ja, csak dobjunk bele mindent ami kell egy hatalmas tömbbe, mert az milyen egyszerű.
Éppenséggel osztályok és absztrakciók gyártásával is elszaladhat a ló.
Egy kisméretű projektnél az absztrakció nem fog mást jelenteni, mint hozzáadott komplexitást, tömb wrapper objektumokat, fölösleges boilerplate kódot. Egy nagyméretű projektnél sok ember fog dolgozni a kódon nyilván más a helyzet.Aztán jön a másik fejlesztő, és dolgoznia kell egy ilyen multidimenziós tömbön, és fogja a fejét, hogy vajon mi az isten lehet ebben a tömbben.
A jó kód egyet jelent az olvasható, érthető kóddal. Ez pedig elsősorban a fejlesztőn múlik, nem a nyelven.A Haskell nem azért működik így, mert funkcionális nyelv, hanem mert típusos nyelv, és azt mondták a kitalálói, hogy ha van módszer arra, hogy megkíméljük a fejlesztőt attól, hogy mindig kiírja a típust, akkor használjuk.
A Haskell azért működik, mert olyan emberek alkották, akik a progamozási nyelvek szakértői.
A Php egy garázsprojektnek indult, egy lelkes amatőrtől.
Nézd meg a Python vagy a Ruby típusrendszerét (meg magukat a nyelveket), ha kíváncsi vagy olyan dinamikusan típusos nyelvekre, amelyek faszák és jól ki vannak találva.
Ja, és meglepő lehet, de használják a funkcionális nyelveket a versenyszférában, Haskell-ről és Erlang-ról tudok, de más is lehet. (Lisp? ) -
cucka
addikt
válasz
modder
#12132
üzenetére
A baj az, hogy a nyelv "kinőtte magát". Az emberek már nem kis dinamikus weboldalakra akarják használni, hanem bonyolult funkciókat megvalósító portálokat írnak benne.
Enterprise javaban is meg lehet oldani bármilyen szkriptelési feladatot, csak nem éri meg.
PHP-ban is meg lehet oldani enterprise szintű feladatokat, csak szintén nem éri meg.Egyébként nagyon magasan van az a léc, ahova a php ne lenne elég. Az, hogy a kód milyen minőségű lesz, elsősorban a fejlesztőn múlik itt is, mint minden más nyelvben.
De van egy csomó hülyeség, amit a PHP megenged (pl. minden lószart hatalmas multidimenziós tömbökben tárolunk végig a program futása során),
Miért, ha külön-külön változókban tárolnák, akkor az mitől lenne jobb? A php a tömböket ígyis-úgyis referencia szerint adja át, tehát nem látom, hol az overhead, amit említettél.A Haskell-t kezdtem el tanulgatni, és ott ez így működik.
A Haskell egy (majdnem) tisztán funkcionális nyelv, ott minden máshogy működik. Típus annotációk egyébként vannak szinte minden nyelvben, talán egyedül a php a kivétel, ahol ez nem lenne teljesen egyértelmű a rossz automata cast-olási szabályok miatt.Szintén Haskell könyvben taglalják több paragrafuson keresztül, hogy mennyire jó, hogy ha megnézzük egy metódus szignatúráját, abból egyből látszik, hogy mit csinál egy függvény
Valamivel ki kell tölteni a helyet abban a könyvben.
Taglalhatnák azt is, hogy a gyakorlati életben milyen jó eszköz a Haskell, meg hogy hogyan tudja leegyszerűsíteni a fejlesztést, de hát az egy elég rövid könyv lenne.(#12127) Sk8erPeter
Korábban is írtad, hogy kvázi egy dilettáns majom, de miből gondolod ezt amúgy?
Ez így túlzás, hogy dilettáns majom. A php egy olyan nyelv, amit nem megterveztek, hanem összegányoltak, élen vele. Jelenleg pedig nem tetszik az a hozzáállása, hogy a visszafele kompatibilitást meg kell őrizni bármi áron. Szerintem a PHP6 egy reboot kellett volna legyen, ahol végre felülvizsgálják a korábbi tévedéseket, nem ez történt. -
#12135
Sk8erPeter
nagyúr
modder
#12132
Sk8erPeter
nagyúr
válasz
modder
#12132
üzenetére
Azért nehogy valakit ez elriasszon a Drupaltól, még ha vissza is vontad
:
"egy drupal oldalletöltés több száz megabyte memóriát igényel"
Ez nagyon nem igaz.
Csak akkor, ha egy vagy több Drupal-modul kegyetlenül el van kúrva, mert rengeteg erőforrást igényel. Múltkor itt a topicban írogattam Drupallal kapcsolatban ilyen memóriazabálós problémáról, hogy állandóan kifogy belőle, és azóta kiderült, hogy konkrétan melyik modul hibáztatható érte (egy modul!), létre is hoztam róla a hivatalos oldalon egy issue-t, és mellékeltem egy félmegoldást:
http://drupal.org/node/1836264
Egyébként az a része igaz, hogy általában a CMS-ek nem éppen az erőforrás-spórolásról híresek, de ez az ára a nagyon nagy rugalmasságnak. Ettől függetlenül egyébként normális esetben maximum 10-20 MB-ot fogyaszt egy átlagos Drupal-oldal (szerk.: ha csak egy-két statikus oldal van az oldalon, akkor lószart sem fogyaszt, magyarul nincs 10 MB sem, itt most némi dinamizmusról beszélek, adatbázis-lekérésekről, stb.). Ami nagyon komplex, az persze simán felmehet 60 MB-ig is, de általában ez úgy igaz, ha sok-sok egymásba ágyazott táblázat van, vagy számtalan kitöltendő űrlapmező, admin-oldalon mindenféle kliensoldali szkript betöltődik, és sok egyéb legenerálandó elem van az oldalon. -
cucka
addikt
válasz
modder
#12119
üzenetére
Ami előnye (lenne), hogy nem kell mindenhol kiírni a típust, de ez nem feltétlenül jelent dinamikus típusosságot.
Nem igazán. A dinamikus típusosság lényegében nem más, mint rengeteg cast-olás, amit megcsinál neked a fordító/interpreter/akármi. Például a design pattern-eknél látható borzasztó objektum hierarchiák nagy részét egyszerűen ki lehet dobni egy dinamikusan típusos nyelvben.
Vagy ott van az, hogy egy függvény visszatérési értéke tetszőleges lehet: így kivételek nélkül is megoldhatod a hibakezelést. Ne feledd, a szkriptnyelvek alapvetően rövid programok írására lettek kitalálva.Vannak más nyelvek, ahol gyönyörűen meg van oldva, hogy ha létrehozol egy változót, onnantól már nem változtathatsz a típusán, és ki sem kell írni a típusát sehol.
És melyik ez a nyelv? Vagy most az új C++ auto kulcsszavára gondolsz?(#12122) Sk8erPeter
Nem, én nem hiszem, hogy csak a típustalanság miatt népszerű ennyire, én nem tudom, ezt honnan szeded.
Attól népszerű, mert egy könnyen tanulható, nagyon megengedő szabályokkal ellátott szkriptnyelv. Nyilván, ha statikusan típusos lenne, akkor ezek a tulajdonságok nem lennének érvényesek.Szerintem a PHP-val rengeteg probléma van, de ezek nem abból adódnak, hogy a nyelv dinamikusan típusos - egy részük annak köszönhető, hogy Rasmus Lerdorf nem értett a programozási nyelvek fejlesztéséhez, a másik részük meg annak, hogy a mai napig nem ért
.
Olvassatok phpsadness-t, megéri. -
#9951
Sk8erPeter
nagyúr
modder
#9950
Sk8erPeter
nagyúr
httpd.conf
Mondjuk tesztelésig érdemes lehet létrehozni csak erre egy VirtualHostot, és azonbelül alkalmazni, a httpd-vhosts.conf-ba betéve.====
Egyébként most nálam sem működik IIS+FastCGI PHP+XDebug+NetBeans kombóval a debuggolás, nem vágom, miért.
A breakpointnál megáll, de b@szik kiírni bármit is, az említett beállítások ellenére is. Na majd ha lesz időm, megkukkantom, mi a sz@r baja van. -
Mad_nv
csendes tag
Megpróbáltam, hogy az egyik echo után meghívtama flush() függvényt, de az outputon továbbra sem jelent meg semmi. A php.ini-ben átírtam ezeket: implicit_flush = On
output_buffering = 0, de semmi eredmény (természetesen az apache-ot újraindítottam az ini módosítása után). Nem tudom, hogy a phpinfo() függvény hogy éri el, hogy azonnal kiküldje az outputra az adatokat. Sajnos az általad javasolt SendBufferSize értéket nem tudtam módosítani, ugyanis nem nagyon értek az apache-hoz, azt sem tudom, hogy az XAMPP alatti változatnak, van-e valami konzolja, amin keresztül módosíthatnám. -
modder
aktív tag
ha még mindig nem megy, próbáld meg a webszerveren állítani az output buffert
pl Apachenál SendBufferSize 0Amúgy ha apache modulként van fönt a PHP, el tudom képzelni, hogy automatikusan flusholja az apache output bufferét is. (nálam működött ez annó). Ha nem apacheot használsz vagy fastcgi van, akkor lehet, hogy nem ilyen egyszerű a helyzet. mindenképpen nézz utána a webszerver output bufferének is.
(sőt, akár még a böngésző is bufferelhetni, azt mondják
) -
#9749
Sk8erPeter
nagyúr
modder
#9748
Sk8erPeter
nagyúr
Igen, és még annyit hozzátennék, hogy ha nem akar egy gány fájlba írós megoldást választani, aminek eredményeként az adatok jóval nehezebben kezelhetőek, ergo a szavazás aktuális állása jóval nehezebben követhető, akkor elengedhetetlen egy tök ingyenesen elérhető és könnyen kezelhető adatbázis (MySQL).
Vagy legalább ha MySQL-szerver fenntartására nincs mód, akkor már SQLite, vagy hasonló.
Mondjuk ha már webes felületen szavaznak, akkor miért is ne lehetne mód telepíteni egy MySQL-szervert...Szerk.: meg szerintem vagy keressen egy normális scriptet, vagy annál még az online, ingyenesen megtehető szavazások is jobbak.
Pl. most ezt találtam: [link] -
Szét spammellek! Na igen. Az a gond, hogy átirányít majd vissza és semmi. Azt észrevettem, hogy más code -dal lök vissza mint amit kaptam.
Tessék a kód:
<?php
$fb = new FacebookConnect();
if(!empty($_POST["fb"])) {
$user = $fb->get_user();
print_r($user);
}
?>
<html>
<head>
<title>Regisztráció</title>
</head>
<body>
...Ez a lényeg, a body után pedig befejezem a nézetet. Semmi komolyság egyenlőre, csak tesztelgetés
-
-
#9050
Sk8erPeter
nagyúr
modder
#9044
Sk8erPeter
nagyúr
Készítettem neked egy megoldást:
<?php
$evil = "function lp0(){echo base64_decode('UmVhZCB0aGF0IG1vdGhlcmZ1Y2tpbmcgbWFudWFsISEh');}lp0();";
eval($evil);Ha kíváncsi vagy a kimenetre: http://ideone.com/dfDiG.
-
#9046
Speeedfire
félisten
modder
#9044
Speeedfire
félisten
-
#9018
Sk8erPeter
nagyúr
modder
#9014
Sk8erPeter
nagyúr
Na ja. Asszem így már nagyjából összeért az álláspontunk. Csak kár, hogy eddig is PHP-ról beszéltünk (nem C-ről és nem is C++-ról), így egy kis időt megspórolhattunk volna.
Miután legalább egy órát elb@sztam azzal, hogy a kivétel vs. nem kivétel témában olvassak, olyan remek újdonságra jutottam, hogy nincs jó megoldás.
Mintha ezt eddig nem tudtuk volna. A lényeg: rengetegen amellett állnak ki, hogy a kivételeket tényleg csak kivételes esetekben érdemes dobálni (egyet muszáj idéznem: "Exceptions should be a truly rare thing, UserHasDiedAtKeyboard type situations."
), sokan mások meg azt állítják, hogy ez totálisan attól függ, hogy mennyire a teljesítményt helyezed a középpontba pl. a gyorsabb átláthatóság előnyeivel szemben. Kábé ugyanott tartok, mint ahonnan mi is elindultunk, annyi különbséggel, hogy csomó időm ráment, és hogy legalább megtudtam, hogy UNIX-nál van olyan hiba, hogy Printer on Fire. Mivel én az eddigi kivételdobálásoknál PHP esetén semmiféle észrevehető teljesítménybeli különbséggel nem találkoztam, asszem nem fogom átírni a kódjaimat úgy, hogy hibatömbbel térjek vissza, és a kódolási szokásaimat sem fogom rossznak tekinteni a vitánk miatt.
Egy C++-alkalmazásnál már nagyon is megfontolandó az, amiről beszéltünk. De természetesen az már másik fórumtémába tartozik.
Egyébként magas szintű nyelvek (pl. C#) előszeretettel alkalmaznak kivételeket különböző esetekre, nem véletlen, hogy számtalan előre definiált exception class van, amiket akár "helyben", egy rövidebb, beágyazott try-catch blokkban is el lehet kapni (ugyanez igaz általunk definiált exceptionökre is), így meg feltételezem, kisebb teljesítményvesztéssel kell számolni.Szerk.:
A TÉNYLEGES, gyakorlati teljesítményveszteségről viszont normális áttekintő cikket, méréseket továbbra sem találtam, csak a szájkoptatást, hogy csúnya nagy költségei vannak, pedig tényleg nagyon érdekelne, egy alkalmazásnál a két eset összehasonlításakor miféle teljesítménykülönbségekkel kell számolni. -
#9009
Sk8erPeter
nagyúr
modder
#9005
Sk8erPeter
nagyúr
Igen, és itt aztán a visszatérési értéket megint csak vizsgálni kell, és akkor visszajutottunk ugyanoda, ahonnan elindultunk.
Vegyük azt a megközelítést, amit Te mondasz, tök egyszerű példával. Itt beletettem még annyit, hogy két különböző paraméterrel hívom meg a logErrors függvényt, ez is szándékosan jó butított példa. A syntax highlighting miatt inkább felraktam pastebinre:
http://pastebin.com/KxH2Fmk9Na, akkor vegyük azt a megközelítést, amiről én beszélek (bár privátban hasonló jellegű megoldást mutattam), aktualizálva a példához:
http://pastebin.com/PVKe4uNANem tudom, ki hogy van vele, de nekem a második, háromsoros kód jobban áttekinthető. A korábbiaknál meg annyi van bent pluszban, hogy van két saját kivételosztály, ami tömböt is tud fogadni.
(#9007) modder : azzal egyetértek, hogy nem mindig egyértelmű, mire szabad/érdemes exceptiont használni. De pl. egy form injection probléma tipikusan olyan, ami miatt érdemes lehet exceptiont dobálni. Ahogy egy adatbázis-kapcsolódás is.
A 404-es hiba meg ilyen alapon ugyanúgy gyakran előfordulhat, ha valaki elcseszi a keresett URL-t, esetleg van hivatkozás Google-ön keresztül olyan oldalra, amit azóta már töröltek, vagy magán az oldalon van rossz hivatkozás van; de tulajdonképpen ezt is meg lehetne oldani sima error tömbökkel, ahogy az összes többi hibát is. Tulajdonképpen mindkettő megoldás alkalmazható minden problémára, kérdés, mire melyiket érdemes - bár az valóban érdekes felmérés lehet, mennyit ront a GYAKORLATBAN a teljesítményen az, ha valaki exceptionökre áll rá.
Ha valaki tud ilyen felmérésről, ne tartsa magában!===
(#9008) Athlon64+ : nem is kell "mindenhol" kivételeket hajigálni.
-
#9006
Sk8erPeter
nagyúr
modder
#9001
Sk8erPeter
nagyúr
Ez sajnos nem volt egy túlzottan érdemi reakció.
Pl. miután kijelentetted, hogy nem igazán tudsz olyan frameworkről, ami exceptionökre építené a működését, megmutattam a Symfony-t, mert próbáltam érdemben vitatkozni, nem csak általánosságban beszélni. A Symfonynál meg most hirtelen nem tudom, milyen meggyőzőbb frameworköt kellene neked mutatnom, hogy az exceptionök létjogosultsága valamennyire világosabbá váljon.Egyébként a gyakorlati ellenpéldákat én is hiányolom, ha már kritizálod azoknak a programozási szokásait, akik a kivételek használatára építenek. Azt érezteted, hogy a kivételekre építés rossz programozói gyakorlat (tehát valamit rosszul csinál az, aki erre alapozva kezeli a program menetében felmerülő hibákat), miközben nálunk okosabb emberek komplett keretrendszert építettek erre. Én jobban hajlanék az érveid elfogadására, ha alátámasztanád őket konkrét példákkal - attól függetlenül, hogy "minden probléma egyedi". Igen, a formvalidálás problémája is egyedi, meg az is, hogy hogyan kezelj le egy 404-es hibát. Én mindkettőre elmondtam a saját megoldásom (privátban komplett pszeudokódot is mutattam, ezt alátámasztandó), úgy tűnt, belátod az átláthatóság előnyeit kivételkezelésnél. De saját példát is mutathatnál, mert én nyitott vagyok más megoldásokra, ha az érdemi javulást hozhat a kódban.
Ha valaki vitatkozik az álláspontoddal, nem azért teszi, mert feltételezi, hogy hülyeségeket beszélsz, épp az a jó szakmai vita ismertetőjele, hogy szakmai szempontokkal győzzük meg egymást (én erre törekszem), nem pedig bezárkózásunknak adunk jelet.
A magasabb szintű programozói nyelvekben meg a kivételkezelés nagyon nem ördögtől való.
Kicsit számomra is olyan ez a vita, mintha arról beszélnénk, hogy mennyire nem éri meg objektumorientáltan programozni, mert az akár lassulást is hozhat. Ugyanez igaz C++-ra is: az OOP-s megoldás továbbra is lassabb marad, ezzel nyilván nem mondtam újat.
De ettől még megkérdőjelezni az OOP előnyeit nem érdemes, mert tény, hogy az átláthatóságban, követhetőségben, az objektumok logikai összetartozásában, kapcsolódásában, annak szemléltetésében, az emberi gondolkodáshoz való hasonlóságában, stb. annyi előnye van, ami miatt bőven van létjogosultsága (ez sem új, de elmondom).
Ettől függetlenül mégis hosszas érvek vannak, amik miatt pl. a Drupal még mindig nem állt át a teljes objektumorientáltságra: Drupal programming from an object-oriented perspective. De ennek nagyon sok történelmi gyökere is van (PHP 4 miatti kompatibilitás - most már erre nem terveznek). -
#9004
Sk8erPeter
nagyúr
modder
#8999
Sk8erPeter
nagyúr
"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 hiszem, én is érthető voltam, amikor leírtam, hogy egy általános jellegű Exception elkapásával minden kivételt el lehet kapni, és a kivétel keletkezésének módjáról mindent meg lehet tudni. Ha azt szeretnéd megtudni, hol dobja, és egész addig nem tudod, amíg nem keletkezett egy pontosan olyan specifikus hiba, akkor valóban az a megoldás létezik, hogy generálsz olyan hibát, vagy rákeresel. És? Nem értem a logikádat, ez miben tér el attól, ha te mondjuk ragaszkodsz a hibatömbös megoldásodhoz. Ha a hibatömbös hibakezelés forrásaira szeretnél rátalálni, akkor még a klasszikus exceptionökre vonatkozó backtrace-es megoldás sem áll a rendelkezésedre, de szerencsére mivel a PHP elég kényelmes nyelv, még erre is igénybe lehet venni egy plusz segítséget (kicsit mintha a bal kezeddel vakarnád meg a jobb füledet a tarkód mögül): debug_backtrace().
Még egy dolog: ha definiálsz saját exception osztályokat, akkor azoknak többnyire elég normális, egyedi neve van.
Pl. legyen épp ValidationException a neve.
Mondjuk ennek eldobása egy egyszerű globális fv.-en belül így néz ki:function blabla(){
// .......
if( $hiba_van ){
throw new ValidationException( 'ezért meg azért' );
}
// .......
}a Te megoldásod meg valami ehhez hasonló:
function blabla(){
// .......
if( $hiba_van ){
$errorArray['status'] = FALSE;
$errorArray['msg'] = 'ezért meg azért';
return $errorArray;
}
// .......
}Ha már Te mindenhol az ugyanilyen jellegű hibatömbös megoldást alkalmazod, és Ctrl+F-es módszer, akkor szerintem több esély van gyorsan megtalálni a throw new ValidationException részt.
De a tömbös megoldást továbbra sem kínál beépítetten backtrace megoldást."Nyilván, ha valaki idiótán programoz, arra nincsen mentség."
Ez önmagában igaz. De arra, amire reagáltál, ez valahogy kicsit sántít. Pl. ha már újrafelhasználásról beszélünk, nem tudom, valakinek miért kellene kitalálnia, hogy a kódot elkészítő illető pontosan milyen tömbindexeket használt. Ja, hát nézze át az egész kódot, ha már szar a dokumentáció, hisz' bár a függvényt készítő ember nem ért rá odaírni három sort, ha három kivételt dob a fv. elejére, de a kódot felhasználó illető majd nyilván rá fog érni átnézni a komplett kódot. Itt pedig ez az indexeléses módszer nem biztos, hogy olyan intuitív megoldás, hogy ránézésre, már az első példa láttán lehet tudni, hogy mi is a helyzet többféle alkalmazásnál. -
PazsitZ
addikt
Azt most már tudjuk, mi a szar, de a temérdek jobb, átláthatóbb, refaktorbarát alternatív javaslatot még nem találtam meg a hsz.-eidben.
Aki pedig azt állatja, hogy minden függvényt azzal kezd, hogy /** */, az biztos ráér programozni
Az annotáció pedig megkönnyíti a további fejlesztést, az autocomplete felhasználás során.
Mert meg sem kell nyitnod függvényt tartalmazó fájlt tudni fogod a be-ki-meneti paramétereket, típusukat és kivételeket, amit dobhat.
Ehelyett ha lehagyod, jobb esetben tízszer nyithatod a fájlt és böngészheted a függvényt, mit miként adj át és várj viszont. Utóbbi minden bizonnyal gyorsabb.
A tömbös indexes hibakezeléses megoldásos pedig aranyos, de ne akard már itt megmagyarázni, hogy ez a frankó, mert már nem tudom, hogy sírjak vagy nevessek.
-
#9000
Sk8erPeter
nagyúr
modder
#8998
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.
-
#8997
Sk8erPeter
nagyúr
modder
#8995
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.
-
#8969
Sk8erPeter
nagyúr
modder
#8967
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). -
#8949
Speeedfire
félisten
modder
#8948
-
#8947
Speeedfire
félisten
modder
#8946
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...
-
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?
-
-
-
-
Lacces
őstag
Olyan furcsa működik...
Újra kreáltam. De most bele mentem az adatbázisba és ott. (Elsőnek még a főoldalon és ott adtam meg az adatbázist...)Jogoknál. van olyan, hogy típus:
- globális
- adatbázis-specifikus.
(mindkettő típus jelen van a felhasználónál)Mi a különbség kettőjük között?
Amikor létrehoztam a felhasználót, hogy csak Select, Insert és Update jogokat kapjon, akkor automatikusan megadta az összes jogot, az adatbázis-specifikus részben.
De kipróbáltam és ott is módosítottam S, I, U jogokra. És ugyanúgy jó. Működik. -
modder
aktív tag
Az a baj még a "szeretnék megtanulni programozni" kérdésekkel, hogy sokan elfelejtik, hogy a programozás nem csak arról szól, hogy kódolok, és akkor ha elég sokat kódolok, akkor készen lesz és jó lesz. Ahogy a kovács szakma sem csak arról szól, hogy ütöm a forró vasat, és akkor jó lesz.
Nagyon sok munkát kell fektetni abba, -- amit már az előző hozzászólásomban meglebegtettem -- hogy jól meg tudd tervezni a kódod, és algoritmus érzék kell hozzá. Ezeket lehet fejleszteni. Ha két részre osztanám a programozói tudást: szintaxis+könyvtárak és tervezés+algoritmus, akkor a tanulásba beleölt idő nagy részét utóbbi kettő fogja kitenni. -- véleményem szerint
[szerk.]
és persze törekedni kell arra, hogy a források után angolul kutatunk, hiszen magyarul csak limitált forrás elérhető, főleg az újabb technológiákból. -
#7984
Sk8erPeter
nagyúr
modder
#7981
Sk8erPeter
nagyúr
Ja, ezzel jó lehet: [link].
Köszi!
Nem tudom, miért nem jutott eszembe, hogy mivel nem webszerveren keresztül futtatom a scriptet, nem állítódnak be a megfelelő változók... Ahtlon64+: na ez az argumentumos megoldás viszont nagyon melósnak tűnik. Ha tételezzük fel, lenne 30 site, annak mindegyikénél be kéne állítani a megfelelő argumentumokat, az annyira nem lenne szimpi. Persze ugyanúgy, mint a cURL-es megoldásnál, végig lehet rohangászni akár batch-fájlon keresztül az ütemezendő fájlokon, ciklussal, rögzített könyvtárstruktúra esetén, mindegyik szükséges változót beállítva, argumentumként átadva, de ennél a cURL-es megoldás szerintem ezerszer egyszerűbb.
Pl. konzolból futtatva, ha nem akarom, hogy bármit is írjon az stdoutra: curl example.com/cron.php. De köszi az ötletet! -
#6945
Speeedfire
félisten
modder
#6944
Speeedfire
félisten
Valószínű prefork lehet, mert valóban nem fogadta el. Ellenben abba is hagytam a nagy erőforrás miatt az apache projektet. Lecseréltem lighttpd-re, ha a youtube-nak megfelelt akkor nekem is megfelel.
Fele annyit memóriát eszik jelenleg, a cpu meg meg sem mozdul 1 szál mellett.
Csak itthoni használatra kell, a router admin felületével szenvedek, na meg akarok 1-2 statisztiai oldalt készíteni.
-
cucka
addikt
Nincs olyan, hogy állandóan, háttérben futó php script. Ha ilyesmit akarsz, akkor valamilyen nem scriptnyelvvel kell megvalósítani és gyakorlatilag kell írni egy kis saját webszervert hozzá.
A 20-30 másodpercenkénti lekérdezés fika, de ha gyorsítani akarsz a dolgon, akkor használj állandó mysql kapcsolatokat (lásd mysql_pconnect() ), ezzel elég sok időt tudsz spórolni.. -
#34784256
törölt tag
Köszi a választ, végülis ezt hoztam össze az ötletedből ( meg a google-ból ):
<script>
document.write('screen.Height/Width: x=' + screen.width + ' y=' + screen.height);
document.write('<a href="get_image.php?x=' + screen.width + '&y=' + screen.height + '">KLIKK IDE</a><br>');
document.write('window.innerHeight/Width: x=' + window.innerWidth + ' y=' + window.innerHeight);
document.write('<a href="get_image.php?x=' + window.innerWidth + '&y=' + window.innerHeight + '">KLIKK IDE</a><br>');
document.write('document.body.clientHeight/Width: x=' + document.body.clientWidth + ' y=' + document.body.clientHeight);
document.write('<a href="get_image.php?x=' + document.body.clientWidth + '&y=' + document.body.clientHeight + '">KLIKK IDE</a><br>');
document.write('document.documentElement.clientHeight/Width x=' + document.documentElement.clientWidth + ' y=' + document.documentElement.clientHeight);
document.write('<a href="get_image.php?x=' + document.documentElement.clientWidth + '&y=' + document.documentElement.clientHeight + '">KLIKK IDE</a><br>');
</script>Hálistennek minden böngészőben máshogy működik, úgyhogy végülis nem fogom használni
-
cucka
addikt
Na most ha pl 20 ember chatel akkor ez mennyire terheli meg a szervert? Illetve webhosting szolgáltató hogy értékeli az ilyet, például alapból limitálva van a processzor időm és belassulhat az egész site emiatt?
Ha normálisan van beállítva a mysql, akkor a lekérdezések nagy részét cache-ből fogja lökni, meg amúgy is kis adatmennyiségekről van szó - tehát ha normálisan írod meg a php részét, akkor kb. észre sem lehet majd venni a szerver terhelést.ha valaki küld új üzenetet akkor és csak akkor a script kiküldené az összes aktív kliensnek, na de hogy oldom meg, hogy apache csak úgy küldjön adatot kérés nélkül a klienseknek
Ajax-al sehogy nem oldod meg, mert csak a kliens kérdezgetheti a szervert, ezért aszinkron. Azt hiszem az Operában van valamilyen technológia, amivel megoldható, de az Opera 1% körüli részesedése miatt ez kb. annyit sem ér, hogy utánanézzekEgyébként memory táblákkal szerintem fölösleges pöcsölni, mint ahogy file-ba mentéssel is. Chat log-nál sok sor lesz a táblában de mindegyikben kevés adat, ezért indexeléssel teljesen jól meg lehet oldani a dolgot. (pl. ha a kliens már úgy kérdezi meg a szervert, hogy az x. id-jú mezőtől kérem az adatokat, akkor onnan könnyű gyors lekérdezést írni)
Természetesen ha több száz felhasználós chat-et szeretnél, akkor oda el lehet gondolkozni más technológiákon (pl. java kliens és/vagy szerver oldalra)
))))))))))))))))))))))))))))))))))
Új hozzászólás Aktív témák
- 127 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4080
- Lenovo Yoga C630 notebook 4K UHD 15,4" kijelző i7-8550U/16GB ram /128GB SSD
- HP ENVY 17,3" 4k UHD IPS notebook - Core i7-1165G7, 16GB, 1TB SSD
- Amazfit Balance okosóra eladó, újszerű, 1 hét garancia
- Asus TUF A15 FA507NU - 15.6"FHD IPS 144Hz - Ryzen 7 7735HS - 8GB - 512GB - RTX 4050 -2.5 év gari
- Samsung Galaxy A56 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- Razer Blade 18 QHD+ 300Hz mini-LED i9-14900HX 32GB DDR5 RTX 4090 2TB SSD (ELKELT)
- AKCIÓ! ASUS PRO WS W790E-SAGE SE alaplap garanciával hibátlan működéssel
- LG 27GR95QL - 27" OLED / Limitált LoL Edition / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync
- Bomba ár! HP Elitebook 850 G8 - i5-11GEN I 16GB I 256GB SSD I 15,6" FULLHD I Cam I W11 I Gari!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest