Nette addons, konvence a architektura aplikace

To je věc, která mi v Nette skutečně chybí. Dovedu si představit, že všechny addony by obsahovaly např. kromě composer.json také addon.neon s pevně danou strukturou. Problém je, jak to celé dobře vymyslet. Osobně považuji dobře napsanou modulární aplikaci jako svatý grál :)

+1. Super, tak nějak podvědomě na toto čekám od doby, kdy jsem začal používat Nette :-)

Jen nesouhlasím s takovouto strukturou, podle mě by kvůli ní vznikaly problémy:

tak jako v Symfony – každá aplikace by vlastně byla jedním addonem (anebo by se mohla dokonce skládat s více addonů, čímž bychom vlastně nahradili moduly.)

Je to de facto opačná struktura, než jakou používá Nette aktuálně pro moduly.

nanuqcz: Ten rozdíl addon/modul podle mě není tak velký. Jeden addon může dědit cokoliv z jiného (a pak na něm má závislost – specifikovanou např. v composer.json), ale addony by samozřejmě nebyly zanořené v podsložkách, jako moduly dnes, což je podle mě významné plus (aneb modul svádí spíše k dědičnosti, addon ke kompozici). (Když se podíváš na Symfony, společné věci pro aplikaci jsou ve složce app a zdrojový kód jednotlivých vlastních Bundles je ve složce src.)

vvoody: S DI jsou opravdu rozdíly mezi miniaturními a velkými addony naprosto smazány. Pomocí CompilerExtension si velký addon může sáhnout třeba na všechny služby frameworku, zatímco malý nemusí CompilerExtension vůbec implementovat. Doporučuju mrknout na Symfony, možná jejich řešení není ideální, rozhodně je to ale správná cesta. Jednoduchost by měla jít zachovat. Volnost je diskutabilní – podle mě jsou pevné konvence velmi pozitivní pro čistotu kódu, ale klidně by mohly být jen nějaké výchozí, které by šly změnit konfigurací.

Chápu, ale vždykcy máš v Latte možnost použít extends a především je to z podstaty toho, co se v této diskusi snažím říct, spíše detail :)

mám několik addonů a popravdě nepotřeboval jsme řešit nějaké cesty do adresářů

To, že si to ty nepotřeboval, pro mě není žádný argument. Máš jednoduché addony jako DoctrineAddon, kde nepotřebuješ žádné resources/assets ani presentery nebo cokoliv podobného a stačí ti sahat na kontejner, a proto si asi taky myslíš, že ComplilerExtension = Addon:

Co se týká „nadtřídy“ Addon tak vpodstatě existuje jen se jmenuje jinak Nette\Config\CompilerExtension.

Tady opravdu pleteš jablka s hruškama, zrovna od tebe bych tohle nečekal. To jsi nikdy neviděl Kdyby nebo Symfony? CompilerExtension je CompilerExtension, neboli rozšíření kontejneru (a zároveň velice silná zbraň, jak s ním pracovat), ale rozhodně to není addon (package/extension/whatever…). Nevím, proč si myslíš, že by každý addon měl mít ComplierExtension a zároveň žádný nějaké obrázky, csska, atd. (Asi proto, že takto vypadá tvých pár addonů?). Addon může být cokoliv – část aplikace, datagrid, formulářové komponenty a mnoho dalšího.

Nevidím důvod, proč by každý addon měl definovat vlastní CompilerExtension (i když to třeba bude dělat většina) a tak jako tak by docházelo ke kolizi jmen, protože nikde není dáno, že si má addon zabírat v kontejneru jméno „vendor/name“, atd.

Jinak taky mám své komponenty, taky je řeším jedním řádkem v bootstrapu. Původně jsem chtěl použít ty z Nella, ale po pár pokusech a pohledu do kódu jsem je smazal a vytvořil si vlastní, trochu po vzoru HosipLana (který je má opravdu výborně napsané), ale naprosto nezávislé na Kdyby. Jedná se o Symfony Console, Doctrine, Doctrine Migrations, Doctrine Data Fixtures, Assetic (nezávislý na HosipLanově HeaderControl) a možná přijdou i další a až mi vyjde chvilka času na refraktoring a nějaké testy, rád se o vše podělím. Ovšem právě při psaní těchto komponent (které jsou jednoduché a s CompilerExtension si vystačí) mi došlo, že Nette opravdu nijak neřeší zcela zásadní věc.

