Jak správně vytvářet Componenty přes context?

Ono s tím předáním presenteru je to takto: jakmile továrnička (protected function createComponentFoo...) vrátí instanci komponenty, tak se na jejím parent prvku (instanci IContainer, což jsou kupříkladu presentery) zavolá ->addComponent($component, $name) – kde $component je právě instance té mojí komponenty. Tam se provede předání presenteru komponentě. Děje se tak tedy automaticky po vykonání továrničky. Viz zdroják

Stručně řečeno: v současně době komponentám není potřeba předávat v konstruktoru presenter ani žádný jiný parent prvek (prostě $this).

protected function createComponentFoo()
{
	return new FooControl;
}

Tohle je naprosto OK továrnička a FooControl bude mít k dispozici presenter (ne ale pochopitelně v konstruktoru, ten se volá (zcela logicky a očividně :) ) v továrničce – připojení k presenteru se odehraje až po jejím vykonání.

Je to dostatečně srozumitelné?

Update: ještě stojí za doplnění, že připojení k presenteru lze přímo detekovat pomocí páru metod monitor a attached. Tu první ani není třeba volat, jistojistý okamžik připojení k presenteru pak lze odchytit v attached:

protected function attached($parent)
{
	parent::attached($parent);
	if ($parent instanceof Nette\Application\UI\Presenter) {
		// do staff
		$this->presenter === $parent; // platí
	}
}

Editoval vojtech.dobes (16. 3. 2012 5:21)

joseff napsal(a):

Což mi přijde mnohem čistější řešení, ale…

Moc by mě zajímala Tvá odpověď na mé následující otázky, ale než je položím… Neber je prosím jako nějaký útok nebo snahu o flame! Ber to třeba jen jako můj soukromý průzkum. :)

V čem ti tohle přijde mnohem čistější? Jaké to má pro Tebe praktické výhody oproti volání new? Je něco nečistého na konstrukci new?

Nesnažím se vůbec říct, že by mi Tvé řešení přišlo „špatné“ nebo tak něco. Určitě mají oba přístupy své výhody a nevýhody (výhodou je určitě možnost autowiringu) a opravdu by mě jen zajímalo, jaké má to či ono řešení výhody/nevýhody přímo pro Tebe a z čeho plyne to označení čisté/nečisté. Klidně ale můj post ignoruj. :) Díky!

Super, díky! Máš to dobře promyšlené a dává to smysl :). To opakované vytváření by se asi dalo vyřešit i vyčleněním té továrničky na úroveň nějakého společného předka, ale to se možná shodneme, že je méně elegantní řešení (minimálně pro mě by pak bylo hůře čitelné, kde že se ta komponenta vlastně bere).

Něco ke čtení. A teď konkrétně, mělo by to jít nějak takto.

factories:
	class: ComponentFoo
	arguments: [%presenter%, %wwwDir%, @translator, %basePath%]
	paremeters: [presenter]

Ale opět se musím vrátit na začátek tématu. Nemyslím si, že presenter během vytváření komponenty potřebuješ. Komponenta se totiž buď vykresluje, nebo zpracovává signál.

Když zpracovává signál, signál je volán presenterem. Je volán až v momentě, když už je komponenta dávno připojena a má přístupný $this->presenter.

Když komponentu vykresluješ, děláš tak v šabloně a předtím než komponentu vykreslíš, tak se musí vytvořit v továrničce, tedy opět během zpracování metody render máš už $this->presenter přístupný.

Pokud potřebuješ presenter dříve, což je oprávněný požadavek, přenes tuto logiku do metody attached, jak radí Vojta.

Tedy místo

public function __construct($parent, $name)
{
	parent::__construct($parent, $name);
	$this->presenter->link(); // což je stejně hovadina, proč bys tady potřeboval odkaz?
}

budeš psát

protected function attached($obj)
{
	parent::attached($obj);

	if (!$obj instanceof Nette\Application\UI\Presenter) {
		return;
	}

	// sem se zpracování dostane ihned po připojení k presenteru
	// zde máš už tedy presenter přístupný
	$this->presenter->link();
}

Je to daleko čistější řešení a více ComponentModel-friendly. Něco ke čtení.

Jen pro jistotu dodávám, že Dependency Injection je opakem contextu, tudíž používám-li context, porušuji a obcházím DI.

David Grudl napsal(a):

Jen pro jistotu dodávám, že Dependency Injection je opakem contextu, tudíž používám-li context, porušuji a obcházím DI.

Ale pokud používám new FooControl v presenteru tak DI porušuji také nebo ne? Takže jak na to správně přes DI?

David Grudl napsal(a):

Jen pro jistotu dodávám, že Dependency Injection je opakem contextu, tudíž používám-li context, porušuji a obcházím DI.

To je takhle špatně? Nebo jsem nerozuměl odpovědi?

public function createComponentAddressBookFormAddFull() {
	$form = new MyForm($this->context->database);
	return $form;
}

Jasný, už jsem se lekl. Jedině možná použít metodu $this->getService(„database“); namísto magie, abych „nepoužil“ context. By mohlo být ještě hezčí…

ViPErCZ napsal(a):

Nejlepší by samozřejmě bylo něco jako

/** @autowire */
public function setDatatbase(Connection $db)
{
    $this->database = $db;
}

Ascaria napsal(a):

Ale jen v případě komponenty, v presenteru můžu používat kontext a zároveň neporušovat DI, nebo ne? Nenapadá mě způsob, jak bez použití contextu v presenteru předat komponentě nějaký model co se vytváří v neonu.

Proti DI je právě $context, tedy pattern zvaný Service Locator. Stačí si položit otázku, zdali presenteru předávám všechny závislosti. Odkud si jako bere ten model? Předávám ho presenteru v konstruktoru nebo setteru? Ne – DI dostává na frak.

Ascaria napsal(a):

Podle mě by presenter také neměl sahat pro komponenty do kontextu, měl by je vytvářet. Do kontextu patří modely a ne komponenty.

Kontext není knihovnička pro modelovou část aplikace, je to DI kontejner. V ideálním světě by v presenteru být neměl, protože všechno se předá čistě konstruktorem nebo setterem, nikoliv odkudsi z klobouku :).