ÉTRENDKÉSZÍTŐ WEBALKALMAZÁS

Átírás

1 Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Automatizálási és Alkalmazott Informatikai Tanszék Tóth Tamás ÉTRENDKÉSZÍTŐ WEBALKALMAZÁS Objektum-orientált PHP alapon KONZULENSEK Dávid Zoltán, Gincsai Gábor BUDAPEST, 2013

2 Tartalomjegyzék Étrendkészítő webalkalmazás... 1 Tartalomjegyzék... 2 Összefoglaló... 5 Abstract Bevezetés Specifikáció A cél A feladat kiírás pontosítása Elvégzendő feladatok Követelmények Rendszer kritériumok Fejlesztői kritériumok Népszerű keretrendszerek, tartalomkezelők vizsgálata Keretrendszerek Tartalomkezelők Kiszolgálói és fejlesztői környezet Webkiszolgáló Statikus kiszolgáló Program nyelv és kiterjesztések Gyorstár (NoSQL) kiszolgáló Relációs adatbázis kiszolgáló Verziókövető rendszer Integrált fejlesztői környezet Saját keretrendszer Tervezés Megvalósítás Étrendkészítő alkalmazás adatbázis terv Tartalomszervezés Területi információk Tudásbázis Étrend Felhasználói adatok... 45

3 7.6 Megvalósítás Szolgáltató alkalmazások Élelmiszer és étrend kezelő (diet-api) Felhasználó kezelő (user-api) Asztali gépekre optimalizált webalkalmazás Tervezés Megvalósítás Mobil környezetre optimalizálás Tervezés Megvalósítás Tesztelés Fajták Terv Példák Élesítési folyamat Lehetőségek Kivitelezés Értékelés Továbbfejlesztési lehetőségek Ábrajegyzék Irodalomjegyzék Függelék A. DVD melléklet... 85

4 HALLGATÓI NYILATKOZAT Alulírott Tóth Tamás, szigorló hallgató kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök stb.) használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait (szerző, cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulensek neve) a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy hitelesített felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. Dékáni engedéllyel titkosított diplomatervek esetén a dolgozat szövege csak 3 év eltelte után válik hozzáférhetővé. Kelt: Budapest, Tóth Tamás

5 Összefoglaló Az egészséges étkezés és ebből adódóan az étrendkészítés manapság egyre fontosabbá váló tényező minden ember számára, mivel a modern, rohanó élet nem hagy időt arra, hogy eldöntsük mi az, ami egészséges vagy megengedhető számunkra étkezéseink során. Az alkalmazás ebben nyújt segítséget oly módon, hogy a felhasználók közreműködésével létrehoz egy tudásbázist, mely alapanyagokat, élelmiszereket, recepteket, ezek kapcsolatait és egyéb speciális tudnivalókat tartalmaz. A begyűjtött információk és a felhasználók személyes paraméterei és preferenciái alapján a rendszer képes számukra könnyedén személyre szabott heti étrendet készíteni, mely az említetteken túl figyelembe veszi az orvosi ajánlásokat, javaslatokat a tápértékek és kalória bevitel terén. Az étrend elkészítése után további segítséget nyújt annak követésében azáltal, hogy segít megtalálni az oldalon regisztrált hasonló felhasználókat vagy éppen meghívni a személyes ismerősöket, hogy együtt könnyebben menjen a rendszeres egészséges táplálkozás betartása a kezdeti időkben és hatékonyan elérhetőek legyenek a kitűzött célok. A rendszer egy objektum-orientált PHP alapú webalkalmazás formájában kerül megvalósításra, amelynél a kezdetektől cél a globális, minőségi jelenlét, ezért már a tervezés során fontos a jó skálázhatóság és a magas rendelkezésre állás. Az okos telefonok elterjedése és azok technikai fejlődése lehetővé teszi a webalkalmazás kiterjesztését ezen eszközökre HTML5 alapokon, így az elkészített felület egyszerre képes minden funkciót biztosítani asztali környezetben és ugyanakkor a lényeges információkat optimalizált, kényelmes formában tálalni a mobil felhasználók számára. 5

6 Abstract Eating healthy and hence the making of a diet is an increasingly important factor nowadays for all people, as the modern, fast-paced life leaves no time to decide what kind of meals are acceptable and healthy for us. The application will help you with these tasks by creating a knowledge base of raw materials, foods, recipes, their relations and other specialized information with the power of the community. Based on the information collcted from users and their personal parameters and preferences, the system will be capable of creating a personalized diet which is taking into account medical recommendations and suggestions in the field of nutrition and calorie intake. After the diet is created the application will help you to find partners on the site with the same interests as you: following the diet, living healthier and achiving your personal goals. The system is implemented as an object-oriented PHP-based web application, which is built from the ground to be available for everyone, everytime and everywhere. The spreading and the technical development of smart phones allows us to easily extend our existing HTML5 based web application s usage to these devices. In this case there will be only one code base that both supports desktop users with all the functionality and mobile users with the most relevant information they need on the go. 6

7 1 Bevezetés A mai fejlett országokban egyre jellemzőbb, hogy a munkavállalók irodai munkát végeznek, ha úgy adódik, túlóráznak vagy éppen még az ebédre is csak szűkösen van idejük. A társadalom többi részével együtt ki vannak téve a globális marketingnek, mely folyamatosan olyan élelmiszerek vásárlására ösztönöz, amelyek egyszerűen egészségtelenek bárki számára a túl magas cukor, só vagy mesterséges anyag tartalom miatt. A két felvázolt probléma együttesen garancia az elhízásra és lényegesen emeli a különböző érrendszeri és egyéb olyan betegségek lehetőségét, melyek egészséges táplálkozással és megfelelő mennyiségű mozgással szinte biztosan elkerülhetőek. A probléma megoldásához életmód váltás szükséges, melynek első lépése a rendszeres és minőségi élelmiszer fogyasztás, a második lépés pedig szintén a rendszeres test mozgás. Egy étrend összeállítása tehát az elsődleges feladat, mely megfelelő mennyiségben és összetételben tartalmazza az egészséges tápanyagokat, ugyanakkor ez koránt sem olyan egyszerű feladat, amit pár perc vagy óra alatt el lehetne végezni, mivel rendszerint hiányzik az ehhez szükséges tudás. Tehát segítségre van szükségünk, kire számíthatunk? Vannak kiváló orvosok és dietetikusok, de rendszerint borsos áron dolgoznak és csak rövid útmutatásokat adnak, hogy mit kellene tenni, de arról már nem szokott szó esni, hogy hogyan. Például meghatározzák a napi tápanyag beviteli értékeket, de étrendet már nem állítanak össze, mondván nem ismerik az étkezési szokásainkat, hogy mit szeretünk és mit nem, s ebben természetesen igazuk is van, viszont ezzel garantált, hogy a nagy többség itt el is akad. A diplomaterv témája az étrendkészítés problémájának megoldása, hogy bárki könnyen vegye ezt az első akadályt és elérhesse kitűzött céljait. A megvalósítás a manapság népszerűvé vált közösségi erőre épít, mely lehetővé teszi tudásbázisok építését, a felhasználók megismerését, csoportosítását, összekötését, hogy mindenki megtalálja azt az információt vagy partnert, amire, akire szüksége van, hogy elérje személyes célját. Az étrendkészítő feladata, hogy az összegyűjtött információk alapján segítse elsődlegesen a személyre szabott étrend elkészítését, másodlagosan

