Akce Kulový blesk je tady

David Grudl

Největší revoluce ve vývoji Nette Frameworku je tady: rozdělení Nette na malé projekty:

K dokonalosti zbývá vyřešit několik věcí:

Všechny balíčky mají závislost na nette/utils, ten by neměl mít závislost na ničem. Nicméně Nette\Utils\Callback::toReflection a Nette\Object::getReflection vrací třídy z balíčku nette/reflection, ten má zase vazbu na nette/caching kvůli kešování anotací, takže dělat vazbu nette/utils → nette/reflection vážně nechci. Musí se to nějak vyřešit. Napadá mě asi jen BC break, kdy funkce bude vracet standardní třídy Reflection. V té souvislosti je na místě otázka, zda vůbec má Nette\Object::getReflection dnes opodstatnění.
Latte při escapování přistupuje jinak k objektům Nette\Utils\Html a Nette\Forms\Form. Tady by bylo na místě udělat nějaký univerzální interface HtmlString, jenž by naopak Html a Form implementovali. https://github.com/…9d071cf580cb
Makra {dump} a {cache} by doplnila až Latte továrna v nette/application, společně s UIMacros & FormMacros. Nicméně kód FormMacros společně s netteForm.js je součástí nette/forms. Druhou možností je bridge přímo v tracy a nette/caching, ale to se mi úplně nezdá…
~~nette/http a nette/caching má vazbu na nette/reflection kvůli anotaci @serializationVersion. Přemýšlím, že bych podporu této anotace zrušil.~~ https://github.com/…te/pull/1456
nette/http má vazbu na nette/security kvůli IUserStorage. To se mi vůbec nelíbí. Jedno z možných řešení je přesunout Nette\Security\User do nette/application.
Obsah balíčku nette/utils bych výhledově zredukoval. Každopádně větší problém je historický mix namespaces, kde některé třídy mají prostor Nette\ a jiné Nette\Utils\.

Určitě budu rád za zajímavé nápady, jen sem prosím nestřílejte dojmy, které si dobře nepromyslíte a které pak nebudou diskusi posouvat.

Filip Procházka

Nette\Object::getReflection může být extension metoda Nette\Object která se přidá při naloadování nette/reflection, nebo bridge
serializationVersion zrusit, cache se má při deployi mazat
UserStorage by mohlo být v HttpSecurity bridge a závislost na nette/security by se přesunula do suggest

Editoval Filip Procházka (18. 3. 2014 20:14)

David Grudl

Ještě k UserStorage: když jsem se pokusil implementovat přihlašování bez session (jen přes cookie), UserStorage do toho moc nepasoval. Tudíž nějaký větší zásah do něj bude stejně potřeba.

David Matějka

+1 pro Filipuv navrh. Mozna bych zvazil odebrani anotaci z reflection. Vytvoril by se samostatny balicek nette/annotations – preci jen ke cteni anotaci by melo dochazet zridka a snadna konstrukce jako $this->getReflection()->getAnnotations() svadi ke zneuziti.
Userstorage – myslim, ze by bylo lepsi ten HTTP UserStorage mit v balicku security. Sice se zavislost jen obrati, ale porad je imho logictejsi, ze security zavisi na http a ne obracene. A samozrejme to muze byt jen v suggest.

btw, jak tam planujes autoloading? Doufam, ze PSR-0/4 :) Nejen proto bych radeji videl, aby balicky mely ten namespace Bridges pod svym namespace (tedy Nette\Forms\Bridges) a ne v Nette\Bridges

David Grudl

Autoloading řeší Composer, RobotLoader nebo NetteLoader, je to tedy docela nepodstatný detail, tím pádem ani nad PSR neuvažuju.

Samostatný nette/annotations je možnost, nicméně v tuto chvíli by na něm reflection závisel, takže to asi nic neřeší.

enumag

Na metodu Nette\Object::getReflection se dívám podobně jako na bývalou Nette\Object::getClass. Tedy bych ji odstranil úplně, zavolat new ClassType($object) přece není problém. Nette\Utils\Callback::toReflection je horší, asi by měla obsahovat fallback na nativní PHP classy pokud nette/reflection není k dispozici. Pokud jste zásadně proti odstranění Nette\Object::getReflection, lze to řešit stejným způsobem. Plus by se do composer.json v nette/utils přidal suggest nette/reflection.
+1
Doplnit až v Application.
Ostranit.
Buď Nette\Security\SessionUserStorage čímž by ale vznikla opačná vazba nette/security na nette/http. Takže opět suggest a třídu přesunout do Nette\Security\Bridges\Http\SessionUserStorage.

Čímž se dostávám k tomu že se mi ani trochu nezamlouvá namespace Nette\Bridges který je rozštěpený všude možně. Přidávám se k návrhu od @matej21.

Dále {cache} makro imho patří spíše do nette/latte než do nette/caching. Balík implementující cachování nemá důvod vědět o nějakém šablonovacím systému latte. Naopak v šablonách se cachování často hodí proto to v balíku latte (když už ne úplně samostatně) být může. Samozřejmě na nette/caching by nebyla vazba requires ale jen suggest.

