[2011–05–05] Finalizace Dependency Injection

Honza Marek napsal(a):

Budou v containeru defaultně jako parametry config a environment variables?

Pochopitelně NE – kde by se to tam vzalo? Co je to Environment a jak to svouvisí s DI?

Jde vyměnit výchozí ServiceBuilder pro všechny servisy?

Myslíš pro své kontejnery? Vlastní ServiceBuilder může být parametrem addService.

Super, konečně to začíná vypadat k světu :) Mám taky několik poznámek:

• ServiceBuilder bych určitě do frameworku dal, bude důležitý pro konfiguraci kontejneru v configu.
• Kontejner by mělo interně využívat samotné Nette, a to tak, že si pomocí něj nechá sestavovat většinu objektů. V důsledku by se pak operátor new měl objevit jen na pár speciálních místech. Umožní to snadnou vyměnitelnost všeho, co framework využívá. To se dnes děje pomocí pole $defaultServices, já bych tu myšlenku rozšířil a aplikoval na vše. V praxi si to představuji tak, že přímo v distribuci bude default.neon s definicemi servis, do něhož se pak bude mergovat aplikační config.neon, čímž si budu moct na jednom místě a jednotně cokoli přepsat.
• Líbí se mi sestavování presenterů pomocí DI kontejneru. Presenter si v konstruktoru nadefinuje, jaké servisy chce a PresenterFactory mu je při vytvoření poskytne. Je pak na první pohled jasné, co daný presenter všechno potřebuje a zajišťujeme tak, že si nesáhne na něco, o co si neřekl. V praxi by pak bylo potřeba do ServiceBuilderu doplnit podporu pro injektování servis do všech potomků nějakého předka, pokud si např. můj BasePresenter sám nějakou závislost nadefinuje. A pokud by to někdo nechtěl takto dělat, jednoduše si nadefinuje, že BasePresenter pouze přijímá DI kontejner a má po starostech. Tohle bude chtít autowiring, abych se neupsal.
• Parametry – hodilo by se tam mít appDir, wwwDir, libsDir, basePath, opět kvůli tomu, abych je mohl injektovat do servis a nemusel používat ty ošklivé konstanty. A hlasuji proto, aby tam byly už z výroby (tedy z nějaké továrny, která samotný kontejner sestaví), protože to povede programátory k tomu, aby nepoužívaly ty konstanty.

David Grudl napsal(a):

Pochopitelně NE – kde by se to tam vzalo? Co je to Environment a jak to svouvisí s DI?

Samozřejmě by se tyhle parametry nevyráběly přímo v třídě Container, ale mohly by se plnit v nějaké továrničce na výchozí globální container. S DI to souvisí tak, že je lepší vytvářet službu už nastavenou podle konfigurace, než že ve službě si budu tahat nějaké $context->config->blabla. Například taková továrnička na vyrobení nějakého databázovátka by jistě měla mít po ruce parametry připojení, přijde mi logické to mít už v parametrech Containeru.

HosipLan

Kompilery nad closurama udělat nepůjdou. Jedině nad nějakýma vlastníma IServiceBuilderama.

Na úvod se omlouvám za hloupou otázku. Ale dost často se tu píše o Dependency Injection, ale co to je?
Mohl by mi někdo nějak jednoduše vysvětlit, co to znamená Dependency Injection a jakou to má východu?

Otázka je dobrá.

http://fabien.potencier.org/…cy-injection
http://www.slideshare.net/…-with-php-53

David Grudl napsal(a):

Zdůrazňuji, že takovýto ServiceBuilder v Nette přímo není, protože mi to připadá jako škrabání se přes hlavu. Nevidím moc smysl ve vytváření nového metajazyka, když to jde jednoduše pomocí callbacků. Ale proti gustu…

Existence něčeho takového má smysl pouze v případě definování složitějších služeb přímo v configu.

David Grudl napsal(a):

Honza Marek napsal(a):

Budou v containeru defaultně jako parametry config a environment variables?

Pochopitelně NE – kde by se to tam vzalo? Co je to Environment a jak to svouvisí s DI?

Tohle je hodně klíčová vlastnost! Bez které mě DI moc nedává smysl. Jak už psal honza třeba kvuli údajům o připojení k DB. Nebo k nadefinování SMTP připojení.

Celé tyto dva postoje mě tak trochu připadají jako by mělo být v Nette možné pracovat s DI pouze v PHP. A možnost definice či jiné práce s kontejnerem v configu úplně odstřihnout. Což se mě nelíbí ani trochu.

Co se týká environment variables a configu a teď vlastně ještě container params. Tak bych byl pro absolutního sjednocení pouze do container params.

Ondřej Brejla napsal(a):

Jen jednu kosmetickou, co mě uhodila do očí. Nebylo by lepší, aby byla konvence pojmenovávání service továrniček stejná, jako u továrniček na komponenty? Rozumějte: createWhateverService() vs. createComponentWhatever()

Taky mě to zarazilo a napadlo (už včera ale to ještě neexistovalo tohle vlákno).