8 pedig a hasonló érdekeltségi körű felhasználók egymásra találásának segítését és az étrend napi követését. A hazai piacon található több megoldás is, melyek többsége csak kalória táblázatokat ad (pl. [1], [2], [3], [4], [5]) vagy kalóriaszámlálásra használható (pl. [6], [7], [8]) ami egyébként egy nagyon hatékony diétás módszer. Utóbbiaknál nem ritka, hogy nem rendelkeznek élelmiszer adatbázissal és a korábban bevitt adatokat sem tárolják, így mindennap újra és újra meg kell adni minden szükséges paramétert, hogy követni lehessen a napi fogyasztásunkat. A másik nagyobb csoportja az oldalaknak, amik már rendelkeznek adatbázissal és étrendeket is adnak [9], de ezek előre összeállított diéták, melyeket egy szakmai csoport dolgozott ki. Sajnos rendszerint olyan összetevőket is tartalmaz, amiket nehéz beszerezni, elkészíteni, illetve leggyakrabban egyáltalán nem felel meg az adott ember ízlésének. Például sokan vannak, akik nem lelkesednek a gombáért, brokkoliért, karfiolért, s ekkor megint előáll, hogy módosítani kellene az étrenden, de nincs meg hozzá a tudás, idő, kedv. A külföldi piacon, angol nyelven tovább keresve jobb megoldásokat is találhatunk. Például bonyolultabb étrend összeállító alkalmazást [10], amely már túlságosan részletes adatokkal bír, így a használata is nehézkes. Még egy kis ügyességgel étrend generátorra [11] (illetve újabb verzióját [12]) is bukkanhatunk, melyek egészen jó munkát végeznek, de sajnos személyes étrendet csak havi díj ellenében készítenek, az étrend követésére és közösség formálásra már nincs lehetőség, pedig mindkettő fontos lenne. További probléma, hogy ezek a szolgáltatások csak angolul érhetőek el, így sok ember számára nem használhatóak ezek az eszközök, főként az idősebb korosztályt zárják ki, pedig számukra kiemelten fontos az egészség megőrzés. Láthatjuk tehát, hogy vannak jó kezdemények, még ha a tengeren túlra is kell menni érte, de vagy túl keveset nyújtanak vagy túlbonyolított a megvalósításuk vagy még fejlesztésre szorulnak, hogy valóban hasznos eszközzé válhassanak számunkra. Ezeket a problémákat hivatott megoldani a megvalósítandó étrendkészítő webalkalmazás, mindamellett, hogy informatikailag is a legjobb megoldásokat igyekszik felhasználni. 8

9 2 Specifikáció 2.1 A cél A cél egy bárki számára elérhető közösségi étrendkészítő és követő megoldás készítése, tanulva a jelenleg létező megoldások jó ötleteiből, hibáiból, hiányosságaiból. 2.2 A feladat kiírás pontosítása A feladat a következő fő részekből áll: keretrendszer tervezése és fejlesztése, mely megfelel a támasztott rendszer kritériumoknak; adminisztrációs felület készítése az adatbázis és főbb rendszerek kezelésére; webalkalmazás készítése mely megvalósítja a következő 4 pontban kifejtett funkciókat (asztali számítógépekre optimalizált felülettel); a webalkalmazás mobil környezetre optimalizálása (különböző kisebb felbontásokra alkalmazkodó felület) Tudástár létrehozása és fejlesztése a fejlesztők bevonásával. A közösség által bővíthető adatbázis létrehozása, melyben megtalálhatóak: az alap összetevők (vitaminok, ásványi anyagok, nyomelemek), alap élelmiszerek (gyümölcsök, zöldségek, halak, alapvető pékáruk stb.), kiegészítő élelmiszerek (multi vitaminok, bio készítmények), ételek és italok (bármi, ami az alap élelmiszerekből készíthető, az egyszerű szendvicstől a 10 fogásos vacsoráig). Továbbá az adatbázis lehetőség szerint minél pontosabban rögzíti az ezek közti tartalmazási kapcsolatokat, kalória tartalmakat. A tudástár a készítendő webalkalmazáson keresztül bárki számára elérhető, listázható, kategorizálható, szűrhető és bővíthető. Az alap összetevők és alap élelmiszerek esetén fontos a pontos értékek megadása, ezek felvétele megbízható, avagy szakértő emberek feladata, az ezekből összeállítható ételek és italok ugyanakkor bármely felhasználó által felvihetőek, a moderálás joga fenn tartva. 9

10 2.2.2 Étrendkészítésben automatizált segítségnyújtás szakmai alapokon A felhasználók készíthetnek saját étrendet. A rendszer a következő lépésekkel segíti a diéta összeállítását: Felhasználó testi és cselekvési paramétereinek begyűjtése: magasság, súly, kor és napi aktivitás. A megadott értékek alapján a főbb határértékek meghatározása: napi kalória, fehérje, szénhidrát és zsír mennyisége, ezek eloszlása az étkezések számától függően egy napon belül. Az élelmiszerek, ételek, italok kiválasztását egy intelligens kereső segíti, kiválasztás után meghatározza az adott határértékeknek megfelelő mennyiséget. Az értékek szabadon módosíthatóak, de a határértékeket ekkor is figyeli és javaslatot tesz túllépés esetén Diéta tervezése gyorsan és hatékonyan Automatikus diéta készítése a felhasználó adatai és preferenciája alapján. Ehhez szükséges, hogy a főbb élelmiszer kategóriákból legyen legalább egy legalább ehetőnek értékelt választása, hogy olyan étrend készülhessen, amit szívesen fogyaszt, nem unja meg és eléggé változatos is, a szervezet számára szükséges nyomelemek, ásványi anyagok és vitaminok beviteléhez Baráti közösség kialakítása Egy új rendszeres cselekedet, mint az étrendkövetés megkövetel egy bizonyos szintű akaraterőt, rendszerességet, amit ki kell fejleszteni. Ebben lehet jó segítségünk egy barát, rokon vagy akár egy ismeretlen, aki ugyanazt készül tenni, mint mi, ezért fontos, hogy a céljainkat támogató vagy még inkább megosztó társakat találjunk. A feladat tehát, hogy a felhasználók ne legyenek egyedül, tudjanak keresni az oldalon a többi felhasználó között, be tudják őket jelölni ismerősnek, hogy könnyen elérjék őket, tudjanak egymásnak üzeneteket írni offline és online egyaránt, illetve legyen lehetőségük direkt módon is diétákat, élelmiszereket, ételeket, italokat egymásnak ajánlani, véleményezni, értékelni. 10

