Jak na model v Nette?

Podle mě Nette model nijak zvlášť neřeší. Nejlepší asi bude, když si vyrobíš v app složku models a tam budeš dávat soubory s třídami modelu podle vlastních potřeb. Mohou to být třeba i rozšířené třídy DibiTable.

No a pak v presenteru můžeš volat např. new Model i bez require, protože pokud prochází RobotLoader složku app, projde i app/models.

Čav, toto som sa chcel aj ja už dlhšiu dobu opýtať, ako to kto robí.
Ja to robím takto:

Mám adresár app/models kde mám modely.
Každý model patrí k jednému modulu, resp. presenteru.
Takže modul news sa volá NewsPresenter (prípadne NewsModule/DefaultPresenter).
Rovnako nazvem aj modul podla názvu, takže NewsModule.
NewsModule bude obsahovať hlavne metódy na prácu s databázov a ďalšie logické.
Pre zoznam noviniek si napríklad spravím metódu getAllNews, ktorú budem volať v presenteru aby mi vrátila všetky novinky.
V presenteru v startup si vytvorím inštanciu modulu.

<?php
function startup()
{
	$this->module = new NewsModule();
}
?>

A potom to normálne využívam v presenteri:

<?php
function actionDefault()
{
	$news = $this->module->getAllNews();
}
?>

Neviem ako to robia ostatní ale mne sa to zdá najlogickejšie, ak to niekto rieši lepšie, mohol by sa s nami podeliť :)

Ano otom som rozmýšlal. dibi disponuje tým statickým oným (zabudol somako sa to volá dibi::) :D , ale vezmime si napríklad že tam chceme udržiavať connection, alebo nejaké data. Potom statické volanie neni moc výhra.

Villem napsal(a):

Model, pokud jej vyžaduješ, by měl obsahovat/implementovat pouze tzv. aplikační logiku. Tedy manipulaci, získávání a ukládání dat. Rozhraní getrů a setrů je jenom jedna možnost implementace.

V tomto konkrétním případě (quickstart) by navíc daný případný model jenom předával neupravené výstupy z dibi dál, takže bys jenom zbytečně tvořil jakýsi adaptér, aniž bys jej potřeboval (např. z důvodu typové kontroly).

V tom „co“ je model a co má dělat mám jasno. Uváděl jsem setry a getry právě jako implementační příklad, který obecně používám. Šlo mi spíš o to, kam v nette „modely“ ukládat, případně jaké kdo používá techniky.

David Grudl napsal(a):

Jod napsal(a):

Neviem ako to robia ostatní ale mne sa to zdá najlogickejšie, ak to niekto rieši lepšie, mohol by sa s nami podeliť :)

Dělám to v podstatě takto.

A toto mi v podstatě vše zodpovědělo. Přesně něco takového jsem si představoval :)

Teď by mě už opravdu jen zajímalo, jak to řeší ostatní…má tu někdo nějaký sofistikovanější přístup? :) Samozřejmě který by nám vysvětlil a shrnul případné výhody a nevýhody ;)

Zatím všem díky za odpovědi.

Toto sa mi nejak nepáči. Najmä keď dáta z modelu predávaš nejakému kontrolu.

_Martin_ napsal(a):

Jod napsal(a):

Toto sa mi nejak nepáči. Najmä keď dáta z modelu predávaš nejakému kontrolu.

Mě se to naopak líbí. Je to plně v souladu s popisem architektury MVP, resp. MVC. Pokud se model rozšíří o skupinu setterů, bude mít presenter možnost měnit model v závislosti na reakci uživatele, a view si getterem bude brát data, nestaraje se o nic jiného.

Súhlas, myslel som to podobne.

Jod: toto riešenie nie je úplné, malo len načrtnúť myšlienku. Určite je v ňom potrebné vyriešiť to, aby do šablóny išiel model read-only, čiže napr:

class NewsPresenter extends MyBasePresenter
{
    // ...
    function renderDefault()
    {
        $this->module->readOnly = TRUE;
        $this->template->news = $this->module;
    }
}

