TemplateFactory: tenká hranice mezi patternem a antipatternem

Okey, chápu důvody a to co píšeš je samozřejmě nejčistější způsob, ale (nikdy bych nevěřil že ti budu vyčítat nedostatečnou pragmatičnost zrovna já :D ) …

Modelová situace…

1. mám helper/makro na gravatary, chci ho v celém projektu vždy ve všech šablonách, jak na to?
   • zaregistrovat ho v každém jednom presenteru a komponentě?
   • zaregistrovat ho ve svém base control a base presenteru?
   • napsat do konfigurace jeden řádek?
2. mám helper na formátování ceny, o kterém vím že ho budu potřebovat v celém projektu (stovky šablon komponent i presenterů)
   • zaregistrovat ho v každém jednom presenteru a komponentě?
   • zaregistrovat ho ve svém base control a base presenteru?
   • napsat do konfigurace jeden řádek?

Je jasné, že když je regnu v base controlu a base presenteru, tak to bude o trochu čistější (nějak je tam musím dostat, musejí si o závislosti pro makra říct), protože stejně všechny moje komponenty a presentery od nich dědí.

Na druhou stranu, není to tak dávno co jsi začal propagovat že base presentery jsou anti-pattern (což jsou, ale označit něco za anti pattern a ukázat lepší řešení, jsou dvě různé věci), nehledě na to že se stejně hromadné utíkání od base presenterů přes noc nekonalo.

Jak bys předložené reálné potřeby z praxe řešil?

a nemely by se smazat i defaultni helpery a makra? (treba tyhle)
myslim, ze budes souhlasit, ze ne. Jsou to proste core veci, ktere jsou casto potreba v kazde aplikaci a v kazde sablone. Ale v ramci urciteho projektu se proste ten seznam maker/helperu, ktere potrebujes vsude, rozsiruje. Gravatary, obrazky, ceny, rozsirena makra pro formulare… A znovu a znovu registrovat v desitkach a stovkach komponent proste nedava smysl. Nehlede na to, ze pri podobnych commitech bych to musel vsude upravovat.

Je naprosto zásadní rozdíl mezi nastavením cesty pro cache a instalací vlastních maker. To první je totiž komponentě šumák, kdežto to druhé je pro ni esenciální a není-li nastaveno přesně tak, jak vyžaduje, dojde k chybě.

Stejne tak pokud bude nastavena spatna cesta k cache, dojde k chybe. Nebo nebude existovat nejaka z techto promennych, dojde k chybe. Proste uz ted jsou sablony zavisle na globalni konfiguraci a rict „Tak, tyhle makra, tyhle helpery a tyhle promenne jsou core a jsou spolecne pro vsechny, vsechno ostatni uz se musi registrovat individualne, jinak je to antipattern“ nechapu – bud vse nebo nic :)

Pokud pomocí konfiguráku instalujete makra, vytváříte tím závislost presenterů či komponent na konfiguraci.

Kdyz bych to vzal do extremu, tak i registraci sluzeb v konfiguraku vytvarim zavislost presenteru, komponent ci jinych sluzeb na konfiguraci – spoleham na to, ze uz budou registrovany a spravne inicializovany.

#trolling: A kde přesně komponenta specifikuje že je závislá na šablonovacím systému Latte?

Zkusím nastínit svůj pohled na tuto problematiku, který je trochu jiný než Davidův a poté nápad ke kterému jsem došel po přečtení Davidova příspěvku.

Už nějakou dobu používám níže uvedený způsob. Vzniklo to jako side-efekt mé adresářové struktury založené na PSR-4 (šablony mám zcela jinde než PHP třídy) a faktu že jsem chtěl mít možnost vytvářet themes a tedy pro jednu komponentu použít vždy šablonu z právě aktivní theme.

namespace App\FrontModule;
use Nette\Application\UI\Control;
class MyControl extends Control {
	// ...
	public function render($file)
	{
		$template = $this->getTemplate();
		$template->data = $this->someModel->getWhatever();
		$template->setFile($file);
		$template->render();
	}
}

{control myControl, $themeDir . '/@components/MyControl/default.latte'}

Zde je podstatná jedna věc. Komponenta samotná neví jaká šablona ji bude vykreslovat a taky ji to ani trochu nezajímá. Netuší jaká makra a helpery šablona použije, dokonce ani neví zda používá Latte, Twig, čisté PHP nebo něco úplně jiného. Tedy narozdíl od Davida nevnímám šablonu komponenty jako její nedílnou součást. Použitá makra a helpery tedy nejsou závislostí komponenty ale závislostí té šablony. Konfigurace maker a helperů z tohoto pohledu je konfigurace view vrstvy aplikace, tedy zajištění aby její šablony fungovaly. Zde už mi začíná dávat smysl makra registrovat v config.neon. Samozřejmě nic nebrání existenci více různých ITemplateFactory.

