Nette addons, konvence a architektura aplikace

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Jan Jakeš
Člen | 177
+
0
-

Po delším používání jiných frameworků než Nette (zejména Symfony) mi v Nette opravdu chybí některé věci, které jsou podle mě pro větší weby naprosto zásadní (Nebudu zde rozebírat, co mi chybí v Symfony, protože mým cílem je zlepšit Nette).

Naprosto zásadní je nějaká konvence pro architekturu aplikace a addony (balíčky, extensions).

Ve světě Symfony máme Bundles, každý Bundle má stejnou strukturu, ve světě Nette jsou kódy většiny addonů naprostý bordel. Ve světě Symfony se Bundle nainstaluje přidáním jedné řádky do jakéhosi bootstrapu, ve světě Nette někdy do BasePresenter, někdy je potřeba vytvořit komponentu, někdy je potřeba zkopírovat několik věcí na různá místa.

Nette nemusí vyžadovat Doctrine ani jiné konkrétní knihovny, ale rozhodně může poskytovat nějakou naprosto základní podporu pro addony. Co je podle mě základní podpora?

  1. jednotné místo jednořádkové instalace addonů (bootstrap nebo speciální neon soubor)
  2. jednotné pojmenovávání addonů ve stylu „Vendor.AddonName“ (a pak opravdu přidat addon např. jednou řádkou v composer.json a jednou řádkou do aplikace)
  3. základní nadtřídu Addon (anebo rozhraní), poskytnutí verze, cesty do adresářů addonu (pro assety/resources)
  4. jednotné odkazování na addony (@MyAddonProject.MySuperAddon) ať už do jejich adresářů nebo například do DI kontejneru, kde by každý addon mohl mít jasně definované místo/namespace
  5. jednoná možnost, kam v addonu umisťovat presentery a jak na ně routovat + automaticky načítat šablony
  6. případné načítání konfigurace addonu, atd.
  7. určitě jsem na něco zapomněl :)

Shrnuto, podtrženo – definice addonu vyžadovaná ze strany Nette by podle mě tedy měla definovat názvosloví, adresářovou strukturu a načítání addonů do Nette. Nette by mělo poskytovat přístup k addonu a routování na jeho presentery, pokud nějaké má. Velmi jednoduchý addon by mohl mít například pouze jednoduché Extension pro kontejner, složitý by mohl být v podstatě webovou aplikací.

Stačila by naprosto základní a jednoduchá podpora a zavedení konvencí, žádné šílenosti, žádné závislosti na Doctrine ani Assetic, ani ničem podobném. Takto pak může vzniknout DoctrineAddon nebo AsseticAddon a jiné addony na těchto budou záviset (na to už máme Composer).

Sepsal jsem to v rychlosti, nepromýšlel do detailů, protože nevím, jestli můžu počítat s tím, že by se něco takového v Nette někdy objevilo. Co mě teď zajímá – bude se něco takového v Nette řešit nebo s tím vůbec nemám počítat?

Pokud ano, můžeme sepsat nějaké RFC a vše prodiskutovat.


A co se týče architektury aplikace, asi bych byl pro používání těchto addonů 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.)

P.S.: Vím, že to řeší Kdyby, vím, že to řeší moc pěkně (ale také momentálně příliš svázaně), ale zajímá mě, jestli to někdy hodlá řešit Nette. Pracuje je se na novém weby pro Nette doplňky, takže by bylo načase. Ale možná je třeba se zamyslet, jestli to vlastně nesouvisí i s plánovanou dekompozicí samotného Nette. Symfony je podle mě v tomto o krok napřed, i když v mnoha věcech je naopak pozadu.

Jan Tvrdík
Nette guru | 2595
+
0
-

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 :)

Jan Jakeš
Člen | 177
+
0
-

Zajímalo by mě hlavně od Davida, jestli je nějaká ochota to řešit.

Máme DI, máme Composer a řešení addonů v tomto stylu opravdu začíná dávat smysl. A možná by se mohl vymyslet i speciální název pro addony, např. Naddon. Každý by tak věděl, že DoctrineNaddon je pro Nette (stejně tak, jako dnes každý Bundle je pro Symfony).

