Citat:
Ovako laicki, preInsert() ti dodje @prePersist ili @preUpdate LifecycleCallbacks, i koliko kontam ovako, isto ili manje koda ti je potrebno jer ako metodi stavis da je @prePersist, ona se poziva automatski bez da ti moras da pozivas bilo kako. Znaci kad uradis ->flush(), adekvatna metoda se poziva (prePersist je samo pred dodavanje novog objekta u bazu, preUpdate je logicno samo pred update)
http://www.doctrine-project.or...m/2.0/en/reference/events.html
a ako pitas za cisto relacije, deluje mi kod prilicno identican, postuj dokle si stigao i gde si zapeo sa v2 kodom pa da vidimo mozda skontamo nesto. Inace bi isto bilo mislim, ako ne identicno, samo izvrtis vezane objekte (kako se vec strucno kaze) i spicis akciju. Al opet, daj malo koda dokle si stigao, nije mi bas najjasniji ovako sta gde koci konkretno.
Jasno mi to za prePersist i preUpdate, pogledao sam dokumentaciju za evente i to je skoro isto kao u V1.2. Mene muci ovaj deo:
Citat:
foreach ($this->Creator->MyFans as $user)
$activity->NotifiedUsers[] = $user ;
$this->Activities[] = $activity ;
U prevodu: od kreatora $this Album-a, izvuci listu fanova i za svakog kreiraj novi Activity (obavestenje o aktivnosti kreatora). Zadnja linija ce taj novo-kreirani Activity da 'prikaci' albumu i snimice se zajedno.
Koliko sam razumeo, u D2.0 bih morao da 'rucno' snimim ta obavestenja. Probaj da napises kod, cini mi se da je daaaaleko komplikovanije.
btw; nisam napisao jos nikakav kod, jer nemam vremena za to ali detaljno citam dokumentaciju. Krenuo sam u tu pricu isto kao i za D1.2; dokumentacija prvo, hvatanje logike rada... i za 3-4 dana naucis.
Nazalost, nije. U real-life situaciji uvek ima MNOGO join-ova, zavisno od stranice do stranice. Evo primer:
Code (php):
/**
* For listen->song() page
*
* @param mixed $id
* @return Song
*/
public function findForListenSong($id)
{
$query = $this->createQuery('o')->select('o.*') ;
$this->addAlbum($query) ;
$this->addLanguage($query) ;
$this->addCreator($query) ;
$this->addStatistics($query) ;
$this->addCategory($query) ;
$this->addCountry($query) ;
$this->addActiveContest($query) ;
......
return $query->addWhere('o.id=?', $id)->fetchOne() ;
}
/**
* Add country as property:
*
* country_name
*
* @param Doctrine_Query $query
*/
protected function addCountry(Doctrine_Query $query)
{
$query->addSelect('e.name as country_name')
->leftJoin('o.Country y')
->leftJoin('y.CountryTranslation e WITH e.translation_id=?', Translation::getForVisitor()->id) ;
}
Znaci za stranicu koja pusta pesmu, treba mi najvise informacija: jezik, zemlja (multijezicka podrska), statistika, da li je pesma u nekom takmicenje (Contest)... itd. Bitno u ovoj prici je metoda addCounty(). Tu na postojeci query samo uradim join potrebnih stvari, dodam addSelect() za ime zemlje i sve lepo radi. Kod QueryBuilder-a, ja ne mogu ovo da uradim vec bih iznova kopirao isti kod. Ili mi nesto promaklo a ne mogu da nadjem. Na primer; ako mi za ListenSong vise ne treba ime zemlje, ja iz metode samo izbacim liniji $this->addCountry($query). U 2.0 to ne mogu da uradim; query builder UVEK zahteva sve parametre, ne moze se tek tako dodati. Nadam se da me razumes...
Citat:
Validacija, e to je malo zez, ja jos uvek radim na tome da provalim najlaksi nacin, ali definitivno preporucuju @prePersist i @preUpdate i to radi sasvim ok sa exceptionima.
Za sada objektu setujem niz sa pravilima za svaki property koji je persistent u bazi, svaki sa svojim pravilima i onda custom proveru validnosti. To sam kontao da bude u serviceLayeru, mada to meni drugacije malo izgleda nego "uobicajeno", lakse mi je da model nasledi serviceModel pa da sam bude sposoban da radi kao serviceLayer (ali mozda i promenim nacin razmisljanja u nekom trenutku).
Aj postuj nesto koda da vidim na sta mislis. Nesto sam razmisljao da mi sve klase nasledjuju neku moju tipa 'BaseEntity', u nju da stavim isValid() a da ona posle iz child elemenata izvlaci pravila za osnovnu validaciju kao ovo gore: regexp, minlength itd. Tj. ono sto mi D1.2 pruza u Base klasama. Medjutim, ta ideja mi vec sad mirise na budzanje koja ce neka buduca verzija imati interno.
Nisi me razumeo dobro; ovo sto ja koristim NIJE translation behaviour koji D1.2 pruza vec sam to ja napravio. Moja verzija je mnogo bolja i fleksibilnija nego originalna. Problem u tom primeru je sto ja imam formu gde se ne edituje samo jedan objekat, vec i mnogo child elemenata.
Ajde ovako; zamisli da imas Album kome je uradjen leftJoin svih Song-ova. Ti imas formu gde mozes da izmenis ime albuma, ali ujedno i imena svih pesama. $album->isValid() treba da vrati false ako i samo jedna od pesama nema ispravno ime, recimo krace je od 3 karaktera i slicno.
Citat:
Sto meni koji godinama radim sa activeREcord nije bas najlakse za svariti iskreno. Ponekad mi deluje da bi mi bilo lakse da sam zavrsio fakultelt i naucio tamo sve fancy pojmove i ideje koje se koriste u "advanced OOP"

