Ebben a sorozatban szeretném végigvezetni a kedves olvasókat egy webfejlesztést támogató keretrendszer tervezésében és implementálásában. A cél nem a világ eddigi legjobb, legszebb, legelegánsabb és leggyorsabb keretrendszerének a létrehozása, hanem az elvek és minták bemutatása, amelyeket én praktikusnak vagy hasznosnak találtam. Reményeim szerint a sorozat végeztével azon túl, hogy egy működő, valós fejlesztésben is felhasználható keretrendszerhez jutunk, megismerkedünk a koncepciókkal is, amelyek a webfejlesztők életét könnyebbé (vagy éppen ellenkezőleg, gyötrelemmé) teszik.

Ez a sorozat egyrészt nekem is nagy kihívás, hiszen egy ilyen terjedelmű sorozat rengeteg időt és figyelmet követel, ezért kérném a megértéseteket. Igyekszem legalább havonta, de ha időm engedi gyakrabban újabb részekkel jelentkezni. Másrészt pedig azért hatalmas kihívás, mert ilyen jellegű munkával én még nem találkoztam, legalábbis nem ilyen mélységűvel. Mégis belevágok, mert már sokan kérték, hogy a tapasztalataimat megosszam valamilyen formában és akkor ha lúd, hát legyen kövér. Tűzzünk ki egy derekas célt - gondoltam magamban. Hát akkor vágjunk is bele, ne szaporítsuk a szót!

 Mint minden a hello_world-nél komolyabb alkalmazást, egy ilyen keretrendszert is a tervezéssel kell kezdenünk. Most adjunk magunknak szabadságot, felejtsük el a nyelvet, amelyben fejleszteni kívánunk, felejtsük el hogy véges erőforrásaink vannak, felejtsünk el mindent, ami megkötné a kezünket és szárnyaljunk egy kicsit szabadon:

Mi a célunk a keretrendszerrel?

1. Először is szeretnénk ha a keretrendszer használható lenne. Ez alatt azt értem, hogy az olyan koncepciók, ötletek, amelyek ellehetetlenítik, hogy valamilyen a webes fejlesztéssel kapcsolatos feladatot megoldjunk, automatikusan a kukába kerülnek. Egy keretrendszernek elég általánosnak kell lennie ahhoz, hogy a megcélzott terület összes problémáját ki lehessen vitelezni a segítségével.

   Később persze kompromisszumokat fogunk kötni, bizonyos feladatok könnyebben megoldhatóak lesznek vele, mint mások. Aki pedig azt mondja nektek, hogy ő ismer vagy ír(t) olyan megoldást, amely univerzális, tehát minden feladat ugyan olyan bonyolultsággal oldható meg, akkor nyugodtan nevessétek ki. Még a CPU-nk bytekódja (vagy éppen az Assembly) sem egyformán kényelmetlen minden feladatra.

2. Másodszor szeretnénk, ha könnyen megtanulható lenne. Feltételezem mindenki találkozott már olyan alkalmazással, keretrendszerrel, amely szép, okos és még gyors is, de egy rémálom megtanulni. Ez persze a használhatóságra is kihatással van. Lehet egy megoldás használhatatlan az által is hogy képtelenség megtanulni, ergo érdemben használni.
    
3. Harmadszor szeretnénk, hogy a keretrendszer a rutinfeladatokat vegye le a vállunkról amennyire csak lehetséges, ha nem lehetséges könnyítse meg azok kivitelezését. Ezen túl a nem rutinfeladatok is könnyebben megvalósíthatóak kell legyenek, hogy kitűnjünk egyáltalán a sokszínü keretrendszer-palettából. Végülis minden feladatban van egy kis (vagy sok) egyedi vonás, különben nem programoznánk, hanem szenet lapátolnánk a vaskohóba.

   Persze itt is kompromisszumokra fogunk kényszerülni, ezt itt a cikksorozat elején jobb ha megszokjuk. A kompromisszumkészség nem erény, hanem elvárt viselkedés életünk minden területén. A célt kell észben tartanunk, még ha gyakran könnyű is letérni a szent útról. Kompromisszumokat pedig ebből a nézőpontból az alapján fogunk kötni, hogy mennyire gyakran ismétlődik az a feladat, amelyet egy-egy ötletünkkel megkönnyítünk. Ha könnyítünk egy nem túl gyakori feladaton egy gyakortabban előforduló kárára vagy olyan bőséges szolgáltatásokat kínálunk minden létező és előforduló problémára hogy az már nem fér bele egy ember fejébe (ld. J2EE), az bizony csúnyán a málnásba ránthat bennünket és akkor lőttek az álmainknak.