11 2.3 Elvégzendő feladatok Először is meg kell vizsgálni a létező megoldásokat, feltárni a problémáikat ez a bevezetőben megtalálható. A látottak ismeretében meg kell fogalmazni a kritériumokat a saját rendszerrel szemben mind üzemeltetési, mind fejlesztési szemszögből. Célszerű megnézni milyen megoldások állnak rendelkezésre a projekt megvalósításához, ehhez átnézzük a népszerűbb tartalomkezelő rendszereket és PHP alapú keretrendszereket. A tanulságok levonása után meghatározom a kiszolgálói és fejlesztői környezet lehetséges és választott eszközeit. A fejlesztés egy saját keretrendszer készítésével kezdődik, mely sok előzetes kutatómunka és tapasztalatszerzés eredményeként fog össze állni egy rugalmas alaprendszerré, amire tetszőleges webalkalmazás fejleszthető. A következő lépésben szükséges megtervezni az étrendkészítő alkalmazásainak adatbázisait, az azokban lévő egyedeket és azok kapcsolatait. Az adatokat elfedő kiszolgáló réteg tervezése és kivitelezése a következő feladat, mely lehetővé teszi egyrészt a webalkalmazás létrehozását, másfelől későbbi széleskörű API támogatás létrehozását, amellyel natív mobil alkalmazások is könnyedén tudnak kommunikálni egy REST interfészen keresztül vagy tetszőleges RPC alapon. A szolgáltató alkalmazások lefedik a teljes háttér funkcionalitást, csak ezeken keresztül lehet adatot módosítani a rendszerben. Felelősek a saját adataikért, ezért több részbe szervezendőek szét. A webalkalmazás, az első számú felület az étrendkészítőhöz. Főként a böngészős felületek kiszolgálása a célja, ehhez szükséges felület tervezés és sitebuild, majd erre építve dinamikus, interaktív funkciók megvalósítása kliens oldalon, illetve az alkalmazás összekötése a szolgáltató réteggel távoli klienst reprezentáló segédek használatával. Az étrendkészítőnek mobil környezetben is használható formában kell megjelennie, ezért meg kell oldani, hogy a webalkalmazás idomuljon a mobil szféra elvárásaihoz, a kisebb kijelzőhöz, felbontáshoz, a nagyobb felhasználói interakciót 11

12 kívánó felület igényéhez. Figyelembe kell venni az adat korlátokat is, mind memória, mind pedig sávszélesség esetén, ehhez szükséges a funkciók elérhetőségének átgondolása, azok letiltása, a felület átrendezése, egyszerűsítése, ahol szükséges. A minőség biztosításhoz elengedhetetlen az alkalmazások tesztelése, kezdetekben ez kézileg is viszonylag gyorsan elvégezhető, viszont a későbbiek során, ha már több fejlesztő fog csatlakozni a projekthez és bővül a funkciólista tetemesen úgy indokolttá válik az automatikus tesztelés. Ennek aspektusait fogjuk áttekinteni és a választott megoldásokról 1-1 példát megnézni. Az elkészült programot konzisztens formában kell kezelni éles üzemben, ezért szükség lesz egy élesítési módszerre, rendszerre. Ennek lehetőségeit és a projekt elején választott módszert megismerjük. A diplomaterv zárásaként értékelem a projektem és kifejtem a további elképzeléseket, fejlesztési lehetőségeket az étrendkészítő jövőjét. 12

13 3 Követelmények A tervezés előtt meghatározzuk a rendszerrel és a fejlesztéssel kapcsolatos elvárásokat, irányvonalakat, amik nagyban befolyásolják a végtermék minőségét és jövőjét. 3.1 Rendszer kritériumok Globális jelenlét: bárki, bárhonnan elérhesse a szolgáltatást, ahol van internet kapcsolat. Minél több a felhasználó, annál értékesebb a termék. Magas rendelkezésre állás: az idő bármely pillanatában legyen elérhető a szolgáltatás. Az új verziók élesítése és a karbantartások ideje alatt is konzisztens elérést kell biztosítani. Megbízható szolgáltatás, hűséges felhasználók. Gyors kiszolgálás: a válaszidők minimalizálása, több adatközpont és elosztott működés révén. A felhasználó türelme véges, az ideje korlátozott, ha a számára fontos információkat nem kapja meg más szolgáltatás után fog nézni. Alacsony költség: az üzemeltetési költségek alacsonyan tartása virtualizációval, felhő szolgáltatások igénybe vételével. Profit maximalizáció, hardver hibák kiküszöbölése. 3.2 Fejlesztői kritériumok Egységes konvenciók: a kódbázis előre meghatározott struktúrával és formával kell rendelkezzen. A jövőbeni csoportos fejlesztés alapköve. Szabványos megoldások: a forráskódoknak lehetőleg teljes mértékben meg kell felelniük a típusukra adott szabványuknak, ettől csak kivételes esetben lehet eltérés (pl. CSS kód IE esetén), illetve ahol létezik validátorok használata kötelező; kommunikációs protokollok esetén a hozzájuk tartozó RFC-ben megadottaktól eltérni nem lehet. Egyszerűség, hatékonyság: amennyiben létezik egy adott problémára optimális vagy ahhoz közeli könnyen beépíthető, tovább finomítható, karbantartott megoldás, úgy annak használata erősen ajánlott. 13

14 4 Népszerű keretrendszerek, tartalomkezelők vizsgálata Fontos, hogy a webalkalmazást a kezdetektől azon elvek mentén tervezzük, ahogy látni szeretnénk pár év múlva. A mai világban egy angol nyelvvel ellátott oldallal könnyű nagy felhasználóbázisra szert tenni, ezért ennek megfelelően olyan rendszert kell készíteni, ami megbirkózik ennek kihívásaival: több millió regisztráció, több száz kérés másodpercenként. Ehhez nem elég a felhasználói funkciókat hatékonyra tervezni, magát a működtető keretrendszert és tartalomkezelő részeket is ennek tudatában kell megtervezni. A következőkben a népszerűbb PHP [13] alapú keretrendszereket és tartalomkezelőket vesszük sorra, hogy lássuk megfelel-e a támasztott igényeknek, mik az erősségeik, mik a gyengeségeik. 4.1 Keretrendszerek Egy keretrendszerrel szemben a legfontosabb elvárások: működjön a legújabb PHP verzióval, használja ki annak lehetőségeit, legyen objektum-orientált, több absztrakciós rétegből felépített (Model-View-Controller, adatelérés absztrakció), alkalmazásokra osztott, moduláris (közös és alkalmazás specifikus modulok), felépítése és működése legyen könnyen érthető, tanulható. Továbbá a korábban megfogalmazott rendszer követelményeknek is feleljen meg. Zend Framework [14]: nagy múltra visszatekintő komplex keretrendszer, mely rengeteg kiegészítővel rendelkezik, szinte bármilyen probléma körre rendelkezik megoldásokkal, ugyanakkor mindez elég nagy plusz terhet ró a rendszerre, emiatt szinte minden teljesítmény tesztben a lista végén kullog. Symfony [15]: az előzőhöz hasonlóan teljes körű megoldásokat igyekszik adni, ugyanakkor mindezt a lehető legáltalánosabb módon próbálták elérni, hogy mikro és óriás projektek számára is megfelelő legyen, ugyanakkor ne jelentsen megkötést. Az általánosítás miatt itt is kissé körülményes az alkalmazásra specializáció: rengeteg beállítási lehetőség, kódbeli plusz művelet lassítja a futást, emiatt jelen projekthez nem 14

