Megjelent a PHPStorm 4.
PHP 5.4 language features support Code coverage for PHPUnit Drupal coding style support ECMAScript Harmony support PHP code sniffer integration New PHP code inspections Smarter JavaScript completion
» Archívum: megjelenített kategóriák
Jelöld be, hogy mely kategóriákat akarod olvasni, vagy ha csak egyet: kattints a nevére.
34 megfelelő bejegyzés.
Things I like:
- Traits (big like)
- $myArray = [];
- $firstElement = getElements()[0]; // array dereferencing
- (new MyObject)->sayHi(); // class member access on instantiation
(Of course there are other things too.)
+1 lol from the changelog:
<?= is now always available, regardless of the short_open_tag php.ini option.How hard they were fighting against short open tags… I think this is similar to HTML 5 where you don't have to close your tags despite the whole community was forcing strict XHTML for years
because it's better.
Vettem egy phpstorm licenszet. 
Jóság.
Nu, Gábortól megint tanultam egy kis Zend Frameworköt, de igazából az eddigi rátekintéseim eddig mindig hiányérzettel zárultak, nem igazán érzem hogy ez miért jó, valahogy a Symfony úgy jobban egyben van…
Ott voltunk ezen is Orcával és PAStheLoDdal.
Szubjektív véleményem: nagyon hardcore advanced cuccot vártam, ehhez képest kicsit bme-sre sikerült, legalábbis az első egy-két előadást a magam részéről túl lassúnak ill. bealvósnak éreztem, a verziókezelős és a scrumos teljesen triviális dolgokról beszélt (szerintem elhibázott tematika). Volt viszont nagyon kellemes meglepetés is, éspedig a PHP Security, ami nagyon élvezetes volt (erről a témakörről még valszeg többször ennyit szívesen hallgatnék), illetve a HTML5 bemutató, ami viszonylag meglepő módon még mindig tudott egy csomó újdonsággal szolgálni a HTML 5 konferencia után is.
Amik voltak:
- Multiplatform mobil fejlesztések (Dr. Forstner Bertalan)
- Hogyan optimalizáljunk C/C++ kódokat! - Esettanulmány (Illés Márton)
- Verziókövető rendszerek alkalmazása fejlesztési projektekben (Gyöngyösi Péter)
- Webműves Kelemen tanácsai, avagy mi kell a PHP falába? (Varga-Perke Bálint)
- Hogy kerül a csizma az asztalra? HTML 5, CSS3, JavaScript (Magyar Attila és Györkő Péter)
- AGILIS / SCRUM fejlesztés (Bakonyi András)
Gondoltam eljátszom a twig template kezelővel, ami erősen a symfony 2-höz és fabien potencierhez kötődik, tekintve hogy ő az atyja mindkettőnek és ez a symfony 2 default templating engine-je.
A telepítés igen könnyű pearrel:
(Egyébként nem muszáj pearrel telepíteni.)
Hozzuk létre a kis hello world sablonunkat:
Mentsük el templates/hello.tpl-ként.
A template-et adattal kiszolgáló php a következőképp fog kinézni:
Ez ennyiből már működik is. A twig lehetőségeibe mélyebben nem megyek bele, aki használt már bármilyen template engine-t, annak sok újat nem fog mutatni.
Nemrég kezdtem el picit ismerkedni a CakePHP MVC frameworkkel, igazából egyáltalán nem célom ismertetni a képességeit vagy bármi hasonló, mindössze megragadnék egy dolgot ami megtetszett. A dolog nem újdonság, mint ahogy a CakePHP sem az, sőt.
Induljunk ki onnan, hogy már megvannak a tábláid a db-ben, amit még korábban létrehoztál, hogy Cake-et kezdtél volna használni. Nem feltétlen tipikus felállás, tudom.
Megmondod az érintett kontrollerednek egy tagváltozóban, hogy
$uses = array('Restaurant', 'Place');
, aminek a hatására a kontroller a Restaurant és a Place nevű modelleket példányosítani fogja és hozzárendeli a $this->restaurant ill $this->place változókhoz a Controlleren belül.
Amennyiben a megfelelő könyvtárban nincs Restaurant ill. Place modell (az ezekhez tartozó php fájl és osztály), akkor megnézi, hogy a db-ben létezik-e restaurant ill. place nevű tábla, és ha igen, akkor ezekből generál on-the-fly egy-egy modellt.
Lekérdezi tehát a db-ből a táblák oszlopait, és rögtön használhatod is valamennyi tagfüggvényt rájuk, mint pl. megkeresheted az 5-ös id-jű éttermet:
$this->restaurant->findById(5);
Nem csak id alapján kereshetsz, hanem bármi egyéb oszlopnév alapján is természetesen, tehát pl. $this->restaurant->findByType('lacikonyha') hívás is teljesen valid.
Nekem ebben az tetszik mondjuk egy symfonyval szemben, hogy a modellt nem kell generálnod, létrehozza neked on-the-fly, aminek különösképp ott érzem előnyét, ha valami változik az adatbázis sémában (nevezetesen nem kell újragenerálgatni a modelleket, ami marha kényelmes dolog). Nyilván hátránya, hogy egy IDE sem fogja kitalálni neked, hogy vajon milyen tagfüggvényeket hívhatsz meg az ilyen módon használt modelljeiden.
| Haszprus, 2011.03.21. 20:29:25 | kúúúúúúúúúrvajó |
Brutál, nagyon impresszív 
Komoly lelkesedéssel díjazom.
Múlt héten a CodeIgniter Framework megismerése volt terítéken, ma pedig kutattam egy kicsit, amit a napokban még folytatni fogok full text search témában, érintve, de nem korlátozódva a következőkre:
- Zend Search Lucene
- Sphinx
- Xapian
Implementáltam egy a Zend Frameworkben található Zend Search Lucene-t használó megoldást (abszolút experimentális jelleggel, index buildelés és lekérdezés) CakePHP Framework alá beültetve.
Megjelenítési réteghez úgy tűnik 960 Grid System lesz a választottunk.
Itthon eközben symfony frameworköt nyomok továbbra is Doctrine ORM-mel.
Izgi mind.
SEO power.
Tegnap ledemóztam Zolinak a symfony - doctrine duó YAML alapú (schema.yml) adatbázis- és modellgenerálási képességeit, illetve hogy miként lehet ebből formokat és komplett modulokat legenerálni, valamint miként lehet testreszabni ezeket. Ahogy láttam, impresszív volt. Mondjuk szerintem is az.
A következő webalkalmazásomhoz symfonyt választottam keretrendszernek.
Lesz ilyen a PHP-ben, kis apróság, de valami amire régóta vágyom
Irgalmatlan tempóban készül a Haszprus PHP Framework…
(Önlabra lesz, egyelőre van benne fasza formgenerálás, mvc (mégpedig kicsit smarty-style), minden ami kell… Nem használ fel korábbi cuccaimat, written from scratch, inspired by symfony and TRES.)
(Munkáltatóm figyelmébe: a cuccot itthon készítem ingyé nem kevés időben (pl. most 4:50-kor végzek vele és kb. tegnap 18 óta nyomom, az hány elszámolatlan óra is egy nap alatt?) és maximálisan fel fogom használni a munkámban. Jól.)
A cégnél az első feladatom egy olyan script optimalizálása volt, amely 12-től 30 vagy akár még több MB-ig terjedő XML állományok alapján hajt végre nagyságrendileg 100-500e egymással összefüggő SQL insertet (értsd: mély és széles xml-fa).
Az eredeti progi egy 30 megás XML-lel kb. 2 perc 40 másodpercnyi munkát adott az apache.exe-nek (ennyit foglalt a prociból tehát az apache), miközben a memóriahasználat az alapjáratú 27 MB-ról felment 558 MB-ra. A program teljes futási ideje 383 másodperc volt.
Elég sok időt eltöltöttem azzal, hogy egyrészt a program logikáját megértsem, másrészt utána nézzek, hogy vajon van-e valami hatékonyabb XML parser. Miután nem találtam a használt megoldásnál jobbat (tekintve hogy az se a teljes dokumentumfát tárolta a memóriában), már majdnem ott kötöttem ki, hogy ezt bizony nem lehet (vagy én nem tudom) optimalizálni (bár persze kételkedtem), ehelyett kicsit kitesztelgettem, hogy hogyan is működik a php-ben a változók és objektumok megsemmisítése (ld. __destruct), és a megfelelő stratégiai helyen mért csapás eredményeként a program most nem növeli az apache alapjáratú memóriafoglalását egy megával sem (Érdekes módon az unset nem segített.)
Azaz az én verzióm a 30 megás XML-lel ugyanúgy 2 perc 40 másodpercig tekeri az apache.exe-t, azonban összesen csak 358 másodpercig fut (fél perc nyeremény itt, miközben sebességre még nem is optimalizáltam), és ami a lényeg, hogy 27-ről nem 558 MB-ra nyomja fel az apache memóriahasználatát, hanem mindössze 29-re. Nem kell mondani, hogy ez mennyire előnyös egy olyan környezetben, ahol más dolgok is futnak (ti. ez egy webszerver).
Amikor nekiálltam a dolognak, egy nagyságrendi változást akartam volna elérni, aztán ahogy beleástam magam, megelégedtem volna akár egy memóriafelezéssel is, végül már majdnem teljesen feladtam, de arra álmomban sem gondoltam, hogy sikerül a memóriahasználatot úgy ahogy van megszűntetni Ettől igen jó kedvem lett
Rulz.
Ma az adminfelületen a logok közé benézve a következő ablak villant fel:
Gondoltam biztos valamelyik firefox extension bugzik. De nem. Valaki egy lapletöltésnél user agentnek azt bírta megadni, hogy
<script>alert(1)</script>
Ofkorsz a user agentek biztonságosan kerülnek az adatbázisba egy $db->safe_string() konverzión keresztül, mert nehogymár valaki ott kezdjen sql-t injektálni, de arra még nem gondoltam, hogy valaki html-t vagy js-t fog becsempészni így az oldalra. Trükkös.
Kvízjáték: mit jelent az alábbi PHP hibaüzenet és hogyan lehet kiváltani?
Parse error: syntax error, unexpected T_DEC, expecting T_PAAMAYIM_NEKUDOTAYIM
Google nem ér.
Először arra gondoltam, létrehozok egy bejegyzést a Propelnek, de kezdetnek inkább csak egy ilyen általánosat… ki milyen külső cuccokat használ php alapú webfejlesztéshez? Nem projektspecifikus cuccokra gondolok (pl. free webgaléria, stb), hanem általánosan használható, beépíthető dolgokra (mint pl. adatbáziskezelő réteg, template rendszer).
Én elsősorban a bloggal szórakoztatom magam, és itt nem az a cél hogy gyorsan fejlődjenek a dolgok, hanem hogy magam fejlesszek ki mindent. Hobbiból. Ennek megfelelően eddig nem is nagyon vettem be külső fejlesztéseket a projektbe, egy éve bekerült egy Smarty (ami nem jött be végülis), és most nemrég a prototype.js, igaz ez nem php, hanem js/ajax. Na ilyesmikre gondoltam. Nyomassad, miket használsz, mire jó, stb.
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.
Gyakran előjövő probléma, hogy a látogatónak szeretnénk megadni a lehetőséget a táblázataink rendezhetőségére. Erre nyújt megoldást a draw_table_from_array függvényem, amelyet egy munkám során hoztam létre. Nemcsak egyforma (teljesen css-ből formázott) megjelenést nyújt a táblázatoknak, de erőfeszítés nélkül lehetővé teszi, hogy bármely oszlop szerint rendezzük őket. Egy-egy tábla előállításához a kód pusztán ennyi, az sql lekérdezéstől a felhasználó által rendezhető tábla megjelenítéséig:
Az eredmény:
A dolog működése élőben is kipróbálható.
Az a blogra pakolt lightweight galéria még mindig lightweight de egyre durvább lesz… Most már tud onthefly, oldalújratöltés nélkül album nézetet is. Ilyet:
Nomeg billentyűzetről jobbra-balra lapozgatni, ha valaki nem lenne naprakész a kommentekből.
Az a helyzet hogy teljesen lightweight módon megoldottam egy atombrutál full-featured highly advanced client-side cached galériát, amihez se külön db nem kell, se adminfelület, se semmi, full automatikusan onthefly ráépül a bejegyzésekre. 37 sor php (!), 60 sor html, 121+64 sor javascript (és 139 sor css). Az egész cucc 10 KB. Csak viszonyítás képpen a Haszprus Private Gallery 110 KB, amiből az adminfelület 26 KB - ez utóbbi ugye itt nem is kell.
Ki lehet próbálni (akárhol az ablakban katt, előjön az album nézet), ráadásul egy olyan képgalérián, ami egy egyelőre nem is publikált bejegyzésből táplálkozik (így a bejegyzésre mutató link nem fog működni (számotokra)… ez nem bug).
Örülnék, ha adnátok valami feedbacket, hogy mégis milyen lett.
ie-ben az album nézet nem jelenik meg de pillanatnyilag lesz*rom. a jó hír hogy valszeg ez elég könnyen javítható, csak rá kéne nézni hogy pontosan mi a hézag.
Update szep. 03. 01:11: na megy.
Íme az überblog legújabb, highly advanced feautre-e, a képlapozó.
Semmiféle adatbázis-módosítás nem kellett hozzá, egyszerűen kideríti hogy a képet melyik bejegyzésből linkelték (mégpedig erőforráskímélően, de még lehet rajta fejleszteni), megnézi hogy a bejegyzésben mely képek veszik körbe őt (azaz melyik kép van előtte és utána (ezen is lehet gyorsítani)), belinkeli azokat, sőt belinkeli magát a bejegyzést is, így megkönnyítvén a navigációt. Ha jók lesztek akkor előbb-utóbb talán megcsinálom javascriptesen széjjelcache-elve is, mint a private galleryt, 0 sec késleltetéssel, lapújratöltés nélkülire.
Ha az egeret az előző/következő link fölé viszed, kapsz egy kis thumbnailt is arról, hogy mégis milyen képre jutsz a linkre kattintva. Mindez nem feltétlen lóg rá egyébként a képre, alapvetően 1280*1024-re illetve afölé van kitalálva mindez, ahol rálógás nincs, sőt az egész kép kifér.
Azt kell mondjam, ez kurvajó lett. Elégedetten dőlök hátra. Vegyük észre hogy ez egy lightweight galleryt akaszt a blogra, amely így 2.9-es stádiumba léphet.
A dolog működését megtekintheted például itt, vagy nyilván bármelyik bejegyzésnél, ahol van mik között lapozgatni.
Update aug. 23. 18:18: lett 0 sec delayes lapozás, cache-eléssel, oldalújratöltés nélkül. Tudnivalók:
- Első képletöltéskor nincs cache-elés, megelőzendő a fölösleges cache-elést. Ez leghasznosabb olyankor, amikor a júzer külön fülekre megnyitogatja a képeket egyesével, ilyenkor a cache-rendszer nem okoz fölösleges többletforgalmat.
- Abba az irányba cache-el, amerre a néző lapoz.
Ki akarjuk bányászni egy időjárásjelentő oldalról hogy hány fok van, hány fok lesz, stb.
/**
* $source szovegbol kibanyassza a
* $id id-ju div erteket es
* $type tipusra castolva visszaadja
*/
function get_value_by_div_id($source, $id, $type) {
$matches = array();
$regexp = "<div.*?id\=\"$id\".*?>(.*?)<\/div>";
preg_match("/$regexp/s", $source, $matches);
settype($matches[1], $type);
return $matches[1];
}
Így pl.
A kimeneten:
Hőmérséklet: 26 fok (érzésre 28 fok).
Adottak a hét napjai (H, K, Sze, Cs, P, Szo, V), valamint egy adattábla, benne minden rekordhoz két nap. Számítsuk ki, hogy a két nap között hány-hány nap van. (Pl. hétfőtől péntekig, majd péntektől hétfőig eltelő napok száma.)
A nem javasolt
megoldás: veszünk egy külső switch case szerkezetet, amelynél az eseteket az első napok szerint alakítjuk. Hét eset. Majd ezek mindegyikében egy újabb switch case, aszerint, hogy a második nap mi. 72 = 49 eset.
switch ($elsonap) {
case 'H':
switch ($masodiknap)
case 'K': echo '1 ill 6 nap van koztuk'; break;
case 'Sze': echo '2 ill 5 nap van koztuk'; break;
...
case 'K':
switch ($masodiknap)
case 'H': echo '6 ill 1 nap van koztuk'; break;
case 'Sze': echo '1 ill 6 nap van koztuk'; break;
...
...
}
Ez tényleg nem túl jó, egyrészt a 49 elágazás miatt, másrészt mert ha mondjuk angolul is ki akarjuk írni az eredményeket akkor már 2*49 elágazásunk lesz. Egy fokkal jobb megoldás, ha a napokhoz számokat társítunk, majd ezeket kivonogatjuk egymásból mod 7:
switch ($nap) {
case 'H': $n = 1;
case 'K': $n = 2;
...
}
Csakhogy ezt a társítást lehet switch case nélkül is, és ezúttal egy végleges, immáron meglehetősen rövid és komplett megoldás:
function eltelt_napok($napchar1, $napchar2) {
$napok = array('H' => 1, 'K' => 2, 'Sze' => 3, ...);
$nap1 = $napok[$napchar1];
$nap2 = $napok[$napchar2];
$diff1 = mod(max($nap1, $nap2) - min($nap1, $nap2), 7);
$diff2 = mod(min($nap1, $nap2) - max($nap1, $nap2), 7);
return array($diff1, $diff2);
}
A mod fv természetesen megvalósítandó vmi tetszőleges módon. Lehet hogy a php-ben van is rá vmi, én hirtelen nem találtam, úgyhogy:
function mod($n, $q) {
$n %= $q;
if ($n < 0)
$n += $q;
return $n;
}
Update 17:13: sőt a mod fv is elhagyható, ld. tbela kommentje.
A cucc naponként egy text/xml adatbázist
dolgoz fel, amiben el vannak mentve a spamküldés részletes körülményei. Ebből a logolásból egyébként sok érdekes tapasztalatra tehetünk szert, így pl. az alábbiakra:
- A kommenteket (egy részüket legalábbis) egyértelműen valami spambot (szoftver) hagyja, mivel előfordulnak a
kitöltött
mezők között olyanok is, amik már rég más névre hallgatnak (így pl. az anon_nick neve régóta vendeg_nev, mégis jönnek spamek kitöltött anon_nick mezővel - érdemes hát betenni a szűrési feltételek közé azt, hogy amennyiben van anon_nick a $_REQUEST-ben, akkor nyilvánvalóan spammel van dolgunk). - Javascriptet a legritkább esetben futtatják le, ez egyrészt következik a fentiből, másrészt a logban látható, hogy a javascript által létrehozott mezők nincsenek kitöltve.
- Értelmi képességekkel nem rendelkeznek, a noscript esetén megjelenő szorzást nem végzik el, az eredmény helyére gyakorta egyéb szöveget vagy reklámurl-t pakolnak.
- Gyakran üres kommentet próbálnak meg beküldeni.
- Vannak annyira primitív botok akik a
pw
nevű input mezőbe is url-t próbálnak beírni aztán csodálkoznak hogy nem jelenik meg a hozzászólásuk…
Na szóval itten gondolkodtam hogy miként lehetne backupolni a bejegyzéseket, de csak szépen finoman, abban bízva, hogy remélhetőleg sosem lesz a backupra szükség.
Először arra gondoltam, egy fájlba szépen kiírom a bejegyzések szöveg mezőjét beküldéskor, oszt jóvan.
Második nekifutásra azonban készítettem egy functiont ami xml-be kiírja a bejegyzéshez kapcsolódó összes adatot, de nemcsak itt használható, hanem bárhol, rekurzívan egy akár többszíntü arrayt kinyom egy gyönyörüen formázott plain text alapú xml fájlba.
/**
* rekurzÃvan xml-be fejt egy akár többszÃntü array-t
*/
function arrayToXML($array, $level = 0) {
$return = "";
$indent = "";
for ($l = 0; $l < $level; $l++)
$indent .= "\t";
foreach ($array as $key => $val) {
$return .= "\r\n";
$return .= $indent;
if (is_array($val))
$val = arrayToXML($val, $level+1) . "\r\n" . $indent;
$return .= "<$key>$val</$key>";
}
return $return;
}
Majd pedig egy elegáns húzással:
$backupfile = new File(....); $content = arrayToXML($_POST, 1); $content = "\r\n<post>$content\r\n</post>"; $backupfile->appendContent($content);
Az eredmény egy konkrét példája:
<post>
<b_id>2439</b_id>
<szoveg><p>Müködése a kommentben.</p></szoveg>
<b_cim>Quoter function</b_cim>
<submit>Ment publikusan</submit>
<gall_categ>0</gall_categ>
<gall_entry_title></gall_entry_title>
<b_commentable>on</b_commentable>
<categ>
<1>on</1>
</categ>
<b_privszoveg></b_privszoveg>
</post>
Nos, 404-es errordoc esetén az apache nem adja át az url-paramétereket a php scriptnek (azaz nem jön létre se a $_REQUEST, se a $_POST, se a $_GET tömb), ez értelemszerüen problémákat okoz a meglévő scriptekben.
A $_GET pótlása nem túl körülményes. (Illetve én a $_REQUEST-be írom, mert azt használom.)
$tmp_request_parameters = explode('&', $URI);
foreach ($tmp_request_parameters as $trp) {
$t = explode('=', $trp, 2);
$_REQUEST[$t[0]] = $t[1];
}
A $_POST-ra egyelőre nincs ötletem.
Ami pedig még jó lenne, hogy pl. egy form az elküldendő adatait az url-hez szépen /.../ formában írogassa hozzá. Valszeg előbb-utóbb erre is sort kerítek, a megoldás gondolom valami script lesz, ami a form adataiból egy window.location változtatást visz véghez submit helyett.
- Szép URL-ek, második felvonás - 2006.04.12.
Jó, persze, a wiw meghívókérés az nem spam valójában, de ez most tökmindegy.
Tekintve, hogy a blogon pillanatnyilag összesen csak egy különösen spamelt bejegyzés van (mégpedig az iwiwről szóló), ezért nem építek semmi adatbázis-cuccot a dolog mögé, egyszerüen forráskódba belegányolom. Lehet hogy gány, de így gyors, így egyszerü, és tekintve hogy ez a lista évente bővül egy bejegyzéssel, ezért könnyen karbantartható is.
/* spamszavak száma: spamfactor */
$spamwords = array(<q>http://</q>, <q>great</q>, [...]);
$spamfactor = 0;
foreach ($spamwords as $spamword)
if (strpos($rq['szoveg'], $spamword) !== false)
$spamfactor++;
/**
* különösen spamelt bejegyzések esetén nagyobb a valószÃnüsége,
* hogy spammel van dolgunk... */
$spammed_posts = array(2226);
if ($spamfactor > 0 && in_array($rq['bejegyzes_id'], $spammed_posts))
$spamfactor++;
Majd ha marha sok időm lesz, lehet, hogy átültetem db alapúra ezt a spam, meg badword, meg spammed_posts témát, de ugye akkor kell hozzájuk kezelőfelületet írni és az rögtön rengeteg vesződséggel jár, és a karbantartás sem egyszerübb végülis mint forráskódba néhanapján belehegeszteni egy-egy új szürt szót vagy id-t.
Na nyilván lehetett erre számítani, de azért említsük meg, hogy a php laborházim 14+45 = 59 pont lett, ez a maximum amit el lehet érni, és egyébként 32-től már amúgy is ötös (Igen, 32-től!) Mondjuk azt nem vágom, hogy hova tűnt a valid xhtml-ért, error_reporting e_all-ért és register_globals off-ért járó +4 (vagy +6?) pontom, valszeg a javító úgy volt vele hogy nincs rá nagy szükségem
Gratulálok. Talán a legprofibb megoldás, amit eddig láttam. Látszik, hogy volt már tapasztalatod a témában. [...]
Na jó, mit verjem magam, tényleg elég sokat foglalkozom a témával. Akik esetleg ezt szeretnék az orrom alá dörgölni egy hozzászólás formájában, hagyják ki, tisztában vagyok vele.
Meg kell mondjam, nagyon emberségesnek tartom az Adatb laborházik javítását, nem volt még olyan házi amihez ne gratulált volna a javító. Persze lehet hogy ez az ő egyéni érdeme. Mindenesetre respect & thx, jólesik.
Ha le akarod mérni, tedd be a lapod elejére ezt:
ob_start();
function microtime_float() {
list($usec, $sec) = explode(' ', microtime());
return ((float)$usec + (float)$sec);
}
$time_start = microtime_float();
A végére pedig ezt:
$time_end = microtime_float(); $time = $time_end - $time_start; echo 'Lapgenerálás: ' . $time . 'mp'; ob_end_flush();
Ez a kód azért jó, mert az ob_startnak köszönhetően nem számítja bele az időbe a lap letöltődését. Enélkül amit kapnál, az függne a szabad sávszélességedtől. És az nem lenne jó.
(A kód nagyrészt innen származik, de a dolog értelmét szerintem az ob_start - ob_end_flush kiegészítés adja, anélkül a script helyett szinte a saját sávszélességedet méred.)
A komment.php-ben a kommenteket immáron OO módon szolgálja ki a blog. Ami emögött van:
class Container {
var $elements
var $pointer
var $length
function Container()
function addElement($element)
function length()
function getElement($i)
function getLastElement()
function getFirstElement()
function getNextElement()
function removeElement()
function setPointer($i)
function forAll($function)
}
class Comments extends Container {
var $picOfUser
function Comments()
function getCommentsByPostId($post_id, $order, $from, $to)
function showHTML()
}
class Comment {
var $row
function Comment($row)
function showHTML()
}
A hajnal óta elkövetett változtatásokat jelöltem. Logikusan a showHTML mellé kerülni fog egy-egy showRSS function.
ha igazán OO akarsz lenni, akkor egy komment egy class, aztán csinálsz egy generikus container vagy lista class-t, és származtatsz belőle egy olyan class-t, amely csak kommenteket tartalmazhat
Tamás - Obi kérdés
Megvalósítva mindhárom (Preview Release 1) A megjelenítést még nem írtam meg szépre, de ott már csak néhány változót kell lecserélni. Ami eddig kész:
class Container {
var $elements
var $pointer
var $length
function Container()
function addElement($element)
function length()
function getElement($i)
function getNextElement()
function removeElement()
function setPointer($i)
}
class Comments extends Container {
function Comments()
function getCommentsByPostId($post_id)
function show()
}
class Comment {
var $row
function Comment($row)
function show()
}
Ez utóbbi show() még tiszta bug, értelemszerűen.
Ha a kommentbe írtok egy olyat, hogy pl.
#10: hogy érted ezt?
Akkor, a #10-et automatikusan linkelni fogja a 10-es kommentre. Sőt, onnan egy újabb linkkel pedig visszatérhettek oda, amelyik kommenttől jöttetek. További részletek a képre kattintva, vagy a hozzászólások során megtapasztalva. (A dolog visszamenőlegesen is műxik a blog kezdete óta érkezett összes kommentre.)
A dolog műxik IE6, Firefox 1.5, Opera 8.5 alatt, többit nemtom, de talán nem is érdekes.
