Template factory: TODO

Slovo globální vždycky zavání ;-)

Otázka je, co je to pro „celou aplikaci“. Jednotlivé komponenty určitě žádnou globální factory nechtějí, protože si věci řeší po svém (aby byly přenositelné). Totéž platí pro jednotlivé moduly. Takže spíš jde o to, jak ovlivnit template factory na úrovni modulů + komponent.

+1 vždycky mě štvalo vše registrovat v BasePresenteru a v BaseControl.

Proč né tohle? Kdyby se to ještě decánko učesalo, tak to imho splní účel perfektně.

Slovo globální je zde dle mého použito trochu ve špatném významu. Template factory jako servis ano, ale to přece neznamená že je globální. Nicméně s myšlenkou souhlasím a sám to již dlouhou dobu používám. Občas si třeba potřebuji jen vytvořit template někde mimo tak si prostě vytvářím přez TemplateFactory, což je definované v contextu. Pak jde jen o to přepsat BasePresenter a BaseControl metody createTemplate a je to. Jestli to bude Nette implementovat nebo ne je mi fuk, já to rozhodně budu používat tak jako do ted, což je přes (injektovaný) templateFactory.

Kdybys mi to napsal tam, tak jsem to mohl před čtvrt rokem opravit :) A dneska to předělám.

Je naprosto logický, že když chceš v šabloně nějaké helpery používat, tak je tam musíš zaregistrovat. To, že bude složitější registrace helperů, aby si lidi radši nic neregistrovali, to přece není řešení :D

Klíčové je si uvědomit, že generování šablony není služba.

Úkolem komponenty je něco vykreslit. Jak to udělá (přímo HTML, Latte, jiný šablonovací jazyk, atd) je její interní věcí, která musí být imunní vůči prostředí, kde komponenta žije. Konfigurovatelné může být snad jen to, jestli generovat XHTML nebo HTML kód.

David Grudl napsal(a):

Klíčové je si uvědomit, že generování šablony není služba.

Úkolem komponenty je něco vykreslit. Jak to udělá (přímo HTML, Latte, jiný šablonovací jazyk, atd) je její interní věcí, která musí být imunní vůči prostředí, kde komponenta žije. Konfigurovatelné může být snad jen to, jestli generovat XHTML nebo HTML kód.

Máš nějakej lepší nápad jak řešit situaci, že chceš mít ve všech vlastnoručně napsaných komponentách a v presenterech stejně nastavené latte, protože nechceš řešit v rámci jednoho webu kde jaký helper funguje a nefunguje?

Udělat službu TemplateFactory mi přijde jako velmi užitečná věc a ostatně konkurence to tak má

Dále bych upozornil, že by to přispělo k zeštíhlení presenteru z five responsibilities principle na four responsibilities principle. A taky, že bych na to byl schopnej vyrobit pull request tak za hodinu práce, protože to mám celkem rozmyšlené. Nemusíš tedy argumentovat proti jen proto, abys to nemusel programovat ;)

David Grudl napsal(a):

Úkolem komponenty je něco vykreslit. Jak to udělá (přímo HTML, Latte, jiný šablonovací jazyk, atd) je její interní věcí, která musí být imunní vůči prostředí, kde komponenta žije. Konfigurovatelné může být snad jen to, jestli generovat XHTML nebo HTML kód.

Nevidím důvod proč by komponenta nemohla dostat informaci (pomoc / vykreslovatko) to jak se má vykreslit z venku.

Viz třeba renderer u formulářů, proč by tohle samé nemohlo být i u „normálních“ komponent?

Pokud chci mít ve všech komponentách a presenterech stejně nakonfigurovanou šablonu, nechám si je všechny vyrobit společnou továrnou.

Což momentálně nelze jinak než si udělat BasePresenter a BaseControl ve kterých bude stejný copy-paste kód. (Nebo se pletu?)

A to je imho to o co tady jde.

Nevidím důvod, proč by mělo být použito static, global nebo $context.

Z téhle rozdělané větve by mělo být zřejmé, jak to celé myslím – https://github.com/…late-factory

K mergnutelnosti chybí poladit nette extension a vyrobení testů.

Má smysl, abych pokračoval?

Problém je v tom $templateFactory = $this->templateFactory ?: $this->getPresenter()->getTemplateFactory();.

Pokud si změním v aplikaci výchozí template factory, přestanou být komponenty přenositelné.

Pokud tedy říkáš, že

• template factory slouží k rozšíření funkčnosti
• ale komponenty se to nedotkne, protože ta bude využívat základní sadu,

vyplývá z toho zbytečnost navrhované úpravy.

@dg: Zbytečné to není, CompilerExtension tím získá několik možností navíc:

1. Přidávání helperů do šablony.
2. Přidávání vlastních proměnných do šablony, tyto proměnné pak mohou používat makra, které to extension registruje. Nyní když ve vlastním makru potřebuji nějakou službu, musím po uživateli chtít aby mi tu službu předal do šablony jako proměnnou nebo v makru použít $_presenter->context->getByType(...).