nanuqcz
Člen | 822
+
0
-

+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.

vvoody
Člen | 910
+
0
-

Berte ma s rezervou, s inym frameworkom nemam skusenost, takze asi niesom ta spravna osoba co by sem mala prispievat, no aj tak mam nutkanie napisat „zopar“ ;) slov.

Pod addonom pre framework si predstavujem drobnosti ako rozsirenie formu o nejaky novy prvok az po uroven komponent, napriklad taky datagrid. Ak by to malo zasahovat az po router a malo to mat nejaku pevnu konvenciu ktora dovoluje robit tie drobne addony a sucastne cele moduly aplikacie tak mam celkom strach, ze by z toho vznikol nejaky moloch. Clovek sa zas bude musiet ucit nejake konvencie ktore povymyslate. Radsej by som bol keby sa jednoznacne urcila hranica medzi modulom a addonom a riesila sa ich konvencia samostatne – spajanie jednotlivych modulov + vkladanie addonov do modulov. Takto by sme mali Naddon a Nmodul :)

Otazka len tak na okraj, nesnazime sa tu pretvarat nette na CMS? Nemalo by sa toto riesit prave pri projektoch ako Kdyby? Vymyslat konvencie a developovat moduly a pluginy pre ne? Na Nette milujem tu volnost a jednoduchost, neberte mi ju :) ak sa ju podari zachovat tak mate moje skromne, nikohonezaujimajuce pozehnanie ;)

Jan Jakeš
Člen | 177
+
0
-

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í.

nanuqcz
Člen | 822
+
0
-

Ten rozdíl addon/modul podle mě není tak velký.

Mě jde konkrétně o jednu vlastnost, která se mi na modulech Nette strašně líbí. Mějme klasické rozdělení AdminModule a FrontModule:

FrontModule
	@layout.latte
	ArticlesModule/
		...
	UsersModule/
		...
AdminModule
	@layout.latte
	ArticlesModule/
		...
	UsersModule/
		...

Pokud například v AdminModule\UsersModule\ nemám vytvořený @layout.latte, tak se automaticky použije ten z vyššího modulu, tzn AdminModule\@layout.latte. Je tak jednoduše a hlavně automaticky vyřešený problém, kdy chci mít v celé administraci jeden vzhled.

Naproti tomu v tvojí architektuře by to jednoduše nešlo

ArticlesNaddon\
	AdminModule\  # odkud se vezme společný layout pro administraci?
	FrontModule\
UsersNaddon\
	AdminModule\
	FrontModule\

Musel bych přepisovat formatTemplateLayoutFiles a kdoví co ještě. Z toho důvodu si myslím, že tato struktura je v základu špatná a časem by možná přinesla i další problémy, ne jen ty se šablonami.

Editoval nanuqcz (8. 5. 2012 23:29)

Jan Jakeš
Člen | 177
+
0
-

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 :)

Patrik Votoček
Člen | 2221
+
0
-

Juan napsal(a):

1. jednotné místo jednořádkové instalace addonů (bootstrap nebo speciální neon soubor)

bootstrap.php

2. jednotné pojmenovávání addonů ve stylu „Vendor.AddonName“ (a pak opravdu přidat addon např. jednou řádkou v composer.json a jednou řádkou do aplikace)

Nette Addons 2.0 má každý addon povinně něco co jsme (pracovně) nazvali ComposerID (<vendor>/<name>) vpodstatě se jedná o to co se píše do composer.json pokud chcete na něco přidat závyslost.
tj. přidání jednoho řádku do composer.json

a samotná aktivace: viz třeba mé addony:

// bootstrap.php

// tyto řádky se přidají před $container = $configurator->createContainer();

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

3. základní nadtřídu Addon (anebo rozhraní), poskytnutí verze, cesty do adresářů addonu (pro assety/resources)

mám několik addonů a popravdě nepotřeboval jsme řešit nějaké cesty do adresářů. Co se týká „nadtřídy“ Addon tak vpodstatě existuje jen se jmenuje jinak Nette\Config\CompilerExtension.

