Dependency Injection v Nette 2.1

David Grudl napsal(a):

Environment & $context …

Jsem pro mělo by se ale ze samotného frameworku odstranit veškeré volání contextu / Environmentu (formuláře, Control::createTemplate, …).

Částečné sloučení Nette\DI a Nette\Config …

To dává smysl celkem často přemýšlím jestli je to či ono v Config nebo v DI.

(Ne)dynamický DI kontejner …

Nikdy jsem nevyužil…

Expandování parametrů v extensions …

Vyhovuje mě současný stav. Občas potřebuju neexandovanou podobu. (protože teprve přidámvám parametr).

Nepojmenované služby …

Jde nějak zapsat složitější nastavení anonymní služby? (tj. včetně create a setup).

Klíč factory v konfigurátoru …

u služeb mě moc nesrozumilený nepřipadá u továrniček je to hodně wtf…

Validační schéma pro rozšíření …

tady hodně záleží na API jinak to lidi nebudou používat

autowire služeb s více instancemi

Věc která mě ohledně DI aktuálně trápí nejvíce je více než jedna služba implementující stejné rozhraní. HosipLan tady navrhuje nějaké řešení.

Mám totiž v aplikaci 30+ repositories (všechno to jsou instance Nella\Doctrine\Repository). Liší se jenom tím pro kterou entitu jsou určeny. A potřeboval bych tyhle služby nějak elegantně dostat do presenteru. Což aktuálně nejde (bez hackování DIc a PresenterFactory).

Dělat pro každou entitu „prázdnou“ třídu repository mě připadá více než zvrhlé.

Protože jsem nahodil hodně témat, abychom udrželi diskusi, nepřidávejte prosím žádné další.

V zápisu factory: App\Authorizator(...) není App\Authorizator(...) továrna, ale volání operátoru new a kontruktoru. Tedy továrna v meta-smyslu. Obecnější varianta factory by skutečně byla creator, ale jak píšeš, to je divné.

Srozumitelnější je mi proto jeví používat slovesa a celý popis brát jako návod. Proto create, setup, implement. (místo factory, methods, inteface).

A pro klasické továrny by nadále zůstalo slovo „factory“ při vytváření služby?

Jinak minimálně proti „implement“ jsem docela dost zásadním způsobem – přijde mi, že pro každého PHP programátora bude vrozenější psát „implements“ (píšou to dost často v samotném PHP kódu) a i jako sloveso pro tu konkrétní továrnu vždy dává mnohem větší smysl s tím -s.

Nešlo by sjednotit class a create do výsledného create? Teď nevím, jestli nenavrhuju pitomost, ale vím, že se někdy přistihnu při rozmýšlení jestli použít to nebo ono.

implements mi přijde naopak zavádějící (a dlouhé), buď implement nebo ještě něco geniálnějšího.

Editoval vojtech.dobes (21. 11. 2012 13:32)

v případě factory: Foo::create(...) mě dává větší smysl factory v případě factory: Foo(...) nějak nechápu proč se nepoužívá rovnou class: Foo(...).

Implement je gramaticky zcela v pořádku, znamená to implementuj.

Environment & $context

Volitelne injektovani kontejneru asi ano, protoze jinak by mohl byt upgrade existujicich aplikaci extremne bolestivy. Environment bych zrusil – pokud vsak zustane zachovano zily mi to trhat nebude.

Částečné sloučení Nette\DI a Nette\Config

Jsem pro – jak pise Patrik obcas nevim co je kde…

(Ne)dynamický DI kontejner

Nepouzivam.

Expandování parametrů v extensions

Rozhodne zachovat neexpandovane parametry!

Tohle povazuju za jednu z killer feature. Pristup k %appDir%, %tempDir% a moznost definovat si vlastni %tempDir%/whatever a podobne.

Urcite to nic nekomplikuje narozdil od situace kdy by parametry uz byly expandovane. Nezaznamenal jsem ani ze by to nekoho matlo.