Po přečtení Davidova příspěvku jsem se nad tím zamyslel trochu více. Pokud komponenta nepotřebuje konfigurovat šablonu tak k čemu vlastně potřebuje ITemplateFactory? A vzato do důsledku, k čemu vlastně potřebuje ITemplate? Co takhle to celé otočit naruby?

class MyControl extends Control {
	public function getView()
	{
		return [
			'control' => $this,
			'flashes' => ...,
			'data' => $this->someModel->getWhatever(),
			// ...
		];
	}
}

// šablona, pro ukázku použito PHP
// reálně by se na to udělalo latte makro které by dostalo název souboru s šablonou, název komponenty a případně konkrétní instanci TemplateFactory
$templateFactory->createTemplate()
	->setFile($themeDir . '/@components/MyComponent/default.latte')
	->setParams($presenter['myControl']->getView())
	->render();

Je-li to celé blbost, prosím poučte mne. ;-)

Editoval enumag (19. 5. 2014 13:51)

enumag: tohle má smysl. Zopakuji z úvodního postu, že „instalaci maker si musí komponenta, používá-li fixní šablonu, dělat sama.“ Naopak, pokud cesta k šabloně se komponentně předává, instalaci maker a helperů dělat nemá.

V takovém případě můžeme třeba komponentě předat celý objekt Template a renderovat ji pomocí $template->render(NULL, $params) bez side efektů. Nebo úplně jinak.

@DG:

Jasně, to mne napadlo taky ale pak jsem si všiml že komponenta teoreticky ani nepotřebuje ten objekt Template a otočil to komplet. Je to ale v podstatě ekvivalentní. :-)

Vzato do důsledku, komponenta by pokud možno neměla používat fixní šablonu. Max může mít nějakou metodu která vrátí název výchozí šablony. V tom případě ale stále je na volajícím aby zajistil že ta šablona dostane potřebné závislosti (správně nakonfigurovaný latte engine etc.).

Mimochodem stejným způsobem by šlo řešit i formuláře. Rozdíl mezi rendererem a šablonou se poněkud vytrácí.

Nyní se vrátím k tvému úvodnímu příspěvku, na konci píšeš:

Pokud pomocí konfiguráku instalujete makra, vytváříte tím závislost presenterů či komponent na konfiguraci. Což je přesný opak inversion of control.

Jak jsme se přesvědčili, nejde (respektive nemusí jít) o závislost presenterů a komponent ale pouze o závislost šablon. To ti vadí také nebo ne? Pokud vadí, proč? Když chci komponentě předávat hotovu šablonu (nebo jen hotové šabloně předat parametry z komponenty) kde bych měl provádět tu konfiguraci pokud ne v configu?

Editoval enumag (19. 5. 2014 14:11)

Tím že to netvrdíš (napsal jsi jenom jak to nedělat) dáváš velký prostor pro interpretaci.

Jak řešíš to, že máš DB connection, jenž potřebuješ v celém projektu? (Hromada tříd.)

Good point. Použít service locator u tříd v modelu bych nevydýchal :) Na druhou stranu mi dělá problém tohle dělat u všech šablon. Něco takového si hodně těžko obhájím před zbytkem týmu.

Ale nechtěj po mně, abych v Nette nebo v příkladech používal něco jiného, než DI.

Nic takového nikde netvrdím ani nechci. Co po tobě chci je, abys ukázal i jak to řešit, ne jenom jak to neřešit.

Takže to shrneme

• buďto všechno napíšeme 200×, což je nejčistější ale neobhájím si to nikdy před týmem tak aby to dělali i z jiného důvod než jenom „procházka nám to nařidil“
• nebo to dám do createTemplate() v mém BaseControl a BasePresenter
• nebo si podědím TemplateFactory a přidám to tam a samozřejmě budu muset ve svém BaseControl a BasePresenter vyžadovat svou konkrétní TemplateFactory a nechat tu výchozí pro všechny cizí komponenty

nebo … ?

Filip: opět stejně jako s DB connection. Pokud ji potřebuji ve 200 třídách, buď napíšu 200 konstruktorů/setterů nebo budu dědit od společné třídy s tímto konstruktorem/setterem nebo použiji trait se setterem.