15 optimális. Ugyanakkor eszköz szinten az általánosítás kifizetődő, sok kész programcsomag (úgynevezett bundle) áll rendelkezésre különféle feladatok elvégzésére, ezért az egyedi megoldások fejlesztése helyett érdemes szétnézni a weben akad-e Symfony Bundle adott feladatra, ezzel sok időt spórolhatunk, főleg az adminisztrációs és monitoring megoldások esetén. Yii [16]: egy fiatal keretrendszer, mely egyre nagyobb népszerűségre tesz szert. Egyszerű, logikus felépítése gyors betanulást, termékfejlesztést tesz lehetővé és kiváló futási eredményeket produkál, mellyel az élmezőnyben foglal helyet. Kisebb vagy közepes projektek megvalósítására tökéletes választás, esetünkben nem elégséges a tudása. Hiányoznak belőle a globális elosztott működéshez szükséges adatkezelő megoldások, ugyanakkor sok jó elképzelés is megtalálható benne, amik a étrendkészítő saját keretrendszerében is megtalálhatóak lesznek. Természetesen léteznek még bőven keretrendszerek, de ezek rendre az említettek között helyezkednek el tudásban és teljesítményben is. Hasonló jó tulajdonságok találhatóak meg bennük, mint a Yii-ben és hasonló általánosításból eredő problémáik vannak, mint a Zend Framework és a Symfony esetében. 4.2 Tartalomkezelők Egy létező tartalomkezelő sokat gyorsíthat a fejlesztésen, mivel az étrendkészítő tudásbázisa részben statikus tartalomból is áll, melyet az ilyen rendszerek kezelni tudnak, amennyiben ráépíthető a további logika és működés. A keretrendszereknél leírt elvárások itt is fennállnak. Wordpress [17]: alapvetően blog motor, de könnyen bővíthető modulárisan. Sajnos nem egészen objektum orientált megoldásokra épül és a modulok is inkább beépülő jellegű megoldások lehetnek, egy önálló komponens készítése nehézkes. Drupal [18]: népszerű tartalomkezelő rendszer, modulárisan bővíthető. Erősen szöveges tartalom orientált, nehezen oldható meg komplexebb struktúrák tárolása, illetve maga az alaprendszer is kötött megoldásokat tartalmaz, melyeket annak 15

16 módosítása nélkül nem lehet megkerülni, viszont ezzel a frissítések követése lenne bonyolult és kockázatos. Joomla [19]: szintén népszerű tartalomkezelő, mely teljesen objektum orientált, komponensekkel, modulokkal és beépülő kódokkal bővíthető. Ez a felépítés követendő példa egy nagy projekt esetén is. A rendszer ugyan jól működik, de a kódbázis minősége hagy maga után kívánni valót, nagyobb verzióváltásoknál előfordulnak erősebb kompatibilitási problémák, a külső felek által készített komponensek sokat gyorsíthatnának a termék fejlesztésén, de ezek rendre az alap rendszernél is problémásabb kóddal rendelkeznek. 16

17 5 Kiszolgálói és fejlesztői környezet Észben tartva a megfogalmazott rendszer kritériumokat áttekintjük és kiválasztjuk a megfelelő komponenseket. A költség minimalizálás elvénél fogva operációs rendszer tekintetében a Windows kizárva, Linux részen a Debian vonal a legáltalánosabb és felhasználóbarát rendszer, ezért az erre építkező Ubuntu disztribúciót választottam. 5.1 Webkiszolgáló Apache [20]: tulajdonképpen az ipari szabvány (linux alatt script kiszolgálásra), mindent tud, moduláris felépítésben. Könnyen konfigurálható, mindenki ismeri, aki fejlesztett már PHP alapon, bármilyen projekt kezdetére jó választás, ezt választottam én is a fejlesztés idejére. Nginx [21]: a fiatal konkurencia, egyre nagyobb tudásra tesz szert, ahogy fejlődik, egyelőre még inkább az Apache intézi a dinamikus tartalom kiszolgálást, de már sok helyen nginx kerül elé, mivel tűzfalként jóval nagyobb teljesítményre képes társánál, illetve statikus kiszolgálásban szintén jobb mutatókkal rendelkezik. (Konkrétan az Apache felső határa valahol 1000 kérés per másodperc közelében van, addig nginx-el sikerült fölé is menni persze ez el is várható egy olyan szoftvertől, amit a c10k problémára szántak megoldásként, avagy a konkurens kérés kiszolgálására.) A fejlesztés ideje alatt csak az Apache kerül használatba, viszont éles üzemben felváltja nginx vagy legalább a kiszolgálási láncban elé kerülhet a jobb védelem érdekében. 5.2 Statikus kiszolgáló Az nginx-en kívül még a lighttpd [22] érdemel szót ezen a téren, de elmarad teljesítményben tőle, a fejlődése is lényegesen lassabb, ezért az nginx-et választom, illetve a fejlesztés ideje alatt az Apache fogja ezt a kiszolgálást is biztosítani. 17