Ještě zkusím popsat jeden dojem, kterého jsem nabyl při souběžném programování v Nette a Symfony – Nette výborně řeší detaily, ale naprosto zaostává v nějaké té modularitě typu addon/package a rozvržení aplikace. Symfony naopak výborně řeší tuto modularitu a má perfektně udělanou architekturu, ale zaostává za Nette v detailech a vychytávkách.

to nebyl argumen nýbrž spíše popud k uvedení příkladu :-) Ideálně s ukázkou implementace do stávajícího nette.

Příklad jsem uvedl několikrát, jakýkoliv addon s vlastními presentery a resources, tedy CSS, JS, obrázky, atd. (addon, který s obrázky pracuje je úplně něco jiného).

Proč musí mít každý addon AddonClass / ExtensionClass / PackageClass?

Protože by poskytovala úplný základ. Přístup do složky addonu, routování na jeho Presentery, atd. Vůbec netvrdím, že by to mělo samo řešit obrázky a CSSka addonu, stačilo by, že by ses k nim třeba v šabloně mohl dostat přes @Vendor.MyAddon/assets/css/main.css. Podobně pak třeba to routování, atd.

Možná jsem se moc rozepsal nebo špatně vyjádřil, ale i takovýhle minimalistický základ by byl podle mě perfetkní. (Pokud by pak někdo chtěl řešit assety s nějakými konvencemi na adresáře a řekněme přes Assetic, napsal by si na to addon a jeho ostatní addony by na tomto addonu mohly být závislé, atd. Tohle by určitě nemuselo řešit Nette.)

Naopak jeden můj Addon dokonce slouží přímo pro práci s obrázky a soubory.

Ano, ale tvůj MediaAddon je úplně něco jiného než mám na mysli. Také mám AsseticAddon, který se instaluje jen přes CompilerExtension. Ovšem ve chvíli, kdy addon nějaké obrázky a CSSka obsahuje, tak je potřeba mít přistup do jeho adresáře a pokud možno elegantněji než přes reflection například.

Koukal jsi na to jak jsou CompilerExtension implementovány? Jméno jaké si má v kontejneru zabírat určuje uživatel (nikoli tvůrce – ano většinou tvůrce určí nějaké výchozí).

Jestli jsem koukal… :) Používám je a to hodně. Neřekl bych, že ve tvém příkladu si jméno v kontejneru zabířá uživatel:

Nella\NetteAddons\Doctrine\Config\Extension::register($configurator);

Samozřejmě lze udělat toto:

$container->onCompile[] = function($container, $compiler) {
	$compiler->addExtension('mojeJmeno', Nella\NetteAddons\Doctrine\Config\Extension);
}

Ale první způsob instalace se mi líbí víc, protože je univerzálnější (když addon svou CompilerExtension nepotřebuje, nemusí ji vytvářet).

A tak se zeptám jaký je podle tebe skutečný rozdíl mezi CompilerExtension a Addon/Extension/Package? Skutečně potřebujeme další třídu?

Snad už se tedy chápeme, jde mi o (alespoň) naprosté minimum. V podstatě by Addon byl ještě daleko méně, než CompilerExtension.

PS: nepřu se o tom že by se měli stanovit nějaká základní pravidla pro to co a jak by mělo v onom Addonu být (nějaká výchozí struktura). S tím souhlasím.

Především za to se tu snažím „bojovat“ :)

Jinak jsem toho názoru, že pokud by nějaká základní třída Addon byla a pokud by na addony šlo přistupovat do adresářů addonů jednotným způsobem a routovat na jejich presentery, z hlediska Nette by asi bylo opravdu „nejjednodušší“ nerozlišovat příliš mezi staženými addony a mými kódy aplikace. Neboli pokud addon může být „cokoliv“ (a myslím, že o to nám jde, aby addony mohly být co nejvíce univerzální), pak nevidím důvod, proč by má aplikace měla pracovat jinak (resp. přinášelo by to zbytečnou podvojnost a WTF faktor).

