Krasný index.php s vylepšeným DI Containerem

Třeba takto by mělo jít volat $configuredAbc = $container->createConfigureAbc($abc);

	factories:
		configureAbc:
			class: Authenticator
			parameters: [service]
			factory: ?(%service%)

Mnohem pěknější řešení než moje naprasené, které ale dalo podnět k řešení problému. Což nic nemění na tom, že se mi tenhle způsob bootstrapování moc a moc líbí :)

Do aplikace mám tři vstupy:

• www/index.php – viz výše, prostě vstup pro uživatele (přes prohlížeč)
• $ app/console – php script, který místo Kdyby\Application\Application spouští úplně stejně Kdyby\Console\Application
• $ phpunit – přes phpunit.xml se načte soubor tests/boostrap.php, který nezapne aplikaci, ale jen vytvoří configurator a zpřístupní container staticky.

Všechny tři využívají app/autoload.php a navzájem si nepřekáží. Kde je problém?

Můj boostrap_cli by tedy byl pouze vyčleněním 4 (slovy čtyř) řádků do samostatného souboru :)

Mně to tedy připadá velice použitelné.

Editoval HosipLan (10. 2. 2012 13:11)

Osobně jsem ze stejného důvodu vyhodil z bootstrap $application->run() a volám ho v index.php . Moje pointa je taková, že pokud vyrábím „servisní skript“ který (z jakéhokoliv důvodu) nechci zabalovat do presenteru (ConsoleModule\NecoPresenter) tak si hodím include na bootstrap a mám nastaveno vše, co potřebuju.

ad $ php index.php module:presenter:action resp. tvoje app/console – imho zbytečné rozdělovat, když stačí přidat CliRouter() ne?

Jinak problém tří bootstrapů řeším momentálně takto:

<?php
// Load default config + configs per developer machine --> with graceful degradation
$configurator->addConfig(__DIR__ . '/config/config.neon');
if($_SERVER['SERVER_NAME'] == 'someproject.com') { // live hosting
    $configurator->addConfig(__DIR__ . '/config/live.neon');
    \Nette\Diagnostics\Debugger::enable('85.13.110.131');
}
elseif($_SERVER['SERVER_NAME'] == 'someproject.animalgroup.cz') { // stage hosting
    $configurator->addConfig(__DIR__ . '/config/stage.neon');
    \Nette\Diagnostics\Debugger::enable(\Nette\Diagnostics\Debugger::DEVELOPMENT);
}
elseif($_SERVER['SERVER_NAME'] == 'someproject.ourci.tld') { // pre-staging environment, it's the one with git installation
    $configurator->addConfig(__DIR__ . '/config/ourci.neon');
    \Nette\Diagnostics\Debugger::enable(\Nette\Diagnostics\Debugger::DEVELOPMENT);
}
elseif($_SERVER['HTTP_HOST'] == 'someproject.ag') { // foglcz's machine
    $configurator->addConfig(__DIR__ . '/config/foglcz.neon');
}
elseif($_SERVER['SERVER_ADMIN'] == 'admin@tomas-cap-pc.RD') { // capino's machine
    $configurator->addConfig(__DIR__ . '/config/capino.neon');
}
?>

-- to je kvůli tomu, že je z principu live/stage/dev, kdy stage = náhled pro klienta a dev = všechny mašiny všech vývojářů (neboť to neděláme na devel serveru, že.)

Hosiplan: Chápu tedy, že moje načítání configů bych přesunul do obou konstruktorů application? Resp. udělal Application Abstract, od kterého by dědila Application a Console\Application? Nechci totiž volat tvoje Kdyby\(Console|Application)\Application (logicky.)

Pak bych měl problém s tím, že abstract neudělám (dependency hell) a tím pádem config loading budu mít ve dvou konstruktorech metodikou ctrl+c a ctrl+v, nebo bych to zabalil do nějaké statické metody (Application::loadConfigs($configurator))

Hrozně bych chtěl mít jeden entry point, který mi vrátí $application, spíše ale $container – což může právě bootstrap.php . Schovávat to do konstruktoru aplikace mi přijde nešikovné..

