Jak dostat do BaseControl službu, aniž by se jí museli potomci zabývat?

Ok, napíšu to jinak. Chci vyřešit:

1. Jak na jednom místě upravit pravidla pro dohledávání šablon jak presenterů, tak komponent (a případně registraci vlastních maker)?
2. Aniž by to znamenalo nutnost změnit způsob vytváření komponent v configu.

Když o tom tak přemýšlím, tak je to stejný problém, jako jak dostat do komponent třeba Translator (je nepovinný a nechci aby s ním měli potomci jakoukoliv práci). Nette tyto vazby řeší skrytě vytažením z kontejneru.
Akademická otázka – daly by se vlastně presentery a komponenty přepsat tak, aby měly jen inject metody s konkrétními závislostmi a neměly přímou závislost na kontejneru? A pokud ano, je to správná cesta, nebo je dobrý důvod k tomu používat stávající řešení?

Jak na jednom místě upravit pravidla pro dohledávání šablon a registraci vlastních maker

Umístění šablony komponenty nebo makra v ní použitá jsou zcela jistě pevně daná, jaký má smysl z toho dělat konfigurovatelnou závislost? Výsledkem je pak komponenta, do níž je nutné injektovat jeden velmi specifický objekt, obdobný service locatoru, bež něhož nebude fungovat.

Komponenta si musí makra, která používá, registrovat sama (ať už jakkoliv).

Btw Nette 2.1 si z kontejneru vytahovalo jen Latte, což vyřešil refactoring a od 2.2 si nevytahuje už nic.

Ja to resim bodem 2.:

https://bitbucket.org/…xtension.php?…

Pak maji vsechny factories automaticky inject: true

Je tedy možné použít anotaci @inject v komponentě nebo ne? Nebo se to musí nějak explicitně zapnout (pokud možno nějak globálně, abych nepřišel o ten krásný krátký způsob definice služby v configu)? Nebo je to až tak moc „špinavé“, že se to za žádných okolností nedoporučuje (navzdory tomu, že to řeší constructor hell)?

Přiznám se, že jsem si zatím ani netroufl to zkusit, ale rád využiji každou možnost jak si ušetřit psaní, mám různé druhy BaseControlů, které jsou na sobě různě závislé a vyžadují různé služby a už se v těch konstruktorech začínám trochu topit. Anotace @inject v presenterech je fajn a co se tak dívám kolem sebe, tak je to i doporučovaný způsob injectování, jenže já to využiji akorát na továrny pro komponenty. Komponenty na druhou stranu mnohdy závisí i na deseti službách a jejich konstruktory pak nepříjemně bobtnají.

Osobně bych @inject v komponentách vůbec nezatracoval. Naopak, kdyby se to stalo běžnou praktikou, všichni bychom si ušetřili psaní a časem by nad tím většina přestala kroutit hlavou, stejně jako v případě @inject v presenterech. (IMO)

Editoval Zax (22. 5. 2014 2:03)

Každý ví, že služby v presenteru nepřepisujeme, navzdory tomu že jsou public, tak snad každýmu automaticky docvakne, že to samé bude platit i pro komponenty. V modelu nebo kdekoliv jinde nemám problém použít konstruktor, ale komponenty prostě mají tendenci bobtnat, kromě modelových služeb v nich často potřebuji User, Cache, Session, různé další továrny pro subkomponenty a formuláře a ve finále je v tom hroznej bordel. To je pak zábava přidávat nebo odebírat službu.

Proč je vlastně pro presentery doporučená anotace @inject a ne metody inject, když jsou vlastně čistší? A když to porušení zapouzdření nevadí u presenterů, proč by to mělo vadit u komponent? Není to snad právě kvůli tomu, že s anotacemi se pracuje podstatně jednodušeji než s inject metodami?

Chápu tedy dobře, že anotace @inject je špatná jen z akademického/dogmatického hlediska a jinak je vše v pořádku, pokud se služby nepřepisují? V tom případě jsem ochoten toto oželet, v zájmu pohodlnějšího a rychlejšího vývoje. Nebo lépe řečeno: pro mě by to byla killer feature ;-)

Editoval Zax (22. 5. 2014 4:00)

Po důkladném prohledání tohoto fóra jsem dospěl k následující extension, která mi zapne @inject anotace pro komponenty generované továrničkami, které mají v názvu třídy „Components“. Jsem spokojený :-)

final class ComponentInjectEnabler extends CompilerExtension {

    public function beforeCompile() {
        $builder = $this->getContainerBuilder();
        foreach ($builder->definitions as $definition) {
            if ($definition->implement && strpos($definition->implement, 'Components') > 0 && method_exists($definition->implement, 'create')) {
                $definition->setInject(TRUE);
            }
        }
    }

}

