Nette addons, konvence a architektura aplikace

To je právě to, že Composer na tohle (css/js/images/fonts/…) naprosto není stavěný. Už jsem nad tím také přemýšlel a v composeru mi to citelně chybí. Výsledek mého dumání: vyřešit to vlastním forkem composeru, na což bohužel nemám čas.

Tak nette/addon-installer uz mi pekne pridava nastaveni do configu.
Zitra jeste doresim kopirovani tech assetu, ale to by melo jit taky docela jednoduse.

Nasledne bych zalozil meta-addony: jQuery, jQuery UI, netteForms. Ty budou moci byt pouzity v zavislostech jinych addonu, coz je casto potreba.

Editoval juzna.cz (1. 8. 2012 16:40)

Tak me napadlo udelat jeden velkej addon nette/extras se vsema moznyma javascriptama a stylama, ktery se casto vyskytujou. Addon, ktery by chtel mit zavistlosti napr na jQuery, tak by to udelal pomoci zavislosti na tento balicek. Priklad addonu – zajimava sekce require a extra:

	"require": {
		...
		"nette/extras": "@dev"
	},
	"extra": {
		"nette-addon": {
			...
			"extras": [ "jQuery", "jQuery-UI", "netteForms" ]
		}
	}

V nette/extras pak bude custom-installer, ktery zpracuje podsekci extras a nainstaluje polozky v ni obsazene.

Pozor, na vyreseni assetu se musi vyresit dve veci: (a) mit asset k dispozici a (b) includnout ho do stranky. Na to druhe uz asi bude potreba WebLoader, jinak nevim, jak to udelat bez nej.

LeonardoCA napsal(a):

1. Možnost stahování js knihoven z CDN s fallbackem na lokální verzi.

To by byla vec addonu nette/extras, ktery by si ve svem custom installeru udelal, co by bylo potreba. Momentalne mam udelane, ze

• asset lokalne zkopiruje do www/temp/
• prida ho do sekce assets v addons.json, na coz zareaguje WebLoader a includne ho do hlavicky stranky.

2. Nějak specifikovat závislosti jiných addonů na konkrétní verzi například jQuery. A následně nějak zajistit ošetření konfliktů verzí jQuery pokud by addony vyžadovaly různé verze jQuery. Tohle vidím jako dost komplexní problém.

Pravda, to asi bude slozite. Nejjednodussi by asi bylo mit addon jQuery a konflikty mezi verzema by pak vyresil sam composer. Pak by se zavislost na definovala klasicky v composer.json v sekci require.

3. Mohl by buď přímo spolupracovat s Webloaderem pokud by byl zahrnut v addonech, nebo by instalátor mohl automaticky kopírovat js knihovny do adresáře www/assets/<library_name> (je-li to možné realizovat)

Ano, to ted jiz mam hotove. JavaScripty (a CSS) neni nutne vykopirovavat, WebLoader si je spoji. U NiftyGridu mi to funguje pekne.

4. Aby se dal bod 3. realizovat jednoduše, chtělo by to zavést pravidlo, že všechny takové knihovny budou v adresáři www/assets/ …

Ano, mam stejny nazor. Zatim to davam do www/temp/ coz je vychozi cesta pro WebLoader. Idea je ale stejna.

Editoval juzna.cz (1. 8. 2012 16:42)

Juan napsal(a):

Tak dneska jsem měl konečně chvilku času, tak jsem septal jednoduchou první představu v podobě pull requestu.

Take chci mit addony minimalisticke a co nejjednodussi, ostatne tak jako je delane cele Nette. Proto ti to zhodnotim jednoduse: Proc? Proc kazda trida/metoda, co tam mas? Je potreba? Neslo by ji vyhodit a udelat to bez ni?

Konkretneji:

• proc musi mit kazdy addon vlastni tridu TestAddon? Neslo by to bez ni?
• proc ma dostavat DI Container? At si rekne jen o to, co opravdu chce.
• proc ma jmeno? Nebude pro pouziti stacit jmeno z composeru? Nebo jeste lepe jen interfaces?
• proc ma tolik callbacku? Nestaci, aby si je registroval sam na prislusna mista, kdyz bude potrebovat?
• je potreba AddonManager? Potrebuji mit v aplikaci pristup k samotnym addonum? Nestaci, kdyz se kazdy zaregistruje, kam ma?