Tharos napsal(a):

Mám dotaz, jestli je v současných zdrojácích Nette používání obou termínů context i container záměrem (podle místa použití), anebo zda se to ještě bude sjednocovat. Chtěl bych se vyhnout tomu, aby se mi při refaktoringu za účelem udržení jednoty s Nette konvencemi ony konvence změnily pod rukami. :)

Je to fakt hodně čerstvé. Záměrem to jistě není. Mělo by to být všude jako container.

Patrik Votoček napsal(a):

Co se týká environment variables a configu a teď vlastně ještě container params. Tak bych byl pro absolutního sjednocení pouze do container params.

Přesně tak.

Honza Marek napsal(a):

Budou v containeru defaultně jako parametry config a environment variables?

Jde vyměnit výchozí ServiceBuilder pro všechny servisy?

Resit se to da asi takto:

$cont = new Nette\DI\Container;

$cont->addService('config', function() {
        return Nette\Environment::getConfig();
});

$cont->addService('db', function($cont) {
    $conn = new DibiConnection($cont->config->database);
    return $conn;
});

Jinak prijde mi to prijemne jednoduche…

bene napsal(a):

Resit se to da asi takto:

…

Jinak prijde mi to prijemne jednoduche…

To víme že to tak jde řešit ale naším cílem je 100% se vyhnout volání Environment. Tohle je jenom taková klička a vůbec to není pěkné!

Nehledě na to že existují v podstatě tři různá úložiště „konfiguračních“ proměnných.

arron napsal(a):

Ja jsem ten kod zatim nezkoumal moc podrobne, ale ono uz nejde mit sluzby v configu??

Jde…

Editoval Patrik Votoček (5. 5. 2011 20:39)

Nechci aby to vyznělo blbě. Ale o nepodpoře DI na straně frameworku se tu nikdo nepře. Jen jsou tu argumenty že stará implementace a ta nová je sice lepší ale né o moc.

Tvůj komentář se dá chápat dvěma způsoby a to tak že je nová implementace obrovský krok v před i když stará byla takřka stejná. A je cool a nic se na ní měnit nebude. Nebo tak že je tohle celé jenom začátek něčeho co teprve příjde (dnes/zítra/…). Sám nevím kterou z těch možností zvolit ale v koutku duše doufám ve druhou variantu. (a nebo sem to vůbec nepochopil a jdu se zahrabat)

Editoval Patrik Votoček (6. 5. 2011 1:43)

Tharos napsal(a):

Mám dotaz, jestli je v současných zdrojácích Nette používání obou termínů context i container záměrem (podle místa použití), anebo zda se to ještě bude sjednocovat.

Současné použití je záměrné, zdá se mi to tak rozumné. Název proměnné vystihuje smysl objektu Container.

David Grudl napsal(a):

Globálně. Ech. Globálně nastavit IServiceBuilder je popliváním všechno, co nějak souvisí s DI.

Tak takhle to Honza určitě nemyslel. Podle mě myslel spíš něco takového:

class Container extends \Nette\FreezableObject implements IContainer
{
	private $serviceBuilderClass;

	public function setDefaultServiceBuilderClass($class)
	{
		$this->serviceBuilderClass = $class;
	}
}

Nevím jak to slovy popsat rychleji… Proto raději kód…

Jasně – otázka zní: proč definovat složitější služby v configu? Nenapadá mě jediná výhoda. Nejde to pořádně krokovat, debugovat, vyžaduje to naučení dalšího jazyka, je to pomalejší, je to méně ohebné, je to prostě jen momentální móda.

Tou výhodou je rychlé přidáni „unikátního“ prostředí (environmentu). Ale oproti ostatním nevýhodám je to slabý argument. Beru! (Hlavně ten dovětek :-) )

Stačí si uvědomit, že Environment = globální container a pak se jeví variables vs. config vs. container params jen jako implementační detail. (Ale sjednocení do params je v plánu)

A právě protože je globální tak zrušit! :-)

Btw mohl by mě někdo vysvětlit výhody klonování kontaineru (asi mě pořád unikají)?

Nikoliv, snažím se poukázat na to, jak plné jsou tyto diskuse dojmologie a jak nejasný, rozmlžený a nejednotný je cíl. Je to v podstatě totéž, jako diskuse o jmenných prostorech, jen se to zdánlivě jeví v souhlasném hávu.

Díky za objasnění…

Editoval Patrik Votoček (6. 5. 2011 2:21)

Ano to ano… Ale né pokud takto chci všechny „class“ služby.

On to nebude nakonec takový problém, když si člověk vyrobí na Container nějaké plnítko, které to new MyServiceBuilder udělá za něj.

Jinak definice jinak než pomocí callbacků dává smysl, pokud je potom možné ty definice projít a upravit. Přidat volání setterů, udělat autowiring a tak. To v symfony jde pomocí kompilátorů containeru. S rychlostí taky nemají problém, protože ContainerBuilder umožňující tuhle pokročilou definici se nakonec vydumpuje do třídy extendující Container, kde se přímo v kódu nachází továrničky na služby podobně jako v Nettím containeru.

