Akce Kulový blesk je tady

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
David Grudl
Nette Core | 8082
+
0
-

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

  1. 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/utilsnette/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í.
  2. 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
  3. 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á…
  4. 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
  5. 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.
  6. 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
Moderator | 4668
+
0
-
  • 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
Nette Core | 8082
+
0
-

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

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
Člen | 2118
+
0
-
  1. 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.
  2. +1
  3. Doplnit až v Application.
  4. Ostranit.
  5. 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
Nette Core | 8082
+
0
-

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

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

Honza Marek
Člen | 1664
+
0
-

Dobrá práce.

  1. Metody getReflection a toReflection zrušit.
  2. IHtmlString je správná cesta.
  3. Makra {dump} a {cache} – jo
  4. @serializationVersion zrušit
  5. IUserStorage podle mě nemá v http co pohledávat. Dal bych do security.
  6. 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
Člen | 2118
+
0
-

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

David Grudl
Nette Core | 8082
+
0
-

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

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

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

David Grudl
Nette Core | 8082
+
0
-

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

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

enumag
Člen | 2118
+
0
-

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

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
Nette Core | 8082
+
0
-
Šaman
Člen | 2632
+
0
-

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

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
Člen | 1834
+
0
-
  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.
  2. A pripravovanem commitu pro master neni replace. Ten by tam asi byt mel, ne?
Filip Procházka
Moderator | 4668
+
0
-

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

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

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

@hrach tagovat se to bude muset tak jako tak

David Grudl
Nette Core | 8082
+
0
-

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

Filip Procházka
Moderator | 4668
+
0
-

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

MartinitCZ
Člen | 580
+
0
-

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

  1. 2.2
  2. 3.0
Honza Marek
Člen | 1664
+
0
-

Na PoSobotě David řikal 2.2

MartinitCZ
Člen | 580
+
0
-

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

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

MartinitCZ
Člen | 580
+
0
-

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

Filip Procházka
Moderator | 4668
+
0
-

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

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

mishak
Člen | 94
+
0
-

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

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

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