Neber prosim mou kritiku jako nejaky utok proti tobe. Pokud mas argumenty, rad je vyslechnu, prodiskutuju a budu je zastavat. Stejne tak budu rad za stejnou kritiku proji memu navrhu. Diky

Tak, trosku jsem to zrefaktoroval a vse vyclenil do samostatneho Configuratoru, kde je mozne jednoduse pridat nove podporovane sekce:

• sekce config-extensions zavola metodu registerSectionConfigExtensions
• sekce assets metodu registerSectionAssets
• …atd

Diky tomu uz to funguje i bez jakehokoliv hacku do Nette a na posledni verzi (2.0.4). Jedine zmeny oproti standardnimu sandboxu jsou:

• pouziti autoloaderu z composeru misto NetteLoaderu a RobotLoaderu
• pouziti pretizeneho Configuratoru
• nacteni config souboru addons.neon
• css + javascript je v @layout.latte renderovan pomoci WebLoaderu, aby addony mohly jednoduse pridavat svoje assety

Vice addonu

Nyni by bylo potreba predelat vice addonu do teto pobody (composer + custom-installer), spravne nastavit zavislosti, otestovat je a pridat je na packagist. S tim se zaroven objevi potreba novych konfiguracnich sekci (extension pointu), ktere tedy bude potreba pridat do Configuratoru.

Rad bych timto pozadal komunitu o pomoc. Pokusim se co nejvice radit na Nette chatu, jabberu nebo pres email ci forum vsem zajemcum. Jakakoliv iniciativa vitana! Dekuji za podporu

Jako největší problém vidím již zmiňované CSS,JS a Obrázky a hlavně závyslost na nějaké verzi JS knihovny (jQuery, Angular.js, …). Obávám se že né všichni chtějí používat WebLoader nebo Assetic

Patrik Votoček napsal(a):

Symfony Bundles a Kdyby Packages

Mě se to nelíbí z jednoho prostého důvodu je to hodně Symfony-way a Symfony-way nemám rád (tady uděláme takovou a makovou třídu, tady takovou a makovou metodu … protože tohle by přeci mohl někdy někdo potřebovat!) ostatně to je důvod proč dělám v Nette a né v Symfony.

Ale kdepak, Symfony way je akademická cesta (ukecanější, ale pořád to má svůj smysl). To co popisuješ je Zend cesta ;)

Editoval HosipLan (1. 8. 2012 20:23)

Patrik Votoček napsal(a):

Co se týká mě tak ač se mě juznovo myšleka líbí a hodně zamlouvá tak absolutně odepisuje lidi, kteří nechtějí/nemůžou/nepoužívají/neumějí používat composer.

To vubec neni pravda. Instalaci bude mozne stale provest starym zpusobem a vse nakopirovat a nastavit rucne. Ja se toto rucni nastavovani pouze snazim zautomatizovat pomoci (a) nette-addon-installeru a (b) addon configuratoru.

Clovek NEpouzivajici composer:

1. stahe addon a rozbali do libs
2. zkopiruje assety na spravna mista
3. zaregistruje addony na spravna mista, tak jako to bylo do ted

Posledni bod by se dal nahradit necim jako ComposerExtension (pojmenovali bychom to treba NotComposer), ktery by natahl informace z composer.json v addonech, ktere by ten soubor stejne mely.

Kazdopadne, moznost nainstalovat addon i bez composeru musi existovat, s tim pocitam.

… závislost na nějaké verzi JS knihovny (jQuery, Angular.js, …)

To bude problem i pri manualni instalaci, ne?

Obávám se že né všichni chtějí používat WebLoader nebo Assetic

Samozrejme, neni problem. V tom pripade nette/addon-installer pouze zkopiruje assets na dohodnuta mista (WWW_DIR/assets/<addonNane>) a do @layout.latte uz si ho clovek doplni sam.

@Bazo: ano, jde to. Zatim ale neimplementovano a nezda se mi to jako prioritni. Az se to trosku usedi a bude jasne, kam se co instaluje, tak bych resil uninstall.

