Jak rozdělit Nette do samostatných projektů
- David Grudl
- Nette Core | 8220
Největší otázka dalšího vývoje stojí v titulku vlákna: Jak rozdělit Nette do samostatných projektů (Latte, Forms, Debugger a možná Database).
Latte je nejlepší šablonovací vrstva pro PHP a musí existovat i samostatně. Je třeba ji propagovat samostatně. Totéž i v případě Debuggeru.
Otázkou je, jak to techniky vyřešit. Asi se to neobejde bez nějaké reorganizace. Přitom koexistence v rámci frameworku musí být zachována. Nějaké nápady?
- paranoiq
- Člen | 392
takhle jsou do několika projektů rozpitvány třeba Symphony (http://symfony.com/components) nebo Doctrine
asi by bylo vhodné, aby byl nějaký balík Common, kde budou opravdu obecné věci (třeba Dibi chudák by si pak nemuselo udržovat vlastní DibiObject)
- Filip Procházka
- Moderator | 4668
Já souhlasím s Hrachem, taky se mi to nelíbí. Svazuje to ruce. Věřím tomu, že by se dalo automatizovat generování balíčku „Latte“, který by nemusel být oddělen od frameworku, ale prostě by builder prošel kód a hledal, které třídy jsou v Latte použity. Stejně tak Laděnka, Neon, ..
Note: pomocí komentářů (tak jak to funguje teď), by se klidně mohly označit i makra, která nemají být v Latte balíčku.
Editoval HosipLan (8. 3. 2012 11:29)
- Tomáš Votruba
- Moderator | 1114
Taky se připojuji k 2 předchozím příspěvkům, zejména ke klíčové automatizaci. Dá to práci (snad) jen jednou, všichni budou spokojeni – kdo Nette používá, sáhne po frameworku, kdo ne, sáhne po balíčku – a latte půjde využít i samostatně.
Hlavně je to dobrý nápad a vytvořil by se tím chybějící most mezi php a frameworkem, který teď tvoří výhradně třída Nette\Forms\Form. Tedy lepší a rychlejší expanze mezi bezvěrce :)
- Honza Marek
- Člen | 1664
Pokud si jednotlivé balíčky budou vyzobávat třídy, které potřebují, tak se může stát, že nepůjdou použít dva balíčky najednou z důvodu duplicitních tříd.
V Symfony to mají rozdělené pěkně. Ale to je tím, že s tím bylo předem počítáno. Pak to jde snadno mít komponenty.
Paranoiqovo Common je dobrý nápad.
hrach: V Symfony jsou spolu věci provázaný naprosto dostatečně, ale až v nějaké společné nadstavbě (frameworku).
- David Grudl
- Nette Core | 8220
Nejde mi o dekomponování Nette na řadu zcela samostatných jednotek. Příkladem je Nette\Object: všechny třídy ho potřebují a tudíž není možné jednotlivé části frameworku provázat až dodatečně.
Rozdělení na zcela samostatné komponenty je už z tohoto důvodu nemožné. Leda by každá komponenta měla svůj vlastní Object. Jenže k vlastnímu Object by se hned přidal vlastní Strings atd, což prostě není cesta. Stejně tak není cesta tyto třídy zrušit.
Nicméně je tu prostor pro „pozitivní“ dekompozici, pro refaktoring, který by lépe definoval vztahy mezi jednotlivými částmi frameworku. A poté by se i snadněji vytvořil samostatný balík třeba pro Latte.
- srigi
- Nette Blogger | 558
Mne sa tato myslienka paci. Raz som sa o tomto rozpraval s Rastom Turekom a ten mi vravel, ze za pomalym/neflexibilnym release/patching procesom je prave, ze Nette je v podstate monolit.
Vysvetlil mi to na priklade Pythonu. Tiez do istej doby narastal a Guido mal
pod palcom vsetko. Az si raz povedal dost – rozdelil Python na Core a moduly
a sam sa zacal starat iba o Core. Zvysok nechal na komunite a Pythonu to velmi
pomohlo – patche co ja viem do urllib nemuleli ist cez neho ale
cez opravneneho spravcu modulu.
- Roman Ožana
- Člen | 52
Dobrý nápad já jsem rozhodně pro. Už teď má Nette několik výrazných částí „knihoven“ Latte šablony, Debugger, Neon parser, DI (Dibi, Texy) – je škoda, že nejsou dostupné více samostatně.
- Roman Ožana
- Člen | 52
jtousek napsal(a):
Co takhle nějaký formulář, ve kterém by si uživatel vybral které části frameworku chce? Vždy by se stáhlo jen to zaškrtnuté + závislosti (Object, v případě Latte zřejmě Caching, atd.).
To by jistě šlo, ale hádám, že nemalé procento vývojářů používá Nette jako git submodul. Pro ty je tahle cesta nevyhovující.
- bene
- Člen | 82
Mě se ta myšlenka líbí.
Osobně to dělám u svých balíků tříd tak, že jsou rozděleny do
adresářů (v mém případě i namespace) a nemohou být volány vzájemně.
Vyjímkou je adresář „common“, ke kterému mohou přistopovat všichni.
Zde je například třída Object, String, …
Když pak v nějakém projektu potřebuji např. databázi tak jen nahraji
adresář Database a common. Pokud časem potřebuji ftp, tak jen přihraji
adresář Ftp.
Pokud bych to aplikoval na Nette, tak by adresář s nette vypadal asi nějak takto:
- common
- Latte
- Debugger
- Forms
- Database
- Nette (vše ostatní)
Napadají mě dvě nevýhody:
- Musím nahrát vždy min 2 adresáře, což pro jednoduchou instalaci může být malá překážka.
- V adresáři common mohou být třídy, které některé balíky nepoužívají.
Editoval bene (11. 3. 2012 15:22)
- Roman Ožana
- Člen | 52
jtousek napsal(a):
Proč? V repozitáři by se nic neměnilo. Takový formulář pro download by měl (imho) smysl hlavně pro stable verze.
Jestli jsem to dobře pochopil tak Davidovy jde o rozdělení Nette kvůli:
nerovnoměrné rychlosti vývoje jednotlivých částí a- možnosti propagovat/šířit jednotlivé celky samostatně.
Což se podle mě bez změn v hlavním repozitáři neobejde. Ve Wikidi to řešíme systémem git submodulů se samostatným verzováním (tagy). Aplikace se pak skládá z několika submodulů v určitých stádiu vývoje.
Editoval Roman Ožana (13. 3. 2012 20:21)
- David Grudl
- Nette Core | 8220
Asi je čas rozdělení uskutečnit.
- nejprve se pokusím v Nette minimalizovat provázanost
- eliminuju Debugger::tryError a Debugger::toStringException a také Nette\Reflection
- vzniknou asi tyto samostatné jednotky:
- core (tam bude Nette\Object, Nette\Callback, výjimky, iterátory apod)
- Application
- Caching
- ComponentModel
- DI (jehož součástí bude i Compiler a CompilerExtension)
- Database
- Debugger
- Finder
- Forms
- Http
- Latte
- RobotLoader
- Neon
- PhpGenerator
- Reflection
- Routing
- SafeStream
- Security
- Templating
- Validators
- + Nette (kde bude Configurator, NetteExtension, NetteLoader atd.)
- každá jednotka bude mít svůj composer.json a specifikovat závislosti na jiných jednotkách. Core bude závislost každé jednotky.
- každá jednotka bude mít vlastní repozitář na Githubu (se zachovanou historií, příklad). Výhodou je pak samostatné issues, pull request, readme atd.
- distribuční balík bude kompozice všech jednotek. Vlastně už nyní je to kompozice 4 repozitářů.
- Patrik Votoček
- Člen | 2221
@mkoubik: misto submodulu tam právě máš závislosti definované composerem.
- Majkl578
- Moderator | 1364
Zajímavé.
Dávalo by mi smysl, aby každá z těch částí byla ve svém namespace, aby byly snadno
odlišitelné.
Zároveň s tím se ale zabordelí repositáře nette organizace na Githubu – části Nette budou na první pohled neodlišné od jiných, jež částmi nejsou (examples, quick-start). Co tedy ty části pojmenovávat nette-* (nette-latte atd.)?
(Doufám, že se to nedotkne stable větve 2.0.x na Githubu. :))
- Honza Marek
- Člen | 1664
Taky by bylo fajn zajistit načítatelnost autoloaderem composeru. (Aby se na to při tom rozdělování nezapomnělo)
- Filip Procházka
- Moderator | 4668
Composer podporuje PSR0, Robota a nově i jednotlivé soubory – tedy tohle by problém být neměl.
- Honza Marek
- Člen | 1664
Ale ty soubory requiruje vždycky, takže to není lazy. Čili každej modul bude muset mít vlastní autoloader nebo se bude muset podřídit PSR-0.
- David Grudl
- Nette Core | 8220
Všechny jednotky by měly být samostatně použitelné, respektive mělo by dávat smysl je samostatně používat. (V případě Routingu to bude vyžadovat konceptuální úpravu.) Pochopitelně Application bude mít nejvíce závislostí, nicméně bude funkční taky samostatně, třeba bez Mail nebo Database.
22 částí vypadá jako hodně. Nicméně určitě chci osamostatnit 7 částí a k tomu režijně musím vzít další 2 (core, caching). Mít 9 částí + zbytek se mi jeví více chaotické, než to dekomponovat kompletně a dívat se na framework jako to, co je na gihub.com/nette, namísto gihub.com/nette/nette.
- Filip Procházka
- Moderator | 4668
To je tak na další major verzi :)
Chtěl jsem taky napsat, že mi přijde rozdělené až moc, ale vždy když chci něco sloučit, tak mi to připadá lepší oddělené.
- Honza Marek
- Člen | 1664
David Grudl napsal(a):
V případě Routingu to bude vyžadovat konceptuální úpravu.
Pokud to znamená, že k vygenerování odkazu nebude potřeba presenter, tak to zní zajímavě :)
- David Grudl
- Nette Core | 8220
K vygenerování odkazu presenter potřeba není, viz IRouter::constructUrl.
- Honza Marek
- Člen | 1664
Ke generování odkazu v šabloně nebo jako v šabloně je potřeba tato metoda z presenteru: https://api.nette.org/…ter.php.html#797
Neni 22 samostatnych casti zbytecne moc?
Imho by stačilo 21 :) Application mi smysl samostatně nedává, sloučil bych ji s „Nette“.
- Cifro
- Člen | 245
Už dlhšiu dobu som sa chystal tu na forum napísať otázku ako sa dá osamostatniť Template+Latte. Ostatné triedy nepotrebujem. Iba šablony s Latte. A toto vlakno ma potešilo, ale iba trochu. Lebo tento proces rozdeľovania bude na dlho a ja to potrebujem rozdeliť teraz a dať to do minifikovanej verzie. Najskôr asi budem musieť upraviť build-tools O.o
- David Grudl
- Nette Core | 8220
Honza Marek napsal(a):
Ke generování odkazu v šabloně nebo jako v šabloně je potřeba tato metoda z presenteru
Na tom rozdělení nic nezmění, vytvoř si nové makro.
Cifro napsal(a):
Už dlhšiu dobu som sa chystal tu na forum napísať otázku ako sa dá osamostatniť Template+Latte. Ostatné triedy nepotrebujem.
Třídy, které nepotřebuješ, ti v minifikované verzi nevadí, ne?
- Cifro
- Člen | 245
Cifro napsal(a):
Už dlhšiu dobu som sa chystal tu na forum napísať otázku ako sa dá osamostatniť Template+Latte. Ostatné triedy nepotrebujem.
Třídy, které nepotřebuješ, ti v minifikované verzi nevadí, ne?
Vadia. Išlo mi aj o veľkosť vysledného súboru. Z pôvodných 543kB som to stiahol na 243kB. Potrebujem len šablony a Latte pre toto. A čím menšia veľkosť tým lepšie. Ide o UX. Čím menšie to je celé tak tým rychlejšie sa to nahrá na FTP a menej pamäte to zožerie.
- Honza Marek
- Člen | 1664
Nešlo by na tom pracovat postupně? Třeba nejdříve vymyslet si nějaké core a „osvobodit“ laděnku. Další části by mohly přijít časem.
- Filip Procházka
- Moderator | 4668
Latte, Neon, Laděnka – asi nejsilnější části frameworku, které by bylo super osvobodit co nejdříve. Třeba tuhle jsem se snažil do Composeru vnutit na parsování JSONu Neon, a prý ne, už jen kvůli tomu, že to není samostatně.
- David Grudl
- Nette Core | 8220
Postupně ty vazby redukuju: ono se řekne osamostatnit Neon, jenže Neon byl závislý na Strings a ten byl závislý na Debuggeru. To už teď je pryč, ale chtělo to vymyslet způsob a to prostě nejde hned.
Teď je potřeba vymyslet, jak na jmenné prostory, když je prakticky vše závislé na několika třídách z Nette a Nette\Utils. Včetně Neonu, který je součástí Nette\Utils.
Úplně samostatným problémem je pak rozdělení do samotatných repozitářů (či ponechání v jednom). Zkrátka pro osamostatnění jedné věci je toho potřeba vyřešit takřka stejně, jak pro kompletní rozdělení.
- Honza Marek
- Člen | 1664
<vidím to jako hurvínek válku>
- Nette\Utils\Strings by mohlo zůstat v core balíku beze změny namespace.
- Repozitáře bych rozdělil, composer to pak může dávat zase dohromady a strkat ty jednotlivé části do správných složek.
- Co se týče Neonu, tak ten zasloužil vlastní namespace od začátku.
- Pro začátek bych udělal třeba čtyři repozitáře:
- core (Nette\Object apod.) + utils (Strings apod.)
- neon (závislý na core)
- debugger (závislý na core)
- framework (zatím vše neoddělené, závisí na core, neonu a debuggeru)
- Koncový uživatel download balíku nebo composeru nemusí nic poznat.
</vidím to jako hurvínek válku>
- Ot@s
- Backer | 476
bazo napsal(a):
neon by mohol byt ako uplne samostatny projekt – ja ho vyuzivam vo svojom translatori, co ho robi zavislym na nette. ak by bol nezavisly dal by sa translator pouzit aj pre non nette appky + by mohli Neon zacat pouzivat ine projekty, frameworky
Asi to víš, tak spíš jen pro ostatní – knihovna pro neon existuje i samostatně na ne-on.org.
- Filip Procházka
- Moderator | 4668
Možná by se vyplatilo udělat s Nette\Utils v Neonu (protože
je to jen jedna třída) co jsi udělal s Debugger::tryError (a
apod.) – prostě ten kód drobínek zduplikovat a očesat.
@Ot@s: to je „málo“ – je lepší vlastní github, vlastní issues a vlastní composer balíček – pak teprve bude opravdu samostatně použitelný.
@dg: Samozřejmě se to řekne snáz než udělá, ale když si na to nedáš sáhnout, tak ti s tím nemůžeme pomoct :) Ale na druhou stranu moc dobře chápu, proč si to chceš udělat sám :)
- David Grudl
- Nette Core | 8220
Docela ožehavá otázka jsou jmenné prostory.
Je dáno jen zvyklostí, že čekáme Latte v
Nette\Latte, nicméně logičtější by bylo samotné
Latte a ve složce Nette\Latte či alternativně
Nette\Bridges\Latte mít jen marka pro presentery a formuláře,
tedy uzpůsobení Latte pro Nette Framework.
To stejné platí i v případě Laděnky.
Druhou možností je uzpůsobení pro jednotlivé frameworky mít přímo
jako součást samostatného Latte. Tady je otázka, jak to dobře rozvrhnout,
kam dát třeba soubory Latte for Zend, protože logicky nechceme,
aby byly součástí distribuce Nette.