Jak rozdělit Nette do samostatných projektů
- LeonardoCA
- Člen | 296
Taky jsem pro ponechat hlavní namespace Nette. Když nic jiného, jednoznačně na první pohled identifikuje, kde má ten daný osamostatněný projekt původ a může to pomoci zviditelnění frameworku.
- Patrik Votoček
- Člen | 2221
Ponechat Nette\Latte
.
Kdysi jsem někde četl / slyšel jak to dělají kluci od Symfony a celkem se mě nápad líbí. Udělají knihovnu a pak k ní udělají ještě Bundle (samostatně). To znamená že knihovna je na Symofny nezávislá (neobsahuje „šum“).
- Filip Procházka
- Moderator | 4668
Nette\Latte
! Všichni používají komponenty ze Symfony a
nikoho nesere, že tam je Symfony\Component
před vším.
- jansfabik
- Člen | 193
Vyhovuje mi přístup, jaký teď používají formuláře
(Nette\Forms\Form
bez MVC vs.
Nette\Application\UI\Form
pro MVC). Myslím, že by ho mohlo
používat i Latte.
- Ve jmenném prostoru
Latte
by bylo samotné Latte, bez vazeb na jakýkoli framework (s výjimkou nette/core, kde by bylNette\Object
,Nette\Utils\Strings
apod.). - Ve jmenném prostoru
Nette\Latte
by bylo poděděné Latte (s přidanými makry specifickými pro Nette apod.). - Ve jmenném prostoru
ZendLatte
by bylo také poděděné Latte přizpůsobené pro Zend Framework.
Nechává to volný prostor pro přizpůsobení Latte i dalším
frameworkům. A je to zpětně kompatibilní se současným
Nette\Latte
(bez nutnosti cokoli přejmenovávat).
Editoval jansfabik (10. 10. 2012 21:30)
- Filip Procházka
- Moderator | 4668
jansfabik napsal(a):
- Ve jmenném prostoru
Zend\Latte
by bylo také poděděné Latte přizpůsobené pro Zend Framework.
Nikdo kromě vývojářů Zendu nemá co deklarovat třídy v namespacu Zendu.
- Filip Procházka
- Moderator | 4668
Imho je daleko lepší něco jako Nette\Latte
a
Nette\ZendBridge\Latte
.
Editoval HosipLan (10. 10. 2012 21:52)
- jansfabik
- Člen | 193
Ne každý chce s Latte používat i Nette Framework. Takže by se pak
musel vytvářet ještě nějaký ten Nette\Bridge\Latte
, ve
kterém by byla Nette makra. Mohl bych třeba chtít v jiném frameworku
používat své vlastní makro {link}
.
To řešení, kdy by se Latte
přesunulo do vlastního jmenného
prostoru a pak se používalo přes Nette\Latte
mi proto připadá
čistější.
- Filip Procházka
- Moderator | 4668
Však to je v pořádku. Jenže když bude Latte v samostatném namespace,
nebude dělat takovou reklamu. Proto je Nette\Bridge\Latte
, pro
makra frameworku, daleko lepší.
Minimalismus je super, ale všechno má své hranice.
- jansfabik
- Člen | 193
Nepřipadá mi to jako minimalismus, ale spíš jen jako čistý objektový návrh.
Myslím si, že mnohem větší význam při propagaci frameworku bude mít, když odkaz na dokumentaci povede na doc.nette.org, kde bude třeba vidět, jak se v Nette dají dělat formuláře, routování, cachování apod.
- Honza Marek
- Člen | 1664
HosipLan napsal(a):
Nette\Latte
! Všichni používají komponenty ze Symfony a nikoho nesere, že tam jeSymfony\Component
před vším.
+1
- Filip Procházka
- Moderator | 4668
Co má namespace společného s čistým objektovým návrhem? Správně, nic.
- Patrik Votoček
- Člen | 2221
Zdá se mě že všichni berou namespace Nette
jako Nette
Framework což ale není tak úplně pravda. Samotný framework je spíš
Nette\Application
a Nette
jako takové je spíše
vendor.
Imho instalovat se to stejně s největší pravděpodobností bude pomocí:
{
"requires": {
"nette/latte": "*"
}
}
Tak proč by tomu nemohl odpovídat i namespace
Nette\Latte
.
jansfabik napsal(a):
Vyhovuje mi přístup, jaký teď používají formuláře (
Nette\Forms\Form
bez MVC vs.Nette\Application\UI\Form
pro MVC). Myslím, že by ho mohlo používat i Latte.
- Ve jmenném prostoru
Latte
by bylo samotné Latte
Všiml sis že si protiřečíš? Nette\Forms
vs
Latte
.
- jansfabik
- Člen | 193
Možná, že čistý objektový návrh není ta správná fráze. Nelíbilo by se mi tohle:
$engine = new Nette\Bridge\Latte\Engine; // pro použití v Nette
$engine = new Nette\Latte\Engine; // mimo Nette
oproti
$engine = new Nette\Latte\Engine; // pro použití v Nette, navíc zpětně kompatibilní
$engine = new Latte\Engine; // mimo Nette
- Honza Marek
- Člen | 1664
Ta druhá varianta by byla asi těžko zpětně kompatibilní, když by v Latte zůstala většina tříd. Do toho Bridge patří cca 2 třídy – něco jako LatteFactory a NetteMacros, zbytek by měl zůstat v tom namespacu kde je.
- Filip Procházka
- Moderator | 4668
@jansfabik: Jenže to tě vůbec nebude zajímat, protože na to budeš mít CompilerExtension, který zaregistruješ a vůbec nebudeš namespacy řešit. Nejspíš nebudeš registrovat ani ten a bude se to dít samo, když budeš mít celé Nette ;)
Editoval HosipLan (11. 10. 2012 8:04)
- David Grudl
- Nette Core | 8199
Řekl bych, že každý vnímá označení „samostatný projekt“ dost odlišně.
Jednak to může znamenat
- jen to, že jde stáhnout samostatně přes composer a používat beze zbytku frameworku
- nebo naopak půjde skutečně o samostatný projekt s vlastním webem, vlastní API dokumentací atd.
Většina z vás tu používá celý framework a je jim v podstatě úplně jedno, že se něco osamostatňuje, spíš přivítají, když to bude znamenat minimum změn. Ale v tu chvíli nejste cílovou skupinou. Podobnou nechuť, jako ke změně Nette\Latte → Latte, byste měli ke změně Texy → Nette\Texy nebo dibi → Nette\Dibi.
Cílovou skupinou je člověk, který pravděpodobně používá jiný framework (třeba proprietární) nebo CMS. Zkuste se dívat na věc z jejich pohledu. A je vůbec fajn mít pod Nette prostory Zend nebo WordPress? Třeba i na api.nette.org?
- Honza Marek
- Člen | 1664
A je vůbec fajn mít pod Nette prostory Zend nebo WordPress? Třeba i na api.nette.org?
Proč jako na api.nette.org? Může existovat Nette\Latte + integrující balíky, kde latte bude součástí integrujícího balíku, nikoliv že latte bude obsahovat všechny existující integrující balíky. Pak není důvod, aby Nette framework obsahoval nějakou podporu Latte v Zendu, tudíž nechápu jak by se to mohl Zend na api.nette.org objevit.
Zkuste se dívat na věc z jejich pohledu.
Už jsem se koukal. Myslím, že je to podobná situace jako když používám Symfony\Console. Věru, nevadí mi, že se to nejmenuje nějakým „cool názvem“.
- Honza Marek
- Člen | 1664
Nevím, třeba Nette\LatteForZend. Jenže by tenhle namespace nebyl součástí Nette frameworku, takže by nepřekážel na api.
- Majkl578
- Moderator | 1364
Podobnou nechuť, jako ke změně Nette\Latte → Latte, byste měli ke změně Texy → Nette\Texy nebo dibi → Nette\Dibi.
Taková změna by mi naopak dávala smysl, za předpokladu, že obojí je od Nette / Nette Foundation.
Cílovou skupinou je člověk, který pravděpodobně používá jiný framework (třeba proprietární) nebo CMS. Zkuste se dívat na věc z jejich pohledu. A je vůbec fajn mít pod Nette prostory Zend nebo WordPress? Třeba i na api.nette.org?
Takového člověka přece vůbec nezajímá, jestli namespace bude Nette\Debug nebo třeba Nebug, pro něj je důležitá skutečnost, že to může použít samostatně. Tříštění do samostatných cool namespaců akorát způsobí zmatky bez přidané hodnoty.
Honza Marek napsal(a):
Už jsem se koukal. Myslím, že je to podobná situace jako když používám Symfony\Console. Věru, nevadí mi, že se to nejmenuje nějakým „cool názvem“.
Souhlasím.
David Grudl napsal(a):
A v jakém prostoru by ten bridge byl?
Třeba Nette\Bridges\Zend nebo NetteBridges\Zend*, důležité je, že by nebyl součástí Nette samotného, ale jen jako rozšíření (vpodstatě addon).
Editoval Majkl578 (11. 10. 2012 13:48)
- Patrik Votoček
- Člen | 2221
Honza i Majkl popisují to co jsem napsal už tady https://forum.nette.org/…iewtopic.php?…
Patrik Votoček napsal(a):
Ponechat
Nette\Latte
.Kdysi jsem někde četl / slyšel jak to dělají kluci od Symfony a celkem se mě nápad líbí. Udělají knihovnu a pak k ní udělají ještě Bundle (samostatně). To znamená že knihovna je na Symofny nezávislá (neobsahuje „šum“).
Tím samostatně je myšlen i samostatný repozitář.
- Vojtěch Dobeš
- Gold Partner | 1316
Vnímám, že nepatřím k většině :). Ale já jsem určitě zastáncem vtipného ne-Nettovského jména™. Mám rád Latte a rád ho uvidím jako samostatný projekt se samostatným webem. Přesně jako je Neon, kterýžto taky není propagovaný jako součást Nette. Nette je na něm úplně okrajové.
Je to krása vymýšlení názvu, dobrý originální název je určitě lepší než uniformní (je lépe zapamatovatelný). Latte, Neon, Anette… they all live in one happy Nette family :).
Editoval vojtech.dobes (11. 10. 2012 14:07)
- David Grudl
- Nette Core | 8199
Honza Marek napsal(a):
Nevím, třeba Nette\LatteForZend. Jenže by tenhle namespace nebyl součástí Nette frameworku, takže by nepřekážel na api.
Tedy by api.nette.org obsahovalo jen některé třídy z Nette. To je dost závažná komplikace, zváženo do důsledků.
- David Grudl
- Nette Core | 8199
Patrik Votoček napsal(a):
Kdysi jsem někde četl / slyšel jak to dělají kluci od Symfony a celkem se mě nápad líbí. Udělají knihovnu a pak k ní udělají ještě Bundle (samostatně). To znamená že knihovna je na Symofny nezávislá (neobsahuje „šum“).
To není zcela přesné: nezávislé je Symfony\Component, nikoliv Symfony.
- Honza Marek
- Člen | 1664
Pořád nechápu proč vnímáš třídy pro integraci Latte do Zendu jako součást Nette.
- David Grudl
- Nette Core | 8199
Vnímám je jako součást Nette\* a je jen otázka času, kdy někdo přijde
s dotazem, proč veřejná třída Nette\Abc\Xyz
není uvedená
v API dokumentaci a jako obvykle budu zase za blbce ;-)
- Honza Marek
- Člen | 1664
Takže když komunita vyrobí 10 integrací Latte nebo Debugu pro různé frameworky, tak všechen tenhle bordel bude k dostání na api.nette.org? To se mi moc nezdá.
- Jan Tvrdík
- Nette guru | 2595
Zamyslím se nad tím dneska večer pořádně, ale teď to vidím takto:
- pohled z composeru
- uživatel Nette Frameworku dá require
nette/nette
⇒ nic se pro něj nemění, zend bridge se nenainstaluje, nette bridge ano - uživatel Zendu dá require
nette/latte
&nette/latte-zend-bridge
⇒ nainstaluje standalone Latte & bridge pro Zend
- uživatel Nette Frameworku dá require
- jmenné prostoru
- vlastní Latte zůstane ve jmenné prostoru
Nette\Latte
- zend bridge bude ve jmenné prostoru
Nette\Latte\Bridges
- nette bridge bude v
Nette\Latte
(a bude otravovat i Zendisty) nebo vNette\Latte\Bridges
- vlastní Latte zůstane ve jmenné prostoru
- pohled API
- asi všechno pod jedno API, bordel bude schovaný
pod
Bridges
- asi všechno pod jedno API, bordel bude schovaný
pod
- pohled Git repozitářů
- ?
Možná je tam nějaký úvahový epic fail, večer pošlu korekci.
- Honza Marek
- Člen | 1664
- Uživatel Zendu může dát jen nette/latte-zend-bridge a ten mu zvládne nainstalovat i nette/latte.
- Nette bridge bude otravovat i Zendisty – k tomu nevidím důvod.
- Patrik Votoček
- Člen | 2221
Jan Tvrdík napsal(a):
2. uživatel Zendu dá require
nette/latte
&nette/latte-zend-bridge
⇒ nainstaluje standalone Latte & bridge pro Zend
imho mu stačí nette/latte-zend-bridge
protože to samo už má
závislost na nette\latte
David Grudl napsal(a):
To není zcela přesné: nezávislé je Symfony\Component, nikoliv Symfony.
Aktualně z praxe mám nella/console což je integrace Symfony Console do Nette Frameworku.
Mám tedy:
- framework Nette (https://github.com/nette/nette)
- addon Nella Console (https://github.com/nella/console)
- závisí na Symfony Console (https://github.com/symfony/console)
V případě Latte pro Zend by to bylo
- framework Zend2 (https://github.com/…ramework/zf2)
- modul Zend2 Latte (https://github.com/…/zend2-latte)
- závisí na Nette Latte (https://github.com/nette/latte)
Nedokážu si moc představit že by se mě podařilo přesvědčit někoho ze Symfony aby do něj integroval Nella Console.
- David Grudl
- Nette Core | 8199
Ale to už tady těžce mícháš naprosto nesouvisející věci. Otázka zní: jaká je logika v tom, že Nette\A je součást Nette Frameworku a api.nette.org a Nette\B není součast frameworku a není na api.nette.org?
Co se týče Symfony, Console je ve skutečnosti Symfony\Component\Console, je to zjevně komponenta. Naopak jejich šablonovací systém není součástní Symfony\Component a už vůbec se nejmenuje TemplatingEngine. Tedy to není dobrý protiargument.
- Honza Marek
- Člen | 1664
Jejich šablonovací systém se nejmenuje Symfony\TemplatingEngine, protože to neni (alespoň původně) jejich produkt.
- Jan Tvrdík
- Nette guru | 2595
Je to složitější, než jsem myslel. Trochu jsem to rozepsal, ale jasno v tom ještě nemám.
Composer
- Existují následující balíčky:
- nette/nette = celý nette framework, včetně Latte a „bridge pro
Nette“, bez „bridge pro Zend“
- obsahuje něco jako
replace: {"nette/latte": "*"}
- obsahuje něco jako
- nette/latte = samostatné Latte, bez žádného „bridge“
- rozdíly vůči současné „složce s Latte“
- nebude obsahovat třídy
CacheMacro
,FormMacros
aUIMacros
CoreMacros::macroDump
se přesune jinam
- nebude obsahovat třídy
- pravděpodobně bude záviset
- na nette/utils (
Nette\Utils\Strings
,Nette\Utils\Html
,Nette\Utils\Tokenizer
…) - na nette/core (
Nette\Iterators\*
…)
- na nette/utils (
- rozdíly vůči současné „složce s Latte“
- nette/latte-zend-bridge = „Latte pro Zend“
- závisí na nette/latte
- nette/utils
- nette/core
- nette/nette = celý nette framework, včetně Latte a „bridge pro
Nette“, bez „bridge pro Zend“
- Pohled různých uživatelů, kteří chtějí používat Latte
- Uživatel Nette dá require
nette/nette
- Uživatel Zendu dá require
nette/latte-zend-bridge
- Uživatel nepoužívající žádný framework dá require
nette/latte
a napíše si vlastní „bridge“
- Uživatel Nette dá require
Jmenné prostory
- Latte zůstane ve jmenném prostoru
Nette\Latte
- důvody:
- kompatibilita
- příslušnost ke svému původu
- výrazně menší šance kolize („latte“ je přece jenom docela běžné slovo)
- důvody:
- „Nette bridge“ =
CacheMacro
,FormMacros
,UIMacros
aCoreMacros::macroDump
- ve jmenném prostoru [Q1]
- „Zend bridge“ bude ve jmenném prostoru
Nette\Latte\Bridges
[Q2]
Git repozitáře
Zde existuje několik možností, zkusím alespoň ty základní vypsat a shrnout jejich výhody a nevýhody:
- Jeden všeobjímající repozitář
- repozitáře:
1. nette/nette = hlavní repozitář Nette Frameworku
– obsahuje Latte i všechny „bridges“
- výhody:
- jeden repozitář, tak jak ho dnes známe
- imho se s jedním repozitářem bude vývojářům Nette lépe pracovat (?)
- nevýhody:
- v repozitáři by musely být i věci jako „Zend bridge“
- vyžaduje speciální skript na tvorbu jednotlivých distribučních balíčků pro Composer
- Composer předpokládá jeden repozitář pro každý package
- repozitáře:
- Jeden všeobjímající repozitář + read-only subtree split
- repozitáře:
- nette/nette = hlavní repozitář Nette Frameworku
- obsahuje Latte i všechny „bridges“
- nette/latte = read-only subtree split (stejně jako např. Symfony Console)
- obsahuje Latte i všechny „bridges“
- nette/nette = hlavní repozitář Nette Frameworku
- výhody:
- Symfonistum to funguje :)
- nevýhody:
- je to takový hack
- repozitáře:
- Závislosti přes Composer
- nette/nette = hlavní repozitář Nette Frameworku
- obsahuje „Nette bridge“
- v composer.json bude require nette/latte
- nette/latte = Latte bez bridges
- nette/latte-zend-bridge = „Zend bridge“
- v composer.json bude require nette/latte
- nette/nette = hlavní repozitář Nette Frameworku
Questions & possible options:
- Kde mají být třídy jako např.
UIMacros
Nette\Latte\Macros\UIMacros
Nette\Latte\Bridges\Nette\UIMacros
Nette\Latte\Bridges\Nette\Macros\UIMacros
- Kde mají být třídy jako např.
ZendMacros
Nette\Latte\Macros\ZendMacros
Nette\Latte\Bridges\ZendMacros
Nette\Latte\Bridges\Zend\ZendMacros
Nette\Latte\Bridges\Zend\Macros\ZendMacros
- Filip Procházka
- Moderator | 4668
Osobně také používám přístup,
kde mám jeden hlavní repozitář a ten rozděluji pomocí
git-subtree
, dokonce jsem si na to napsal automatiku za pomoci github
hooků.
Mně to dává smysl v tom, že primárně potřebuji jeden balík svých věcí nad Nette, které přenáším přes projekty, ale zároveň chci, aby se některé části daly použít samostatně.
Přístup, že by byla spousta malých repozitářů má spoustu výhod, například vlastní issue a většinu nevýhod řeší automatické skládání Composerem. Jenže problém je, že dokud nebude Composer umět tohle, tak reálný vývoj takto roztříštěného balíku bude neskutečná bolest.
- David Grudl
- Nette Core | 8199
ad Jeden všeobjímající repozitář: u Latte a Debuggeru to v žádném případě nechci. Jde mi o skutečné osamostatnění a u samostatných projektů se prostě samostatné repo očekává, vše je pak srozumitelnější a působí i důvěryhodněji.
Read-only subtree split nic neřeší, protože součástí repozitáře Latte by měly být třeba i příklady, vlastní readme.txt, atd., klidně i bridge. Navíc read-only subtree komplikuje život autorům pull-requestů, musí totiž zjišťovat, jak a kam vlastně přispívat.
Otázkou je, jak vyčlenit Nette core se třídami Object nebo Strings, nebo jak řešit třeba takové formuláře. Tohle jsou věci, u kterých je pravděpodobnost použití mimo Nette docela minimální a tedy vytvářet samostatná repa by přinášelo víc komplikací než užitku. Aby je však mohl composer používat, musí se udělat buď subtree repa (nejlépe asi do nějakého vlastního github.com/nette-sub), nebo udělat vlastní packages.json.
Vlastní packages.json mi připadá jako čistější cesta.