@Vrtak: Pokud bude addon ve formatu nette-addon (pro nette/addon-installer), pak je mozne jej nainstalovat manualne tak, ze do config.neon do sekce addons pridam adresar addonu (nebo primo cestu k composer.json z onoho addonu).
Udelala by se nejaka CompilerExtension, ktera by z takto nainstalovanych addonu nacetla composer.json, z toho sekci extra.nette-addon a podle toho by addon zaregistrovala na prislusna mista, tak jako to dela instalator ted. Jediny rozdil, ze by to nacital primo ze zdrojovych json souboru a ne z predzpracovaneho addons.neon.

Pokud by v addonu byly nejake assety, ktere se musi vykopirovat jinam, tak ty by se holt musely vykopirovat rucne. S tim asi nic nenadelame.

Editoval juzna.cz (2. 8. 2012 0:37)

Juznovo řešení assetů mi připadá jako overkill. Proč řešit assety composerem? Ten má addon stáhnout a maximálně třeba zaregistrovat do addons.neon. Tam by bylo pole s názvi tříd zastřešující Addony.

A byly by tam uvedeny jen Addony, které něco potřebují. Ať už assety, routování, DI. Vše by se mělo řešit pomocí odkazování. To znamená nic nikam automaticky neregistrovat, nic neassetovat a podobně.

Každý uživatel by měl mít možnost zajistit si a uzpůsobit si vlastním potřebám (Nette-way). Odkazováním myslím například metody:

getCompilerExtension() {
	return new NetteExtension;
}

getAssets() {
	return array(
		'js' => array(ABSOLUTE_PATHS),
		'css' => ...
	);
}

Když si vyberu použití webloaderu, rozparsuju addons.neon, iteruju nad třídami a volám. Například:

foreach(Neon::decode(file_get_content(ADDONS_NEON) as $className) {
	$class = new $className;
	if($class instanceof IAssets) {
		$assets = $class->getAssets();
		foreach($assets['js'] as $asset) {
			$container->webloader->jsFileCollection->addFile($asset);
		}
	}
}

Konvencí by bylo jen několik interfaců a každý addon by implementoval jen to, co potřebuje. (ICompileable, IAssets, IRouteable, …)

A tak podobně. Nejsem proti vytvoření implicitního řešení ve formě AddonsManageru ala Kdyby packages, sám jsem se inspiroval, ale nic nikomu, prosím, nevnucovat.

Editoval echo (2. 8. 2012 14:24)

Odmitam nastrojem pro php resit js. S tim jdete nekam. Patrikova poznamka se mi libi, jde (mi) o to zjednodusit workflow i bez composeru. Budu nanejvys spokojen, kdyz mi composer update stahne nejnovejsi verzi se zavislostmi. Pridat do konfigu potrebnou sluzbu uz si zvladnu sam. Dekuji, muzete se posadit :)

LeonardoCA napsal(a):

echo: Assets je potřeba řešit composerem, aby bylo možné řešit závislosti na javascriptových knihovnách, Když už se závislosti řeší composer, měl by řešit všechny – jinak by řešení závislostí bylo poloviční.

Nesouhlasím, že to má mít na starosti Composer. Moje řešení:

class PackageA implements IAssets {

	public static function getAssets() {
		return array(
			'js' => array(JQUERY_PATH)
		);
	}

}

class PackageB implements IAssets {

	public static function getAssets() {
		return array(
			// pouze nástin, v reálu by samozřejmě potřebovalo upravit
			'js' => array( PackageA::getAssets() ) // závislost - pouze uvést v composer.json závislost na PackageA
		);
	}

}

Závislost vyřešená, každý slušnější AssetsManager nepřidá jeden soubor vícekrát. Musely by se udělat balíčky/addony pro jquery, které by sice byly triviální, ale byl by v tom pořádek. A hrach by byl spokojen, protože by si to vyřešil po svém a žádné getAssets by ho nezajímalo.

juzna.cz napsal(a):

Druha moznost je registrovat addony imperativne, tzn ze se zavola nejaka matoda, ktera udela co je potreba. Ale to uz se neda tak pekne managovat. Kdyz by si chtel nekdo udelat klikatko na editaci, tak to uz nepujde tak pekne jako s editaci configu.

Naopak mi to připadá pohodlnější protože mám vše na jednom místě addons.neon.

Konfigurace v neonu deklarativně by měla být volitelná, pracujeme v php ne v neonu. Dokázal bych si ji představit v implicitním addons manageru.

