Co dál s Quickstartem – inject*() vs setContext()

Napsat inject* a kdo má starší, ať použije $this->context.

Ale to už David někde říkal ne? Že v podstatě je to jedno, že tam stejně tak jako tak musí být poznačeno jak to udělat i tím druhým způsobem, takže v podstatě jde jen o pořadí odstavců.

ale stejně jsem pro injectFoo ;)

@pilec: Ano, přesně to David psal. Problém je v tom, že my se zkrátka neshodneme. A bylo by dost nefér, kdybych třeba teď šel a celý QS předělal na inject*(), když s tím nesouhlasí několik guruů, které respektuji.

Chce to zásah autority ;)

Editoval HosipLan (5. 9. 2012 18:25)

napise tam variantu pre 2.0.x a potom aj pre 2.0.5+

toto je dost velka zmena takze by som to tam spomenul…

Osobně spíš vidím prodlém jinde. Proč se tak velká změna prováděla ted a nenechala se na 2.1? Myslim si, že tyhle setinkové verze mají být výhradně na úpravu bugů. ;)

Z toho důvodu:
@Patrik Votoček: +1

Nebo případně jak píše @achtan. Verzovat quickstart.

@David Grudl : Tak to sorry, já myslel, že to je nějaká nová fičura ;)

Editoval martinit (5. 9. 2012 19:12)

@martinit k žádné změně nedošlo. Podpora inject() je důležitá kvůli dopředné kompatibilitě. Inject je bugfix na problémy se setContext.

Já si myslim, že to setContext nikdo (ze začátečníků) nikdy nemoh reálně používat. Proto jsem pro inject. Chtělo by to výzkum :)

Kdyby jen ze začátečníků :-) jsem inject* začal používat asi před měsícem, do té doby $this->context. Jinak stačí dát do vyhledávání setContext vs. $this->context, je to 1:9. Myslím, že setContext je hodně neznámé a ani bych s tím lidem nemotal hlavu a nechal je při $this->context u starších verzí, s tím, že pokud nechtějí porušovat DI, tak by měly použít setContext() a od 2.0.5 toto řešit výhradně přes inject* metody.

Editoval 22 (5. 9. 2012 20:40)

Super tedy, takže to zítra přepíšu na inject*() a důsledně přidám komentářů :)

@HosipLan: Rovnou můžeš opravit callbacky na starší zápis. Tj. s funkcí callback bez spoléhání na novinku v Nette\Object.

Dopředná kompatibilita řeší skutečnost, že už dnes víme, co bude v 2.1 deprecated (a házet E_USER_DEPRECATED) a dáváme možnost lidem psát dnes aplikace tak, aby fungovaly později. Má to jednoznačně přínos pro uživatele, snižuje to potřebu v budoucnu něco upravovat, což jsou klíčové hlediska, kterým všechny argumenty, co jsem tu četl, nesahají po kotníky.

Samozřejmě se Nette 2.0.5 mohlo jmenovat 2.1.0 a tato diskuse by pak skutečně nevnikla, vznikla by totiž diskuse o něčem mnohem a mnohem komplikovanějším.

Mluvím za sebe jako mírně pokročilý začátečník :) Začal jsem na verzi QS, kde byly modely tvořený děděním NDB\Selection, což jsem záhy zjistil, že byla cesta do pekel. Naštěstí se to v QS změnilo a já pochopil, že to je rozhodně lepší cesta.

Teď používám ->context, ale jestliže mi v QS někdo ukáže použití inject a vysvětlí proč je to takto lepší, tak nemám sebemenší problém to začít používat.

Nový začátečníci si stáhnou stejně novou verzi, a takový jako já si myslím, že raději se přizpůsobí nejnovější stable verzi, nebo si hold pojedou to svoje, protože to již mají trošku zažité.

achtan napsal(a):

nie, nezostal! Ked FooPresenter dedi od BasePresentera kt. ma inject() a potrebujes injectnut dalsie veci tak si vo FooPresenter spravis nieco ako injectFoo()

Řeč byla o inject(...), nikoliv o inject*(...), viz samotným Davidem navržené inject(Service $service).

Patrik Votoček napsal(a):

Ivorius napsal(a):

Teď používám ->context, ale jestliže mi v QS někdo ukáže použití inject a vysvětlí proč je to takto lepší, tak nemám sebemenší problém to začít používat.

https://pla.nette.org/…ect-autowire :-)

Pořád nechápu, jak mám řešit, že mám víc služeb stejné třídy. Pokud u služby zakážu inject, ztratím asi jediný čistý způsob, jak jí dostat do presenteru, nebo ne?

Jsem přesvědčen, že vůbec nemá smysl přihlížet k dogmatům („dokumentace musí být kompatibilní s 2.0.0“ – proč?), ale stačí kriticky zvážit, co je nejpřínosnější pro uživatele.

