CakePHP: tvoríme CMS - 3 (Active Record)

24. 4. 2008 | Tibor Piňo | Programování | 7919×

Táto časť patrí k najdôležitejším, pretože si v nej budeme podrobne vysvetľovať srdce celého frameworku, a to je Active Record.

V minulej časti sme si povedali o základnej inštalácii celého frameworku a pre začiatok sme si vysvetlili, ako funguje základné rozloženie stránky. V dnešnej časti si predstavíme srdce celého CakePHP a ukážeme si, ako správne dodržiavať konvencie Cake v súvislosti s návrhom databáze. Samotný návrh databázy príde na radu v nasledujúcej časti.

Active Record

Active Record je srdce CakePHP a dokonale demonštruje princípy, na akých je Cake postavený.

Active Record je návrhový vzor, ktorý mapuje databázové tabuľky na triedy, riadky na objekty a stĺpce na ich atribúty (toto však v Cake nie je úplne tak - rozdiel je v tom, že aktuálne sa riadky a stĺpce mapujú na dvojrozmerné polia; mapovanie na objekty je naplánované na verziu 2.0). Z názvu triedy modelu teda jednoducho odvodíme názov tabuľky. Napr. máme model Article a k nemu patrí tabuľka articles (vždy množné číslo od názvu modelu). Zároveň Active Record umožňuje definovať vzťahy medzi tabuľkami (hasMany, belongsTo, hasManyAndBelongsTo, …) a okrem toho obsahuje výkonné nástroje pre prácu s dátami, ako je zápis, čítanie, validácia.

Čo teda Active Record prináša do našej práce? Najdôležitejšia a podstatná vec je, že nám značne uľahčuje prácu s databázou, kde v konečnom dôsledku nemusíme písať SQL. Koľko práce trávime písaním, ladením SQL dotazov a následným mapovanim výsledkov atď. Active Record nám umožňuje pracovať na oveľa vyššej úrovni. Poďme sa pozrieť na nasledujúci príklad:

Máme tabuľku Articles, v ktorej máme uložené jednotlivé články. Bežným spôsobom chceme vybrať konkrétny článok SELECT * FROM articles WHERE id = 1.

+----+-------------+-------+--------+---------------------+
| id | title       | text  | author | created             |
+----+-------------+-------+--------+---------------------+
|  1 | Titulok     | Text  | Linus  | 0000-00-00 00:00:00 |
+----+-------------+-------+--------+---------------------+

V Cake si vytvoríme triedu Article (uložíme ju do súboru /app/models/ar­ticle.php), ktorá nám bude reprezentovať tabuľku articles (názov tabuľky je množné číslo názvu modelu):

class Article extends AppModel{
  var $name = 'Article';
}

A pomocou príkazu $this->Article->find(1); dostaneme požadovaný výsledok:

Article =>
id: 1
title: Titulok
text: Text
author: Linus
created: 0000-00-00 00:00:00

Pôsobivé však? Ako sme si uviedli v prvej časti, konvencia má prednosť pred konfiguráciou, preto Cake automaticky predpokladá, že keď máme model nazvaný Article, v našej databáze existuje tabuľka nazvaná articles. Ak by sme však chceli zmeniť názov tabuľky a nepoužívať tak automatické konvencie, môžeme tak urobiť následovne

class Article extends AppModel{
  var $name = 'Article';
  var $useTable = 'clanky';
}

Vyššie sme si povedali, že Active Record obsahuje efektívne metódy nielen pre čítanie dát, ale aj pre ich manipuláciu. Poďme teda zmeniť titulok nášho článku:

$article = $this->Article->find(1);
$article['Article']['title'] = 'nový titulok';
$this->Article->save($article);

po uložení môžeme vidieť obsah tabuľky:

+----+-------------+-------+--------+---------------------+
| id | title       | text  | author | created             |
+----+-------------+-------+--------+---------------------+
|  1 | nový titulok| Text  | Linus  | 0000-00-00 00:00:00 |
+----+-------------+-------+--------+---------------------+

