DibiDataSource v aplikaci

phx

Zdravim.

Jakmile se objevila DibiDataSource zacal jsem premyslet o nastinenem navrhu a vidim v nem jeden problem ve spojeni s Nette.

Myslenka to je uzasna, ze by se z DB nacitaly pouze potrebna data. Neboli Presenter/ ziska DibiDataSource (dale DDS), aplikuje omezeni filtru (uzivatelsky filtrovatelny vypis), ziska z nej celkovy pocet zaznamu (strankovani) a DDS preda view (sablone, *.phtml). Sablona si urci jake sloupecky nacitat a pozada si o data. Logiku to ma bezchybnou, Model se stara o zpristupneni dat, Presenter urci co a jak dle uzivatelva prani a sablona urci co z tech dat chce zobrazit. Nikde neni nic navic.

Ale co kdyz dotaz na databazi skonci chybou??? Jakakoliv vyjimka v sablone je odeslana jako Warning do prohlizece. Jeste lepsi to je v Produkcnim modu, kdy se nezobrazi nic:) (coz chapu proc) A ladenka nebo errorPresenter ji vubec nezachyti. Co s tim?

Diky za nakopnuti.

Editoval phx (25. 2. 2009 21:53)

David Grudl

Výjimka by měla být odeslána jako výjimka, nikoliv warning. Teda – je potřeba se vyhýbat konstrukci {!$content} resp. <?php echo $content ?>, ale používat korektní {include $content} resp. <?php $content->render() ?>. Nicméně aby všechno fungovalo ok, bylo by potřeba aktivovat nějaký output buffering.

phx

Aha. Uzasne… Krasa… Klanim se…

Jen uz nevim kde jsem onu konstrukci <?= $content ?> nebo {!$content} opsal:)

David Grudl

Teda takto, na {!$content} není z hlediska Nette nic špatného, slovo korektní jsem myslel ve smyslu PHP a výjimek.

crempa

Mrknul jsem ted podrobneji na DibiDataSource resp. filozofii jeho pouzivanji v kontextu k Nette a nejak to nezapada do meho pojeti rozdeleni ukonu v ramci MVP. Mel jsem za to, ze vse co se deje a tyka databaze ma byt bezpodminecne v casti modelu a proto i kdyz totalne prekopu databazi tak jedine kam musim hrabnout budou soubory modelu. Vyse uvedena koncepce vsak vede k prekopani kodu na vsech urovnich aplikace… na druhou stranu je rozdeleni dotazu v zavislosti na prezentacni logice resp. vyber toho co vlastne chci videt do pohledu taktez logicke…

Hadam, ze v tomto smeru asi neexistuje zadne dogma, nebo se pletu? Jak k danemu problemu pristupujete v aplikacich vy? Mate model jen jako vychozi bod nebo se stara i o casti z prezentacni logiky, ktere jsou primo spjate s databazi ?

pro zajimavost jeste budu citovat Davida z jine diskuse (tady):

Takže dgx-ova břitva dobrého MVC:

když změním názvy sloupců v databázové tabulce, bude nutné editovat kód controlleru či view?

když změním HTML rozhraní za Flashové, bude nutné editovat kód modelu? (zmíněno i v článku)

když přehodím rozložení prvku na stránce, bude nutné editovat controller nebo model?

kde se dle meho prvni bod rozchazi s prikladem uvedenym zde na foru

David Grudl

crempa napsal(a):

kde se dle meho prvni bod rozchazi s prikladem uvedenym zde na foru

Představ si, že tam prostě bude

return $this->connection->dataSource('SELECT col1 AS alias1, col2 AS alias2 FROM table1 INNER JOIN table 2 ... WHERE ... GROUP');

Jod

Čo si myslíte otom, keď v modelu vytvorím dotaz cez DibiFluent, ale model vracia DibiDataSource pomocou DibiFluent::toDataSource? Administračná stránka s gridom, filtrom, či formulárom sa mi pohybuje okolo 100–150ms, zatiaľ som netestoval či by sa zrýchlila, keby som používal len datasouce. Môžem ďalej pokojne používať takúto konštrukciu, alebo by bolo lepšie vytvárať priamo datasouce, sú tie prevody stabilné? Všimol som si, že sa to konvertuje pomocou subselectu, mal som s tým nejaký problémik myslím.

phx

to crempa: Ohledne konceptu MVP se to chystam vyresit za pomoci

dibi::setSubstFallBack('mojeORM');

Kde zajistim preklad nejakych modelovych sloupecku na skutecne sloupecky v DB. Napr syntaxi Model.sloupecek, ktery mojeORM nahradi za spravny nazev sloupecku v DB.

// view
$ds->select(':Model.sloupecek:');

I kdyz muj koncept se mi stale vnitrne (dusevne, ne kodem PHP) nelibi.

Editoval phx (26. 2. 2009 11:15)

Ondřej Mirtes

Proč si zesložiťovat život 100%ním dodržováním MVC návrhu? (tzn. při změně sloupců v DB zachovat funkční view + presenter bez jeho modifikace?). Psát všude SELECT col1 AS alias1, col2 AS alias2 jen kvůli tomuto mi přijde šílené.

Jod

Čo tak dostať z modelu pole stĺpcov a vykresliť ich vo view. A máme po probléme :D

David Grudl

LastHunter napsal(a):

Proč si zesložiťovat život 100%ním dodržováním MVC návrhu? (tzn. při změně sloupců v DB zachovat funkční view + presenter bez jeho modifikace?). Psát všude SELECT col1 AS alias1, col2 AS alias2 jen kvůli tomuto mi přijde šílené.

Přesněji řečeno, MVC nic netvrdí o tom, že při změně sloupců se nesmí modifikovat view nebo presenter. Při změně modelu se naopak počítá s tím, že se presenter/view změní. Jde spíš o to, jestli musí změna sloupců (tj. vnitřní záležitost modelu) měnit i (venkovní) API modelu.