Příklad je pro mě ukázka nikoli teoretizování. :-)

Když si nedovedeš představit ani normální include CSSka z adresáře addonu do šablony…

Jinak řečeno je ti proti srsti aby každý addon měl CompilerExtension ale není ti proti srsti aby měl každý addon AddonClass… hmm…

Přesně tak, protože jde o dvě naprosto odlišné věci.

Přesně tohle může řešit CompilerExtension přidáním parametru do DIc. :-) Případně přímo registrací do (přidáním setup) do určené AsseticAddon sluzby. :-) Routu taky zaregistruješ jako službu. Stejně tak Latte makra.

Hm, takže předpokládáš něco jako AsseticAddon a až pak můžeš alespoň trochu „normálně“ includovat např. CSSka? Anebo je podle toho, co říkáš pohodlný include CSS z addonu to, že přidáš cestu k němu do DIc jako parametr, to si pak vytáhneš v presenteru a vložíš do šablony? Hm… To se nám ty doplňky budou fakt pěkně tvořit a ještě líp používat…

Pro mě je pohodlný include CSSka (pokud se bavíme bez Asseticu, atd.) například toto:

{css @Vendor.MyAddon/cesta/v/addonu/k/css.css}

A jde mi o to, že by to bylo jednotné, ne že by si to každý dělal po svém a bylo všude milion zdlouhavých návodů, co kam přidat, jako teď…

see: http://api.nellafw.org/…tension.html#496 :-)

OK. Nicméně… i kdyby se všechny addony měly přidávat právě takto, není to žádný standard a to mi vadí.

Já pořád nevidím nějaký zásadní rozdíl. Nikdo tě nenutí psát CompilerExtension který bude čarovat a kouzlit šílenosti. :-)

Zkus mi říct, jak mám nyní (bez CompilerExtension a alespoň trochu elegantně) vyřešit následující naprosto primitivní úlohu – mám addon s jedním Presenterem a jednou šablonou, chci, aby můj web při přístupu na adresu /my-addon zavolal právě tento presenter.

A co teprve, kdybych měl doplněk, který závisí na jiném a tak by od něj chtěl třeba i něco podědit – u tříd no problem, ale co kdyby náhodou chtěla dědit i šablona? To, čemu já říkám elegantní, je {extends @Vendor.MyAddon/templates/@layout.latte}. (Příklad spíše okrajový, ale mně jde opravdu o to, aby addony byly naprosto univerzální a aby Nette poskytovalo nějakou alespoň naprosto základní podporu.)

Každopádně nemá smysl tu takhle diskutovat, dokud se neozve David, jestli se vůbec někdy něco takového bude řešit…

@Juan: zkus sepsat RFC, pripadne nejaky example/proof of concept, jak by sis to predstavoval ;) @HosipLan o modularnosti svoji aplikace povidal na dubnove Posobote, tim by se dalo dobre inspirovat.

Nějakou představu mám, protože jsem sám několik addonů psal v poslední době, ale určitě to chce hlubší analýzu. RFC nebo rovnou i nějaký kód se klidně pokusím sepsat, ale nebude to asi úplně hned, protože mám zkouškový…

Komu se nechce číst, důležité je tučně :-)

Přidám svou představu k jednotlivým bodům:

1. Automatická instalace addonu, jen přidáním addonu do config.neon – vše ostatní by se už mělo nastavit samo
2. jednotné pojmenování ANO, jedna řádka v composer.json (nepovinná pro ty co composer nepoužívají) a nastavení v config.neon – jestli má být addon aktivní – případně jestli má být jen v development nebo i v production
3. nadtřída ne, případně rozhranní, ale myslím si že není potřeba. Preferoval bych addon.config.neon addonu, který by vše potřebné definoval. Plus composer.json, který by byl povinný, ten by se automaticky vytvářel při přídání addonu do doplňků, i v případě, že autora composer vůbec nezajímá…

Taky addon.config.neon by vznikal automaticky při přidání doplňku, pokud by ještě nebyl definován, na základě informací od autora ve formuláři pro přidání doplňků. Autor, který by měl již vše připravené, by addon přidal prostým uvedením url z github. Jinak by přidání addonu bylo trochu složitější,ale zase by automaticky generovalo potřebné konfigurační soubory .neon a .json.