A máme hotovo. Jednoduchšie to už ani nemôže byť. Absolútny rozdiel od spôsobu, kde by sme museli písať SQL ako select… a potom update…, je značný. Možností využitia Active Record je mnoho:

• $this->Article->findById(1) - vráti článok s id 1
• $this->Article->findAll(null,a­rray(‚title,‘tex­t'),‚Article.created desc‘) - vráti články zotriedené podľa dátumu vytvorenia, a vyberú sa len stĺpce title a text
• $this->Author->findByName(‚Li­nus‘) - vráti autora s menom Linus

Bolo by asi zbytočné vypisovať tu ďalšie ukážky a demonštrovať tak silu Active Record. Pre jednotlivé metódy a ich parametre odporúčam pozrieť oficiálnu dokumentáciu. Okrem iného sme si povedali, že Active Record nám nedáva len nástroje pre manipuláciu s dátami, ale poskytuje nám taktiež možnosť validácie vstupných dát a určenie vzťahov medzi tabuľkami.

Validácia vstupných dát

Validácia vstupných dát je jednou zo základných podmienok bezpečnosti a správnej funkcie webovej aplikácie. Active Record preto obsahuje vstavanú a veľmi prepracovanú validáciu, ktorá nám uľahčí množstvo práce. Chceme určiť, aby titulok článku nebol pri uložení prázdny

class Article extends AppModel{
   var $name = 'Article';
   var $validate = array(
           'title' => VALID_NOT_EMPTY,
           );
}

Týmto sme určili, že pri uložení článku, musí byť vždy atribút title neprázdny. Preto, keď sa pokúsime uložiť článok následovne, dostaneme chybovú hlášku, ktorá nás upozorní, že titulok článku nemôže byť prázdny.

$article = $this->Article->find(1);
$article['Article']['title'] = '';
$this->Article->save($save);

This field cannot be left blank

Používať môžeme aj niekoľko validačných kritérie pre jeden atribút. Chceme-li napríklad určiť, aby náš titulok nebol prázdny a zároveň aby mal minimálne 5 znakov a maximálne 100 znakov, nie je nič jednoduchšie:

class Article extends AppModel{
   var $name = 'Article';
   var $validate = array(
        'title' => array(
            'required' => VALID_NOT_EMPTY,
            'length' => array( 'rule' => 'validateLength', 'min' => 5, 'max' => 100 )
        ),
   );
}

Sami vidíte, že jednoduchšie to už ani nemôže byť. A k tomu ešte platí, že Cake automaticky vypĺňa hodnotu prvku formulára, pri neúspešnom uložení generuje chybovú hlášku pre každý prvok formulára (podľa určenia validácie v modely) a umožňuje nám určiť taktiež aj iné validačné pravidlá ako VALID_NUMBER, VALID_YEAR, resp. ľubovoľný vlastný regulárny výraz. Z tohto nám musí byť jasné, koľko práce, kódu a starostí máme ušetrených.

Vzťahy medzi tabuľkami

Posledná vec, ktorú spomeniem pri Active Record, sú vzťahy medzi tabuľkami. Active Record umožňuje mapovať vzťahy medzi tabuľkami ako napríklad 1:N, M:N atď. Vezmime si náš prechádzajúci príklad. Určite budeme chcieť mať autorov v osobitnej tabuľke. Vytvoríme si preto novú tabuľku s názvom authors. Každý článok bude mať práve jedného autora a autor môže mať niekoľko článkov, čiže tu máme väzbu 1:N. Kód bude nasledovný:

class Article extends AppModel{
  var $name = 'Article';
  var $belongsTo = 'Author';
}

class Author extends AppModel{
  var $name = 'Author';
  var $hasMany = 'Article';
}

Poďme si vytvoriť nového autora a následne nový článok s daným autorom:

$author['Author']['name'] = 'Linus';
$author['Author']['email'] = 'linus@aaa.com';
$this->Author->save($author);

+----+-------------+--------------------+
| id | name        | email              |
+----+-------------+--------------------+
|  1 | Linus       | linus@aaa.com      |
+----+-------------+--------------------+

$article['Article']['title'] = 'titulok';
$article['Article']['text'] = 'text';
$article['Article']['author_id] = 1;
$this->Article->save($article);

+----+-------------+-------+-----------+---------------------+
| id | title       | text  | author_id | created             |
+----+-------------+-------+-----------+---------------------+
|  1 | titulok     | text  | 1         | 0000-00-00 00:00:00 |
+----+-------------+-------+-----------+---------------------+

To bolo jednoduché. Keď sa teraz pozrieme na článok $this->Article->find(1), vidíme detaily, že nám všetko funguje správne:

Article =>
id: 1
title: Titulok
text: Text
author: Linus
created: 0000-00-00 00:00:00
Author =>

id: 1
name: Linus
email: linus@aaa.com

Aké jednoduché však? Nemuseli sme písať žiadne dodatočné SQL dotazy, stále nám stačí príkaz $this->Article->find(1). Jediné, čo je potrebné, je dodržiavať konvencie Cake a správne určiť vzťahy medzi tabuľkami (určiť správny vzťah medzi danými tabuľkami nám značne pomáha tzv. console, venovať sa jej budeme v niektorých z nasledujúcich častí) a v daných tabuľkách správne dodržiavať cudzie kľúče. Poďme sa preto pozrieť, ako vyzerajú dané tabuľky.

Z obrázku je jasné, že cudzí kľúč v tabuľke articles musí byť pomenovaný author_id, čo sú dané konvencie Cake, aby framework mohol určiť, že sa jedná o cudzí kľúč z tabuľky authors. Čiže vždy platí, že cudzí kľúč v tabuľke je zložený z jednotného číslo názvu tabuľky cudzieho kľúča a príslušného id, teda pre cudzí kľúč autora v tabuľke articles bude author_id.

Ako to bude s väzbou N:M? Opäť to bude veľmi jednoduché. Predstavme si situáciu, že článok môže mať niekoľko autorov a autor može mať niekoľko článkov. Tabuľky sú na sebe nezávislé a ich prepojenie bude zaisťovať špeciálna tabuľka, ktorú môžeme vidieť na obrázku.

Opäť musíme dodržiavať konvencie Cake, aby všetko fungovalo správne. Názov tabuľky articles_authors sa skladá z názvov tabuliek, ktoré sú vo vzťahu N:M, čiže articles a authors a navyše tieto tabuľky musie byť zapísané v abecednom poradí a oddelené podtržítkom. Kód bude potom nasledovný

class Article extends AppModel{
  var $name = 'Article';
  var $hasAndBelongsToMany = array(
          'Author' => array('className' => 'Author',
                        'joinTable' => 'articles_authors',
                        'foreignKey' => 'article_id',
                        'associationForeignKey' => 'author_id',
                           )
       );
}

class Author extends AppModel{
  var $name = 'Author';
  var $hasAndBelongsToMany = array(
          'Article' => array('className' => 'Article',
                        'joinTable' => 'articles_authors',
                        'foreignKey' => 'author_id',
                        'associationForeignKey' => 'article_id',
                           )
       );
}

Ešte treba poznamenať, že model sa pre spojovaciu tabuľku articles_authors nevytvára; vďaka dodržiavaniu konvencií Cake to nie je potrebné.

Týmto sme u konca. Dúfam, že sa mi podarilo zachytiť základné rysy a možnosti Active Record v CakePHP. Samotný návrh databáze a jej testovanie príde na radu v nasledujúcom článku.

       

Komentáře

[camlost]

pusobive? na me to skutecne zapusobilo - radsi zustanu u sql dotazu. lze je modifikovat pomerne nezavisle na vlastnim kodu, coz snizuje riziko zaneseni chyby.

[karotka]

Ano active record jsou pekne, napsani sql dotazu trva minutu s actice record pul minuty, ovsem do te chvile, nez narazite na neco s cim autor v navrhu jaksi nepocital, v te chvili to trva tyden :). Na jednoduche veci to samozrejmne staci, ale v pripade, ze napr. potrebujete optimalizovat dotaz a z nejakeho duvodu ho nepsat uplne jinak, stava se to naprosto nepouzitelne.

[vkuzel]

Pro spouštění komplikovanější sql příkazů, bude zřejmě sloužit metoda execute, viz dokumentace, na kterou uvedl autor článku odkaz.

[KK]

Jak už tu bylo řečeno výše, na spuštění vlastního SQL dotazu slouží metoda Model::query. Nechci se Cake zastávat ani ho hanit. Jsou věci které se udělají naprosto triviálně a jsou věci které zaberou den, než na ně přijdete.

[Pavel]

$article = $this->Article->find(1);
$article['Article']['title'] = 'nový titulok';
$this->Article->save($article);

Prilis nechapu logiku tohoto zapisu. Z jakeho kontextu se k vlastnosti Article pristupuje? Z metody tridy Article? Nebo z akce? Na co ukazuje promenna $this? A pokud je tento kod umisten v tride Article, proc je nutne pristupovat k vlastnosti Article a nestaci napsat rovnou $article = $this->find(1);? Dalsi otazka je podobna, proc ma pole vracene metodou find prvni rozmer Article? Cekal bych, ze staci zapis echo $article['title'].

[freshmouse]

Na tyto otázky bych taky rád znal odpověď.

Co se týče indexu "Article", na ten jsem se již ptal v prvním dílu článků.

[Daniel Kvasnička ml.]

$this je controller, Article je instance toho modelu do nej natazena nejakym $this->load... bla, bla..., to uz si presne nepamatuju. System Cake povazuju celkove za dost nestastny a trochu me zarazi, ze rozumny ORM planuji az na verzi 2... vzhledem k tomu, ze v1.2 je v beta stavu uz peknou radku mesicu... Ale koukam, ze maj novej web Tak asi se neco deje

[Tibor Piňo]

Dany zapis ktory som pouzil by bol zapisany v controllery napr. v triede ArticlesController a ten vola metody triedy modelu Article. Cize v danom controllery pristupujes k metodam modelu napr. takto $this->Article->find(1)

Odpoved preco su tam tie indexy sa uz diskutovala v prvom diely.

[Deleted [8409]]

Kdyby chtěl někdo něco podobného a mnohem robustnějšího v pythonu, tak doporučuju sqlalchemy (manuál).

[sNop]

Stale se rozhoduji mezi Zend, Prado a CakePHP a neumim se rozhodnout. Zatat tak zbezne studuji Zend, ale jen kvuli temu ze vsichni ho vychvaluji a je asi mezi PHP programatorama(i vnasich koncinach) nejpouzivanejsi. Byl bych rad, kdybyze autor clanku nejak povznese CakePHP a proc delat v nem. Ja osobne delam klasicke weby, login, diskusia, blog, kometare k clankom, novinky, ... Chysta se pro CakePHP nejake vyvojove prostredi ?

[Daniel Kvasnička ml.]

Velice bych ti doporucil zahrnout do vyberu i Kohanu (fork CodeIgniteru). Osobne ji pouzivam prave v kobinaci se Zendem (modularnost Zendu je obrovskou vyhodou) a jsem spokojen. Pro nekoho muze byt nevyhodou, ze jeji databazova vrstva je zatim dosti primitivni. Ale pro me to bylo spise vyhodou, rad si vybiram komponenty sam a zvolil jsem Propel (i kvuli jiste koncepcni podobnosti s Apache Cayenne). Prado nevim, jestli je to nejlepsi pro to, co delas. Je to stavovy komponentovy framework, ktery je vhodny spise na komplexni aplikace, ktere se maji chovat co nejvice jako desktopove. Tobe by asi spise vyhovoval nejaky vice "strankove" orientovany framework.

[.]

CakePHP podle mně lepší

[Daniel Kvasnička ml.]

Nez...? A alespon nejaky argument

[sNop]

Ale nadruhe strane, ted sem zase dodelal aplikaci (elektronicky obstaravaci system) a ta by se asi nejlepe delala v PRADO. V te aplikaci ani jedna stranka nema tu istu podobu, vse se pocita dynamicky, teda tym myslim hodnoty v tabulkach, zmeny barev pri zvyraznenach, zmeny fontu, sumare, vsetky ciselne polozky,.. ja sem to resil vsetko refresem(nastavitelny indetrval i v admin i v uzivatelske casti), coz neni ono. Nejlepsi by bylo, kdybyze se to cele chova jak desktoppova aplikace, teda veskera komunikace ze serverem na pozadi a minimum refresu alebo vubec zadne. A PRADO se mi libi, povodne sem programator v DELPHI a toto se doost podoba. Kohana mi pripada dost neznama a mala, nema vsechno co je potreba. Skratka chci nadrtit framewrok, ktery ma vizi a muzu snim delat jak jendoduche staticke stranky, tak i plne dynamicke AJAX stranky (polodesktopove). Ale KOHANU urcite tez obmrknu. Skratka musim patrat, ale zatim sem na uplneme zacatku. ;)

[Daniel Kvasnička ml.]

V te aplikaci ani jedna stranka nema tu istu podobu, vse se pocita dynamicky, teda tym myslim hodnoty v tabulkach, zmeny barev pri zvyraznenach, zmeny fontu, sumare, vsetky ciselne polozky,.. ja sem to resil vsetko refresem(nastavitelny indetrval i v admin i v uzivatelske casti), coz neni ono. Nejlepsi by bylo, kdybyze se to cele chova jak desktoppova aplikace, teda veskera komunikace ze serverem na pozadi a minimum refresu alebo vubec zadne.

To si myslim, ze ale neni uplne pripad PRADO a podobnych frameworku (ASP.NET, Wicket). Standardne AJAX nepouzivaji, jde jen o to, ze ukladaji stav View.

Kohana mi pripada dost neznama a mala, nema vsechno co je potreba.

No neznama, stavi na CodeIgniteru a ten neznamy rozhodne neni. Kohana jde dal v cistote navrhu a objektovosti a hlavne v reakcich na namitky uzivatelu. Firma stojici za CodeIgniterem je totiz delsi dobu ignorovala -- proto Kohana vznikla.

A ze nema vse co je potreba... no pro me to je vyhoda Cake ma "co je potreba" ale vsechno je relativne dost zadratovane do systemu a tezko se to vymenuje nebo odstranuje. Se Zendem bys na tom byl omnoho lepe.

[sNop]

J, Zend i tak uz pomaly studuji, ten se v bodouncu bude hodit tak ci tak, knihovny se daji pouzivat nezavisle na sobe. Ale muj nejzasadnejsi problem zatim je MVC, dost temu nechapu(i kdyz sem uz par veci precetl) asi proto, ze sem v tem nic jeste neudelal. Problem je, ze k popisu MVC neni zadna kvalitni literatura, budu muset najit neco na webu.

[Daniel Kvasnička ml.]

S MVC je to totiz tak, ze kolik developeru, tolik interpretaci... A navic je kolem toho hodne mytu a mnoho frameworku casti toho patternu dost priohybaji. ja na MVC pisu magisterku, tak kdyz ji dopisu ( ), tak ji pak nekam hodim.

V zasade je to tak, ze controller prijme udalost od uzivatele, na zaklade prijatych dat vykomunikuje s modelem co potrebuje a pak preda data view, ktery je potrebuje, aby uzivatel dostal na svou udalost odezvu.... a tak porad dokola.

S prichodem AJAXu vznikla i prima vazba mezi V a M, pricemz v realne implementaci tam ale stejne nejake to "malinke C" je Krasnym prikladem je javovsky AJAXovy framework DWR, ktery umoznuje primo z JS volat vypublikovane servisni tridy na serveru -- v realu tam samozrejme mezi tim je controller v podobe nejakeho servletu, ale v podstate je to komunikace V <-> M. Nebo View Helper pattern z J2EE, kdy JSP view nejen ze dostane data od controlleru, ale jeste muze pouzit beanu a natahnout nektera data mimo front controller -- extremne uzitecna vec pro psani prenositelnych view komponent.

[sNop]

A ze nema vse co je potreba... no pro me to je vyhoda :) Cake ma "co je potreba" ale vsechno je relativne dost zadratovane do systemu a tezko se to vymenuje nebo odstranuje. Se Zendem bys na tom byl omnoho lepe.

