konstruktor v modelu

o5 napsal(a):

Ovšem tohle neprojde (chyba níže), protože je to: špatná logika OOP / nette neumožňuje ?

Fatal error: Call to a member function query() on a non-object in /libs/dibi/libs/DibiTableX.php on line 259

To, či je to zlá logika OOP nechám na teba, Nette to samozrejme umožňuje.

Chyba zjavne popisuje, že voláš query() na niečom, čo nie je objekt.

Typicky sa toto môže stať napríklad v prezenteri:

class MyCoolPresenter extends MyBasePresenter
{
    protected $model;

    public function actionWhatever()
    {
        $model = new MyCoolModel('typeA');
    } # $model sa zahodí

    public function renderWhatever()
    { # tu je $model nová premenná
        $this->template->result = $model->getResult();
    }
}

keď namiesto $this->model píšeš len $model. Chyba samozrejme môže byť i inde, no zjavne ak model vytvoríš a potom na ňom voláš query(), v tom momente to objekt nie je. V takýchto prípadoch často pomôžu Notice:-ky.

_Martin_ napsal(a):

o5 napsal(a):

Ovšem tohle neprojde (chyba níže), protože je to: špatná logika OOP / nette neumožňuje ?

Ani jedno, ani druhé, chyba pravděpodobně vyskakuje proto, že jsi přepsal původní konstruktor, který (mimo jiné) zajišťuje získání připojení k databázi (viz. API reference).

Presne tak. Tiež treba čítať celé chybové hlášky, nie len prvú časť ako ja :-)

A samozrejme vždy volať rodičovský konštruktor:

class MyModel extends DibiTableX
{
  public function __construct($type)
  {
    parent::__construct();

    if($type == "typeA")
    {
       $this->primary = "id_tableA";
       $this->name = "tableA";
       $this->primaryModifier = "%i";
    }
    else
       //atd
  }
}

kravco napsal(a):

Presne tak. Tiež treba čítať celé chybové hlášky, nie len prvú časť ako ja :-)

A samozrejme vždy volať rodičovský konštruktor:

class MyModel extends DibiTableX
{
  public function __construct($type)
  {
    parent::__construct();

    if($type == "typeA")
    {
       $this->primary = "id_tableA";
       $this->name = "tableA";
       $this->primaryModifier = "%i";
    }
    else
       //atd
  }
}

Spíš bych to dělal obraceně, tedy nejdříve nastavoval ->name a pak volal rodičovský konstructor, protože se v něm vola DibiTableX::setup(), které ->name a další defaultně nastavuje (když nejsou):

class MyModel extends DibiTableX
{
	public function __construct($type)
	{
		if($type == "typeA")
		{
			$this->primary = "id_tableA";
			$this->name = "tableA";
			$this->primaryModifier = "%i";
		}
		else
		//atd

		parent::__construct();
	}
}

David Grudl napsal(a):

No, raději jsem z příkladů třídu DibiTable odstranil, ať to nesvádí k jejímu používání.

Totiž příklad Akrabat měl být co nejvíce 1:1 transformací Zendovského příkladu do Nette, jenže to asi nebyl úplně dobrý nápad, protože jsem použil techniky, které nepovažuju za nejlepší. Pro začátek jsem se tedy zbavil DibiTable a nejspíš asi dám pryč i variantu „old“, nebo ji alespoň přesunu mimo distribuci. Samozřejmě ještě musím znovuzprovoznit verzi „forms“, která háže chybu kvůli chybějícímu parametru v šabloně.

Můžu se tě zeptat proč je nepovažuješ za dobrý nápad? Osobně taky používám DibiTable ale ne přímo. Jak to používám já bude asi jasnější z příkladu.

<?php
class Test extends DibiTableX
{
	protected static $all;

	public static function getTestByName($name)
	{
		self::loadAll();
		foreach (self::$all as $value)
		{
			if ($value->name == $name)
				return $value;
		}
		return FALSE;
	}

	public static function getTestById($id)
	{
		self::loadAll();
		if (empty(self::$all[$id]))
			return FALSE;
		return self::$all[$id];
	}

	public static function getAll()
	{
		self::loadAll();
		return self::$all;
	}

	protected static function loadAll()
	{
		if (empty(self::$all))
		{
			$cache = Environment::getCache();
			if (isset($cache['Test']))
				self::$all = $cache['Test'];
			else
			{
				$test = new Test();
				$res = $test->findAll();
				if ($res->count() > 0)
				{
					foreach ($res->fetchAll() as $value)
						self::addTest($value->id, $value->name);
				}
				$cache->save('Test', self::$all, array('expire' => time() + 60 * 60, ));
			}
		}
	}

