Diskuse o vícenásobném načítání konfigů

Schmutzka: NotORM by teď mělo jít použít třeba i takto:

	services:
		notorm: NotORM(PDO('mysql:host=localhost;dbname=database', user, pass))

Je nekde popsana funkcnost a pouziti v praxi onoho FactoryLoader? Diky

@uestla:
moc nad tim spekulujes

1. predat reflection do contructoru connection muzes bez i bez nastaveni setConnection danemu reflection, connection se k reflection pribinduje sam
2. vcera bylo mj. pushnuto, ze connection ma metodu setDatabaseReflection, tedy muze byt predano pozdeji, akorat se vytvori automaticky conventionalreflection. a opet i v tomto pripade plati, ze se connection pribinduje (lepsi termin asi spis injectne) sam.

uestla napsal(a):

Chci-li nastavit v setup nějakého servicu jiný service, který zatím nebyl vytvořen, ale sám onu první službu používá, jde tohoto nějak docílit?

V tomto případě není potřeba mít dbReflection jako službu, takže stačí jako 4. argument uvést Nette\Database\Reflection\DiscoveredReflection() (tj. vytvoření nového objektu). Pokud bych to jako službu mít chtěl a pomineme-li, jak píše hrach, že setConnection se volá automaticky, lze zapsat:

services:
 	database:
 			class: Nette\Database\Connection(...)
 			setup:
				- @dbReflection::setConnection(@database)

Tedy v setup může být volání metody i jiné služby a jako argument lze předat sebe.

To není bug, sekce skutečně lze používat jen v primárním a nikoliv inkludovaném konfiguráku. Použití sekcí unvitř inkludovaného souboru by vedli k „diamond“ problému podobnému vícenásobné dědičnosti.

Současné chování includes mi přijde taky hodně matoucí a nepraktické. Chtěl jsem includes použít pro vložení neverzovaného lokálního konfiguračního souboru a nešlo to, protože includovat se dá jen v sekcích a ty sekce jsou prý potřeba vždy.

Zhruba takhle by v současném Nette vypadal konfigurák, který by dělal to co chci:

common:
    includes:
        - config.common.local.neon
production < common:
development < common:
    includes:
        - config.development.local.neon
console < common:
    includes:
        - config.console.local.neon

Přijde mi, že to hodně komplikují ty sekce. Stejné problémy by dokázalo vyřešit přímočařeji načtení více konfiguračních souborů. Jeden hlavní a druhý, který přepisuje nějakou lokální nebo testovací konfiguraci. Pak by includes nebylo v sekci, protože by žádná sekce nebyla :)

Je to v tom úplně prvním příspěvku: Pokud použijete loadConfig('soubor.cosi', FALSE), sekce se používat nebudou. Máte-li pocit, že by sekce a include mělo fungovat jinak, jsem přístupný jakékoliv změně, ale zkuste si to předem důkladně promyslet – podle mého je to mission impossible.

Honza Marek wrote:

… použít pro vložení neverzovaného lokálního konfiguračního souboru …

pekelnik wrote:
bootstrap.php

<?php
$configurator->loadConfig(array(
	'%configDir%/config.neon',
	'%configDir%/config.local.neon',
	));
?>

Super pani, kombinaciou tychto dvoch veci, teda includovanie lokalnej verzie neon a zaroven jej neverziovania sa da krasne poriesit vsetko, co som doteraz v configu elegantne riesit nevedel.

Možnost načítat více souborů je věc, po které existuje poptávka už hodně dlouho (od první zmínky uplynulo skoro 2 a půl roku). Naposledy jsem se o ní (na Davidovu žádost) rozepsal v červnu (use case a návrh řešení included).

„includes“ jsou sice pěkná věc, ale pokud se Honza Marek nemýlí, tak na řešení té jediné věci, kterou jsem chtěl, aby dobře řešili, nejsou vhodné.

Pokud bude ale vícenásobné volání loadConfig fungovat stejně dobře, jako doposud, tak to asi není prioritní řešit.

Editoval Jan Tvrdík (16. 12. 2011 14:40)

Více konfiguračních souborů v Nette jednoduše takhle:

V příkladu nejsou záměrně použity tzv. „sekce“, protože se domnívám, že problém, který se snaží řešit, se v praxi řeší jinak – načtením více konfiguračních souborů.

Některé konfigurační soubory nemusí být vůbec verzovány a mohou sloužit jako tzv. lokální konfigurační soubory specifické pro daný stroj. Takhle se to používá jak na serverech, na kterých jsou aplikace nasazany a správce nemá zájem heslo do produkční databáze komukoliv dávat, tak na vývojářských stanicích kde pro změnu není zájem sdílet mnoho lokálních konfigurací s celým týmem.

bootstrap.php

<?php
$configurator->loadConfig(__DIR__ . '/config.neon', FALSE);
?>

Nastavením druhého parametru na FALSE dojde ke zrušení dělení konfigurace na sekce common, production, development a console – což je výchozí chování, které se v praxi ale ukazuje jako nevyhovující například kvůli zmíněnému problému „production console vs. development console“.

config.neon

includes:
	- config.local.neon
parameters:
	database: [driver: mysql, host: localhost, dbname: test, user: '***', password: '***']
php:
	date.timezone: Europe/Prague
services:
	database:
		class: Nette\Database\Connection
		arguments: ['%database.driver%:host=%database.host%;dbname=%database.dbname%', %database.user%, %database.password%, ..., Nette\Database\Reflection\DiscoveredReflection()]
		setup:
			- setCacheStorage()