A spraviť si objekt, ktorý sa môže rozhodnúť byť read-only:

class ReadonlyableObject extends /*Nette\*/Object
{
    protected $readOnly = FALSE;

    public function getReadOnly()
    {
        return $this->readOnly;
    }

    public function setReadOnly($value)
    {
        $this->readOnly = $value;
    }

    public function __set($name, $value)
    {
        if ($this->readOnly) {
            throw new Exception("Instance of ". get_class($this) ." is read-only.");
        }

        parent::__set($name, $value);
    }
}

A potom už len dediť…

Myslím, že to není dobré řešení:

• při jakékoliv chybě, třeba když ti spadne DB, jseš už v šabloně a tedy na konci životního cyklu presenteru. Chybu ošetříš jen obtížně a určitě ne transparentně.
• jak už bylo řečeno výše, měnit model v šabloně je dost špatné řešení. Read only viz výše to řeší jen částečně – musely by se kontrolovat i všechny metody. A pak, co uděláš s výjimkou v šabloně?
• html generuješ v modelu. To se vymstí hned jakmile budeš potřebovat to samé exportovat do RSS, poslat jako plaintext mailem nebo třeba někde jinde na webu zobrazovat jen nadpisy místo celé zprávy.

Myslím je praktičtější používat něco jako toto:

class NewsPresenter extends MyBasePresenter
{

    function startup()
    {
        $this->module = new NewsModule;
    }

    function renderDefault()
    {
        $this->template->news = $this->module->getAllNews();
        // vraci pole nebo pripadne nejaky primitivni objekt pro ulozeni dat
    }

}
<body>
    {cache 'news/all'}
    {foreach $news as $line}
    <h2>{$line->header}</h2>
    <p>{$line->text}</p>
    {/foreach}
    {/cache}
</body>

Wosonj napsal(a):

• při jakékoliv chybě, třeba když ti spadne DB, jseš už v šabloně a tedy na konci životního cyklu presenteru. Chybu ošetříš jen obtížně a určitě ne transparentně.

S tím by mohl být problém.

• jak už bylo řečeno výše, měnit model v šabloně je dost špatné řešení. Read only viz výše to řeší jen částečně – musely by se kontrolovat i všechny metody. A pak, co uděláš s výjimkou v šabloně?

Zabránit změnám modelu z view by se nějakým způsobem zcela jistě dalo. Výjimka by pravděpodobně šla řešit bufferováním výstupu a jeho smazáním při zachycení výjimky.

• html generuješ v modelu. To se vymstí hned jakmile budeš potřebovat to samé exportovat do RSS, poslat jako plaintext mailem nebo třeba někde jinde na webu zobrazovat jen nadpisy místo celé zprávy.

Nevím, jak přesně svůj kód myslel kravco, ale já jej pochopil takto:

<body>
    {cache 'news/all'}
    {foreach $news->getAllNews() as $line}
    <h2>{$line->header}</h2>
    <p>{$line->text}</p>
    {/foreach}
    {/cache}
</body>

Problém sem vnáší ono kešování – když posílám stránku z keše, pravděpodobně nebudu chtít, aby aplikace ještě tahala data z databáze a nějakým způsobem je zpracovávala. Vlastně mě to přivádí k otázce, kde začíná view. V šabloně? V metodě beforeRender?

kravco napsal(a):

Problém sem vnáší ono kešování – když posílám stránku z keše, pravděpodobně nebudu chtít, aby aplikace ještě tahala data z databáze a nějakým způsobem je zpracovávala. Vlastně mě to přivádí k otázce, kde začíná view. V šabloně? V metodě beforeRender?

Tomuto nerozumiem, snažil som sa o to, aby sa výstup kešoval – teda dáta z db sa ťahať nebudú, ak je stránka dostupná v keši…

Však ano, ty to přesně tak zamýšlíš, ale Wosonj si toho nevšiml (jeho řešení tahá data nezávisle na keši), tohle nebyla reakce na tebe =)