Abych celou věc trošku zrelativizoval: Quick-start je důležitá část dokumentace a troufám si tvrdit, že udělat jej 2.0.5-only způsobí řádově méně škod, než když se v něm dědí Selection ;-)

Tedy:

• Prioritním cílem je uživateli srozumitelně vysvětlit co nejčistější a preferovanou cestu.
• Druhotným cílem je nezmást uživatele starších verzí.

Nelze věc bagatelizovat a předpokládat, že quick start je jen pro ty, co si právě stáhli poslední revizi. To je naivní, tudíž se nesmí nic tajit, všechno vysvětlit a na nekompatibilitu upozornit.

A dá se to udělat chytře! Co třeba setContext() vůbec nezmiňovat a začít intuitivně předávat závislosti konstruktorem. Přičemž musíme předat také závislosti rodičovské třídy, ať už to bude UI\Presenter nebo BasePresenter. To je logické. A tady se dá říct, že od verze 2.0.5 existuje způsob, jak tento problém obejít, a to pomocí metod inject*. Uživatele starších verzí vyzveme k upgrade.

Rozhodně setContext (s tím, že se v něm udělá assignment do proměnných té třídy). A inject* zmínit jako alternativu pro novější verze.

začít intuitivně předávat závislosti konstruktorem

A nebo todle.

Prečo sa v tomto konkrétnom prípade (QS) nepoužije predávanie služby priamo v __construct()? Akú býhodu má nastavovať to cez metódu inject*()? Pochopil by som, keby sa to nenastavovalo vždy.

jsvelta napsal(a):

Pochopil by som, keby sa to nenastavovalo vždy.

Nenastavuje sa to vzdy… mozes mat prezenter bez akychkolvek zavislosti…

to ano, ale inject* metody niesu povinne, o tom som hovoril

Nedalo mi to a pozrel som sa poriadne. Podľa mňa sa na konštruktor šahá a tá závyslosť je povinná. Teda malo by to byť v ňom.

Container.php obsahuje toto:

<?php
	public function createInstance($class, array $args = array())
	{
		$rc = ClassReflection::from($class);
		if (!$rc->isInstantiable()) {
			throw new ServiceCreationException("Class $class is not instantiable.");

		} elseif ($constructor = $rc->getConstructor()) {
			return $rc->newInstanceArgs(DIHelpers::autowireArguments($constructor, $args, $this));

		} elseif ($args) {
			throw new ServiceCreationException("Unable to pass arguments, class $class has no constructor.");
		}
		return new $class;
	}
?>

Samozrejme že je jedno, či sa to predá konštruktorom, alebo settrom. Obe varianty budú funkčné. Ide mi o správne používanie DI. Ak ide o závislosť, ktorá je pre objekt nevyhnutná a bez nej nemože žiť, tak by ju mal dostať cez konštruktor. Ak ide o závislosť, ktorá povinná nie je a bez nej može žiť, tak by sa mala nastavovať cez setter.
Ak vytvorím objekt ručne a po vytvorení do neho „nevstrieknem“ závislosť, tak ten objekt bude v nekonzistentnom stave a volanie nejakej metódy skončí chybou.
QS by mal byť i o tom, aby učil nováčikov prgramovať správne. Alebo ich aspoň upozorniť, že je to školské riešenie, ktoré by sa reálne nemalo používať.

Diskusia je o tom, či inject*() alebo setContext(). Podľa mňa je ale v tomto prípade správna varianta __construct(). Všetky tri varianty, z hľadiska funkčnosti, sú ekvivalentné.

Implementácia triedy je vecou autora danej triedy. Ak nevolá rodičovský konštruktor, je to chyba. Trieda mi poskytuje určité pevne dané rozhranie. Používaním tohoto rozhrania by som nikdy nemal dostať inštanciu triedy do nekonzistentného stavu.

Pri použití inject* metód má framework lepšiu kontrolu nad injectovaním závislostí.

Prečo? Konštruktor odvodenej triedy može mať menej parametrov ako konštruktor rodičovskej. Je to normálny jav.

jsvelta napsal(a):

Samozrejme že je jedno, či sa to predá konštruktorom, alebo settrom. Obe varianty budú funkčné. Ide mi o správne používanie DI.

Obe varianty sú správne použitie DI. Ktorú si zvolí programátor je už len na jeho preferenciách.

Implementácia triedy je vecou autora danej triedy. Ak nevolá rodičovský konštruktor, je to chyba.

Ktorú nemožno rozumne detekovať.

Pri použití inject* metód má framework lepšiu kontrolu nad injectovaním závislostí.

Prečo?

Lebo framework nemôže zdetekovať či bol zavolaný rodičovský konštruktor, aby na to mohol upozorniť výnimkou.

@studna: Sám používam obe možnosti. Tu sa len snažím vysvetliť, prečo je v presenteroch v quickstarte odporúčané používať inject metódy.