4. určitě
5. do toho moc nevidím, zatím řeším addony na úrovni komponent, ale opět by vše mělo být definováno v addon.config.neon a automatickou instalaci addonu a nastavení všeho by mělo být řešeno pomocí compilerExtension

Vycházím ze své zkušenosti. Asi před týdnem jsem předělal první projekt z nette 0.9.7 na 2.0. Zasekl jsem se i na takové drobnosti jako správné nastavení dibi jako služby v config neon, protože na fóru i v dokumentaci je několi různých míst kde je to popsané, ale takovým způsobem, že se mi to stále míchalo dohromady s použitím nette/database a než jsem byl schopen rozchodit finální konfiguraci, musel jsem prostudovat „polovinu“ frameworku, abych pochopil co a proč se děje.

Protože jsem zrovna nutně potřeboval zprovoznit logování všech SQL dotazů do souboru, abych dokázal najít chybu, v procesu, který generoval řádově desítky sql dotazů, musel jsem si napsat vlastní compilerExtension na základě Davidova DibiExtension. To je podle mně pro nováčka začínajího s nette (připadně s PHP) od nuly nadlidský úkol.

Teď už chápu, proč některý addon, může být přidán v bootstrapu a některý až v BasePresenteru, ale když jsem to viděl poprvé dělalo mi problém se v tom vůbec zorientovat, ne tak to chápat. To pochopení přišlo, až když jsem si otevřel temp sobory vygenerované configurátorem a pochopil do důsledku celé DI. A ještě teď mám nějaké mezery…

Přitom je celá konfigurace navržena geniálně a mohla by fungovat plně automaticky. Nevidím důvod, proč bych při přidávání addonu potřeboval studovat co kam přidat, jen je potřeba ještě dodefinovat a standartizovat pár detailů – hlavně ohledně js,css, apod.

Moje finální představa přidání addonu je:

• Otevřu si panel addonů z debug baru.
• Kliknu na přidat addon, vyjede seznam addonů pro danou verzí nette.
• Kliknu na přidat addon. Automaticky se nahraje do libs(vendors), přidá se do panelu addonů. Obnoví se stránka, aby se inicializoval, ideálně se obnoví jen snippet s addonem.
• Kliknu na něj, objeví se panel nastavení.Změním nastavení, uložím, hotovo.

Dále v panelu addonů budou informace co dělá s příklady použití, vše definováno v addon.txt nebo .html s obsahem identickým jako v repozitáři addonů. Bude tam možnost aktivovat/deaktivovat addon. Možnost Check updates. Info o autorovi, odkaz na git nebo homepage addonu…

Jestli trochu „lítám v oblacích“, tak mne klidně zchlaďte, ale v tuto chvíli mám desítky nápadů na vylepšení a bude trvat ještě pár dnů než se mi utřídí a pár měsíců, než je realizuji…

Pro přehlednost shrnu – addon by měl být instalován vždy automaticky a jen pomocí

• jedné řádky v config.neon, případně v samostatném addons.neon – automaticky by se generovalo <addon>::register() pomocí standartního configurátoru/compileru, případně by se vytvořil výchozí AddonsCompilerExtension
• <Addon>CompilerExtension – pokud addon potřebuje přidávat do frameworku jakékoli další závislosti, každe extension by mělo mít definované $defaults = array(); pro nastavení parametrů – aby volitelné parametry byly zjistitelné pro zpracování instalátorem addonů (GUI), na základě toho by se automaticky generoval <addon>.neon nebo příslušný blok parametrů do addons.neon

Editoval LeonardoCA (24. 5. 2012 15:08)

Chtěl jsem se zeptat, jestli se u nových NetteAddons počítá stím, že aktuální demo daného addonu bude na serveru nette?

Doplněk:
https://componette.org/search/?…

Demo:
https://componette.org/search/?…

Osobně si myslím, že by to byla dobrá věc a zároven by se předešlu tomu, že expiruje doména nebo někdo smaže demo na své doméně ..........

Kvůli bezpečnosti, výkonu a dalším potenciálním problémům se nic takového neplánuje.