PSR-0/4 bych uvítal, samostatný balík nette/annotations také.

Editoval enumag (18. 3. 2014 20:37)

David Grudl

Prosím utněme v zárodku diskusi o PSR-0/4, loading za nás dělají nástroje. (Navíc Nette PSR používá, jen pro vyšší přehlednost a v důsledku i výkon umisťuje definice výjimek do jednoho souboru exceptions.php).

Bridges není součástí namespace balíčku, protože to prostě není jeho součást. Skutečnost, že je umístěn ve stejném repozitáři, je vlastně jen pragmatický kompromis, o fous lepší řešení, než jedno repo se všemi bridges či samostatné repa pro jednotlivé bridges (k čemuž lze kdykoliv časem případně přejít).

Tharos

Teda, Davide (a komunito), klobouk dolů!

Honza Marek

Dobrá práce.

Metody getReflection a toReflection zrušit.
IHtmlString je správná cesta.
Makra {dump} a {cache} – jo
@serializationVersion zrušit
IUserStorage podle mě nemá v http co pohledávat. Dal bych do security.
Z utils půjde ještě pár věcí vyčlenit. Například image, neon, finder dávaj perfektní smysl použít samostatně.

Všimnul jsem si, že úplně neodpovídají balíky a namespacy. Třeba v routingu je Nette\Application\Request. Ale vzhledem k nějaké zpětné kompatibilitě se asi nedá nic dělat.

enumag

@Honza Marek: IUserStorage je v Security. Jeho implementace UserStorage (pomocí Session) je v Http.

David Grudl

Balík nette/routing je pracovní verze pro budoucí záměry, doplnil jsem to do prvního postu. toReflection je užitečná metoda používaná na řadě míst frameworkem, proč bych ji měl rušit?

David Matějka

@Honza Marek:

Z utils půjde ještě pár věcí vyčlenit. Například image, neon, finder dávaj perfektní smysl použít samostatně.

Puvodne jsem to chtel napsat sam, ale je to komplikovanejsi – a mozna i zbytecny. Ty tridy zaviseji na nette\object, tokenizer, asi nejakych iteratorech atd. takze by nette\utils stejne vyzadovaly

@David Grudl: nez bude diskuze utnuta – dulezitejsi vec nez snadny loading prinasi PSR-0/4 prehlednou strukturu souboru a nemuze tak dojit k tomu, ze ve slozce Routing najdes Nette\Application\Request

Honza Marek

Pardon, nevěděl jsem, že je užitečná :)

David Grudl

Další rozdělování utils by mělo být technicky poměrně snadné, ale otázka je, do jaké míry je to i praktické. Takřka každá třída by mohla existovat jako samostatný balíček, jenže to znamená práci navíc s přidáváním závislostí do composeru, pochopitelně to zpomaluje aktualizace, přičemž výkon aplikace to neovlivní.

Rozhodně se tomu nebráním, jen to chce dobře promyslet.

Honza Marek

Pokud budeš chtít propagovat třeba neon samostatně, nemůžeš uživatelům říct, že si maj nainstalovat balík nette/utils.

enumag

U ostatních tříd v tom úplně smysl nevidím, ale zrovna Neon by podle mne měl být vyčleněn do samostatného balíčku nette/neon už nyní.

David Grudl

Souhlasím, že značka má být v názvu balíčku. Samostatné repozitáře mají i výhodu v samostatném issue trackeru, historii, dokumentaci v readme atd. Na druhou stranu to komplikuje vývoj, obzvlášť, když se týká více balíčků.

David Grudl

Tak je to tady https://github.com/…te/pull/1461.

Šaman

Můžeš trochu nastínit, jak si představuješ přechod na Nette Components? Jestli Nette 3 už bude rozkomponentované, nebo to zůstane jen jako alternativa? Změní se nějak práce s frameworkem?
Obecně toto vítám, ale konkrétně nedokážu odhadnout co to v praxi obnáší. :)

Filip Procházka

Kdo si stáhne distribuční balík tak rozdíl nepozná. Kdo bude používat composer tak by taky rozdíl neměl pokud možno poznat.

Super je, že teď můžeme vnucovat jednotlivé komponenty do jiných projektů :)

hrach

Moc nechapu, proc je tam minimum stability dev. Aplikovatelny je to jenom na root package, tj. smysl to ma jen pri instalaci zavislosti pro vyvojare v nette, a tam mi to moc opodstatneny neni, protoze vsude stejne requiruju dev nette.
A pripravovanem commitu pro master neni replace. Ten by tam asi byt mel, ne?

Filip Procházka

hrach napsal(a):

1. Moc nechapu, proc je tam minimum stability dev. Aplikovatelny je to jenom na root package, tj. smysl to ma jen pri instalaci zavislosti pro vyvojare v nette, a tam mi to moc opodstatneny neni, protoze vsude stejne requiruju dev nette.