4. Negyedszer szeretnénk, hogy modern legyen minden létező tekintetben. Web 19,3 és amit csak el tudunk képzelni. Végülis vonzóvá és népszerűvé kell tennünk a nagyközönség számára a verejtékes munkánkat és a marketingeseknek is kell valamiről áradozniuk az ügyfélnek, ha a cégük ezzel a keretrendszerrel fejleszt Nem utolsósorban mi szakmabeliek szeretjük az új és friss dolgokat, kütyüket tehát máris lefedtünk mindenkit, akit meg akarunk célozni a mi kis garázsprojektünkkel. (És még nem is említettem hogy szeretjük a screenshotokat, videókat, érdekes blogbejegyzéseket és mindent ami látványos).
5. Végül pedig az ötödik pontban egy nem a fejlesztéshez kötődő, de legalább annyira fontos dolgot szeretnénk: Gyakori és kicsi frissítések, magas minőségben. Ez azt hiszem manapság elvárás mindentől és mindenkitől, úgyhogy vegyétek úgy hogy ezt le sem írtam!

Fontos megjegyezni még hogy a felsorolás bizony fontossági sorrendet is jelent, fentről lefelé terjedően. Csak hogy ne merüljön fel kérdés bennünk, ha később netalántán ütköznének ezen elveink egymással.

 Miután ebben a szekcióban elszívtuk ópiumos pipánkat és álmodoztunk hogy mi lenne jó és hogy mit szeretnénk elérni, itt az ideje hogy az eddig is oly sokat emlegetett kompromisszumok közül megkössünk pár komolyabbat.

Hogyan és milyen eszközökkel kívánjuk elérni ezt a célt?

 A keretrendszert - hosszú mérlegelés után úgy döntöttem - PHP 5 felhasználásával készítjük el és nyílván fejleszteni is ezen nyelv felhasználásával fogunk tudni a mi kis keretrendszerünkben. Ennek számos és szerteágazó okai vannak, csak hogy néhányat említsek:

• Sok embert szeretnénk vele elérni, mert szeretjük a népszerűséget. PHP-ban pedig szignifikánsabban többen fejlesztenek, akik kíváncsiak lehetnek eme cikksorozat céljául kitűzött ismeretszerzésre.
• A PHP dinamikus tulajdonságai lehetővé tesznek néhány vagány fogást, amelyet szeretnék a tudtotokra adni.
• PHP-ban könnyebb demonstrálni és nem utolsósorban kevesebb kódsorral azokat a mintákat és technikákat, amelyek fontosak lehetnek egy jó keretrendszerben.

Lényeg a lényeg, a PHP sem a szent grál, rengeteg probléma van, amellyel meg kell küzdenünk a mindennapokban. Egyúttal nem rosszabb, mint pl. a Java, Python vagy a Ruby. Más, az igaz. De nem jobb vagy rosszabb. Ezen felbuzdúlva, lopni is fogunk sok-sok ötletet a taglalt nyelvekből és a hozzájuk fejlesztett keretrendszerekből és nem átallunk majd saját házunk tájáról sem tolvajolni, kivagdossuk a húsát a PHP-s keretrendszereknek is.

Modern vagányságunk és rutinunk mindemellett azt diktálják, hogy ha már PHP 5, akkor bizony önsanyargatás lenne nem objektum-orientáltan hozzáállnunk a modellezett világunknak. Gyakori, hogy kezdő, vagy kevésbé rutinos fejlesztők idegenkednek ettől a koncepciótól, de remélem hogy ez a fundamentális világlátás őket is megragadja majd, ahogy előrébb haladunk a munkánkkal és sikerül bebizonyítanom, hogy elengedhetetlen paradigma komplex rendszerek megalkotásához.

Mindemellett nem szeretnénk feltalálni a spanyol viaszt. Ki szeretné?! Használni fogjuk a nagyok elméjét, olyanok kútfőjéből merítünk majd mint Martin Fowler és Erich Gamma. Az uriembereket a jártasabbak a tervezési minták vagy design patterns termékeny apjaiként ismerhetik. Ezek a minták önmagukban és csokorba szedve is nagyon hasznosak, hiszen komplex feladatokat oldanak meg elegánsan és nem utolsósorban (!) sok-sok éven keresztül bevált módon.

Azt hiszem sikerült összeszednünk minden nagyvonalú fortélyt, amire szükségünk lesz, hogy egy életképes rendszert hozzunk a világra. A következő részben nekilátunk közelebbről vizsgálni a dolgot, megismerkedünk az MVC elveivel és megvizsgáljuk hogy hogyan tudjuk hatékonyan alkalmazni, aztán belelesünk az információkezelésbe és tárolásba, az üzleti logika, tehát a konkrét funkciók megvalósításának rejtelmeibe, végezetül pedig a megjelenítéssel fogunk egy kicsit babra menni. Mindezt tálaljuk egy csipetnyi kakukkfűvel és egy nagy csokor tervezési mintával (az MVC-n túl).

Bring it on!