A Yii (PHP) keretrendszer, magyarul.

Az Art-Work.hu története (Murányi S.)

2012-02-29T06:11:00.001-08:00

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

Yii 1.1 Application Development Cookbook (összefoglaló magyarul)

2011-11-03T09:58:00.000-07:00

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.

Megjelent Nagy Gusztáv - Web Programozás (alapismeretek) című könyve

2011-08-28T08:52:00.000-07:00

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.

Gittegylet meg a Yii - avagy Yiiki 2.0 (4. rész)

2011-08-01T13:00:00.000-07:00

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)

Gittegylet meg a Yii - avagy Yiiki 2.0 (3. rész)

2011-07-26T01:04:00.000-07:00

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.

Gittegylet meg a Yii - avagy Yiiki 2.0 (2. rész)

2011-07-19T01:00:00.000-07:00

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 ;)

Gittegylet meg a Yii - avagy Yiiki 2.0 (1. rész)

2011-07-12T01:00:00.000-07:00

Ugyan ez egy új cikk, de nem teljesen. Talán a tavaly szeptemberben megjelent Yiiki avagy WIKI a'la Yii cikkben bemutatott rendszer 2.0-ás változatának lehetne tekinteni.

Elég sok idő eltelt azóta és maga az alap keretrendszer is sokat változott, szerencsénkre. Még annyival szeretnénk kicsit megfűszerezni a fejlesztést, hogy bevonjuk a mostanában nagy népszerűségnek örvendő Git forráskezelőt. Vágjunk is bele.

Bevezetés

Magába az alapok installálásába nem fogunk belemenni, itt csak felsoroljuk mi mindent kell ismerni:

- Objektum Orientált Programozás (PHP 5): A jelenleg stabil Yii 1.1.8-es verzió a PHP 5.1-en alapszik, tehát annak ismerete mindenképp szükséges. - http://hu.wikipedia.org/wiki/Objektumorientált_programozás

- Adatbázis (SQL): A Yii, alapból sokféle adatbázis motort támogat. Az itteni példában én a SQLite-ot fogjuk használni, mert nem igényel különösebben bonyolult szerver oldali beállítást - http://hu.wikipedia.org/wiki/SQL

- MVC (Model-View-Controller) avagy Modell-Nézet-Vezérlő: A Yii az egy MVC-t szorgalmazó keretrendszer. Dióhéjban annyit jelent, hogy az alkalmazás jól elkülöníthető 3 részre. Az M vagy modell, ami az adatbázis jellegű lekérdezéseket végzi, a C vagy vezérlő ami kapcsolatot teremt és feldolgoz felhasználók által bevitt információt és végül a V vagy nézet, ami pedig magát a megjelenítést végzi. Ilyen többek között a Ruby On Rails rendszer is. - http://hu.wikipedia.org/wiki/MVC

- Active Record - ami tulajdonképpen "megszűnteti" a függőséget a különböző adatbázisok között és az adatbázis táblákat objektumokként kezeli. Ez a gyakorlatban azt jelenti, hogy mondjuk fejlesztői környezetben használhatunk SQLite-ot élesben pedig MySQL-t vagy MsSQL-t stb. - http://en.wikipedia.org/wiki/Active_record_pattern

- Git, forráskezelés - vagy verziókezelés alatt több verzióval rendelkező adatok kezelését értjük. Leggyakrabban a mérnöki tudományokban és a szoftverfejlesztésben használnak verziókezelő rendszereket fejlesztés alatt álló dokumentumok, tervek, forráskódok és egyéb olyan adatok verzióinak kezelésére, amelyeken több ember dolgozik egyidejűleg.

Apache, Nginx és egyéb web szerverek beállításába nem szeretnénk itt belemenni. A programot a következő konfigurációval készítettük:

- Ubuntu Linux (10.10)

- Apache 2.x
- SQLite 3
- PHP 5.3.x
- Yii 1.1.8

- Csomagoljuk ki a letöltött Yii-t a web szerverünk fő könyvtárába (pl. /var/www/yii ), a forráskód majd szintén a /var/www alá kerül (pl: /var/www/yiiki2).

Az is fontos, hogy a Yii rendszer a parancssorból is futtatható legyen! (PHP CLI)

A WEB alkalmazás létrehozása