config.local.neon

php:
	date.timezone: Europe/Paris
parameters:
        database: [driver: mysql, host: localhost, dbname: test, user: '***', password: '***']

Editoval pekelnik (16. 12. 2011 20:20)

Míchají se tu hrušky s jablkama.

1. rozdělení konfigurace do více souborů je možné pomocí sekce includes v načítaném konfiguráku. I každý z takto načtených souborů může mít další includes a načítané soubory mohou být dokonce v různém formátu. Nicméně třeba pro konfiguraci služeb je NEON mnohem šikovnější než PHP/INI/XML/YAML.
2. sekce jsou historická záležitost, co umožňovala udržovat více konfigurací v jednom souboru a neopakovat stejné údaje. V tuto chvíli jsou kvůli kompatibilitě defaultní a vypínají se přes FALSE. Změnit se to může, vymyslete jak.
3. console production/development platí co stejné co pro sekce.
4. vícenásobné volání loadConfig rozhodně možné není, předat mu jako argument pole taktéž ne. Implementovat by to bylo triviální, ale připadá mi to jako duplicita k includes. Byť obojí má své výhody a nevýhody.
5. sekce + includes lze používat dohromady, s tím, že includes zapíšeme do common, protože sekce se zpracovávají dřív než includes. V inkludovaných souborech se už sekce nepoužívají. Žádnou komplikaci v tom nevidím.

Tak jo tu to je https://github.com/…tte/pull/427

David Grudl napsal(a):

4. vícenásobné volání loadConfig rozhodně možné není, předat mu jako argument pole taktéž ne. Implementovat by to bylo triviální, ale připadá mi to jako duplicita k includes. Byť obojí má své výhody a nevýhody.

Rád bych načítal všechny .neon soubory, které mi najde Nette Finder. Přimlouvám se tedy k implementaci loadConfig(array). Jaké výhody má includes oproti vícenásobnému volání loadConfig?

Vícenásobné volání (které jistou dobu „omylem“ funguje) nedokáže některé věci řešit. Spolehlivé řešení je povolit loadConfig(array(...)) nebo použít nějakou formu include resp. extends. Při povolení loadConfig(array(...)) přijdeš o možnost určit, že něco sekce má a něco nemá.

Výhoda sekcí oproti více souborům (což považuji za pěkný nápad) je, že v případě krátkých konfiguračních souborů je všechno na jednom místě. Samostatné soubory mi přijdou praktičtější v případě rozsáhlejších aplikací.

@hrach:

Řeší. Výsledná konfigurace se uloží do jednoho souboru. (Klíčem cache jsou totiž mimo jiné parametry loadConfig.)

@hrach: +1 pro tvůj návrh řešení, snad tam není nějaký fatální problém. Skutečnost, že loadConfig vrací systémový kontejner je skutečně trochu podivná. Možná místo createContainer volat getContainer, který by v případě neexistence containeru zavolal privatní createContainer.

Já bych šel do extrému.

Nemyslím si, že nějaké loadConfig je vůbec potřeba volat. Na všechno by mohla stačit současná implementace include + dohledávání configu pro prostředí v jedné složce.

Pokud by někdo potřeboval něco jiného, podědil by si Configurator

class MyConfigurator extends Nette\Config\Configurator
{
	protected function getConfigFile($params)
	{
		return $params['appDir'] . '/config/config_' . $params['environment'] . '.neon';
	}
}

$configurator = new MyConfigurator();
$container = $configurator->getContainer(); // volá createContainer()

$container->application->run();

viz: https://github.com/…r/app/config

Samozřejmě se zachováním zpětné kompatibility, protože na metodu loadConfig by nebyla potřeba sahat.

Souhlas, loadConfig() vracející kontejner se mi nelíbí. Nelíbí se mi ani to FALSE. Co to udělat tak, že 1× loadConfig použije standardně sekce, vícekrát loadConfig bude bez sekcí? Blbost…

BTW, nelíbí se mi ani setCacheDirectory() pro tempDir, což taky si nejsem jist jak změnit, viz https://github.com/…tte/pull/426

David Grudl napsal(a):

Souhlas, loadConfig() vracející kontejner se mi nelíbí.

Z estetického hlediska bych se spokojil s tím, kdyby metoda createContainer byla public. Používal bych tu.

+1

Hlavně je to WTF magie.

Vícenásobné načítání přes addConfig() implementované už je.

Uvažuju nad tím, že bych zrušil sekci includes.

Jsem pro :))

Incluses bych rád používal, připadá mi to super.
Odděluje to logiku presenteru (aplikace) od logiky configu.
Když rozdělím config na dva soubory (třeba se mi rozrůstá některá sekce, tak ji vyčlením vlastní soubor), tak mi připadá lepší tuto změnu zavést jen do configu a nesahat do bootstrapu.

Vícenásobné načítání je taky dobré, ale spíš pro jiný případ – třeba při existenci config.local.neon přepíše lokalní nastavení ta předchozí. To už je aplikační logika, je to nějaké naprogramované chování a do .php souboru patří.

Při použití include configu by se ale klidně mohla vyhazovat výjimka v případě, že se snažím několikanásobně (duplikovaně) nastavit nějaké údaje. Je to podle mě chyba, stejně jako několik tříd stejného jména. Vzniká problém s prioritou a tak..

Při několikásobném načítání je jasné, že později zavolaný má prioritu a přepíše dřívější nastavení.