@echo, @Juan a dalsi zastanci Symfony/Kdyby way – zkuste udelat proof of concept: vezmete treba 10 addonu a zkuste z nich udelat addony dle vasi predstavy. Pro zaklad uz je udelany Pull Request, ze ktereho muzete vychazet. Udelejte upraveny sandbox, do ktereho bude mozne addony jednoduse pridavat.

At si to ozkousite, jak dobre/spatne se to pouziva. Navic ostatni a hlavne ja budeme mit konkretni ukazky a bude se daleko lepe diskutovat, nez jen spekulovat.

LeonardoCA napsal(a):

echo: zatim chapu composer tak, ze nainstaluje vsechny potrebne balicky v takovych verzich aby byly spolu kompatibilni. Jak to dokazes se svym resenim? Mam pocit, ze to co pises resi neco uplne jineho nez resi composer.

Nerozumíme si. Common assety řeším tak, že z nich vytvořím composer balíček s patřičnou verzí a pak na ně odkážu mým způsobem.

Je to trochu prasárna, ale práci to odvede a pro mě je to přehledné.

Tak jsem si to trochu pročetl a hlavní problém juznova řešení vidím v tom, že ohýbá composer na něco, k čemu prostě není. Composer by měl každý addon nahrát, vyřešit jeho verzi a závislosti a tím by to mělo (podle mě) pro Composer končit. Kdo nechce/nemůže používat Composer, stáhne addon a někam ho nakopíruje.

Pokud má assety něco někam kopírovat/zpracovávat/cacheovat, měl by to být buď přímo framework anebo nějaký addon, který budou ostatní addony (které potřebují pracovat s assety) vyžadovat (např. nějaký AsseticAddon).

Můj návrh assety přímo zatím neřeší, ale řešil jsem tam to, že lze zjistit složku každého addonu, čímž by se dalo dostat k adresáři s assety. Způsob, jakým je vytahovat, jsem schválně zatím nijak neřešil, protože někdo chce Assetic někdo WebLoader a někdo nic.

Myšlenka @echo s IAssets se mi libí. Mít u addonu nějakou metodu, která by vrátila pole jeho assetů je podle mě ideální. To, jak s nimi pak naložíme už je další stupeň problému a opravdu toto může řešit třeba i sám nějaký addon.

Souhlasím s juznou, že by možná nebylo nutné, aby můj návrh addonů vytvářel všechny metody pro události aplikace, atd. a že by si je addon mohl registrovat sám. Ale musí to být jednoduše a jasně proveditelné. Aby každý neprasil ve svém addonu své vlastní hacky. Navíc lze u mého řešení zavést konvence ve stylu „pokud jsou assety ve složce assets, nemusím dělat nic, aby je framework našel, pokud ne, přepíšu si nějakou metodu getAssets“. Ale jak říkám, ten IAssets zní taky jako dobrý nápad.

Stojím si za tím, že Addon má být prostě předně nějaká třída (ať už poděděná nebo s interface), která nabídne základní věci jako přístup k případným assetům, Presenterům a dalším složkám addonu. Instalace je podle mě to, že připíšu jeden řádek do bootsrap anebo (lépe) do nějakého assets.neon. To, jak se addon dostane do mého projektu (např. Composerem anebo nakopírováním) by s jeho instalací/registrací podle mě nemělo nijak souviset!

Jinak souhlas s juznou, chtělo by to předvést více kódu a addonů v praxi. Teď se k tomu bohužel nedostanu. Pokud to bude aktuální, tak až se v září vrátím do civilizace, můžu se pokusit rozvinout svůj pull o řešení routování a předvést nějaké addony.

Editoval Juan (2. 8. 2012 18:23)

Tak jsem si to trochu pročetl a hlavní problém juznova řešení vidím v tom, že ohýbá composer na něco, k čemu prostě není. Composer by měl každý addon nahrát, vyřešit jeho verzi a závislosti a tím by to mělo (podle mě) pro Composer končit. Kdo nechce/nemůže používat Composer, stáhne addon a někam ho nakopíruje.

Pokud má assety něco někam kopírovat/zpracovávat/cacheovat, měl by to být buď přímo framework anebo nějaký addon, který budou ostatní addony (které potřebují pracovat s assety) vyžadovat (např. nějaký AsseticAddon).