Honza Marek napsal(a):

On to nebude nakonec takový problém, když si člověk vyrobí na Container nějaké plnítko, které to new MyServiceBuilder udělá za něj.

Přesně tak, co „chybí“ je ContainerBuilder, samotný Container netřeba ohýbat. Takový minibuilder je v podstatě součástí loadConfig(), možná by nebylo špatné ho vyčlenit to samostatné třídy.

Super

Nápad na vylepšení opět rychleji pochopitelné z kódu (kromě již zmiňovaného sjednocení params):

interface IContainerBuilder
{
	public function addConfigurator(IConfigurator $configurator);

	/**
	 * @return IContainer
	 */
	public function createContainer();
}

interface IConfigurator
{
	public fucntion process(IContainer $container);
}

class ContainerBuilder implements IContainerBuilder
{
	private $configurators = array();

	public function addConfigurator(IConfigurator $configurator)
	{
		$this->configurators[] = $configurator;
	}

	public function createContainer()
	{
		$container = new Container;
		foreach ($this->configurators as $configurator) {
			$configurator->process($container);
		}
		return $container;
	}
}

class DefaultServicesConfigurator implements IConfigurator
{
	public $services = array(
		'Nette\\Web\\IHttpRequest' => array(__CLASS__, 'createHttpRequest'),
		'Nette\\Web\\IHttpResponse' => 'Nette\Http\Response',
		// ...
	);

	public function process(IContainer $container)
	{
		foreach ($this->services as $name => $service) {
			$container->addService($name, $service);
		}
	}

	public static function createHttpRequest(IContainer $container)
	{
		// ...
	}

	// ...
}

class ConfigConfigurator implements IConfigurator
{
	public function process(IContainer $container)
	{
		// vzasadě to samé co dělá stávající Nette\DI\Configurator::loadConfig()
	}
}

Proč?

je jednoduché pak dělat něco jako „bundless“ v Symfony (třeba Doctrine viz: https://forum.nette.org/…te-framework)

Stávající Nette\DI\Configurator je hodně „neohebný“ – dělá moc různých věcí naráz.

Proč neposílám pull? Po předchozích zkušenostech se o implementaci ani(/zatím) nepokouším.

Editoval Patrik Votoček (9. 5. 2011 2:01)

Patrik Votoček napsal(a):

Proč neposílám pull? Po předchozích zkušenostech se o implementaci ani(/zatím) nepokouším.

Zatím to vážně nemá smysl, mám zatím jasnou představu, kam směřuji.

Tohle jsem nepochopil? Já myslel, že to bude sjednoceno s params? Tohle vypadá jako registrace service

zdravím,
dříve to šlo (do verzí z minulého týdne), ale v aktuální vývojové verzi je možné zavolat loadConfig v bootstrapu jen jednou. Při druhém zavolání to zahlásí, že config již byl načten.
Je možné nějak jinak načíst dva oddělené configy?

Po pár hodinách pokusů a omylů tomu konečně začínám přicházet na kloub! A konečně chápu na co je víc kontejnerů.

Pár poznatků z „používání“:

• $context vs $container (nikdy si nevzpomenu jak se to zrovna tady na tom místě jmenuje)
• „$app->context“ je obrovsný BC break! (presenter má Environment::getContext() a né $app->context!!!)
• u vlastního kontejneru nepoužívejte createServiceFoo jako výchozí služby (nepůjde to https://api.nette.org/…ner.php.html#56)
• u defaultních služeb nejde registrovat $typeHint
• hodně chybí tagy např.: panels (pro panely do debugbaru), run (pro autorun), atd…
• přidat prvek do pole které je jako param je opruz

Editoval Patrik Votoček (12. 5. 2011 0:04)

Kašlu na to, dám $params zase jako public a všechny metody pro práci s parametry vyhodím pryč.

Patrik Votoček napsal(a):

Po pár hodinách pokusů a omylů tomu konečně začínám přicházet na kloub!

Každopádně jsem fakt rád, už jsem si myslel, že tady existuje nějaká mentální bariéra v chápání DI :-)

Patrik Votoček napsal(a):

Proč vlastně params není Nette\ArrayHash ?

Ze by se k params pristupovalo jako k property? $cont->params->foo

Ako sa tá nová DI sranda používa celkovo v apikácii? Registrácia nových služieb v configu s rôznymi parametrami a prístup k ním. Chcelo by to update sandboxu (napr. službu pre pripojenie do DB).

A je možné používať Auto-wiring aj v config.neon? Mne sa pačilo ako to mal Vrtak v Nelle a v configu

Update:

Patrik Votoček napsal(a):

Mě dělalo největší problém pochopit smysl / význam více kontextů pak už to šlo celkem snadno.

Celkom by som bol rád keby si vysvetlil ten význam viacerých kontainerov. Ja to nepoberám :(

Editoval Cifro (15. 5. 2011 17:26)