Az alap alkalmazás létrehozása rendkívül egyszerű, csak adjuk ki a kovetkező utasítást (a web szerver root könyvtárából, ahol reméljük a maga a Yii rendszer is elhelyezkedit (pl /var/www).

./yii/framework/yiic webapp yiiki2

Ha minden jól sikerült, akkor a "Your application has been created successfully under /var/www/yiiki2" - szerű üzenet jelenik meg, ami röviden annyit jelent, hogy az alap program sikeresen létrehozva a megadott mappa alatt.

Azt már itt érdemes megjegyezni, hogy a programunk már ebben a fázisban működőképes. Ha megtekintjük a URL-t egy böngészőben (pl http://localhost vagy http://yiiki.peldaprogram.local) akkor egy (remélhetőleg) üdvözlő képernyő fogad bennünket.

Na itt a Git

Már rögtön az elején érdemes a munkánkat a forráskezelő alá tenni. Lépjünk be a yiiki2/ mappa alá és adjuk ki a következő parancsot.

$git init
Initialized empty Git repository in /var/www/yiiki2/.git/

Ez csak annyit jelent, hogy a Git sikeresen létrehozott egy üres (empty) forrástárat a megadott mappa alatt. Ha most megnézzük a könyvtárszerkezetet, akkor valami ilyesmit kell, hogy kapjunk. (rejtett file-okat is mutatva!)

$ll

drwxr-xr-x 8 imehesz imehesz 4096 2011-07-08 22:34 ./
drwxr-xr-x 42 imehesz imehesz 4096 2011-07-08 22:19 ../
drwxrwxrwx 2 imehesz imehesz 4096 2011-07-08 22:19 assets/
drwxr-xr-x 2 imehesz imehesz 4096 2011-07-08 22:19 css/
drwxr-xr-x 7 imehesz imehesz 4096 2011-07-08 22:34 .git/
drwxr-xr-x 2 imehesz imehesz 4096 2011-07-08 22:19 images/
-rw-r--r-- 1 imehesz imehesz 478 2011-07-08 22:19 index.php
-rw-r--r-- 1 imehesz imehesz 481 2011-07-08 22:19 index-test.php
drwxr-xr-x 14 imehesz imehesz 4096 2011-07-08 22:19 protected/
drwxr-xr-x 3 imehesz imehesz 4096 2011-07-08 22:19 themes/

Láthatjuk is, hogy a .git mappa ott figyel, amibe a Git program fogja tárolni a változtatásainkat.

Rutinos Yii-s mókusként tudjuk azt, hogy az assets/ a protected/runtime/ és a protected/data/ mappa alatt a Yii olyan dolgokat fog tárolni ami 99%-ban minden rendszeren más és más (pl. fejlesztői és éles környezet!), tehát érdemes lenne ezeket nem forráskezelő alá tenni, mert egyszerűen semmi értelme.

A Git erre egy nagyon elegáns megoldást kínál (illetve többet is), egyszerűen hozzunk létre egy file-t .gitignore néven (a yiiki2/ mappa alatt), és adjuk meg neki ezeket az útvonalakat. Így amikor a git ezekhez a mappákhoz ér, egyszerűen figyelmen kívűl hagyja őket. A gyakorlat azt diktálja, hogy még pár dolgot ne vegyünk forráskezelés alá, ilyenek például az adatbázis file-ok, vagy tömörített file-ok stb. Tehát a .gitignore file-unk valahogy így nézzen ki.

$less .gitignore

assets/*
protected/data/*
protected/runtime/*
*.zip
*.sqlite

Nos, eddig megvolnánk, de ha jól emlékszünk akkor a Git az elöbb azt mondta, hogy egy üres rendszert hozott létre. Ez igy is van. Az egyik legfontosabb Git parancs amit gyakran használni fogunk az a git status. Adjuk is ki:

$git status
# On branch master

#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
# css/
# index-test.php
# index.php
# protected/
# themes/
nothing added to commit but untracked files present (use "git add" to track)

Amint láthatjuk, annyi történt, hogy a Git kilistázta, hogy mely file-ok változtak. Jelen esetben azonban még semmi nem változott, hiszen még semmit nem rendeltünk a forráskezelő alá. Ezt egyébként alul a Git szépen jelzi is, hiszen azt mondja, hogy nincs semmit a commit-hez hozzáadnunk, azonban vannak olyan file-ok amiket nem követ. Ja, és azt tanácsolja, hogy ezeket a git add utasítással adhatjuk a forráskezelő alá. Remek, pont ez kell nekünk. Adjuk is ki:

$git add .

A pont "." az azt jelenti, hogy MINDEN használható file-t vagy változást adjon hozzá a forráshoz. Miután kiadtuk a parancsot, szemmel láthatóan semmi nem történt, azonban a Git a háttérben szorgosan dolgozik. Ha most kiadjuk a git status -t, egyből észrevesszük, hogy igenis valami történt:

# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: .gitignore
# new file: css/bg.gif
# new file: css/form.css
# new file: css/ie.css
# new file: css/main.css
# new file: css/print.css
# new file: css/screen.css
# new file: index-test.php
# new file: index.php
...

A lista elég hosszú, ide csak egy kis részletet illesztettünk be! A lényeg az, hogy ezek a file-ok készen állnak az un. commit-álásra, ami annyit tesz, hogy a módosításaink (jelen esetben új file-jaink) véglegesen a forrás részei lesznek. Magát a commit-álást pedig a -drrrrr ... dobpergés- git commit paranccsal hatjuk végre:

$git commit -m "itt a Yiiki2.0, elso commit-unk"

A -m (message) azaz üzenet, azt jelenti, hogy üzenetet fűzhetünk a commit-hez, aminek hiányát néhány programozó törzsek gyakran kéz- és/vagy fejvesztéssel büntetnek. Persze a képernyőn minden gyorsan leszalad, azért nézzük meg mi is történt:

[master (root-commit) 9e22a96] itt a Yiiki2.0, elso commit-unk
Committer: Imre Mehesz <imehesz@imehesz-laptop.(none)>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

git config --global user.name "Your Name"
git config --global user.email you@example.com

If the identity used for this commit is wrong, you can fix it with:

git commit --amend --author='Your Name <you@example.com>'

34 files changed, 1512 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
create mode 100644 css/bg.gif
create mode 100644 css/form.css
create mode 100644 css/ie.css
create mode 100644 css/main.css

...

Itt azt irta ki, hogy létrejött a commit, és a rendszer beállította a nevünket és az email címünket, de azért ellenőrizzük, hogy jó e. Még talán egy git parancsot érdemes itt megemlítenünk, a log -ot, ami az utolsó commit-okat listázza ki:

$git log

commit 9e22a96c0d94b58cb780eaa0d53fedd24df99242

Author: Imre Mehesz <imehesz@imehesz-laptop.(none)>

Date: Fri Jul 8 23:24:51 2011 -0400

itt a Yiiki2.0, elso commit-unk

Ebből a commit azonosítón kívül az is látszik, hogy pénteken este fél 12-kor nincs más dolgom, minthogy ilyeneket irogassak :)

A következő részben reméljük már talán valami kódot is sikerül majd írnunk!

Csinibaba Szeress Belém avagy Sminkelés/Themeing a Yii rendszerrel

2011-06-09T14:53:00.000-07:00

Alapozás

A "Theming vagy Sminkelés" nem más, mint egy (webes) alkalmazás kimenetét a felhasználó elé táró kinézet-lapok rendszere. Egy új Sminket használva az egész program általános kinézete azonnal megváltoztatható.

Yii-ben minden Sminket egy mappa képvisel, ami különböző Nézet és Layout (pl: header vagy footer stb...) fájlokat tartalmaz(hat), ugyancsak itt találhatók meg a Sminkhez tartozó képek, CSS- és JS file-ok is. A Smink neve minden esetben megegyezik a mappa nevével (fontos!). Az összes Smink a WebRoot/themes mappa alatt található, és egyszerre csak egy Smink lehet aktív.

Smink felkenése:

Egy Sminket úgy aktiválhatunk, hogy beállítjuk a Web programunk 'theme' paraméterét. Ezt vagy magában a fő konfigurációs file-ben tehetjuk meg (protected/config/main.php), vagy futás közben a Kontrollerben. (persze futás közben sminket feltenni veszélyes is lehet - minden körülmények között!)

Megjegyzés: maga a Smink neve kis- és nagybetű érzékeny. Ha egy olyan Smink-et probálunk aktiválni, ami nem létezik a 'Yii::app()->theme' null-t fog vissza adni.

Paletta készítése:

A Smink-nek mindenképpen követnie kell a Yii által használt és szorgalmazott könyvtárfelépítést. Például minden Nézet file-nak a '/views' mappában kell elhelyezkednie, a layout file-oknak pedig a '/views/layouts'- és a rendszer nézet file-oknak pedig a '/views/system' alatt. Tehát ha pl. le szeretnénk cserélni a 'PostController' kontroller 'create' nézet file-ját a 'classic' smink-ben, csak mentsük el az új nézet file-unkat valahogy így 'Webroot/themes/classic/views/post/create.php'.

Azokat a Nézet file-okat, amelyek olyan Kontrollerekhez tartoznak amik egy meghatározott Modul részei, ugyanúgy a 'views' mappa alá kell elhelyezni. Például, ha az előbb említett PostController egy 'forum' nevű modul alatt található, akkor az új "sminkelt" nézet file-t a WebRoot/themes/classic/views/forum/post/create.php-ként mentjük el. Ha pedig maga a forum modul egy másik modul, pl: 'support' része (mert iiyet lehet a Yii-vel ;) ) akkor egyszerűen ide mentjük: WebRoot/themes/classic/views/support/forum/post/create.php.

Megjegyzés: Mivel a 'views' mappa tartalmazhat kényes file-okat, érdemes úgy konfigurálni, hogy halandó internetfelhasználó ne férhessen hozzá.

Amikor a render()-t vagy renderPartial()-t meghívjuk, hogy a Nézet-ünket megjelenítse, Yii először megpróbálja megtalálni magát a nézet file-t és a hozzá tartózó layout file-t az aktív smink könyvtár alatt. Ha sikerül, ezek a file-ok kerülnek megjelenítésre. Ha nem, akkor pedig az alap nézet és layout file-ok, amiket a viewPath/layoutPath-ek állítanak be.

Tipp: Gyakran előfordul olyan, hogy a nézet file-unkból szeretnénk elérni egyéb, csak az aktív sminkre jellemző, file-okat. Ilyenek lehetnek például a képek a smink 'images' mappában. A baseUrl változó segítségével ezt könnyedén megtehetjük, valahogy így: Yii::app()->theme->baseUrl.'/images/FileName.gif'.

Alább látható egy Yii alkalmazás teljes mappa rendszere, két sminkkel basic és fancy néven.

WebRoot/
assets
protected/
    .htaccess
    components/
    controllers/
    models/
    views/
      layouts/
        main.php
      site/
       index.php
themes/
basic/
    views/
      .htaccess
      layouts/
        main.php
      site/
        index.php
fancy/
    views/
      .htaccess
      layouts/
        main.php
      site/
        index.php

És ha az alkalmazásunk konfigurációs file-jába ezt beállítjuk (/protected/config/main.php):

return array(
...
'theme'=>'basic',
...
);

akkor a basic smink lesz aktív, ami azt jelenti, hogy a themes/basic/views alatti /layouts/main.php és a site/index.php kerül megjelenítésre. Ha pedig ezek nem lennének meg, akkor Yii automatikusan a "gyári" /protected/views-t fogja használni.

then the basic theme will be in effect, which means the application's layout will use the one under the directory themes/basic/views/layouts, and the site's index view will use the one under themes/basic/views/site. In case a view file is not found in the theme, it will fall back to the one under the protected/views directory.

Hát ennyi :)

A Yii Themes oldalon lehet ingyé előre elkészített Sminkeket letölteni a Yii-hez.

Eredeti cikk (még több infóval): http://www.yiiframework.com/doc/guide/1.1/en/topics.theming

Függyvény hívása Nézetből

2011-05-28T06:19:00.000-07:00

Néha előfordul, hogy valamilyen bonyolultabb kimenetet kell produkálnunk Nézetünkben - például egy táblát. A legtöbben azt tanácsolják, hogy az MVC szabályainak megfelelően a Nézet az legyen egyszerű, ne legyen benne túl sok ciklus stb. Tehát valahogy a kódunkat máshová kell helyeznünk. Erre fogunk néhány példát bemutatni.

Függvényünket betehetjük a Modellünkbe, így a Nézetben elérhetővé válik a modellen keresztül mint osztály metódus. A hátulütője ennek az, hogy a modellbe nem igazán szép nézettel/kimenettel kapcsolatos függvényeket tenni. Tehát ez a módszer egyáltalán nem tanácsolt.
Használjunk Widget-et. Készíthetünk egy osztályt, ami a CWidget-et bővíti ki, ebben az esetben a Nézetből csak meghívjuk a Widget-ünket és kész is. Ez akkor is nagyon hasznos, ha például több nézetben szeretnénk megjeleníteni ugyanazt a tartalmat.
Tegyük a függvényünket a Kontrollerbe. Ha csak egyetlen Nézet használja a függvényünket (és nem tartalmaz nagyon összetett logikát) elég lehet, hogy a Kontrollerbe helyezzük el.
Használjunk Nézet file-t. Mert a CController render() és renderPartial() metódusai visszaadhatnak értéket is megjelenítés helyett. Ez azt jelenti, hogy a függvényünket betehetjuük egy speciális Nézet file-ba, lehetőleg ugyanabba a mappába ahol maga a hívó file helyezkedik el. Ezt úgy érhetjük el, hogy a render() - vagy renderPartial()) - harmadik paraméterét true-ra állítjuk be.

Eredeti cikk: http://www.yiiframework.com/wiki/125/putting-function-to-be-called-in-view/

UI: Yii-s widget-ekrol meg itt olvashattok bovebben (magyarul!): Nosza irjunk widget-et tyuklepesrol tyuklepesre

2011-es PHP keretrendszer statisztika

2011-05-15T10:03:00.000-07:00

Ennek annyira megörültem, hogy gyorsan fel is teszem ide:

De ez még szebb:

Itt az eredeti link: http://www.php-developer.org/most-used-php-framework-the-popular-top-7-list-in-year-2011/

Nosza, írjunk widget-et! 2. rész (tyúklépésről tyúklépésre)

2011-04-19T01:00:00.000-07:00

2. rész

Írta: János Zahratka

Nos, ahogy ígértem, íme a második rész. Ebben a szakaszban származtatni fogjuk a már elkészített jQTBaseOverlay widget-ünket, aminek ezúttal már a HTML oldalon megjelenő eredménye is lesz.

Emlékeztetőül: az előző részben elkészítettünk egy alap widget-et, a jQuery Tools overlay plugin-jéhez. Erre azért volt szükség, mert a plugin-ból több, különböző eszközt lehet csinálni. Ebben a részben két felhasználási lehetőséget fogok megmutatni. Az egyik egy olyan overlay doboz, amibe bármilyen tartalmat el lehet helyezni. A másik pedig egy üzenő/kérdező dialógus, amivel üzeneteket, illetve kérdéseket lehet megjeleníteni a felhasználóknak, és utóbbi esetében a választól függően lehet "reagálni" a felhasználó választására.

jQTOverlay

Első lépésben létrehozunk egy új php állományt a protected/components/widgets mappában jQTOverlay.php névvel. Még mielőtt nekikezdenénk awidget osztályának kiterjesztéséhez, gondoskodnunk kell róla, hogy a widget megtalálja a szülő osztályát, ezt pedig a YiiBase osztály import metódusának segítségével fogjuk megoldani. Az üres osztályunk valahogy így fog kinézni:

<?php

Yii::import('application.components.widgets.jQTBaseOverlay');
class jQTOverlay extends jQTBaseOverlay
{

}

Ezután kicsit átírjuk a publikus init metódust, ami a widget alapértékeinek beállítását végzi el. Ebben az esetben mindőssze annyit fog csinálni ez a metódus, hogy lefuttatja a szülő osztály azonos nevű metódusát, majd meghívja a registerClientScript, és a renderBegin metódusokat. Egyik sem csinál mást, "csak" végrehajtja a szülő osztályban lévő azonos nevű eljárásokat. Ez azért lett így összerakva, mert az alap osztályban már minden szükséges metódus, és paraméter definiálva van, itt pedig csak a megfelelő sorrendben hívogatni kell őket.

...
    public function init() {
        parent::init();

        $this->registerClientScript();
        $this->renderBegin();
    }
    ...

Ha ezzel megvagyunk, előkapjuk a run metódust, és meghívjuk benne a renderContent és a renderEnd metódusokat. Ezek szintén definiálva vannak a szülő osztályban.

...
    public function run() {
        $this->renderContent();
        $this->renderEnd();
    }
    ...

Már csak négy metódus van hátra, melyek egy kivételével szintén csak annyit csinálnak, hogy meghívják a szülő osztály azonos nevű metódusait. Ezek aregisterClientScript, a renderBegin, a renderContent, és a renderEnd metódusok. Az üres metódus arra való, hogy ha valaki tovább szeretné származtatni ezt a widgetet, akkorű jobb, ha megvan ez a metódus is.

...
    protected function  registerClientScript() {
        parent::registerClientScript();
    }

    protected function  renderBegin() {
        parent::renderBegin();
    }

    protected function  renderContent() {

    }

    protected function  renderEnd() {
        parent::renderEnd();
    }
    ...

A widget-et tovább lehetne rövidíteni azzal, hogy azokat a metódusokat, amelyek csak a szülő osztályban lévő önmagukat hívják meg nem kell deklarálni, csak meghívni a parent segítségével, azonban gondolni kell arra is, hogy esetleg olyan osztályt fogunk csinálni, ami ezt a már kibővített osztályt fogja tovább származtatni.

Ahogy ígértem, valóban sokkal rövidebb lesz a második rész, ugyanis az a helyzet, hogy a jQTOverlay widget ezzel készen is van. Lássuk a kódot!

<?php

Yii::import('application.components.widgets.jQTBaseOverlay');
class jQTOverlay extends jQTBaseOverlay
{
    public function init() {
        parent::init();

        $this->registerClientScript();
        $this->renderBegin();
    }

    public function run() {
        $this->renderEnd();
    }

    protected function  registerClientScript() {
        parent::registerClientScript();
    }

    protected function  renderBegin() {
        parent::renderBegin();
    }

    protected function renderContent() {

    }

    protected function  renderEnd() {
        parent::renderEnd();
    }
}

Már csak annyi van hátra, hogy bármely view (nézet) állományban meghívjuk, ami valahogy így néz ki:

...
<!-- Ha erre klikkel, akkor jöhet az overlay. -->
<?php echo CHtml::link(CHtml::encode('Overlay'),
    array('#'),
    array(
        'id' => 'showOverlay',
        'name' => 'showOverlay',
        'rel' => '#Overlay'
    )
); ?>
...

...
<!-- És ez a widget hívása. -->
<?php $this->beginWidget('application.components.widgets.jQTOverlay', array(
    'htmlOptions' => array(
        'id' => 'overlay',
        'name' => 'overlay'
    ),
    'trigger' => 'showOverlay',
    'useMask' => true,
    'title' => 'Overlay',
)); ?>
    Bármilyen HTML, vagy php tartalom, amit meg akarunk jeleníteni.
<?php //$this->endWidget(); ?>
...

jQTDialog

A második származtatott widget-ünk egy kicsit - de tényleg csak egy kicsit - bonyolultabb, de csak azért, mert arra vetemedtem, hogy egy type nevű paraméter segítségével három dialógus típust kezeljek egy widget megírásával. Mindhárom változat működése azonos. A különbség abban van, hogy milyen válaszlehetőségeket adok a felhasználónak.

Két paramétert vezettem be, amelyek a szülő osztályban nem léteznek. Az egyik a már előbb említett type, ami a dialógus típusát határozza meg. Értéke "alert" (figyelmeztetés), "question" (kérdés) vagy "decision" (döntés) lehet. A másik a message paraméter, amely a megjelenítendő üzenetet, vagy kérdést tárolja.

A szülő osztályból átvettem még az _openTag paramétert, ami pontosan ugyanazt tárolja, mint a szülő.

Az init metódus ezúttal összetettebb lesz, mint az előző esetben.

Megvizsgálja, hogy a type paraméter a megfelelő értéket tartalmaz-e, azután azt is meg kell vizsgálni, hogy van-e üzenet, amit meg kell jeleníteni (message). Ha ez a két paraméter nem megfelelő, akkor a widget egyszerűen leáll és nem jelenít meg semmit.
Megváltoztatja az overlay CSS osztályának nevét a dialógus típusának megfelelően. Ez nem kötelező, viszont szerintem jó megoldás arra, hogy az egyes dialógus típusok más-más megjelenési formát vehessenek fel.
Meghívja a szülő osztály azonos nevű metódusát, aztán az előbbi overlay widget-ben leírt módon a registerClientScript és renderBegin metódusok hívásai következnek.

...
    public function init() {
        if('alert' !== $this->type && 'question' !== $this->type && 'decision' !== $this->type) {
            return null;
        }
        if(null === $this->message) {
            return null;
        }

        $this->htmlOptions['class'] = $this->type;
        $this->params['closeOnClick'] = false;

        parent::init();

        $this->registerClientScript();
        $this->renderBegin();
    }
    ...

A run metódus ugyanazt csinálja, mint az előző widget.

...
    public function run() {
        $this->renderEnd();
    }
    ...

A registerClientScript metódus állítja elő azt a javascript kódot, ami az oldal végére kerül, és a dialógus kliens oldali működéséért felelős.

Ha kérdés típusú dialógust szeretnénk megjeleníteni, akkor több válaszlehetőséget kell biztosítanunk, és egyúttal gondoskodnunk kell róla, hogy a lap tudja, hogy mit válaszolt a felhasználó. Ennek első része az, hogy egy target nevű változóba betöltjük a dialógus azonosítóját, ami vagy meg van adva az overlay plugin paraméterei között, vagy ha nincs, akkor a dialógus azonosítója lesz az.

Ha ez megvan, akkor elkérjük a szülő osztálytól a script első részét, és hozzáfűzzük a válasz gombok kezelésének szkriptjét, aztán az így elkészült kódot visszatesszük a publikus script praméterbe, majd meghívjuk a szülő osztály azonos nevű metódusát.

A script kódja csak annyira van megírva, hogy az igényeknek megfelelően simán folytatni lehessen, tehát az igazi használathoz még dolgozni kell rajta.

...
    protected function  registerClientScript() {
        if('question' === $this->type || 'decision' === $this->type) {
            if(isset($this->params['target'])) {
                $target = $this->params['target'];
            } else {
                $target = $this->htmlOptions['id'];
            }

            $script = $this->script;

            $script = $script . "\n" .
                '$("#' . $target . ' .buttons button").click(function(event) {' .
                    'var result = $(this).attr("value");' .
                '});';

            $this->script = $script;
        }

        parent::registerClientScript();
    }
    ...

És már csak annyi kell, hogy megjelenítsük a dialógusunk HTML kódját. Ennek első felét a renderBegin metódus végzi, ami kiírja a dialógus kezdő részét, címét - ha van -, aztán az üzenetet, vagy kérdést.

...
    protected function  renderBegin() {
        ob_start();
        ob_implicit_flush(false);
        echo "\n" . CHtml::openTag($this->tagName, $this->htmlOptions) . "\n";
        if(null !== $this->title || '' !== $this->title) {
            echo CHtml::tag('h3', array('class' => 'title'), CHtml::encode($this->title), true) . "\n";
        }
        echo CHtml::tag('p', array('class' => 'message'), CHtml::encode($this->message), true);
        $this->_openTag = ob_get_contents();
        ob_clean();
    }
    ...

És jön az utolsó metódus, név szerint a renderEnd, ami mindössze annyit csinál, hogy a kód végére odateszi a dialógus típusának megfelelő gombokat, aztán lezárja a widget záró kódjával az egészet.

...
    protected function  renderEnd() {
        $content = ob_get_clean();
        echo $this->_openTag;
        echo trim($content);
        echo "\n" . CHtml::openTag('div', array('class' => 'buttons')) . "\n";
        if('alert' === $this->type) {
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonOk', 'value' => 'ok', 'class' => 'close'), 'OK', true) . "\n";
        } elseif('question' === $this->type) {
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonYes', 'value' => 'yes', 'class' => 'close'), 'Igen', true) . "\n";
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonNo', 'value' => 'no', 'class' => 'close'), 'Nem', true) . "\n";
        } elseif('decision' === $this->type) {
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonYes', 'value' => 'yes', 'class' => 'close'), 'Igen', true) . "\n";
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonNo', 'value' => 'no',  'class' => 'close'), 'Nem', true) . "\n";
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonCancel', 'value' => 'cancel',  'class' => 'close'), 'Mégsem', true) . "\n";
        }
        echo CHtml::closeTag('div');
        echo "\n" . CHtml::closeTag($this->tagName) . '' . "\n";
    }
    ...

Most pedig nézzük a teljes kódot!

<?php

Yii::import('application.components.widgets.jQTBaseOverlay');
class jQTDialog extends jQTBaseOverlay
{
    public $type = 'alert';
    public $message;

    private $_openTag;

    public function init() {
        if('alert' !== $this->type && 'question' !== $this->type && 'decision' !== $this->type) {
            return null;
        }
        if(null === $this->message) {
            return null;
        }

        $this->htmlOptions['class'] = $this->type;
        $this->params['closeOnClick'] = false;

        parent::init();

        $this->registerClientScript();
        $this->renderBegin();
    }

    public function run() {
        $this->renderEnd();
    }

    protected function  registerClientScript() {
        if('question' === $this->type || 'decision' === $this->type) {
            if(isset($this->params['target'])) {
                $target = $this->params['target'];
            } else {
                $target = $this->htmlOptions['id'];
            }

            $script = $this->script;

            $script = $script . "\n" .
                '$("#' . $target . ' .buttons button").click(function(event) {' .
                    'var result = $(this).attr("value");' .
                '});';

            $this->script = $script;
        }

        parent::registerClientScript();
    }

    protected function  renderBegin() {
        ob_start();
        ob_implicit_flush(false);
        echo "\n" . CHtml::openTag($this->tagName, $this->htmlOptions) . "\n";
        if(null !== $this->title || '' !== $this->title) {
            echo CHtml::tag('h3', array('class' => 'title'), CHtml::encode($this->title), true) . "\n";
        }
        echo CHtml::tag('p', array('class' => 'message'), CHtml::encode($this->message), true);
        $this->_openTag = ob_get_contents();
        ob_clean();
    }

    protected function  renderEnd() {
        $content = ob_get_clean();
        echo $this->_openTag;
        echo trim($content);
        echo "\n" . CHtml::openTag('div', array('class' => 'buttons')) . "\n";
        if('alert' === $this->type) {
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonOk', 'value' => 'ok', 'class' => 'close'), 'OK', true) . "\n";
        } elseif('question' === $this->type) {
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonYes', 'value' => 'yes', 'class' => 'close'), 'Igen', true) . "\n";
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonNo', 'value' => 'no', 'class' => 'close'), 'Nem', true) . "\n";
        } elseif('decision' === $this->type) {
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonYes', 'value' => 'yes', 'class' => 'close'), 'Igen', true) . "\n";
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonNo', 'value' => 'no',  'class' => 'close'), 'Nem', true) . "\n";
            echo CHtml::tag('button', array('id' => $this->htmlOptions['id'] . 'ButtonCancel', 'value' => 'cancel',  'class' => 'close'), 'Mégsem', true) . "\n";
        }
        echo CHtml::closeTag('div');
        echo "\n" . CHtml::closeTag($this->tagName) . '' . "\n";
    }
}

Végül pedig az elkészült widget használata a view (nézet) állományokban.

...
<!-- Ha erre klikkel, akkor jöhet a dialógus. -->
<?php echo CHtml::link(CHtml::encode('Dialog'),
    array('#'),
    array(
        'id' => 'showDialog',
        'name' => 'showDialog',
        'rel' => '#Dialog'
    )
); ?>
...

...
<!-- És ez a widget hívása. -->
<?php $this->widget('application.components.widgets.jQTDialog', array(
    'htmlOptions' => array(
        'id' => 'overlay',
        'name' => 'overlay'
    ),
    'trigger' => 'showDialog',
    'useMask' => true,
    'title' => 'Dialógus',
    'type' => 'question',
    'message' => 'Valamit kérdezni akartam, de elfelejtettem. Nem tudod, mi volt az?'
)); ?>
...

Remélem, lesz némi haszna a cikknek! Akinek netán kedve támadna, hogy megjegyzéssel illesse a két cikket, ne fogja vissza magát! Nem vagyok egy über okos programozó, csak szeretek ezzel foglalkozni, és szívesen tanulok én is abból, amit a nálam okosabbak mondanak/írnak.

Hajrá MAGYAROK!

2011-04-02T06:29:00.000-07:00

Hajrá MAGYAROK!

FRISSITES 2:

Na, csak hogy lathassatok kemeny munkank gyumolcset, bekuldtem a cuccost:

http://code.google.com/p/yiidoc/source/detail?r=2008

---

FRISSITES:

Hat holgyeim es uraim, ugy latom kesz vagyunk - 3.5 nap alatt ... nem rossz :) nagyon szepen koszonjuk mindenkinek az idejet es energiajat.

Ha valakinek lemaradt volna a neve, kerem jelezze!!! Remelem mar az 1.1.8-asban benne lesz a cucc. Koszi megegyszer!

--------------------------------------------------------------------------

Már nem lehet elbújni a felelősség alól, hehe.

Ha megy az angol, márpedig ha a Yii rendszert használod, akkor valamennyire biztos megy, légyszives légy oly kedves, segíts nekünk abban, hogy végre a Yii megszolaljon már magyarul is.

Az egész nem tart tovább mint tíz másodperc. Tényleg. Se regisztrálni nem kell, se semmi. Csak klikkolj a linkre, nézd meg melyik mondat hiányzik és ha tudod, fordítsd le:

http://j.mp/ftAMJu

KÖSZI

ui: ja, ha segítettél a fordításban, légyszi jelentkezz, hogy a nevedet feltüntethessük valahol!

Néhány kifejezés, amit jó lenne a fordítás során betartani, hogy nagyjából egységes legyen ( ahova ? jelet tettem, nem vagyok biztos ):

Controller - Vezérlő

Model - Modell

View - Nézet

MVC - MVC (szvsz, ne fordítsuk!)

Active Record - Aktív Rekord (más ötlet?)

Class - Osztály

Cache - Gyorsítótár

Alias - Álnév
Extension - Bővítmény
Widget - Widget, ne forditsuk!

Eddigi fordítóink:

- Balázs Simon
- Benyó Balázs
- Erős Bence
- Hajdu Mihály
- Kádár Péter
- Kelemen Zádor Dániel
- Méhész Imre
- Nagy Róbert
- Perjési Szabolcs
- Schumacher Zsolt
- Vajda János
- Zahratka János

Nosza, írjunk widget-et! (tyúklépésről tyúklépésre)

2011-03-20T01:00:00.000-07:00

1. rész

Írta: János Zahratka

Ok, de mi az a widget?

A Yii egyik alapelve a DRY (Dont Repeat Yourself), vagyis ne ismételd önmagad! Ennek szellemében a widget egyik tulajdonsága, hogy kódrészleteket tárol, amelyeket aztán tetszés szerinti számossággal képes reprodukálni az oldalakon.

Tegyük fel, hogy dobozokra szeretnénk felosztani weblapjainkat! Ekkor az átlag halandó nekiáll a HTML kódnak, és összeszedve minden kitartását bemásolgatja a dobozok leíró kódját a megfelelő helyekre. Ezzel önmagában nincs is semmi gond, egészen addig, amíg nem kell megváltoztatni a dobozok kódját. No, ekkor szokott előjönni az az effekt, hogy az ember fia/lánya rágyújt egy újabb koporsószögre, és nagyot sóhajtva nekiáll, hogy ismét végigmenjen az összes lap kódján, és egyenként megváltoztassa az egyes dobozokat. Kb. a harmadik, negyedik ilyen kimerítő változtatás után kezd testetölteni a gondolat, hogy ez az egész weblap készítés nagyon macerás dolog.
Ha Yii-t használunk, akkor mázlisták vagyunk, hisz itt van nekünk a widget, s ennek segítségével szó szerint percek alatt képesek vagyunk arra, hogy a teljes weblap összes kódjában megváltoztassuk a dobozokat megjelenítő kódot. Nos, akkor nézzünk erre egy kis példát! Maradva a feltételezésnél, egy sima doboz konténer kódját kell előállítanunk.

Yii kód	HTML eredmény
<?php $this->beginWidget('dobozWidget'); ?> ... A doboz tartalma ... <?php $this->endWidget(); ?>	<div class="doboz"> <div class="tartalom" ... A doboz tartalma ... </div> </div>

Ó, igen, tudom, ez egy használhatatlan példa, viszont nagyon is jól mutatja a widget kód reprodukálási tulajdonságát.

A widget újabb igen jó tulajdonsága, hogy paraméterezhető. Tehát nemcsak egy nevet tudunk neki megadni, hanem - a példánál maradva - mondjuk a doboz címét is.

Yii kód

HTML eredmény

<?php $this->beginWidget('dobozWidget', array(
    'title' => 'A doboz címe'
)); ?>
    ... A doboz tartalma ...
<?php $this->endWidget(); ?>

<div class="doboz">
    <div class="cim">A doboz címe</div>
    <div class="tartalom"
        ... A doboz tartalma ...
    </div>
</div>

Nos, igen, ezen a példán azért már látszik valami abból, hogy nemcsak kód gépelést takarít meg a widget a fejlesztőnek, hanem bizony a paraméterezési lehetőséggel igencsak összetett widgeteket lehet írni.

És még mindíg vannak lehetőségek a widgetekben. A fejlesztők - nagyon okosan - gondoltak arra is, hogy ne csak a tartalmat lehessen hordozni a widget-ben, hanem a formát is. Ezért aztán lehetőség van arra, hogy a dobozunk formáját is belepakoljuk, sőt, ha netán arra vetemednénk, hogy javascript funkciókkal ruháznánk fel a dobozt (animált megjelenés, görgethető tartalom, stb), akkor az ehhez a kódrészlethez tartozó javascript állományokat is magában hordozhatja, és amikor szükség van rá, pár sor megírásával gondoskodik róla, hogy a szükséges CSS és egyéb file-ok elérhetővé váljanak a weblap megjelenítésénél.
És még van egy nagyon-nagyon fontos tulajdonsága, amivel ez a cikk ugyan nem foglalkozik, de érdemes tudni, hogy arra is van lehetőség, hogy a kliens oldali megjelenítéshez hozzá lehet fűzni a szerver oldali kiszolgáló action-okat.

Talán első blikkre elég is ennyi a widget-ek tulajdonságairól. A most következő példa widget eléggé jól fogja szemléltetni, hogy milyen jó kis cuccokat lehet farigcsálni velük, ha egy kis időt rászánunk a dologra.

Lássuk a feladatot!

"A Gugli a barátod" című mondás nagyon is igaz voltát bizonyítja, hogy keresgélés közben ráakadtam a jQuery Tools oldalra. Ez egy jQuery alá írt kis gyűjtemény, ami a felhasználói felületet hivatott kiegészíteni, feltuningolni. Egy szó, mint száz, eldöntöttem, hogy lekapom a netről, és beledolgozom a kis Yii eszköztáramba. Jó, ha az embernek vannak ilyesmik a keze ügyében.
Az Overlay egy olyan kis plugin, amivel az oldal "fölé" lehet megjeleníteni különböző tartalmakat. Egyszerűbben fogalmazva egy panel szerűség, amit tetszőleges tartalommal lehet megtölteni, aztán ezt meg lehet jeleníteni - mondjuk egy linkre, vagy képre kattintva -, illetve el lehet rejteni. Az oldalon jó sok demo mutatja be az egyes plugin-ek működését, sőt, olyan demo-kat is feltettek, melyek az egyes elemek kombinációit demonstrálják.
Némi negatívumként meg kell említenem, hogy a letöltés nem ment simán. Megpróbáltam összerakni magamnak egy összeállítást, de a letöltés gombra kattintva nem találta a cuccot. Viszont egy szerkesztőt megnyitva, és egyenként ráklikkelgetve az egyes szkriptekre, majd kijelölve, és bemásolva a szerkesztőbe simán meg lehet csinálni a saját összeállítást.
Szóval a feladat az, hogy csináljunk egy olyan widget-et, ami:

lekezeli a megjelenítendő HTML kód paramétereit,
"legyártja" a plugin használatához szükséges HTML kódot,
elérhetővé teszi a megjelenő oldalon a plugin-hez tartozó CSS, és javascript állományokat,
beállítja a plugin lehetséges paramétereit,
elkészíti és befűzi az oldal végére azt a scriptet, amitől az Overlay működni fog,
és végül alkalmas arra, hogy ebből a widget-ből származtatással új widget-eket lehessen írni az Overlay kibővítéséhez.

A "kopasz" widget

A magam részéről egyfajta komponensnek tekintem a widget-eket, ezért a protected/components/widgets mappába szoktam tenni őket. Esetünkben a kiinduló widget a következőképpen néz ki:

<?php
class jQTBaseOverlay extends CWidget
{
    public function init() {
    }

    public function run() {
    }
}

A "kopasz", azaz üres widget-ünk összesen négy dolgot tartalmaz:

A widget nevét, amire később hivatkozni fogunk.
Azt az osztályt, amiből származtatjuk, s így örököljük a szülő paramétereit és metódusait (CWidget).
A publikus init metódust, amiben majd beállítjuk a widget paramétereit, és elkészítjük a widget nyitó fejrészét.
A szintén publikus run metódust, amiben megjelenítjük a widget tartalmát, és a záró lábrészét.

Paraméterek

A példa widget-ben szintaktikailag három, logikailag négy fajta osztály szintű paramétert fogunk használni:

A publikus paraméterek azok, amelyek értékét közvetlenül megadhatja, illetve lekérheti a felhasználó.
A privát, vagy protected (védett) paraméterek olyan változók, melyeknek értékét nem közvetlenül adjuk meg, vagy kapjuk meg, hanem valamilyen eljárás, számítás eredményét hordozzák. Jó példa erre a _clientScript, melynek értékét a Yii-től kapjuk meg. Csinálhatnánk azt is, hogy ezt az értéket minden alkalommal lekérjük a rendszertől és nem tároljuk, ám ez lassítaná a widget futását, és ezzel az egész lap megjeleítését.
Harmadik típusú változónk a privát, belső típus. Ezt arra használjuk, hogy két védett, vagyis az osztályon kívülről elérhetetlen metódusok között adatokat adjunk át.
A negyedik kategória, amit ebben a widget-ben használunk a privát, belső és statikus paraméter. Ez a fajta változó megkapja a kezdeti értékét, és a nem statikus változókkal szemben megőrzi azt akkor is, ha egy új Overlay widget-et szeretnénk létrehozni a lapon.

Publikus paraméterek

A CHtml helper metódusai használnak egy htmlOptions nevű tömböt, ami arra szolgál, hogy a megjelenítendő HTML kód paramétereit lehessen átadni vele a widget-nek, ezért mi is alkalmazni fogjuk, hogy csak azokat a paramétereket kelljen külön megtanulnunk, megjegyeznünk, amelyek kiegészítik a Yii kód formátumát.
További ilyen, Yii szerű paraméter a tagName, ami azt a HTML tagot jelenti, amit majd a widget Overlay-ként megjelenít. Ez alapértelmezésben a divtag.
Megjegyzés: Ez a paraméter nagyon hasznossá válhat abban az esetben, ha pl.: valaki netán arra vetemedne, hogy HTML5 alapú oldalt akar csinálni. Ekkor nem kell átírnia a widget-et, csak annyi a dolga, hogy a widget hívásakor beállítja az használni kívánt HTML tag nevét.
A title paraméterben lehet majd megadni a megjelenő Overlay panel címét. Ha nem adjuk meg, vagyis üresen hagyjuk, akkor nem jeleníti meg a címet HTML oldalon.
A trigger-ben kell megadni annak a másik HTML elemnek a nevét, amire klikkelve megjelenik az Overlay.
A useMask paraméter true/false (igaz/hamis) értékeket vehet fel, és arra szolgál, hogy amikor az Overlay megjelenik, takarja-e el egy valamilyen szinű felület az oldal többi részét.
A params, maskParams paraméterekben lehet megadni azokat a paramétereket, melyek az Overlay működését szabályozzák.
Aki érzi annyira a szert, hogy tovább akarja bonyolítani a javascript kódot, annak itt vannak az Overlay adta események paraméterei: events, maskEvents.

Privát paraméterek

Az _id paramétert elvileg nem kellene definiálni, mert azt már örököltük a CWidget osztálytól, viszont azt szeretnénk, hogy a widget-ünk ne a szokásos "yw0" id-t kapja, ha nem adunk meg neki mi magunk id-t a létrehozás során, hanem legyen saját, csak erre a widget-re jellemző egyedi neve.
Az _assetsUrl a widget "tartozékainak" (CSS, javascript, képek, stb.) elérési útvonalát tárolja.
Ahhoz, hogy a widget "tartozékait" hozzá tudjuk tenni a megjelenítendő HTML oldalakhoz, szükségünk van a _clientScript paraméterre, aminek érékét majd a Yii-től kell elkérnünk.
Következő paraméterünk a _script, ami arra szolgál, hogy a widget működéséhez szükséges javascript kódot tárolja.

Privát, belső paraméterek

Az _openTag-ot arra használjuk, hogy az init metódusban megkezdett widget megjelenítésre elkészített kódját átvigyük vele a run metódusba, hogy ott folytathassuk vele a megjelenítést.
Megjegyzés:A megjelenítéshez a php Output Buffering Control (kimenet pufferelés) technikáját használjuk, hogy lehetőség legyen pl.: a header-ek módosítására még a megjelenítés előtt.

Privát, belső, statikus paraméterek

Utolsó osztály szintű paraméterünk a statikus _counter, amit arra fogunk használni, hogy a widget egyedi nevének (_id) automatikus létrehozásakor legyen egy számlálónk, amit a név végéhez hozzáfűzve valóban egyedi értéket kapunk.

Ok, most lássuk mindezt kódban is!

    ...
    public $htmlOptions = array();
    public $tagName = 'div';
    public $title = null;
    public $trigger = null;
    public $useMask = false;
    public $params = array();
    public $events = array();
    public $maskParams = array();
    public $maskEvents = array();

    private $_id;
    private $_assetsUrl;
    private $_clientScript;
    private $_script;

    private $_openTag;
    private static $_counter = 0;
    ...

Metódusok

A widget-ben public (publikus) és protected (védett) metódusokat fogunk használni attól függően, hogy megengedjük-e a metódushoz való hozzáférést az osztályon kívülről.
A publikus metódusok egy része az un. getter/setter (olvasás/írás) kategóriába tartoznak, és arra szolgálnak, hogy a paraméterek bekérése vagy beállítása során kódrészleteket hajtsanak végre, mellyel befolyásolni tudják a paraméterek értékeit.
A "publikusok" másik része pedig vagy automatikusan kerül majd meghívásra, vagy pedig az ebből a widget-ből származtatott új widget-ekben lehet majd használni őket.
Nos, ha eddig nem volt eléggé hosszadalmas és unalmas a cikk, akkor most jön a java, mert elkezdem magyarázgatni, hogy mit is csinálnak az egyes metódusok.

init

A publikus init metódus nevéhez hűen inicializálja a widget paramétereit. Egy sima widget esetében nem kellene az inicializálást így szétdarabolni több almetódusra, ám ez egy speciális eset, mivel a jQTBaseOverlay widget alapnak készül, amiből majd az újabb widget-eket származtatni fogjuk. Ennek fényében már nem is olyan furcsa, hogy ennek a widget-nek egyáltalán nincs is megjelenése a view-ban.
Tehát ez a metódus meghívja a következő almetódusokat:

    ...
    public function init() {
        $this->initHtmlOptions();
        $this->initParams();
        $this->registerScriptFiles();
        $this->getScript();
    }
    ...

run

Ez a metódus ezúttal üresen marad. Pusztán annyi a szerepe, hogy majd a leszármaztatott widget-ben elővegyük. Egyébként a widget-ben ez a metódus futtatja le magát a widget-et.

...
    public function run() {

    }
    ...

getId

Ez a metódus az _id paraméter értékét állítja be, vagy adja vissza attól függően, hogy az autoGenerate bemeneti paraméter értéke false (hamis), vagy true (igaz).
Ha automatikusan kell előállítania az értéket, akkor fogja az osztály nevét, hozzáfűz egy kötőjelet, és a _counter változó eggyel megnövelt értékét, majd ezt a string-et visszaadja.

    ...
    public function getId($autoGenerate = true) {
        if(null !== $this->_id) {
            return $this->_id;
        } elseif($autoGenerate) {
            return $this->_id = get_class($this) . '-' . (self::$_counter++);
        }
    }
    ...

setId

A metódus cask annyit csinál, hogy a value bemeneti paramétert átadja a _counter változónak.

    ...
    public function setId($value = null) {
        if(null !== $value) {
            $this->_id = $value;
        }
    }
    ...

getAssetsUrl

Megvizsgálja, hogy az _assetsUrl paraméternek van-e már értéke. Ha nincs, akkor bekéri a Yii alkalmazástól az assetManager hivatkozását, aztán megállapítja, hogy hol van a widget állományunk, és hozzáfűzi a "/assets" stringet. Ha ezekkel végzett, publikálja a widget-hez tartozó CSS, javascript, és egyéb állományokat, majd beállítja az _assetsUrl értékét. Ezután már csak annyi van hátra, hogy felszabadítsa az assetManager változó által lefoglalt memóriát és visszaadja a beállított _assetsUrl-t.

A publish metódus utolsó paramétere (YII_DEBUG) azért van megadva, mert ha a fejlesztői szakaszban vagyunk, akkor minden alkalommal publikálni kell a widget "tartozékait", hisz a rendszer nem tudja, hogy mit változtattunk a feljesztés közben. Ha az oldal már kint lesz a neten, és üzemel, akkor természetesen már nem kell majd minden alkalommal publikálni a cuccokat, és ezt a YII_DEBUG be is állítja helyettünk, tehát nem kell majd feltúrni az összes widget kódját, hogy átkapcsoljuk az erőltetett publikálást.

A "tartozékok" kezelésének megértéséhez tudom ajánlani a cikket.

    ...
    public function getAssetsUrl() {
        if(null === $this->_assetsUrl) {
            $assetManager = Yii::app()->getAssetManager();
            $path = dirname(__FILE__) . '/assets';

            $this->_assetsUrl = $assetManager->publish($path, false, -1, YII_DEBUG);

            unset($assetManeger);
        }

        return $this->_assetsUrl;
    }
    ...

getClientScript

Ó, igen. Kelleni fog a _clientScript is, amit ez a metódus állít be. Persze csak akkor, ha még nincs beállítva.

    ...
    public function getClientScript() {
        if(null === $this->_clientScript) {
            $this->_clientScript = Yii::app()->getClientScript();
        }

        return $this->_clientScript;
    }
    ...

getScript

A _script paraméter értékét is elő kell állítani, hogy aztán majd hozzá lehessen fűzni az oldal végéhez.
Ha még nincs beállítva az értéke, akkor egy üres tömbbe beleteszi a params, majd az events értékeit. Mindezt úgy csinálja, hogy összefűzi a két paraméter értékeit, mert a jQery Tools Overlay plugin-je úgy lett megírva, hogy egy objektumban fogadja a beállításokat, és az eseményeket. Ha ezzel megvan akkor még azt is megvizsgálja, hogy akarunk-e mask-ot tenni a megjelenítendő panel mögé. Ezek után már csak annyi a dolga, hogy az összefűzött tömböt átalakítsa a javascript számára "emészthető" formára, aztán elkészítse a javascript-et, amihez még a trigger paramétert is felhasználja, s végül az így összerakott javascript string-et adja vissza.

    ...
    public function getScript() {
        if(null === $this->_script) {
            $params = array();
            $params = CMap::mergeArray($this->params, $this->events);
            if($this->useMask) {
                $params['mask'] = CMap::mergeArray($this->maskParams, $this->maskEvents);
            }
            $params = CJavaScript::encode($params);
            $this->_script = '$("#' . $this->trigger . '").overlay(' . $params . ');';
        }

        unset($params);

        return $this->_script;
    }
    ...

setScript
Persze arra is lehetőséget kell adni, hogy ne csak automatikusan lehessen beállítani a _script értékét. A metódus kap egy értéket, amit átad, és ezzel meg is van a dolog.

    ...
    public function setScript($value = null) {
        if(null !== $value) {
            $this->_script = $value;
        }
    }
    ...

initHtmlOptions
Ahol javascript van, ott bizony nem árt, ha a HTML elemeknek adunk nevet, azaz id-t, hogy könnyen és gyorsan azonosíthatóak legyenek. Ha a widget véletlenül nem kapna id-t, akkor majd ad saját magának. Ugyanezt megcsinálja a name HTML paraméterrel is. Végezetül pedig még arról is gondoskodik, hogy ha netán nincs CSS osztály hozzárendelve a widget-hez, akkor ad neki. Mindezt a htmlOptions paraméterben tárolja el a widget.
    ...
    protected function initHtmlOptions() {
        if(!isset($this->htmlOptions['id'])) {$this->htmlOptions['id'] = $this->getId();}
        if(!isset($this->htmlOptions['name'])) {$this->htmlOptions['name'] = $this->getId();}
        if(!isset($this->htmlOptions['class'])) {$this->htmlOptions['class'] = 'overlay';}
    }
    ...
initParams
Ez a metódus az egész widget legizmosabb metódusa. röviden összefoglalva arról gondoskodik, hogy a params, az events, a maskParams és a maskEventsparaméterek megkapják a kezdeti, vagy alapértelmezett értékeiket.Ha a "close", "target" elemek be vannak állítva, akkor az értékük elé odateszi a "#" jelet, mert ez a két paraméter HTML id (azonosító), amit a jQuery a CSS szelektorok szabályai szerint ismer fel.Ha a "top" értéke nincs megadva, akkor beállítja "center"-re. A jQuery Tools-ban az Overlay "top" paramétere alapértelmezésben "10%". Ezt az értéket saját hatáskörben felülírtam, hogy függőlegesen is középre igazítsa a megjelenítendő panelt.A következő lépés az, hogy megnézi, hogy az Overlay saját eseményei be vannak-e állítva. Ha igen, akkor leszedi előlük a "js:" szöveget, mert ez a Yii-ben szokásos jelölés, aminek a végeredményben nem szabad benne lennie.Ezutan néhány alapértelmezett érték beállítása következik a "mask" paraméterein, de csak abban az esetben, ha nincsenek megadva ("closeSpeed", "color", stb).A metódus utolsó blokkja ismét eseményekkel foglalkozik, csak ezúttal nem a panel eseményeivel, hanem a mögötte megjeletethető mask eseményeivel.    ...
    protected function initParams() {
        if(isset($this->params['close'])) {$this->params['close'] = (strpos($this->params['close'], '#') !== 0 ? '#' : '') . $this->params['close'];}
        if(isset($this->params['target'])) {$this->params['target'] = (strpos($this->params['target'], '#') !== 0 ? '#' : '') . $this->params['target'];}
        if(!isset($this->params['top'])) {$this->params['top'] = 'center';}

        if(isset($this->events['onBeforeLoad'])) {$this->events['onBeforeLoad'] = (strpos($this->events['onBeforeLoad'], 'js:') !== 0 ? 'js:' : '') . $this->events['onBeforeLoad'];}
        if(isset($this->events['onLoad'])) {$this->events['onLoad'] = (strpos($this->events['onLoad'], 'js:') !== 0 ? 'js:' : '') . $this->events['onLoad'];}
        if(isset($this->events['onBeforeClose'])) {$this->events['onBeforeClose'] = (strpos($this->events['onBeforeClose'], 'js:') !== 0 ? 'js:' : '') . $this->events['onBeforeClose'];}
        if(isset($this->events['onClose'])) {$this->events['onClose'] = (strpos($this->events['onClose'], 'js:') !== 0 ? 'js:' : '') . $this->events['onClose'];}

        if(!isset($this->maskParams['closeSpeed'])) {$this->maskParams['closeSpeed'] = 'normal';}
        if(!isset($this->maskParams['color'])) {$this->maskParams['color'] = '#000000';}
        if(!isset($this->maskParams['loadSpeed'])) {$this->maskParams['loadSpeed'] = 'normal';}
        if(!isset($this->maskParams['maskId'])) {$this->maskParams['maskId'] = '#overlay-mask';}
        if(!isset($this->maskParams['opacity'])) {$this->maskParams['opacity'] = 0.5;}
        if(!isset($this->maskParams['zIndex'])) {$this->maskParams['zIndex'] = 99;}

        if(isset($this->maskEvents['onBeforeLoad'])) {$this->maskEvents['onBeforeLoad'] = (strpos($this->maskEvents['onBeforeLoad'], 'js:') !== 0 ? 'js:' : '') . $this->maskEvents['onBeforeLoad'];}
        if(isset($this->maskEvents['onLoad'])) {$this->maskEvents['onLoad'] = (strpos($this->maskEvents['onLoad'], 'js:') !== 0 ? 'js:' : '') . $this->maskEvents['onLoad'];}
        if(isset($this->maskEvents['onBeforeClose'])) {$this->maskEvents['onBeforeClose'] = (strpos($this->maskEvents['onBeforeClose'], 'js:') !== 0 ? 'js:' : '') . $this->maskEvents['onBeforeClose'];}
        if(isset($this->maskEvents['onClose'])) {$this->maskEvents['onClose'] = (strpos($this->maskEvents['onClose'], 'js:') !== 0 ? 'js:' : '') . $this->maskEvents['onClose'];}
    }
    ...
registerScriptFiles
Ahhoz, hogy a widget kinézetét befolyásolni tudjuk, érdemes hozzáfűzni egy CSS állományt, amiben kényelmesen meg tudjuk határozni a megjelenését. Ezen kívül a jQuery Tools-nak szüksége van magára a jQuery-re, illetve saját magára. Ezeket az állományokat "pakolja" ki ez a metódus a megjelenítendő HTML lapba.    ...    protected function registerScriptFiles() {
        $url = $this->getAssetsUrl();

        $cs = $this->getClientScript();
        $cs->registerCssFile($url . '/css/' . 'overlay.css');

        $cs->registerCoreScript('jquery');
        $cs->registerScriptFile($url . '/js/' . 'jquery-tools.min.js', CClientScript::POS_HEAD);

        unset($cs);
    }
    ...

registerClientScript
E metódus egyetlen faladata az, hogy a "legyárott" javascript-et befűzze az oldal végére.
    ...
    protected function registerClientScript() {
        if(!isset($this->_script)) {
            return false;
        }

        $cs = $this->getClientScript();

        $cs->registerScript(__CLASS__ . '#' . $this->_id, $this->getScript(), CClientScript::POS_READY);

        unset($cs);
    }
    ...
renderBegin
És elérkeztünk végre ahhoz a ponthoz, amikor a beállítások, alapértelmezett értékek és egyéb előkészületek után végre megjeleníthetjük magát a kész widget-et. Első lépésben kiírjuk a megjelenítő pufferbe a widget kezdő részét.    ...
    protected function renderBegin() {
        ob_start();
        ob_implicit_flush(false);
        echo "\n" . CHtml::openTag($this->tagName, $this->htmlOptions) . "\n";
        echo CHtml::tag('div', array('class' => 'close'), 'X', true) . "\n";
        if(null !== $this->title || '' !== $this->title) {
            echo CHtml::tag('h3', array('class' => 'title'), CHtml::encode($this->title), true);
        }
        $this->_openTag = ob_get_contents();
        ob_clean();
    }
    ...
renderEnd
A megjelenítés második része pedig a widget tartalmának és végének kiírása és a puffer egészének kiküldése a böngészőbe.    ...
    protected function renderEnd() {
        $content = ob_get_clean();
        echo $this->_openTag;
        echo trim($content);
        echo "\n" . CHtml::closeTag($this->tagName) . '' . "\n";
    }
    ...
Hú, ez jó hosszú volt eddig, és még nincs vége a dolognak. Odáig jutottunk, hogy elkészült az alap widget, amiből majd származtatni fogjuk az Overlay egyes változatait. Ahogy azt illik, nézzük meg a teljes kódot egyben!

protected/components/widgets/jQTBaseOverlay.php
protected/components/widgets/assets/css/overlay.css
protected/components/widgets/assets/js/jquery-tools.min.js

"Mára ennyit a tudomány, és a technika érdekességeiből" - szokták volt mondogatni anno a Delta c. műsorban.

Tudom, kicsit hosszúra sikeredett a dolog, de talán akad majd egy-két hasznos információ benne, amiért érdemes végigolvasni!

A következő részben már olyan widget-et fogunk készíteni, ami ebből származik, és ígérem, sokkal rövidebb lesz a kód is, és a leírás is, ami hozzá tartozik.

MVC Model-View-Controller avagy Modell-Nézet-Vezérlő

2011-03-08T01:00:00.000-08:00

Model-View-Controller (MVC)

A Yii a model-view-controller (MVC / modell-nézet-kontroller/vezérlő) tervezési mintát valósítja meg, ami webprogramozás terén széleskörűen alkalmazott. Az MVC célja elválasztani az üzleti logikát a felhasználói felülettel kapcsolatos elgondolásoktól oly módon, hogy a fejlesztők minél könnyebben változtathassák meg az egyes részeket anélkül, hogy a többire hatással lennének. Az MVC mintában
a modell képviseli az információt (adatot) és az üzleti logikát; a nézet tartalmazza a felhasználói felület elemeit, úgy mint szövegek, űrlapok; a kontroller/vezérlő pedig kezeli a modell és a nézet közti párbeszédet.

Az MVC mellett a Yii a 'front-controller'-t, más néven alkalmazást, is bevezeti, ami a felhasználói kérések feldolgozásához biztosít végrehajtási környezetet. Az alkalmazás feloldja a felhasználói kérést, majd továbbítja a megfelelő kontrollernek további feldolgozásra.

A következő ábra egy Yii alkalmazás statikus felépítését mutatja:

Egy Yii alkalmazás statikus felépítése

Egy tipikus munkafolymat

A következő ábra egy tipikus munkafolyamatot mutat, aminek során a Yii alklamzás egy felhasználói kérést kezel:

Egy Yii alklamazás tipikus munkafolyamata

   1. A felhasználó kérést intéz a következő URL-lel `http://www.example.com/index.php?r=post/show&id=1` a webszerver pedig a kérést kezelendő, végrehajtja a rendszertöltő `index.php` szkriptet.

   2. A rendszertöltő szkript létrehoz egy alkalmazás példányt, és futtatja.

   3. Az alkalmazás részletes információt kap a felhasználói kérésről a `request` nevű alkalmazás komponens-től.

   4. Az alklamazás meghatározza a kért kontroller-t és tevékenységet egy `urlManager` nevű alkalmazás komponens segítségével. A jelenlegi példában ez a `post` kontrollert jelenti, ami a `PostController` osztályra hivatkozik; a tevékenység pedig `show`, aminek a tényleges jelentését a kontroller határozza meg.

   5. Az alkalmazás példányosítja a kért kontrollert, hogy a továbbiakban kezelje a felhasználói kérést. A kontroller meghatározza, hogy a `show` tevékenység a kontroller osztályának `actionShow` metódusára vonatkozik. Ezek után a tevékenységhez kapcsolódó szűrőket hoz létre (pl.: hozzáférés ellenőrzés, benchmarking). A tevékenység végrehajtódik, ha a szűrők ezt engedélyezik.

   6. A tevékenység beolvassa az adatbázisból az `1`-es ID-jű `Post` modell-t.

   7. A tevékenység lefordítja a `show` nevű nézet-et a megadott `Post` modellel.

   8. A nézet kiolvassa és megjeleníti a `Post` modell tulajdonságait.

   9. A nézet végrehajt néhány kütyü-t.

   10. A nézetfordítási eredmény beillesztésre kerül az elrendezés-be.

   11. A tevékenység befejezi a nézet fordítást és az eredményt megjeleníti a felhasználónak.

Eredeti: http://www.yiiframework.com/doc/guide/1.1/en/basics.mvc
Fordította: Endyl

File feltöltés Modellen keresztül

2011-02-22T01:00:00.000-08:00

Először vegyünk fel egy új paramétert a Modell osztályunkban, ahol a file nevét fogjuk tárolni (a modellünk lehet Form vagy Active Record osztály is). Ezek után állítsunk be egy Validálási Szabályt, hogy biztosak lehessünk abban, hogy a felhasználó csak meghatározott kiterjesztésű file-okat tölthet fel.

Majd a Kontroller osztályunkban készítsük el azt a funkciót (action), ami a form-unk megjelenítéséért és a felhasználó által küldött adatok összegyűjtéséért lesz felelős:

Végül pedig a Nézetünkben állítsuk be a megfelelő file-feltöltő mezőt. (Megj: az enctype is fontos!)

Eredeti cikk: http://www.yiiframework.com/wiki/2/

Telepítés

2011-02-08T09:32:00.000-08:00

A Yii telepítése a következő két lépésből áll:

A Yii keretrendszer letöltése a http://www.yiiframework.com-ról.
A letöltött fájl kicsomagolása egy webről elérhető könyvtárba.

Tipp: Nem feltétlenül szükséges a Yii-t egy webről eléhető könyvtárba telepíteni. Minden Yii alkalmazásnak van egy belépési parancsfájlja és gyakorlatilag ez az egyetlen fájl, amit elérhetővé kell tenni web felhasználók számára.

A többi PHP parancsfájl, beleértve a Yii-hez tartozókat, jobb, ha nem elérhető a webről, mivel támadás célpontjává válhatnak.

Követelmények

A Yii telepítése után célszerű megbizonyosodni arról, hogy webszerverünk teljesít minden követelményt, ami a Yii használatához szükséges. Ez könnyen megtehető a követelmény-ellenőrző parancsfájl böngészőn keresztüli futtatásával, mely a következő URL-en érhető el:

http://hostname/path/to/yii/requirements/index.php

A Yii által támasztott alapkövetelmény egy webszerver, mely rendelkezik PHP 5.1.0 (vagy későbbi) támogatással. A Yii tesztelve lett http://httpd.apache.org-rel Windows és Linux operációs rendszereken. Minden bizonnyal más webszervereken is futtatható, feltéve, hogy rendelkezik PHP 5 támogatással.

Eredeti: http://www.yiiframework.com/doc/guide/1.1/en/quickstart.installation
Fordította: Endyl

Mi is a Yii?

2011-01-25T17:45:00.000-08:00

A Yii egy nagyteljesítményű, komponens alapú PHP keretrendszer nagyszabású
webalkalmazások fejlesztéséhez. Maximális újrahasznosíthatóságot tesz lehetővé
a webprogramozás terén, és a fejlesztési folyamatot is jelentősen meggyorsítja.
A Yii név (ejtsd: angolosan `Yee` vagy fonetikusan `[ji:]`) a következő szavakból
ered: *easy (egyszerű)*, *efficient (hatékony)* és *extensible (kiterjeszthető)*.

Követelmények

Egy Yii alapú webalkalmazás futtatásához egy webszerverre van szükség, mely
rendelkezik PHP 5.1.0 (vagy későbbi) támogatással.

Azoknak a fejlesztőknek, akik Yii-vel akarnak dolgozni, az objektum-orientált
programozás (OOP) megértése meglehetősen hasznosnak bizonyul, mivel a Yii egy
tisztán OOP keretrendszer.

Mire jó a Yii?

A Yii egy általános webprogramozási keretrendszer, ami voltaképpen felhasználható
bármilyen webalkalmazás fejlesztéséhez. Mivel könnyűsúlyú (light-weighted) és
kifinomult gyorsítótárazási megoldásokat nyújt, kifejezetten alkalmas nagy forgalmú
alkalmazások, úgy mint portálok, fórumok, tartalomkezelők (CMS), e-kereskedelmi
rendszerek, stb. fejlesztésére.

A Yii összehasonlítva más keretrendszerekkel

Mint a legtöbb PHP keretrendszer, a Yii egy MVC kertrendszer.

A Yii felülmúlja a többi a keretrendszert a következőkben: hatékony, képességekben
gazdag, és világosan dokumentált. A Yii a kezdektetől fogva komoly weblakalmazások
fejlesztésére lett tervezve. Nem egy projekt mellékterméke vagy netán harmadik féltől
származó kódok összefércelt változata, hanem a szerzők webalkalmazások fejlesztésében
és vizsgálatában szerzett tekintélyes tapasztalatának eredménye és a legnépszerűbb
webprogramozási keretrendszerek és alkalmazások tükröződése.

Eredeti: http://www.yiiframework.com/doc/guide/1.0/en/quickstart.what-is-yii
Fordította: Endyl

Yii Radiio 38. adás

2011-01-21T06:03:00.000-08:00

Halihó,

Mivel az új Yii Radiio oldalon már van automatikus fordítás (igen, magyarra is!) ezért nem fogom fordítgatni az egyes részeket, csak a Twitter-en keresztül osztom majd meg az új linket.

Itt a Yii 1.1.6-os

2011-01-17T10:35:00.000-08:00

Végre valahára itt van az 1.1.6-os változat. Személy szerint már nagyon vártam leginkább a beépített Adatbázis Migrációk miatt. Csak nagyjából nézzük mi van az új verzióban:

Újdonság:
- Adatbázis Migrációk
- DB Query építő (erről majd később próbálok valamit összerakni)

Változott:
- A filterek használata esetén a CGridView az első oldallal tér vissza.
- A $live paraméter változtatható az $htmlOptions-on keresztül (CHtml::clientChange()).

Javítások:
- PHP hibaüzenet CJuiDatePicker::$name használatánál.
- CActiveForm felesleges focus() JavaScript kódja.

A változtatások teljes listáját itt találhatjátok: http://www.yiiframework.com/files/CHANGELOG-1.1.6.txt

Egy Modell Validálási Esetei

2011-01-11T01:00:00.000-08:00

Ha valakinek van ötlete, hogy lehetne a Validation Scenarios-t szépen magyarra fordítani, ne kíméljen (talán Értékellenőrzési Forgatókönyv-nek vagy Szabályozási Szintek-nek?).

Az 1.0.2-es megjelenése óta lehetőségünk van különböző Validálási Eseteket (Validation Scenario) beállítani modelljeinkhez. Ez nagyon hasznos olyan esetekben, amikor az alkalmazásunk több pontján lehet/kell egy modellen keresztül adatot bekérni a felhasználótól.

Például egy új felhasználó regisztrálásánál valószínűleg a 'felhasználónév' az 'email cím' és a 'jelszó' mezők kötelezőek, míg az 'elfelejtett jelszó' oldalon talán csak az 'email cím'. Itt egyből látszik, hogy ha mind a három mező kötelező alap esetben, akkor az 'elfelejtett jelszó' funkció nem igazán fog működni, hiszen ha felhasználóbarátok akarunk maradni, akkor nem fogjuk bekérni sem a felhasználónevet sem pedig a jelszót (amit úgyis elfelejtett a kedves kis felhasználó ;) )

Tehát hasonló problémákra kínál tökéletes megoldást a Validálási Esetek használata amiket nagyon egyszerűen állíthatunk be az 'on' paraméterrel a különböző modell szabályokhoz (rules). Az 'on' paraméter talán már ismerős lehet adatbevitelnél (insert) vagy frissítésnél (update) attól függően, hogy melyik mentést (save) használjuk. Elég gyakran ez a kettő nem elég sajnos, viszont ennek az új megoldásnak köszönhetően akarmennyit készíthetünk. Nézzünk is egy példát:
protected/model/User.php

Ezekkel a beállításokkal Yii már tudni fogja, hogy mikor melyik Szabály fusson le. A példa kedvéért persze betettünk egy-két extra szabályt is. Remélhetőleg a megjegyzések elolvasása után már jobban érthető, hogy mire is jó ez az egész. Az összehasonlító (compare) szabálynál látni, hogy több Szintet is meg lehet adni vesszővel elválasztva (pl: 'register,update').

Tehát ha egy modell ellenőrzését (CModel::validate()) szeretnénk elvégezni, egyszerűen adjuk át a Validálási Esetet paraméterként:

Az eredeti cikk, Jonah által: http://php-thoughts.cubedwater.com/2009/validation-scenarios/

Auto TDD avagy PHPUnit magától

2010-12-28T01:00:00.000-08:00

Ez a kis tipp nemcsak Yii fejlesztőknek ajánlott, hanem akárkinek aki a PHPUnit-ot használ Linux-os környezetben. (elvileg Apple-lel is működnie kell, de nem próbáltam!) -- Javítás: NEM MŰKÖDIK Apple-lel!

A következő egyszerű utasítással 15 másodpercenként lefuttathatjuk egységtesztjeinket. (protected/tests)

watch -n 15 -d phpunit unit/

Az én képernyőm valahogy így néz ki (bal sarokban fut a teszt!)

Katt nagyobb képhez!

Nagyobb tesztek esetén persze lehet finomítani, hogy csak 1 teszt file fusson .., stb.

Az eredeti cikk itt található: http://www.yiiframework.com/wiki/124/auto-tdd-how-to-auto-run-phpunit/

A ChromePHP használata Yii alatt

2010-12-21T01:00:00.000-08:00

Ha valakinek valamilyen oknál fogva nem tetszene a Yii által kínált naplózási (logging) rendszer, annak jól jöhet ez a kis kiegészítő. Kifejezetten a Chrome böngészőre készült és ChromePHP a neve.

Először is installáljuk a magát a ChromePHP kiegészítőt a böngészőnkre innen. Majd töltsük le a ChromePHP osztályt és másoljuk be a ZIP tartalmát a protected/vendors alá. Miután ezzel megvagyunk, módosítsuk a konfigurációs file-unkat (protected/config/main.php)

És készen is lennénk. A Log (bejegyzés), Warning (figyelmeztetés) és Error (hiba) utasításokat pedig a következő képpen futtathatjuk:

ChromePHP::log('Hello Virág!');
ChromePHP::warn('Figyelmeztetés!');
ChromePHP::err('Hiba!');

Jó naplózgatást ;)

Az eredeti cikket itt olvashatjátok: http://www.yiiframework.com/wiki/119/chromephp-for-yii/

ui: persze csak fejlesztés közben ajánlatos használni!

Yii Radiio 37. adás

2010-12-14T10:22:00.000-08:00

Idei utolsó (37.) adásunk, valamikor Január közepe-vége fele jövünk vissza, az 1.1.6-os változat megjelenése után.

Nagyon szépen köszönjük minden hallgatónknak, hogy havonta kétszer figyelmet és időt szentelnek a műsornak, külön köszönet a magyar Larry Hangman zenekarnak, akik a műsor zenéjét "kölcsönözték" nekünk.

Ezen kívül természetesen a Yii keretrendszer fejlesztőinek és szponzorainknak jár köszönet, akik nélkül nem lenne ilyen sikeres a műsor.

Szponzorunk ebben a hónapban az Ext4Yii, akik az ExtJS modul segítségével a Yii rendszert a "nagycéges-fellegek" közé segítik.

Nos, tehát, namégegyszer:

Simon Fraser élményei a és csalódásai avagy CodeIgniter a Yii ellen.

MongoDB-ről már jónéhányszor esett szó, ez egy újabb, talán a legkiforrottabb, kiegészítő a Yii-hez, Canni által, YiiMongoDBSuite.

Jeffrey Winesett újabb videója, a klasszikus "Hello World!" megvalósítása.

TipsTank mutatja be, hogyan gyorsítsuk fel HTML és CSS kódolási technikánkat a PHaml segítségével.

Megjelent az Ext4Yii 0.7-es verziója.

8 szakember véleménye (jó és rossz!) a PHP-ről általában.

Ugye milyen jó lenne, ha minden böngészővel lehetne HTML5 tag-eket (audio, video) használni? Na, most már lehet: http://mediaelementjs.com

A hét oldala: http://www.realself.com.

Na, és talán a legizgalmasabb dolog ami történt az elmúlt két hétben (szintén a hét oldalával kapcsolatos) ... 1.5 millió látogató egy hónap alatt, avagy 7 indok, miért váltsunk Drupal-ról Yii-re, Eric Kennedy-től.

Jó olvasgatást, és kellemes Ünnepeket :)

--
http://yiiradiio.mehesz.net

Felhasználó kezelés a Yii-User modullal

2010-12-07T01:00:00.000-08:00

Alap esetben Yii egy olyan felhasználó (user) rendszerrel lát el bennünket, amit éles helyzetben nem nagyon ajánlatos használni. (pl.: felhasználónév = jelszó). (Persze ez csak példaként van a rendszerben)

Ha szeretnénk valami komolyabb, biztonságosabb és adatbázissal támogatott megoldást használni, kétféle lehetőségünk van. Vagy magunk írjuk meg a szükséges kódot, vagy letöltünk egy modult. Ebben az írásban a Yii User modult szeretném ismertetni. (Tudom, hogy van egy másik Yii User Management, de Yii User-nek nemrég jött ki egy újabb verziója Mishamx klaviatúrájából. Ja, és még egy remek kis logója is van ;) )

A modul segítségével felhasználóink regisztrálását és kezelését könnyíthetjük meg. Jelenleg a következő funkciók támogatottak:

Felhasználó beléptetése email-lel vagy névvel
Registráció
Felhasználói fiók aktiválással (email-en keresztül)
Saját felhasználói oldal (profile page)
Adminisztrátorkodás
Mezők kezelése a felhasználói form-on
Popup Dátum kezelő widget (jQueryUI datepicker-rel)
File feltöltő widget
Felhasználók kapcsolatai widget
API

Installálás

Csomagoljuk ki a letöltött file-t az <project>/protected mappába.

Állítsuk be a modult a config/main.php file-ban a következő képpen:

Beállítások

Az adatbázisunkban készítsük el a modulhoz szükséges táblákat. (a dump file-ok segítségével: schema.mysql.sql és schema.sqlite.sql)

És végül változtassuk meg a menüt a protected/views/layouts/main.php file-ban:

A részletes leírást és a paraméterek listáját itt találjátok: http://code.google.com/p/yii-user/w/list

Az eredeti oldalt pedig itt: http://www.yiiframework.com/extension/yii-user/

Yii Radiio 36. adás

2010-11-30T01:00:00.000-08:00

Bob Belderbos mondja el saját szavaival, hogy miért is tetszik neki a Yii ennyire.

Talán egy éve már, hogy említettük a Chive-ot, ami a PHPMyAdmin-t próbálja letaszítani a MySQL-kezelőfelületek trónjáról, persze mindenki döntse el saját maga. Nemrég jelent meg a 0.4-es változat, ha másért nem is, azért érdemes kipróbálni, mivel Yii-fel készült.

A ScrollingNews segítségével készíthetünk jQuery-vel hajtott tartalom lapozgató finomságokat.

Aztech próbálkozik egy új(abb) fajta SPAM megelőzéssel, illetve az ötlet nem új, de Yii alá most került ilyesmi először. (megj: én mondjuk személy szerint a ReCaptcha-t használgatom, viszont ehhez nem kell semmit betölteni.)

A Free Open Source Magazine-ban jelent meg egy cikk a Yii-ről.

Ryan Lahue megoldása a "{Model} cannot be blank" hiba üzenetre.

Jeff Winesett, a Yii könyv írója, indított útjára egy VIMEO sorozatot: 1. rész, Előkészületek.

Larry Ullman neve már remélem sokaknak ismerősen cseng, a kezdőknek szánt sorozata egyre népszerűbb a Yii-t használó programozók táborában. Gyakran kérdezgetik is, miért éppen a Yii-t használja. Most végre elmonta :) (megj: a kedvencem - "A keretrendszerek olyanok mint az autók. Mindegyikkel eljutsz ahová menni akarsz, csak az a kérdés, melyikben érzed jól magad.")

Végre sikerült az OpenSearch kereső alkalmazást a yiiframework.com-ra "telepíteni". Ez annyit jelent, hogy egyszerűen a böngészőnkből kereshetünk Yii oldalon található dolgokat.

WebEnabled támogatja a Yii-t (1.1.5). Az oldal segítségével néhány klikkolással készíthetünk Yii alapokra épülő alkalmazást, SVN forráskezelővel (a Git az úton van), SSH hozzáféréssel és egy linkel, amit a felhasználóinknak tudunk adni, tesztelésre. Ja, és mindezt ingyenesen! (egyébként Yii az első keretrendszer, eddig többnyire CMS-eket és CRM-eket támogattak)

Hogy lehetne még gyorsabban és eredményesebben dolgozni? Mi az a Kanban?

A hét oldala: egy brazil horgász oldal: http://revistapescaesportiva.com.br

Adatbázis migrációk a Yii-vel

2010-11-22T01:00:00.000-08:00

A Rails keretrendszernek köszönhetően az elmúlt pár évben nagy teret hódított az Adatbázis Migrációk (Migrations) használata, még PHP-s környezetben is. Személyesen hallottam olyanról, hogy míg az egész rendszer PHP alatt futott, a programozók a Rails-t használták táblák és kapcsolatok készítésére.

Persze több kevesebb sikerrel megjelentek PHP-vel hajtott alkalmazások is, az egyik ilyen pl. a Doctrine Project. Ebben a cikkben azonban a Pieter Claerhout által publikált, és a Yii alá készített Yii-DbMigrations-t fogjuk ismertetni.

Mire jó ez egyáltalán?

Felmerülhet a kérdés, hogy miért is van szükség ilyen rendszerek használatára. A felvetés jogos, hiszen sima SQL-t használva is készíthetünk táblákat és kapcsolatokat. Valóban, viszont az így készített ún. tábla leírások (schema) kifejezetten az adott adatbásban működnek.

Képzeljük el például, hogy a fejlesztés kezdetén SQLite-ot használtunk és késöbb szeretnénk az adatbézisunkat MySQL alá tenni (mondjuk a LIVE szerveren). Sajnos ilyen esetben az összes tábla leírást újra kell készítenünk, mivel a két adatbázis motorban használt SQL nem kompatibilis. Itt jön a képbe az Adatbázis Migráció.

A lényeg az, hogy adtabázisleíró nyelvtől függetlenül tudunk táblákat és kapcsolatokat készíteni a PHP segítségével. Az így elkészített tábla osztályokat pedig nagyon egyszerűen a kívánt (és támogatott!) adatbázis alá be lehet illeszteni. Külön hab a tortán, hogy arra sem kell emlékeznünk, hogy melyik volt az utolsó lefuttatott tábla osztály, mindezt a Yii-DbMigartions elvégzi helyettünk. Úgy is gondolhatunk rá, mint egy adatbázisra szabott Forráskezelő program (pl: SVN vagy GIT)

Hátrányok

A modul még csak alpha állapotban van.
Jelenleg csak SQLite és MySQL támogatott.

Installálás és Beállítás

Miután kicsomagoltuk a zip file-t a szokásos helyre - protected/extensions, győződjünk meg arról, hogy az adatbázissal kapcsolatos beállítások megfelelőek a protected/config/main.php-ben.

MySQL:

SQLite:

A Parancssor beállítása

Alap esetben természetesen a yiic nem tud a migrate utasításról, hiszen még csak most telepítettük a modult. Ezért be kell állítanunk egy új commandMap-et a protected/config/console.php file-ban:

Beállítások tesztelése

Ha minden jól sikerült, egyszerűen futtassuk le a yiic parancsot a parancssorból:

Reméljük így a migrate parancs már elérhető.

Migrációk készítése

Nevvekkel kapcsolatos korlátozások

A migrációs file-okat a protected/migrations vagy a migrations mappába (a modul könyvtárába) helyezhetjük el. Az file-ok neveit pedig a következő képpen ajánlatos elnevezni:

m20090614213453_MigracioNeve.php

A névnek mindig egy 'm' betűvel kell kezdődnie, utána egy 14 karakter hosszú dátumot meghatározó string, egy aláhúzásjel '_' és végül pedig egy szabadon választható MigrációNév.

Persze, szerencsénkre, ezt automatikusan is megtehetjük a protected/yiic migrate create <MigracioNev> lefuttatásával:

Táblaleírások készítése

Magában a tábla leíró file-ban létre kell hoznunk egy osztályt, aminek a szülő osztálya a CDbMigration, és két kötelező metódusunk az up és down lesz. Reméljük a következő példa kicsit segíteni fog:

Tehát az up() segítségével elkészítjük az új táblát, a down()-nal pedig töröljük.

Támogatott funkciók

A migráció osztályban a következő funkciók érhetők el:

execute: sima SQL futtatása, ami nem ad vissza értéket.
query: sima SQL futtatása, ami értékkel tér vissza.
createTable: új tábla készítése
newTable: új tábla leírás készítése
addTable: táblaleírás hozzáadása a migrációhoz
renameTable: tábla átnevezése
removeTable: tábla törlése
addColumn: oszlop hozzáadása a táblához
renameColumn: oszlop átnevezése
changeColumn: oszlop változtatása
removeColumn: oszlop törlése
addIndex: index hozzáadása táblához vagy adatbázishoz
removeIndex: index törlése táblából vagy adatbázisból.

Mezőleíró beállításoknál pedig a következő változók használhatók:

primary_key
string
text
integer
float
decimal
datetime
timestamp
time
date
binary
boolean
bool

Persze ezen kívül lehet adatbázis specifikus mezőket is készíteni, viszont úgy nem tudjuk a programot más adatbázis alá (könnyedén) átemelni.

Táblák készítése másként

Migrációk futtatása

Csak azért mert elkészítettük a tábla-leírásokat, az nem azt jelenti, hogy a táblák már készen is vannak az adatbázisban. A migrate parancs lefuttatásával történik meg mindez:

Még itt a végén annyit érdemes megjegyezni, hogy ha most lefuttatnánk a migrate parancsot mégegyszer, semmi nem történne, hiszen a modul megjegyzi, hogy melyik volt az utolsóként lefutott migráció.

És ennyi! Mindenképpen javaslom az eredeti cikk elolvasását is, mert ott még van egy-két utasítás amire nem tértünk itt ki, de remélem ezek után mindenkinek megjön a kedve egy kis adatbányászáshoz :)

https://github.com/pieterclaerhout/yii-dbmigrations

Yii Radiio 35. adás

2010-11-16T01:00:00.000-08:00

Megjelent a Yii 1.1.5-ös, sok javítással és mégtöbb újdonsággal. A változtatások listája ezen a linken található meg.

Nagy port kavart fel Qiang azon bejelentése, miszerint a Yii 2.0-át a PHP 5.3 alapjaira építve teljesen újraírják, és nem lesz kompatibilis a régebbi (1.1, 1.2) ágakkal. (mondjuk szvsz ez teljesen egyértelmű). A kiabálókhoz a fórumon lehet csatlakozni.

Ramirez Cobos mutatja be, hogyan használhtajuk az SWFUpload-ot, ami egy Flash meghajtott file-feltöltő rendszer.

Christian Montoya irása a BluePrint CSS rendszer-ről, amit egyre gyakrabban választanak designerek, weboldalak (pl: http://mint.com, http://stay.com vagy a http://dailymotion.com).

Az 5 (6-7-8) legfőbb ok a Yii mellett (ChruchCO szerint: Demók, Tesztelés, Közösség, Kiterjesztések, Dokumentáció, Forrás (egyszerűen jó ránézni), Active Record és Scope-ok kezelése )

Larry Ullman ismerteti a Zend keretrendszerben már jól ismert (Apache) Lucene kereső Yii-re történő implementálását.

Üdvözlünk két újabb bloggert a Yii torpedó-hajó fedélzetén (Kyokasuigetsu, Mushfiq) akik többek között azt is megírják miért váltottak egyéb rendszerekről (pl. CodeIgniter és Symfony). A blogokat itt meg itt olvashatjátok.

Ha valaki már kicsit járatos a Yii felépítésében az biztosan tudja, hogy hol található (és mire való) az assets mappa. Néhány kivételes esetben azonban szükség lehet rá, hogy ezt máshova tegyük. Ezt magyarázzal el Dana Luther ebben a blog post-ban.

Ha valakinek (még mindig) gondot okozna, hogy melyik MVC-re alapuló PHP keretrendszert válassza, annak hasznos lehet Jorges Albaladejo tesztje, aki több más rendszert is megvizsgál és próbál segítséget nyújtani a PHPs közösségnek.

SamDark mutatja be, hogyan lehet cron alkalmazásokat futtatni Yii-n keresztül.

Ha valakinek sürgős segítségre van szüksége valamilyen Yii-vel kapcsolatos problémara, és nincs ideje (türelme?) a fórum látogatóinak válaszára várni, annak érdemes kipróbálnia a #yii IRC csatornát, ahol naponta több mint 30-40 lelkes Yii programozó próbál egymásnak segítséget nyújtani.

Semmiképp nem szeretnénk pletykát indítani, de egyre többet hallani a MySQL és Oracle háza táján történő bizonytalanságokról. Az adatbázis motor lecserélését segítheti elő a MariaDB, amit egy az egyben arra találtak ki, hogy a MySQL-t leváltsa. (állítólag néhai MySQL programozók találták ki). Mindenképp érdemes rá odafigyelni.

A hét oldala: bumperize.com, akik arra vetemednek, hogy a már jól megszokott szöveges alapó email-jeinket felcsinosítsák.

----------------------------------------------------------------------------------------------------------
eredeti: http://yiiradiio.mehesz.net/episode-35

Hogyan fűszerezzük Yii proginkat a már jól bevált ImageCache-sel

2010-11-09T01:00:00.000-08:00

Ha valaki már régóta tevékenykedik a "szakmában" az biztosan tudja, hogy egy oldalon megjelenő képeknek az átméretezését még azelött jó megtenni, mielött a kép a böngészőbe kerül. Például, mi történik akkor, ha a képünk 3000x2000 pixeles, és azt 300x200-as méretben szeretnénk megjeleníteni:

<img src="valami.jpg" width="300" height="200" />

A fenti sorral többek között az a gond, hogy az ember azt gondolná (reméljük nem, de lehet), hogy a böngésző ilyenkor csak egy ekkorka képet tölt le. Sajnos ez nem igaz, tehát a felhasználóinkat (és a szerverünket) büntetjük azzal, hogy a böngésző egy hatalmas, alkalmanként több MB-os képet tölt le. A Drupal CMS rendszerben van egy úgy nevezett ImageCache modul, ami pontosan erre kínál megoldást.

Hwangar-nak köszönhetően ez a modul már elérhető a Yii rendszerben is, így néhány "képmegváltoztató" funkcióval lényegesen felgyorsíthatjuk oldalaink betöltését. Ez a cikk azt próbálja bemutatni, hogy hogyan is tehetjük meg mindezt.

Az ImageCache modul segítségével (GD2 szükséges hozzá!) többek között átméretezhetjük, elforgathatjuk és vízjeggyel láthatjuk el képeinket. Maga a beállítás egyszerűen megtehető az alkalmazásunk konfigurációs file-jában. (protected/config/main.php)

Beállítás:

Annyi féle preset-et készíthetünk, amennyit csak akarunk. A fenti példában, a 640x480-nak nevezett preset segítségével például először átméretezzük és vágjuk a képet (scaleAndCrop) majd pedig vízjegyet teszünk a képre (watermark). Az elkészített képeket a modul a webroot/<akarmi> könyvtárba helyezi el. Jelenleg a következő képmódosító funkciók támogatottak: újraméretezés (resize), zsugorítás (scale), zsugorítás és vágás (scaleAndCrop), elforgatás (rotate), vágás (crop) és vízjegy (watermark).

Használat:

Magát a képkészítő programot vagy a Kontrollerben (Controller) vagy a Nézetben (View) szokás meghívni a következő módon:

<?php

$thumb = Yii::app()->image->createUrl( '640x480',YiiBase::getPathOfAlias('webroot.files').'/valami.jpg'); // An image file!!!

if ($thumb) print $thumb; else print "bad";

?>

Még annyit érdemes megjegyezni, hogy amikor először jelenítjük meg a képet a modul segítségével (tehat a cache könyvtár üres!), akkor fut le maga a képszerkesztő program és készül el az új kép. A következőkben már ezt a képet töltjük be és jelenítjük meg, remélhetőleg gyorsabban.

Az eredeti leírás és maga a modul itt található: http://www.yiiframework.com/extension/image-cache/

(Egyébként ha valakinek van ötelete arra, hogy magyarul hogyan lehetne érzékeltetni a különbséget a resize és a scale között (lehetőleg egyszóval), azt szívesen venném ... köszi)

Yii Radiio 34. adás

2010-11-02T01:00:00.000-07:00

Sikerült néhány újabb template-t készítenünk és fel is tettük őket a Yii Themes oldalra. Reméljük tetszik az új lapozgató is.

Na, de nézzük mi történt az elmúlt hetekben a Yii körül:

BHushan részletezi több PHP keretrenszer előnyeit és hátrányait, köztük persze a Yii-t is.
Hasonló kategóriába tartozik az include-once.org által közzétett PHPs keretrendszer összehasonlító program, aminek segítségével könnyen fej-fej mellé tehetjük az összes jelenleg elérhető keretrendszert.
MongoDB-ről már esett szó párszor a Yii Radiio adásaiban, röviden egy Kulcs-Érték (Key-Value) alapokra épülő adatbázismotorról van szó. Ehhez próbál segítséget nyújtani a Tyohan által elkészített modell osztály, MongoRecord.
Ha valaki már többször járt a Yii oldalon, talán ismerősnek tűnhet Larry Ullman neve, aki a kezdetektől fogva támogatja a rendszert és népszerű sorozatát nagyon sokan elismerik. Végre sikerült frissítenie a leírásokat, a jelenlegi legújabb, Yii 1.1.4-re.
Remélem nem vagyok egyedül, de velem többször előfodult már, hogy az agyamban felmerülő megoldást probáltam kód formájában begépelni, de az ujjaim lassabak voltak mint maga a gondolat. Mit lehetne még kitalálni, azon kívül, hogy megtanulunk baromi gyorsan gépelni? A Tutsplus hasábjain probáltak 9 olyan dolgot összeszedni, ami a segítségünkre lehet. (pl: Zen kódolás, Osztott képernyő (Vim - hehe), LESS.js stb)
Talán szükségünk lehet arra, hogy az amúgy jól bevált Yii lapozgató rendszert átalakítsuk. (vagy csak egyszerűen tudni akarjuk, hogyan is működik). Ramirez Cobos kalaúzol el bennünket a Yii rejtett világába és mutatja be, hogyan tudjuk ezt megtenni.
Ha még csak most kezdünk ismerkedni a Yii rendszerrel, gyakran előfordul, hogy a Modell kapcsolatok megértése homályos lehet. Hungred.com próbálja mindezt elmagyarázni ezzel a post-tal.
WordPress a Yii-vel! Baptek meséli el nekünk miért is kellett nekik egy ilyen megoldás és milyen egyszerűen oldotta meg ezt a feladatot.
WillowDan2009 mutatja be, hogyan kell Windows alá a Yii 1.1.4-est feltelepíteni.
A Yii csapatának végre sierült befejeznie a már régóta esedékes új arculatot, új logóval és funkciókkal. A kedvenceink a Hall of Fame, és Badges (kitüntetések) :)
A hét oldala: Ha az interneten szeretnénk valamit eladni, néha jó tudni, mi mennyit ér. WothMonkey.com

Hogyan kezdjük?

2010-10-26T01:00:00.000-07:00

A Yii rendszert a kezdetektől fogva úgy tervezték, hogy WEB alapú alkalmazások készítését megkönnyitse. Ebben a postban megmutatjuk, hogyan lehet a legegyszerűbb egy alap, adatbázissal összekapcsolt programot elkezdeni.

0. lépés - Előkészítés

A Yii rendszer letöltése és installálása után, egyszerűen futtassuk le azt a konzol parancsot, ami elkészíti a WEB-es alkalmazásunk vázát. A program már ekkor is működőképes, olyan finomságokkal fűszerezve mint felhasználó beléptetés vagy kapcsolat felvételi űrlap. Ezekre az alapokra már szépen építhetünk bonyolultabb funkciókat a programunk számára.

1. lépés - Az adatbázis létrehozása

Amig Yii jelentősen lecsökkenti ismétlődő forráskód írását, az izgalmas rész, a kreatív munka ránk marad. Ez gyakran kezdődik adatbázis és táblák tervezésével.

2a. lépés - Yii elkészíti a Modell Osztályokat

Most a Yii rendszeren van a sor, hogy az előkészített adatbázis táblából használható PHP kódot készítsen. Ezt könnyen megtehetjük a rendszerbe épített, böngésző alapú kód generálóval (gii), aminek segítségével pillanatok alatt működő modell osztályokat készíthetünk, anélkül, hogy egy sort is gépelnünk kéne. Modell osztályokat használva az adatbázis táblák érhetők objektum osztályként.

2b. lépés - Yii elkészíti a CRUD kód alapokat

Az előzőekben említett kód generáló segítségével készíthetjük el a nagyon gyakran használatos CRUD funkciókat a kiválasztott adatbázis táblához. (Create azaz Létrehoz, Read - Beolvas, Update - Frissít, Delete - Töröl ).

Az elkészített forráskód természetesen személyre szabható, a jól ismert MVC (Model - Modell, View - Nézet, Controller - Vezérlő) szabályait betartva. Egyelőre eddig minden sort a Yii rendszer készített, még billentyűzethez nem kellett nyúlnunk.

3. lépés - Az elkészített kód testreszabása, finomítása

Az utolsó lépés, a Yii által elkészített forrás kód testreszabása. Például, hogy ne jelenítsük meg a jelszó oszlopot a listában, egyszerűen töröljük a jelszó mezőt az alábbi adminisztrációs nézet file-ban:

Hogyan tovább?

A fenti leírás persze csak egy nagyon kicsi bepillantást enged a Yii csodálatos világába. A következő logikus lépés lenne, hogy letöltsük a Yii keretrendszert, probáljunk ki egy vagy két példa programot, és csatlakozzunk a többiekhez a fórumon.

Két kis magyar példa:

Yiiki avagy WIKI a'la Yii - egy nagyon egyszerű, Yii alapokat bemutató alkalmazás, vagy
Környezetbarát Egységtesztelés Meztelencsigákkal - egy kicsit komolyabb példaprogram.

Sok sikert!

Yii Radiio 33. adás

2010-10-19T01:00:00.000-07:00

Végre itt van a már rég óta beharangozott interjú a Yii könyv szerzőjével, Jeff Winesettel. (maga az anyag angolul van, itt csak nagyjából összefoglaltam, miről beszélgettünk.)

Ez egy elég érdekes adás (#33), ugyanis mind terjedelmében, mind tartalmában eltér a megszokott formától, de nem kell aggodni, nem marad így ;)

Összefoglaló:

Többek között arról beszélgetünk, hogy Jeff és csapata (Control Group Inc.) miért választotta a Yii rendszert, hiszen nagyon sok hasonló PHPs progamozási megoldás (keretrendszer) található manapság az interneten. Jövendőbeli könyvíróknak talán hasznos lehet, hogy hogyan sikerült megbírkózni a gyorsan megjelenő verziókkal, hiszen egy programozási könyvet azért (is) nehéz megírni, mert maga a rendszer (is) gyakran változhat és bizony vátozik is. (A Yii elég fiatalnak számít a "nagyágyúk" mellett).

Említésre kerül továbbá TrackStar, azaz alkamazás amit a könyv alapján készítünk, a Teszt Alapú Fejlesztés fontossága, és néhány szó a különböző forrás kezelő megoldásokról (SVN, GIT).

Meglepetés:

Jelenlegi szponzorunk (Packt Publishing) felhatalmazott bennünket, hogy elajándékozzunk 3 db elektromos Yii könyvet INGYÉ.

Ha még nincs meg (vagy jó lenne az eredeti ...) csak annyit kell megtennetek, hogy küldtök egy email-t a yiiradiio [kukac] mehesz.net -re, amiben néhány mondatban leírjátok, miért is lenne jó nektek ez a könyv. A jelentkezési határidő Október 31!

(Sajnos nem mi döntjük el, hogy kik lesznek a nyertesek, ezért fontos, hogy az emil tartalma angolul legyen!!!)

Köszi és sok sikert!

Twitter Madár

2010-10-13T11:15:00.000-07:00

!!! Kövessetek !!!

Elindítottuk a YiiHun Twitter madarát az alábbi címen:

http://twitter.com/yiihun

Ezen olyan, a Yii keretrendszerrel kapcsolatos, kisebb híreket fogunk közölni, amik nem érik el egy blog bejegyzés méretét.

Yii Radiio - 32. adás

2010-10-05T01:00:00.000-07:00

Hello,

Itt a Yii Radiio 32. adása ...

Új szponzorunk ebben a hónapban a Packt Publishing, akik rengeteg más programozói és designer könyv mellett a nemrég megjelent Yii könyv-et is publikálták.

A következő adásban egyébként egy új, eddig még ismeretlen területre merészkedünk, ugyanis interjú alanyunk lesz a Yii könyv írója (Jeffrey Winesett). Az adás végén pedig egy meglepetés vár a hallgatókra :)

Na nézzük, mizu ezen a héten:

- Bater Makhabel elkészítette a Yii UML leírását, biztos nagy segítséget fog nyújtani a programozóknak.
http://www.yiiframework.com/forum/index.php?/topic/11677-yii-architecture-with-uml-model-details/

- Willowdan meséli el nekünk, hogy miért választották a Yii-t más PHP-s keretrendszerek helyett.
http://putvaluefirst.info/tech-news/yii-my-chosen-php-framework/

- PRLog.org említi a Yii könyvet, és hogy hogyan lehet vele felgyorsítani a programozás.
http://www.prlog.org/10935481-accelerate-web-application-development-using-packts-new-yii-php-framework-book.html

- Hogyan készítsünk könnyedén Yii Form Varázslókat, ebbe tekint bele Nautilebleu írása.
http://nautilebleu.tumblr.com/post/1131788452/easy-form-wizards-with-yii

- Hogyan hajtsunk végre 180 fokos fordulást a Titanic-kal (még süllyedés előtt). Ez egy nagyon jó kis cikk sorozat arról, hogy egy cég hogyan próbál egy hatalmas online alkalmazást új alapokra helyezni, Yii-vel.
http://jacquesmattheij.com/Turning+around+the+Titanic,+part+1,+triple+the+signup+rate

- PostgreSQL-el ritkán foglalkoznak a blogok, pedig sokan azt rebesgetik, hogy mivel az Oracle tavaly(?) bekebelezte a MySQL-t, Postgres lesz az új nyílt forrású relációs adatbázisok királya. Addig is, itt egy jó kis leírás, hogyan is kell mindezt beállítani Yii-vel.
http://blog.93-interactive.com/wordpress/2010/09/using-the-yii-php-framework-with-postgresql/

- Egyre népszerűbb a NetBeans kód szerkesztő a PHP programozók körében. Marcov Twout bemutatja, hogyan lehet vele még elegénsabban dolgozni PHPUnit és Selenium RC-vel keverve.
http://www.yiiframework.com/doc/cookbook/83/

- A hét oldala: http://ikl.me, egy feltörekvő URL rövidítő és analizáló rendszer.

( még itt a magyaroknak annyit, hogy az adásban hallható intro és outro zenét a magyar Larry Hangman zenekartól kaptuk, akiknek nemrég jelent meg az első nagylemeze: http://www.myspace.com/larryhangman )

Könyvajánló: Agile Web Application Development with Yii 1.1 and PHP5

2010-09-28T10:37:00.000-07:00

A következő könyvajánló a Weblabor hasábjain jelent meg pár nappal ezelőtt, Orionstar klaviatúrájából:

A könyv azon haladó PHP fejlesztők számára készült, akik otthonosan mozognak az objektumorientált programozás világában, és felgyorsítanák munkájukat egy keretrendszer használatával. A könyv e fejlesztőket vezeti be a Yii keretrendszer alapszintű használatába pár egyszerű és egy komplex példán keresztül, agilis fejlesztési módszertant alkalmazva. Habár a tudásanyag nagy része könnyedén elérhető a keretrendszer weblapján illetve fórumában kutakodva, ezt a keresést helyettesíti részben a könyv kibővítve az agilis szempontból történő fejlesztéssel.
A könyv egy rövid összefoglalóval indít, hogy miért a Yii keretrendszert válasszuk. Röviden bemutatja a Yii által alkalmazott tervezési mintát, az MVC-t. Ez tényleg csak egy rövid összefoglaló, aki nincs tisztában ezzel, annak először ajánlott utána járni, majd ezt követően jönnek az egyszerű példák. A későbbi fejezetek során szoftverfejlesztési életciklus követésre képes alkalmazás lépésenkénti fejlesztését mutatja be a szerző a főbb funkciók megvalósításon keresztül, a témakezelésen át az RSS hírlevél és cachelésig. Maga a példa rendkívül hasonló a keretredszer oldalán megtalálható blog példához.
Miért érdemes hát elolvasni a könyvet, ha szinte minden elérhető az interneten is? Azért, mert a kezdéshez szükséges több helyen felhalmozott tudást a szerző összefoglalja, és mindezt olyan módszertan segítségével teszi, amiből az olvasók profitálhatnak. Engem személy szerint arra ösztökélt, hogy jobban utánajárjak az agilis módszertannak, amit noha korábban elvetettem a vízesés modellre esküdve. Továbbá nagy hangsúlyt fektet a(z) (egység)tesztelés részletes bemutatására is, amiről hajlamosak vagyunk olykor elfeledkezni.
Hogyan tovább, mi hiányzik? A könyv csak bevezető a Yii világába, ezért nem találhatók meg benne jQuery-vel, Ajaxszal, web service-okkal kapcsolatos példák, amik viszont a Yii igazi erejét adják, de az interneten sok példakód, tutorial elérhető melyek segítenek továbbfejleszteni tudásunk.

Az eredeti cikk itt található: http://weblabor.hu/konyvek/agile-yii-11-and-php5

Yii Radiio - 31. adás

2010-09-21T01:00:00.000-07:00

MZ/x MZ/x,

Itt a Yii Radiio 31. adása, nézzük mik a legújabb hírek a Yii háza táján:

- Hosszas fontolgatás után úgy döntöttünk, hogy a Facebook 'csoport' helyett egy 'oldal'-t készítünk amivel talán egyszerűbben tudunk kapcsolatot teremteni az érdeklődőkkel. Csupán LIKE-olni kell és kész is :) http://facebook.com/yiiradiio.

- Frank Kleine még 2008-ban írt egy cikket az 'annotations' és a PHP kapcsolatáról, és most újraelemzi a helyzetet, és egy megoldásra is rámutat a Yii segítségével.
http://www.stubbles.org/archives/79-State-of-annotations-in-the-PHP-world,-revisited.html

- A HAML and SASS kiterjesztésnek jelent meg egy újabb változata. Aki nem ismerné, a Ruby környezetben már régóta használt HTML és CSS "csonka kód" megoldásról van szó, aminek segítségével sokkal gyorsabban tudunk program kódot írni, hiszen nem kell annyit gépelnünk ...
http://www.yiiframework.com/extension/haml-and-sass/

- Végre a Yii-hez is elért a már rengeteg helyen használt OAuth. Köszönet CGeorge-nak.
http://www.yiiframework.com/extension/eoauth/

- Megjelent a Yii 1.1.4-es változata, közel 60 hibajavítással és újításokkal. A teljes listáért ide klikkoljatok:
http://www.yiiframework.com/files/CHANGELOG-1.1.4.txt

- Az MVC (Modell - Nézet - Vezérlő) elterjedésével egyre többen próbálják újraértelmezni a már jól bevált technológiát, de még mindig MVC-nek álcázva. A "Nézet az nem Template" -
http://r.je/views-are-not-templates.html

- Ha már nem lenne elég, itt egy újabb NoSQL szerű adatbázis motor, de azt mondják jobb minden eddiginél. Majd meglátjuk: Pomegranate.

- A hét oldala: PicLyf képmegosztó szolgáltatás és közösségi oldal a Twidl Inc.-től.

Temesvári Imre: Online informatikai tudásbázis Yii alapokon

2010-09-15T14:51:00.000-07:00

Az interneten böngészgetve akadtam erre a remek kis szakdolgozatra, amit Temesvári Imre publikált:

"Szakdolgozatom célja és témája egy olyan informatikai tudásbázis elkészítése, amely az informatika minden területéről összegyűjti a szakszavakat, fogalmakat, kifejezéseket – abból a célból, hogy az érdeklődőnek pontos információt adhasson. Jellege tudásbázis – ami annyival több, mint egy adatbázis vagy informatikai szótár, hogy nem egy valaki, vagy egy zárt csoport fejleszti - bővíti, hanem mindenki, aki az oldalt felkeresi, és érdemben tud rajta javítani, hozzá tenni. A cél egy minél bővebb tudásbázis létrehozása, ahol az érdeklődő gyorsan megtalálhatja a magyarázatot az általa nem ismert szóra, fogalomra.

A tudásbázis Yii alapokon fog működni, ami egy nem túl régi és még nem annyira elterjedt PHP keretrendszer. A keretrendszer jelentősen meggyorsíthatja a fejlesztés menetét, és az előre elkészített osztályok, kódok felhasználásával segíti a fejlesztő munkáját. Így a szakdolgozat másik célja a Yii bemutatása, megismertetése."

A szakdolgozat (PDF)

(az eredeti cikk itt található: http://nagygusztav.hu/temesvari-imre-online-informatikai-tudasbazis-yii-alapokon)

Környezetbarát Egységtesztelés Meztelencsigákkal

2010-09-11T20:49:00.000-07:00

avagy, hogyan gyártsunk Egységtesztelős programot a Yii-vel.

Mi ez?

Ha netán a címből nem lenne eléggé egyértelmű, a következőkben Egységteszetkről (Unit Test) lesz szó PHP-s környezetben. Ha a nyájas olvasó még nem olvasta a korábban megjelent Yiiki al'a Yii cikket, és semmilyen tapasztalata nincs a Yii keretrendszerrel, mindenképp érdemes rajta átfutni ugyanis itt nem fogunk belemenni az alapvető, -Na most akkor, hogy is kezdjem? kérdésekbe.

Mi lesz ez?

Egy nagyon egyszerű URL rövidítőt fogunk késziteni, mint pl a http://tinyurl.com vagy a http://vurl.me. Ha valaki nem ismerné, a lényeg az, hogy marha hosszú URL-eket lekicsinyítünk, és ha valahol egy felhasználó az általunk lekicsinyített linkre (slug) kattint, azt továbbítjuk a megfelelő oldalra.

Bevezetés

Környezet:

PHP 5.2.x
Apache (a PHP futtatásához)
SQLite (az egyszerűség kedvéért használjuk ezt, lehetne MySQL is)
Yii 1.1.3 (de elvileg működik az 1.1-es ág bármelyik csomagjával)
PHPUnit (tesztelést végrehajtó program: http://www.phpunit.de )

Fogalmak:

Test Driven Development (TDD) - Tesztelésen alapuló fejlesztés.

Ezt talán úgy lehetne a legegyszerűbben bemutatni, hogy képzeljünk el egy adott problémát és próbáljuk meg visszafelé megoldani. Oké, lehet, hogy ez így elsőre hülyén hangzik, de talán ez az ábra segíthet.

Írjunk tesztet
Ellenőrizzük, hogy a tesztünk hibázik (FAIL)
Írjuk meg (a legegyszerűbben!) a kívánt kódot úgy, hogy a tesztünk sikeres legyen.
Ellenőrizzük, hogy a tesztünk sikeres e (PASS)
Módosítsuk a kódunkat (úgy, hogy a teszt még mindig sikeres maradjon!)
Kezdjük előlről az egészet.

Unit Test - Egységteszt.

Az egységek, komponensek tesztelése, hogy megbizonyosodjunk a működésének helyességéről. Cél, hogy feltárja nincsenek-e tévműködések, feltáratlan hibák a belső algoritmusban, adatkezelésben. A komponensek más rendszer komponensektől függetlenül vannak tesztelve. (http://www.dcs.vein.hu/)

Ez így elsőre, másodikra de talán még harmadikra is érdekesen hangozhat, de reméljük a cikk végén minden világos lesz.

(ja, itt ajánlanám Erenon írását.)

Adatbázis

Mint korábban említettük, SQLite3-at fogunk használni, de gyakorlatilag bármilyen adatbázis motorral is műküdik a dolog.

Táblák

protected/data/rovidke.db

++++++++++++++++++++++++++
+ urls                   +
++++++++++++++++++++++++++
+ id INT (auto_increment)+
+ url TEXT               +
+ slug VARCHAR(50)       +
+ created INT            +
++++++++++++++++++++++++++

SQLite3

CREATE TABLE urls (created INTEGER, id INTEGER PRIMARY KEY AUTOINCREMENT, slug varchar(50), url TEXT);

Na, ennyi pepecselés után ugorjunk is bele a programozásba. Miután sikeresen létrehoztuk az alap alkalmazásunkat (pl: yiic webapp rovidke). Állítsuk is be egyből az adatbázis kapcsolatot.

protected/config/main.php

...
  'connectionString' => 'sqlite:'.dirname(__FILE__).'/../data/rovidke.db',
...

Itt szeretném megjegyezni, hogy többször is belefutottam a következő hibaüzenetbe (SQLite esetén, Linux-szal, lehet, hogy ez MS környezetben nem gond)

CDbCommand failed to execute the SQL statement: SQLSTATE[HY000]: General error: 8 attempt to write a readonly database

Ez annyit jelent, hogy az adatbázis file-t a program nem tudta írásra megnyitni, tehát át kell állítanunk a jogokat (ha csak a saját gépemen programozok, és nem foglalkozok a biztonsággal, egyszerűen 777-et adok neki :) )

Itt a MVC

Modell

Első lépésként hozzuk is létre a Url modellünket. Ha valaki nagyon bátor, az használhatja az új csodafegyvert: Gii, amit a yiic utódjának szán a Yii fejlsztői csapat. Tulajdonképpen egy grafikus, bongészőbarát kódgeneráló eszköz. (a cikkben a yiic-et fogjuk használni)

./protected/yiic shellYii Interactive Tool v1.1 (based on Yii v1.1.3)
Please type 'help' for help. Type 'exit' to quit.
>> _

>> model Url urls
   generate models/Url.php
   generate fixtures/urls.php
   generate unit/UrlTest.php
The following model classes are successfully generated:
    Url
If you have a 'db' database connection, you can test these models now with:
    $model=Url::model()->find();
    print_r($model);
>>

Akiknek jobb a szeme, azok nyilván észrevették a teszt csomagot, amit a Yii alapból elkészít minden modellhez a protected/tests/unit mappa alatt. Gyakorlás képpen Futtassuk is le "tesztjeinket" (protected/tests/) ...

$phpunit unit...
There was 1 error:
1) testCreate(UrlTest)
CDbException: The table "urls" for active record class "Url" cannot be found in the database.
...

Hoppá, hát az meg mi? Mi az, hogy nincs ilyen tábla az adatbázisban?

Azt fontos megjegyezni, hogy tesztelés közben nem egy, csak és kizárólag, a teszthez írt funkciót futtatunk, hanem az éles alkalmazás kódját. Ami azt jelenti, hogy a funkció az mindig ugyanaz marad és mindig ugyanúgy fut le. Hova is akarok ezzel kilyukadni? A lényeg, hogy amikor a teszteket futtatjuk, a program egy előre legyártott adat-tömbből (fixtures) veszi az adatokat, ezeket egy adatbázisba teszi, lefutattja a tesztet, és törli a DB táblákban tárolt bejegyzéseket. Tehát fontos, hogy az éles adatbázis és a teszt adatbázis különböző legyen!

Innen jött a hibaüzenet, ugyanis a teszt adatbázisunk még nem létezik. Csináljunk is egyet ...

protected/data/rovidke_test.db

++++++++++++++++++++++++++
+ urls                   +
++++++++++++++++++++++++++
+ id INT (auto_increment)+
+ url TEXT               +
+ slug VARCHAR(50)       +
+ created INT            +
++++++++++++++++++++++++++

SQLite3

CREATE TABLE urls (created INTEGER, id INTEGER PRIMARY KEY AUTOINCREMENT, slug varchar(50), url TEXT);

... és módosítsuk a teszt(!) konfigurációs file-t az alábbiak szerint

protected/config/test.php

...
 'connectionString'=>'sqlite:' . dirname(__FILE__).'/../rovidke_test.db',
...

ha, most lefuttatjuk a tesztünket ... protected/tests/

$phpunit unitPHPUnit 3.3.16 by Sebastian Bergmann.
.
Time: 0 seconds

OK (1 test, 0 assertions)

minden OK! Birkabőr (Juhéjj)!

Kedvenc szövegszerkesztőnkkel nyissuk meg a UrlTest? a protected/tests/unit/ könyvtárból (aki VIM-et hasznal +1 piros pontot kap). Ez elvileg üres, illetve, az osztályt a Yii már létrehozta, és talán akad is egy példa teszt. Ha van, ha nincs, a lényeg, hogy minden teszt funkciónak a testcimkével kell kezdődnie. Nem történik semmi baj, ha nem kezdjük ezzel a tesztünket, de nem fog lefutni. A gyakorlás kedvéért csináljunk is két tesztet ...

protected/tests/unit/UrlTest?.php

...
    public function testTrue()
    {
        $this->assertTrue( false );
    }

    public function testTrue2()
    {
        $this->assertTrue( true );
    }
...

Ez talán elég világos, de ha nem, akkor röviden annyi történik, hogy elsőben megvizsgáljuk, hogy az IGAZ az HAMIS e, a másodikban pedig, hogy az IGAZ az IGAZ e. Futtasuk is le ...

protected/tests/

$phpunit unit
PHPUnit 3.3.16 by Sebastian Bergmann.

F.
Time: 0 seconds
There was 1 failure:
1) testTrue(UrlTest)
Failed asserting that <boolean:false> is true.
/var/www/rovidke/protected/tests/unit/UrlTest.php:18

FAILURES!
Tests: 2, Assertions: 2, Failures: 1.

Jajj de remek, láthatjuk is, hogy egy darab (F) betűt kaptunk, ami a tévhitekkel ellentétben, az jelenti, hogy FAIL (ja, a pont . meg azt, hogy a teszt PASS(ED), azaz sikeresen lefutott.) Ha jobban megvizsgáljuk az üzenetet, akkor még az is kiderül, hogy Failed asserting that <boolean:false> is true, ami a Google fordító szerint annyit jelent, hogy Elmulasztotta azt állítja, hogy hamis igaz. Remélem lejön a lényeg :)

Rengeteg ilyen "a teszt azt állítja, hogy" funkció létezik, ebben a példában mi csak néhányat fogunk bemutatni/használni. A teljes listáért ide klikkoljatok.

Fixtures - Minta Adat

Mint már korábban említettem, a "teszt csomag" egy úgynevezett adat-tömbből veszi a teszthez szükséges adatokat, most itt erről lesz szó (egy kicsit). Szerencsénkre Yii már létrehozta az alap könyvtárrendszert és a file-okat, sőt még néhány példa tömbböt is készített aprotected/tests/fixtures/urls.php file-ban. Pompás.

Módosítsuk is az értékeket, valahogy így:

return array(
        'sample1'=>array(
                'created' => '1234567890',
                'slug' => 'AA',
                'url' => 'http://weblabor.hu',
        ),
        'sample2'=>array(
                'created' => '1234567890',
                'slug' => 'AB',
                'url' => 'http://google.com',
        ),
);

Ugyan ezek az adat-tömbök elhanyagolhatóak, a gyakorlatban szinte mindig hasznaljuk őket.

Megint Tesztelünk

Nyissuk meg a URL teszt file-unkat és írjunk gyorsan egy számláló tesztet, ami megszámolja az összes linket a táblában:

protected/tests/unit/UrlTest?.php

...
    public function testCountAll()
    {
        $urls_count = sizeof(Url::model()->findAll());
        $this->assertEquals( 2, $urls_count );
    }
...

A példa kedvéért itt az assertEquals()-t mutatom be, ami azt "Feltételezi", hogy a két megadott érték megegyezik. Ezzel lehet játszadozni, ha valami nem stimmel a tesztünk úgyis elbukik. PL:

protected/tests

$phpunit unit/
...
  Failed asserting that <integer:2> matches expected value <integer:1>.
...

Ugye milyen egyszerű? Az assertEquals()-ba nem csak szám értéket passzolhatunk ám, hanem akár szöveges változót is:

protected/tests/unit/UrlTest?.php

...
    public function testActionView()
    {
        $url = Url::model()->findByAttributes( array( 'id' => 1 ) );

        $this->assertTrue( $url instanceof Url );
        $this->assertEquals( $url->url, 'http://altavizsla.hu' );
    }
...

ez nyilván elbubik, de ...:

protected/tests/

$phpunit unit...
There was 1 failure:

expected string <http://weblabor.hu>
difference      <       xxxxxxxxxxx??>
got string      <http://altavizsla.hu>
...

Itt a PHPUnit ügyesen megmutatja nekünk, hogy pontosan hol is tértek el a szöveges változók. jajj, de jó :)

Na most nézzünk egy kicsit komolyabb tesztet. A urls táblába csak olyan rekordot szertnénk elmenteni, aminek mind a url, mind a slug értéke be van állítva, tehát nem lehet üres. Írjuk meg a tesztet:

protected/tests/unit/UrlTest?.php

...
    public function testUrlRequired()
    {
        $this->assertTrue( Url::model()->isAttributeRequired( 'url' ) );
    }
...

Ha most lefuttatnánk a tesztünket, akkor nyilvánvalóan elbukna. Szerencsénkre a Yii modell osztálynak van egy ún. rules() (szabályok) funkciója, amivel többek között azt is beállíthatjuk, hogy mely értékek nem lehetnek üresek. Ezt a required-del határozhatjuk meg.

protected/models/Url.php

...
  public function rules()
  {
    return array(
       ...
       array( 'url', 'required' ),
       ...
    );
  }
...

A tesztünk már majdnem sikeres ;) Hasonlóan az előző példához, most állítsuk be a slug-ot is ...

protected/tests/unit/UrlTest?.php

...
    public function testSlugRequired()
    {
        $this->assertTrue( Url::model()->isAttributeRequired( 'slug' ) );
    }
...

TESZT: FAIL!

protected/models/Url.php

...
    return array(
       ...
       array( 'url,slug', 'required' ),
       ...
    );
...

Itt még azt is észrevehetjük, hogy milyen szépen lehet több értéket is megadni a Yii rules()-ban.

TESZT: PASS!

Most nézzünk egy olyan példát, ahol a tesztelésre szánt funkció még nem létezik. Például mi történik akkor, ha egy új URL-t (inkább slug-ot) szeretnénk készíteni. Ha most próbálnánk ki a programot, akkor kézzel kéne beállítanunk a lerövidített URL-t. Na ne má ... Tehát ha az adatbázisunk üres (nincs 1 darab URL sem) akkor az első slug legyen: AA. Na hogy is néz ez ki pontosan?

protected/tests/unit/UrlTest?.php

...
    public function testCreateUrl()
    {
        $url = new Url();
        $url->setAttribute( 'url', 'http://altavizsla.hu' );
        $this->assertTrue( $url->save(), 'URL tarolas tesztelese' );
        $this->assertEquals( $url->slug, 'AA' );
    }
...

A tesztünk az feltételezi, hogy egy új URL esetén az új URL slug-ja az AA értékkel fog visszatérni. A teszt itt nyilván elbukik. (azt érdemes megjegyezni, hogy több feltételezést is meg lehet adni 1 teszten belül).

Itt jön segítségünkre, a beforeValidate() beépített függvény, ami arra szolgál, hogy még a mezők ellenőrzése előtt(!) futtassunk le valamit ...

protected/models/Url.php

    public function beforeValidate()
    {
        $this->slug = $this->createSlug();
        return parent::beforeValidate();
    }

    public function createSlug()
    {
       return 'AA'; 
    }

Azért nem tudtuk itt a beforeSave()-et használni, mert az ellenőrző szabályunk (rule) elbukna, ugyanis a slug nem lehet üres. Most csak azt akarjuk elérni, hogy a tesztünk sikeresen lefusson, ugyanis a createSlug() nem adhat mindig AA értéket, pl. ha több URL-t is szeretnénk tárolni az adatbázisunkban ;). Ha most lefuttatjuk a tesztünket akkor sikeresen lefut. Jajj, de jó. Na most módosítsuk a kódunkat úgy, hogy az tényleg azt csinálja amit akarunk ...

    public function createSlug()
    {
        $slug = Url::model()->find( array( 'order' => 'slug DESC' ) )->slug;

        if( ! $slug )
        {
            $slug = 'AA';
        }
        else
        {
            ++$slug;
        }

        return $slug; 
    }

Futtassuk a tesztet ...

protected/tests/

$phpunit unit/
...
Failed asserting that two strings are equal.
expected string <AC>
difference      < x>
got string      <AA>
...

Ez meg hogy lehet, az előbb még minden jó volt ;) Persze a fentiekből egyből kiderül, hogy a teszt az AA értéket várta és AC-t kapott. Tehát módosítanunk kell a tesztünket. Itt jogosan merülhet fel a kérdés, hogy mi a ráknak ez a kerülőút? De ne feletjtsük el, tesztelünk.

protected/tests/unit/UrlTest?.php

...
    public function testCreateUrl()
    {
        $url = new Url();
        $url->setAttribute( 'url', 'http://altavizsla.hu' );
        $this->assertTrue( $url->save(), 'URL tarolas tesztelese' );
        $this->assertEquals( $url->slug, 'AC' );
    }
...

Még itt gyorsan, mielőtt elfelejtem, a createSlug()-ot rövidíthetjük így is.

protected/models/Url.php

...
    public function createSlug()
    {
        $slug = Url::model()->find( array( 'order' => 'slug DESC' ) )->slug;
        return $slug ? ++$slug : 'AA';
    }
...

Vezérlő és Nézet Cucc - CRUD - Létrehoz, Megjelenít, Frissít, Töröl

Az azért remélem feltűnt, hogy még egyszer sem ellenőriztük a programot a böngészőben. Mert nincs is rá szükség. Abban azonban biztosak lehetünk, hogy a URL modellre vonatkozó funkcióink majdnem 100%-osak. Azért nem mondom, hogy majdnem, mert több mindent lehetne, sőt, kellene(!) még tesztelnünk. Pl. mi van akkor, ha frissítünk, vagy törlünk egy linket az adatbázisból stb. Ezeket a fentiek alapján, remélem, kis gondolkodás után meg lehet csinálni. De még van néhány egyéb teendőnk is mielőtt a programunkat a felhasználók karmai közé eresztenénk.

Készítsük el az alap felhasználói interfészt (formok, nézetek és egyebek) a yiic segítségével.

protected/yiic shell

>> crud Url
   generate UrlController.php
   generate UrlTest.php
      mkdir /var/www/rovidke/protected/views/url
   generate create.php
   generate update.php
   generate index.php
   generate view.php
   generate admin.php
   generate _form.php
   generate _view.php
   generate _search.php

Ha egy új felhasználó érkezik az oldalra, azt szeretnénk, hogy minden klikkolgatás nélkül készíthessen egy rövidített linket (monnyuk ez nem csakúj felhasználókra vonatkozik). Módosítsuk az alap kontrollerünket:

protected/config/main.php

...
    'defaultController'    => 'url/create',
...

Amikor a Yii a hozzáférési szabályokat készíti, alapból a létrehozás funkció (create) csak belépés után lehetséges. Ami jelen esetben nem elfogadható, hiszen mi azt szeretnénk, hogy a felhasználóink a lehető leggyorsabban létrehozhassanak rövidített linkeket. Módosítsuk tehát a

protected/controllers/UrlController?.php

...
   public function accessRules()
... 
   array('allow',  // allow all users to perform 'index' and 'view' actions
        'actions'=>array('index','view', 'create'),
        'users'=>array('*'),
   ),
   array('allow', // allow authenticated user to perform 'create' and 'update' actions
        'actions'=>array('update'),
        'users'=>array('@'),
   ),
...

Ha most megnéznénk a kis programunkat, akkor mindenféle egyéb form mezőket látnánk, amit az okos (már tesztelt) Modell funkcióink szépen kitöltenek a URL mentése előtt. (pl. dátum mező, a rövidített URL azaz slug mező). Tulajdonképpen csak egyetlen mezőre van szükségünk, a URL-re:

protected/views/url/form.php

...
    <?php /*
        <div class="row">
                <?php echo $form->labelEx($model,'created'); ?>
                <?php echo $form->textField($model,'created'); ?>
                <?php echo $form->error($model,'created'); ?>
        </div>

        <div class="row">
                <?php echo $form->labelEx($model,'slug'); ?>
                <?php echo $form->textField($model,'slug',array('size'=>50,'maxlength'=>50)); ?>
                <?php echo $form->error($model,'slug'); ?>
        </div>
    */ 
    ?>

        <div class="row">
                <?php echo $form->labelEx($model,'url'); ?>
                <?php echo $form->textField($model,'url', array( 'size' => 50 )); ?>
                <?php echo $form->error($model,'url'); ?>
        </div>
...

Miután programunk elmenti az új Url-t, Yii automatikusan betölti a megjelenítő kódot (viewAction()). Mi azt szeretnénk, ha a felhasználónk valami ilyesmit látnának: http://rovidke.hu/QWD, és erre klikkelve (vagy a böngészőbe másolva) jutnának el az igazi URL-hez.

Először módosítsuk a megjenítő nézetet:

protected/views/url/view.php

...
<?php 
    echo 
        CHtml::link( 
            $_SERVER['SERVER_NAME'] . '/' . $model->slug, 
            $this->createUrl( '/' . $model->slug ) 
        );
?>
...
<?php /*
$this->widget('zii.widgets.CDetailView', array(
        'data'=>$model,
        'attributes'=>array(
                'created',
                'id',
                'slug',
                'updated',
                'url',
        ),
)); 
*/
?>

No, és itt jön az alkalmazás egy másik érdekessége, az átirányítás vagy redirect. Alapértelmezésben a rendszer a kapott URL alapján megpróbál egy Vezérlőt (Controller) keresni és átpasszolni neki a kapott változókat. Nekünk viszont az kéne, hogy ha valami ilyesmit kapunk (/QWD) akkor a program ne keresse a QWD-t (nem találna!) hanem hívja meg a Url vezérlőt és adja át QWD-t mint egy változó értéket. (ugyebár a slugazonosítója.) Ezt az alap konfigurációs file-ban tehetjük meg, a következő képpen (a szabályok sorrendje fontos):

protected/config/main.php

...
        'urlManager'=>array(
             'urlFormat'=>'path',
             'showScriptName' => false,
             'rules'=>array(
                 '/<slug:[A-Z]+>' => 'url/redirect',
                 '<controller:\w+>/<id:\d+>'=>'<controller>/view',
                 '<controller:\w+>/<action:\w+>/<id:\d+>'=>'<controller>/<action>',
                 '<controller:\w+>/<action:\w+>'=>'<controller>/<action>',
             ),
         ),
...

Persze mindez nem jöhetne létre ha nics apache (.htaccess). Ha az alkalmazás ROOT könyvtárában valami oknál fogva nem lenne meg ez a file, akkor az alábbiak alapján kíszítsünk egyet.

.htaccess

Options +FollowSymLinks
IndexIgnore */*
RewriteEngine on

#Uncomment "RewriteBase /" when you upload this .htaccess to your web server, and comment it when on local web server

#NOTE: 

#If your application is in a folder, for example "application". Then, changing the "application" folder name, will require you to reset the RewriteBase /[your app folder]

#RewriteBase /[your app folder - optional]

# if a directory or a file exists, use it directly
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d

# otherwise forward it to index.php 
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Na, most már tényleg csak egy dolog van hátra, megírni magát az átirányító funkciót actionRedirect()

protected/controllers/UrlController?.php

...
    public function accessRules()
    {
       ...
          array('allow',  // allow all users to perform 'index' and 'view' actions
                  'actions'=>array('index','view','create','redirect'),
                  'users'=>array('*'),
                ),    
       ...
    }
...
    public function actionRedirect()
    {
        $slug = Yii::app()->request->getParam( 'slug', null );
        if( $slug )
        {
            $url = Url::model()->findByAttributes( array( 'slug' => $slug ) );
            if( $url )
            {
                $this->redirect( Url::model()->findByAttributes( array( 'slug' => $slug ) )->url );
            }
        }

        throw new CHttpException( '404', 'hmmm ... slug not found!' );
    }
...

Még nagyon sok mindent lehetne finomítani a programunkon, de szerintem kezdetnek ez is elég. Azt pedig nagyon remélem, hogy a PHP közösség (végre) felébred és használni fogja a Teszt Alapú (TDD) programozást.

A Yii legyen veletek.

"Ismeret az nem cselekedet, csakis cselekedet a cselekedet" - tdc10