4. jednotné odkazování na addony (@MyAddonProject.MySuperAddon) ať už do jejich adresářů nebo například do DI kontejneru, kde by každý addon mohl mít jasně definované místo/namespace

tohle jsem nepochopil…

Jan Jakeš
Člen | 177
+
0
-

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.

Patrik Votoček
Člen | 2221
+
0
-

Juan napsal(a):

To, že si to ty nepotřeboval, pro mě není žádný argument.

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

Tady opravdu pleteš jablka s hruškama, zrovna od tebe bych tohle nečekal.

Nemyslím si. Dále se pokusím rozvést proč…

To jsi nikdy neviděl Kdyby nebo Symfony?

Právě že viděl a nelíbí se mě. Proto imho nic takového v #nellafw nemám.

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…).

Nesouhlasím. Co by měl dělat typický addon? Někam se registruje, nastavuje nějaké proměnné, přidává nějaké služby do DIc (neřešme teď zda to dělá prostřednictvím sama sebe nebo nějáké další třídy – např. CompilerExtension).

Nevím, proč si myslíš, že by každý addon měl mít ComplierExtension …

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

… a zároveň žádný nějaké obrázky, csska, atd.

Kde něco takového tvrdím?

(Asi proto, že takto vypadá tvých pár addonů?).

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

Addon může být cokoliv – část aplikace, datagrid, formulářové komponenty a mnoho dalšího.

Souhlas ani nikde netvrdím opak.

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)

Stejně jako já nevidím důvod proč by každý addnon měl mít AddonClass / ExtensionClass / PackageClass.

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.

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í).

Proč o tom celém mluvím? Protože se snažím více myslet tak abych „zbytečně“ nerozšiřoval API frameworku kvůli pár okravým případům (to je věc která se mě na Symfony / Doctrine moc nelíbí – spousta tříd které se možná někdy můžou hodit).

Ostatně ke snaze řešit věci bez boptnání API mě naváděl sám David https://github.com/…tte/pull/323#….

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?

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.

Jan Jakeš
Člen | 177
+
0
-

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).

Patrik Votoček
Člen | 2221
+
0
-

Juan napsal(a):

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).

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

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.

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…

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.

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.

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);
}

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

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.

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

Jan Jakeš
Člen | 177
+
0
-

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…

jasir
Člen | 746
+
0
-

Vidím, že tu urputně diskutujete, tak nechci nějak urputně vstupovat, ale stejně jako Juan si myslím, že toto Nette extrémně chybí a rozhodně se to nedá nahradit CompilerExtension. Možná by bylo fajn, kdyby Juan zkusil sepsat nějaké RFC?

juzna.cz
Člen | 248
+
0
-

@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.

juzna.cz
Člen | 248
+
0
-

@Juan: zkus vzit 5 addonu, ktere pouzivas, plus 10 dalsich nahodne vybranych, shrnout co potrebuji k instalaci do nette projektu a pripadne pro ne navrhnout nejake addon.neon. Budeme tak mit konkretni priklady a zaroven i slusnou generalizaci ;) Od toho se bude lepe pokracovat.
(zkusim se na to take mrknout, ale ted mam rozpracovanou jinku cast nettefw ktera me pali vic)

Jan Jakeš
Člen | 177
+
0
-

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ý…

nanuqcz
Člen | 822
+
0
-

Juan: Držím palce, na nějakou defaultní podporu pro addony se už fakt těším, pokud to vyjde ;-)

LeonardoCA
Člen | 296
+
0
-

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.

  1. určitě
  2. 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)

LeonardoCA
Člen | 296
+
0
-

Teď mne napadla další výhoda implementace čistě přes config.neon. Pokud by se například všechny panely debug baru registrovaly takto jednoduše, bylo by možné napsat plugin, kde by se dalo přes checkboxy nastavit, které panely chci mít momentálně aktivní.

Přijde mi zbytečné, aby se při každém renderování stránky renderovaly všechny panely, když většinu z nich 90% času nevyužiju. Případně by se to dalo udělat rychlé přepínání na jedno kliknutí vybrané panely/všechny panely.

