Refactoring Environment & Configuration

Ani mě snad nenapadá, co by se ještě dalo vylepšit (krom jemného refaktoringu configuratoru, protože některý nový konstrukce jsou dost psycho, ale zase věřím, že jsou opravdu efektivní, když se dostaly do Nette :)

Všechno na co jsme naříkali teď máme (nepíšu podle priority, ale jak mě to napadá)

• kompletní ignorance k Environment (je vůbec někde ve FW? nebo už je úplně pryč z vnitřností?)
• (vlastní) DI\Container (byť je potřeba ho dědit, za což bude Patrik asi ještě protestovat :)
• (vlastní) DI\ServiceBuilder
• načítání více configů
• konfigurovatelnost služeb (včetně volání metod a expandování %proměnných% a @služeb) i v configu
• „exporter“ configu do PHP do cache

a ještě pár dalších, co mě teď nenapadnou :)

(OT ?) PS.: ještě takový malý feature request, co si myslíte o ArrayAccess na Containeru pro přístup k $params? Zvážíš to, nebo je to hloupost a mám si jít extendnout DI\Container? :)

PS2.: je %database[user]% (tečky vadí kvůli php.ini) za hranicí přijatelnosti magie, nebo to spadá pod YAGNI?

HosipLan napsal(a):

PS.: ještě takový malý feature request, co si myslíte o ArrayAccess na Containeru pro přístup k $params? Zvážíš to, nebo je to hloupost a mám si jít extendnout DI\Container? :)

To pak bude vypadat jako NotORM. Na služby „object access“, na parametry array access. A nikdo neví, proč se co na co používá. A ještě jsme nevyužili __call, jistě k němu taky najdeš nějaké smysluplné využití ;)

HosipLan napsal(a):

(OT ?) PS.: ještě takový malý feature request, co si myslíte o ArrayAccess na Containeru pro přístup k $params?

Magické gettery a ArrayAccess představují velký technický problém, pokud se pracuje s vícerozměrnými poli. Z uživatelského hlediska nevidím žádnou výhodu oproti přístupu k public proměnné.

PS2.: je %database[user]% (tečky vadí kvůli php.ini) za hranicí přijatelnosti magie, nebo to spadá pod YAGNI?

Hranaté závorky jsou divné, možná spíš přes tu tečku (v INI vadí?).

arron napsal(a):

Chtel bych se zatim vyjadrit k tem nazvum prostredi, jak psal Patrik na GitHubu. Nazvy prostredi, jsou VELMI (!) dulezite,

Názvy prostředí a módy byly vždy jen zdrojem nedorozumění, bylo je potřeba nějak předělat. Zatím jsem zkusil je smazat ;-) K čemu konkrétně je používáš? Pokud jde jen o určení sekce v načítaném konfiguráku, jeví se mi lepší explicitní:

Environment::loadConfig(__DIR__ . '/config.neon', 'stage');

Teď mě napadl jeden use-case, který „není ošetřený“. Má někdo lepší nápad jak předat službě celý container? (když těch závislostí má opravdu hodně, já vím bad practices, smelly code, bla bla bla…)

public static function createServiceFoo(IContainer $container)
{
	return new FooService($container); // god class
}

nebo trošku lépe

public static function createServiceFoo(IContainer $container)
{
	$context = new Container;
	$context->addService('bar', $container->bar);
	// ...

	return new FooService($context); // god class
}

V kódu je to OK, ale když už jde (prakticky všechno co je běžně potřeba) nastavit v configu, tak by možná nebylo na škodu, vymyslet řídící znak pro předání containeru službě?

Nebo se považuje za best-practices druhý snippet kódu?

PS: Symfony má na tohle interface IContainerAware (služba co ví o svém containeru, skoro jako námět na horor :D). Při vytváření služby, která implementuje tohle interface (afaik jenom metoda setContainer) se jí během vytváření předá Container automaticky (protože interface).

My máme v aplikaci cca 5 těch sekcí na různé prostředí aplikace, podle toho v jakém stádiu vývoje/testování/produkce se zrovna nachází. Takže fakt to není zbytečné.

(ContainerAwareInterface je jen pro controllery (resp. minimálně byl), interface injection už Symfony DI neobsahuje, neb činil problémy — jen pro upřesnění. .])

Editoval Yrwein (17. 5. 2011 15:42)

Ondřej Mirtes napsal(a):

Takže jak aktuálně v Nette funguje detekce prostředí a načítání jednotlivých sekcí configu? Jak teď zařídím, abych v configu měl sekce pro development/production a autodetekcí se rozhodovalo, která se použije?

// implicitne
Environment::loadConfig();

// explicitne
Environment::loadConfig(__DIR__ . '/config.neon', Environment::isProduction() ? 'production' : 'development');

Lepší možností mi každopádně přijde mít config.ini + config.local.ini, který není verzován a do toho nadřazeného se merguje. Jednotliví vývojáři pak nevidí hesla ostatních a hlavně nevidí hesla na ostrém serveru.

Environment::loadConfig(__DIR__ . '/config.ini');
Environment::loadConfig(__DIR__ . '/config.local.ini');

Honza Marek napsal(a):

