Hardcore kocka bejegyzés következik, kérjük álljanak hátrébb.
Szerinted melyik a jobb kód? (Katt a képre, látni fogsz egy alsó és egy felső verziót.)
Kereső revamp - szűkítés szerzőreUpdate nov. 13. 10:04: már három verzió lapul a kép mögött! Frissítettem Kristóf javaslatával.
19 hozzászólás
Definiáld a
Szerintem egy 3. verzió nyer majd nálad is, amikor elég mély-OO paradigma-transzba zuhanva újra alkotod ezt is (:
jobbot. Sebesség szempontjából valószínűleg a fölső konkatenálós és
inlájnosabba befutó. Átláthatóság szempontjából a második kicsit informatívabb (főleg egy külső szemlélőnek), ami megint csak dobogós helyet erdeményez neki.
Szerintem egy 3. verzió nyer majd nálad is, amikor elég mély-OO paradigma-transzba zuhanva újra alkotod ezt is (:
válasz
Ha a célod az átláhatóság, akkor szerintem a 2. verzió sem visz sokkal közelebb a célhoz. 
Én ilyen esetekben ilyesmit alkalmazok (egy függény paraméterezése a példa):
Szerintem így + a soronkénti kommenteléssel sokkal átláthatóbb, mintha "beszédes" változónevekkel ügyeskedsz. Miccólsz?
Én ilyen esetekben ilyesmit alkalmazok (egy függény paraméterezése a példa):
függvény (
param1, // ez az első param
param2, // ez a második param
param3, // ez a harmadik
stb
);Szerintem így + a soronkénti kommenteléssel sokkal átláthatóbb, mintha "beszédes" változónevekkel ügyeskedsz. Miccólsz?
Kristóf, köszi, jó ötlet mondjuk élőben a paramN-ek nem egyforma hosszúak na ki is próbáltam, ízlelgetem
Ps. Olyat nem lehetne hogy legalább itt a kommentbox alatt onthefly bejelentkezz kommenteléskor? (Firefox megjegyzi a mezőket…) Visszamenőleg betársítottam 26 anonim kommentedet a useredhez
mondjuk élőben a paramN-ek nem egyforma hosszúak na ki is próbáltam, ízlelgetem Ps. Olyat nem lehetne hogy legalább itt a kommentbox alatt onthefly bejelentkezz kommenteléskor?
(Firefox megjegyzi a mezőket…) Visszamenőleg betársítottam 26 anonim kommentedet a useredhez
És ha az elsőt és a harmadikat kombinálnád?
Valahogy így:
Tudom nem egy nagy ötlet, de ha már kérdezted… Teljesítmény szempontjából esetleg kicserélheted még az idézőjeleket (") aposztrófra ('), hogy ne dolgozza fel őket a fordító, bár ez nem tudom mennyire illeszkedik a kódolási stílusodhoz.
Valahogy így:
$var= "and ".
function(
"param1", // egy
"param2", // ketto
"paramN" // N
;
Tudom nem egy nagy ötlet, de ha már kérdezted… Teljesítmény szempontjából esetleg kicserélheted még az idézőjeleket (") aposztrófra ('), hogy ne dolgozza fel őket a fordító, bár ez nem tudom mennyire illeszkedik a kódolási stílusodhoz.
ph03nixx, a konkrét kód esetében szvsz ez rontaná az átláthatóságot.
Egyébként az aposztróf vs. idézőjel annyit számít a kód lefutásának idejében, mint az, hogy melyik ujjammal gépeltem be Érdemes inkább azzal az ujjal gépelni, amelyikkel gyorsabban megy (azt az idézőjelet/aposztrófot használni, amelyik jobban kézreáll, és az időt valami értelmesebbel tölteni, mint pl. azt javítgatni tesztelés után, hogy jaj már megint aposztrófok között akartam kiíratni egy $változót…)
Egyébként az aposztróf vs. idézőjel annyit számít a kód lefutásának idejében, mint az, hogy melyik ujjammal gépeltem be
Érdemes inkább azzal az ujjal gépelni, amelyikkel gyorsabban megy (azt az idézőjelet/aposztrófot használni, amelyik jobban kézreáll, és az időt valami értelmesebbel tölteni, mint pl. azt javítgatni tesztelés után, hogy jaj már megint aposztrófok között akartam kiíratni egy $változót…)
nrg, én is pont a Propelt akartam beszólni, de aztán meggondoltam magam és kitöröltem a hozzászólást, nehogy végeláthatatlan hitvitákba kelljen bonyolódnom
Haszprus, nézd meg a Symfony keretrendszert, azon belül is a dokumentáció 8. fejezetét: symfony Web PHP Framework » Chapter 8 - Inside The Model Layer. Ez Propelt használ, a
Bár az is tény, hogy bonyolultabb lekérdezéseket (amiben AND meg OR is van összevissza) Propellel elég halál összeállítani.
Haszprus, nézd meg a Symfony keretrendszert, azon belül is a dokumentáció 8. fejezetét: symfony Web PHP Framework » Chapter 8 - Inside The Model Layer. Ez Propelt használ, a
Retrieving records with criteriaalfejezet lehet érdekes a számodra.
Bár az is tény, hogy bonyolultabb lekérdezéseket (amiben AND meg OR is van összevissza) Propellel elég halál összeállítani.
Tamás,
szvsz nyilván nem fogja nekem semmi legenerálni user interfészről vagy valami könnyű paraméterfájlból a 30 soros, mindenféle feltétel szerint dinamikusan összeálló sql queryjeimet
de a Propelt meg fogom nézni amint lehet, csak még mindig nem megy az oldaluk (lol?)
symfonyt nézem, thx… update szimpi a cucc…
btw miért vélted hogy hitvita lesz? mik a Propel ellen szóló érvek?
könnyű dolgokat lehet könnyen csinálni, bonyolultakat csak bonyolultan…
szvsz nyilván nem fogja nekem semmi legenerálni user interfészről vagy valami könnyű paraméterfájlból a 30 soros, mindenféle feltétel szerint dinamikusan összeálló sql queryjeimet
de a Propelt meg fogom nézni amint lehet, csak még mindig nem megy az oldaluk (lol?)
symfonyt nézem, thx… update szimpi a cucc…
btw miért vélted hogy hitvita lesz? mik a Propel ellen szóló érvek?
nrg, Smarty nem is jött be végül. Az jeleníti meg a postokat, a kommenteket, a lapozólistákat (ld. pl. üzenőfal), és a rövid postokat (archívum:
Elkezdtem egyébként template jellegű php functionöket csinálgatni (function tpl_*), amik csak a megjelenítésért felelnek, nem hívnak meg eljárásokat, nem nyúlnak a db-hez, szóval úgy viselkednek mint egy átlagos smarty template, csak éppen nem smartyban vannak és így gyorsak is, meg nem támaszkodnak a Smartyra (Aminél elég ciki ha pl. leállnak a fejlesztésével, na akkor mit csinál a sok smartys arc, hogy tér majd át a következő php-re, amit a régi smarty nem fog támogatni? Ugyanígy parázok egyébként a prototype.js miatt is )
Mivel egyelőre nincs a Propelnek honlapja… mi a különbség az meg a symfony között?
btw nrg, neked is javasolnám a kommentform alatti gyorsbejelentkezési lehetőséget
csak címeknézet), de ezek után máshol nem erőltettem, nem szerettem meg, nem látom semmivel se áttekinthetőbbnek mint egy szép áttekinthetően megalkotott php-t. Ugyanúgy tele van elágazásokkal stb (mert egy csomó apróságban el tud térni a bejegyzések meg kommentek kinézete, és szvsz a template-beli elágazásoknál semmivel se jobb ha csinálok 10 féle template-et ahol aztán egyesével írogathatom át mindet ha valami változik, mint a css előtti időkben). (CSS power btw, láthattad korábban hogy teljesen át tudom szabni a blog arcát CSS alapon, ha akarom.)
Elkezdtem egyébként template jellegű php functionöket csinálgatni (function tpl_*), amik csak a megjelenítésért felelnek, nem hívnak meg eljárásokat, nem nyúlnak a db-hez, szóval úgy viselkednek mint egy átlagos smarty template, csak éppen nem smartyban vannak és így gyorsak is, meg nem támaszkodnak a Smartyra
(Aminél elég ciki ha pl. leállnak a fejlesztésével, na akkor mit csinál a sok smartys arc, hogy tér majd át a következő php-re, amit a régi smarty nem fog támogatni? Ugyanígy parázok egyébként a prototype.js miatt is )Mivel egyelőre nincs a Propelnek honlapja… mi a különbség az meg a symfony között?
btw nrg, neked is javasolnám a kommentform alatti gyorsbejelentkezési lehetőséget
Haszprus, a Propel ellen az szól(hat)na, hogy ágyúval verébre sok esetben. Meg ott van mellette a Doctrine mint konkurens is, aztán lehet jókat vitázni, hogy Propel vagy Doctrine.
Haszprus, a Propel csak egy absztrakciós réteg az adatbázis fölött (object-relational mappernek hívják, gyakorlatilag többé-kevésbé transzparens módon felelteti meg az ojjektumaidat az adatbázistábláknak). A Symfony meg egy komplett Model-Controller-View architektúrájú webes keretrendszer, olyasmi, mint a Ruby on Rails, vagy a CakePHP.
Haszprus, igen, a Propelhez kell shell hozzáférés, amikor szinkronizálod a megadott sémafájlodat az adatbázisstruktúrával. De meg lehet kerülni, ha van phpMyAdmin-od és le tudod benne futtatni a Propel által generált SQL scriptet. Sőt, igazából hosszú távon egyszerűbb, ha az ember kézzel felveszi az új oszlopokat az adatbázisba is meg a schema. Xml-be is, és a Propelt kihagyja az adatbázisstruktúra piszkálgatásából, különben minden sémamódosításkor lehet törölni az összes rekordot. (Ez a Ruby on Rails-ben kicsit szebben volt megoldva, meg mintha a Doctrine is jobb megoldást alkalmazna). Nekem pl úgy szokott lenni, hogy a development környezetben (a saját gépemen) a Propelre bízom az adatbázisstruktúrát (a tesztadatbázist úgyis mindig szűzre töltöm újra), az éles rendszeren meg mySQLdiff-fel detektálom, hogy milyen változások voltak a legutóbbi szinkronizálás óta, és azt kézzel vezetem át.
ja, ha már Symfony, érdemes elolvasni ezt is: symfony Web PHP Framework » Askeet - symfony Advent Calendar - avagy hogyan építsünk fel egy trendi webkettes site-ot a nulláról Symfony-val.
Haszprus, a Propel csak egy absztrakciós réteg az adatbázis fölött (object-relational mappernek hívják, gyakorlatilag többé-kevésbé transzparens módon felelteti meg az ojjektumaidat az adatbázistábláknak). A Symfony meg egy komplett Model-Controller-View architektúrájú webes keretrendszer, olyasmi, mint a Ruby on Rails, vagy a CakePHP.
Haszprus, igen, a Propelhez kell shell hozzáférés, amikor szinkronizálod a megadott sémafájlodat az adatbázisstruktúrával. De meg lehet kerülni, ha van phpMyAdmin-od és le tudod benne futtatni a Propel által generált SQL scriptet. Sőt, igazából hosszú távon egyszerűbb, ha az ember kézzel felveszi az új oszlopokat az adatbázisba is meg a schema. Xml-be is, és a Propelt kihagyja az adatbázisstruktúra piszkálgatásából, különben minden sémamódosításkor lehet törölni az összes rekordot. (Ez a Ruby on Rails-ben kicsit szebben volt megoldva, meg mintha a Doctrine is jobb megoldást alkalmazna). Nekem pl úgy szokott lenni, hogy a development környezetben (a saját gépemen) a Propelre bízom az adatbázisstruktúrát (a tesztadatbázist úgyis mindig szűzre töltöm újra), az éles rendszeren meg mySQLdiff-fel detektálom, hogy milyen változások voltak a legutóbbi szinkronizálás óta, és azt kézzel vezetem át.
ja, ha már Symfony, érdemes elolvasni ezt is: symfony Web PHP Framework » Askeet - symfony Advent Calendar - avagy hogyan építsünk fel egy trendi webkettes site-ot a nulláról Symfony-val.
Tárolt eljárásokról már hallottatok, ti péhápés fírgek? sql logicot a datalayerbe…
sql logicot a datalayerbe…
geezer, köszi az említést. Hallottunk, de tárolt eljárásokat a mysql csak az 5-ös verzió óta tudja, szóval még kevéssé elterjedt a használatuk/ismeretük. De érdekelnének az érveid a használata mellett. (Jobban kifejtve, mint hogy
Mi van ha nekem a php előállít egy 30 soros sql queryt egy rakás bemenő paraméter alapján? Meg tudom ezt csinálni tárolt eljárással? Mit profitálok belőle?
oda való.)
Mi van ha nekem a php előállít egy 30 soros sql queryt egy rakás bemenő paraméter alapján? Meg tudom ezt csinálni tárolt eljárással? Mit profitálok belőle?
Haszprus, sql server / oracle / db2, illetve ahogy mondtad, a mysql 5.x is tudja a tarolt eljarasokat. nyilvanvalo, hogy egy konkatenált string parseolása és átküldése az sql motornak időben jóval több, mint egy sql szerveren lévő kvázi objektum felparaméterezése. Arról a tényről már nem is beszélve, hogy például joinok, unionok optimalizalasara-kezelesere, view-k bekotesere, indexek optimalizalasara lekerdezesenkent csak igy van igazan lehetoseg (az sql server pl. elore letre tudja hozni es temptablakban gyujteni a sokat hasznalt adatokat, ergo cache-elni tudja a bulk adatokat, amit mondjuk masodpercenkent 5-7-szer lekerdeznek a site-on; nem kell minden alkalommal a raw datafile-hoz mászkálnia), nameg h nem egy programozastechnikai megoldastol, hanem az sql logikától függ a query sebessége… (az sql inject támadásokról már nem is beszélve…)