edit: všechno ostatní, co potřebuju, můžu nastavit v .neon souborech.. Routování, konekce, služby, .. Můj bootstrap by tedy víceméně mohl jen načíst config a vrátit container – v indexu pak:

<?php
$container = require '../app/bootstrap.php';
$container->application->run();
?>

Zatímco v servisním skriptu:

<?php
$container = require '../../app/bootstrap.php';
$dibi = $container->dibi;
// etc.
?>

Editoval ptacek.pavel (12. 2. 2012 14:56)

HosipLan: jsem ještě doeditoval last post – sorry :-)

… každopádně pointa těch configů je, že na každém projektu dělají jiní lidé – tzn. sice všude je (config|live|stage|ourci).neon, ale na některých projektech je inject pouze capino.neon a někde jenom foglcz.neon někde je obojí etc – nejde/nechci to dělat univerzálně v libs/Kdyby/Configurator.php – potřebuju to někde v app.

Nakonec mi přijde, že je to spíš o názvosloví – ty tomu říkáš autoload, já bootstrap což mi přijde logičtější kór když by to jenom vrátilo container :-)

Obecne mi index.php a bootstrap.php tak jak jsou v sandboxu/skeletonu prijde takovy nelogicky. Jaky smysl toto rozdeleni vlastne ma?

Duvod: casta je potreba vice vstupnich bodu do aplikace. Mam to presne tak, jak rikaji @hrach a @hosiplan: 1/ web 2/ konzole 3/ testy. Ve vsech 3 potrebuji mit

Problem: bootstrap neni mozne pouzit samostatne, protoze mu chybi konstanty urcujici cesty k aplikaci (WWW_DIR, APP_DIR, LIBS_DIR) a stejne tak neni znovupouzitelny, protoze okamzite spousti aplikaci. Prijde mi tedy jako takovy jediny vstupni bod do aplikace, kteremu ale neco chybi (to ty cesty).

Reseni od @hosiplan se mi zase moc nelibi, protoze vyzaduje moc kodu „nad Nette“. Mam radeji lehci reseni.

Nejlogictejsi mi prijde reseni, ktere tady zminuje @hrach, kde vsak drobitko zlobi nazvoslovi. bootloader znaci, ze natahuje a spousti aplikaci, coz u nej nedela (lepsi nazev me ale momentalne nenapada).

Jednoduche reseni by znamenalo pouze trosku zamichat index a bootstrap:

• bootstrap by byl samostatny a znovupouzitelny – obsahoval by tedy definice vsech cest, ale primo aplikaci uz by nespoustel. O to by se staral index…
• index by pouze nacetl bootstrap a spustil aplikaci (2 radky);
• konzole jako druhy vstupni bod by se velice podobala indexu – nacetla by bootstrap a spustila si dvoji aplikaci (at uz Nette s CliRouterem, nebo Symfony; opet 2 radky);
• testy by si nacetly bootstrap a delaly si svoje testovani;
• abcxyz neboli jakykoliv dalsi skript/daemon by si nacetl bootstrap a delal by si svoje, treba zustal bezet a komunikoval by si po siti, sledoval servery a tak obecne co by se mu zachtelo.

Rozsirene reseni popsal @hrach, stejne jako predchozi ale vytahuje z bootstrapu cast pro web a pro cli.

Nakonec jsem se priblizil jeste o krok vic k @Hosiplanovi a z bootstrapu jsem vyclenil autoload v takovem tvaru, jako ho ma on. Autoload se stara pouze o to, aby byly vsechny potrebne tridy k dispozici, nic vic nedela.

To už spíš:

bootstrap.php:

<?php

...
return $configurator->createContainer();

a index.php:

<?php
$container = require __DIR__ . '/../bootstrap.php';
$container->application->run();

Nicméně to už je krůček k tomu udělat třídu Bootstrap a pak mít v index.php

<?php
require __DIR__ . '/../bootstrap.php';

$container = Bootstrap::boot();
$container->application->run();

podle mě je to zbytečné protože toho samého lze dosáhnout pomocí Nette\Config\CompilerExtension

Jedno slovo: over-engeneering.

Už já toho mám možná zbytečně moc, ale zase to je krásně ohebné.