Přijde mi, že třída configurator má teď velmi široké pole působnosti. Určitě by měla být rozdělena na něco, co přidává ty defaultní služby a parametry do kontejneru (ContainerExtension / ContainerCompiler / ContainerLoader / ?), načítátko neon souboru (DI\NeonLoader?) a něco, co umí vygenerovat z nějakého ContainerBuilderu zdroják Containeru. Potom by byly jednotlivé DI součástky krásně vyměnitelné a z DI contianeru by šlo dostat cokoliv.

Naprostý souhlas! Nejvíc mě stále a pořád (už jsem to zmiňoval hodněkrát) vadí nutnost dědit Configurator hlavně z důvodu toho že obsahuje továrničky. Mám třeba v plánu vyhodit RobotLoader protože používám PSR-0 loader. Můžu to udělat tak že vyhodím run z configu (ale služba bude pořád existovat). Můžu to udělat i takto $configurator->removeService('robotLoader') ale pořád se mě to nezdá čisté protože existuje továrnička. Mnohem raději bych viděl něco jako DefaultServicesConfigurator a ConfigServicesConfigurator či další (jak už jsem také psal).

David Grudl napsal(a):

Názvy prostředí a módy byly vždy jen zdrojem nedorozumění, bylo je potřeba nějak předělat. Zatím jsem zkusil je smazat ;-) K čemu konkrétně je používáš? Pokud jde jen o určení sekce v načítaném konfiguráku, jeví se mi lepší explicitní:

Environment::loadConfig(__DIR__ . '/config.neon', 'stage');

Tohle řešení je pro mě dostačující. Ve firmě každý máme své prostředí a nastavovat ho potřebujeme.

Ondřej Mirtes napsal(a):

Lepší možností mi každopádně přijde mít config.ini + config.local.ini, který není verzován a do toho nadřazeného se merguje. Jednotliví vývojáři pak nevidí hesla ostatních a hlavně nevidí hesla na ostrém serveru.

Tohle je zajímavé řešení a určitě o něm popřemýšlím. Nicméně napadá mě jeden use case kde by mohl být problém. A tím je přepnutí aplikace do produkčního prostředí na development serveru. Dělá se to těsně před nahozením na ostrý server aby se otestovalo jak to pošlape.

• to co říká xificurk

<OT>BTW: davide kdy jsi sakra spal? :-D</OT>

Edit: a ještě jsem si vzpoměl že by se mě hodilo pár údálostí jako třeba onBeforeLoadConfig a onAfterLoadConfig.

Patrik Votoček napsal(a):
Tohle je zajímavé řešení a určitě o něm popřemýšlím. Nicméně napadá mě jeden use case kde by mohl být problém. A tím je přepnutí aplikace do produkčního prostředí na development serveru. Dělá se to těsně před nahozením na ostrý server aby se otestovalo jak to pošlape.

Jak říká xificurk – my si v configu konfigurujeme celou Laděnku, abychom mohli ovlivnit, co přesně dělá.

parameters:
  debug_strict_mode: false
  debug_production_mode: true
  debug_email: null
  debug_email_snooze: 172800
  debug_log_directory: null
  application_error_presenter: "Front:Error"
  application_catch_exceptions: true

Pozor, je nejdříve potřeba zavolat Debug::enable() a až pak donastavovat tyto parametry.

No ona to principiálně statická věc je, když pracuje s PHP funkcemi jako set_exception_handler apod.

Zkusím to u nás přehodnotit, jak se to chová, pokud Laděnku hned zapnu. Zatím jsem se tomu vyhýbal. Budu ji muset zapnout v produkčním módu, pro případ, že by se ta chyba stala na ostrém serveru. Ale bílá stránka na vývojářském stroji bude WTF. Chyba se nám stává často, protože Laděnku konfigurujeme až na základě parametrů kontejneru, které načítáme z YAMLu a ten je dost náchylný na překlepy.

A aktualizoval jsi z čeho na co?

Aktuální DI je v Nette hodně čerstvá věc a spousta lidí si ji teprve osahává a zkoumá jak nejlépe na to takže je těžké rovnou něco sepisovat.

Pak taky předpokládám že základní vysvětlení bude součástí nové české dokumentace která bude spuštěna 1.6.

Ty různý contexty mě taky dost matou, možná trochu naivně bych čekal, že když něco nadefinuju v configu, bude to v contextu dostupný… Mluvím hlavně o službách a parametrech, pokud je možnost nahradit třídu frameworku (Router, User, Application…) svojí implementací, chci, aby to tak bylo v celé aplikaci. Zkrátka, od configu čekám, že bude dostupný všude a bez výjimky.

Jako že žádám něco, co už je, a nebo něco, co není ideologicky přípustné? :)

Nevím, jestli je to uplně ideální téma, kde položit tento dotaz … každopádně, už mne přestalo bavit učení na maturitu a chtěl jsem si zaprokrastinovat, tak jsem updatl u svého jednoho projektu Nette. Témata o DI atd jsem sledoval jedním okem, každopádně – nyní mi hlásí nette „InvalidStateException“, protože nezná environment variable „baseUri“ [dostával sem se k ní přes Environment::getVariable("baseUri")].

Jak se k této proměnné nyní dostat/čím byla nahrazena? Zkoušel jsem hledat a nenašel jsem.