	protected static function addRole($id, $name)
	{
		return self::$all[$id] = new TestItem($id, $name);
	}

	public function insert($data)
	{
		$this->connection->query('INSERT INTO %n', $this->name, '%v', $this->prepare($data));

		self::reloadCache();

		return $this->primaryAutoIncrement ? $this->connection->insertId() : NULL;
	}

	public static function reloadCache()
	{
		self::$all = NULL;
		$cache = Environment::getCache();
		unset($cache['Test']);
		self::loadAll();
	}
}
class TestItem extends Object
{
	public $id;
	public $name;

	public function __construct($id, $name)
	{
		$this->id = (int)$id;
		$this->name = (string)$name;
	}

	public function delete()
	{
		$test = new Test();
		$test->delete(array('id' => $this->id));

		Test::reloadCache();
	}
}
?>

To že načítam všecho je dobře protože předem vím že budu potřebovat všechny položky… A pak někde dál můžu potřebovat zobrazi třeba jenom jednu a tak si uchovam v paměti všechny… A to že mám další svoje statické metody uvnitř modelu dohromady s dibi table vim neni to nejidealnejsi mohl bych dibi table mit ve jako class Text a metody ktery nad ni volam mit třeba v classu TestFilter… Ale takhle mě to příde pohodlnější… A tak se ptám je použití DibiTable (DibiTableX) špatné řešení? Pokud ano tak proč?

Jenom bych vypíchnul jeden Davidův příspěvek na dibifóru: https://forum.dibiphp.com/…iewtopic.php?…

OT: předpokládám nASi že se uvidíme na trpasliconu ;], jestli to není jen záměna nicku (pochybuji). Zajímalo by mě zda se tam nechystá více příznivců Nette. Mohli by sme si třeba chvilku sednout na pivo či vínečko a pomlouvat Davida. ;]

Sejít se nad kávou či pivem, tedy nad jedem dle chuti, a pomlouvat Davida zní jako dobrý plán, ale já se tou dobou zrovna rekreuju na horách, takže letos se bude trpasliconit beze mě.

Tak to je teda pecka! Nádhera! Díky moc!

David Grudl napsal(a):

Klíčové je, že se provede jen jeden (!) SQL dotaz, který žádá přesně jen ta data, která se budou potřebovat. Zároveň model není nijak zatížen prezentační logikou, nezajímá ho stránkování.

Dobrý, ne?

Awesome! :)

To budú asi selecty dva :) , asi tým myslel, že to selectovanie obsahu je len jeden select a dá sa s tým pekna pracovať.

Davide, buď umíte kouzlit, nebo se mám ještě hodně co učit. Dost možná obojí ;-) Mozek se mi stále cyklí na poněkud převráceném pořadí řádků kódu. Nejdříve spočítáte počet všech záznamů count($articles) (z tohoto chápu, že musíte naplnit celé pole, abyste mohl spočítat počet řádků). A až následně omezíte vrácené záznamy přes where a limit. Z toho mi vyplývá, že by muselo být pole naplněné celou tabulkou a pak přes cykly a podmínky se zahazovaly nepotřebné řádky. Ale takhle by to zase dělala lama největší, nikoli David Grudl. Tuším správně, že v nevinném count($articles) je skryt nějaký fígl, který skočí do budoucnosti a mrkne na sql_calc_found_rows později omezeného dotazu? Protože jinak to asi jedním dotazem do databáze udělat nepůjde.

Legen… wait for it …dary!

Je to luxus ať už tam SELECT count(*) je nebo neni :)

LuKo napsal(a):

Jakou technikou se count($articles) převede na $articles->count();?

Pomocí rozhraní Countable, které DibiDataSource implementuje.

brablc napsal(a):

Na prvni pohled musi byt volani count($articles) nejen pomalejsi nez $articles->count() (nutnost detekce rozhrani) ale musi nutne vest ke zmateni prumerneho ctenare. Objektove volani metody by bylo jasne vsem i bez toho, abychom museli vedet, zda je interface Countable implementovan.

Používej to jak chceš. David jen ukázal jednu z cest.

LuKo napsal(a):

(…) Druhá je pak dodatečná podmínka uvedená v ukázce $articles->where('date < %d', time()); – tímto získám jinou množinu výsledků, než jsem spočítal. Tím pádem se mi vygeneruje špatný počet odkazů paginatoru. Neměla by tedy být tato dodatečná podmínka spíš nad count($articles). (…)