18 A statikus fájlok esetén számba kell venni a gyorstárazási lehetőségeket, mivel egy jó verziózás használatával minden fájlt több napra, hétre a memóriában lehet tárolni, ha egyszer már lekérték, s ezzel a megoldással nagyságrendekkel gyorsabb e a fájlok kiszolgálása. Varnish [23]: nagyon hatékony http gyorstár, a kiszolgált tartalmat akár több részre bontva is képes külön tárolni, rengeteg beállítási lehetősége van, és ezek nem rontják a teljesítményét. Egy Apache elé kiváló választás lenne, de mérések alapján nginx elé/mellé nem hoz már akkora teljesítmény különbséget (1.5-2-szeres adatokat mértem), hogy megérje plusz egy rendszer karbantartása és üzemeltetése. A gyorsaság kritériumának szemszögéből nézve fontos, hogy ne csak a kiszolgálás legyen villámgyors, de jusson is el mielőbb a klienshez, ezért érdemes egy CDN (Content Delivery Network [24]) megoldás készítése vagy igénybe vétele, mely a klienshez legközelebb eső szerverről fogja megvalósítani a kiszolgálást, így a hálózati késleltetés minimális. Érdemes a forgalom növekedésével a saját megoldás használata, előtte pedig figyelemre méltó a CloudFlare [25] ingyenes induló csomagja, illetve az Amazon Web Services [26] CloudFront [27] megoldása, mely forgalomfüggő költségekkel rendelkezik és egyszerűen összeilleszthető más AWS szolgáltatásokkal. Az éles kiszolgáló környezetbe már kiválasztottuk az nginx-et, ezért induláskor ez fogja kiszolgálni a statikus tartalmakat, a CDN megvalósítása tulajdonképpen útvonalválasztás kérdése, így ez esetben is használható lesz, hiszen csak azt kell megoldani, hogy egy globális cím a kliens IP-je alapján a megfelelő adatközpontba legyen irányítva, ebben pedig a BGP (Border Gateway Protocol [28]) játszik fontos szerepet. 5.3 Program nyelv és kiterjesztések A projekt megvalósítása PHP script nyelv használatával történik, melynek 5.4- es verziója az aktuálisan stabil. Az 5.3-as verzió óta minden fontosabb eszköz meg van (gondoljunk itt a névterek bevezetésére) egy korrekt objektum-orientált projekt megvalósításához. Az 5.4 újításai egyszerűsítenek a kódoláson (kevesebb gépelés, 18

19 azonos működés), illetve a trait-ek bevezetésével lehetőség nyílik aspektus orientált fejlesztésre is. Fontosabb kiterjesztések, amiket a projekt használni fog (lásd [29]): Adatformátumok: JSON [30] (a belső API és külső AJAX kommunikáció alapja), YAML [31] (emberbarát, beállításokat tartalmazó fájlok formátuma), XML [32] (külső, szabványos rendszerek által használt formátum). AMQP (Advanced Message Queue Protocol): szabványos üzenet sor kiszolgálók kezeléséhez ad kliens felületet (pl. a projekt által is használt RabbitMQ-hoz). APC (Alternative PHP Cache): opcode (lefordított script kód) gyorstárazás, így nincs szükség minden futásnál a kód fordítására, egyből futtatható. curl: sokféle kommunikációs protokollt támogató megoldás, mellyel egyszerű megoldani a belső szerverek közti kommunikációt (http alapon) és külső szolgáltatások adatainak beolvasását is (pl. hírfolyamok, időjárás RSS alapon). GD: képfeldolgozó kiterjesztés, mellyel lehetséges képek átméretezése, vízjelezés, captcha képek készítése. GeoIp: adott időközönként frissülő adatbázis alapján egy IP-ről visszaadja a hozzátartozó hely információkat (ország, megye, város stb.), ezt kihasználva könnyen meg lehet határozni egy felhasználó által preferált nyelvet már az első kérésénél, illetve lehetőséget ad ország/közösség specifikus funkciók készítésére vagy egy-egy nagyobb új funkció tesztelésére kisebb felhasználói körben. Gzip: hibanaplók, statikus tartalmak tömörítése, a webkiszolgálók és böngészők is natívan támogatják, lényegesen csökkenti az adatforgalom méretét. PDO: relációs adatbázisokhoz nyújt közös elérési réteget. Phar: PHP archívum formátum kezelése, ezzel egy fájlba csomagolható egy teljes alkalmazás, s futtatható is. Teljesítményromlással jár, ezért csak offline eszközök készítésénél használható ki jól az előnye. 19

20 Xdebug: a fejlesztés során a hibakeresést könnyítő eszköz, gyorsan telepíthető, beállítható és hibák esetén részletes információkat nyújt a hiba környezetéről, paraméterekről, azok értékéről. Xhprof: a Facebook által kifejlesztett profilozó megoldás, az Xhgui-val együtt remek eszköz a problémás kódrészek feltárására, a graphviz gráf rajzoló segítségével a hívási láncokat is szépen tudja szemléltetni, kiemelve a legtöbb időbe kerülő részeket. 5.4 Gyorstár (NoSQL) kiszolgáló A relációs adatbázisok ACID tulajdonsága nagyon fontos a kritikus adatok tárolásához, másfelől e kritériumoknak való megfelelés a teljesítmény rovására megy, melynek hatására egyre több eltérő szemléletű rendszer készül, melyek a teljesítményre és az egyszerű kulcs-érték alapú tárolásra koncentrálnak. A következőkben átnézzük a népszerűbb, már elterjedtebb felhasználású NoSQL kiszolgálókat, hogy kiderüljön mire is lehet használni, mire lehet jó? APC: nem tartozik szorosan a mezőnybe, mivel megosztott memória alapon működik, így 1-1 szerverre korlátozott a hatóköre. Emiatt rendkívül alkalmas előfordított kódok tárolására, de kulcs-érték megőrzésre az adminisztrációs nehézsége miatt nem ajánlott. Memcache [33]: C-ben írt memória alapú kulcs-érték tároló szerver, kis méretű adatokra (8kB per kulcs) a leggyorsabb megoldás, de semmilyen diszk alapú tárolás nincs benne és maximum 1MB-ig terjedhet az adat kulcsonként. Vendég felhasználók munkamenetének tárolására kiváló. Repcache [34]: egyszeresen redundáns Memcache pár, melyek bármelyikébe lehet írni-olvasni (master-master [35] felépítés, tovább nem bővíthető), az adatokat szinkronban tartják. Regisztrált felhasználók munkamenetéhez, CSRF és egyéb biztonsági token-ek tárolására alkalmas. Redis [36]: C-ben írt master-slave [37] felépítésű memória alapú tároló szerver, mely az adatokat fájlba is tudja menteni, ezáltal nem tervezett leállás után az adatok jó 20

21 része vagy egésze megmarad. A kulcs-érték tároláson felül többféle adatszerkezetet is kezel, például rendezett listát, ami jól jöhet, ha bármilyen korlátos top-, kedvenc- vagy ajánló listát szeretnénk készíteni. Cassandra [38]: Java-ban írt, relációs adatbázisokhoz hasonló adatszerkezettel dolgozó, multi-master felépítésű rendszer. Az RDMS-ekhez képest nincsenek benne tranzakciók, illesztés és zárolás, így kulcs-érték tárolóként érdemes rá tekinteni, ami lehetőséget enged bonyolultabb, kulcsokon átívelő lekérdezések készítéséhez. A felépítése lehetővé teszi, hogy több adatközponton keresztül elérhető, redundáns és gyors kiszolgálást tegyen lehetővé. Nagyobb cégek is használják (pl. Netflix), de rendre plusz fejlesztéseket igényel, hogy valóban jól használható és hibamentes legyen. Riak [39]: szintén multi-master felépítésű, Erlang nyelven írt tároló, ami a Cassandrához hasonlóan hash-elés útján osztja el a kulcsokat a cluster gépei között. Tárolás szempontjából nincs megkötés, bármilyen adatot bármilyen méretben tárolhatunk benne, s amire értelmezhető azokon Map/Reduce [40] (hatékony adatszűrési és feldolgozási módszer) és Full Text Search [41] (szöveges tartalmakban való gyors keresés) funkciók elérhetőek. MongoDB [42]: JSON formátumú dokumentumok tárolására készített masterslave felépítésű rendszer. Kliens oldali javascript-tel és szerver oldali Node.js kiszolgálóval együtt készíthető vele tisztán javascript alapú alkalmazás. Az adatstruktúra kezelése kifejezetten alkalmassá teszi egymásba ágyazott információ halmazok kezelésére, például: üzenet fal, chat, felhasználói kapcsolatok egy normál adatbázis esetén ezek megvalósításához bonyolult illesztésekre van szükség, míg itt megfelelő szerkezettel egyetlen egyszerű lekérdezéssel minden szükséges adatot megkaphatunk. A legtöbb említett kiszolgáló felhasználásra kerül a projekt során: APC opcode cache, Memcache vendég munkamenetek sharding használatával, Repcache biztonsági tokenek, Redis kedvenc és toplisták, MongoDB üzenetek és chat. A Riak későbbi fejlesztések során juthat szerephez az elosztott adatfeldolgozó képessége okán (Map/Reduce), hogy az étrendkészítő még jobb ajánlatokat tudjon adni az összes felhasználó és az általuk végzett tevékenységek alapján. 21

