Předávání dalších služeb do své implementace Application

Delas tam presne to, co jsem tu popisoval, ze mi prijde jako prasarna :-D Tohle reseni je ve stavajicim stavu velmi primocare, ale jednak duplikujes kod (coz jak vsichni vime je velmi nedobře) a jednak kdyz se zmeni implementace teto funkce v Nette (napriklad se prida nastavovani nejakeho dalsiho parametru), tak to odhalis jen v pripade, ze sledujes commit logy. Jinak se Ti nejspis aplikace zacne chovat prapodivne z neznameho duvodu:-)

Co potrebuju udelat je ve sve Application zaregistrovat nektere dalsi sluzby, jejich konfiguraci nacitam z databaze. Zaroven tam nacitam z databaze routy. Na oboji by se dala napsat nejaka zvlastni trida a delat to v bootstrapu, ale jedna to tam podle me nepatri, a jednak je to proste soucasti te aplikace, takze poděděni a uprava Application se mi jevi z hlediska navrhu jako nejlepsi volba. Z toho vyplyva, ze potrebuju do sve Application predat minimalne nektere modely pro pristup k datum, ze kterych pak uvedene veci builduju. Nehlede na to, ze bych nové sluzby potreboval pridavat do globalniho containeru. Coz by se asi dalo obejit pomoci Container::$instance…mno asi to nebude uplne nejcistci reseni, ale bude to primerene ciste a funkcni :-) Takze asi zatim vyreseno :-D

Nepřipadá mi to jako prasárna.

1. nejde to jinak
2. sleduji changelog Nette docela podrobně

To jsem chtěl vědět :) Řešil bych to asi takto nějak. Popř by se dal ještě upravit (čti: podědit a přiohnout) Configurator, aby tuto službu využíval přímo, nikoliv pomocí configu, což by bylo čistější.

services:
	applicationSetupper:
		class: MyApplicationSetup
		arguments: [@connection]
		methods:
			- {'install', [@container]}
		tags: ['run']