Dle mého názoru je primárním účelem služby templateFactory právě možnost rozšíření přes CompilerExtension, nikoli možnost kompletní výměny templateFactory. Např. mohu mít addon který pomocí CompilerExtension zaregistruje makra a helpery, které pak bude používat komponenta z toho addonu – tj. komponenta bude přenositelná společně s tím extension, protože extension zařídí její závislosti.

Problém je v tom, že makro se ti spouští jenom a pouze při komplikaci a když potřebuješ nějaké závislosti runtime, tak je tam přes makro těžko dostaneš :)

Nadruhou stranu se musí „globálnímu“ template factory nechat, že je to docela dost velká úspora času.

Když jsem na jeden ze svých projektů naimplementoval postup, který je detailně popsaný zde – https://forum.nette.org/…-pres-config, na content loadu jsem ušetřil více jak 100ms.

Kdeže, David si z neznámého důvodu myslí, že všechny controly by si měly nastavovat šablony samy. Ne, že by se to mělo umožnit, ale že by se to mělo vynutit. Myšlenka template factory jako služby jde bohužel proti tomu :)

Podobný problém řeším s rixxi/template-factory a rixxi/template-locator. Nejspíš o nich nevíte, ale než se dokopu napsat dokumentaci vyřeší se to v Nette :)

Editoval mishak (6. 1. 2014 21:01)

@enumag: TemplateFactory jako extension – Zenify/TemplateFactory

Prosím pouze o podněty ke zlepšení. Díky.

@enumag: Díky za přehledný feedback. OK: 1. layouts, 2. tagy, 3. konfigurace, 5. protected, viz změny,

4. (pole služeb) Tedy předat nette.templateCacheStorage, Nette\Http\IResponse, Nette\Caching\IStorage, Nette\Http\IRequest a Nette\Localization\ITranslator přes constructor, je tak?

6. (ne control) Zkusil jsem přesunout. Mohl bys mi případně ukázat konkrétní návrh?

7. (generovaná továrna) Zkoušel jsem, ale neuspěl.

ad 6) Přemýšlím nad něčím typu ITemplateConfigurator, kterých by bylo více (přidávány pomocí tagu) a ta TemplateFactory by novou šablonu prohnala těmito službami. Ten konfigurátor by mohl vypadat asi takto:

class TranslatorTemplateConfigurator implements ITemplateConfigurator
{
	private $translator;

	public function __construct(ITranslator $translator = NULL) { ... }

	public function configureTemplate(ITemplate $template) {
		$template->translator = $this->translator;
	}

}

Považujete to za dobrou cestu nebo za blbost?

EDIT: Pozn. šablona by imho vůbec neměla mít metodu setTranslator, ten helper by se přidal jinak.

EDIT2: Možná by se všechno (filtry, helpery, makra) mohlo přidávat skrz tyhle služby. TemplateFactory by pak jako jedinou závislost měla pole těch konfigurátorů a možná templateCacheStorage.

EDIT3: A ještě jedna střela od boku, možná úplná blbost – připravit jednu šablonu interně v té továrně a poté vracet klony.

Všechno co tu teď píšu jsou momentální nápady nad kterými jsem zatím moc nepřemýšlel tak to berte s rezervou. ;-)

Editoval enumag (5. 2. 2014 13:52)

@enumag: tohle vypada jako reseni :) zavislosti, helpery apod. by se pridavaly dobre, komplikovanejsi by to bylo s makrama.. ale to by se snad nechalo vyresit…

edit: nebo co takhle pridavat makra pres compiler extension? podobne jako to kdyby resi treba s IDatabaseTypeProvider ?

Editoval matej21 (5. 2. 2014 14:01)

@Tomáš Votruba:

4. Ano, takto.

8. Konfigurátory, které navrhuji by to asi vyřešily lépe.

Jsi rychlý jak blesk.

Jo, někdy až příliš… Mluvím/píšu dříve než si to stihnu promyslet.

@matej21:

Jo, makra to trochu komplikují… tam bude asi lepší ten provider jak píšeš.

Se službou User máš samozřejmě pravdu, nevšiml jsem si. :-)

Nějak se vracím ke 3 dny starému závěru – to RFC na TemplateFactory budu muset stejně napsat. :-D

Editoval enumag (5. 2. 2014 14:04)

@Tomáš Votruba:

Registrace maker je v poho, stačilo přidat Nette\Latte\Compiler.

jako kam? jestli do ITemplateConfigurator, tak rozhodne ne. sablona by nemela byt tolik zavisla na latte, krom toho se latte kompilace neprovadi tolikrat a ve stejnou dobu jako vytvareni sablony atd. jedine jako samostatnou sluzbu, ILatteConfigurator, ktery by se staral o registraci maker

Napadá mne, že i presenter lze injectnout. Tím by tato továrničky byla zcela nezávislá.

kdyz bezi aplikace, muze projit nekolika presenterama, at uz proste obycejny error presenter, nebo rucni zmena pomoci ->forward() apod. takze by se minimalne musel vytahovat ten presenter vzdy pri vytvareni sablony. ale stejne jsem proti tomu :) az se refaktoruje generovani linku a vytvori se pro to samostatna sluzba, nebude potreba dostavat presenter do kazdy sablony