Jak rozdělit Nette do samostatných projektů

hrach

Osobně se tako klonim k zachovani vazby Latte v nette, tedy ve slozce Nette\Latte, stejne jak jmenem prostoru.

LeonardoCA

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.

Majkl578

Určitě ponechat.

Jan Jakeš

To by jako vznikly projekty typu Latte, Debugger, Tester? To není dobré, určitě to chce Nette namespace, třeba chápáno jako to Nette Foundation – může zastupovat ten krásný výraz „vendor“ :)

Jirda

Ponechat.

mkoubik

Myslim, že Nette\Latte je jako název ok. Podobně každý ví o co jde, když se řekne Nette\Database nebo Symfony\Console (i když namespace je jiný). Navíc u obecnějších názvů (debugger, tester) by to jinak nešlo.

Patrik Votoček

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

Nette\Latte ! Všichni používají komponenty ze Symfony a nikoho nesere, že tam je Symfony\Component před vším.

jansfabik

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 byl Nette\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

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.

jansfabik

HosipLan: ok, změnil jsem to

Filip Procházka

Imho je daleko lepší něco jako Nette\Latte a Nette\ZendBridge\Latte.

Editoval HosipLan (10. 10. 2012 21:52)

jansfabik

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

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

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

HosipLan napsal(a):

Nette\Latte ! Všichni používají komponenty ze Symfony a nikoho nesere, že tam je Symfony\Component před vším.

+1

Filip Procházka

Co má namespace společného s čistým objektovým návrhem? Správně, nic.

Patrik Votoček

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

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

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

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

jansfabik

Neuvědomil jsem si, že v Nette\Bridge může být jenom továrna a ne poděděné třídy. Takhle se mi taky víc líbí ta varianta s hlavním jmenným prostorem v Nette\Latte.

pekelnik

Samotný framework je spíš Nette\Application…

+1 pro Nette\Latte

David Grudl

Ř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

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

David Grudl

A v jakém prostoru by ten bridge byl?

Honza Marek

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

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)

mkoubik

David Grudl napsal(a):

A v jakém prostoru by ten bridge byl?

Za předpokladu, že bude Latte samostatný projekt – nemělo by se tohle řešit na fóru ZendFrameworku (nehledě na to, že to bude nejspíš programovat někdo z nette komunity)?

Patrik Votoček

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š

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

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

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

Pořád nechápu proč vnímáš třídy pro integraci Latte do Zendu jako součást Nette.

David Grudl

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

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

Zamyslím se nad tím dneska večer pořádně, ale teď to vidím takto:

pohled z composeru
1. uživatel Nette Frameworku dá require nette/nette ⇒ nic se pro něj nemění, zend bridge se nenainstaluje, nette bridge ano
2. uživatel Zendu dá require nette/latte & nette/latte-zend-bridge ⇒ nainstaluje standalone Latte & bridge pro Zend
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 v Nette\Latte\Bridges
pohled API
- asi všechno pod jedno API, bordel bude schovaný pod Bridges
pohled Git repozitářů
- ?

Možná je tam nějaký úvahový epic fail, večer pošlu korekci.

Honza Marek

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.

David Grudl

Klíčové je, že Nette\* není Nette Foundation, ale Nette Framework.

Honza Marek

zatím ;)

Patrik Votoček

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

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

Jejich šablonovací systém se nejmenuje Symfony\TemplatingEngine, protože to neni (alespoň původně) jejich produkt.

jansfabik

Myslím, že Nette\Bridge by si zasloužil vlastní composer balíček. Pokud je Latte samostatný projekt, neměl by obsahovat bridge pro žádný framework (byť by to byl framework od Nette Foundation).

Jan Tvrdík

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": "*"}
- nette/latte = samostatné Latte, bez žádného „bridge“
  - rozdíly vůči současné „složce s Latte“
    - nebude obsahovat třídy CacheMacro, FormMacros a UIMacros
    - CoreMacros::macroDump se přesune jinam
  - pravděpodobně bude záviset
    1. na nette/utils (Nette\Utils\Strings, Nette\Utils\Html, Nette\Utils\Tokenizer…)
    2. na nette/core (Nette\Iterators\*…)
- nette/latte-zend-bridge = „Latte pro Zend“
  - závisí na nette/latte
- nette/utils
- nette/core
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“

Jmenné prostory

Latte zůstane ve jmenném prostoru Nette\Latte
- důvody:
  1. kompatibilita
  2. příslušnost ke svému původu
  3. výrazně menší šance kolize („latte“ je přece jenom docela běžné slovo)
„Nette bridge“ = CacheMacro, FormMacros, UIMacros a CoreMacros::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
Jeden všeobjímající repozitář + read-only subtree split
- repozitáře:
  1. nette/nette = hlavní repozitář Nette Frameworku
    - obsahuje Latte i všechny „bridges“
  2. nette/latte = read-only subtree split (stejně jako např. Symfony Console)
    - obsahuje Latte i všechny „bridges“
- výhody:
  - Symfonistum to funguje :)
- nevýhody:
  - je to takový hack
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

Questions & possible options:

Kde mají být třídy jako např. UIMacros
1. Nette\Latte\Macros\UIMacros
2. Nette\Latte\Bridges\Nette\UIMacros
3. Nette\Latte\Bridges\Nette\Macros\UIMacros
Kde mají být třídy jako např. ZendMacros
1. Nette\Latte\Macros\ZendMacros
2. Nette\Latte\Bridges\ZendMacros
3. Nette\Latte\Bridges\Zend\ZendMacros
4. Nette\Latte\Bridges\Zend\Macros\ZendMacros

Filip Procházka

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

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.

pekelnik

pro me stale vetsi adept na osamostatneni je Nette\Database…

enumag

@pekelnik: +1 :-) Tam by to navíc nemuselo být až tak složité. Moc závislostí tam pokud vím není.

Šaman

To osamostatnění databáze by se mi taky líbilo. Zdá se mi že je to nejčastěji přepisovaná/přetěžovaná část Nette a po osamostatnění by bylo možné, že by různí lidé udržovali několik forků s vlastním životem. Teď to není možné bez udržování celého Nette.