MartinitCZ
Člen | 580
+
0
-

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ě ..........

Jan Tvrdík
Nette guru | 2595
+
0
-

martinit wrote:

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?

Ne, např. kvůli bezpečnosti.

Patrik Votoček
Člen | 2221
+
0
-

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

LeonardoCA
Člen | 296
+
0
-

drobná poznámka k

Otazka len tak na okraj, nesnazime sa tu pretvarat nette na CMS? Nemalo by sa toto riesit prave pri projektoch ako Kdyby? Vymyslat konvencie a developovat moduly a pluginy pre ne? Na Nette milujem tu volnost a jednoduchost, neberte mi ju :) ak sa ju podari zachovat tak mate moje skromne, nikohonezaujimajuce pozehnanie ;)

Na jednu stranu příspěvek chápu, taky nemám moc rád konvence. (v ničem), ale…

Volnost nikdo nebere, svoje neveřejné addony, si může každý tvořit jak chce a přidat si je do projektu třeba 100 řádky v bootstrapu a na 10 dalších místech. Ale pokud má být addon „ready to use“ pro kohokoli, tak musí dodržovat konvence, jinak si stejně bude muset každý takový „volně psaný“ addon upravovat, aby mu seděl do jeho „volně psaného“ projektu.

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

LeonardoCA
Člen | 296
+
0
-

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)

Jan Jakeš
Člen | 177
+
0
-

Nemám teď čas to pořádně číst a podrobně se k tomu vyjadřovat, ale podle mě trochu motáš jablka s hruškama.

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. To, že místo jejich vyjmenování v bootstrap lze zavést něco jako addons.neon, to už je detail a kosmetická vychytávka.

Za druhé „addon bez nadtřídy, ale s addon.neon“ – zamýšlel ses nad tím, jak by to bylo použitelné? Takto by Nette ani nevědělo, kde addon.neon hledat. A přidávání addonu ve stylu vendor/addon/libs/myVendor/myAddon/addon.neon je fuj. Daleko více se mi líbí new MyVendor\MyAddon\MyAddon() nebo MyVendor\MyAddon\MyAddon do nějakého toho addons.neon. Jinak řečeno – přidáváme třídu addonu a je nám jedno, kde tato třída je. Stačí, když jí umí jakýkoliv loader načíst. Přístup do složky addonu, k jeho assets, konfiguraci, atd. poskytne tato třída a to tak, že ve výchozí implementaci a pro jednoduchý addon by ji klidně stačilo mít pouze poděděnou a prázdnou.

Za třetí, tvoje nápady s GUI a podobně jsou hezké, ale vůbec to nesouvisí s architekturou addonů v Nette. Nejdřív je potřeba vymyslet jednoduché, elegantní a dobře rozšiřitelné addony, a jestli pak nad nimi někdo postaví GUI a klikátka, to je věc, která s tím vůbec nesouvisí. Do tohoto tématu bych to nepletl.

Editoval Juan (28. 5. 2012 10:37)

Filip Procházka
Moderator | 4668
+
0
-

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
Člen | 248
+
0
-

Addony by se klidne mohly registrovat v config.neon, napr v sekci addons. Ta by se zpracovala jeste pred kompilaci a tudiz by mohla pridat vlastni CompilerExtensiony.

Presne na to se hodi udalost Configurator::onCompile, ktera se vsak momentalne nedostane ke konfiguraci – bylo by potreba ji pridat dalsi parametr.

(Btw „prednostne“ se jiz zpracovava sekce includes; podobnou prednost by mohla ziskat i jina vyjimecna sekce)

Filip Procházka
Moderator | 4668
+
0
-

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

Vojtěch Dobeš
Gold Partner | 1316
+
0
-

Snad jediná věc by byla fajn, aby se mohly extensions přidávat v configu. To navěšování na onCompile[] teď opravdu musí být venku, ne?

Filip Procházka
Moderator | 4668
+
0
-

@**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
Člen | 296
+
0
-

Juan:

podle mě trochu motáš jablka s hruškama.