Ještě jsem nad mou vizí addonů a instalátoru addonů přemýšlel. V bodech, další návrhy a úvahy:

0. Možná lepší než instalace přes panel debugbaru by byl samostatný addon AddonsManager, který by do projektu přidal modul, administrace by byla přehlednější. Přístupný by byl standartně pouze v development módu, s možností aktivace pro admina, ale to už je spíše detail, který by si každý mohl nastavit po svém.

Z hlediska mé vize je pro mne klíčové:

1. Rozdělení addonu dle typu, respektive, jednoznačná identifikace funkčnosti tříd

• panel
• helper
• macro
• modul
• component
• form control
• other

důležité pro:

1. možnost automatické instalace
2. přehled

je samozřejmě, že jeden addon v sobě může mít např. modul , componenty i helpery, ale rozhodně bych chtěl mít možnost si jednoduše a přehledně vypsat jaké všechny macra/helpery, atd. jsou v aplikaci k dispozici

Uvažuji, jestli je nutné to definovat nějak explicitně, ale asi to bude lepší, v některých případech to lze zjistit z kódu, dle toho jakou třídu dědí nebo jaké rozhraní implementuje, ale například helper takto identifikovat možné není.

Jednoduché addony by se registrovaly standartními postupy, složitější addony by pravděpodobně potřebovaly vlastní compilerExtension

2. Addony by měly mít pravidla pro namespace, navrhuji: <Vendor>\<AddonType>\<Addon>\<a dál už je to na každém>
důležité pro:

1. jednoznačně určen původ i funkčnost třídy
2. snadno zapomatovatelená konvence
3. přehlednou dokumentaci API projektů

3. Addon by měl nějakým způsobem předat AddonsManageru všechny možné parametry nastavení, včetně výčtu možných voleb – pokud jde u konkrétního parametru o seznam možností

důležité pro:

1. mou vizi GUI
2. zároveň tak bude mít každý jednotné vodítko přímo v kódu addonu, jaké parametry v config.neon může ovlivňovat

Tak bude možné aby nastavení mohlo být v režii AddonsManageru, bylo univerzální a samotný Addon by nemusel nic takového řešit a zároveň uživatel by nemusel editovat config.neon, nastavování by bylo přes GUI

4. Moje představa, co může být addon

• samostatná třída, dle bodu 1.
• kolekce vylepšení, např. několik helperů (helper loader) + macro + několik rozšířených Controls pro formuláře
• I moduly mohou být jako addon (případně několik modulů)

5. samozřejmě addon může obsahovat i js, css, images, a to je samostatná kapitola jak vše zpřístupnit automaticky pro frontend

Pravděpodobně by mělo být několik možností, např.

1. popis, co je nutno nakopírovat do wwwDir
2. automaticky s použitím WebLoaderu, pokud je instalován

…
nějaké další…?
v tomto mám zatím nejméně jasno

6. Pokud by mohl být jako addon brán i samostatný helper, mohl by AddonsManager implementovat HelpersLoader pro takové samostatné helpery, aby nebylo nutné psát kvůli jednomu helperu v addonu samostatný helper loader, případně by to mohl být standard a tento integrovaný helper loader by mohl být preferovaný i pro kolekce více helperů. (to už je asi jen detail) Takže by v zásadě byly jen dva HelpersLoadery, originální Nette a AddonsManager::HelpersLoader

7. Pro to, aby to bylo skutečně usnadněním, bych sepsal kuchařku/pravidla pro tvorbu addonu pro jednotlivé typy

• například pro možnost automatické instalace bez nutnosti jakéhokoli psaní kódu, je nutné v addonu získat aktuální presenter přes application a ne tím, že se vloží registrace addonu do BasePresenteru, atp.
• tyhle pravidla/návody by se doplňovaly, dle reálných potřeb a zkušeností

Další body k řešení:

8. Addony a PHP 5.2 (bez namespace)

• podporovat/nepodporovat?
• souvisí s následujícím bodem
• teoreticky by se dalo řešit alespoň u jednoduchých addonů automaticky