22 5.5 Relációs adatbázis kiszolgáló A felhasználói és pénzügyi adatok tárolására egy megbízható, jól bevált relációs adatbázis szükséges, az alábbiakban ezeket nézzük át. MSSQL [43]: a Microsoft terméke, melynek ugyan van ingyenes verziója, de a futtatásához szükséges Windows Server már pénzes. Tudása bőven elégséges bármilyen projekthez, ugyanakkor üzemeltetési költségei miatt nem opció számomra. MySQL [44]: a legnépszerűbb adatbázis szerver, mely az általános igényeket kiszolgálja, s mindezt teljesítményben is megfelelően teszi. Master-slave architektúrában az olvasás intenzív kiszolgálásban rendkívül erős tud lenni, s megfelelő feltételek esetén multi-master módon is sikerrel használják. Ingyenes, megbízható és több külső cég is az optimalizálásán fáradozik, például a Percona, akik a fő kiadások után pár hónappal rengeteg optimalizálással megtoldott verziójukat szintén ingyenesen kiadják, s így már valóban egy kevés hibával és kiváló teljesítménnyel bíró adatbázist kapunk. Oracle [45]: az MSSQL-hez hasonlóan minden tud, de sok tudást és még több költséget követel, amit a támasztott kritériumok kizárnak. PgSQL [46]: az Oracle ingyenes terméke, tartalmazza az összes értelmes felhasználói funkciót, jó megoldás lehet Oracle-ről való átállásra, de teljesítményben elmarad a MySQL-től. A MySQL-t választottam, mivel ingyenes, könnyen adminisztrálható, skálázható és megfelel a teljesítménybeli elvárásoknak. 5.6 Verziókövető rendszer A projekt eredetileg Subversion (röviden SVN [47]) verziókövető rendszert használt, de időközben a más projekteken való csoportos munka felderítette ennek problémáit, melyek nehezen használhatóvá teszik nagyobb projektek esetén, sok plusz munkát igényel, ha komolyabb ütközés van két fejlesztő munkája között. A 22

23 problémát az okozza, hogy nem a tényleges változásokat, hanem állapotokat tárol, vagyis nem tud róla, hogy mi változott a fájlban, csak azt, hogy melyik sor és mi lett vele. Leggyakoribb példa a sorvégi karakter módosítása egy fájlban, ekkor úgy veszi, hogy a teljes fájl módosult és ilyenkor, ha ketten ugyanazon a fájlon módosítottak, akkor kézi beavatkozás szükséges, az SVN egyáltalán nem tudja feloldani az ütközést, ez pedig plusz idő a fejlesztő számára, mely a hasznos munka rovására megy. A problémákra megoldásként két érdekes verziókövető rendszer is született nagyjából egy időben: a Git [48] és a Mercurial [49]. Hasonló elképzeléseken alapulnak: egy központi tároló helyett legyen ott a teljes verziókezelés mindenkinél, aki használja (elosztott működés); legyen egyszerű átjárás ezek között (pull és push műveletek repository-k közt); a változások ténylegesen változásként legyenek regisztrálva (úgynevezett changeset-ek) és a rendszer ennek megfelelően legyen képes azokat commit sorrendben összefésülni (merge). A két rendszer között a branch és history kezelésben van leginkább különbség, egyszerű felhasználói szempontból egyformának tekinthetjük. A Mercurial használata valamivel barátságosabbnak tűnt, ezért ezt választottam. A rendszer megértéséhez és minél gyorsabb elsajátításához segítségünkre van a hginit.com [50], mely taglalja a különbséget az SVN-nel, majd pedig végigvezet a munka (folyamat) során előforduló szükséges parancsokon példákkal illusztrálva. Megjegyezném még, hogy publikus, avagy nyílt forrású kódok készítése esetén a Git-re támaszkodó GitHub [51] megoldása rendkívül népszerű (és ha jelen projekt ilyen jellegű lenne valószínűleg ezt választottam volna), szinte minden projekt megtalálható rajta, ami számít, teljes rendszert ad a csoport munkára. 23

24 5.7 Integrált fejlesztői környezet Munkám során a Zend Studio 8-as és 9-es [52] (eclipse alapú) megoldásával hozott össze a sors, mivel közel áll a PHP készítőihez, így ez a legteljesebb létező megoldás, mely integrálva van a Zend többi saját készítésű megoldásával (pl. Zend Server). Az eclipse alapnak köszönhetően sok külső modullal okosítható, például PHPUnit, Code Sniffer, Mess Detector és egy kódminőség vizsgálókkal, illetve bármilyen külső alkalmazást is futtathatunk a kódra (tulajdonképpen az említettek is így működnek, de a fontosabb beállításaik elérhetőek a felületen keresztül is). Hobbiként a PhpStorm [53] alkalmazás fejlődését követem figyelemmel, mely immáron a 6-os verziónál jár. Sok kis részletben túltesz a Zend Studio-n, de tapasztalatom alapján Windows-os környezetben vannak problémák, illetve hiányosságok, ami miatt nem teljes az élmény gondolok itt például a mostanában divatos composer-re [54], ami integrálva van az eszközbe, de mégsem működik. Valószínűsítem, hogy Linux alatt nincsenek ilyen problémái, mivel ott különböző programcsomagok (úgy, mint PHP) telepítése is gyerekjáték, de sajnos a Windows még mindig sokkal kényelmesebb a mindennapi multimédiás felhasználásban vagy éppen diplomaterv szerkesztésben. Itt említeném meg, hogy a Zend Studio sem tökéletes Windows alatt, ezért rendelkezésemre áll egy Ubuntu szerver [55] is, mely megoldja a parancssorból intézendő dolgokat, másrészt az egész projektnek otthont ad, biztosítva minden szükséges szolgáltatást, ami csak kellhet. 24