Veruj, bolje sto nisi. Tamo bi ucio 300 programskih jezika, a nijedan ne bi znao kako treba. Tvrdio bi da je moj kod 'glupost' kao i koriscenje 'ORM-a i Framework-a'. Znas li da ja sam 4-5 puta padao Racunare? Moj algoritam je radio tacno i bio kraci od profinog, ali svaki put sam dobio isti odgovor: NISAM TAKO PREDAVAO! Na kraju sam morao da kupim knjigu i uradim po njegovoj ideji. Mikroprocesore nikad nisam ni polozio, napustio sam visu kad sam ukapirao da profesori znaju manje od mene.
Programiranje nije egzaktna nauka; to se uci SAMO kroz rad i vezbanje. Ja sam uveliko koristio Doctrine i tek na ovom forumu sam saznao da se to zove Active Record pattern. Do singleton-a sam sam dosao, ne secam se kako ali verovatno analizirajuci Doctrine kod; i tek posle par meseci saznao i 'zvanicno' ime
Citat:
Ako si me nesto i razumeo, super
Zapravo jesam, vidim da nisam jedini koji muci muku oko nekih osnovnih stvari na koje smo izgleda obojica navikli. I za mene je AR prirodan nacin rada, kod je uvej jako kratak, brz, lako citljiv... Znam da gresim, to je sigurno, ali nikako da uklavirim kako mi DataMapper olaksava stvar. Ili da bar bude isto, nema problema, ne bih kukao.
Posto D2 nema validaciju kao D1, kako ti zvuci ideja o BaseXXX klasama koje nasledjuju neku zajednicku npr. BaseEntity gde bi se postavilo isValid() i getErrorStack() kao u D1? getErrorStack() mi treba da izvucem gde je tacno pala validacija.
Ovo nije tesko napraviti, pogledaj
ovu sliku. To je moja Settings klasa, ima identican API kao Doctrine, ali nema nikakve veze sa njim. Ona koristi .ini fajl za sebe, ne bazu.
Posto vec radis sa D2, da li ti se takva ideja cini kao budzanje? Meni su validacija i sigurnost podataka vazniji od bilo cega drugog.