to je pravda, kdyz ty frameworky ovladas a oni neovladaji tebe, tak je urcite lepsi si vybrat framework, ktery neni tak robustni jako napr. KOHANA a knemu pripojit co je potreba, napr. ZEND,.. Ja by sem to udelal tak isto kdybyze ty frameworky znam a muzu si takto vybrat. Jenom je tu problem ze ze zacatku nemuzu drtit tri framworky + Javascript + AJAX, to skratka nejde. Ale jinak uplne stebou suhlasim.

ja na MVC pisu magisterku, tak kdyz ji dopisu ( ;) ), tak ji pak nekam hodim.

tak to je super nahoda, kdy to chystas dokoncit ? ale kdyz mas uz nejakou chopnou verzi tak mi to klidne muzes poslat na mail, nenahnevam se :)

[Daniel Kvasnička ml.]

tak to je super nahoda, kdy to chystas dokoncit ? ale kdyz mas uz nejakou chopnou verzi tak mi to klidne muzes poslat na mail, nenahnevam se :)

To bude az na podzim, ted v lete to ani statnice nestihnu

[sNop]

skoda, nevis mi doporusit nejaku dobru knihu alebo i anglicky clanek (s ang. nemam problem), nic dobre a ucelene sem zasti nenasel, jakoze ci nemas neco fakt dobre bookmarkle :) jinak ja si poradim

