Přidání presenteru do šablony v komponentě

pawouk

Ahoj, narazil jsem na takový problém když jsem vytvářel komponentu. Vypadala asi takto:

class TestComponent extends \Nette\Aplication\UI\Control {
	public function__construct($translator){
		parent::__construct();
		$this->template->setTranslator($translator);
	}
	public function render(){
		$this->template->setFile('file.latte');
		$template->render();
	}

}

V šabloně jsem měl makro {plink …} což neprošlo. Hlásilo mi to ře komponenta nemá připojený presenter, ten tam ale už dávno je, jen není v template. Je tedy potřeba napsat do metody render toto:

$this->template->presenter = $this->template->_presenter = $this->presenter;

A vše funguje. Problém je že tím že jsem zavolal $this->template už v konstruktoru (což je pochopitelně chyba, ale měla by se tolerovat) tak se metoda createComponent zavoala ještě před tím než byl presenter přítomen a tím pádem v tempalte nebyla. Podle mého názoru by tedy v metode setParent mělo přibýt něco takového:

if($parent instanceof \Nette\Aplication\UI\Presenter && $this->presenter != NULL)
	$this->template->presenter = $this->teplate_presenter = $parent;

Co si o tom myslíte?

Aearsis

Nebylo by přeci jen lepší podědit createTemplate() ? Control má setParent od Component, které template mít nemusí, navíc by to byl neočekávaný side-effect.

pawouk

No nevím, samozřejmě možností jak to vytvořit „po svém“ je spousty, měl jsem na mysli nějaké řešení na straně Nette. Přijde mi, že pro začátečníka to může být poměrně neprůhledný problém, mě osobně to také chvíli trvalo než jsem si to uvědomil… Pokud má setParent od Component, pak bych přidal do Nette do Control setParent a tam bych to přidal, pak by to bylo čisté což? Možná by to šlo vyřešit jinak (na straně Nette), tohle je jen nápad…

jtousek

Control by ale měl v konstruktoru dostávat trochu jiné parametry, ne? Bylo by lepší přidat metodu setTranslator, která by jej přidala šabloně a volal bys ji v továrničce hned po vytvoření komponenty.

Aurielle

@jtousek: Taková deklarace konstruktoru je zcela správná, dost lidmi i doporučovaná a preferovaná. Zeptej se HosipLana ;)

pawouk

No tak když ti tu třídu vytváří config (SystemContainer), tak do konstruktoru těžko dostaneš presenter. Ten se poté připoji sám, když se komponenta zavolá. Jinak setTranslator by bylo ideální, to je fakt, ale to platí jen v případě translatoru, asi to byl nevhodný příklad, úplně stějně by mohlo jít o nějakou hodnotu. Kterou prostě potřebuješ předat šabloně…

Aearsis

Stále si myslím že (i pro hodnotu) je lepší si ji uložit někam do property, a šabloně ji předávat až při renderování. Navíc tím získáš možnost ještě ho prohodit za běhu, případně změnit hodnotu.

awsickness

zkus do predavat translator nekde driv jako v basepresenteru

$this->template->setTranslator($translator);
a pak v te komponente dej v render neco jako
$template = parent::getTemplate();
...

snad by to melo chodit.

Editoval awsickness (14. 4. 2012 19:12)

Ani

pawouk napsal(a):

No tak když ti tu třídu vytváří config (SystemContainer), tak do konstruktoru těžko dostaneš presenter. Ten se poté připoji sám, když se komponenta zavolá. Jinak setTranslator by bylo ideální, to je fakt, ale to platí jen v případě translatoru, asi to byl nevhodný příklad, úplně stějně by mohlo jít o nějakou hodnotu. Kterou prostě potřebuješ předat šabloně…

Můžeš si to v configu vytvořit jako factory, do té pak presenter předat můžeš.

factories:
	testComponent:
		class: TestComponent(%parent%, %name%)
		parameters: [parent: null, name: null]

jtousek

gmvasek napsal(a):

@jtousek: Taková deklarace konstruktoru je zcela správná, dost lidmi i doporučovaná a preferovaná. Zeptej se HosipLana ;)

Já se jen divím, že PHP nezačne řvát kvůli nekompatibilní specifikaci parametrů metody __construct.

Filip Procházka

U construct nemusí být parametry stejné.

jtousek

To vím, ale nechápu proč.

bene

HosipLan napsal(a):

U construct nemusí být parametry stejné.

Nechci kecat, ale mám pocit, že jsem četl, že tomu tak v budoucnu nebude. Jinak řečeno to bude vyhazovat E_STRICT jako u klasickych metod.

Filip Procházka

@**jtousek**: Protože PHP nemá přetěžování metod.

@**bene**: Tím bych se vůbec netrápil ;)

Editoval HosipLan (16. 4. 2012 16:54)

Patrik Votoček

bene napsal(a):

Nechci kecat, ale mám pocit, že jsem četl, že tomu tak v budoucnu nebude. Jinak řečeno to bude vyhazovat E_STRICT jako u klasickych metod.

V PHP 5.4 ale týká se to jenom abstraktních tříd :-)