Za mě souhlasím. Mám podobný názor, který se přes několik diskuzí nezměnil. Osobně by se mi inject medody líbily povolené všude, anotace nikde. Na prototypy je ale taky používám (při refaktoringu je přepíšu), takže imho povolit všechno všude a je jen na programátorovi, co použije a proč. Inject metody se hodí třeba na nepovinné závislosti a často se mi takové nepovinné závislosti objebují v base třídách.
A určitě souhlasím s tím, že presenter a komponenty jsou skoro totéž.

Závislosti do komponent lze velmi snadno předávat přes konstruktor – v kombinaci s generovanou továrničkou se to chová jako jakákoliv jiná služba.

Zax napsal(a):

Úplně nejradši bych byl, kdyby mi k tomuto příspěvku napsal názor přímo sám @DavidGrudl

Ono k tomu není moc co dodat, napsal jsi to perfektně :-)

…Je ale třeba fakt důsledně respektovat to, že zvenku se na tyto proměnné nesahá a zrovna právě u presenterů (kde je anotace @inject doporučovaný způsob) to k tomu někdy vyloženě svádí – člověk má komponentu a z ní si sáhne do presenteru pro nějakou službu, která tam je takto nainjektovaná. Přitom komponenta by měla vědět prd o tom, co je v presenteru.

Doporučovaný způsob je používat konstruktor. Anotace jsou spíš tolerované. Sahat si pro něco z komponenty do presenteru je problém sám o sobě, ať jde o proměnnou nebo metodu.

2. Inject metody: … Je třeba mít na paměti to, že v konstruktoru potomka nemám k dispozici závislosti předka.

Kdyby to náhodou bylo potřeba, dá se to řešit tak, že se v potomkovi vytvoří taky metoda inject. DI kontejner zaručuje, že ji zavolá jako poslední.

3. Konstruktor/klasické settery: Snažím se tvořit co nejčistěji, třeba dělám nějakou knihovnu, která by měla být použitelná i samostatně, bez DI kontejneru

Tady musím doplnit, že všechny způsoby injektování, které Nette podporuje, jsou použitelné i bez DI kontejneru. Použitelnost bez DI kontejneru je základním rysem DI. I metoda inject je klasický setter, neboť není podmínka, že setter musí začínat prefixem set.

Moje návrhy:

1. Kromě presenterů bych defaultně povolil injecty i u komponent.

Ono to vede k tomu, že pak programátoři místo konstruktorů píšou metody inject. Tedy myslím tam, kde není žádný důvod inject používat.

Inject metody – …úplně nechápu ten myšlenkový pochod typu „u presenterů je to v poho, u komponent je to fuj“.

Inject je úplně korektní věc všude, kde nelze použít konstruktor. Ať už jde o presenter, komponentu nebo jakoukoliv jinou třídu. Že je to automaticky povolené jen v presenterů je dáno spíš tím, že šlo o experimentální řešení a v presenterech to nejvíc pálilo.

Zde se píše, že "Komponenty jsou typicky vytvářeny přímo v kódu presenteru, nebo prostřednictvím továren, které jsou specifické pro danou aplikaci. V těchto případech Nette nemůže závislosti automaticky předat a není možné použít metody inject*, ani anotaci @inject." – jenže to dnes, kdy máme automaticky generované továrničky (které jsou doporučeným způsobem vytváření komponent), přece neplatí!

Ten text je napsaný nešťastně. Jednak obojí používat lze, s tím, že je to potřeba ručně naplnit, a nebo použít továrničku. Pošleš opravu?

2. Rozdělil bych anotace a inject metody

To zbytečně věc komplikuje.

3. Asi by bylo fajn neuvádět anotace jako doporučovaný způsob vkládání závislostí do presenterů. Konstruktor přeci funguje úplně normálně a na base bych opět použil inject metodu. Zde se argumentuje tím, že anotace @inject nekomplikuje kód, což je sice fakt, ale to přece ani konstruktor.

Ano, opět by to chtělo text vylepšit (btw, jsem vděčný, že @Panda tu kapitolu vůbec sepsal, nerodila se snadno a pochopitelně jsou tam věci na vylepšení.)

A taky mám trochu tušení, že to bude BC break, třeba takové Kdyby (teď nevím, jestli zlobí Doctrine nebo Translation) se s mým hackem moc nekamarádí. Ale asi by nebylo špatné to zahrnout do nějaké příští major verze, hm?

To proto, že na spoustě tříd inject natvrdo vypínám, protože jeden čas byl zaplý i na službách a já chtěl aby se to chovalo jinak. To že to u některých služeb, na které ty v podstatě sahat nepotřebuješ, potřebuji jinak, je naprosto legitimní.

