Přístup ke konfiguraci v presenterech
- blindAlley
- Člen | 31
Vypadá to, že neexistuje rozumná alternativa Environment::getConfig(), která by byla v souladu s DI. Přitom požadavek na přístup ke konfiguraci v presenteru nebo komponentě je legitimní a docela častý.
Navrhuji aby se v PresenterFactory obsah konfigurace (sekce „parameters“ v neon konfiguraci, potažmo $this->context->parameters v PresenterFactory) posílal do každého presenteru přes nějaký setter. V presenteru by pak mohla vzniknout public metoda getConfig().
S tím souvisí i to, že PresenterFactory::$container je private. Podle mne k tomu není důvod, měl by být protected, použití containeru ve vlastní PresenterFactory je v pořádku.
- vvoody
- Člen | 910
Tak tak, ked uz je clovek lenivy cpat funkcionalitu do sluzby, tak si aspon vytvorim triedu/sluzbu ktora tie parametre dopravi do presenteru cez
22 napsal(a):
stačí bohatě
inject<Something>
Ale prave len tie parametre, ktore v tom presenteri potrebujem. Toto je podla mna v souladu s DI.
- blindAlley
- Člen | 31
Neřekl bych že setovat celou konfiguraci do presenteru je nějak extra špatně, stejně jako celou konfiguraci, dostává presenter vždy celý http request, ačkoli třeba cookie využije jen někdy. Mě přijde celá konfiguraci jako jedna služba. Ale asi je fakt, že pokud to nepotřebuje dělat sám framework kvůli sobě, tak není důvod aby to v něm bylo, ať si to každý zařídí sám.
Nicméně stávající řešení s inject<Service>, kterým si to mohu sám zařídit, pak vyžaduje psát na přenesení kousku pole z konfigurace zvlášť službu a to určitě není to pravé. Ale D. Grudl už zmínil, že upravovat setování služeb do presenterů bude možné přímo přes konfiguraci, to by bylo řešení.
A co to PresenterFactory::$container nově protected místo stávajícího private? Vůbec jako nejlepší řešení mi přijde, aby se PresenterFactory::createPresenter($name) změnila na PresenterFactory::createPresenter($name, Nette\DI\Container $container) a $container property z té třídy úplně zmizela, protože nikde jinde není potřeba.