Můj návrh assety přímo zatím neřeší, ale řešil jsem tam to, že lze zjistit složku každého addonu, čímž by se dalo dostat k adresáři s assety. Způsob, jakým je vytahovat, jsem schválně zatím nijak neřešil, protože někdo chce Assetic někdo WebLoader a někdo nic.

Myšlenka @echo s IAssets se mi libí. Mít u addonu nějakou metodu, která by vrátila pole jeho assetů je podle mě ideální. To, jak s nimi pak naložíme už je další stupeň problému a opravdu toto může řešit třeba i sám nějaký addon.

toto presne podepisuji :)

@juzna
Jestli se bude používat třída, nebo neon je jedno. Hlavní je, aby to neměl na starosti composer. Ten pouze stáhne, uloží záznam o addonu do kontejneru (neon, db, json) a vygeneruje neon pro user nastavení (extension name).

Dále:

• Potřebujeme přidat do DI → jednoduché, kdo by používal něco jiného než Nette\DI\Container? ⇒ řešením upravit Nette\Application\Application, aby projel kontejner a podle nastavení v neonu přidal rozšíření.
• Interakce mezi službami v DI → pokud umožníme změnu extension name, musí se použít autowiring.
• Potřebujeme assety → složitější, ne každý používá Webloader, Assetic. v šablonách se musí registrovat něco dřív, něco později ⇒ poskytnout službu registrovanou v NetteExtension, která po zavolání např. $addonManager->getAssets(‚Echo511/Plupload‘) vrátí pole s js, css, obrázky.
• Řešíme obrázky → zapeklité, třeba nakopírovat do WWW_DIR, ale strukturu interního asset adresáře si každý vývojář volí svou a css odkazující na obrázky používají právě tuto strukturu ⇒ použití filtru na css (nepraktické, svazující), nebo konvence adresářové struktury (svazující, ale přehledné) HLASUJU ZDE, nebo nechat na uživateli.

Zapomněl jsem na něco mimo ty čtyři body?

Zítra se pustím do Proof of concept.

@Juan Presvecil jsi me. Rucne si vlozit do config.neon tridu addonu a nechat composer nebo jakykoliv jiny autoloading mechanismus, aby si ji nasel, je spravne reseni. Jak se k tomu zase dostanu, zkusim ty ukazkovy addony udelat v nove branch timto zpusobem.

Trosku me to vsak porad mrzi, protoze takto nepujde udelat plna automatizace, jak jsem si predstavoval.

Mel jsem takovou krasnou utopickou ideu, ze by addony mohly mit i nejaky wizzard (jako ma ted composer init). Pri instalaci by se tak zeptaly uzivatele: „hele, potrebuju nastylovat, chces nahrat defaultni styly?“ a kdyz by to uzivatel potvrdil, tak by se css-ko nakopirovalo (nebo pridalo do webloaderu).

Nebo by se addon zeptal „hele, jsem v zakladu anglicky, ale umim i cestinu a nemcinu, jak mluvis ty?“ a prihodil by i jazykovou mutaci.

A tak, mno. Ale je pravda, ze uz i s odstupem jen par dni se mi to zacina libit min a min.

Juan napsal(a):

… ta plná automatizace je lákavá, ale správné/čisté se mi to nezdá.

Teď mě napadlo ultimátní řešení kombinujicí vše. Splníme tím jak (a) instalaci pomocí jedné třídy, nikomu nic nenucení a nekopírování, tak také (b) možnou plnou automatizaci, pokud bude chtěna.

Způsob: Addon bude mít uvedeno jako type nette-addon, ale už nebude vyžadovat addon-installer (ten bude pouze třeba v suggest). To je pro úplně běžné zacházení v pořádku. Vše bude fungovat, tak jako to zastává Juan.

Pokud bude chtít uživatel plnou automatizaci, tak mu ji můžeme přidat jako třešničku na dortu. V takovém případě si přidá do svého projektu (root composer.json) závislost na addon-installeru, který najednou začne instalovat addony se vší parádou.

Do composer.json, sekce extra se pouze uvede třída zastřešující Addon (tak jako je to např u custom-installerů; aby si ji mohl addon-installer dohledat, když bude použit).

jazykova mutace by se dala dala nastavit např. v configu

