Komponenty a Presentery v DI Containeru

Dobrý, to dává smysl. Ale není trochu hardcore mít všechny presentery v containeru?

To máš opravdu config o 1000 řádcích? (Přeháním, ale když tam nebudou jen presentery ale i modely a komponenty, tak to může klidně být ještě víc)

Editoval HosipLan (2. 11. 2011 14:33)

Přijde mi rozumné dát konfiguraci presenterů do vedlejšího souboru (právě kvůli rozsahu konfiguráku). To ale nevím jak je možné v Nette, v Mediu používáme symfonní container. Další věc, co se hodí, tak je společné nastavování setterů třeba pro všechny front presentery. V symfony to lze provést pomocí dědění definic služeb, v nette v php továrničkách by to šlo pomocí nějaké pomocné konfigurační metody. V nette neonu nevím.

Co myslíš tím děděním služeb?

Aha, já si to blbě přečetl, dědění definicí služeb, jasně.

Pokud bys chtěl sestavovat presentery s plným využitím DI a konfiguráků, tak potom, jak píše Honza Marek, je jediná možnost mít každý presenter jako samostatnou službu. Každý záznam v konfiguraci je pak vlastně továrničkou, byť napsanou v jiném jazyce než PHP.

Na rozdělení konfigurace do více souborů chci buď doplnit sekci include do konfiguráku nebo nahradit loadConfig() za možnost vícenásobného volání addConfig() (a nebo obojí). Zároveň se nadtřída Configurator rozpadne do více samostatných tříd, každá z nich bude zpracovávat samostatnou část konfigurace.

BTW, stále nejsem schopen se rozhodnout. Mám konfigurák config.neon, kde bude sekce includes se seznamem dalších konfiguračních souborů. Otázka zní: mají inkludované konfiguráky přepisovat hodnoty prvního konfiguráku nebo naopak má hlavní konfigurák přepisovat hodnoty z inkludovaných?

Tj. config.neon:

includes:
	- routes.neon
	- services.neon
	- parameters.neon

parameters:
	a: 10

a parameters.neon:

parameters:
	a: 20

Kolik bude $a?

Inkludované soubory by podle mě měly přepsat hodnoty z dříve načtených souborů, tedy 20. Vidím tam paralelu s čistým php, kde inkludované soubory taktéž přepíší už definované proměnné, pokud jim přiřadí hodnotu.

a.php

<?php
$a = 10;
include 'b.php';
dump($a);
?>

b.php

<?php
$a = 20;
?>

K čemu budu includovat soubor s nastavením, když se jeho hodnoty stejně zahodí a použijí se defaultní?

Hodnoty z configu by měly mít větší váhu, než hodnoty z include. Čili a = 10

@22: koukáš na to ze špatné strany, výchozí jsou ty, které includuji (parameters.neon).

Editoval HosipLan (10. 11. 2011 18:02)

!important je děsivé!

Já bych to bral tak, že config.neon bude obsahovat výchozí nastavení a includnuté soubory budou tyto hodnoty přepisovat. Protože includování není nutné (narozdíl od toho mít config.neon) a tím pádem vám to volitelně přepíše na vlastní hodnoty a nastavení, pokud potřebujete upravovat nevýchozí nastavení.

Na druhou stranu jsem schopný se smířit s obojím, protože si dokážu představit, že by specifické lokální nastavení (které by se neverzovaly gitem apod.) nijak nepřepisovaly v hlavním neonu :)

tl;dr
preferoval bych a = 20

Pajka napsal(a):

Já bych to bral tak, že config.neon bude obsahovat výchozí nastavení a includnuté soubory budou tyto hodnoty přepisovat. Protože includování není nutné (narozdíl od toho mít config.neon) a tím pádem vám to volitelně přepíše na vlastní hodnoty a nastavení, pokud potřebujete upravovat nevýchozí nastavení.

Co když ale vznikne něco jako default-services.neon?

Na druhou stranu jsem schopný se smířit s obojím, protože si dokážu představit, že by specifické lokální nastavení (které by se neverzovaly gitem apod.) nijak nepřepisovaly v hlavním neonu :)

přesně tak

Mě by dávalo smysl buď že pozdější volání přepisuje dřívější (je jen na mě, jestli defaultní hodnoty napíšu před include sekci, nebo naopak vnutím nějaké hodnoty až po includování), ale pokud by se mělo stanovit pravidlo kdo má přednost, tak hlavní config by měl mít možnost přepisovat nastavení v includovaných souborech. Takže a = 10.

