- iPhone topik
- Mindent vitt 2024 elején a Galaxy S24 Ultra (Androidon)
- Nokia 3210 - felélni az örökséget
- Redmi Note 9 Pro [joyeuse]
- Fotók, videók mobillal
- Honor Magic6 Pro - kör közepén számok
- Honor Magic V2 - origami
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Xiaomi Mi 11 Lite - 4G-vel vagy 5G-vel kéred?
- Samsung Galaxy A52s 5G - jó S-tehetség
Hirdetés
-
Befutott a Destiny 2: The Final Shape premier előzetese
gp Néhány nap múlva befut a játék legújabb nagy DLC-je, amely pontot tesz egy hosszú évek óta tartó harc végére.
-
A választási tévinformációk ellen küzd a Meta
it Az EU monitorozza azokat az intézkedéseket, amelyeket a választási tévinformációk ellen alkalmaz a Meta.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
Új hozzászólás Aktív témák
-
#8938
Sk8erPeter
nagyúr
cAby
#8937
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"Sk8erPeter
-
#8939
Sk8erPeter
nagyúr
Sk8erPeter
#8938
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
-
#8954
Sk8erPeter
nagyúr
Speeedfire
#8943
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é.[ Szerkesztve ]
Sk8erPeter
-
#8964
Sk8erPeter
nagyúr
Peter Kiss
#8963
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?[ Szerkesztve ]
Sk8erPeter
-
#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).[ Szerkesztve ]
Sk8erPeter
-
#8973
Sk8erPeter
nagyúr
raczger
#8972
Sk8erPeter
nagyúr
válasz
raczger
#8972
üzenetére
Ha nem szeretnéd, hogy a kiterjesztés hozzá legyen adva Apache esetén, szedd ki explicite a MultiViews opciót, ajánlott rövid cikk a témában, ami pont URL-átírásos problémáról szól: [link]. Az ott linkelt másik doksi még rövidebben összefoglalja: [link].
[ Szerkesztve ]
Sk8erPeter
-
#8975
Sk8erPeter
nagyúr
raczger
#8974
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.
Sk8erPeter
-
#8984
Sk8erPeter
nagyúr
Speeedfire
#8983
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.Sk8erPeter
-
#8994
Sk8erPeter
nagyúr
mobal
#8985
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.
Sk8erPeter
-
#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.
Sk8erPeter
-
#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.
Sk8erPeter
-
#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.Sk8erPeter
-
#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).Sk8erPeter
-
#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.
[ Szerkesztve ]
Sk8erPeter
-
#9011
Sk8erPeter
nagyúr
Sk8erPeter
#9009
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#9009
üzenetére
"felmérés" helyett inkább simán teljesítménymérésre gondoltam.
(#9010) Speeedfire : bárcsak közérthetőbben írtad volna le, mit szeretnél.
[ Szerkesztve ]
Sk8erPeter
-
#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.[ Szerkesztve ]
Sk8erPeter
-
#9024
Sk8erPeter
nagyúr
Lacces
#9023
Sk8erPeter
nagyúr
Veled jól járnak a könyvesboltok.
Nem tudom, mit nem értesz a Server Faulton fent lévő válaszon.
Mondjuk nem ártana, ha utánaolvasgatnál, hogyan csináld, mielőtt pánikolsz (ez nagy általánosságban is igaz), pl. nagyon gyors keresés után itt is megvan az, amit írtál: [link]. Vagy még jobb: [link].
Ott van halál egyértelműen az is, hogy mitől működik (többek közt):
"Tip: In order to use the yiic tool as shown above, the CLI PHP program must be
on the command search path. If not, the following command may be used instead:
path/to/php /wwwroot/yii/framework/yiic.php webapp /wwwroot/blog"
Ebből egyértelmű, hogy a PHP terminálban használható változatának elérési útja alatt kell végrehajtani azt, amit írtál, vagy környezeti változók közé kell tenni a PHP CLI elérési útját, ÉS még ezenkívül nyilván léteznie is kell a /wwwroot/yii/framework/yiic.php elérési út alatt a megfelelő fájlnak... (remélem nem kell hozzátennem, hogy ez a wwwroot könyvtár nem a Szentírás, attól függ ez az elérési út is, hogy hova rakod...)Egyébként ha fogalmad sincs, mit csinálj, miért nem olvasgatsz magyar fórumokat? Ott volt a link hozzá a hivatalos honlapon:
http://www.yiiframework.com/forum/index.php/forum/33-hungarian/[ Szerkesztve ]
Sk8erPeter
-
#9028
Sk8erPeter
nagyúr
Lacces
#9026
Sk8erPeter
nagyúr
Sehol nem írtam PHP CPL-ről...
A többire meg annyit javasolnék, hogy mielőtt másoktól várnád, hogy szinte vezessék az egeredet, hova kattints, és pötyögnének a billentyűzeteden, próbálj alaposan utánaolvasni, biztos hatmillió tutorialt találsz róla. Ha meg olyan alapvető kérdések merülnek fel, hogy mi az a command line vagy terminal, akkor előbb annak kellene utánanézni, és csak utána foglalkozni a komolyabbakkal.Sk8erPeter
-
#9033
Sk8erPeter
nagyúr
Speeedfire
#9032
Sk8erPeter
nagyúr
válasz
Speeedfire
#9032
üzenetére
Micsoda megoldás.
Abból, hogy valakinek egyedi hibák miatt nem sikerült megcsinálnia valamit Ubuntun, az az egyenes ágú következtetés, hogy "ne használj Ubuntut", BIZTOS csakis az Ubuntu és a fejlesztői lehetnek a hibásak!... [ Szerkesztve ]
Sk8erPeter
-
#9036
Sk8erPeter
nagyúr
Speeedfire
#9034
Sk8erPeter
nagyúr
válasz
Speeedfire
#9034
üzenetére
Nem is mondtam egy szóval sem, hogy nincsenek hibái. Viszont biztos, hogy a Yii-t össze lehet hozni Ubuntun is, az, hogy Laccesnek nem sikerült, nem azt jelenti, hogy Ubuntun még ezt sem lehet működésbe hozni.
Webfejlesztgettem Ubuntu alatt is, érdekes módon nekem nem volt olyan problémám, hogy bugok miatt képtelen voltam használni a terminált...
Nyilván rengeteg bugja van, de nem pont a Yii telepítése az, ami kiveri a biztosítékot.
Félre ne értsd, nem tisztem védeni az Ubuntut, jelenleg nem is használom (egyszóval: kb. leszarom), de mondjuk az is igaz, hogy a Linux disztrók közül a "felhasználóbarátsága" miatt az egyik legnépszerűbb, nyilván nagyon sokan használják, így gondolom nem gyengén derülnek ki hibái (nem is beszélve az egységsugarú júzerekről ). Aztán lehet, hogy fostenger, nem tudom, konkrét, alátámasztott szakmai véleményt erről még nem olvastam, pedig jobb olyat olvasni, mint azt, hogy "az egy szar, mert a Pisti is megmondta". ===
(#9035) Athlon64+ : ennél jobban alátámasztott szakmai véleményt még soha nem olvastam.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Sk8erPeter
-
#9038
Sk8erPeter
nagyúr
Peter Kiss
#9037
Sk8erPeter
nagyúr
válasz
Peter Kiss
#9037
üzenetére
És ki/mi határozza meg, hogy hol a "helye"?
Szerk.:
Amúgy attól az új bal oldalt szereplő Ubi-menütől én őszintén szólva kimentem a fazonomból. Valahogy nagyon zavart, persze mondjuk az is hozzátartozik, hogy egy régi fos gépre telepítettem melóhelyen, mert azt gondoltam, az legalább gyorsan fut majd rajta - hát nem futott gyorsan. A menü megjelenésére meg külön várni kellett...[ Szerkesztve ]
Sk8erPeter
-
#9048
Sk8erPeter
nagyúr
Speeedfire
#9046
Sk8erPeter
nagyúr
válasz
Speeedfire
#9046
üzenetére
Fricska akart lenni a sok gyökér kérdésre reagálva.
Bővebben: sokan úgy kérdeznek, hogy óvodás szintű, degeneráltak által is érthető dokumentációk/tutorialok/e-bookok/... állnak rendelkezésre arról, hogyan kell megoldani egy adott problémát, de sokan ezt lusták elolvasni/kipróbálni/felfogni, és úgy gondolják, jobb, ha inkább f@szságokat kérdeznek a fórumokon, majd valaki megmondja a megoldást attól kezdve, hogy hogyan kapcsolja be a gépet, nem zavarja őket, ha kicsit hülyét csinálnak magukból, belefér. Az ilyenektől eléggé felhígul egy szakmai fórum, elviszi a témaköröket a "buta kérdések topicja" irányba.Sk8erPeter
-
#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.
Sk8erPeter
-
#9063
Sk8erPeter
nagyúr
Tele von Zsinór
#9062
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#9062
üzenetére
Igen, én sem értem, minek keverni a szezont a fazonnal...
Ez kb. olyan, mintha egy jQuery-kódot valaki teleszórna document.getElementById()-kkel...Sk8erPeter
-
#9066
Sk8erPeter
nagyúr
Jim-Y
#9056
Sk8erPeter
nagyúr
("#saleBtn").click(function(){
var xmlhttp;
if (window.XMLHttpRequest) {
xmlhttp=new XMLHttpRequest();
} else {
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.onreadystatechange=function() {
if (xmlhttp.readyState==4 && xmlhttp.status==200) {
var jsonobj=new Function("return "+xmlhttp.responseText)();
$("#goodsResult").text(jsonobj.entity.countrycode);
}
}
xmlhttp.open("GET","../SERVER/my_extension.php?query=cc",true);
xmlhttp.send();
});Ez jQuery-vel kifejezve (ha már azt használsz), kicsit kibővítve, nagyon egyszerű példával élve:
("#saleBtn").click(function () {
var
processing_file = "../SERVER/my_extension.php?query=cc",
jqxhr = $.getJSON(processing_file, function (jsonObj) {
if(jsonObj.status == 'success'){
$("#goodsResult").text(jsonObj.data.entity.countrycode);
}
else{
$("#goodsResult").text(jsonObj.data.msg);
}
}).error(function () {
alert("There was an error while processing your request!");
})
});A PHP-fájlban (lehetne másképp is, rengeteg módszer létezik rá, ez csak egy gyorspélda):
<?php
$query = isset($_GET["query"]) ? $_GET["query"] : '';
$jsonStuff['status'] = FALSE;
$jsonStuff['data'] = array('msg'=>'');
if ($query == "cc") {
$jsonStuff['data'] = file_get_contents('test.txt');
$jsonStuff['msg'] = 'Success';
$jsonStuff['status'] = TRUE;
}
else{
$jsonStuff['data']['msg'] = "no data received";
}
echo json_encode($jsonStuff);(Megj.: a ?> lezárást szándékosan nem tettem ki, nem is kötelező, sőt, ha nem várunk pl. HTML-outputot utána, inkább nem is érdemes.)
===
(#9065) modder : néha meg tudsz lepni a reakcióiddal.
Senki nem mondta, hogy f@szfej, de ha az ember elkezdi használni a jQuery-t, a használható, akár kezdőknek szóló tutorialok között biztos, hogy megemlítik az AJAX-os függvényeket. Az XMLHttpRequest-es szarakodással meg az ember igazából ezerszer többet szív és gépel feleslegesen, mintha egyszer elolvasná a doksik között az AJAX-ra vonatkozó részt (lásd jQuery a cross-browser dolgokat eleve lekezeli).[ Szerkesztve ]
Sk8erPeter
-
#9068
Sk8erPeter
nagyúr
Jim-Y
#9067
Sk8erPeter
nagyúr
Persze, így érthető, remélem azért nem tűnt nagyon sértőnek, amit írtam, ha igen, akkor bocs.
Mi is átéltük, milyen az, amikor fogalmunk sincs, mi fán terem a jQuery.
Szóval kérdezz nyugodtan, ha felmerül valami, van amúgy külön topicja is: jQuery kérdések.
Sk8erPeter
-
#9078
Sk8erPeter
nagyúr
Speeedfire
#9077
Sk8erPeter
nagyúr
-
#9094
Sk8erPeter
nagyúr
mobal
#9093
Sk8erPeter
nagyúr
Ahogy elnézem, az oldaladon van egy ilyen:
<input type="submit" name="fb" value="Facebook">Innen várnád, hogy beállítódjon a $_POST['fb'], de mivel történik egy átirányítás a Facebookra, és ott történik az authentikáció, ezt a $_POST értéket legfeljebb a Fácsé kapná meg az átirányítás során, a Te oldaladon a visszairányításnál már gondolom ez nincs beállítva. Szóval nem a $_POST['fb'] meglétét kellene vizsgálni. Mondjuk nem próbáltam még PHP-vel a FB-os authentikációt, de első ránézésre így lenne logikus.
Sk8erPeter
-
#9097
Sk8erPeter
nagyúr
Sk8erPeter
#9066
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#9066
üzenetére
Most látom, hogy itt én is simán ("#saleBtn")-t írtam az elején, helyesen a dollárjellel kiegészítve: $("#saleBtn").
Sk8erPeter
-
#9100
Sk8erPeter
nagyúr
Jim-Y
#9098
Sk8erPeter
nagyúr
Ne add fel, mert ha feladod, abból nem tanulsz.
Igazából gyorsan, fejből írtam a kódot, szóval természetesen tartalmazhat hibát, szóval ez inkább szemléltetés akart lenni.
De jó lenne tudni, hogy nálad mi volt a konkrét hiba oka, ezért próbáld meg pl. ilyen módon lekezelni a hibát: [link], meg itt is vannak jó példák: [link].
Aztán írd meg, konkrétan milyen hibaüzenetet írt!
Már ha az .error() függvénybe belelép egyáltalán.Sk8erPeter
-
#9113
Sk8erPeter
nagyúr
Lacces
#9112
Sk8erPeter
nagyúr
"hol van a modul könyvtár?"
Gondolom létre kell hozni.... és igen, gyors Guglizás után - nem használtam még ezt a frameworköt - pl. itt mutatja a "Yii User Management Module" telepítésének módját: [link].
van ez a rész:
"Extract the Yii User Management Module under the modules/ directory of your new Web Application. Replace the _0.4 with the latest Version available.$ cd testdrive/protected
$ mkdir modules
$ cd modules
$ wget http://www.yiiframework.com/extension/yii-user-management/files/User_Management_Module_0.4.tar.bz2
$ tar xvf User_Management_Module_0.4.tar.bz2
""mkdir modules", magyarul ő is létrehozza a modules könyvtárat, aztán odanavigál, majd kibontja a modul tartalmát, amin belül először a modul nevét tartalmazó könyvtár van, ami jelen esetben - most letöltöttem - a "user" nevű.
"és hogy shop mappát rakjam oda, vagy a shop mappa tartalmát?"
Értelemszerűen ennél a modulnál is shop könyvtárat kellene beleraknod a modules könyvtárba. Ez ebben a formában elég logikus, gondolj bele, mi lenne, ha mondjuk 100 modult telepítenél, akkor 100 modul tartalma lenne ömlesztve? Az úgy irtó gány lenne.
Tehát ha most telepítenéd a fenti modult, meg azt a webshoposat, akkor elméletileg így kéne kinéznie a könyvtárszerkezetednek:yiikönyvtárad
|- ....
|- modules
|- shop
|- user
|- ...Épp azáltal lesz moduláris a felépítés, hogy jól elkülöníthető egységeket kapcsolsz hozzá a meglévő rendszeredhez (vagy épp választasz le róla).
Egész értelmesen sikerült megfogalmaznom egy liter bor és 5 sör után.
[ Szerkesztve ]
Sk8erPeter
-
#9127
Sk8erPeter
nagyúr
Speeedfire
#9115
Sk8erPeter
nagyúr
válasz
Speeedfire
#9115
üzenetére
A selectnél még oké, a checkbox kevésbé világos, mert az szerintem alapból nem szokott átmenni szerveroldalra, ha nincs semmi kipipálva.
Pl. select:
<select class="asdasd" name="form_elem_select[]">
<option>- semmi -</option>
<option value="blabla_1">Blabla 1</option>
<option value="blabla_2">Blabla 2</option>
<option value="blabla_3">Blabla 3</option>
<option value="blabla_4">Blabla 4</option>
</select>Ha így néz ki, akkor itt az első, a - semmi - lesz a kiválasztott option (mivel sehol nincs explicite a selected="selected"), a szerveroldalon pedig ezt kapod a $_POST-ban:
array (
'form_elem_select' => '- semmi -',
)Épp ezért inkább érdemes egy default üres értéket adni neki:
<select class="asdasd" name="form_elem_select[]">
<option value="">- semmi -</option>
<option value="blabla_1">Blabla 1</option>
<option value="blabla_2">Blabla 2</option>
<option value="blabla_3">Blabla 3</option>
<option value="blabla_4">Blabla 4</option>
</select>Így ez lesz a $_POST-ban:
array (
'form_elem_select' => '',
)Erre így könnyű ráereszteni egy empty() ellenőrzést, és akkor pampoghatsz, hogy válasszon ki valamit a júzer, ha kell.
A checkbox általában nem jelenik meg szerveroldalon, ha nem választasz ki semmit, úgyhogy azt nem vágom...
Az empty(), amire kérdeztél, teljesen jó, igen.
A foreach-et és más ciklusokat is tovább lehet léptetni "kierőszakoltan" continue-val: [link].
===
(#9117) Lacces : ez függ attól, van-e jóféle iterátor a bejárandó elemhez.
Meg a láncolt listánál szokták így is, hogy egyszerű legyen, mint egy marék lepkefing: while( loszar->next() ){...} .(#9122) Lacces :
"Másik épp nézem át, de a javascript / jquery az hol tárolódik?"
Őőőőő, nincs kereső a gépeden?
Letöltöttem a Yii-t, és nagyjából 10 másodperc alatt megvolt keresővel...[ Szerkesztve ]
Sk8erPeter
-
#9130
Sk8erPeter
nagyúr
Lacces
#9128
Sk8erPeter
nagyúr
-
#9133
Sk8erPeter
nagyúr
Speeedfire
#9132
Sk8erPeter
nagyúr
válasz
Speeedfire
#9132
üzenetére
ja, a $tomb az itt pont nem tömb lesz, hanem a tömbindex/kulcs.
$value1 = $value[0]; $value2 = $value[1];
Ez így ellenőrzés nélkül nem biztos, hogy túl jó ötlet, vagy garantált, hogy a $_POST['post'] aktuális elemén belül mindig lesz 0. és 1. index? (és nem lesz kevesebb vagy éppen több kulcs?)Sk8erPeter
-
#9135
Sk8erPeter
nagyúr
Speeedfire
#9134
Sk8erPeter
nagyúr
válasz
Speeedfire
#9134
üzenetére
Ha nem töltötte ki a másik mezőt, akkor akár megoldhatnád a kérdést default értékekkel, az első mező értékének függvényében.
Vagy egyszerűen kötelezővé teszed a második mező kitöltését is, meg is vizsgálod, megvan-e mindkettő, és csak ennek megléte esetén dolgozod fel a formot, és kész.===
(#9128) Lacces : közben eszembe jutott, hogy gyűlölöd a terminált.
De létezik az Ubuntu default fájlkezelőjében is (Nautilus) kereső, ha nyomatsz egy Ctrl+F-et..... Meg nem is egy kétpaneles fájlkezelő van GNOME-hoz és KDE-hez egyaránt - de KDE-st is használatsz GNOME-on is, pl. akár Krusader (még talán ez viszonylag hasonlít a Windows-os Total Commanderhez, de sajnos eddigi tapasztalataim alapján egyik sem közelíti meg azt).[ Szerkesztve ]
Sk8erPeter
-
#9139
Sk8erPeter
nagyúr
Entrecampos
#9138
Sk8erPeter
nagyúr
válasz
Entrecampos
#9138
üzenetére
"nagyon túl bonyolítsátok a dolgokat"
Nekem meg nem bánTSa és nem is hasogaSSa a fülemet...
Jó kezdés volt.A tömbös elrendezés valóban véletlenül maradt benne, és azért, mert ezt ollóztam egy korábban általam készített, formelem-klónozós scripthez tartozó markupból:
http://jsfiddle.net/Sk8erPeter/RqYYj/
Ha klónozod az elemeket, jobban jársz, ha nem írod felül az előző elemet, hanem lehetővé teszed, hogy a klónozott elemek is láthatók legyenek szerveroldalon... Valószínűleg nem azért klónozod, mert a korábbi formelemek értékét el szeretnéd veszíteni.
Ha pedig ezáltal egy tömb keletkezik szerveroldalon, azt egy tömbbel be kell járni. Ez aztán rendkívül bonyolult.
Egyébként ez a szögletes zárójeles megoldás annyit módosít a korábban írt példámon, hogy szerveroldalon nem ezt látod a $_POST-ban:
array (
'form_elem_select' => '- semmi -',
)
hanem ezt:
array (
'form_elem_select' =>
array (
0 => '- semmi -',
),
)Az, hogy ez plusz terheléseket róna a szerverre, az egyszerűen baromság. Ha a ciklus egyetlen lépés után megáll, mert mindössze egyetlen elem található benne, akkor ez nem jelent semmiféle plusz terhelést (az, hogy mondjuk egy, a ciklus léptetéséhez felhasznált változó indexét megnöveli eggyel, talán ne vegyük a releváns "terhelés" és időtöbblet kategóriájába). Cserébe felkészülsz arra az esetre is, ha valóban több elem létezik a tömbben.
A szögletes zárójelekkel tudod jelezni jelen esetben a PHP felé, hogy itt egy tömb következik, kezelje is annak megfelelően.A tömbös megoldással nincs semmi baj. Nem muszáj alkalmazni, de nyugodtan lehet. Anélkül és vele is jól működő megoldásokat lehet összehozni.
Ha az én mondókám nem is volt számodra meggyőző, akkor példának hadd hozzam fel, hogy a Drupal előszeretettel alkalmazza a Form API-jában a mezők tömbalapú generálását. Biztos azért csinálták így, mert nem értenek hozzá...Szerk.: Egyébként kilencmillió soros if-elseif-elseif-elseif-elseif...-else megoldások helyett létezik switch-case is. Meg céltól függ, milyen ellenőrzésre van szükséged, egyáltalán mit szeretnél csinálni a kapott adatokkal.
[ Szerkesztve ]
Sk8erPeter
-
#9144
Sk8erPeter
nagyúr
Entrecampos
#9141
Sk8erPeter
nagyúr
válasz
Entrecampos
#9141
üzenetére
"Majd egyszer mérjetek egy lefutási időt..."
Sokkal hitelesebb lett volna a mondókád, ha valami konkrétumot is tartalmaz, nem csak levegőbe beszélést: például a saját tapasztalataidat futási időkről, esetleg konkrét mérési eredményeidet."Persze, itt nem 3 elem bejárására gondoltam... Illetve 3 aktív felhasználónál. "
Ja, mert mi eddigi életünkben 3 elemnél többet tartalmazó tömböt nem jártunk be, és elképzelésünk sincsen arról, hogy milyen is lehet, ha egy oldalon 3-nál több felhasználó is tevékenykedik egyszerre...
Nem azért, de ekkora arccal, a többiek lebecsülésével (a másik tudásának vagy tapasztalatainak ismerete nélkül) betolni egy indokolatlanul nagyképű dumát nem túl szimpatikus kezdés a fórumon - ahogy elnézem, ebben a topicban eddig ez a kettő volt az összes termésed.
Hidd el, hogy nagyon jó szakmai vitákat lehet folytatni itt a fórumon arcoskodás nélkül is - ha jó szakmai érvet hozol fel, elfogadjuk, de lehet, hogy vitatjuk - amivel még nincs is semmi baj, mert egy ilyen vita termékeny is lehet, mindegyik résztvevő fél tanulhat belőle a másiktól. De amiket eddig villantottál, annak alapot nem adtál, csak értelmetlenül lefitymáltad más kódját.Visszatérve a kérdésre:
nagyon nem árt, ha az ember a kód rugalmasságát, átláthatóságát, módosíthatóságát, bizonyos részek egységes kezelését is az első szempontok közé helyezi.
Például ha éppen az a cél, hogy mondjuk valamilyen formmezőket azonos módon tudj validálni, feldolgozni, azonos tömbbe tartozzanak, akkor ez a tömbös megoldás nagyon előnyös lehet, ha valaki jól írja meg, a hozzá tartozó kód gyorsan átlátható, könnyen kezelhető lehet.
Vegyük azt, hogy mondjuk épp egy select lista klónozgatásáról van szó, előre nem lehet tudni, mennyi keletkezik, de azért ugyanezen a formon mondjuk van még 10 text field, 5 textarea, néhány radio box, checkbox, stb.
Te meg azt mondod, hogy fúj de csúnya ez a tömbös megoldás, te úgy fogod megoldani, hogy a select listáknál mondjuk a name attribútum mögé raksz egy alsóvonás+inkrementált számot (tehát mondjuk ilyen lesz: name="list_1", name="list_2", stb.) Gondolj bele, milyen csúnya lesz ennek a szerveroldali kezelése - és mennyivel szebben kezelhető lenne egy tömbös megoldás, ahol egybetartozó elemeken rohangászhatnál végig.
Vagy:
a $_POST-on belül mondjuk van 100 formmező, ebből kb. 30 mondjuk a fentihez hasonlóan összetartozó, de szerinted legyenek csak széjjeldobálva, majd valami érdekes módszerrel megpróbáljuk bejárni - pl. a $_POST tömbön végigmegyünk, majd minden egyes elemre valami ellenőrzést megpróbálunk pl. a name attribútum első pár karaktere alapján ellenőrizni (vagy nem tudom, hogy gondoltad). Nem lenne szebb úgy, ha a 30 teljesen egybetartozó, hasonló módon kezelendő mező egybetartozna, és egy tömbön belüli tömb lenne? Így azonos name-en belül több field szerepelne.
Kétlem, hogy ez a fajta a tömbbe rendezés releváns teljesítményromlást okozna.Remélem innentől már némi konkrétumokat is tartalmazó hsz.-eket fogsz tudni kreálni, úgy érdemben is tudnánk vitatkozni.
[ Szerkesztve ]
Sk8erPeter
-
#9148
Sk8erPeter
nagyúr
Jim-Y
#9145
Sk8erPeter
nagyúr
Gondolom JSON-ről beszélsz.
Ez esetben:
test.php:
<?php
$response['x'] = 'valami';
$response['y'] = 'valamimas';
echo json_encode($response);(Ismét szándékosan maradt le a záró PHP-tag (?>).)
Így JSON-ben ennek a feldolgozása pl. jQuery segítségével ennyi:
$.post("test.php", function(response) {
alert("response.x: " + response.x);
alert("response.y: " + response.y);
});[ Szerkesztve ]
Sk8erPeter
-
#9150
Sk8erPeter
nagyúr
Speeedfire
#9146
Sk8erPeter
nagyúr
válasz
Speeedfire
#9146
üzenetére
"Esetleg ha valami speckó karaktert raksz a sztingek közé akkor explode-al szét lehet szedni a sztringet."
Ezt inkább ne. Kerülendő, rossz programozási szokás, nem is "biztonságos" - ha ehhez valaki hozzászokik, elfelejtheti, hogy az a bizonyos belepakolt érték szintén tartalmazhat olyan karaktersorozatot, ami épp az elválasztó karaktersorozat, kizárni nem lehet.
Főleg, ha van alternatíva (pl. amit írtam fentebb
).Sk8erPeter
) 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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
).Új hozzászólás Aktív témák
- Bomba ár! HP EliteBook 840 G5 - i5-8G I 8GB I 128GB SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- Bomba ár! Dell Latitude 5490 - i5-7GEN I 8GB I 256GB SSD I 14" HD I HDMI I Cam I W10 I Gari!
- Bomba ár! Dell Latitude 5580 - i5-G6 I 8-16GB I 256 SSD I 15,6" FHD I HDMI I CAM I W10 I Garancia
- iPhone 11 Pro 64 GB 88% aksival, hibátlan állapot (kártyafüggetlen)
- Dell Latitude 7480,14",FHD,i5-6300U,8GB DDR4,256GB SSD,WIN10,TOUCH
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen