Presentery: property lazy-autowire na steroidech

Osobně bych to napsal spíše jako trait, aby to šlo používat i jinde než v presenterech (komponenty, modely, služby). Mám možnost používat PHP 5.4, tak proč ji nevyužít (uživatel PHP 5.3 si kód traitu do BasePresenteru snadno zkopíruje). EDIT: @HosipLan mne vyvedl z omylu, byl to velmi špatný nápad.

Zatím ale dost váhám zda se do toho pouštět, je to nechutně pohodlná čuňárna. :-D

P.S. Do Nette podobná magie imho nepatří (byť jsem dříve měl opačný názor).

Editoval enumag (16. 12. 2012 18:27)

@HosipLan: Možná máš pravdu. :-) Ale stejně bych rád slyšel důvod proč je to odpustitelné pouze v presenterech a jinde ne.

Editoval enumag (25. 4. 2013 13:59)

@HosipLan: Jako odpůrce psaní inject* metod považuji už dlouhou dobu autowirování do properties s @inject anotacemi jako jediný akceptovatelný způsob, jak nahradit používání $this->context, který je ve srovnání s inject* metodami výrazně praktičtější a produktivnější.

Trocha inspirace ze SF2 bundlu. Já to teda nepoužívám, ale na ty controllery/presentery to může být celkem fajn no.

http://jmsyst.com/…/annotations

Editoval maryo (16. 12. 2012 18:15)

@HosipLan: Co takhle umožnit zápis @autowire serviceName? Řešilo by to problém, kdy nelze určit službu pouze na základě typu.

Jsem take pro zavedeni @autowired v konecnem dusledku to bude inject*, akorat pohodlnejsi.

Idealne kdyby to umelo akceptovat i interface viz https://forum.nette.org/…ept-generics

/**
 * @autowire IMyService
 */
protected $myService;

<=>

/**
 * @autowire MyServiceImpl
 */
protected $myServiceImpl;

Nemůžu dostat z hlavy jednu asi až moc očividnou věc – chceš řešit injection hell, ale vadí servicelocatior + magie … co to redukovat jen na magii (stejně černou a prohnilou, leč…)?

Místo aby se @autowire automaticky načetlo ala service locator, co takhle dát kód do __call který by simuloval injectXY? Takže mechanismus injectů by zůstal kompletně zachovaný, jen by už kód neplevelily injecty, ale jen anotace (podobně jako u Nette\Object::get by to šlo samozřejmě překrýt vlastní metodou, pokud by tam člověk chtěl ještě něco dělat)

Něco mi uniká?

Edit: aha, nebude to lazy … ale tak případně jako druhá možnost

Editoval Nox (17. 12. 2012 11:02)

@HosipLan: Pokusím se ti vysvětlit ten jeho nápad.

Místo

class MyPresenter extends UI\Presenter
{
	/** @var ArticleRepository */
	private $repo;

	public function injectArticleRepository(ArticleRepository $repo)
	{
		$this->repo = $repo;
	}
}

by se použil kód (tu @method anotaci jsem doplnil já, jinak netuším, jak by to mohlo fungovat):

/**
 * @method injectArticleRepository(ArticleRepository $repo)
 */
class MyPresenter extends UI\Presenter
{
	/**
	 * @var ArticleRepository
	 * @inject
	 */
	private $repo;

	public function __call($method, $args)
	{
		// dark magic
	}
}

Je zřejmé, že anotace nad private $repo by bylo možné vyhodit a řídit se jen @method anotacemi.

Nápad pěkný, ale nelíbí se mi, ač skutečně nepracuje se service locatorem.

@Jan Tvrdík: to by se muselo ještě domyslet, protože s tou @method je toho psaní tak asi stejně, ne méně, takže nevýhody spíš převáží. V method je duplicitně typ (už je ve @var), ohledně názvu – ten by se dal doplnit za @inject s tím, že by byla nějaká konvence, nejspíš podle názvu proměnné (pokud to v rámci anotací je možné) – a pak by se nemuselo psát ani tam. Pak by šlo @method odstranit. S tím, že by pak už nebylo v CC – jediný případ, kde by to vadilo, mě napadlo – pokud někdo dělá unit testy presenterů.

Pak by to bylo

<?php
class MyPresenter extends Presenter // featuring dark magic
{
    /**
     * @var ArticleRepository
     * @inject
     */
    private $articleRepository; // chybí serviceName = udělá inject.ucfirst($varname)

}
?>

Editoval Nox (17. 12. 2012 18:17)

Ono už settery na povinné závislosti je taková vratká věc imho, ale máš pravdu, toto je na tom ještě hůř. Tak pokus byl :)

Editoval Nox (18. 12. 2012 12:21)

@hrach: které? tohle? :))

@HosipLan: jj :)

Je to účelně dělané tak, aby to bylo jen v BasePresenteru a tedy použitelné pouze v presenterech.

@Hosiplan: Zkusím nahodit úplně jinou perspektivu. (mírně off topic) Injektování komponent jen v konstruktoru? Co když mám problém, který popisuješ posunutý na úroveň komponent a používám prezenter, jen proto že to zatím neumím jinak (jako prostředníka na generování komponent a vše ostatní řeším v komponentách)?

Důvod a vize: Co kdyby se komponenta mohla kdykoli sama stát „prezenterem“ a zároveň, aby mohlo být více "komponent(prezenterů)¨ na stránce nebo jeden a tentýž vícekrát? Dělení Prezenter ⇒ komponenty beru jako nepříjemně svazující. (mám už představu jak by to mohlo fungovat, ale ještě hodně abstraktní)

Chcu tez trait! Presne jak psal JT – kvuli jednoduche znovupouzitelnosti.

Tak ok no, udělal jsem traitu :P

Davídku, co ty si o tom myslíš? Já vím že chceš tlačit striktní DI (alespon jako vychozi best practise), ale ty presentery jsou fakt oser :)

Jen detail. Když už, proč ne možnost nastřelit třeba blog.articles? Proč jen autowiring podle typu?

@maryo: protože přesouváš „konfiguraci“ do aplikace. Jména služeb jsou nepodstatná – důležité jsou interfacy a abstrakce. Proti nim máš programovat a ty máš vyžadovat. To že na interfacy v 90% případů kašleme, je jenom otázka lenosti.

Jsem přesvědčen, že tady ta lazy-autowire magie je pořád menší zlo, než vyžadovat služby podle názvu.

Já v Nette nedělám (firemní rozhodnutí), i když na soukromej projekt bych si možná vybral, tak se můžu mýlit.

Pokud se používá BasePresenter, neregistrují se presentery jako služby, tak je ten presenter stejně závislej na containeru a používá se stylem service locatoru. Tj. že se stejně tahaj služby pomocí getService (nebo jak to v nette je) a jejich jména (pokud se nepoužije ta tvá magie), ne?. Pak už to vyjde nastejno, ne? Nebo mi něco nedochází (pravděpodobně :))?

Editoval maryo (21. 12. 2012 15:17)

Čas jít pracovat jinam.

Symfony2 taky neni zlý. Má větší komunitu a víc rozšíření (bundlů). Ale asi bych si stejně vybral Nette, nemám v tom ještě jasno kdo by zvítězil. Nicméně nechci rozjíždět flame a navíc je to tu trochu OT :)

Bylo tomu tak, ale od určité doby už třída UI\Presenter není na DI containeru závislá. Předává se pouze kvůli zpětné kompatibilitě.

Cool 8-)

BTW když předání služby na základě její třídy/interfacu stačit nebude (i když ve většině případech to asi stačí), co pak? Pár závislostí se bude muset konfigurovat jinak a to neni asi úplně ono nebo se vám to ještě nestalo? Nebo to je ono? :)

Nevím proč by to nutně muselo být nečistý. Někdy prostě požaduješ nějakej abstraktní typ jako závislost (Interface, Abstraktní třídu) a na jednom místě chceš předat jednu implementaci a na druhym místě jinou (obě jsou registoravný jako služby v kontejneru). Tam už si asi jen s typem nevystačíš, ne? Ale žádnej rozumnej příklad pro Presenter mě teď zrovna nenapadá :). Pro obyčejný služby by se jich našlo asi dost.

(To s těma generickejma službama už jsem četl, zní to zajímavě)

Editoval maryo (21. 12. 2012 17:06)

@HosipLan: Tohle obcházení problému mi přijde výrazně horší, než povolení @autowire serviceName, které neporušuje nic víc, než to, co už je dávno porušeno celým konceptem @autowire anotací.

Považuji to za obcházení problému zcela nezávisle na existenci @autowire. Ten problém prostě současná Nette implementace (předpokládající nepoužití $this->context) má a ty nenabízíš řešení, pouze konstatuješ, že workaround který existoval před @autowire existuje a funguje pořád.

Více k tématu parametry v presenteru zde

Prosil bych všechny o migraci na kdyby/autowired. Původní balíček ani repozitář mazat zatím nebudu, ale nebude ani vyvíjen. Použití je naprosto identické, stačí změnit namespace v BasePresenteru.

Oproti původnímu obsahuje kdyby/autowired hromadu vylepšení a v repozitáři je navíc druhá traita pro továrničky na komponenty, od matej21. Více v nové dokumentaci.