To by stejně nepomohlo. DibiDataSource je napsaný tak, že count() vrací vždy počet řádků dotazu, kterým byl DS inicializován. V uvedené ukázce bude v opravdu paginátor vracet nesprávné výsledky. Na myšlence to ale nic nemění. Jenom je třeba počet řádků do paginátoru dostat jinak (_toString() vrací aktuálně platný dotaz; zavolat na něj SELECT count(*) je až směšně jednoduché).

Editoval Villem (6. 2. 2009 17:50)

Villem napsal(a):

To by stejně nepomohlo. DibiDataSource je napsaný tak, že count() vrací vždy počet řádků dotazu, kterým byl DS inicializován. V uvedené ukázce bude v opravdu paginátor vracet nesprávné výsledky. Na myšlence to ale nic nemění. Jenom je třeba počet řádků do paginátoru dostat jinak (_toString() vrací aktuálně platný dotaz; zavolat na něj SELECT count(*) je až směšně jednoduché).

Mně spíš šlo o to, zda tak, jak je to v příkladě napsané, paginator vypíše správný počet příspěvků podle až později definované podmínky. Zda tam není nějaký skrytý fígl.

enoice napsal(a):

Tak to ale ani nemá fungovat, první sql query má vybrat všechny zobrazitelné záznamy (pokud uživatel některé nemá mít možnost vidět, tak tam nemají být) – z těch se vypočítá počet. Ty pozdější podmínky už určují spíše co se zobrazí a neovlivňují původní počet pro paginaci

Je to přesně tak, jak říkáš – a právě proto v tom (logicky) jiní hledali nějaký fígl, neboť takovýto postup rozhodí stránkování. Správně by se stránkování muselo provádět až nad konečnou (všemi podmínkami ořezanou) sadou záznamů.

enoice napsal(a):

Nevím, zda-li si dobře rozumíme. Já obhajuji Davidův postup, myslím, že je správný. Nejsem si jistý jestli se opravdu shodujeme :)

Davidova myšlenka DataSource je geniální, o tom není sporu. Pouze hledám skrytý fígl v podle mě nevhodně umístěné dodatečné podmínce. Zkusím doplnit komenty:

class MyPresenter
{

        public function renderDefault($page)
        {
		/** vybere určitou množinu článků, celkem jich je 45 **/
                $articles = $this->model->getArticles(...);

                $paginator = new Paginator;
                $paginator->itemsPerPage = 40;
                $paginator->itemCount = count($articles); // vrací celkový počet článků (45) -> paginator vygeneruje odkazy na stránky 1 a 2
                $paginator->page = $page;

                // omezíme datasource na LIMIT a OFFSET -> omezíme na prvních 40 článků
                $articles->applyLimit($paginator->length, $paginator->offset);

                // a ještě přidáme nějakou dodatečnou podmínku -> této podmínce však vyhoví jen 38 článků
                $articles->where('date < %d', time());

		/** v šabloně se zobrazí 38 článků a paginator vygeneruje slepý odkaz na stránku 2 **/
                $this->template->articles = $articles;
        }
}

Už si trochu rozumíme, s čím vás tu celou dobu prudím? :-) Ikdyž mi to připadá jako chybně umístěná dodatečná podmínka (měla by být před definicí paginatoru), hledám v tom skrytý Davidův úmysl, jehož genialitu stále nejsem s to pobrat ;-)

LuKo napsal(a):

Už si trochu rozumíme, s čím vás tu celou dobu prudím? :-) Ikdyž mi to připadá jako chybně umístěná dodatečná podmínka (měla by být před definicí paginatoru), hledám v tom skrytý Davidův úmysl, jehož genialitu stále nejsem s to pobrat ;-)

Aj, byl jsi rychlejší =)

LuKo napsal(a):

Už si trochu rozumíme, s čím vás tu celou dobu prudím? :-) Ikdyž mi to připadá jako chybně umístěná dodatečná podmínka (měla by být před definicí paginatoru), hledám v tom skrytý Davidův úmysl, jehož genialitu stále nejsem s to pobrat ;-)

Je v tom jeden fígl. A ten že count($datasource) vrátí stejný výsledek at už před tím zavoláš $datasource->where(...) s jakým koliv dotazem. Proto je uplně jedno v které části si necháš spočítat počet řádků. A proto možná ostatní nechápou co na tom nechápeš ty :).

Villem napsal(a):

enoice napsal(a):

Ale tomuhle problému se samozřejmě vyhnete, když přidáte podmínku před count, (…)

Právě že ne. Podívej se na můj předchozí příspěvek, nebo do kodu DibiDataSource. Count se počítá z původního doatazu, kterým byl DS inicializován.