Zapnout to úplně pro všechny služby úplně automaticky není úplně nejšťastnější řešení.

To je přesně ten důvod, proč ten hack nepoužívám. Ignoruje přepínač inject: no.
@DavidGrudl: Opravdu bys nemohl přidat konfigurační možnost, kde by se dalo upravit které třídy se budou autoinjectovat, prosím? S tím, že výchozí chování bude jak se to chová dnes [Presenter]. Extension, která natvrdo zapíná inject pro některé třídy na to jdou příliš natvrdo.

@FilipProcházka, @Šaman Možná bych se u toho interface ještě podíval na @return anotaci a dal inject jen pokud to opravdu vyrábí komponentu a ne něco jiného.

@FilipProcházka Dík, tohle to vysvětluje. A ano, povolovat to všude není úplně nejšťastnější, ale jak mám napsáno v komentáři, je to „because FREEEEEDOOOOM“ (byť zatím injektuji jen v komponentách).

Buď bych se klonil k tomu, co tu navrhuje @Šaman, nebo by možná nebylo úplně od věci zavést jinou konvenci. Navrhuji povolit inject všude, ale s tím, že (libovolně pojmenovaná) metoda musí mít anotaci @inject. Pak si může kdokoliv pojmenovat settery injectNeco a kontejner je bude ignorovat, pokud ta anotace u nich není. Nenapadá mě žádná nevýhoda, snad jen kromě nižšího výkonu při sestavování kontejneru a nutnosti si ty anotace dopsat. Výhodou je pochopitelně možnost injektovat kdekoliv (na tom není nic vyloženě špatného, ne?) a konzistentnější konvence (u vlastností se čte anotace @inject, u metod se čte název, to není úplně konzistentní).

Editoval Zax (9. 8. 2014 17:07)

@DavidGrudl je to implementační detail, který nemění chování a zlepšuje výkon ⇒ validní.

@TomášVotruba predevcirem jsem napsal librette/setup. ktery by melo resit problem base trid. Zatim tam neni zadny readme, ale muzes kouknout na par use case, ktery to podporuje (navic je to i rozsiritelne, ale to az jindy :))

@matej21 Tomášův nápad s injecty se mi líbil a tvé extension navíc velmi elegantně řeší i tagy. Myslím, že tohle budu používat, díky! :-)

@hrach cim inject metody porusuji zapouzdrenost?

Uff, pleteš páté před deváté. Jednak nezavolání inject metody nemá nic společného se zapouzdřením. Inject property ho porušují, metody nikoliv.

Dále zda byly inject metody volány není třeba kontrolovat, protože musí být zavolány z definice. Obdobně, jako se nekontroluje, že byl volán konstruktor (jde to obejít), že byly dodrženy type hinty (jde to obejít) a že nebyl zavolán vícekrát (taky to jde).

@matej21 Moc pěkné, díky.

@hrach Souhlasím s balastem a částečně zapouzdřeností. Pokud by sis chtěl ušetřit balast i v configu (tedy přibližně polovina obsahu screenshotu), můžeš si na inject vytvořit malé rozšíření.

@DavidGrudl good, tak nemusim pokracovat ve vyvoji toho meho extension :)

jen par poznamek:

• do tech sablon by se hodila podpora trait
• kdyz uz jsi u tech uprav, tak bych v ServiceDefinition zmenil defaultni hodnotu inject na null – respektovaly by to pak ty „sablony“ a inject zapnuly pouze v pripade, ze $def->inject===null – to by umoznilo explicitne vypnout inject i pres to, ze sablona by to mela zapnout
• pokud se nepletu, tak tam nebude fungovat zkraceny zapis tagu bez argumentu, tedy tags: [foo]

edit:
jo a moc se mi nelibi ten zapis klic: sablona

a taky tam asi nepude setup bez parametru, tedy jen - injectFoo (a predpokladat, ze se zbytek autowiruje)

Editoval matej21 (15. 8. 2014 17:59)

@dg:

Málem mě omylo, když čtu tvou milnou argumentaci, bez pochopeni principu zapouzdrenosti.

Uff, pleteš páté před deváté. Jednak nezavolání inject metody nemá nic společného se zapouzdřením

Pokud objekt ve svem rozhrani nabizi stav, jez je mozne dosahnout spatnou praci s api objektu, pak se jedna prave o prilis benevolentni zapouzdreni. Zapouzdreni neznamena, ze je vsechno private, zapouzdreni znamena, ze se neda porusit konzistence objektu. Ze to resime pomoci private property, to je dusledek, implementacni detail. Nezavolanim metody dostavame objekt do stavu, ktery z principu nikde v kodu nekontroluje a neosetruje. Tim tedy vznika problem nedostatecneho zapouzdreni.

