A Yiituts ötlete még 2012 év elején született, amikor a saját Yii alapú CMS rendszerem fejlesztése során összegyűlt tapasztalatokat szerettem volna megosztani cikkek/tutorialok formájában. Tovább gondolva rájöttem, hogy jó lenne egy kisebb közösségi funkciókkal rendelkező, magyar Yii fejlesztőket összegyűjtő oldal létrehozása. A "yiiframework.hu" domain sajnos már foglalt volt, így összeállt az oldal fő profiljára utaló Yiituts elnevezés.
Friday, March 22, 2013
Magyar Yii Tutorial oldal
Nemreg indult a magyar nyelvu YiiTuts.hu oldal.
Wednesday, February 29, 2012
Az Art-Work.hu története (Murányi S.)
Az Art-Work (http://art-work.hu) története 2007-ben kezdődött el, amikor egy szakdolgozat témájaként jött létre. Mivel én magam is szeretek fotózni, így nem csak a szakdolgozat viszonylag hamar kikerült a netre (deviantart, stockexpert ihletésére). Reklámozni akkoriban csak iwiw-en reklámoztam, illetve készült pár száz szórólap, amit pár városban művészeti iskolákban szórtunk ki.
2007-2009 -ig három verziót élt meg az oldal. A verzió váltás okai a szakmai fejlődésem volt elsősorban.
Az első nagyobb lépés a 2009-ben PRADO-ra váltás volt, amikor már némi web2 is bekerült az oldalba, és mégis csak egy összeszedettebb rendszer volt, mint az addigiak. A PRADO-t nagyon szerettem, mert jó volt használni, megvoltak a megfelelő dolgok, nem kellett semmiben feltalálni a spanyol viaszt.
2009-2011-ig sajnos nem nagyon volt foglalkozva az oldallal az akkori munkahelyem miatt, ezért a felhasználói bázis szép lassan el is felejtette az oldalt. Így az addig összegyűlt 1000 felhasználó és 8000 kép ott maradt.
2011 végén, munkahely váltás után lett szabadidőm ismét, és az akkor már általam használt Yii-ben gondoltam, hogy újra írom az oldalt.
Így az már működik és ismét zajlik az élet :)
A Yii-re azért váltottam PRADO-ról, mert ugyan az MVC nagyon új volt a PRADO felfogásával szemben, ám sebességben olyan szakadék tátongott a kettő között, hogy egyértelmű volt a váltás. Megnyugtató volt számomra, hogy a Yii egyik fejlesztője a PRADO volt alapítója, így egyértelmű volt, hogy minőségi keretrendszer ez is.
Yii-ben kihasználok mindent, amit lehet, de azért pár dolog, aminek nem tetszik a működése, azt inkább magam készítem. Ilyen például az assetek kezelése. Nem szimpatikus, hogy egy mappában random dir-be kerülnek az assetek, és ha kiviszem production-be az alkalmazást, akkor új dir-ek generálódnak. Inkább én belinkelem magamnak, ami éppen kell. Remélem ezt valamikor átalakítják.
Nem szoktam használni a grid-et például, inkább saját foreach ciklust használok, mert felesleges extra lépcsőként tekintek erre a lehetőségre.
Kiegészítettem a rendszert egy saját DataType osztállyal és annak leszármazottjaival, mellyel igyekszem a PHP laza típus kezelését kivédeni. AJAX kommunikációnál és minden klienstől REQUEST-ben érkező adatnál kialakítottam egy DTO (Data Transfer Object) rendszert, ahol előre definiált adatok közlekednek az objektumok között, nem csak feltöltöm a model attributes property-jét a POST-ból érkező adattal. Így pl, mivel külön class-ban van mondjuk egy form-tól várt mezők, jól látható, hogy mi az, és csak az, amit a klienstől várunk. Nagyjából a CFormModel is ezt oldja meg (ha jól tudom), próbáltam is használatát, de kevésbé volt szimpatikus, mint a saját megoldásom.
Ha elakadok, sokszor segít a Yii fórumban keresgélés, de a stackoverflow-n is nagyon sok Yii-s problémára találok megoldást.
Amit viszont örömmel használok a Yii alap lehetőségeiből és letölthető extension-jaiból: EAjaxUpload, urlManager, YiiMail, I18N
Amit még fontosnak tartok megemlíteni, mert sokat könnyít a fejlesztésen, az az, hogy az I18N modult kiegészítettem egy wrapper osztállyal, amit ugyanúgy kell használni, mint a Yii által adott default tool-t, annyi különbséggel, hogy nem kell magunknak belerakni az új fordítandó szavakat az adott dictionary php-ba, hanem magától belerakja, ha még nincs benne, illetve a file-t is létrehozza, ha még nincs. Ez a felfogás a PRADO-ból jött, mert ott is nagyon tetszett, hogy ezt megcsinálja helyettem. Ezt a Yii fórumon meg is osztottam természetesen.
Jelenleg a UNIT tesztek írását készítem, ahol azért néha rájövök, hogy nem teljesen sikerült minden részt tesztelhetőre készíteni. Ezért is alakítottam ki a DTO környzetet például.
-- írta Murányi Sándor
2007-2009 -ig három verziót élt meg az oldal. A verzió váltás okai a szakmai fejlődésem volt elsősorban.
Az első nagyobb lépés a 2009-ben PRADO-ra váltás volt, amikor már némi web2 is bekerült az oldalba, és mégis csak egy összeszedettebb rendszer volt, mint az addigiak. A PRADO-t nagyon szerettem, mert jó volt használni, megvoltak a megfelelő dolgok, nem kellett semmiben feltalálni a spanyol viaszt.
2009-2011-ig sajnos nem nagyon volt foglalkozva az oldallal az akkori munkahelyem miatt, ezért a felhasználói bázis szép lassan el is felejtette az oldalt. Így az addig összegyűlt 1000 felhasználó és 8000 kép ott maradt.
2011 végén, munkahely váltás után lett szabadidőm ismét, és az akkor már általam használt Yii-ben gondoltam, hogy újra írom az oldalt.
Így az már működik és ismét zajlik az élet :)
A Yii-re azért váltottam PRADO-ról, mert ugyan az MVC nagyon új volt a PRADO felfogásával szemben, ám sebességben olyan szakadék tátongott a kettő között, hogy egyértelmű volt a váltás. Megnyugtató volt számomra, hogy a Yii egyik fejlesztője a PRADO volt alapítója, így egyértelmű volt, hogy minőségi keretrendszer ez is.
Yii-ben kihasználok mindent, amit lehet, de azért pár dolog, aminek nem tetszik a működése, azt inkább magam készítem. Ilyen például az assetek kezelése. Nem szimpatikus, hogy egy mappában random dir-be kerülnek az assetek, és ha kiviszem production-be az alkalmazást, akkor új dir-ek generálódnak. Inkább én belinkelem magamnak, ami éppen kell. Remélem ezt valamikor átalakítják.
Nem szoktam használni a grid-et például, inkább saját foreach ciklust használok, mert felesleges extra lépcsőként tekintek erre a lehetőségre.
Kiegészítettem a rendszert egy saját DataType osztállyal és annak leszármazottjaival, mellyel igyekszem a PHP laza típus kezelését kivédeni. AJAX kommunikációnál és minden klienstől REQUEST-ben érkező adatnál kialakítottam egy DTO (Data Transfer Object) rendszert, ahol előre definiált adatok közlekednek az objektumok között, nem csak feltöltöm a model attributes property-jét a POST-ból érkező adattal. Így pl, mivel külön class-ban van mondjuk egy form-tól várt mezők, jól látható, hogy mi az, és csak az, amit a klienstől várunk. Nagyjából a CFormModel is ezt oldja meg (ha jól tudom), próbáltam is használatát, de kevésbé volt szimpatikus, mint a saját megoldásom.
Ha elakadok, sokszor segít a Yii fórumban keresgélés, de a stackoverflow-n is nagyon sok Yii-s problémára találok megoldást.
Amit viszont örömmel használok a Yii alap lehetőségeiből és letölthető extension-jaiból: EAjaxUpload, urlManager, YiiMail, I18N
Amit még fontosnak tartok megemlíteni, mert sokat könnyít a fejlesztésen, az az, hogy az I18N modult kiegészítettem egy wrapper osztállyal, amit ugyanúgy kell használni, mint a Yii által adott default tool-t, annyi különbséggel, hogy nem kell magunknak belerakni az új fordítandó szavakat az adott dictionary php-ba, hanem magától belerakja, ha még nincs benne, illetve a file-t is létrehozza, ha még nincs. Ez a felfogás a PRADO-ból jött, mert ott is nagyon tetszett, hogy ezt megcsinálja helyettem. Ezt a Yii fórumon meg is osztottam természetesen.
Jelenleg a UNIT tesztek írását készítem, ahol azért néha rájövök, hogy nem teljesen sikerült minden részt tesztelhetőre készíteni. Ezért is alakítottam ki a DTO környzetet például.
-- írta Murányi Sándor
Thursday, November 3, 2011
Yii 1.1 Application Development Cookbook (összefoglaló magyarul)
Sajnos irói válságban szenvedek, de szerencsére egyedül vagyok ezzel. Gregnek szerencsére sikerült egy nagyon jó kis összefoglalót írnia a weblabor.hu hasábjain a nemrég megjelent Yii 1.1 Application Development Cookbook-ról:
"Nemrég jelent meg a Packt kiadónál a Yii 1.1 Application Development Cookbook, nyolcvan hasznos recepttel a Yii Frameworkhöz. A szerző az egyik Yii core developer, Alexander Makarov.
A könyv véleményem szerint inkább a Yii Framework alapjaival már tisztában lévő fejlesztőknek szól, viszont ők sokat tanulhatnak belőle. Minden fejezet bővelkedik kódpéldákban, és mindennapi problémákra kínál megoldásokat.
..."
Az egész cikket ide klikkolva lehet megtekinteni.
"Nemrég jelent meg a Packt kiadónál a Yii 1.1 Application Development Cookbook, nyolcvan hasznos recepttel a Yii Frameworkhöz. A szerző az egyik Yii core developer, Alexander Makarov.
A könyv véleményem szerint inkább a Yii Framework alapjaival már tisztában lévő fejlesztőknek szól, viszont ők sokat tanulhatnak belőle. Minden fejezet bővelkedik kódpéldákban, és mindennapi problémákra kínál megoldásokat.
..."
Az egész cikket ide klikkolva lehet megtekinteni.
Sunday, August 28, 2011
Megjelent Nagy Gusztáv - Web Programozás (alapismeretek) című könyve
Egyre többen probálkoznak Web programozással tizenéves gyerekektől egyetemen végzett diákokon át lelkes amatőrökig. A számítógépek, programozási nyelvek, mobil telefonok már már hihetetlen iramú fejlődése naprakész ismerettséget követel minden (webes) programozásra vetemedő egyéntől. De egy biztos. Megéri.
Nagy Gusztáv megpróbálja egy könyvben összefoglalni mi is az a Web- és Web Programozás. Az alap HTML elemektől kezdve, a CSS gyönyörein át a különböző szerverbeállítások fondorlatosságaiba merülhetünk bele, fűszerezve persze szerver oldali programokkal (PHP). Továbbá megtudjuk mi is az a CMS, és megismerhetjük a Keretrendszer fogalmát is (megemlíti a Yii-t is, így került ebbe a blogba ;) )
A könyvet nyugodt szívvel ajánlhatjuk olyanoknak akik még csak most ismerkednek a webes programozással, de olyanoknak is, akik régebben kezdték és szeretnék felfrissjteni/felújitani tudásukat.
Jó könyv, csak így tovább Gusztáv!
Link a könyvhöz.
Nagy Gusztáv megpróbálja egy könyvben összefoglalni mi is az a Web- és Web Programozás. Az alap HTML elemektől kezdve, a CSS gyönyörein át a különböző szerverbeállítások fondorlatosságaiba merülhetünk bele, fűszerezve persze szerver oldali programokkal (PHP). Továbbá megtudjuk mi is az a CMS, és megismerhetjük a Keretrendszer fogalmát is (megemlíti a Yii-t is, így került ebbe a blogba ;) )
A könyvet nyugodt szívvel ajánlhatjuk olyanoknak akik még csak most ismerkednek a webes programozással, de olyanoknak is, akik régebben kezdték és szeretnék felfrissjteni/felújitani tudásukat.
Jó könyv, csak így tovább Gusztáv!
Link a könyvhöz.
Monday, August 1, 2011
Gittegylet meg a Yii - avagy Yiiki 2.0 (4. rész)
Ebben a negyedik és egyben utolsó részben kicsit kifényesítjük a programunkat, olyan finomságokat rakunk majd bele, mint MarkDown-parser (markdown értelmező), WIKI editor és a legvégén pedig megnézzük hogyan lehet a Git (illetve a Github) segítségével forrásunkat publikussá tenni.
Fejlesztéseink közben gyakran fordul elő olyan helyzet, hogy valaki (lehet, hogy mi magunk) valahol máshol (pl. egy másik keretrendszer alatt) már megoldotta a felmerülő problémát és szeretnénk a kódot újra felhasználni. Erre Yii barátunk többféle lehetőséget ad. Használhatunk, kifejezetten Yii-nek szánt kiterjeszések -et (extensions: http://www.yiiframework.com/extensions/ ) vagy teljesen Yii-től független csomagokat. Ilyen például a ZendFramework-be beépített RSS kezelő rendszer. Nekünk jelenleg erre nincs szükségünk, de ha valakit bővebben érdekel, az itten járhat utána: http://www.yiiframework.com/doc/cookbook/20/.
MarkDown
Szerencsénkre Yii már az 1.0-ás verzió óta rendelkezik egy ún. MarkDown osztállyal (CMarkdown) és egy MarkDown widget-tel amit a megjelenítésre fogunk használni. Nyissuk is meg a Nézet file-unkat és módosítsuk:
/protected/views/page/view.php
... és ennyi, a megjelenítés kész is van. A CMarkDown osztályról és használatáról itt lehet bővebben olvasni: http://www.yiiframework.com/doc/api/1.1/CMarkdown
Zii
A Zii nem más mint a hivatalos, Yii fejlesztők által támogatott extension- azaz kiterjesztés könyvtár. Ez együtt érkezik magával a Yii rendszerrel tehát nem kell semmi mást beállítanunk vagy installálnunk. Ezzel szemben van egy YiiExt nem hivatalos kiterjesztés-könyvtár amit innen http://code.google.com/p/yiiext/ lehet elérni. Innen fogjuk mi a markItUp szövegszerkesztőt beállítani, ami szépen megy a már előre felkészített MarkDown tipusú Oldalainkhoz.
Töltsük is le a markit_xx.zip file-t (http://code.google.com/p/yiiext/downloads/detail?name=markitup_1.1.zip&can=2&q=), tömörítsük ki és másoljuk be a legutolsó markitup/ mappát a protected/extensions/ alá. Ha ezzel megvagyunk egyszerűen csak hívjuk meg a widget-et a protected/views/page/_form.php file-ban és állítsuk be a paramétereket:
Ha mindent jól csináltunk akkor valami ilyesmit kell, hogy lássunk ha meglátogatjuk a http://localhost/yiiki2/index.php?r=page/create oldalt:
Maga a WIKI szerkesztőnk már egész jól néz ki, de milyen jó lenne ha a title meg a body feliratok magyarul jelennének meg. Ezt nagyon egyszerűen a Page modell osztályunk attributeLabels() függvényével tehetjük meg.
Github
A Git forráskezelő előretörését nagy mértékben segítette a Github oldal, ami nem más mint egy online kód tároló, ahová teljesen ingyé feltehetjük a kódunkat. Egyébként már a Google is támogatja a Git-et a Mercury meg az SVN mellett. Ha eddig nem tettük volna, az első cikk alapján commit-oljuk a változásainkat, és készítsünk egy fiókot a Github oldalon. Ha ezzel megvagyunk, akkor készítsünk egy new repository-t. Miután beállítottuk az alap paramétereket (csak a név kötelező), az új oldalon csak kövessük végig az utasításokat az Existing Git Repo? rész alatt. Ha minden igaz, valahogy most így nézünk ki:
A programot egyébként itt is meg lehet találni: https://github.com/imehesz/Yiiki2 és a a Github egyik erőssége az ún. fork-olás ami azt jelenti, hogy ha pl. találunk egy hibát a kódban, fork-olhatjuk az eredetit, kijavíthatjuk és jelezhetjük a program készítőjének egy pull-request-tel azaz pull kéréssel, hogy a kód javítva lett, és ha jónak találja, akkor frissítheti az eredeti kódot.
Hát ennyi. Remelém aki végig követte a sorozatot annak sikerült valamit tanulni belőle. Indítottam egy fórum bejegyzést annak akinek segítségre van szüksége, nem ígérem, hogy azonnal de megpróbálok mindenkinek válaszolni. (Akinek meg van kedve segíteni a válaszadásban annak előre is köszönöm)
Fejlesztéseink közben gyakran fordul elő olyan helyzet, hogy valaki (lehet, hogy mi magunk) valahol máshol (pl. egy másik keretrendszer alatt) már megoldotta a felmerülő problémát és szeretnénk a kódot újra felhasználni. Erre Yii barátunk többféle lehetőséget ad. Használhatunk, kifejezetten Yii-nek szánt kiterjeszések -et (extensions: http://www.yiiframework.com/extensions/ ) vagy teljesen Yii-től független csomagokat. Ilyen például a ZendFramework-be beépített RSS kezelő rendszer. Nekünk jelenleg erre nincs szükségünk, de ha valakit bővebben érdekel, az itten járhat utána: http://www.yiiframework.com/doc/cookbook/20/.
MarkDown
Szerencsénkre Yii már az 1.0-ás verzió óta rendelkezik egy ún. MarkDown osztállyal (CMarkdown) és egy MarkDown widget-tel amit a megjelenítésre fogunk használni. Nyissuk is meg a Nézet file-unkat és módosítsuk:
/protected/views/page/view.php
... és ennyi, a megjelenítés kész is van. A CMarkDown osztályról és használatáról itt lehet bővebben olvasni: http://www.yiiframework.com/doc/api/1.1/CMarkdown
Zii
A Zii nem más mint a hivatalos, Yii fejlesztők által támogatott extension- azaz kiterjesztés könyvtár. Ez együtt érkezik magával a Yii rendszerrel tehát nem kell semmi mást beállítanunk vagy installálnunk. Ezzel szemben van egy YiiExt nem hivatalos kiterjesztés-könyvtár amit innen http://code.google.com/p/yiiext/ lehet elérni. Innen fogjuk mi a markItUp szövegszerkesztőt beállítani, ami szépen megy a már előre felkészített MarkDown tipusú Oldalainkhoz.
Töltsük is le a markit_xx.zip file-t (http://code.google.com/p/yiiext/downloads/detail?name=markitup_1.1.zip&can=2&q=), tömörítsük ki és másoljuk be a legutolsó markitup/ mappát a protected/extensions/ alá. Ha ezzel megvagyunk egyszerűen csak hívjuk meg a widget-et a protected/views/page/_form.php file-ban és állítsuk be a paramétereket:
Ha mindent jól csináltunk akkor valami ilyesmit kell, hogy lássunk ha meglátogatjuk a http://localhost/yiiki2/index.php?r=page/create oldalt:
Maga a WIKI szerkesztőnk már egész jól néz ki, de milyen jó lenne ha a title meg a body feliratok magyarul jelennének meg. Ezt nagyon egyszerűen a Page modell osztályunk attributeLabels() függvényével tehetjük meg.
Github
A Git forráskezelő előretörését nagy mértékben segítette a Github oldal, ami nem más mint egy online kód tároló, ahová teljesen ingyé feltehetjük a kódunkat. Egyébként már a Google is támogatja a Git-et a Mercury meg az SVN mellett. Ha eddig nem tettük volna, az első cikk alapján commit-oljuk a változásainkat, és készítsünk egy fiókot a Github oldalon. Ha ezzel megvagyunk, akkor készítsünk egy new repository-t. Miután beállítottuk az alap paramétereket (csak a név kötelező), az új oldalon csak kövessük végig az utasításokat az Existing Git Repo? rész alatt. Ha minden igaz, valahogy most így nézünk ki:
A programot egyébként itt is meg lehet találni: https://github.com/imehesz/Yiiki2 és a a Github egyik erőssége az ún. fork-olás ami azt jelenti, hogy ha pl. találunk egy hibát a kódban, fork-olhatjuk az eredetit, kijavíthatjuk és jelezhetjük a program készítőjének egy pull-request-tel azaz pull kéréssel, hogy a kód javítva lett, és ha jónak találja, akkor frissítheti az eredeti kódot.
Hát ennyi. Remelém aki végig követte a sorozatot annak sikerült valamit tanulni belőle. Indítottam egy fórum bejegyzést annak akinek segítségre van szüksége, nem ígérem, hogy azonnal de megpróbálok mindenkinek válaszolni. (Akinek meg van kedve segíteni a válaszadásban annak előre is köszönöm)
Tuesday, July 26, 2011
Gittegylet meg a Yii - avagy Yiiki 2.0 (3. rész)
Akik még mindig olvassák ezt a cikk sorozatot, azoknak KÖSZI. Akik csak most probálkoznak bekapcsolódni, azoknak mindenképp ajánlom az előző két rész elolvasását hiszen ott ismerkedtünk meg olyan dolgokkal mint a yiic parancs, Git forráskezelő és a Gii kódgeneráló.
Az előző részt ott fejeztük be, hogy a Gii segítségével elkészítettük a Page modell osztályunkat a pages táblához. Ha most megnézzük, hogy hogy áll a forrásunkat (git status) akkor láthatjuk, hogy egy Page.php file jött létre a protected/model/ mappán belül. Ezt hozzá is adhatjuk a szokásos git add paranccsal. (A Git-ről itt van egy leírás magyarul a BME oldalain. Ebben a cikk sorozatban már csak a végén vesszük elő mégegyszer, amikor publikáljuk a programunkat).
CRUD
Azzal, hogy elkészítettük a Page modellünket, még semmi, böngészőben látható eredményt nem sikerült produkálnunk. Itt jön a CRUD a képbe,
Create - Létrehoz
Read - (Be)olvas
Update - Frissít
Delete - Töröl
Most megint vegyük elő a varázságyúnkat (Gii) és belépés után kattintsunk a Crud Generator linkre. Ha minden igaz, egy két mezős form-ot kell kapnunk, ahol valójában elég csak az első mezőt kitölteni a Model Class-t azaz Modell Osztáy-t, a Controller ID-t a Gii magától kitalálja. Jó mi? (Megj: a Base Controller Class és a Code Template útvonal is átírható, így ezek segítségével ha akarjuk teljesen újraírhatjuk a Gii viselkedését.)
Tehát írjuk be a Model Class-be, hogy Page és nyomjuk meg (csak egyszer!) a Preview gombot. Ha valami ilyesmit látunk akkor örülhetünk:
Itt már lényegesen több file fog elkészülni mint a modell létrehozásánál. Láthatjuk, hogy maga a Controller (vezérlő) is elkészül majd, a view/page mappa is, ahol a rendszer fogja tárolni a szükséges nézet file-okat (create.php, update.php, view.php stb). Ha minden OK, nyomhatunk a Generate-ra.
A programunk jelenlegi állapotában már mindenre kész. Tudunk oldalakat listázni, készíteni és törölni. Hogy megbizonyosodjunk róla, böngészőnkkel látogassuk meg a következő URL-t:
http://localhost/index.php?r=page
Na de mi nem elégszünk meg ennyivel, hiszen egy igazi Wiki-t szeretnénk készíteni. Jöhet a testreszabás ...
Testreszabás
Beviteli form módosítása
Ha most probálnánk egy Page-t azaz Oldalt készíteni (http://localhost/index.php?r=page/create), akkor azonnal észlelnénk, hogy a beviteli form-on egy csomó olyan mező van, amit nem szeretnénk kézzel minden egyes alkalommal kitölteni, illetve elvárnánk a programunktól, hogy saját maga töltse ki. Ilyen például a created vagy a revision mező.
Módosítsuk is a form-unkat valahogy így:
A Page Modell Szabályainak Beállítésai
A Page (Oldal) modellünkre is ráfér egy kis farigcsálás. Ugyan Gii többnyire kitalálta, hogy milyen szabályokat hozzon létre a különböző form mezőkhöz, a gondolatolvasástól azért még messze van.
Mi ugyanis szeretnénk, ha az Oldalunk címébe csakis betűk, számok, vagy aláhúzás jel szerepelhessen. (Egy jó kis bővítés lenne, ha a programunk automatikusan felülírná a bevitt a címet, de az példa kedvéért itt egy szabályt hozunk létre)
protected/models/Page.php
Az itt használt szabályok elég egyértelműek, de ha valaki jobban bele szeretne mélyülni itt olvashat róluk bővebben: http://www.yiiframework.com/doc/cookbook/56/
Itt még azt is megfigyelhetjük, hogy hogyan kell a programunkat magyarul tanítani ;)
A beforeSave() and save() modell függvények használata/felülírása
A modelljeink, amik a programunkban az adatbázis lekérdezéseket kezelik, mindenféle függyvényekkel fel vannak fegyverkezve, hogy nekünk ne kelljen védőkesztyű nélkül SQL-kódban kotorászni. Az egyik ilyen függvény a save() (mentés) és hű csatlósa a beforeSave() (mentés elött elment). A save() egy adatbázis rekordot köteles elmenteni vagy felülírni.
A pages adatbázis táblánkban van egy olyan mező, hogy created (készítve), ami egy dátum mező. (a példánkban UNIX Timestamp-et használunk!) Ez a mező tartja nyilván, hogy az adott oldal mikor lett készítve/felülírva. Ugyan használhatnánk a save() függvényt arra, hogy ezt az értéket beállítsuk, a példa kedvéért ezt a beforeSave()-vel oldjuk meg.
(Az fontos, hogy itt a szülő beforeSave()-jével térjünk vissza, return parent::beforeSave() )
protected/models/Page.php
Néha előfordul, hogy még a form mezők ellenőrzése elött szeretnénk beállítani valamilyen értéket, ezt a beforeValidate() funkcióval tehetjük meg.
A save() függvénynél már kicsit más a helyzet. Először vegyük sorra, hogy mit is szeretnénk a programunktól, amikor elmentünk egy oldalt. Ha minden igaz, említettük az elején, hogy a jövőben szeretnénk egy revert opciót, ami annyit jelent, hogy az odalalainkat, ha akarjuk, visszaállíthatjuk egy korábbi változatba. Ezt többféle módon is meg lehet valósítani, de talán a legrövidebb megoldás, ha az oldalakat mindig újként mentjük el, és csak növeljük a revision azaz verziószámot.
protected/models/Page.php
A Yii modell osztálya olyan finomságokkal lát el bennünket, mint például a $this->isNewRecord ami egyszerűen megmondja nekünk, hogy most egy új rekordról van e szó, vagy csak felülírunk egyet. Mi persze tudjuk, hogy nekünk arra van szükségünk, hogy minden egyes oldal újként legyen elmentve, tehát ha az oldal nem új, akkor egyszerűen gyártunk egyet ami a $newpage->attributes=$this->attributes segítségével felveszi az eredeti oldal értékeit.
Még annyit érdemes megjegyezni, hogy ha a save() függvényt false paraméterrel hívjuk meg, akkor az ActiveRecord-ban beállított szabályai nem vonatkoznak az adott rekordra.
Az Oldalak-at lekérő SQL módosítása és a hozzá tartozó Nézet (View) beállítása
Ha most néznénk meg az Oldalak listáját, azt vennénk észre, hogy programunk, az egyes Oldalakhoz tartozó összes reviziót megmutatja. Ez ideáig rendben is van, hiszen minden egyes változatot "új"-ként mentettünk el, azonban ez elég zavaró lehet, meg bugyután is néz ki. Ha eddig még nem említettük volna, majd minden Controller osztálynak van egy úgynevezett actionIndex()-je ami az alapértelmezett függvény. Jelen esetünkben ez szolgáltatja az Oldalak listáját. Keressük is meg a PageController-ben és módosítsuk a következők szerint:
protected/controllers/PageController.php - actionIndex()
SQL-ben valamennyire jártasabbak egyből kiszúrhatják, hogy mi is történik. Itt létrehozunk egy úgynevezett CDBCriteria() osztályt aminek segítségével különböző SQL paramétereket állíthatunk be, és ez által módosíthatjuk a lekérdezéseinket, ami ebben az esetben az Oldalak csoportosítását jelenti a title azaz cím szerint, és rendezést a létrehozás dátuma szerint.
Az alábbi file-okat pedig módosítsuk izlésünk szerint (illetve az én izlésem szerint). Ha még emlékszünk, a PageController-t kicsit átalakítottuk, hogy az adott Oldal azonosító ID-ja helyett a title mező értékével dolgozzon. Ez nagyon szép és jó, de a program többi részét is kicsit át kell alakítanunk. Ilyen például az actionCreate() és actionUpdate() funkciókban használt redirect() ami azt a célt szolgálja, hogy bizonyos események után böngészőnket egy meghatározott oldalra küldje.
protected/controllers/PageController.php
A következő file-ok pedig a megjelenítést szolgálják ...
protected/views/page/_view.php
protected/views/page/view.php
Jajj de jó, már lassan készen is vagyunk. Mondjuk a megjelenített oldal egyáltalán nem úgy néz ki mint egy igazi Wiki oldal. A következő részben megnézzük, hogyan használjuk a Yii-be alapból beépített MarkDown értelmezőt, hogy megússzuk a sok str_replace()-t ;)
Mivel a Wiki alkalmazásunk elég speciális (ID-k helyett a cím alapján találunk meg egy-egy Oldalt), ezért a Page vezérlőnkben elég sok minden változott,úgyhogy a teljesség kedvéért ide betettük az egész osztályt.
Az előző részt ott fejeztük be, hogy a Gii segítségével elkészítettük a Page modell osztályunkat a pages táblához. Ha most megnézzük, hogy hogy áll a forrásunkat (git status) akkor láthatjuk, hogy egy Page.php file jött létre a protected/model/ mappán belül. Ezt hozzá is adhatjuk a szokásos git add paranccsal. (A Git-ről itt van egy leírás magyarul a BME oldalain. Ebben a cikk sorozatban már csak a végén vesszük elő mégegyszer, amikor publikáljuk a programunkat).
CRUD
Azzal, hogy elkészítettük a Page modellünket, még semmi, böngészőben látható eredményt nem sikerült produkálnunk. Itt jön a CRUD a képbe,
Create - Létrehoz
Read - (Be)olvas
Update - Frissít
Delete - Töröl
Most megint vegyük elő a varázságyúnkat (Gii) és belépés után kattintsunk a Crud Generator linkre. Ha minden igaz, egy két mezős form-ot kell kapnunk, ahol valójában elég csak az első mezőt kitölteni a Model Class-t azaz Modell Osztáy-t, a Controller ID-t a Gii magától kitalálja. Jó mi? (Megj: a Base Controller Class és a Code Template útvonal is átírható, így ezek segítségével ha akarjuk teljesen újraírhatjuk a Gii viselkedését.)
Tehát írjuk be a Model Class-be, hogy Page és nyomjuk meg (csak egyszer!) a Preview gombot. Ha valami ilyesmit látunk akkor örülhetünk:
Itt már lényegesen több file fog elkészülni mint a modell létrehozásánál. Láthatjuk, hogy maga a Controller (vezérlő) is elkészül majd, a view/page mappa is, ahol a rendszer fogja tárolni a szükséges nézet file-okat (create.php, update.php, view.php stb). Ha minden OK, nyomhatunk a Generate-ra.
A programunk jelenlegi állapotában már mindenre kész. Tudunk oldalakat listázni, készíteni és törölni. Hogy megbizonyosodjunk róla, böngészőnkkel látogassuk meg a következő URL-t:
http://localhost/index.php?r=page
Na de mi nem elégszünk meg ennyivel, hiszen egy igazi Wiki-t szeretnénk készíteni. Jöhet a testreszabás ...
Testreszabás
Beviteli form módosítása
Ha most probálnánk egy Page-t azaz Oldalt készíteni (http://localhost/index.php?r=page/create), akkor azonnal észlelnénk, hogy a beviteli form-on egy csomó olyan mező van, amit nem szeretnénk kézzel minden egyes alkalommal kitölteni, illetve elvárnánk a programunktól, hogy saját maga töltse ki. Ilyen például a created vagy a revision mező.
Módosítsuk is a form-unkat valahogy így:
A Page Modell Szabályainak Beállítésai
A Page (Oldal) modellünkre is ráfér egy kis farigcsálás. Ugyan Gii többnyire kitalálta, hogy milyen szabályokat hozzon létre a különböző form mezőkhöz, a gondolatolvasástól azért még messze van.
Mi ugyanis szeretnénk, ha az Oldalunk címébe csakis betűk, számok, vagy aláhúzás jel szerepelhessen. (Egy jó kis bővítés lenne, ha a programunk automatikusan felülírná a bevitt a címet, de az példa kedvéért itt egy szabályt hozunk létre)
protected/models/Page.php
Az itt használt szabályok elég egyértelműek, de ha valaki jobban bele szeretne mélyülni itt olvashat róluk bővebben: http://www.yiiframework.com/doc/cookbook/56/
Itt még azt is megfigyelhetjük, hogy hogyan kell a programunkat magyarul tanítani ;)
A beforeSave() and save() modell függvények használata/felülírása
A modelljeink, amik a programunkban az adatbázis lekérdezéseket kezelik, mindenféle függyvényekkel fel vannak fegyverkezve, hogy nekünk ne kelljen védőkesztyű nélkül SQL-kódban kotorászni. Az egyik ilyen függvény a save() (mentés) és hű csatlósa a beforeSave() (mentés elött elment). A save() egy adatbázis rekordot köteles elmenteni vagy felülírni.
A pages adatbázis táblánkban van egy olyan mező, hogy created (készítve), ami egy dátum mező. (a példánkban UNIX Timestamp-et használunk!) Ez a mező tartja nyilván, hogy az adott oldal mikor lett készítve/felülírva. Ugyan használhatnánk a save() függvényt arra, hogy ezt az értéket beállítsuk, a példa kedvéért ezt a beforeSave()-vel oldjuk meg.
(Az fontos, hogy itt a szülő beforeSave()-jével térjünk vissza, return parent::beforeSave() )
protected/models/Page.php
Néha előfordul, hogy még a form mezők ellenőrzése elött szeretnénk beállítani valamilyen értéket, ezt a beforeValidate() funkcióval tehetjük meg.
A save() függvénynél már kicsit más a helyzet. Először vegyük sorra, hogy mit is szeretnénk a programunktól, amikor elmentünk egy oldalt. Ha minden igaz, említettük az elején, hogy a jövőben szeretnénk egy revert opciót, ami annyit jelent, hogy az odalalainkat, ha akarjuk, visszaállíthatjuk egy korábbi változatba. Ezt többféle módon is meg lehet valósítani, de talán a legrövidebb megoldás, ha az oldalakat mindig újként mentjük el, és csak növeljük a revision azaz verziószámot.
protected/models/Page.php
A Yii modell osztálya olyan finomságokkal lát el bennünket, mint például a $this->isNewRecord ami egyszerűen megmondja nekünk, hogy most egy új rekordról van e szó, vagy csak felülírunk egyet. Mi persze tudjuk, hogy nekünk arra van szükségünk, hogy minden egyes oldal újként legyen elmentve, tehát ha az oldal nem új, akkor egyszerűen gyártunk egyet ami a $newpage->attributes=$this->attributes segítségével felveszi az eredeti oldal értékeit.
Még annyit érdemes megjegyezni, hogy ha a save() függvényt false paraméterrel hívjuk meg, akkor az ActiveRecord-ban beállított szabályai nem vonatkoznak az adott rekordra.
Az Oldalak-at lekérő SQL módosítása és a hozzá tartozó Nézet (View) beállítása
Ha most néznénk meg az Oldalak listáját, azt vennénk észre, hogy programunk, az egyes Oldalakhoz tartozó összes reviziót megmutatja. Ez ideáig rendben is van, hiszen minden egyes változatot "új"-ként mentettünk el, azonban ez elég zavaró lehet, meg bugyután is néz ki. Ha eddig még nem említettük volna, majd minden Controller osztálynak van egy úgynevezett actionIndex()-je ami az alapértelmezett függvény. Jelen esetünkben ez szolgáltatja az Oldalak listáját. Keressük is meg a PageController-ben és módosítsuk a következők szerint:
protected/controllers/PageController.php - actionIndex()
SQL-ben valamennyire jártasabbak egyből kiszúrhatják, hogy mi is történik. Itt létrehozunk egy úgynevezett CDBCriteria() osztályt aminek segítségével különböző SQL paramétereket állíthatunk be, és ez által módosíthatjuk a lekérdezéseinket, ami ebben az esetben az Oldalak csoportosítását jelenti a title azaz cím szerint, és rendezést a létrehozás dátuma szerint.
Az alábbi file-okat pedig módosítsuk izlésünk szerint (illetve az én izlésem szerint). Ha még emlékszünk, a PageController-t kicsit átalakítottuk, hogy az adott Oldal azonosító ID-ja helyett a title mező értékével dolgozzon. Ez nagyon szép és jó, de a program többi részét is kicsit át kell alakítanunk. Ilyen például az actionCreate() és actionUpdate() funkciókban használt redirect() ami azt a célt szolgálja, hogy bizonyos események után böngészőnket egy meghatározott oldalra küldje.
protected/controllers/PageController.php
A következő file-ok pedig a megjelenítést szolgálják ...
protected/views/page/_view.php
protected/views/page/view.php
Jajj de jó, már lassan készen is vagyunk. Mondjuk a megjelenített oldal egyáltalán nem úgy néz ki mint egy igazi Wiki oldal. A következő részben megnézzük, hogyan használjuk a Yii-be alapból beépített MarkDown értelmezőt, hogy megússzuk a sok str_replace()-t ;)
Mivel a Wiki alkalmazásunk elég speciális (ID-k helyett a cím alapján találunk meg egy-egy Oldalt), ezért a Page vezérlőnkben elég sok minden változott,úgyhogy a teljesség kedvéért ide betettük az egész osztályt.
Tuesday, July 19, 2011
Gittegylet meg a Yii - avagy Yiiki 2.0 (2. rész)
Az első részben elkészítettük a Yiiki 2.0 alkalmazásunk alapjául szolgáló keretünket a Yii segítségével és megismerkedtünk a Git forráskezelővel. Ebben részben először kicsit átírjuk a belépő index.php file-t, elkészítjük az adatbázisunkat a Yii-be épített migráció kezelővel, majd létrehozzuk a Modell osztályunkat Gii-vel, a Yii kódgeneráló varázságyújával (tényleg az).
Amikor az alkalmazásunkat létrehoztuk a yiic paranccsal, maga a Yii készített nekünk egy konfigurációs file-t a protected/config/ alatt main.php néven. Természetesen használhatnánk ezt a file-t úgy ahogy van, de igazából nem szerencsés a rendszer kofigurációs adatait a forráskezelő alá tenni, hiszen a beállítások mások lesznek különböző környezetek alatt (pl. fejlesztői, éles stb), sőt az adatbázis kapcsolathoz szükséges felhasználó és jelszó is ebben a file-ban van. Erre a problémára természetesen többféle megoldás is lehet, itt csak egyet mutatunk be.
Első lépésként másoljuk a protected/config/main.php -t development.config.php -ra:
$cp protected/config/main.php protected/config/development.config.php
Ha most git stat-tal megnéznénk, hogy hogyan is áll a forráskódunk, látnánk, hogy a git azt jelzi, hogy van egy új file-unk. Mi persze nem szeretnénk a konfigurációs file-t a forráskezelő alá helyezni, ezért tegyük is a .gitignore file-ba.
Belépő script módosítása
Most kedvenc kódszerkesztőnk segítségével (ami nyilván VIM), nyissuk meg az index.php file-t és módosítsuk a követlkező képpen.
Ezzel csupán azt értük el, hogy amikor ha a YII_DEBUG konstanst true-ra állítjuk, akkor programunk a development.config.php-t fogja betölteni, egyébként pedig a production.config.php-t amit majd később az éles, mindenki által elérhető szerveren fogunk használni.
Adatbázis Migrációk
Migrációkról más esett szó ezen a blogon, igaz akkor még egy különálló modulként kellett installálni, de szerencsére ez mára már a Yii, pontosabban a yiic része. Röviden arról van szó, hogy könnyebb hordozhatóság kedvéért az adatbázis táblákat migrációs osztályok és tömbök segítségével készítjük el.
Jelenleg, mivel az eredeti main.php konfigurációs file-t másoltuk át development.config.php-re, adatbázisunk még mindig a testdrive.db. Ezzel sajna nem sokra megyünk, úgyhogy állítsuk is át valami másra, pl:
'components' => array(
...
'db'=>array(
'connectionString' => 'sqlite:'.dirname(__FILE__).'/../data/yiiki2.db.sqlite',
),
...
),
Ugyanezt tegyük meg a protected/config/console.php file-ban is, hiszen a migrácókat készítő yiic parancs innen olvassa be az adatbázis hozzáférési adatait.
Már nincs más hátra mint előre, készítsük el a táblánkat az adatbázisban (a yiiki2/ mappában adjuk ki a következő parancsot):
$./protected/yiic migrate create pages_tabla_letrehozasa
Yii Migration Tool v1.0 (based on Yii v1.1.8)
Create new migration '/var/www/yiiki2/protected/migrations/m110710_033230_pages_tabla_hozzaadasa.php'? [yes|no]
Mondjuk neki, you 'y' (igen) és ha minden igaz, akkor egy a megerősítő "New migration created successfully." - üzenetet kapjuk vissza. HURRÁ! Ezzel egy új file került létrehozásra a protected/migrations alatt valami hasonló névvel: m110710_033230_pages_tabla_hozzaadasa.php. Itt az 'm' csak azt jelzi, hogy ez egy migráció, az utána következő számsorozat pedig a migráció sorszáma, majd a név amit megadtunk.
Nyissuk is meg ezt a file-t és módosítsuk a következők szerint:
Ezzel elkészítettük az új migrációs lépést, de még le is kell futtassuk, hogy a táblánk magában az adatbázisban is megjelenjen:
$ ./protected/yiic migrate
Yii Migration Tool v1.0 (based on Yii v1.1.8)
Creating migration history table "tbl_migration"...done.
Total 1 new migration to be applied:
m110710_033230_pages_tabla_hozzaadasa
Apply the above migration? [yes|no]
Ez csak azt jelenti nekünk, hogy ez a Yii Migrációs Eszköz 1.0-ás változata, a Yii 1.1.8-ra épül és jelenleg 1 migrációs lépést lehet végrehajtani a pages_tabla_letrehozasa -t. Mondjuk neki, hogy 'y' vagy 'yes'. Ha miden jól sikerült valami hasonlót kell, hogy lássunk:
*** applying m110710_033230_pages_tabla_hozzaadasa
> create table pages ... done (time: 0.201s)
*** applied m110710_033230_pages_tabla_hozzaadasa (time: 0.054s)
Migrated up successfully.
Ez kb. annyit jelent, hogy minden OK. Csak egy megjegyzés - ugyan ebben a cikkben nem fogunk többet a migrációkkal foglalkozni, érdemes őket tanulmányozni, hiszen nagyon sok mindenben segítséget nyújthatnak. Páldául ha az idegen kulcsokat (foreign-keys) a táblák között megfelelően beállítjuk, Yii automatikusan összeköti Modell osztályainkat a használandó BELONGS_TO, HAS_ONE stb. kapcsolatokkal. Persze ezt kézzel is be tudjuk állítani, de mennyivel egyszerűbb amikor nem kell gépelni ... elvégre is lusta programozók lennénk, vagy mi fene.
Mivel jelenleg egyedül programozunk ez a lépés elhanyagolható, de a példa gyakorlás kedvéért érdemes magát az új migrációs lépést egyből a forráskezelő alá tenni, hogy "csapattársaink" is frissíthessék az adatbázisaikat. Használjuk a git status-t és a git add-et és persze a git commit-ot :)
Gii Gii Gii Giiiiiiiii
Ha annak idején a yiic-et a Yii varázspálcájának hívtuk, a Gii-t joggal nevezhetjük varázságyúnak. Egy nagyon egyszerű de szexi, böngészőn keresztül futtatható kód generáló eszközről van szó, ami szépen felgyorsítja a programozást. Azoknak akik meg nyöszörögnek (mert akadnak páran), hogy túl sok a varázslás meg a mágia, vissza lehet menni saját keretrendszert barkácsolni. Sok szerencsét.
A Gii ugyan együtt érkezik a rendszerrel de biztonsági okok miatt alapból ki van kapcsolva. Nyissuk meg a konfigurációs file-unkat és keressünk rá a gii szóra a modules tömb környékén. Ha megvan, nyilván szedjük ki a /* ... */-t, és állítsunk be egy jelszavat (password), mondjuk: giiros -ra (vicces mi? haha).
Most látogassuk meg a Gii eszközt egy böngészőben ezen a URL-en: http://localhost/yiiki2/index.php?r=gii. Ha mindent jól csináltunk akkor a Yii Code Generator-nak kell megjelennie (ez a Gii) és egy jelszót bekérő form mezőnek. Büszkén írjuk is be a jelszavunkat (tudod, a giiros). Itt már láthatjuk is a köszöntő oldalt ami röviden annyit közöl, hogy a Kód Generáló segítségével gyorsan felépíthetjük a Yii alkalmazásunkat. És tényleg ... Elsőként tanácsos a Modell-t elkészítenünk, hiszen ez köti össze az adatbázisunkat a programmal. Klikkoljunk is rája:
A tablePrefix-szel most ne foglalkozzunk, mert nem állítottuk be, viszont a tábla nevét (Table Name) töltsük ki azaz írjuk be, hogy: pages - (hiszen ez volt a táblánk neve). Gii elvileg okosan megpróbálja kitalálni, hogy mi lesz (legyen) a Modell osztály elnevezése ... Majdnem jó is, én személy szerinte egyes számba szoktam tenni a Modell-jeimet (tehát pl: Page a Pages helyett). A többi értéket hagyhatjuk úgy ahogy van, és kattinthatunk az Előnézet (Preview) gombra.
Remélhetőleg egy új file név jelenik meg alul: models/Page.php. Ha erre a link-re kattintunk, akkor meggyőződhetünk róla, hogy igen, a mezők mind itt vannak és nyomhatunk egyet a Generate gombra. Ha jó Atyánk és a jogosultságok is úgy akarják, akkor a Page Modell osztályunk elészült a models/ mappa alatt.
Hát ennyi fért így a második részbe, elég sok mindent átvettünk, persze tudom, lehetne még ezt azt jobban részletezni, de a cikk célja inkább csak amolyan ismertetés féle. A következő részben használni fogjuk a Gii eszköz CRUD generáló finomságát, ami elkészíti majd nekünk a Kontroller és Nézet file-okat, az alap Create, Update, Read, Delete funkciókkal. Ja, és talán majd gépelni is fogunk egy kicsit ;)
Amikor az alkalmazásunkat létrehoztuk a yiic paranccsal, maga a Yii készített nekünk egy konfigurációs file-t a protected/config/ alatt main.php néven. Természetesen használhatnánk ezt a file-t úgy ahogy van, de igazából nem szerencsés a rendszer kofigurációs adatait a forráskezelő alá tenni, hiszen a beállítások mások lesznek különböző környezetek alatt (pl. fejlesztői, éles stb), sőt az adatbázis kapcsolathoz szükséges felhasználó és jelszó is ebben a file-ban van. Erre a problémára természetesen többféle megoldás is lehet, itt csak egyet mutatunk be.
Első lépésként másoljuk a protected/config/main.php -t development.config.php -ra:
$cp protected/config/main.php protected/config/development.config.php
Ha most git stat-tal megnéznénk, hogy hogyan is áll a forráskódunk, látnánk, hogy a git azt jelzi, hogy van egy új file-unk. Mi persze nem szeretnénk a konfigurációs file-t a forráskezelő alá helyezni, ezért tegyük is a .gitignore file-ba.
Belépő script módosítása
Most kedvenc kódszerkesztőnk segítségével (ami nyilván VIM), nyissuk meg az index.php file-t és módosítsuk a követlkező képpen.
Ezzel csupán azt értük el, hogy amikor ha a YII_DEBUG konstanst true-ra állítjuk, akkor programunk a development.config.php-t fogja betölteni, egyébként pedig a production.config.php-t amit majd később az éles, mindenki által elérhető szerveren fogunk használni.
Adatbázis Migrációk
Migrációkról más esett szó ezen a blogon, igaz akkor még egy különálló modulként kellett installálni, de szerencsére ez mára már a Yii, pontosabban a yiic része. Röviden arról van szó, hogy könnyebb hordozhatóság kedvéért az adatbázis táblákat migrációs osztályok és tömbök segítségével készítjük el.
Jelenleg, mivel az eredeti main.php konfigurációs file-t másoltuk át development.config.php-re, adatbázisunk még mindig a testdrive.db. Ezzel sajna nem sokra megyünk, úgyhogy állítsuk is át valami másra, pl:
'components' => array(
...
'db'=>array(
'connectionString' => 'sqlite:'.dirname(__FILE__).'/../data/yiiki2.db.sqlite',
),
...
),
Ugyanezt tegyük meg a protected/config/console.php file-ban is, hiszen a migrácókat készítő yiic parancs innen olvassa be az adatbázis hozzáférési adatait.
Már nincs más hátra mint előre, készítsük el a táblánkat az adatbázisban (a yiiki2/ mappában adjuk ki a következő parancsot):
$./protected/yiic migrate create pages_tabla_letrehozasa
Yii Migration Tool v1.0 (based on Yii v1.1.8)
Create new migration '/var/www/yiiki2/protected/migrations/m110710_033230_pages_tabla_hozzaadasa.php'? [yes|no]
Mondjuk neki, you 'y' (igen) és ha minden igaz, akkor egy a megerősítő "New migration created successfully." - üzenetet kapjuk vissza. HURRÁ! Ezzel egy új file került létrehozásra a protected/migrations alatt valami hasonló névvel: m110710_033230_pages_tabla_hozzaadasa.php. Itt az 'm' csak azt jelzi, hogy ez egy migráció, az utána következő számsorozat pedig a migráció sorszáma, majd a név amit megadtunk.
Nyissuk is meg ezt a file-t és módosítsuk a következők szerint:
Ezzel elkészítettük az új migrációs lépést, de még le is kell futtassuk, hogy a táblánk magában az adatbázisban is megjelenjen:
$ ./protected/yiic migrate
Yii Migration Tool v1.0 (based on Yii v1.1.8)
Creating migration history table "tbl_migration"...done.
Total 1 new migration to be applied:
m110710_033230_pages_tabla_hozzaadasa
Apply the above migration? [yes|no]
Ez csak azt jelenti nekünk, hogy ez a Yii Migrációs Eszköz 1.0-ás változata, a Yii 1.1.8-ra épül és jelenleg 1 migrációs lépést lehet végrehajtani a pages_tabla_letrehozasa -t. Mondjuk neki, hogy 'y' vagy 'yes'. Ha miden jól sikerült valami hasonlót kell, hogy lássunk:
*** applying m110710_033230_pages_tabla_hozzaadasa
> create table pages ... done (time: 0.201s)
*** applied m110710_033230_pages_tabla_hozzaadasa (time: 0.054s)
Migrated up successfully.
Ez kb. annyit jelent, hogy minden OK. Csak egy megjegyzés - ugyan ebben a cikkben nem fogunk többet a migrációkkal foglalkozni, érdemes őket tanulmányozni, hiszen nagyon sok mindenben segítséget nyújthatnak. Páldául ha az idegen kulcsokat (foreign-keys) a táblák között megfelelően beállítjuk, Yii automatikusan összeköti Modell osztályainkat a használandó BELONGS_TO, HAS_ONE stb. kapcsolatokkal. Persze ezt kézzel is be tudjuk állítani, de mennyivel egyszerűbb amikor nem kell gépelni ... elvégre is lusta programozók lennénk, vagy mi fene.
Mivel jelenleg egyedül programozunk ez a lépés elhanyagolható, de a példa gyakorlás kedvéért érdemes magát az új migrációs lépést egyből a forráskezelő alá tenni, hogy "csapattársaink" is frissíthessék az adatbázisaikat. Használjuk a git status-t és a git add-et és persze a git commit-ot :)
Gii Gii Gii Giiiiiiiii
Ha annak idején a yiic-et a Yii varázspálcájának hívtuk, a Gii-t joggal nevezhetjük varázságyúnak. Egy nagyon egyszerű de szexi, böngészőn keresztül futtatható kód generáló eszközről van szó, ami szépen felgyorsítja a programozást. Azoknak akik meg nyöszörögnek (mert akadnak páran), hogy túl sok a varázslás meg a mágia, vissza lehet menni saját keretrendszert barkácsolni. Sok szerencsét.
A Gii ugyan együtt érkezik a rendszerrel de biztonsági okok miatt alapból ki van kapcsolva. Nyissuk meg a konfigurációs file-unkat és keressünk rá a gii szóra a modules tömb környékén. Ha megvan, nyilván szedjük ki a /* ... */-t, és állítsunk be egy jelszavat (password), mondjuk: giiros -ra (vicces mi? haha).
Most látogassuk meg a Gii eszközt egy böngészőben ezen a URL-en: http://localhost/yiiki2/index.php?r=gii. Ha mindent jól csináltunk akkor a Yii Code Generator-nak kell megjelennie (ez a Gii) és egy jelszót bekérő form mezőnek. Büszkén írjuk is be a jelszavunkat (tudod, a giiros). Itt már láthatjuk is a köszöntő oldalt ami röviden annyit közöl, hogy a Kód Generáló segítségével gyorsan felépíthetjük a Yii alkalmazásunkat. És tényleg ... Elsőként tanácsos a Modell-t elkészítenünk, hiszen ez köti össze az adatbázisunkat a programmal. Klikkoljunk is rája:
A tablePrefix-szel most ne foglalkozzunk, mert nem állítottuk be, viszont a tábla nevét (Table Name) töltsük ki azaz írjuk be, hogy: pages - (hiszen ez volt a táblánk neve). Gii elvileg okosan megpróbálja kitalálni, hogy mi lesz (legyen) a Modell osztály elnevezése ... Majdnem jó is, én személy szerinte egyes számba szoktam tenni a Modell-jeimet (tehát pl: Page a Pages helyett). A többi értéket hagyhatjuk úgy ahogy van, és kattinthatunk az Előnézet (Preview) gombra.
Remélhetőleg egy új file név jelenik meg alul: models/Page.php. Ha erre a link-re kattintunk, akkor meggyőződhetünk róla, hogy igen, a mezők mind itt vannak és nyomhatunk egyet a Generate gombra. Ha jó Atyánk és a jogosultságok is úgy akarják, akkor a Page Modell osztályunk elészült a models/ mappa alatt.
Hát ennyi fért így a második részbe, elég sok mindent átvettünk, persze tudom, lehetne még ezt azt jobban részletezni, de a cikk célja inkább csak amolyan ismertetés féle. A következő részben használni fogjuk a Gii eszköz CRUD generáló finomságát, ami elkészíti majd nekünk a Kontroller és Nézet file-okat, az alap Create, Update, Read, Delete funkciókkal. Ja, és talán majd gépelni is fogunk egy kicsit ;)
Subscribe to:
Posts (Atom)



