Nette addons, konvence a architektura aplikace
Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
- LeonardoCA
- Člen | 296
Pro inspiraci… Na client side development bude v nejbližší době uveřejněn hodně zajimavý Yeoman. Zvlášť druhé video stojí za to se koukat jak efektivně se dá rozjet projekt a ladit …
- pepakriz
- Člen | 246
Rád bych se podělil o mé řešení instalace modulů přes composer. V mnohém se podobá již popisovaným.
- mé moduly/addony/balíčky (nazvěte si to jak chcete) nepoužívají
žádnou zavádějící třídu. Vystačí si s
composer.json
. - Používám pár svých úprav v Nette.
- tento commit, který řeší možnost vložení nové extension v jiné extension: https://github.com/…tte/pull/720 + něco takového: https://componette.org/search/?….
- doplnil jsem jednoduchou podporu expanze proměnných v s sekci
includes
společně s podporou absolutní cesty k souboru. Díky tomu mohu includovat vlastní konfiguráky jednotlivých modulů.
- mám postavený malý framework nad Nette, který mimo jiné obsahuje
i instalátor pro composer pro typ balíčků
<myframework>-module
. Tento instalátor provede základní instalaci balíku jako typlibrary
+ podle sekce extra provede další kroky, jsou-li definovány:- nasdílí definovaný adresář někam do /www/public
- vloží nějaké definice do hlavního
config.neon
. Tím může zaregistrovat nové extensions, includovat vlastní konfigurák a další běžné činnosti. - provede instalaci pomocí dalších instalátorů, které mohou zautomatizovat další činnosti. Například používám DoctrineInstaller, který projde Entity v modulu a podle nich vytvoří db schéma. Jako další příklad bych si dokázal představit nějaký AssetsInstaller.
Toť vše.
Absenci zavádějící třídy nepociťuju. Na veškeré události v Nette se připojím. Na druhou stranu to přináší některé omezení. Například každý modul musím instalovat jedině přes composer, aby ho dependency resolver bral v úvahu.