Kvůli travisu. Ještě to bude funny až se budou vydávat stable verze :) Musí se to otagovat a přenastavit tak, aby to žralo vývojovou verzi svých závislostí, ale aby je to nevyžadovalo když si instaluješ knihovnu.

Například nette/component-model se musí otagovat na v3.0 a přidá se do extra branch-alias: {"dev-master": "3.0-dev"}. Potom se do nette/forms musí změnit závislost z @dev na "nette/component-model": "~3.0@dev" a taky otagovat.

Tím pádem když dáš composer require nette/forms tak se ti nainstaluje otagovaná verze nette/component-model, ale na travisu se díky minimum-stability budou instalovat vývojové závislosti.

David Grudl

Pro uživatele celého frameworku se vlastně nic nemění, distribuční balík bude vypadat stejně, instalace Composerem taktéž. Je to vidět i na Travisu, celý framework jsem smazal, ponechal jen testy a ty bezchybně prochází.

Oproti verzi 2.1 dojde jen ke dvěma větším změnám: Nette\Diagnostics bude Tracy a Nette\Latte bude Latte s (jiným API, které ještě není commitnuté). Původní třídy budou fungovat jako aliasy.

Z toho důvodu bych se asi klonil k označení verze 2.2. Betaverzi bych rád vypustil během několika dní.

Repozitář nette/nette vlastně obsahuje jen Configurator a deprecated stuff (kam směřuje i NetteExtension). Může to být i místem pro testy jsoucí napříč více balíčkama. Readonly je jen dokud nemergnu https://github.com/…te/pull/1461.

Configurator by se mohl přesunout i do vlastního balíčku (nette/configurator nebo nette/bootstrap nebo whatever), díky čemuž by bylo možné namíchat i jinou podobu frameworku a nepříjít o Configurator.

hrach

Filip Procházka: ok, takže chápu minimum stability, nechápu pořád, proč je tam dev. Akorát se to bude muset celé retagovat. Kdyby tam byl aktuální tag, respektivě neco ve smyslu 2.2., tak se to přece nemusí retagovat. A paradoxně navíc, uplně si nejsem jistej, jesltije dobře, že nette-db 3.0 bude muset vyžadovat nette-utils 3.0, přeci by bylo fajn trackovat realnou zavislost, a povolit třeba nette-utils 2.0, ne?

Filip Procházka

@hrach tagovat se to bude muset tak jako tak

David Grudl

Zatím tam žádné tagy nejsou, proto ten dev. Samozřejmě je ok, aby byly závislosti i na jiné verze.

Filip Procházka

Furt ještě ladíš nebo vyčkáváš než tě ještě něco napadne? :)

MartinitCZ

Chtěl jsem se zeptat, jestli už se ví, jaké označení tato verze ponese?

2.2
3.0

Honza Marek

Na PoSobotě David řikal 2.2

David Grudl

Done https://phpfashion.com/…te-framework

MartinitCZ

Composer na dev verzi nefunguje:

Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - nette/nette dev-master requires nette/application ~2.2 -> no matching pack
age found.
    - nette/nette dev-master requires nette/application ~2.2 -> no matching pack
age found.
    - Installation request for nette/nette dev-master -> satisfiable by nette/ne
tte[dev-master].

Editoval martinit (2. 4. 2014 11:53)

David Grudl

Zatím je potřeba v composer.json uvést "minimum-stability": "dev".

MartinitCZ

@**David Grudl**: Aha. Tak snad to brzo půjde normálně, jelikož Symphony v dev verzi opravdu nechci :)

Filip Procházka

Nebo můžeš vyjmenovat jednotlivé nette balíčky které se mají instalovat a explicitně říct že mají být @dev, to jde taky.

David Grudl

Tak než vyjde stable to určitě pár týdnů potrvá.

mishak

Ad 3. {cache} stejně neposkytuje přístup ke všem vlastnostem nette/cache (jen id, expire a tags). Byl bych pro interface co načte/zapíše pomocí makra (save: id, expire, tags; load: id) a most z latte pro nette/cache a jen doporučení pro nette/cache.

Ad 5. Mi Security mimo Application nedává moc smysl. Most a doporučení v composeru bude asi nejlepší řešení. Jak psal @enumag.

mishak

Co sem si všiml plno balíčků se chce osamostatnit, v čemž bych jim nebránil. Nedávalo by ale větší smysl rozdělit nette/utils (Arrays, Strings …) ještě do nette/(common|object) (Object, mixin …) ať se nemusí v balících nahrazovat užitečné funkce jejich inline zápisy? Např.: Strings::truncate který používá mb_string pokud je dostupný.

nette/utils pak může být nadosmrti bez BC breaků a jen s přidávanou hodnotou ve verzi 0.1.

Editoval mishak (2. 4. 2014 15:24)

David Grudl

Z mého pohledu je hotovo a další změny v balíčcích, tak jak nyní jsou, bych dělal jen ze skutečně vážných důvodů.