[2011–12–12] Přechod na nový Configurator v poslední verzi

Neměl by se config soubor v sandboxu jemnovat trochu jinak?
Varianty:

• app/config/app.neon
• app/config/main.neon
• app/config/default.neon

David Grudl napsal(a):

To, co je popsané v dokumentaci DI, by mělo fungovat. Taky Configurator vytváří statický kontejner. Ale nejspíš nerozumím otázce.

Asi jsem se špatně vyjádřil. Dříve jsem si podědil Nette\DI\Container, přidal vlastní služby a v bootstrap ho předal konstruktorem configuratoru. Teď když koukám do třídy Configurator, nevidím způsob, jak mu předat vlastní container. Asi jen ale nechápu širší souvislosti.

@HosipLan: A proč bad practise? Totéž přece udělá configurator, jen nad tím mám menší kontrolu. Taky se programátor musí (více) učit další syntax (config). Osobně raději aplikace programuju, než konfiguruju a služby a továrny mi fakt přijdou logický spíš v kódu. Připouštím ale, že nevidím tak daleko, jak asi vidíte vy. :-P Každopádně mi popsaný způsob vyhovoval daleko víc.

HosipLan napsal(a):

@**Fanda** určitě chtěl mít vlastní protected function createServiceMyService metody v containeru místo v configu.

Tak jsem to myslel. Děkuji, že mi rozumíš. :-) Vidím, že nette jde cestou konfigurování, tak se přizpůsobím. Samotné konfigurování mi tak moc problém nedělá, spíš ideově nesouhlasím. :-)

Máš v loadConfig přístupný public ContainerBuilder::$parameters, který se expanduje do Containeru. Zkusil bych to tudy.

API CompilerExtension není definitivní, nicméně je to poslední věc, do které plánuju v DI případně zasahovat.

Poznámka ke config.neon ze sandboxu, PostgreSQL a DiscoveryReflection:
https://forum.nette.org/…ryreflection#…

Ano, je to tak, proti této vlastnosti byla řada námitek.

pokud jsem to dobře pochopil nelze definovat factory a službu se stejným jménem

Je to kvůli jednoduchosti konfigurace, aby se na obojí dalo odkazovat přes @name a nedocházelo ke konfliktům.

Use case: chci na něco mít továrničku a zároveň chci mít možnost výchozí služby

Nazvi službu defaultFoo. Asi cítíš, že není úplně ok, pokud $container->createFoo() a $container->getFoo() vrací něco jiného, zatímco $container->getDefaultFoo() je srozumitelné. (jasně, container má getService).

Kód nahoře mě přivádí k další otázce: Používám dobře prefix? Nikde jsem nenašel jeho využití.

Ano, ale chybí prefix u setFactory a špatně je zapsán setClass a setParameters. Lépe by bylo takto:

		$foo = $container->addDefinition($this->prefix('foo'))
			->setClass('Foo', array('%arg1%', '%arg2%'))
			->setParameters(array('arg1', 'arg2' => NULL));

		$container->addDefinition($this->prefix('defaultFoo'))
			->setClass('Foo') // tohle by se asi dalo vynechat
			->setFactory($foo, array($bar, '%config%'));

A poslení otázka může mít továrnička definovanou factory? (vzásadě by to byl alias pro někde hluboko zanořenou továrničku mimo kontainer)

Nerozumím. Továrnička = factory in english.

Přesně tak.

Použij $ext->prefix('@foo');

Mám takovou potíž s DI kontejnerem. Jde o to, že do hotového containeru se při přidání služby do property $classes kontejneru sám nepřidá záznam spojující interface=>název služby. Což pak samozřejmě vyhodí new MissingServiceException("Service of type $class not found."), pokud volám $presenter->user->login(). Samozřejmě moje řešení je buď přidat ten název ručně, jak je uvedeno v 1) nebo přidat authenticatora do user pomocí 2)

Mě tedy spíš zajímá, jestli by nestálo (a bylo by to správně) za to při přidání služby pomocí addservice či __set aktualizovat $classes automaticky.

Pozn. funkci reset se nelíbí, že dostává hodnotu, navíc jsem neřešil, když třída impl. víc inerfaces.

$cfg = new Nette\Configurator();
$cfg->tempDirectory = $tmp;
$cont = $cfg->createContainer();
$name='authenticator';
$svc = new SimpleAuthenticator(array('admin' => 'pepa123'));
$cont->addService($name, $svc);
//1 tohle musím zařídit ručně
$cont->classes[strtolower(reset(class_implements($svc)))]=$name;
//nebo 2)
$cont->user->authenticator = $svc;

