Proč Nette\Application\UI\Control nepoužívá template factory?

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Andrewsville
Člen | 6
+
0
-

Zdravím a mám otázku.

Je nějaký důvod, proč Nette nepoužívá template factory ve svém DIC, ale místo toho se instance šablony vytváří „ručně“ (https://github.com/…/Control.php#… Paradoxní je, že třeba instanci Latte (o metodu níž) to vytvoří za pomocí Latte factory.

Docela by se nám to hodilo, protože takhle musíme v našich presenterech překrývat metodu createTemplate, abychom si zavedli vlastní helpery, atd. A hlavně řešíme, jak se dostat ke stejně nastavené šabloně v servisách (momentálně injektujeme application jenom proto, abychom z ní dostali presenter a z něj šablonu) a komponentách (kde taky získáváme instanci šablony přes presenter).

Kdyby se ta factory používala i v UI\Control, dalo by se to nakonfigurovat centrálně a celé by to bylo mnohem hezčí.

Jsem ochotný a snad i schopný spáchat PR, ale napřed se chci přesvědčit, že k tomu není nějaký důvod, který mi jako ne-Nette-guruovi uniká :)

Nebo existuje jiné hezké řešení, které mi zatím uniklo? Díky.

Editoval Andrewsville (28. 2. 2012 15:34)

David Grudl
Nette Core | 8147
+
0
-

Současná implementace je špatná.

Šablona a její konfigurace je totiž věcí čistě prvku Control a nemůže mu být injektována. Control ví, jaká makra, proměnné, helpery v šabloně používá a nastaví si je tam. Tyto věci je kontraproduktivní globálně měnit, mohly by přestat fungovat prvky třetích stran.

Co naopak je vhodné globálně ovlivnit, je formát výstupu XHTML nebo HTML a úložiště cache. Z toho důvodu se injektuje Latte, přesněji jeho továrnička. A to je právě špatně, měl by se injektovat jen cachestorage a parametr s formátem výstupu.

Použití TemplateFactory by asi bylo dobré, ale globální injektování nikoliv.

Honza Marek
Člen | 1664
+
0
-

David Grudl napsal(a):

Šablona a její konfigurace je totiž věcí čistě prvku Control a nemůže mu být injektována.

Použití TemplateFactory by asi bylo dobré, ale globální injektování nikoliv.

Mám podezření, že to jsou jen výmluvy pro to, aby se současný kód nemusel měnit. Pokud někdo přidává nová makra či helpery do šablony, tak její funkčnost nemění, ale rozšiřuje. Jistě by tam mohly teoreticky vzniknout nějaké konflikty, ale globální nastavení project specific záležitostí tyto nevýhody bezpečně převáží.

redhead
Člen | 1313
+
0
-

Po dlouhé době jsem začal dělat v Nette a přesně na tohle jsem taky narazil a chytal se za hlavu. Proč?!! :(

bojovyletoun
Člen | 667
+
0
-

Taky se mi nelíbí, že $container->nette->createTemplate() jednak vytváří instanci FileTemplate a zároveň ji i nastavuje další věci(helper,latte). Vytvoření obyč Templating\Template pak nejde flexibilně.

Nápady:

  1. createTemplate by mohla přijímat název třídy, jako je to přesně v Nette\Application\UI\Control::createTemplate(). Bylo by funkční, ale takovýhle styl se mi poněkud nelíbí.
  2. vyčlenit metodu setupTemplate(){latte;helper;} Tím pádem vytvoření Template nebude bolestivé(můžu si v kódu vytvořit new Template a zavolat setup a nebo továrničku přidat do configu, kde bude jen addSetup)

Celkově souhlasím s tím, že proces vytváření šablon a věci s tím spojený by se měli ynovovat.

Editoval bojovyletoun (14. 6. 2012 22:29)

juzna.cz
Člen | 248
+
0
-

Ja jsem si na to udelal interface a sluzbu ITemplateConfigurer, ktera prave pridava custom helpery a parametry do sablon. V mem BasePresenteru a BaseControlu mam pretizenou metodu createTemplate a navic tam zavolam ten configurer, aby mi jiz vytvorenou sablonku donastavil.

V projektu je stejne 99% komponent mych vlastnich a tam bych chtel, aby mohly vsechny pracovat se stejnyma moznostma v sablone. Jinak je v tom zmatek, co kde je a neni.

LeonardoCA
Člen | 296
+
0
-

David Grudl napsal(a):

Současná implementace je špatná.

Šablona a její konfigurace je totiž věcí čistě prvku Control a nemůže mu být injektována. Control ví, jaká makra, proměnné, helpery v šabloně používá a nastaví si je tam. Tyto věci je kontraproduktivní globálně měnit, mohly by přestat fungovat prvky třetích stran.

Co naopak je vhodné globálně ovlivnit, je formát výstupu XHTML nebo HTML a úložiště cache. Z toho důvodu se injektuje Latte, přesněji jeho továrnička. A to je právě špatně, měl by se injektovat jen cachestorage a parametr s formátem výstupu.

Použití TemplateFactory by asi bylo dobré, ale globální injektování nikoliv.

Chápu důvod, ale většinou chci použít globální nastavení.

Co takhle nechat rozhodnutí na autoru komponenty/uživateli?

  • přidat nějaký switch useGlobalTemplateConfiguration (by default true)
  • defaultně používat globální nastavení!
  • každý by si jednoduše mohl globální nastavení pro konkrétní komponentu vypnout pokud by měl problém

Autor komponenty by mohl

  • napsat komponentu tak, ať funguje z výchozím sandboxem
  • případně rozšířit konfiguraci template o to co potřebuje
  • ve výjimečných případech defaultně nastavit použití vlastního createTemplate

IMHO je současný stav kontraproduktivní – vede jen k tomu, že si to „každý“ stejně naprogramuje po svém (a naopak komponenty třetích stran si pak někdy musí přizpůsobit).

pekelnik
Člen | 462
+
0
-

LeonardoCA napsal(a):

  • chápu důvod, ale většinou chci použít globální nastavení
  • napsat komponentu tak, ať funguje z výchozím sandboxem
  • případně rozšířit konfiguraci template o to co potřebuje
  • současný stav je kontraproduktivní: vede k tomu, že si to „každý“ stejně naprogramuje po svém

+1

+ duplicita kodu v basecontrol a basepresenter