php keretrendszerek i.

Talán csak magamból indulok ki, de azt hiszem a nagyon sok ember úgy találkozik először a PHP nyelvvel, hogy rájön, a HTML nem elégíti ki minden igényét. Ilyenkor elkezd olvasgatni és rájön, hogy a tárhely, ahol az oldala van, támogatja a PHP-t. Utánaolvas, hogy az mi fán is terem. Feltelepíti a PHP-t, esetleg a MySQL-t is és elkezdi próbálgatni, amíg meg nem oldja az adott kérdést. Az ember szépen lassan elkezd komolyabb és komolyabb feladatokat megoldani, míg egészen rá nem érez az ízére és úgy nem érzi, hogy ő már bármit meg tud oldani. Az én esetemben, körülbelül itt tartottam, amikor először vállaltam el pénzért egy weboldal elkészítését a designért felelős barátommal karöltve, és szerintem nem voltam ezzel egyedül.

Az ember nagy megelégedésében aztán egyre összetettebb feladatokat kap, szép lassan elkezdi újrahasznosítani saját kódjait és ekkor rájön, hogy a PHP egy objektumorientált nyelv, lehet benne használható osztályokat is létrehozni. (Lehet, hogy ez ma már sokkal evidensebb, mint 5-6 éve volt, a PHP négyes verziója még elég kezdetleges objektum-modellt használt.)

Jobb esetben az ember előbb-utóbb találkozik néhány érdekes kódrészlettel vagy egy-egy jó cikkel, amik megragadják a fantáziáját, hogy elkezdje mások kódját olvasgatni esetleg fel is használni ezt-azt. Rosszabb esetben rögtön feltelepít egy Joomlát vagy Drupált és megállapítja, hogy soha többet nem kell programoznia, mert már minden problémájára van elérhető és letölthető megoldás. Félreértés ne essék, nem szeretnék belemenni, hogy ezek a tartalomkezelő rendszerek jók-e vagy rosszak, csak abban vagyok biztos, hogy nem nyújtanak mindenre megoldást.

Én a jobbik esethez sorolnám magam, először talán egy PHPMailer nevű levélküldő könyvtárat kezdtem használni, később a phpclasses.org-ról is gyűjtöttem be kódokat, majd PEAR könyvtár elemeit is beépítettem itt-ott. Minden nagyszerűen működött, de az egész rendszer egy nagy, feldarabolt spagetti volt és hát a sok különbözőképpen kódolt könyvtár összességében nem volt egy szép látvány.

2007 nyarán aztán aztán minden megváltozott. Találkoztam életem első komplett keretrendszerével, a CodeIgniter-rel. Azt hiszem, amikor láttam a videót, hogy hogyan lehet vele 20 perc alatt egy kezdetleges blogot elkészíteni, akkor már valahol el voltam veszve, de azért biztos, ami biztos körülnéztem az elérhető keretrendszerek között. Úgy emlékszem, akkoriban 4 rendszer volt ami egyáltalán felmerült: a már említett CodeIgniter, a Symfony, a Zend Framework és CakePHP. Azt tudom, hogy a Symfony és a Zend Framework rögtön kiestek, mert nem támogatták a php4-et és akkoriban még elég sok hazai szerveren az futott. A CakePHP talán támogatta a php4-et, de nem nagyon dicsérték a dokumentációját, ellenben a CodeIgniter már akkoriban is hasonlóan jól dokumentált volt, mint ma. Szóval ezek után könnyű volt a választás, és mit mondjak fantasztikus volt, hogy szinte mindenre egységes és jól dokumentált megoldást kínált, amire szükségem volt, ráadásul még parancssori telepítő sem kellett hozzá, mint a PEAR-hez, (meg amúgy a Zend Framework-höz és Symfony-hoz) csak kicsomagoltam/feltöltöttem és működött. Ráadásul az akkor nekem még teljesen új MVC szerkezeti minta is magával ragadott. Időközben a CodeIgniter igencsak népszerű lett, ennek köszönhetően mai napig jó néhány projektem ezt a keretrendszert használja.

A CodeIgnitert én egy nagyon jó keretrendszernek tartom, de mint az előző szakasz múlt idejű környezetéből talán kitűnt, ma már nem sorolnám a kedvenceim közé. Az viszont tény kérdés, hogy a programozó sémákkal csak újonnan ismerkedőknek egy nagyszerű választás, mert jól dokumentált, könnyű hozzá segítséget találni és sokat tanulhat belőle bárki, akinek az MVC netán nem mond semmit. Hogy miért tartok manapság más keretrendszereket többre, az kiderül a sorozat folytatásából.

Címkék: php keretrendszerek

A bejegyzés trackback címe:

https://szajtbilder.blog.hu/api/trackback/id/tr671407318

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.