25 6 Saját keretrendszer A keretrendszer feladata minden általános komponens és funkció megvalósítása, amire a webalkalmazásnak szüksége lesz. 6.1 Tervezés Irányvonalak A keretrendszer meg kell feleljen a korábban támasztott rendszer kritériumoknak. El kell fednie az erőforrásokat legyen szó akár a bemeneti paraméterekről, adatbázis kapcsolatról vagy sablonkezelésről. Felesleges részeket nem tartalmazhat, mivel növeli a kódbázis méretét, s ezzel lassítaná a futást. Komplett megoldást kell tartalmaznia webes kérések feldolgozására, API működésre és ütemezett scriptek futtatására Összetevők Projekt felépítés A keretrendszer és az általa támogatott működés öt fő részre bontható: Alkalmazások (application): gépcsoportokra bontható funkció csoportok, például portál alkalmazás, mely a felhasználói felületet nyújtja, API alkalmazások, melyek felhasználó-kezelést, étrendkészítést fogják egybe. A felelősségi körök így elkülöníthetőek, biztonsági szempontból jobban védhető infrastruktúra felépítést tesz lehetővé. Gyakorlatilag a portál alkalmazás fogad minden kérést, így első védelmi lépcsőként kiszűrheti a támadásokat, a normál kiszolgálás során pedig hívásokat intézhet a csak belső hálózaton elérhető API gépekhez, melyek így védve vannak a külső támadásoktól. Háttérfolyamatok (batch): konzolban futtatható vagy cron-nal ütemezett feladatok elvégzésére készített script-ek. Például az élesítéshez szükséges kódgenerálás, napló táblák tisztítása, a rendszer általános karbantartása. Közös kódrészek (common): az alkalmazásokhoz erősen hasonuló kódbázis, ami olyan funkciókat valósít meg, amit több alkalmazás is használhat. 25

26 A keretrendszer osztályai (framework): lásd következő cím. Statikus tartalom (media): az alkalmazások által használt css/js/kép/dokumentum fájlokat tartalmazza elkülönítve, mivel ezek kiszolgálása eltérő vagy akár külső szolgáltató által történik Moduláris felépítés Az objektum-orientáció egységbe zárás elvét alkalmazva meghatározunk három nagy csoportot, amire az alkalmazások bonthatóak: Komponensek (component): az alkalmazás fő részei, amelyek egy teljes MVC felépítést valósítanak meg (vezérlő osztályok, adatkezelő és üzleti logikát tartalmazó osztályok, oldalkeretek, tartalmi és blokk szintű sablonok). A kiszolgálóra érkező kéréseket dolgozzák fel és generálják a teljes megfelelő formátumú választ (pl. a nyitólapot, étrend oldalt). Modulok (module): a komponensek által használható egységek, amik egy jól körülírható funkciót tudnak elvégezni és legfeljebb blokk szintű sablont használnak (pl. felhasználói belépő felület és beléptetés). Beépülő modulok (plugin): az előző két csoport által használható, egyszerű kiegészítő működést végző kódok, amik sablont nem generálhatnak, csak adatkezelést végezhetnek (pl. Facebook beléptetés, védelmi funkciók (CSRF, XSS), Captcha kezelés) Keretrendszer részek Application (alkalmazás): a központi elem, minden folyamat elején ez kerül példányosításra és futtatásra. A környezettől függően beállítja a futáshoz szükséges értékeket, konfigurációt, betölti a szükséges keretrendszer részeket, meghatározza a feldolgozást végző egységet, példányosítja és átadja a vezérlést. Ekkor lekezelésre kerül az aktuálisan elvégzendő művelet a specifikus üzleti logika által, majd visszakerül a futás az alkalmazáshoz, mely elvégzi a tényleges kimenet generálást a megfelelő formátumban vagy kezeli az esetleges hibákat. ClassLoader (osztály betöltő): a PHP futása során hivatkozhatunk osztályokra, amik még nem kerültek betöltésre, ekkor egy saját logika alapján megkereshetjük és betölthetjük a szükséges fájlt, ezáltal sokkal kényelmesebb a kódok módosítása, 26

27 átrendezése, hiszen nem kell a betöltendő fájlok elérési útjával játszani, a teljesítmény különbség pedig minimális. A betöltő a PSR-0 [56] szabványt használja. Config (beállítások): a rendszer futásához szükséges beállításokat gyűjtő osztály, rendszerint alkalmazásonként adott egy beállító fájl, melyet az alkalmazás feldolgoz és beállít ebben a statikus osztályban, s a futás további részében lekérdezhetőek belőle az adatok. Error (hibakezelő osztályok): a PHP lehetőséget nyújt arra, hogy átvegyük a hibák és az el nem kapott kivételek lekezelését, az ErrorHandler osztályunk fogja ezt megtenni, de csak éles környezetben, ahol a hibákat syslog-ng-n [57] keresztül fogja adatbázisba küldeni, így a futás során minimális időt vesz igénybe egy hiba jelzése. Exception (kivétel osztályok): a projekthez tartozó kivételek mindenféle témára. Log (naplózás): hibák és egyéb rendszer események naplózása, szintén syslogng-n keresztül, de további naplózó osztályok is készíthetőek, melyek más erőforrással dolgoznak. MVC (Model-View-Controller alapok): tulajdonképpen a komponens, modul és plugin megvalósításához szükséges egységes absztrakt ős osztályok és interfészek: vezérlő és sablonok, a modellek is ide tartoznának, de erről a Propel már gondoskodott. Request (kérés adatainak kezelése): a szuper globális tömböket ($_GET, $_POST, $_COOKIE, $_SERVER, $_FILES) kezelő (elfedő) osztály. Response (válasz kezelése): a válasz fejlécek és magának a küldendő tartalomnak a kezelését végzi. Router (útvonalkezelő meghatározása): az alkalmazás által beállított útvonal választási stratégia alapján meghatározza az adott kérés útvonalához tartozó komponenst, vezérlőt és műveletet, aminek a feldolgozást kell végeznie. 27

28 Language (fordítás): kulcs alapú fordítást tesz lehetővé, így a sablonokban csak a rövid, de értelmes azonosítót szükséges megadni, amennyiben az adott nyelvre még nem létezik, úgy az alapértelmezett nyelven próbálja újból. Validator (adat ellenőrzés): minden bemenő adat illegálisnak tekinthető, amíg egy ellenőrző nem állítja az ellenkezőjét. Az itt lévő osztályok az alapvető méret, intervallum, létezés és típus ellenőrzéseken túl a specifikus adatokat is vizsgálhatóvá teszik: cím, név, IP, lakcím stb. Cache (gyorstár kiszolgálók): az egyszerű CacheInterface set és get metódusát megvalósító osztályok helye, pl. ApcCache, FileCache, MemCache, RepCache, RedisCache, RiakCache. Resource (erőforrás-kezelők): a különböző erőforrásokat kezelő osztályok, pl. adatbázis, repcached, message queue (például RabbitMQ [58]), Redis, Riak stb. Általánosságban két külön rész tartozik egy erőforráshoz, egy kapcsolatkezelő és egy interfész megvalósító osztály, mely a gyakrabban használt parancsokat implementálja. Session (munkamenet-kezelő): egy-egy kliens számára tárol adatokat, a felhasználó típusa szerint a beállító fájlban megadott adattárolót használva pl. vendégek esetén Memcache, regisztrált felhasználó esetén biztonságosabb Redis vagy Riak. User (felhasználó): adat objektum, ami egy felhasználó adatait reprezentálja. Mindig az aktuális munkamenethez tartozik, annak user kulcsa alatt lévő adatok kezeléséért felel. ACL (Access Control List): hozzáférés szabályozás. Főként a felhasználók saját tartamainak védelme, melyet megosztás esetén ők állíthatnak be, olvasási, módosítási jogot adhatnak más felhasználók számára. Mail ( küldés): PHPMailer [59], a legjobb megoldás. 28