Inject property ho porušují, metody nikoliv.

Porusit zapouzdreni lze metodami jednoduseji. Aho, property ho porusuji, ale metody tez.

Dále zda byly inject metody volány není třeba kontrolovat, protože musí být zavolány z definice.

Davide, jsi autorita, ale ze si jednoho dne napsal clanek, jeste neznamena, ze jsi stvoril nějakou definici jak pracovat se zavislostmi v daném jazyce. Definice není nikde napsaná, nikde zdokumentovana (u kodu, povina zavislost rozsireni jazyka, apod.). Nebo mi můžeš říct, kde si danou definici mám vycucat např. u UI\Presenteru? Prostě jsi tam plácnul kód a očekáváš, že ho všichni budou používat tak, jak nettí DIC.

Pěkný protipříklady jsou @FilipProcházka usecasy.

Přesně tento problém, že to není nikde zadefinované, řeší pěkně již zmíněné symfony, které vyžaduje interface. Je to sice slabý kontrakt, ale aspoň nějaký.

Obdobně, jako se nekontroluje, že byl volán konstruktor (jde to obejít)

Prosim, prestan s tou demagoii. Je snad jasne, ze se bavime o vychozich chovanich. Vsechno jde obejit. Vychozi chovani constructor injeciton netrpi vadami jako metod / property injection.

že byly dodrženy type hinty (jde to obejít) a že nebyl zavolán vícekrát (taky to jde)

Souhlasím, u obou to je velmi jednoduse porusit, aniz bych vyuzival nejake dalsi nastroje (reflexi).

@matej21

neni treba chodit daleko https://api.nette.org/…ter.php.html

ale no tak, moc dobre vis, ze to je prvni a posledni kod, ktery to tak ma.

a co kdyz bych chtel v inject metode pracovat se zavislostmi konstruktoru?

netrapci. vymyslis hovadiny, misto abys to podlozil normalnim usecasem. a to je napr. to, ze v potomkovi (dejme tomu treba basepresenteru) volam jeho API (protected, nebo i verejny!) v konstruktoru – kde si sam ziskavam zavislosti. jak mam proboha tusit, ze ten predek to api nabizi az po te, co jsou mu zavislosti nainjektovany pomoci inject metod? Toto je poruseni te zapozdrenosti, musis znaz vnitrni implementaci, abys to nezprasil.

mj. z toho duvodu ma presenter metodu startup, ktera je v podstate jenom odlozeny constructor. a implementovat si toto do vsech trid, ktere maji inject metody… hovadina. Tj. zopakuji, inject metody jsou velmi nedobre a polovicate reseni, casto staci – ale presne ve chvili kdy staci, pak pro me ma vyssi hodnotu public property injection.

jinak presne timto problemem trpi Control/BaseControl, ktery nema startup metodu, a kvuli kteremu se to tady rozjelo.

To uz rovnou muzes rikat, ze vsechny property muzou byt public, protoze psat settery, ktery osetri vstup, je moc srani.

vsak presne to si myslim. napr. https://github.com/…Metadata.php vyzaduju rychlost. je to z podstaty interni trida, resit tu gettery a settery je hloupost.

Zajímavý čtení. Souhlasím s @hrach, že se objekt může dostat do nekonzistentního stavu, ale na druhou stranu – proč bych to proboha dělal, když vím, že to nejde? Ideální by byla v komponentách ta obdoba metody startup(), která může suplovat konstruktor, ve kterém ještě nejsou předány všechny závislosti. Občas je potřeba něco inicializovat hned na počátku.

Čím víc mám v aplikaci závislostí, tím horší je se v tom vyznat, to je jasné. Konstruktor na dva řádky už je hrozný bordel. Optimální cesta jsou podle mě buď inject* metody nebo public properties, ať si každý používá co chce. Když bude chtít někdo prasit a sahat kam nemá, jak už někdo psal, klidně si předá celý DIC, context a já nevím co ještě. Raději budu mít čistý a přehledný kód, než abych se v něm nevyznal a byl se v prsa, že používám teoreticky správné řešení.

@Climber007 inicializaci komponenty doporucuju provadet v attached

use Nette\Application\UI;

class FooControl extends UI\Control
{
	public function attached($presenter)
	{
		parent::attached($presenter); //nezapomenout zavolat

		if($presenter instanceof UI\Presenter) { //jelikoz to muze byt i necho jinyho
			//tady nejdriv muzes pracovat s presenterem - vytvaret linky, plnit sablonu....
		}

	}
}