Může se stát, proto sem píšu, abych si věci ujasnil, jinak bych rovnou realizoval.

Za prvé „instalace addon v config.neon“ – to je nesmysl.

Všechno jde, když se chce, viz. komentář juzna.cz – „instalaci“ přes config.neon chápe skoro stejně jako já. Možnost přidat compilerExtension jen pomocí zápisu do sekece Addons config.neon bez nutnosti psát cokoliv do bootstrapu je základem mé myšlenky. Detaily reailizace je nutné promyslet.

Za druhé „addon bez nadtřídy, ale s addon.neon“ – zamýšlel ses nad tím, jak by to bylo použitelné?

kde jsi přišel na „vendor/addon/libs/myVendor/myAddon/addon.neon“ ?

  • Pokud vím tak composer používá adresář vendors a nette libs, tj. cesta by byla buď

vendors/vendor/[addontype]/addon případně libs/vendor …

  • Jinak si nerozumíme a přidání by bylo realizované tak jak píšeš jen přidáním třídy, jen konfigurace by byla místo třídou realizována přes addons.config.neon
  • Moje nápady s GUI předpokládají dostupnoust určitých informací, pokud možno bez duplicit a práce navíc, protože vím, co mi v současné verzi addonů a nette chybí a je to jen málo, tak to zmiňuji, protože jinak by jste napsali k některým mým požadavkům „Zbytečné“.

Hosiplan:
:-)

1. Zbytečné.

  • možná ano, možná je to subjektivní.
  • rozdělení by v zásadě pomohlo pro body 6. 7. a podobné (pak mám další důvody, ale ty jsou v sekci, „bude se možná jednou hodit“, proto je nepíšu)

2. zbytečné

  • když myslíš

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.

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

Souhlas. Píšu o tom jen proto, aby jste pochopili důvody pro některé „zbytečné“ požadavky.

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

Jedině pokud to bude zcela dynamické je možné uvažovat o něčem jako popisuju v bodech 8. 9. Teoreticky by se dalo testování funkčnosti addonu na různých verzích nette/php,atd. zcela automatizovat, ale to už je zatím za hranicí i mé fantazie.

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.

dík za odkaz, v podstatě nemám připomínek, kromě těch pár drobných, které jsem si domyslel pro „mé“ potřeby. (btw. Hned první podkapitolu článku popíráš svou odpovědí na můj bod č. 2.)

$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());
        }
};

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

Editoval LeonardoCA (28. 5. 2012 13:55)

Filip Procházka
Moderator | 4668
+
0
-

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
Člen | 296
+
0
-

Možná nakonec dojdu k tomu, že něco jako ta Bundle třída v Symphony, je nejlepší řešení. Pro jednoduché addony mi přišla zbytečná, ale asi by bylo lepší ji mít jednotně.

Hosiplan:
díky za odkazy, na Kdyby už jsem částečně narazil, sledoval jsem i nějakou přednásku z Planette videí, ale konkrétně tyhle informace na fóru jsem neviděl, projdu si.

Nevymýšlím řešení pro ty co už to mají vyřešené.

Vymýšlím koncept jasnější a jednodušší pro ty, kteří s Nette/PHP/OOP začínají a než pochopí funkčnost i důvody a výhody tvého nebo jiného řešení, tak budou potřebovat půl roku studia. Prostě dokud tomu co například Kdyby řeší nerozumím, tak ani nevím, proč bych to měl chtít řešit. A to je také důvod, proč jsem tvé příspěvky, které jsi mi připomenul nepostřehl nebo ignoroval.

Když nový uživatel uvidí nabídku, nainstalovat Addon, a bude to fungovat, tak jim bude jasné o co jde a snadno to využije.

Právě pro ty, chci vytvořit GUI

A protože jsem sám „začátečník“ s Nette 2.0 a narazil jsem stejně jako wasill ,že jakákoli maličkost je při prvním pokusu na hodiny a hodiny studia a pokusů, i když řešení je pak na pár minut.

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.

Děkuji všem za komentáře.

