Nette a moduly, addony, bundly atd

Já to mám rozdělené na moduly, nehledal bych v tom nic složitého. I Zend má moduly a má tma jak vizuální věci, tak jen něco co například jen vylepší nějaké původní chování a je to na deset řádků… Jinak použvám Flame\Modules. A mám pak ArticleModule, UserModule etc.

Tak nějak intuitivně jsou moduly ucelené části aplikace např.:

• administace
• frontend
• interní sekce (vyžaduje např. přihlášení uživatele)
• cron
• atd.

Se vším, co k nim patří tedy v případě nette jsou to presentery, šablony nebo třeba ještě komponenty specifické pro daný modul apod.

V aplikaci (obecně) pak používáš doplňky (addony/rozšíření) např. již zmíněný webloader nebo dibi a nebo třeba nextras/datagrid. Tohle jsou různé doplňky, které můžeš použít třeba i opakovaně v rámci jednoho modulu (několik datagridů nebo obecně komponent v administraci) nebo je použiješ klidně i ve více modulech. Některé (jako webloader) se používají na aplikaci jako celek. U něktrých doplňků je potřeba je „nainstalovat“, přesněji je správně nastavit v config.neon (viz webloader), jiné stačí nastavit jako službu (dibi) a jiné stačí do aplikace „nakopírovat“ (nebo lépe přidat přes composer).

Tvé rozdělení na admin, front atd by se dalo aplikovat pro nějaký „malý“ rozsah ale v okamžiku kdy to chceš mít ucelené tak by tyto části měly imho byt vnořeny do hlavního modulu např. články a v něm až admin, front, cron atd.

Co ale řeším je zda to nějak dělit modul vs addon. Dejme tomu že si udělám „balík“ pro komunikaci s platební bránou. Ten se připojí k aplikaci, nastaví a přidá své služby. Jak je pak nazvat? Addon, modul? Jak řešit adresářovou strukturu? Ja to zatím udělal tak že je to prostě modul a zařadil jej nějak takto:

projekt
	app
		blog-module
			admin
			front
			...
		users-module
			...
	libs
		framework (uni třídy co rozšiřují nette)
		doctrine (doplnění doctrine do projektu)
		platebni-brana
	vendor
		nette
		kdyby

a mám tedy dva druhy modulů, ty co jsou uni a můžu je pak vzít a hodit do jiného projektu a ty co jsou appspecific které mají zadefinované prvky již konkrétní aplikace.

Je tedy toto pojmenování/rozdělení ok a v souladu s budoucím vývojem nette?

libs a vendor nejsou totéž…vendor dělá composer, libs je sestaveno ručně. Ale zřejmě tady došlo k nepochopení otázky. Nejde mě o to co v nette lze či nelze, co dělá či nedělá composer. Jde mě o vyřešení otázky jak směřuje následný vývoj nete ať podle něj můžu ten projekt připravit.

@akadlec: jsou totéž:

libs // vsechny zavislosti projektu
	composer // zavislosti zpracovane composerem
	cssmin // priklad rucne nactene zavislosti, kterou nactu treba robotloaderem

To, že se nette rozdělí do balíčků je v případě použití composeru blackbox, který na použití nette nic nezmění. Jen ti, kteří nepotřebují celý framework, budou moct sáhnout jen po vybraných částech. Nic víc.

Z hlediska struktury sandboxu by se nic měnit nemělo. Pořád platí, že nette zajímá víc to, které třídy pro presentery má použít, než fakt, kde leží.

Edit:
vendor složku v composeru lze změnit tak, aby se chovala výše uvedeným způsobem, následovně:

"config": {
    "vendor-dir": "libs/composer"
}

Editoval castamir (28. 1. 2014 12:37)

Začni používat tohle a máš po problému :) Co konkrétně na tom nechápeš?

akadlec napsal(a):
Jednoduše zda je správný směr to mít vše jako moduly, tj. vizuální moduly (BlogModule, AccountModule, AclModule,…) a pak ty co dělají svou práci jen na pozadí (Doctrine, Payments, FormElements, Webloader,…)

To už by mělo být pouze na jednotlivci zda je pro něj pochopitelnější, a zda to vůbec chápat chce, že modul je ‚zobrazitelná‘ součást aplikace a extension je ‚systémová‘ součást aplikace a nebo je mu to jedno a všechno pojmenuje modul – jako třeba já :)

Ale co se týče třeba Webloader, FormElements to už by měli být spíše komponenty, tak jak jsou, aspoň myslím. Ale může to zapřičinit zmatek.. Navíc teď mě zrovna napadá že Webloader by měl být builtin funkcionalita pač ho nejspíš inicializuješ v BasePresenter.. ? Stejně tak Doctrine je služba, ne modul!! Zbytečně si motáš hlavu. Payments by rozhodně měla být extension pač se jedna o platební bránu kterou budou/můžou používat jiné moduly – v případě že je instalovaná.. promysli si co vlastně chceš naprogramovat.. udělej si celkový obrázek toho jakou aplikaci nebo platformu pro budoucí aplikace chceš mít.. Další vývoj Nette by rozhodně neměl zrušit dobře promýšlenou aplikaci a i kdyby náhodou ano snadno to napravíš.. veř mi, vím co píši, mě se nějakým zázrakem se celkem často poztrácejí nebo po rozházejí zdrojové kody na DEVu (starší PC :o)) ale během krátké chvilky to zas dam do kupy pač vím jak jsem to navrhoval: sám, bez řešeni třetích stran a s určitým záměrem (vím co ta platforma má dělat).. Ale u tebe se mi zda že nevíš.

Já v tom nevidím rozdíl. To že má rozšíření nějakou vizuální část imho není důležité. CompilerExtension použiješ ve vizuálním i nevizuálním. Pokud tam máš presentery, můžeš si zaregistrovat mapping, který ti nasměruje modul do správného namespacu. Komponenty zaregistruješ pomocí generovaných továrniček. A ostatní služby jsou brnkačka.

V CompilerExtension můžeš dodatečně načítat služby i z nějakého neonu, takže záleží čistě na tobě :)

Já to tak dělám ve své aplikaci, že mám poděděný CompilerExtension který modifikuje nette a načítá mi služby ze services.neon, který je hned vedle něj, ve stejné složce.

class MyExtension extends Nette\DI\CompilerExtension
{

	public function loadConfiguration()
	{
		$this->loadFile(__DIR__ . '/services.neon');
		$this->loadFile(__DIR__ . '/presenters.neon');

		// ...
	}



	private function loadFile($file)
	{
		$builder = $this->getContainerBuilder();
		$services = $this->loadFromFile($file);
		if (isset($services['parameters'])) {
			$builder->parameters = Nette\DI\Config\Helpers::merge($builder->parameters, $builder->expand($services['parameters']));
		}
		$this->compiler->parseServices($builder, $services);
	}

}

Když registruješ služby do extension, měl bys je prefixovat aby ti nedocházelo ke konfliktům jmen. Osobně to dělám tak, že svoje služby registruju podle toho jak se to hodí (tedy například services.neon), ale když upravuju služby Nette nebo jiného rozšíření, tak to dělám pomocí ContainerBuilderu, například tady.