Jak jednoduše vkládat komponenty do šablony?

Fajn, zkusím to popsat z jiné strany. Jak bych si to představoval:

1. Vytvořím obecnou komponentu Moje v app/components
2. V šabloně uvedu {control moje}
3. Presenter se podívá, jestli zná metodu createComponentMoje. Nezná, takže se podívá do app/components, jestli existuje komponenta Moje. Existuje, takže ji použije a vykreslí, aniž bych musel psát ty 3 řádky, kde akorát vytvořím instanci a vrátím ji.

Řešil už někdo takovou situaci? Je na to v Nette nějaký dobrý pattern?

EDIT: Chápu, že komponenta může reagovat na signály, ale v mojem případě je to jen kus HTML kódu, který bych rád definoval jen jednou pro více použití.

Editoval Pavel S. (20. 8. 2012 15:52)

@duke: je to továrna, není to komponenta!

@22 Metoda createComponentMyComp je továrna pro komponentu myComp, kterážto je typu Moje.

@Pavel S.: možná se ti to zdá jako obtěžování, ale ručně vypsat všechny komponenty do továrniček, které pak v daném presenteru (jeho šabloně) použiješ, je ten nejlepší možný přístup.

@duke: bez komentáře.. to je marný

Já myslel, že jsem na tohle odpovídal a teď koukám, že ta odpověď byla úplně v jiném vlákně, kde se řešil stejný problém.

Můžeš si udělat supertovárničku přetížením metody createComponent($name). Je to maličko magie, tak s tím opatrně, doporučovaný postup je mít na každou komponentu továrničku. Já supertovárničku používám tak, že pokud nemám explicitně vypsanou továrničku, tak se mi vrátí továrna stejného jména z configu (ze sekce factories).
Je možné taky vracet novou instanci $name, ale často je potřeba nějaká konfigurace nové komponenty a config ji umožňuje, zatímco univerzální zápis return new $name; ji neumožňuje – takže jsem rychle narazil a přepsal to.

V createComponent($name) se dá univerzálně vytvořit komponenta podle parametru $name. Když máš požadavek na komponentu FooBar (třeba protože ji voláš v šabloně), tak se hledá metoda createComponentFooBar() a pokud se nenajde, tak se zavolá createComponent('fooBar'), která implicitně nic nedělá. No a tuhle metodu si můžeš přepsat tak, aby to třeba vytvořilo instanci třídy FooBar a vrátilo ti ji. Nebo zkrátka cokoliv bys měl v továrničce.

Pozor, pokud budeš potřebovat dvě různé komponenty stejné třídy – třeba dvě různá počitadla. Pak potřebuješ každé pojmenovat jinak a tedy mít dvě továrničky: createComponentCounter1() a createComponentCounter2(). Jinak při druhém použití komponenty stejného jména se ti jen podruhé vykreslí ta samá (třeba stránkovač nad tabuklou i pod ní jsou stále stejná komponenta).

Když si následující kód vložíš do BasePresenteru a BaseControl, tak ve všech poděděných presenterech a a komponentách můžeš používat všechny komponenty, které máš zaregistrované v configu jako factories.

<?php
/**
 * Supertovárnička na komponenty
 * Pokud neexistuje volaná komponenta, zkusí se zavolat továrnička z configu
 *
 * @param	string	$name	jméno komponenty
 * @return	\Nette\ComponentModel\IComponent
 */
protected function createComponent($name)
{
	$ucname = ucfirst($name);
	if ( method_exists($this, "createComponent$ucname") )
	{
		return parent::createComponent($name);
	}
	else
	{
		$factory = "create$name";
		return $this->context->$factory();
	}
}
?>

P.S. V BaseControl místo $this->context musíš použít $this->presenter->context

Editoval Šaman (25. 8. 2012 16:32)

To už je na tom, kdo tu továrnu zavedl do kontextu. Jestli je to komponenta jednoúčelově pro jeden presenter, tak myslím, že v konfigu nemá co dělat. A kontrolu práv by si měla dělat přímo metoda která maže/edituje.

Nicméně trocha magie v tom určitě je, o tom není sporu. Ale opakovat spoustu stejných továren v několika presenterech není pěkné a mít v BasePresenteru spousty továren je ještě ošklivější. Máš nějaký nápad, jak z toho ven?

Editoval Šaman (25. 8. 2012 16:59)

Cesta vede tudy

Třída zodpovědná za smazání článku zase podle mě vůbec nemá řešit, jestli aktuálně nastavení session a cookies takovou akci dovoluje (session a cookies === kontrola práv), protože je to míchání věcí. Uživateli například mohu užití metody dovolit jen pro jeho články, zatímco administrátor ji může použít na kterýkoliv. Proč bych ale tuhle logiku měl patlat do metody, jejíž jedinou zodpovědností by mělo být smazání článku?

Pozor, presenter je v Nette prostředník mezi view a modelem. Je zodpovědný za víc než za „prezentování“ (pokud to dobře chápu).

@Šaman Předně narážím na to, že DIC Factories jsou nepoužitelné.

Vykonání jakékoliv akce by mělo přecházet kontrola oprávnění. Takže když vytvářím komponentu, kontroluji jestli ji uživatel může vidět, když zpracovávám signál, kontroluji, jestli má uživatel oprávnění udělat akci, kterou představuje.

Tyhle kontroly můžou být přímo v presenteru, přímo v komponentě, nebo v nějakém prostředníkovi. Každopádně tam být musí!

„Magické“ vytváření komponent tohle trošku stěžuje, ale i tak se to dá napsat tak, aby jsi při vytváření komponenty kontroloval, jestli komponenta může být vytvořena.

Každopádně jsem zastáncem klasického způsobu, kdy továrničky prostě vyjmenuješ v presenterech, kde budou použity (popř, ve společném předkovi), byť je to o pár řádek ukecanější. Až uvidím opravdu pěkné řešení, jak tohle zautomatizovat, tak začnu propagovat to. Zatím jsem ho neviděl :)