Rozdělení aplikace do composer knihoven

MiskynsCZ

Zdravím,

chtěl jsem se zeptat zda-li nemáte nějaký tip, jak rozdělit určité části aplikace (které se opakují i v jiných mých aplikací) do samotných composer balíčků. Většinou se opakují stejné Presentery, Modely/Entity a nějaké ty Services.

Hledal jsem snad všude možně, ale nemohl jsem nic najít.

Předem mockrát děkuji za informaci!

ZahorskyJan

Je to dost komplexní téma. Základem je mít v každém balíčku CompilerExtension, kterou po instalaci balíčku jednoduše zaregistruješ v config.neon v sekci extensions.

Ta extension pak může do aplikace přidávat např. PresenterMapping, překlady, vlastní config nebo třeba entity, pokud používáš třeba Doctrine.

Dokud nepotřebuješ na projektu nic modifikovat, co máš v balíčku, tak je to v pohodě. Legrace začíná, když chceš entitu na projektu o něco rozšířit. U služeb je to celkem jednoduché, dají se přepsat na projektu tím, že na projektu zaregistruješ jinou pod stejným klíčem.

To jsem nastínil jen takový základ témat, na které člověk narazí.

Marek Bartoš

Základem je mít v každém balíčku CompilerExtension, kterou po instalaci balíčku jednoduše zaregistruješ v config.neon v sekci extensions

A hned sis to zbytečně zkomplikoval. Stačí neon soubor, který přidáš v bootstrapu. Je mnohem flexibilnější – můžeš v něm konfigurovat extensions, aniž by měly nějaký extra interface. Extension přidáš jen na věci, na které je skutečně třeba.

ZahorskyJan

Marek Bartoš napsal(a):

Základem je mít v každém balíčku CompilerExtension, kterou po instalaci balíčku jednoduše zaregistruješ v config.neon v sekci extensions

A hned sis to zbytečně zkomplikoval. Stačí neon soubor, který přidáš v bootstrapu. Je mnohem flexibilnější – můžeš v něm konfigurovat extensions, aniž by měly nějaký extra interface. Extension přidáš jen na věci, na které je skutečně třeba.

Chápu, ale jak jsem psal hned na začátku, je to dost komplexní téma. Šli jsme tou cestou, protože jsme u všech modulů, které registrují entity, chtěli od začátku zajistit možnost entity přepsat na projektu nebo přeregistrovat služby nebo presentery na specifičtější implementaci.

btw. bootstrap máme taky v balíčku, takže tam bych nic nepřidal :-)

Editoval ZahorskyJan (16. 10. 15:11)

Marek Bartoš

zajistit možnost entity přepsat na projektu

Tomu je lepší se vyhnout a raději řešit navazující entitou. Ono se snadno může stát, že např. pro produkt v eshopu mohou být dva nezávislé rozšířující moduly a pak není cesta, jak entitu podědit v obou.

bootstrap máme taky v balíčku, takže tam bych nic nepřidal

A můžeš se o něj podělit? Zatím jsem nepřišel na to, jak ho bezpečně odsunout do vendoru.
Ale přidávat do něj můžeš – vytvořil jsem composer plugin, který konfigurační neony z vendoru posbírá automaticky do loaderu a v bootstrapu už si přidáš jen ten. Není to kompletně dokončené a nette/bootstrap není oficiálně podporovaný (vytvořil jsem si vlastní), ale načtení souborů bez dalších podmínek se už měnit nebude https://github.com/…ai/installer

ZahorskyJan

Marek Bartoš napsal(a):

zajistit možnost entity přepsat na projektu

Tomu je lepší se vyhnout a raději řešit navazující entitou. Ono se snadno může stát, že např. pro produkt v eshopu mohou být dva nezávislé rozšířující moduly a pak není cesta, jak entitu podědit v obou.

Souhlas. Pokud to rozšiřuje další balíček, tak je to jiná entita. Děláme to jen tam, kde to dává smysl, ale zase kvůli přidání jednoho nebo dvou polí do blogu nebo třeba adresáře kontaktů, ať nemusíš přepisovat nebo rozšiřovat moc věcí.

bootstrap máme taky v balíčku, takže tam bych nic nepřidal

A můžeš se o něj podělit? Zatím jsem nepřišel na to, jak ho bezpečně odsunout do vendoru.
Ale přidávat do něj můžeš – vytvořil jsem composer plugin, který konfigurační neony z vendoru posbírá automaticky do loaderu a v bootstrapu už si přidáš jen ten. Není to kompletně dokončené a nette/bootstrap není oficiálně podporovaný (vytvořil jsem si vlastní), ale načtení souborů bez dalších podmínek se už měnit nebude https://github.com/…ai/installer

Díky, to je fajn tip.

Máme to takhle:

// index.php
require '../vendor/bcws/project-tool/bin/run.php';

// run.php
use BCWS\Core\Application\Application;
use BCWS\Core\Bootstrap\Booting;
use BCWS\ProjectTool\Project\Environment;

require '../vendor/bcws/project-tool/src/constant.php';

require \VENDOR_DIR . '/autoload.php';

// Boot options
$options = [
    Booting::DISABLE_ROBOT_LOADER => !Environment::isDevelop(),
];

$app = new Booting(\APP_DIR, \TEMP_DIR, \LOG_DIR);
$app->boot($options)
    ->createContainer()
    ->getByType(Application::class)
    ->run();

Těch „run“ máme několik typů pro prostředí (api, cli, http). Konfigurace je potom celá v config.neon, resp. jeho variantách jako config.local.neon, config.develop.neon s možností přepisu chování.

Felix

Pridam jeste balicek co pouzivam ja. Dejte vedet co vy na to.

https://github.com/…butte/kernel

<?php declare(strict_types = 1);

namespace App;

use Contributte\Kernel\Bootloader;
use Contributte\Kernel\Kernel;
use Contributte\Kernel\Modules\ConfigModule;
use Contributte\Kernel\Modules\EnvModule;
use Contributte\Kernel\Modules\InjectionModule;
use Contributte\Kernel\Modules\TracyModule;

final class Bootstrap
{

	public static function boot(): Kernel
	{
		return Bootloader::of(__DIR__)
			->from(MyAppPreset::create())
			->use(TracyModule::create())
			->use(ConfigModule::create())
			->use(EnvModule::create())
			->use(InjectionModule::create())
			->boot();
	}

	public static function run(): void
	{
		self::boot()
			->createContainer()
			->getByType(YourApplication::class)
			->run();
	}

}

Marek Bartoš

@Felix z dokumentace vím, jak se to používá, ale bez zkoumání kódu vůbec netuším, co to dělá.