Ještě mě napadá vypůjčit si syntax z latte:

a: 10;
default b: 15;

22 napsal(a):
no tak jestli je to tak, tak pak 10, ale spíš mi přijde víc praktické mi config.noen, jako výchozí hodnotu a includované konfigy ho nějakým způsobem modifikují/rozšiřují..

To je věc názoru. IMHO config.neon ručí za správné nakonfigurování programu a pokud potřebuji nějakou hodnotu přepsat, musí k tomu mít možnost. Já includy chápu tak, že každý pokrývá nějakou oblast/modul/komponentu a ten hlavní konfig to celé sestaví (případně přepíše některé hodnoty) a vrátí aplikaci.

Taky se bude lépe přepisovat hodnota v hlavním configu (třeba kvůli ručním testům, fuj:), než dohledávat ve kterém includovaném souboru je definovaná, případně ze kterého souboru ta proměnná platí (pokud by se definovala ve více souborech).

Osobně se mi asi nejvíc líbí priorita hlavního konfigu (důvod viz příspěvek od Šamana).

Když už jsme u toho, nezvažuje se možnost includovat soubory pomocí masky? Například

includes:
        - %appDir%/*services.neon

by mohlo vložit všechny služby ze všech modulů…

Editoval norbe (10. 11. 2011 21:14)

V tom případě ale ty údaje v config.neon mít nebudeš a je to ok, ne?

vojtech.dobes napsal(a):

Řešením by bylo neinkludovat v configu, ale v bootstrapu. Pak bych mohl gitignornout hlavní konfigurák…

To mě připadá už zbytečné. Config ve kterém je include by měl mít vyšší prioritu. Pak bych to řešil nějak takto:

$config = __DIR__ . "/environment.neon";
$configurator->loadConfig(file_exists($config) ? $config : NULL);

config.neon

includes:
	- defaultServices.neon
	- defaultParams.neon
	- modules.neon
production:
	database:
		driver:	mysql
		user: app
		database: app

environment.neon

includes:
	- config.neon
production:
	database:
		password: T0pS3cr3t

<OT>Prořád přemýšlím jak by pomocí toho environment.neon šlo určovat sekci, která se má načíst a zapínat / vypínat „development“ laděnku.</OT>

Nevím, co přesně znamená ta defaultní konfigurace, ale pokud to potřebujete, tak si ji inkludnete hned jako první a problém je vyřešen.

Co tohle? :)

Nevím jakto že to tady ještě nikdo nezmínil ale nemělo by to být tak, že pokud vložím konfiguraci na začátek souboru – mohu dále v souboru vloženou konfiguraci změnit?

Pokud chci mít vložené hodnoty „nahoře“ vložím konfiguraci nakonec…

Dělá to tak třeba Apache…

1. Configuration file is parsed top to bottom
2. Included files are parsed right at their include location. In other words within the configuration file.
3. For directives which are called more than once, the last call overrides the previous calls.
4. For a directive called more than once in a directory tree, the lowest call in the directory tree takes precedence.

vojtech.dobes: To se mi nelíbí. Co kdybych chtěl v jednom souboru použít obojí?

includes:
	- someService.neon
	- anotherService.neon

parameters:
	database:
		host: localhost
		username: root
		password: 12345
		database: xyz

includes: # <-- tohle přepíše pův. seznam
	- credentials.neon

Myslím, že ideální bylo přepisování zakázat, čímž by se předešlo různým WTF záležitostem.

Např. Změním v config.neon hodnotu password, ale nic se nestane (protože soubor credentials.neon to heslo přepíše). Správné by bylo, kdyby tam taková hodnota vůbec nebyla, aby to nemohlo nikoho mást.

K predchozi diskusi bych se vyjadril tak, ze (IMHO):

• paklize mam hodnotu v my_included_conf.neon, v main_conf.neon je tato hodnota prepsana (s ohledem na to, ze kdyz uz neco takoveho delam, je to zrejme jen docasne reseni) – hlavni konfiguracni soubor prebiji vse*
• nezalezi na poradi (kdyby ano, je to „Pure WTF™“ – umim si predstavit, jak si nekdo pastne do sveho konfiguraku neco duleziteho, a nevsimne si, ze nechal nejaky jiny dulezity radek nad/pod)

* a kdyz uz by to muselo byt opacne – vetsi vahu by mela specificke konfigurace – musela by zde byt moznost addÜberConfig k prebiti specifictejsich konfiguraku.

A urcite bych se v tomto pripade neinspiroval konfiguraci Apache – precejen nastaveni serveru je pomerne staticke – clovek se v tom az zas tolik nevrta. Na rozdil od nastaveni aplikace, kdy casem pridava nove a nove veci.

Editoval wdolek (19. 11. 2011 18:12)

Rozhodně by include mělo fungovat jako asistované copy&paste. Tzn. vzal by se obsah toho includovaného souboru a vložil by se do inkludujícího. (Jinými slovy – později definované přepisuje dříve definované.)
Přijde mi to jako běžné a logické chování.

Mimochodem, include bych nepovažoval za sekci, ale za něco jako informaci preprocesoru v C.

Koukám, že se tahle diskuse hodně odklonila od původního tématu.

Dneska jsem kamaráda učil základy Nette a z toho způsobu, jak se v čistém Nette píšou presentery, jsem byl značně rozladěný. Pokud chci, aby mi aplikace dodržovala DI, musím si všechny služby v presenteru vytahovat přes zdlouhavé $this->getContext()->getService('...'). Že to z DI kontejneru dělá Service Locator a že mi v takovém momentě nefunguje napovídání v IDE snad netřeba zdůrazňovat.

Presenter by si měl všechny služby, které využívá, vyžádat v konstruktoru podle zásad DI. Napovídání se pak rozeběhne, v blbějších IDE se k privátní proměnné ještě napíše @var typ. Taky získáme přehled o všech závislostech, které presenter má, pokud pominu služby jako HttpRequest, User apod., které jsou k dispozici přes metody v předkovi Nette\Application\UI\Presenter díky contextu.

V config.neon bych vedle pole services navrhoval založit ještě pole presenters:

presenters:
	Front:
		Homepage:
			class: FrontModule\HomepagePresenter
			arguments: [@articlesModel, @user]
		Error:
			class: FrontModule\ErrorPresenter
		Article:
			class FrontModule\ArticlePresenter

Zde by se mohla uplatnit trocha magie – pokud by jméno třídy souhlasilo se současnou konvencí v Nette, class by se mohla vynechat a PresenterFactory by si ji sama odvodila.

Ondřej Mirtes napsal(a):

Presenter by si měl všechny služby, které využívá, vyžádat v konstruktoru podle zásad DI.

To, co navrhuješ, lze realizovat vcelku triviální úpravou PresenterFactory. Problém vidím v předávání služeb přes konstruktor. UI\Presenter využívá HttpRequest, HttpResponce, User, Session, PresenterFactory, Router a templateCacheStorage. To máme 7 parametrů v konstruktoru. Každý potomek tedy musí převzít 7+x parametrů, 7 předat do parent::__construct a ostatní si uložit. Dovedu si představit, že časem projde UI\Presenter refactoringem, počet služeb se sníží případně objeví nějaká nová. A všechny, kdo použijí DI přístup, tak narazí na děsný BC break.

Samozřejmě by se těch 7 služeb mohlo zamést pod jeden Nette\DI\Container, ale to jaksi není DI, že. Eventuálně použít potomka Nette\Application\UI\PresenterContainer, který by alespoň formálně určoval obsah containeru, ale stále je to ServiceLocator.

Rozumnější se mi jeví zavést method setter, takže presentery by místo konstruktoru vytvářeli např. metodu setContext() a v ní specifikovali požadované služby. Tipuju, že taková metoda bude vždy jen přemisťovat argumenty do proměnných objektu, takže by se možná dalo rovnou uvažovat o nějakém property setter. (A předsudky stranou, mezi method setter a property setter je rozdíl jen jako mezi public a protected).

Možná budu za puristu, ale… nemůžu se ubránit dojmu, že tady je prostě prapůvodní problém v tom, že v Nette toho má Presenter na starost příliš mnoho. Troufám si tvrdit, že každá třída, která ke své činnosti potřebuje 7+x dalších instancí, je vážným adeptem k refaktorování… Jenomže to je v tomhle případě asi nereálné, protože to by byl BC break „na druhou“…

Ale kdyby hlavní novinkou Nette 3.0 byl kompletně refaktorovaný návrh plně v duchu SOLID designu, tenhle problém by úplně odpadl. :)

Editoval Tharos (13. 12. 2011 21:37)