[Daniel Kvasnička ml.]

http://del.icio.us/smilelover/MVC ...a Rudolf Pecinovsky to docela rozebira take v knize Navrhove vzory. Tu je vubec dobre si poridit. Nestarne totiz s verzemi jazyku tak jako ruzne prirucky, ale obsahuje obecne vzory.

[kralyk z abclinuxu]

Dík za celkem pěkný článek, akorát bych autorovy doporučil aby nesrovnával pořád Cake s jinými metodami jako psaní sql dotazů a zůstal více nestranný ve svém popisu Cake. Stálé vyvyšování předností Cake oproti ostatním technikám ho dostává do nepříjemného postoje, jak je ostatně vidět v diskuzích...

[dc]

Trosku off topic, mierne som na nervy z toho bordelu ktory vznika vdaka JavaScriptu Ajaxu a JS kniznic. Potrebujem aby webova aplikacia bola dynamicka a pomerne casto clovek bojuje s roznou interpretaciou IE/Mozilla/etc. Takze k veci, skusal niekto Flex? Robil niekto v tom nieco vecsie, nejaku komplexnu webovu aplikaciu ? Neni to uplne to prave, ale zasa sa daju trochu obist obmedzenia webu a mozno aj niektorych frameworkov.

[&#*$@(]

...it always ends totally screwed up, because the programmer concentrated more to framework creation than to the project itself ya dummies.

[tom]

to je sice hezky , na jednu stranu to praci ulehci , ale zapamatovat si slova jako associationForeignKey to zas praci protizi , proto je lepsi napsat klasickej vypis z SQl SELECT * FROM user, article WHERE article.user_id = user.id

[Tibor Piňo]

Pokial navrhujes databazu podla konvencii CakePHP, nic si pamatat nemusis, cakephp automaticky pouziva konvencie.

[Tibor Piňo]

A este som zabudol dodat, ze ak sa pouziva ine znacenie, ako su konvencie, mozes si ich explicitne nastavit pri urcovani vazieb v modely a kazdy dodat sa bude riadit podla tvojich pravidiel.

[jackyseo15]

검증된 파워볼사이트 를 찾으신다면 eos파워볼사이트 가 있는 파워볼사이트추천 에서 파워볼 을 즐기시길 바랍니다. 5년 이상 운영된 메이저업체 이며 지금까지 많은분들께 사랑받은 안전한파워볼사이트 입니다. 안전한파워볼사이트

[Adilkhatri]

For this situation you will start it is essential, it again creates a site a solid noteworthy web webpage: 먹튀검증커뮤니티