9. Addony a verze Nette
Předpokládám, že by se vše řešilo pro aktuální verzi Nette, ale co v budoucnosti, co když budou potřeba nějaké zásadní úpravy pro funkčnost ve verzi Nette 3.0. A jak si autor addon snadno otestuje, jestli funguje ve verzi nette 2.0, 2.0.3, 2.1, 2.5, 3.0, 3.3.3 ?

Mám v hlavě možné řešení, o tom se nebudu zatím rozepisovat, dokud nebudu mít funkční „proof of concept“. Jen jednou větou. Uvažuji o vytvoření něčeho s pracovním názvem „Single Click Sandbox“ (nejen pro Nette). Pak by funčnost addonu mohla být otestována s minimálním úsilím na více verzích Nette během pár minut, za předpokladu, že by byly addony realizovány v souladu s předchozími body. A AddonsManager by vše usnadnil.

Co jsem ještě nepromýšlel:

10. Routování, šablony …

• jak?

11. Závíslosti, povinné a volitelné

• jak?
• myslím si, že composer.json vše nedokáže podchytit

Celý koncept píšu s tím, že AddonsManager naprogramuji, ale myslím si, že všechny body, ke kterým jsem dospěl, dávají smysl i v případě manuální konfigurace.

Nějak takto si to udělám každopádně pro sebe, ale pokud se vám něco líbí/nelíbí, máte připomínky nebo další postřehy/požadavky, tak prosím pište, ať vše mohu vzít v potaz už při návrhu.

V příštích měsících budu psát desítky vlastních addonů všech typů a během toho bych mohl tento koncept dotáhnout k „dokonalosti“.

Editoval LeonardoCA (27. 5. 2012 23:35)

LeonardoCA napsal(a):

Hurvínku, klid.

**0.

Ehm…

Juan napsal(a):

Za prvé „instalace addon v config.neon“ – to je nesmysl. Addony musí být načteny mimo config.neon, aby mohly přidávat své CompilerExtensions.

1. Rozdělení addonu dle typu

Zbytečné.

2. Addony by měly mít pravidla pro namespace

Zbytečné. Jediným pravidlem je, že nesmí být v namespace Nette.

3. Addon by měl nějakým způsobem předat AddonsManageru všechny možné parametry nastavení, včetně výčtu možných voleb

Zbytečné. Máme rozšíření containeru.

5. samozřejmě addon může obsahovat i js, css, images…

Na to by měla existovat komponenta, která bude buď tyto soubory kopírovat do public www/, nebo je bude „streamovat“ (na devu, třeba). Což je Assetic nebo WebLoader.

11. Závíslosti, povinné a volitelné

• myslím si, že composer.json vše nedokáže podchytit

Myslíš si špatně.

… pokud …, máte připomínky …

Nette je Framework, tvoje GUI na pluginy by muselo být nepovinným pluginem ;)

Přestaň vymýšlet kolo a rozhlédni se kolem. Dle mého je naprosto nejlepší řešení přečíst si tento článek a upravit pravidla, která fungují a používají je tisíce projektů, pro potřeby Nette.

Editoval HosipLan (28. 5. 2012 11:11)

@**juzna.cz**: Tobě to nepřijde jako zbytečně dynamické? Tohle je přeci perfektně dostačující řešení.

@**vojtech.dobes**: nejjednodušším řešením je udělat druhý konfigurační soubor

doctrine: Kdyby\DoctrinePackage\DI\OrmExtension
...

$configurator->onCompile[] = function ($configurator, $compiler) {
	$exts = Nette\Utils\Neon::decode(__DIR__ . '/config/compilers.neon');
	foreach ($exts as $name => $class) {
		$compiler->addExtension($name, new $class());
	}
};

Hotovka :)

A když na to dojde, tak by se to dalo šoupnout do jednoho configu

$configurator->onCompile[] = function ($configurator, $compiler) {
	$config = Nette\Utils\Neon::decode(__DIR__ . '/config/config.neon');
	foreach ($config['compilers'] as $name => $class) {
		$compiler->addExtension($name, new $class());
	}
};

Dalo by se to nacpat sem, ale moc se mi to nelíbí. Jedině nepovinně, onCompile musí pořád fungovat!

Editoval HosipLan (28. 5. 2012 12:44)

LeonardoCA napsal(a):