Áha, tak nad tím by se mělo zauvažovat.

_Martin_ napsal(a):

enoice napsal(a):

Nevím jestli to bude dobrý příklad, ale v soutěži bude třeba prvních deset míst a budeme chtít zobrazit pouze ženy, které se umístily v první desítce – a deset žen umístěných na prvních místech.

Tomu moc nerozumím… můžeš to trochu rozvést?

Pro paginaci je to asi logicky nevyužitelné. Ale třeba je taková situace, že budu mít celkový počet soutěžících třeba 45, v první desítce se umístilo 6 mužů a 4 ženy. V logice aplikace bude určen výpis jen oné první desítky, a pak bude šablona, která si bude sama určovat, jestli chce zobrazit všech deset, nebo jen muže (6), nebo jen ženy (4). Kdyby se tato podmínka zahrnula do countu a až později do limitu zobrazení, pak by se zobrazovalo bud 10 lidí, nebo 10 mužů, nebo 10 žen.

Asi to je ale opravdu poněkud špatný příklad. Metafory a ukázkové příklady nejsou mou silnou stránkou ;)

DibiDataSource je jak už název napovídá rozhraní ke zdroji dat. V této konkrétní implementaci se snaží vytvořit vrstvu k tabulce jako výsledku databázového dotazu. Svým určením je koncipován jako výstup z modelu.

Proto není jeho ukolem zvladat presentační logiku, pouze pro ni získává data. Navíc nemůže být na tuto logiku nijak vázán. Představte si jednoduchý CMS, kde přijde požadavek na zobrazení seznamu užvatelů. Výstupem z modelu je DataSource, kde každý řádek obsahuje informace o uživately jako jméno, přezdívku, počet článků, jestli je on-line, prostě výsledek posbíraný z mnoha tabulek v DB. O tom, které kontrétní uživatele je nutné vypsat ale rozhoduje presenter.

A tady se dostávám k tomu where. Model vůbec nemusí vědět, že uživatel chtěl zobrazit pouze uživatele daným počtem, příspěvků a navíc ho zajímá pouze jeho stav. A nebo si nechal zobrazit informace o nějakém konktrétním uživately.

Navíc takto koncipovaný model je unverzálnější, protože nad jedním datasource je možné postavit spoustu ruzných tiskových sestav.

Možná, že použitý příklad je lehce zavádějící, ale to co kolem toho David napsal je dle mého dostatečně vysvětlující.

LuKo napsal(a):

Jedna záhada zdá se být odhalena. Pak jsou tu ale další dvě. Jakou technikou se count($articles) převede na $articles->count();? Druhá je pak dodatečná podmínka uvedená v ukázce $articles->where('date < %d', time()); – tímto získám jinou množinu výsledků, než jsem spočítal.

Správná připomínka, v DibiDataSource je bug, metodu count upravím. Na spočítání samotného zdroje přidám asi getTotalCount().

pmg napsal(a):

Mocné a přitom jednoduché řešení, gratuluji. Také koukám, že už se dají dělat zanořené transakce a DibiFluent je integrováno do DibiTable. Děkuji za tato příjemná vylepšení. Dovoluje mi to zapomenout na Doctrine, ze které se mi dnes udělalo zle.

OT: Zdravím! :) Tak vidíš, vše je již vyřešeno. :)

pmg napsal(a):

Doctrine třeba umí relace, takže se dá napsat $category->Articles a tabulka se sama připojí podle definovaného vztahu. K tomu je potřeba poznamenat jednu věc: ve vztahu M : N je málokdy potřeba spojovat všechny tři tabulky, takže ten join nebývá tak složitý.

Dibi by se ale mohlo naučit vztah rozpoznávat a doplňovat automaticky podle výčtu položek. $category->select('name, count(Articles)') by podle nastavených konvencí přidalo join('articles_categories ON category.id = articles_categories.category'), a pokud bych v dotazu chtěl jiné než souhrnné informace, tak ještě join('articles ON articles_categories.article = articles.id'). Typ vztahu by se dal detekovat automaticky podle existence spojovací tabulky (její třídy) nebo by šlo vztahy vyčíst přímo z databáze podle indexů a restrikcí.

Dělat tohle za běhu aplikace není v 99 případech ze sta nutné. Proto se domnívám, že režie s tím spojená by byla obrovská. Může se to hodit při vývoji aplikace, abys nemusel přepisovat dotazy, ale na to se hodí nejaký externí prográmek, který projde tvoje zdrojáky dotazy doplní před tím, než se do toho pustí php.