Nepojmenované služby

services:
	App\Authorizator: self

Tento zápis je skutecne ani ne tak nesrozumitelný jako spis neintuitivni a tedy spatny z hlediska UX ;)

services:
	- App\Authorizator

Tento zapis se mi libi a pripada mi zaroven nejlepsi mozny, protoze obsahuje 0 znaku navic :)

…nastavovat autowired na false s možnosti globálně vypnout…

Toto bych urcite nemenil. Stavajici system musi zustat zpetne kompatibilni. Takze pokud ano tak s moznosti globalne zapnout toto nove chovani. (Me osobne by vubec navadilo umazat vsechny nazvy)

S tim take lehce souvisi Hosiplanovy genericke sluzby. Poslouchaj, Hosiplan, podobny pristup by mohl byt pouzit u konfigurace tech sluzeb:

services:
	-
		class: App\Repository
		generic: App\Entity

Klíč factory v konfigurátoru

Klic factory v sekci services mi pripada v poradku. Libilo by se mi pouzit create pro soucasnou „meta-factory“:

services:
	-
		create: `App\Service(...)`

Soucasne bych ale urcite zachoval factory pro oznaceni tovarny. To by navic mohlo akceptovat tovarni tridy, ktere by mohly implementovat nejake to rozhrani:

interface IFactory
{
	function create();
}

services:
	-
		factory: App\ServiceFactory

Jako oznaceni tovarny se me osobne se nejvic libi class, proste proto, ze je to jasne nejkratsi slovo – prosim nebrat na lehkou vahu. Kazdy programator vi, ze slova interface natoz implements jsou mnohem horsi na psani.

Pokud jde o semantiku – ta trida se vytvori – takze to je trida – oznacena rozhranim.

factories:
	latte:
		create: Latte\Engine
		class: Latte\IFactory

Validační schéma pro rozšíření

Pokud by to vypadalo takhle nejak – jsem vsema deseti pro.

$rootNode
    ->arrayNode('connection')
        ->children()
            ->scalarNode('driver')
                ->isRequired()
                ->cannotBeEmpty()
            ->end()
            ->scalarNode('host')
                ->defaultValue('localhost')
            ->end()
            ->scalarNode('username')->end()
            ->scalarNode('password')->end()
            ->booleanNode('memory')
                ->defaultFalse()
            ->end()
        ->end()
    ->end()
;

Syntax se jiste necha vymyslet inteligentnejsi…

Editoval pekelnik (21. 11. 2012 19:31)

Dik za odkaz :) Doplnil jsem svuj prispevek o ukazku.

Editoval pekelnik (21. 11. 2012 19:30)

„Factory latte will implement interface Latte\IFactory and will create class Latte\Engine.“

Asi jo no… ale stejne se to blbe pise ;)

Nepojmenované služby pomocí odrážky a klíč create jsou už v dev verzi, můžete vyzkoušet.

To by mohly řešit ty schémata…

$config->scalar('implement')
	->commonTypos('implements', 'impl', ...);

paranoiq napsal(a):

ta trčící odrážka je hrozné WTF. vypadá to jako typo

Taky me to napadlo… jenze co s tim?

HosipLan napsal(a):

nedalo by se ještě tohle?

services:
	Foo\NazevTridy(@httpRequest): #anonymni
		setup:
			- ...

Něco takového používáme v Mediu v našem upraveném symfoním DI kontejneru.

services:
    Foo\NazevTridy:
        arguments: [@httpRequest]

Honza Marek napsal(a):

Něco takového používáme v Mediu v našem upraveném symfoním DI kontejneru.

Ano, a to je právě ta problematická věc. Proč je jednou název třídy před dvojtečkou a jindy za dvojtečkou. Proto experimentuju s odrážkou jakožto náhradou.

David Grudl napsal(a):

Proč je jednou název třídy před dvojtečkou a jindy za dvojtečkou.