3. zbytečné
Zbytečné. Máme rozšíření containeru.

Nemáš pravdu. To mi nesdělí výčet konfiguračních parametrů, včetně možných hodnot.

To je pravda, ale takovou konvenci si můžeš zavést.

interface IOptionsProvider
{
	/** @return array */
	function getAvailableOptions();
}

A compiler ti volitelně vrací volby. Né každý compiler totiž potřebuje nastavovat :)

Hned první podkapitolu článku popíráš svou odpovědí na můj bod č. 2.

Dovolil bych si oponovat. Symfony má konvenci „Bundle třídy“, které se ptá, co je zač ona a ten konkrétní addon. Přepsáním dvou metod tedy můžeš dosáhnout naprosto libovolného reálného jména třídy a odlišeného pojmenování v aplikaci. Což je sice hloupost, ale jde to a dokazuje to, že je to pouze doporučením, né nařízením ;) O což mi šlo.

Nemám rád nařízení, mám rád doporučení ;)

jj, už se blížíš tomu co chci dosáhnout

Já se tomu moc blížit nechci, já chápu o co ti jde, ale mám to dávno vyřešené :)

Editoval HosipLan (28. 5. 2012 14:29)

LeonardoCA napsal(a):

Ještě úplně naokraj ke Kdyby – také mne moc nelákalo se tím zabývat, z principu, protože je označen jako framework. Chci používat framework Nette, ne Kdyby. Vím že tam máš některé věci parádně vymyšlené a realizované. To už je psychický blok – proč používat nějaký nástavbový framework? Kdyby bylo Kdyby jako addon, tak bych mu asi věnoval více pozornosti.

Na okraj: Kdyby je primárně CMS a jako takové bude mít vymazlené GUI na addony. To že je rozdělené na více částí kvůli praktičnosti není podstatné :)

Blbost. V Composeru můžeš mít naprosto jakoukoliv adresářovou strukturu

samozřejmě, šlo mi jen o to, ať se v tom dá rozumně orientovat, když si vygeneruju dokumentaci

U composeru jsem přehlédl „suggested“ – a to je věc, kterou jsem potřeboval, takže už v tom mám jasno

Otázka – má jít podle vás přidat dvakrát stejný addon? V Symfony to nejde, v Kdyby tuším také ne.

Pro – dokážu si představit, že by někdo chtěl mít stejný addon několikrát s různým nastavením.

Ale…
 – pokud by to nešlo, usnadnilo by to spoustu věcí
 – v mnoha případech by to stejně nešlo, protože pokud addon přidává služby, které jsou autowired, docházelo by ke konfliktům
 – stejně by to podle mě měl řešit addon (např. více entity managerů pro Doctrine a podobně)

Editoval Juan (2. 6. 2012 22:18)

Tak jsem to ještě překopal, přidal eventy aplikace a pár dalších vychytávek. Dost jsem se inspiroval Kdyby, asi bych ti měl dát do kódu mention :)

V čem je výhoda custom-installeru? Moc jsem to nepochopil (proč by se nemohl composer používat klasickým způsobem?). Sekce extra… to by asi chtělo se napřed pořádně zamyslet, co za informace by se tam mělo dávat. Podle mě se základní addon obejde snadno bez této sekce i bez addon.neon. Prostě:

class TestAddon extends Nette\Addons\Addon
{
	// the default addon name will be resolved from the class name - "test"

	// registrace nějakých extensions
	// registrace nějakých eventů
	// atd.
}

Vůbec nechápu, co řešíš. Composer naprosto dostatečně zvládá řešit závislosti mezi balíčky. Pokud mám balíček, který vyžaduje jiný balíček, Composer to vyřeší.

Modulový systém s klikátkem nikdo dělat nechce nebo alespoň mně osobně klikátko vůbec nezajímá, snažím se prosadit do Nette naprosto univerzální modulárnost. První krok jsem vyjádřil jednoduchým PR na GitHubu, dále by šlo především o vyřešení routování na presentery jednotlivých addonů a načítání jejich templates. Už po těchto dvou krocích bychom měli velice silný (ale zároveň velmi jednoduchý) systém pro modulárnost Nette.

