Jak se mimo bootstrap dostanu k configu bez Nette\Environment?

Pouzivam posleni verzi samozrejme… ale proste pokud jsem spravne procet zdrojak Nette\Configurator, tak konfigurace se nacte, zpracuje, nastavi se podle ni sluzby a pak uz zustane jen ulozena v tomhle globalnim configuratoru – ke kteremu se napriklad z presenteru uz nedostanu jinak, nez pres Environment::getConfigurator()… a jeste navic pokud chci pouzivat debugger, tak uz v bootstrapu musim pouzit Environment::getConfigurator() misto new Nette\Configurator(), jinak ma v sobe Environment ulozenej prazdnej (nenakonfigurovanej) Configurator a prazdnej Context ktery si vytvari v tom Debuggeru… zkratka: jestli framework nikde Environment nepouziva, proc ho pouziva Debugger? Tohle je celkem neintuitivni a je to podle me navic spatne napsany v Sandboxu (tam je v bootstrapu konstrukce s new). A pak se k tomu configu uz proste nedostanu nikde jinde… :o/ pokud teda nechci pouzit Environment – a to ja nechci, DI je ubercool :o)

Muj problem je ze ne vsechno co potrebuju konfigurovat je sluzba – takze je semantickej nesmysl to jako sluzbu definovat v configu, aby se tomu kontext a konfigurace vytvarely diky DI automaticky. A tak si rikam, ze by se mi libilo neco jako:

common:
  ...
  context:
    mujModel:
      var1: val1
      var2: val2

    mojeKomponenta:
      var3: val3
      var4: val4

    necoJinyho:
      var2345: val2345

  ...

a pak bych mohl nejak pri vytvareni contextu (containeru) pro nejakej objekt do toho kontejneru nasypat prislusnou sekci treba takhle:

...
$container = new DI\Container;
$container->params = $this->context->getContextConfig('mojeKomponenta');
...

Proc by mi nestacilo jenom $this->context->getConfig()? Protoze by se to mohlo takhle obecne koukat do configu kamkoliv – napriklad i na hesla do db – coz neni dobry napriklad kdyz chci nechat aplikaci otevrenou pro 3rd-party komponenty; proto bych rek, ze by bylo hezky mit pres takovouhle funkci pristupnou nejakou jasne omezenou cast configu. Pak by treba tyhle konfiguracni sekce mohly jit jeste vnorovat, takze kdyz si pak komponenta pri vytvareni subkomponenty zavola $this->context->getContextConfig('sadf'), ma zase pristup jenom k podsekcim svoji vlastni konfigurace…

No, je to asi docela neucesany pokud jde o nazvoslovi, ale pokud se to ideove uchyti, urcite neco vymyslime :o)

EDIT: napada me, ze by se ty metody mohly jmenovat treba spis getSubcontext() nebo getSubcontextConfig()… protoze $context->getContextConfig() zni jako ze se to vztahuje k tomu kontextu na kterym to volam, ja ale spis chci pristoupit k jeho pod-kontextu…

Editoval danik (15. 6. 2011 22:01)