Sypu si popel na hlavu. Proč mě toto nenapadlo??? Tak to má být.

V případě ultimátní kombinace se installer může na jazyk zeptat a do configu ho přidat. Ale to je zatím daleká budoucnost… Zatím neřešme.

dědičnost anebo použití více interfaců

Raději interfaces – je to univerzální a nikomu nevnucuješ, od koho má dědit. Ale k tomu i defaultní BaseAddon třída s obecnou implementací, aby se nemuselo hodně kódu opakovat.

Pravda pravda. A super nápad od juzny – tedy, že napřed uděláme řešení, které nebude souviset s Composer custom-installery a pak Composer tuto instalaci kdyžtak naučíme. To se mi líbí.

Má první otázka tedy zní – co potřebujeme za interfaces? Napadá mě: možnost routování na presentery addonu, možnost vrácení nějakého pole assetů, možnost registrace CompilerExtension, možnost registrace callbacků do životního cyklu aplikace. Toto je podle mě základ, který by snad měl pokrýt potřeby většiny addonů, další kdyžtak vyplynou až se pokusíme addony do této podoby přepsat. Zapomněl jsem na něco?

Ještě k assetům: Myslím, že je to opravdu největší problém, co se týče nějaké automatizace, univerzálního řešení atd. Líbí se mi juznovy nápady ohledně nějakých speciálních typů addonů pro např. JS knihovny. Tedy např. jQuery by byl addon implementující pouze nějaké IAssets. Obrovskou výhodu zde vidím v tom, že by verze i těchto JS knihoven dokázal takto vyřešit Composer. Navíc by toto mohl naprosto zautomatizovat web addonů – tedy sám by nabízel z GitHubu všechny verze např. jQuery a přidával k nim composer.json s příslušnou verzí a tu obalující třídu.

Pokud pak budeme tvořit nějaký addon, který by všechny assety includoval sám, objeví se další problém – assety musí být načteny ve správném pořadí. Jenže toto pořadí (tedy který addon závisí na kterém) půjde vyčíst jedině z composer.json. (Což by asi nevadilo, protože i když někdo nepoužívá Composer, composer.json by u addonu byl.)

Já bych to nekomplikoval :)

interface Addon
{
	function compile($configurator, $compiler);
}

interface AddonAppEvents
{
	function listen($application);
}

interface AddonAssets
{
	function listAssets();
}

class MyAddon extends Nette\Object implements Addon, AddonAppEvents, AddonAssets
{
	public function compile($configurator, $compiler)
	{
		$compiler->addExtension('doctrine', new DI\DoctrineExtension);
	}

	public function listen($app)
	{
		$app->onError[] = $this->appError;
	}

	public function appError($app, $e)
	{
		MyLogger::log($e); // třeba
	}

	public function listAssets()
	{
		return Nette\Utils\Finder::files('*')->from(__DIR__ . '/Resources/public');
	}
}

@repli2dev: Tak jdi, vyřeš to a pošli pullrequest, když jsi takový odborník ;) Ok, tak jinak.

Tohle (jak je vidět z jejich rozboru) řešit nejde (cc @hrach). Protože když dovolíš definovat repozitáře jinde než v rootu, brzy narazíš na nezanedbatelnou pravděpodobnost konfliktu. Řekl bych, že zrovna tahle feature je naprosto zanedbatelná. Definovat repozitáře stačí v rootu. A stačí ti na to jeden, nějaký společný pro Nette Addony, který bude zašťiťován Nette webem.

Oni chápou repozitář jako zdroj balíčků, verzovaný repozitáře je něco jiného. Proč by se z těchto nedaly udělat „klasické“ balíčky a importovat je do systému (do addons portálu)? Pak nebudeš vlastní repozitář (pro svůj virtuální balíček) potřebovat.

A pokud potřebuješ vnitrofiremní věci, tak ti zase stačí definovat repozitář v rootu. Tohle opravdu není problém.

Editoval HosipLan (7. 8. 2012 11:40)

@HosipLan Nechtel by ses trochu uklidnit? Na jasnou vytku tu odpovidas jen arogantne. Je to fakt, uz sem na to taky razil a je to proste problem. @repili2dev nikde ze sebe odbornika nedela, to spis ty, takze jdi a udelej pull-request.