Jak rozdělit Nette do samostatných projektů

před 6 lety

David Grudl
founder | 6756
+
0
-

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?

před 6 lety

paranoiq
Člen | 388
+
0
-

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)

před 6 lety

hrach
Člen | 1792
+
0
-

Jo, tak ja sem spíš proti :D To je přesně to, co mi vadí na symfony. Celé jsou to nějaké komponenty, díky čemuž jejich rozhraní je dosti univerzální → není to tak provázané… prostě .. :D neumím to říct, ale nelíbí se mi to, ačkoliv důvody chápu.

před 6 lety

Filip Procházka
Moderator | 4693
+
0
-

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)

před 6 lety

Tomáš Votruba
Moderator | 1149
+
0
-

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

před 6 lety

Honza Marek
Člen | 1674
+
0
-

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

před 6 lety

David Grudl
founder | 6756
+
0
-

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.

před 6 lety

srigi
Člen | 552
+
0
-

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.

před 6 lety

Roman Ožana
Člen | 52
+
0
-

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

před 6 lety

jtousek
Člen | 956
+
0
-

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

před 6 lety

Roman Ožana
Člen | 52
+
0
-

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

před 6 lety

jtousek
Člen | 956
+
0
-

Proč? V repozitáři by se nic neměnilo. Takový formulář pro download by měl (imho) smysl hlavně pro stable verze.

před 6 lety

bene
Člen | 83
+
0
-

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:

  1. Musím nahrát vždy min 2 adresáře, což pro jednoduchou instalaci může být malá překážka.
  2. V adresáři common mohou být třídy, které některé balíky nepoužívají.

Editoval bene (11. 3. 2012 15:22)

před 6 lety

Roman Ožana
Člen | 52
+
0
-

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:

  1. nerovnoměrné rychlosti vývoje jednotlivých částí a
  2. 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)

před 6 lety

David Grudl
founder | 6756
+
0
-

Jde mi vlastně jen o bod č. 2, s rovnoměrností problém není.

před 6 lety

David Grudl
founder | 6756
+
0
-

Asi je čas rozdělení uskutečnit.

  1. nejprve se pokusím v Nette minimalizovat provázanost
    • eliminuju Debugger::tryError a Debugger::toStringException a také Nette\Reflection
  2. 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
    • Mail
    • Neon
    • PhpGenerator
    • Reflection
    • Routing
    • SafeStream
    • Security
    • Templating
    • Validators
    • + Nette (kde bude Configurator, NetteExtension, NetteLoader atd.)
  3. 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.
  4. 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.
  5. distribuční balík bude kompozice všech jednotek. Vlastně už nyní je to kompozice 4 repozitářů.

před 6 lety

mkoubik
Člen | 732
+
0
-

A v těch repozitářích bude jen composer.json, nebo i submoduly závislostí? Jde mi o to, aby byl nějaký repozitář, který když si naklonuju (a updatnu submoduly) tak mám kompletní framework, stejně jako teď z github.com/nette/nette.

před 6 lety

David Grudl
founder | 6756
+
0
-

Jen composer, submoduly by použít nešly.

před 6 lety

Patrik Votoček
Člen | 2249
+
0
-

@mkoubik: misto submodulu tam právě máš závislosti definované composerem.

před 6 lety

Majkl578
Moderator | 1379
+
0
-

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

před 6 lety

Patrik Votoček
Člen | 2249
+
0
-

Samostatně použitelný Application?

před 6 lety

Honza Marek
Člen | 1674
+
0
-

Taky by bylo fajn zajistit načítatelnost autoloaderem composeru. (Aby se na to při tom rozdělování nezapomnělo)

před 6 lety

Filip Procházka
Moderator | 4693
+
0
-

Composer podporuje PSR0, Robota a nově i jednotlivé soubory – tedy tohle by problém být neměl.

před 6 lety

Honza Marek
Člen | 1674
+
0
-

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.

před 6 lety

juzna.cz
Člen | 249
+
0
-

Neni 22 samostatnych casti zbytecne moc? Myslim, ze to prida nejakou rezii, minimalne na mozek programatora. Uz nebude nette videt tak pekne cele pohromade.

Nebylo by lepsi zacit s oddelenim treba 3 nebo 4 hlavnich modulu? Jit formou evoluce, misto revoluce.

před 6 lety

David Grudl
founder | 6756
+
0
-

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.

před 6 lety

Filip Procházka
Moderator | 4693
+
0
-

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

před 6 lety

Honza Marek
Člen | 1674
+
0
-

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

před 6 lety

David Grudl
founder | 6756
+
0
-

K vygenerování odkazu presenter potřeba není, viz IRouter::constructUrl.

před 6 lety

Jan Jakeš
Člen | 178
+
0
-

Já myslím, že těch 22 částí není moc. Takhle to dává smysl, snaha nacpat to do méně balíků by přinesla spíše chaos.

před 6 lety

Honza Marek
Člen | 1674
+
0
-

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

před 6 lety

Cifro
Člen | 245
+
0
-

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

před 6 lety

David Grudl
founder | 6756
+
0
-

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?

před 6 lety

paranoiq
Člen | 388
+
0
-

@david: „eliminuju Debugger::tryError“
tohle je dost užitečná věc a mělo by smysl jí vyškubnout z diagnostiky a zařadit do balíku core. určitě to pár lidí používá ve vlastních knihovnách pro práci s debilními chybami PHP (já teda jo)

update: a ono to vyškubnout nejde :[

před 6 lety

Cifro
Člen | 245
+
0
-

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.

před 6 lety

hrach
Člen | 1792
+
0
-

pro takoveto ucely je nejjednodussi upravit build tools. Je to vcelku jednoduche :)

před 6 lety

hrach
Člen | 1792
+
0
-

Nejak to umrelo, tak co Davide? :)

před 6 lety

paranoiq
Člen | 388
+
0
-

420 Enhance Your Calm :]

před 6 lety

meris
Člen | 8
+
0
-

Také by mě zajímalo, jestli se v tomto něco děje?

před 6 lety

David Grudl
founder | 6756
+
0
-

Děje, ale je to na dlouho.

před 6 lety

Honza Marek
Člen | 1674
+
0
-

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.

před 6 lety

Filip Procházka
Moderator | 4693
+
0
-

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

před 6 lety

David Grudl
founder | 6756
+
0
-

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

před 6 lety

Honza Marek
Člen | 1674
+
0
-

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

před 6 lety

bazo
Člen | 625
+
0
-

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

před 6 lety

Ot@s
Člen | 478
+
0
-

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.

před 6 lety

Filip Procházka
Moderator | 4693
+
0
-

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

před 6 lety

bazo
Člen | 625
+
0
-

Co som pozeral Strings v poslednej dev verzii, tak uz ni je zavisla na nicom inom, mozno by mohli byt tiez samostatne.

Alebo zduplikovat ten kod pre Neon, tusim je tam vyuzita len jedina metoda zo Strings

před 6 lety

David Grudl
founder | 6756
+
0
-

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.

před 6 lety

paranoiq
Člen | 388
+
0
-

je-li Latte vyvíjeno Nette Foundation, pak nevidím v namespace Nette\Latte problém :]

Stránky: 1 2 3 Next RSS tématu