Analogicky totéž u komponent, jen místo setteru pro DB půjde o funkci createTemplate().

Díky, jsem rád že už si rozumíme :) Společný předek je přijatelné řešení.

Ze všeho co tady čtu se mi asi nejvíce líbí řešení přes traity. Kód je na jednom místě a můžu ho bez problémů použít jako v presetneru tak v komponentě. Neměl by být ani problém použít stejnou traitu i pro šablony emailů a šablony mimo presentery a komponenty obecně. Velmi dobře si tak mohu i roztřídit skupiny maker a použít je jenom tam, kde je budu potřebovat. V případě vlastních maker v nějakém balíčku mi autor ani nemusí nutit dědit nějakou jeho třídu, ale jenom použití traity.

Šaman: neumím ti odpovědět jinak, než jako předtím.

a: Má tvoje komponenta metodu render, která vykreslí řetězec?
b: Má.
a: Používá se uvnitř metody render PHP šablona, Latte šablona nebo DOM?
b: To ti může být úplně ukradené, to je věc její vnitřní implementace.
a: Jak mám komponentě předat konfiguraci maker té šablony?
b: Jaké šablony? O šabloně nic nevíš, nešťourej se ve vnitřní implementaci, po tom je ti kulový.
a: Jak si teda ta komponenta nainstaluje makra a filtry?
b: Tak, jak bude chtít. Zavolá addFilter(), zavolá nějakou třídu, která to udělá, nech to na ní, nic neřeš a hlavně – nic neinjektuj. :-)

(k @injekt a inject() tu prosím neodbočujme)

Nikoho netrolím, nemám důvod, takže si prostě nerozumíme.

Pokud máš v patnácti třídách registraci stejných filtrů, tak tu registraci copy & paste do nové třídy a metody a volej jen tu metodu. Nebo to dej to společného předka. Co je proboha na tom nepochopitelného? A jak to souvisí s injektováním?

To je jako kdyby jsi chtěl každé použití globální nebo statické funkce nahradit callbackem, který bys injektoval. Proč? Volání čistých deterministických funkcí, které nemají postranní efekty a se stejnými argumenty vrací vždy stejnou hodnotu, není závislost.

Viz http://www.zdrojak.cz/…storu-v-php/?…

Jsem rád, že si rozumíme. Jinak statickou metodu můžeš klidně nahradit za (new MyTemplate)->registerFilters($template), ale nic se tím nemění.

Matej21: těch možností je více. Začněme tím, že ve hře není žádná template factory a komponenta si řeší šablonu sama, pak budou tyto služby jejími závislostmi. Stejně tak i v případě, že bychom použili jen nějaký helper jako tady.

Pokud by tu závislost jen delegovala dál do nějakého filtru/helperu, bylo by vhodnější místo ní předávat rovnou ten nakonfigurovaný filtr.

Pokud by takových filtrů bylo víc, nebo zejména kdyby bylo víc komponent, které je potřebují, bylo by načase předávat rovnou template factory, jejímiž závislostmi by byly ony služby.

V komponentě bych ale nemohl chtít obecnou Nette\Bridges\ApplicationLatte\TemplateFactory, chtěl bych vlastní template factory, která garantuje, že tam budou ty očekávané filtry.

Vytvoření takové komponenty v presenteru by už nebylo úplně triviální, protože je třeba jí předat template factory. Proto bych si vytvořil v konfigu továrnu na tuto komponentu a do presenteru předával už ji.

Zkusil bych přispět do diskuze s jedním modelovým případem. Hlavním argumentem proč ne TemplateFactory je, že by to zhoršilo přenositelnost komponent. Pokud ale řešíme přenositelnost tak je podle mě nutné uvažovat o jedné další věci:

Mám nějakou obecnou komponentu třetí strany, kterou použiju ve svém projektu. Ale potřebuju upravit/doplnit její vzhled, protože mi ten výchozí nezapadá do mojí aplikace. Na to potřebuju změnit její šablonu. A to tak, že v téhle její nové šabloně potřebuju nějaké svoje obecné helpery/makra.

Jaké by podle vás bylo nejlepší řešení těchto situací?

Btw za mě se mi hodně líbí navržené řešení od enumag, které by zodpovědnost za vykreslení přeneslo z kompomenty ven. Prostě zrušit závislost komponenty na její šabloně.

Asi bych se zkusil zamyslet jestli je vykreslení opravdu zodpovědností komponenty a mělo by být jen jejím implementačním detailem.

Editoval mystik (20. 5. 2014 18:42)