Filozoficky se to dá vysvětlit tak, že to není služba bez názvu, ale služba s názvem stejným jako je název třídy. A když není definovaná třída služby, tak se vezme z názvu služby, protože předpokládáme, že tuhle konvenci bude dodržovat 95% služeb.

Proto experimentuju s odrážkou jakožto náhradou.

To je to samé. Proč je tam někdy odrážka a někdy ne?

Moc se mi nelíbí používání sloves (create, implements, …) v konfiguračním souboru. Přijde mi, že konfigurace má být deklarativním stylem a popisovat tedy, co je v DIC a ne jak se to vytvoří. Když se použijí slovesa, začne se říkat jak, tak vzniká nový programovací jazyk. Nevím, zda to chceme?

Podle mě je naopak implements dostatečně deklarativní (služba … implementuje rozhraní …), narozdíl od imperativního implement (službo …, implementuj rozhraní …). Kvůli typos by nette stejně muselo podporovat obě možnosti, takže si může vybrat každý.

Ještě jednou bych se vrátil k expandování parametrů v konfiguraci.

CompilerExtensions pracují s neexpandovanými (ale místy i expandovanými) proměnnými, tj. kdekoliv v definicích lze používat řetězce jako třeba %tempDir%/abc a expanze se provádí až při generování DI kontejneru.

Tohle bych rád změnil: expanze by se provedla hned po načtení souboru a dále už by se pracovalo s „ostrými“ daty.

Důvod je především ten, že když do definice předáváme nějakou obecnou proměnnou (například heslo), vůbec nás nenapadne, že bychom ho měli nejprve escapovat funkcí Nette\DI\Helpers::escape, protože pokud heslo bude například a%bc%d, dojde u něj k nechtěné expanzi.

Pravděpodobnost výskytu takového řetězce je malá, takže se na tento problém nenaráží, nicméně je to principiální problém.

Taktéž je potřeba myslet na to, která proměnná je expandovaná a která ne, když s ní chceme nějak pracovat (např. ověření existence adresáře apod.).

Rád bych proto, aby vše bylo od začátku expandované. Pokud bych escapovat chtěl, explicitně bych to uvedl. Tj. třeba na řádku https://github.com/…xtension.php#L114 by se

		$container->addDefinition($this->prefix('cacheJournal'))
			->setClass('Nette\Caching\Storages\FileJournal', array('%tempDir%'));

nahradilo za

		$container->addDefinition($this->prefix('cacheJournal'))
			->setClass('Nette\Caching\Storages\FileJournal', array($container->expand('%tempDir%')));

Pochopitelně v tomto případě musí už při volání metody expand() proměnná %tempDir% existovat. Soudím, že tohle by neměl být v praxi problém.

Chci se ujistit, že jsem to správně pochopil. Dejme tomu, že chci nastavit cestu do %tempDir%/abc, mám pak použít něco jako

$container->addDefinition($this->prefix('cacheJournal'))
    ->setClass('Nette\Caching\Storages\FileJournal', array($container->expand('%tempDir%') . "/abc"));

Ještě mě napadá – když už dělám v metodě loadConfiguration

	$config = $this->getConfig($this->defaults);

tak tam nejsou parametry jako productionMode apod, ale ostatní explicitně uvedené v configu tam jsou. Co takhle to sjednotit?

$container->addDefinition($this->prefix('cacheJournal'))
    ->setClass('Nette\Caching\Storages\FileJournal', array($config['tempDir'] . "/abc"));

Jenže to ani teď neplatí. Dostaneš tam totiž i globální parametry, které si explicitně uvedeš v sekci parameters, které ti dokonce přepíšou konfliktní parametry v dané extension.

Editoval castamir (2. 4. 2013 15:24)

Boží, muj pull request byl schválen. To otevírá možnost vytvořit schema pro validaci konfiguráků. Už žádné překlepy v config.neon!