David Grudl napsal(a):

		$foo = $container->addDefinition($this->prefix('foo'))
			->setClass('Foo', array('%arg1%', '%arg2%'))
			->setParameters(array('arg1', 'arg2' => NULL));

		$container->addDefinition($this->prefix('defaultFoo'))
			->setClass('Foo') // tohle by se asi dalo vynechat
			->setFactory($foo, array($bar, '%config%'));

Tak jsem se dneska dostal k tomu abych to použil a ejhle. Nelíbí se mu to $foo predavane jako prvni parametr setFactory.

Warning
implode(): Invalid arguments passed

Nette/DI/ContainerBuilder.php:453

} elseif (!Validators::isList($entity) || count($entity) !== 2) {
	throw new Nette\InvalidStateException("Expected class, method or property, " . implode('::', $entity) . " given.");

Pokud ->setFactory($foo, array($bar, '%config%')); přepíšu na ->setFactory('@container::create' . ucfirst($this->prefix('foo')), array($bar, '%config%'));. Tak to funguje jak má.

Proki napsal(a):

…Proto se chci zeptat, zda existuje nějaký novější a v budoucnu podporovaný přístup, jak se dostat k těmto parametrům. Nebo je to obecně chyba a presentery na tyto parametry šahat nemají?

Zatím neexistuje, označení deprecated zruším.

Davide, prosim dopis do kucharky jeste co udelat, kdyz mam vlastni tridu s hromadou createServiceX metod a chci je vsechny zaregistrovat ;)

juzna.cz napsal(a):

Proc je nutne vytvaret RobotLoader „rucne“ a nejde to uz delat v configu? Zvlaste kdyz bych chtel mit adresare pro loading zavisle na projektu a tudiz je mit nejlepe v configu

Můžeš klidně RobotLoader vytvořit jako službu v configu. Jen musíš zajistit, aby při generování SystemContainer z configu byly k dispozici všechny potřebné třídy.

Tak jsem docela rozhozen novými změnami, kdy mi vše přestalo fungovat a ať se snažím najít cokoli, tak nikde o nové vezi nic moc není. Používal jsem modelLoader a DibiConnection neb mi Nette\Database přijde poněkud omezená.

V config.neon jsem měl:

<script>
common:
    php:
        date.timezone: Europe/Prague

    #parametry pro připojení k databázi
    database:
        hostname: localhost
        username: jarda
        password: sleva
        database: mydb
        charset: utf8
        profiler: TRUE

    services:
        database:
            class: DibiConnection
            arguments: [%database%]
        modelLoader:
            class: ModelLoader
            arguments: [@container]
</script>

Můžete mi někdo říci jak toto zapsat novým způsobem? Pokaždé skončím u vyjímky: „Found sections ‚database‘, ‚models‘ in configuration, but corresponding extensions are missing.“ Každopádně robotloader je najde, v cache souboru vidět jsou…

Zkoušel jsem všechno možné, ale spíš zabředávám do větších a větších konstrukcí, které nikam nevedou :-(

Patrik Votoček napsal(a):

Musíš si udělat vlastní Nette\Config\CompilerExtension a udělat si metodu Nette\Config\CompilerExtension::afterCompile.

	$class->addExtend('MySuperExtraContainer');

Zkoušel jsem postup, který popisuješ, ale vygeneruje mi to následující kód, což je syntax error:

class SystemContainer extends Nette\DI\Container, \Containers\MySuperExtraContainer

Jaký má smysl metoda addExtend, kdyz PHP nema vicenasobnou dedicnost? Neměla by místo metody addExtend spise existovat metoda setExtends?

Edit:
Tak jsem to obesel takto:

$class->extends = array('\Containers\DatabaseContainer');

Plus jeste v closure nefunguje new static, takze je treba predat instanci z vnejsku pomoci use. (to je srandy takhle po ranu :-))

Editoval Elijen (11. 2. 2012 3:05)

HosipLan napsal(a):

Jelikož ClassType je obecně pro třídy i interfacy, tak to smysl má ;)

PS: tfuj :P

$configurator->addParameters(array('container' => array(
	'parent' => 'Containers\DatabaseContainer'
)));

Nj par minut po tom, co jsem to postnul jsem videl Daviduv prispevek:

parameters:
	container:
		parent: Containers\DatabaseContainer

a za dalsich par minut, jsem zjistil, ze to pujde udelat jeste lip bez vlastniho containeru pouze tovarnickama :-D

V NEONu takto:

parameters:
	foo: true

Při předání nějaké službě v NEONu takto:

services:
	FooService:
		factory: \Model\FooService( %foo% )

V presenteru takto:

$this->context->parameters['foo'];`

Hned na instanci $containeru.

$container = $configurator->createContainer();
$foo = $container->parameters['foo'];

$container === $presenter->context