Co se týče doporučení vs nařízení mám na to stejný pohled, možná jsem některé myšlenky špatně formuloval. Za vším je, že se pokouším nějak dostat do frameworku, addonů pár drobností, které mi pak umožní „čarovat“.

Můj závěr je, věci navíc si realizuji po svém, zveřejním demo verzi a pokud to bude vypadat použitelně a někdo bude chtít využívat výhod a možností, které to otevře ve svých addonech, dořeší se detaily až potom.

Filip Procházka
Moderator | 4668
+
0
-

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é :)

Jan Jakeš
Člen | 177
+
0
-

Souhlasím s HosipLanem ve všech směrech.

Pokud vím tak composer používá adresář vendors a nette libs, tj. cesta by byla buď…
vendors/vendor/[addontype]/addon případně libs/vendor

Blbost. V Composeru můžeš mít naprosto jakoukoliv adresářovou strukturu (samozřejmě uvnitř nějaké složky, která se defaultně jmenuje vendors), ale vnitřní strukturu ti Composer nijak neurčuje a i když má PSR-0 loader, tak umí mapovat také libovolně uspořádané třídy podobně jako RobotLoader anebo tě nechá includovat vlastní loader, podobně jako to dělá Nette

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

Naopak, od toho Composer je a můžeme být rádi, že to řeší – verze a závislosti vůbec nemusí být řešeny ze strany frameworku. Naopak by to duplikovalo informaci a způsobovalo bordel.

Editoval Juan (29. 5. 2012 0:34)

LeonardoCA
Člen | 296
+
0
-

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

Jan Jakeš
Člen | 177
+
0
-

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

Čekám na vaše reakce, je to minimalistický první krok, nástin mojí přestavy o addonech.

Jan Jakeš
Člen | 177
+
0
-

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)

Filip Procházka
Moderator | 4668
+
0
-

Nevidím důvod, proč by to mělo jít. Addon může registrovat svoji komponentu jako factory do DIC – můžeš ji vytvářet libovolně několikrát s různým nastavením a pořád mít jeden addon.

Editoval HosipLan (2. 6. 2012 23:19)

Jan Jakeš
Člen | 177
+
0
-

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 :)

juzna.cz
Člen | 248
+
0
-

Btw addony by bylo mozne instalovat pres Composer pomoci custom-installeru a veskere nette-related veci by se uvedly v sekci extra. Diky tomu by mohla byt plna kompatibilita s composerem a nebylo by potrebovat rozdelovat (a duplikovat) informace do dvou souboru (composer.json a addon.neon)

Editoval juzna.cz (31. 7. 2012 12:12)

Jan Jakeš
Člen | 177
+
0
-

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.
}
repli2dev
Člen | 57
+
0
-

Na lehké „adony“ si strukturu představit dokážu, ale na velké celky sotva a už vůbec ne spravované composerem, poněvadž ten nezvládá importovat závislosti jiného balíčku (podbalíčky) a podle zadání nikdy umět nebude.

Nicméně z této diskuze spíš vyplývá, že z frameworku (tzn. knihovny) chcete udělat rovnou modulový systém s klikátkem ;-)

Editoval repli2dev (27. 7. 2012 21:54)

Jan Jakeš
Člen | 177
+
0
-

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.

Filip Procházka
Moderator | 4668
+
0
-

repli2dev napsal(a):

a už vůbec ne spravované composerem, poněvadž ten nezvládá importovat závislosti jiného balíčku (podbalíčky) a podle zadání nikdy umět nebude.

Nastuduj si prosím fakta.

Editoval HosipLan (28. 7. 2012 0:14)

juzna.cz
Člen | 248
+
0
-

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)

juzna.cz
Člen | 248
+
0
-

Melo by byt mozne vytvaret i velice jednoduche addony, ktere maji treba jen nekolik malo PHP trid. Prikladem budiz Kurzovnik CNB, ktery nepotrebuje zadnou obalovaci tridu CNBAddon; bohate by zde stacil composer.json. Ted otazka, zda to povazovat vubec za nette addon…

juzna.cz
Člen | 248
+
0
-

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.

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:

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)