Pokud máš pocit, že modulárnost nějak souvisí s klikáním, tak doporučuju přešíst alespoň toto.

CompilerExtension je prostě extrémně silná zbraň právě pro modulárnost, zavedení podpory addonů zdaleka nemusí být tak složité, jak by se mohlo zdát a myslím, že už by se s tím konečně něco mělo začít dělat.

custom-installer je mozne pouzit napr pro zkopirovani assetu (css/js) na spravne misto aplikace, aby byly dostupne. Tedy jako mozna alternativa k Assetic/WebLoader.

Predtim jsem si myslel, ze by se pri instalaci mohl addon i zaregistovat (tzn pridat napr radek co config.neon), ale to nakonec neni pekny napad (je spatne, aby mi neco upravovalo muj kod).

Navic by se pri instalaci mohl instalator zeptat, zda a kam se ma nainstalovat. Napr. VisualPaginator by se mohl zeptat, zda ma nainstalovat dodavane css, nebo zda si uzivatel doda svoje vlastni. Pokud by clovek zvolil moznost dodavane css, tak by jej VisualPaginator pridal do WebLoaderu.

Editoval juzna.cz (31. 7. 2012 13:41)

Motivace

Moje predstava pro workflow je takova:

1. Pridej addon do composer.json
2. nainstaluj jej pomoci composer update
3. pouzivej addon – je jiz nastaven a pripraven k pouziti.

Tedy zadne dlouhe postupy, jak addon instalovat, kam do nakopirovat, na jake zavislosti nezapomenout atd. O to by se mel postarat composer a nette. O pomoc s instalaci by se mel postarat custom-installer, ktery jem jiz zminoval, a o kterem se rozepisu nize.

Addon sandbox

Na zkousku jsem vytvoril novy sandbox, ktery by mel ukazat postup, jak jednoduche je pouzit addony v Nette. Momentalne to tak jednoduche neni, jak se bude podpora zlepsovat, tak by se mely commity menit a zjednodusovat. Napr WebLoader je momentalne nutne rucne pridat jako sluzbu, ale to by se melo radeji udelat samo pouhym nainstalovanim addonu.

Addon ukazky

Vzal jsem par existujicich addonu a predelal je tak, aby byly mozne instalovat pomoci composeru.

• Visual Paginator (GitHub) – funguje
• Date Picker+ (GitHub) od Honzy Tvrdika – zatim je nutne doinstalovavat rucne, styly a js zatim nemam vubec vyresene
• Date Paginator (GitHub) – nutno dopomoci zavislostem
• NiftyGrid (GitHub) – nutno rucne pridat css+js+obrazky
• Kdyby CURL extension – nutne pridat rucne CompilerExtension
• WebLoader – nutne pridat rucne jako sluzbu

Custom-installer

Composer ma featuru zvanou custom-installer, tedy moznost pouzit vlastni skript pro instalaci balicku urciteho typu. Komplikovanejsi addony toho mohou vyuzit a dostat se na spravne misto. Balicek si tak bude moci nadefinovat napr:

• CompilerExtension pro DIC
• assets ktere se maji pouzit (napr. pomoci WebLoaderu)
• form extension metody
• debug bar panely
• … a dalsi

Pri instalaci addonu bude spusten nette-addon-installer (composer balicek), ktery tento informacim bude rozumnet a zavede addon na spravna mista (nejspis do addons.neon nebo config.neon, pripadne vykopiruje obrazky do www/).

Status

Nektere addony jde pridat uz nyni za pomoci samotneho composeru, jine potrebuji trochu rucni prace. Tu by bylo dobre odstranit primou podporou addonu.

Problemy

Nejvetsim problemem se mi zdaji assets/resources, tedy css+js+obrazky.
JavaScripty je mozne vyresit pres WebLoader. U CSS to bude horsi, protoze muzou mit relativni cesty napr na obrazky a ty by se spojenim rozbily. A jak resit obrazky samotne a pripadne jakekoliv jine zdroje (web fonts, flash, …) me nenapada zatim vubec.

Zavislosti na JavaScriptovych knihovnach – jak udelat zavislost addonu napr na jQuery, jQuery UI, netteForms…? Udelat je take jako addony?

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