Jak rozdělit Nette do samostatných projektů

NDB si o to doslova říká ;-)

S těmi UI makry v rámci nette/application naprosto souhlasím. Přesto by ale nette/application nemělo mít přímou závislost na nette/latte, spíše definovat suggest a v ApplicationExtension detekovat přítomnost Latte, makra instalovat pouze pokud latte existuje. Podobně makra pro formuláře, cache, dump.

U toho oddělení databáze je ale jeden problém. Bude mít nette/nette závislost na nette/database nebo opačně? @hrach navrhuje opačně, ale v tom bych si dovolil nesouhlasit. (Pochybuji že by composer zvládl cyklickou závislost a i kdyby ano tak považuji za nesmysl ji vytářet.) Balíček nette/nette by dle mého názoru měl obsahovat celé Nette, v budoucnu bych jej nejraději viděl pouze jako metapackage. Z tohoto důvodu jsem toho názoru že jako první by se mělo vyčlenit nette/core, jako druhé nette/cache a pak teprve databáze.

Další věc je, že oddělení nám poněkud změní zápis v neonu, protože každý balíček bude mít své CompilerExtension, které bude zřejmě také v bridges jako most na balíček nette/di (zde asi opět suggest, určitě ne přímou závislost).

Dnešní zápis:

nette:
	latte:
		#...
	database:
		#...

Nový zápis:

nette.latte:
	#...
nette.database:
	#...

Tento zápis se někomu možná nebude líbit natolik jako stávající. Mně ale připadá lepší, protože je i zde jasné že ta extensions jsou samostatná, proto myslím že bude lepší tuto změnu neřešit tj. nesnažit se za každou cenu zachovat původní syntaxi.

Pozn. Latte bych raději viděl jako balíček nette/latte než latte/latte.

EDIT:
Ještě jedna věc, speciálně pro @hracha, který nebyl na lednové posobotě. David prozatím nechce mít žádné nette/core, kde by byl Object a Strings a to z toho důvodu že composer-based instalace ještě není úplně standard – až to nastane může Nette\Object opět být jen jeden v nette/core, to už se dá udělat kdykoli celkem bezbolestně.

Další problém je třída Strings. Např. laděnka má na této třídě závislost, ale pouze kvůli funkci fixEncoding. V tomto případě bude podle Davida (a já s ním souhlasím) lepší tu jednu funkci zkopírovat než vytvářet zbytečnou závislost. Obzvlášť laděnka by měla být trochu stand-alone aby ji mohl použít kdokoli kdekoli, tj. bez composeru, bez nette.

Nevím teď jak moc je na Strings závislá NDB, je-li ta závislost podobně slabá, tak by též mohlo být lepší potřebné metody zkopírovat.

Editoval enumag (26. 2. 2013 13:58)

Takze pridavam reakci jeste ne edit:

• ackoliv sem tuto informaci jsem nevedel, muj navrh je plne s timto v souladu.
• nevim, jestli jsi to dobre interpretoval, ale ten nazor je mimo. Existuji dve kategorie, pouzivaci novych technologii a ti zpomaleni (v neutralnim slova smyslu). Ti, co si nette klonovali, tak davno pouzivaji composer. Ta stara kategorie stale pouziva … ? No preci stazeni archivu z nette.org. Zavedeni nette/core by samozrejme nic nezpusobilo s archivem na nette.org. Ten by se kompiloval samozrejme porad stejne.
• podbodem na zamysleni je moznost mit v repozitar nette/nette duplikovane changesety, misto metabalicku. (proste opak split subtree)

Má představa:

• nette/core – jádro
• nette/database
• nette/cache
• nette/latte
• …
• nette/nette
  • vyžaduje
    • nette/core
    • nette/latte
    • nette/core
  • volitelné
    • nette/database
    • nette/dibi – (nějaký sjednocený mechanismus i pro DibiExtension načítající dg/dibi)

@Honza Marek: Hrach to myslel jako dočasné řešení, ale nemyslím že to projde. Kdyby náhodou jo, tak NDB lze vyčlenit jako první, jak @hrach navrhuje s tím že by se závislost na nette/database musela psát zvlášť. Pokud ne, bude to pořadí muset být tak jak jsem řekl, přičemž nad nette/core David vyvěsil otazník.

@castamir: S první částí souhlasím, ale nette/database by mělo být součástí nette/nette. Pokud NDB nechceš, definuj si vlastní meta package, to je trivka. DibiExtension může být součástí dg/dibi, do nette to nepatří.

Editoval enumag (26. 2. 2013 15:20)

Souhlasim s hrachem v tom ze by bylo dobre aby vsechny baliky zustaly v namespace nette.