class MyApplicationSetup extends Nette\Object
{
	public function __construct($connection) {}
	public function install(Nette\DI\Container $container)
	{
		// služby
		foreach ($this->connection->select('*')->from(...
			$container->addService(...

		// routy
		$router = new RouteList;
		foreach ($this->connection->select('*')->from(...
			$router[] = new Route(...
		$container->removeService('router'); // nutné udělat před vytvořením služby application
		$container->addService('router', $router);
	}
}

Editoval HosipLan (22. 7. 2011 9:26)

@HosipLan: Zrovna na to koukám. Ale to přece nijak zásadně nevadí, stačí mít svou vlastní MyApplication (kterou autor dotazu podle všeho už beztak má) a použít de facto ještě jednodušší konstrukci:

<?php

class MyConfigurator extends Nette\Configurator
{
	public static function createServiceApplication(Nette\DI\Container $container, array $options = NULL)
	{
		$application = parent::createServiceApplication($container, $options);
		//$application instanceof MyApplication === true

		// MyApplication::addServiceIntoContext je programátorem dopsaná public metoda
		$application->addServiceIntoContext('cacheJournal', function() use ($container) {
			return $container->cacheJournal;
		});
		return $application;
	}
}

Samozřejmě je pak zapotřebí nakonfigurovat aplikaci tak, aby se v továrně vytvářela instance MyApplication.

Přijde mi to jako čisté a stručné řešení bez potřeby opakování kódu.

Editoval Tharos (22. 7. 2011 13:10)

$application->context->freeze() ale právě díky protected nikdo zvenčí nezavolá.

Aby to mé řešení přestalo fungovat, musel by kontext zmrazit vyloženě David v nějaké další verzi Nette ve výchozí createServiceApplication. Jiné (v úvahu připadající) nebezpečí tam není.

Plus mám výhradu k té „konfiguraci služby po jejím vytvoření“. :) Já ten kontext nekonfiguruji až po vytvoření služby. Službu lze IMHO považovat za vytvořenou až v momentě, kdy ji vrátí tovární metoda (hlavně pak v Nette, kde se to setter injections jen hemží).

Jsem toho názoru, že mezi vytvoření služby a vytvoření instance, která službu ve výsledku reprezentuje, nepatří rovnítko.

Ale necháme to plavat, handrkovali bychom se kvůli blbostem. :)

Editoval Tharos (22. 7. 2011 13:09)

Tohle je ale něco úplně jiného, než $application->context->freeze(). Tohle v první řadě není zvenčí (psal jsem zvenčí, čímž jsem samozřejmě myslel mimo továrničku a mimo třídu Application). Tohle nepovažuji za nebezpečí v úvahu připadající :) (proč by to někdo dělal? Tohle přece nelze udělat ani v dobré víře). Proč by někdo psal následující továrničku?

public static function createServiceApplication(Nette\DI\Container $container, array $options = NULL)
{
	$application = parent::createServiceApplication($container, $options);
	$context = new Container;
	//$context->addService(...);
	$context->freeze();
	return new Application($context);
}

Podobnými postupy může pochopitelně jakýkoliv programátor kdykoliv shodit celý běh aplikace, v tom máš samozřejmě pravdu. :)

Editoval Tharos (22. 7. 2011 14:02)

@arron: V té mé verzi se ale ten kontext nezahazuje, jen se zpřístupňuje pro přidávání služeb zvenčí a ty se pak do něj v té továrničce z hlavního kontejneru předávají. Ale už se v tomto vláknu odmlčuji, protože mé řešení nebylo shledáno hezkým :).

Editoval Tharos (22. 7. 2011 22:05)

Mno, tak jsem se k tomuhle problemu zase vratil. Cele navrzene reseni je sice hrozne pekne, ale chybi tomu jedna malinkata drobnost:-) Kde reknu, ze misto ´Nette\Application\Application` chci vytvorit napr. My\Application, ha?

Protoze mit v configu tohle:

services:
    application:
      options:
        class: \My\Application

nema sanci probehnout, protoze sluzby se v Configuratoru vytvareji jeste pred nacteni configu :-)

Zkusím přeformulovat otázku:-)

Co mám napsat do config.neon, aby se mi vytvorila Application jako instance tridy MyApplication, ktera od té původní dědí?

Tak ja mam o neco starsi…vyzkousim, diky moc

Mělo by Ti pomoci následující nastavení v config.neonu:

services:
	application:
		option: [class: MyApplication]

Pokud jde skutečně jen o použití vlastní třídy odvozené od Application, není vůbec zapotřebí vyrábět si kvůli tomu vlastní konfigurátor či provádět nějaké jiné čáry máry :).

EDIT: Teď ale koukám, že přesně tohle řešení už jsi zmínil. V čem konkrétně je problém? :) Vyzkoušel jsem to pro jistotu v sandboxu a samozřejmě to funguje.

EDIT 2: Už možná tuším, v čem je problém. Pozor na to, že v konfigurátoru se v té části, na kterou odkazuješ, neinstancují (fuj, hrozné slovo) služby, nýbrž se pouze do kontejneru registrují callbacky pro jejich instanciování (nevíte někdo, jak se tahle hrůza skloňuje?). Tyto „tovární metody“ přijímají parametry, které lze dospecifikovat až v config.neonu. Proto není k jejich definici „až“ v config.neonu pozdě. Tohle by mělo být to nedorozumění. Instance té Application třídy se vytváří skutečně až v bootstrapu někde na konci, tzn. v době, kdy kontejner už v sobě má patřičnou tovární metodu (používající třídu konfigurátor) a zná i její parametry nadefinované v config.neonu (a skrze ně ví, jakou třídu má vlastně instanciovat).

Editoval Tharos (31. 8. 2011 23:47)

Já u sebe parametr, který jsem předal pomocí config.neonu, zkompilovaný v cache mám:

// výňatek z cache _Nette.Configurator

$container->addService('application', function($container) {
	$service = call_user_func(
		array ( 0 => 'Nette\\Configurator', 1 => 'createServiceapplication', ),
		$container,
		array ( 'class' => 'MyApplication', )
	);
	return $service;
}, NULL);

Že by došlo na obligátní radu „zkus vyčistit cache“? :)

Option a options je častá chyba, nicméně když jsem navrhoval sjednocení (jako u variable(s) nebo service(s)), tak to vypadá, že option bude do budoucna odstraněno.

$context je pouze DI\Container. Application jej používá mám dojem čistě z pohodlnosti, není třeba předávat všechny potřebné služby ručně. K takovému hromadnému předání je použit DI\Container, ale není to ten systémový (který používá i klientský kód), protože je zbytečné ho do Application předávat, když je jasné, které služby Application potřebuje. Vysvětlil jsem to srozumitelně?

(například nemá smysl do Application předávat DI\Container se službou dibi, kterou si někdo nadefinuje v config.neon)

Editoval vojtech.dobes (7. 12. 2011 14:29)