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

Az Art-Work (http://art-work.hu) története 2007-ben kezdődött el, amikor egy szakdolgozat témájaként jött létre. Mivel én magam is szeretek fotózni, így nem csak a szakdolgozat viszonylag hamar kikerült a netre (deviantart, stockexpert ihletésére). Reklámozni akkoriban csak iwiw-en reklámoztam, illetve készült pár száz szórólap, amit pár városban művészeti iskolákban szórtunk ki.

2007-2009 -ig három verziót élt meg az oldal. A verzió váltás okai a szakmai fejlődésem volt elsősorban.
Az első nagyobb lépés a 2009-ben PRADO-ra váltás volt, amikor már némi web2 is bekerült az oldalba, és mégis csak egy összeszedettebb rendszer volt, mint az addigiak. A PRADO-t nagyon szerettem, mert jó volt használni, megvoltak a megfelelő dolgok, nem kellett semmiben feltalálni a spanyol viaszt. 

2009-2011-ig sajnos nem nagyon volt foglalkozva az oldallal az akkori munkahelyem miatt, ezért a felhasználói bázis szép lassan el is felejtette az oldalt. Így az addig összegyűlt 1000 felhasználó és 8000 kép ott maradt.
2011 végén, munkahely váltás után lett szabadidőm ismét, és az akkor már általam használt Yii-ben gondoltam, hogy újra írom az oldalt.

Így az már működik és ismét zajlik az élet :)

A Yii-re azért váltottam PRADO-ról, mert ugyan az MVC nagyon új volt a PRADO felfogásával szemben, ám sebességben olyan szakadék tátongott a kettő között, hogy egyértelmű volt a váltás. Megnyugtató volt számomra, hogy a Yii egyik fejlesztője a PRADO volt alapítója, így egyértelmű volt, hogy minőségi keretrendszer ez is.

Yii-ben kihasználok mindent, amit lehet, de azért pár dolog, aminek nem tetszik a működése, azt inkább magam készítem. Ilyen például az assetek kezelése. Nem szimpatikus, hogy egy mappában random dir-be kerülnek az assetek, és ha kiviszem production-be az alkalmazást, akkor új dir-ek generálódnak. Inkább én belinkelem magamnak, ami éppen kell. Remélem ezt valamikor átalakítják.

Nem szoktam használni a grid-et például, inkább saját foreach ciklust használok, mert felesleges extra lépcsőként tekintek erre a lehetőségre.

Kiegészítettem a rendszert egy saját DataType osztállyal és annak leszármazottjaival, mellyel igyekszem a PHP laza típus kezelését kivédeni. AJAX kommunikációnál és minden klienstől REQUEST-ben érkező adatnál kialakítottam egy DTO (Data Transfer Object) rendszert, ahol előre definiált adatok közlekednek az objektumok között, nem csak feltöltöm a model attributes property-jét a POST-ból érkező adattal. Így pl, mivel külön class-ban van mondjuk egy form-tól várt mezők, jól látható, hogy mi az, és csak az, amit a klienstől várunk. Nagyjából a CFormModel is ezt oldja meg (ha jól tudom), próbáltam is használatát, de kevésbé volt szimpatikus, mint a saját megoldásom.

Ha elakadok, sokszor segít a Yii fórumban keresgélés, de a stackoverflow-n is nagyon sok Yii-s problémára találok megoldást.

Amit viszont örömmel használok a Yii alap lehetőségeiből és letölthető extension-jaiból: EAjaxUpload, urlManager, YiiMail, I18N

Amit még fontosnak tartok megemlíteni, mert sokat könnyít a fejlesztésen, az az, hogy az I18N modult kiegészítettem egy wrapper osztállyal, amit ugyanúgy kell használni, mint a Yii által adott default tool-t, annyi különbséggel, hogy nem kell magunknak belerakni az új fordítandó szavakat az adott dictionary php-ba, hanem magától belerakja, ha még nincs benne, illetve a file-t is létrehozza, ha még nincs. Ez a felfogás a PRADO-ból jött, mert ott is nagyon tetszett, hogy ezt megcsinálja helyettem. Ezt a Yii fórumon meg is osztottam természetesen.

Jelenleg a UNIT tesztek írását készítem, ahol azért néha rájövök, hogy nem teljesen sikerült minden részt tesztelhetőre készíteni. Ezért is alakítottam ki a DTO környzetet például.

-- írta  Murányi Sándor