Nelibi se mi mnozna cisla u Bridges ale to je asi detail…

Wow, dobrý tool!

Všech těch šílených závislostí se lze zbavit zrušením Object::getReflection (a asi Callback::toReflection). Což samozřejmě zase otevírá otázku kompatibility. Bez BC breaků tohle uskutečnitelné nebude.

Nette\Object::getReflection() můžeš doplnit pomocí extension method :)

@Milo: Nette\Object má závislost na Reflection, a Reflecion\AnnotationsParser a zase na Caching. Není mi jasné proč tam ta závislost na Cache je, protože se nepoužívá vždy, ale jen v určitém případě – jakém?

@Milo: Pokud jsem správně pochopil implementaci tak se nekešují ani tak anotace jako spíše „docblock“ komentáře pokud je nelze přečíst z reflexe. Na jednu stranu si říkám že důvodem může být něco jako eAccelertator který komentáře maže, na druhou stranu témata s nefunkčními perzistentními parametry kvůli tomu že eAccelertator mazal komentáře už tu byly. Tzn. buď to nefunguje tak jak bylo zamýšleno, anebo (a to je mnohem pravděpodobnější) jsem něco špatně pochopil.

Přemýšlel jsem nad vyčleněním Database z Nette. První co se zdá těžké je závislost na Cache, ale co jsem prohlížel kód, tak cache je v NDB použita dost jednoduše. Postačila by celkem triviální implementace jako náhrada. Hlouběji se tím nezabývám, když jsem viděl že už vznikl nette/database repo… :)

V souvislosti s tím jsem ale přemýšlel nad tím, jak případně onu trivální cache nahradit full Cache z Nette. První co mě napadlo je implementace stejného interface. Nestálo by za to, udělat nějaký repozitář nette/interafces? Anebo to granulovat ještě víc na nette/cache-interfaces? Nehloubal jste nad tím někdo víc?

Nejlepší by asi bylo, kdyby balík nette/database závisel na nette/caching, ale to už je zase jiná pohádka.

mkoubik napsal(a):

Nejlepší by asi bylo, kdyby balík nette/database závisel na nette/caching, ale to už je zase jiná pohádka.

To si nemyslím. Představ si, že bys chtěl ndb použít třeba v Symfony, které má vlastní keš. Raději si napíšeš bridge než abys používal nějakou další alien keš a měl schizofrenní kešování.

Majkl578 napsal(a):

mkoubik napsal(a):

Nejlepší by asi bylo, kdyby balík nette/database závisel na nette/caching, ale to už je zase jiná pohádka.

To si nemyslím. Představ si, že bys chtěl ndb použít třeba v Symfony, které má vlastní keš. Raději si napíšeš bridge než abys používal nějakou další alien keš a měl schizofrenní kešování.

Oproti situaci, kdy by nette/database měla vlastní „triviální implementaci“ to není žádný rozdíl. Nic by ti samozřejmě nebránilo použít jakoukoliv jinou cache, která by implementovala příslušné rozhraní (třeba tu ze symfony).

Ještě mě napadlo další řešení: inteface Nette\Caching\IStorage extends Nette\Database\Caching\IStorage, Nette\Latte\Cahing\IStorage, ... – nette/database by měla vlastní rozhraní pro cache a každý by si ho mohl implementovat aniž by k tomu potřeboval cokoliv z nette, přičemž standardní úložiště z Nette by tam pořád pasovaly.

castamir napsal(a):

Nojo, to mi nedošlo, beru zpátky.

@enumag a to něčemu vadí? Já bych některé kousky uvítal ;)

@enumag no, to by mohl řešit release skript, který to spojí a který vytvoří komplet balík, který se umístí na web nette. Pokud vím, tak nějak to funguje už teď…

@**castamir**, @**enumag**: nějak se to tu zvrhlo. Zachvíli z toho uděláte co třída, to package.
A když jsme u toho, né každý používá composer ;)

@martinit já nechci rozdělit nette úplně na jednotlivé třídy, jen vysekat 2 další (a k nim patřičné závislosti). Například při testování používám jen Robotloader a Debugger (+ volitelný CacheStorage) viz bootstrap pro testování jednoho mého projektu. Uznej, že stahovat kvůli tomu celý framework je trošku zbytečné…

Celkově se podle mě má cenu z nette vysekat pouze Debugger, Latte, NDB, CacheStorage, Object a RobotLoader (snad jsem na nic nezapomněl). To není až tolik částí…

co se nightly verzí bez composeru týče – to je vždy takové ehm komplikované. Ale asi jsem díky používání Composeru zaujatý. Composer totiž hrozně rozmazluje ;-)

Editoval castamir (21. 4. 2013 13:51)