29 Export (exportálás más formátumokba): magában foglalja az FPDF-et [60], amivel könnyen konvertálható HTML oldal PDF-be, illetve készíthető tetszőleges PDF a segítségével például letölthető, igényes étrend dokumentum készítéséhez; illetve a TXLS-t, amivel egyszerű, régi, bináris XLS formátumba lehet menteni (saját készítmény). Pattern (tervezési minták): különféle tervezési mintákhoz absztrakt ősosztályok, trait-ek, amikkel az adott minta megvalósítás még egyszerűbb Működés 1. ábra: Egy böngésző kérés lekezelése a keretrendszer szemszögéből Főbb lépések: 1. A kérés beérkezik a webszerverre, ami domain alapján meghatározza a használandó vhostot. A vhost meghatározza a kiszolgáló útvonalat. URL rewrite szabályok megadják, hogyha a kapott URL nem egy valós fájlra vagy könyvtárra mutat, akkor az index.php szolgálja ki a kérést. 2. Az index.php példányosítja az alkalmazásnak megfelelő Application osztályt átadva neki az aktuális alkalmazás gyökerének útvonalát, majd futtatja. 3. Az Application inicializálja a keretrendszer főbb osztályait (osztály betöltő, beállítás-kezelő, hibakezelő), lekezeli az alkalmazáshoz tartozó config, routing és translation fájlokat. A Router segítségével meghatározza a kéréshez tartozó komponens, vezérlő, művelet hármast és ezzel példányosítja 29

30 is a megfelelő vezérlőt, majd átadja neki a feldolgozást az adott művelet meghívásával. 4. A komponens vezérlője tetszőleges műveleteket végez, majd visszatér vagy egy sablonnal, amit generálni kell a kimenetre (HTML formátumban) vagy egy tömbbel, amelyet JSON formában szánunk válaszként. 5. Az Application visszakapja az említett adatokat és elvégzi a szükséges műveleteket vagy hibát kezel, amennyiben történt Kód struktúra A manapság egyre népszerűbb composer ( [54] külső függőségeket kezelő rendszer) által javasolt felépítést használom a legfelső szintek meghatározásához: <gyártó neve>/<termék vagy csomag neve>. Esetemben a MechaRex/DietMaker lesz a konkrét meghatározás, mely könyvtár szinten is realizálódik a MechaRex elnevezésű Mercurial repository-ban. 2. ábra: Étrendkészítő könyvtár struktúrája. 30

31 A következő, harmadik szint egy adminisztrációs szint, ahol még szétválaszthatóak a kód és nem kód jellegű tartalmak, így itt a következő mappák találhatóak: docs: a projekthez tartozó esetleges dokumentumok, ide tartozhat akár domain regisztráció, szolgáltatói szerződés vagy a kódból generált dokumentáció is src: a forráskód, a MechaRex\DietMaker PHP névtér ettől a könyvtártól indul tools: főként konzolból futtatható eszközök, pl. composer, codeception, az élesítő rendszer elemei, bash scriptek vendor: külső függőségek composer által karbantartva, pl. Propel A projekt kódjának felépítése: application: alkalmazások gyűjtője o <alkalmazás név> batch: a projekthez tartozó scriptek, hasonló felépítéssel, mint egy alkalmazás esetén, annyi különbséggel, hogy component helyett a package elnevezést használom és view rész nincs, esetleg később HTML levelek küldésére bekerülhet; továbbá nincs web mappa, helyette a package könyvtárral egy szinten van egy script könyvtár, ahova az index.php-nak megfelelő tetszőleges elnevezésű indítófájlok kerülnek common: közös elemek gyűjtője; az alábbiakban azonos az alkalmazás felépítésével o component o module o plugin framework: a keretrendszer lakhelye media: statikus fájlok helye resource: erőforrás leíró fájlok helye, pl. Apache2 vhost, Propel adatbázisleíró XML fájlok, további használt szolgáltatások beállításai tetszőleges felépítésben Egy alkalmazás felépítése: 31

32 component: komponensek gyűjtője o <komponens név> module: modulok gyűjtője o <modul neve> plugin: beépülő modulok gyűjtője o <plugin neve> include: alkalmazás beállító fájlok gyűjtője o (opcionális) config.php: beállítások o (opcionális) config_<nyelv>.php: nyelvfüggő beállítások o (opcionális) routing.php: útvonal-kezelési stratégia beállítása o (opcionális) routing_<nyelv>.php: nyelvfüggő routing web: az alkalmazás web kiszolgálási gyökere o index.php: az alkalmazás belépési pontja Egy komponens felépítése: controller: vezérlők gyűjtóje o <vezérlő neve> model: üzleti logikák és adatkezelés gyűjtője o data: adatkezelők <adatkezelő osztály neve>.php o logic: üzleti logikák <üzleti logika neve>.php view: felületek gyűjtője o cache: lefordított sablonok helye <nyelv#típus#sablon név>.php o block: blokk sablonok <blokk neve>.tpl o layout: oldalkeret sablonok <keret neve>.tpl o template: oldal tartalmi sablonok <oldal sablon neve>.tpl Egy modul felépítése alkönyvtárakra bontható, kategorizálás céljából: <modul név>.php: a modul vezérlője 32

33 (opcionális) model / data, logic / osztályok view / cache, block / blokk sablon Egy plugin felépítése alkönyvtárakra bontható, kategorizálás céljából: <plugin név>.php: a plugin vezérlője (opcionális) model / data, logic / osztályok A keretrendszer felépítése: egyezik az összetevőkben vázolt részekkel. A média felépítése: <alkalmazás név> o css: less és css fájlok gyűjtője o files: letölthető dokumentumok gyűjtője o images: képanyagok gyűjtője o js: javascript fájlok gyűjtője common: közös, általános statikus fájlok, egyezik a felépítése az előzővel lib: könyvtárak egy-egy komplett funkcióra o <könyvtár neve>: ez alatt egyezik az alkalmazás felépítésével Adatbázis Jelmagyarázat: tábla(elsődleges kulcs, idegen kulcs, egyedi kulcs, oszlop). A projekt indulásához a beállító fájlok és routing kezelése egyszerűbb fájl alapon megoldva, a későbbiekben viszont kényelmesebb lesz egy adminisztrációs felületről állítani ezeket az értékeket, amihez szükség lesz a következő táblákra (amelyekből majd generálni lehet az említett fájlokat): applications(id:int, name:varchar) configuration(id:int, application_id:int, key:varchar) configuration_values(configuration_id:int, language_id:int, value:varchar) A nyelvi fordításhoz kezdetben is szükség lesz az alábbiakra (az eredeti elgondolásom szerint futás időben APC-ben is tárolhatóak ezek az információk, de már jobbnak gondolom fájlba kigenerálni nyelvenként ezzel elkerülve teljesen az adatbázis 33