Jak rozdělit Nette do samostatných projektů

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

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

LeonardoCA
Člen | 296
+
0
-

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
Moderator | 1364
+
0
-

Určitě ponechat.

Jan Jakeš
Člen | 177
+
0
-

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

Ponechat.

mkoubik
Člen | 728
+
0
-

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

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

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

jansfabik
Člen | 193
+
0
-

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
Moderator | 4668
+
0
-

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

HosipLan: ok, změnil jsem to

Filip Procházka
Moderator | 4668
+
0
-

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

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

jansfabik
Člen | 193
+
0
-

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

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

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

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
Moderator | 4668
+
0
-

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

Patrik Votoček
Člen | 2221
+
0
-

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

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

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

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

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

Samotný framework je spíš Nette\Application

+1 pro Nette\Latte

David Grudl
Nette Core | 8082
+
0
-

Ř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
+
0
-

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
Nette Core | 8082
+
0
-

A v jakém prostoru by ten bridge byl?

Honza Marek
Člen | 1664
+
0
-

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

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

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

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

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 | 8082
+
0
-

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 | 8082
+
0
-

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

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

David Grudl
Nette Core | 8082
+
0
-

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

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

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

  1. 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
  2. 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
  3. pohled API
    • asi všechno pod jedno API, bordel bude schovaný pod Bridges
  4. pohled Git repozitářů
    • ?

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

Honza Marek
Člen | 1664
+
0
-
  1. Uživatel Zendu může dát jen nette/latte-zend-bridge a ten mu zvládne nainstalovat i nette/latte.
  2. Nette bridge bude otravovat i Zendisty – k tomu nevidím důvod.
David Grudl
Nette Core | 8082
+
0
-

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

Honza Marek
Člen | 1664
+
0
-

zatím ;)

Patrik Votoček
Člen | 2221
+
0
-

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:

V případě Latte pro Zend by to bylo

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 | 8082
+
0
-

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

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

jansfabik
Člen | 193
+
0
-

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
Nette guru | 2595
+
0
-

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, UIMacrosCoreMacros::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:

  1. 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
  2. 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
  3. 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:

  1. 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
  2. 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
Moderator | 4668
+
0
-

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 | 8082
+
0
-

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

pro me stale vetsi adept na osamostatneni je Nette\Database

enumag
Člen | 2118
+
0
-

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

Šaman
Člen | 2632
+
0
-

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.