PresenterMapper, IPresenterFormatter apod

před 4 lety

David Grudl
Nette Core | 7148
+
+6
-

Na Githubu se velmi často objevují diskuse a pull requesty s rozdělením PresenterFactory na víc nebo míň menších tříd, zrovna teď @trejjam připravil pull request, který z PresenterFactory vyčleňuje tři nové třídy a umožňuje sestavit soustavu mapperů, které se pak zkoušejí jeden po druhém, předtím @FilipProcházka navrhoval úpravu, kdy by pro každý modul existovala samostatná třída mapující presentery atd.

Asi takto: mým úkolem je udržovat Nette tak jednoduché, jak je to jen možné, ale ne jednodušší.

Takže mě zajímá: jsou tady opravdu situace, které tohle rozdělení vyžadují? A jsou tak časté, aby to mělo smysl řešit přímo v nette/application? (tedy nikoliv vlastní implementací PresenterFactory?)

Nijak nezpochybňuji, že současný PresenterFactory může být v lecčems limitující, jen prostě dokud nebudu znát naprosto přesně v čem, tak to nemůžu řešit. Takže prosím o popis konkrétních use cases.

před 4 lety

trejjam
Backer | 64
+
0
-

Duvod proc jsem zacal upravovat PF byl o tom ze format/unformat metody jsou @internal.
Samotny PF je k dispozici v DI pouze jako interface, v kterem nejsou format/unformat metody.
Mym prvotnim cilem bylo povolit OR v PhpDoc var-inject (IDE s tim dokaze pracovat). To jsme v prislusnem pull req. zamitly.
Shodou okolnosti se v nette/app resil format pro mapper, kde @FilipProcházka navrh neco cemu by se mel blizit zmineny pull request do nette/app.

Tod k historii.

Co bych povazoval za dostatecne minimalisticke reseni je pouzit jen aktualni DefaultPresenterFormatter a jeho interface a nechat uzivatele si ho pripadne reimplementovat/vyuzit jednodussi cestou nez dedit cely PF.

před 4 lety

Eda
Člen | 213
+
+7
-

U nás bojujeme s PresenterFactory a presenter mappingem v této situaci: Máme CMS, v něm jsou definované nějaké moduly, které můžou mít X presenterů. Máme tedy třeba ArticleModule, který má třeba ArticleDetailPresenter. V některých situacích je potřeba na konkrétním projektu (webu), který tohle CMS využívá, některý z presenterů přepsat (+ podědit z „balíčkového“ presenteru). A v tu chvíli pak chceme, aby se akce „Article:ArticleDetail:default“ přestala mapovat na „CMS\ArticleModule\Presenter\ArticleDetailPresenter“ a začala se mapovat na „Project\ArticleModule\Presenter\ArticleDetailPresenter“. Hodilo by se tedy mít možnost např. nějak mappingy zřetězit.

Ano, jde to nějak řešit i teď (přepis celé PresenterFactory), ale kdyby existovala nějaká nativní a hezká cesta, bylo by to supr.

Nicméně, není to nijak kritická věc.

před 4 lety

Jan Tvrdík
Nette guru | 2563
+
0
-

@DavidGrudl Já bych přidal na to rozhraní formatPresenterClass a unformatPresenterClass. Mají stabilní API od Nette 0.7 a programátor si je nemůže dost dobře nahradit u sebe (tj. musí je poskytovat framework).

před 4 lety

Filip Procházka
Moderator | 4693
+
+1
-

Formátování presenterů a cest k šablonám jsou věci, které přetěžuje úplně každé CMS postavené na Nette. Imho je správná cesta na takové věci vytvořit rozhranní a udělat z toho služby – pak stačí přetěžovat/implementovat to, co skutečně chceš měnit

⇒ zbavíme se dalšího důvodu vytvářet MyCustomPresenterFactory a MyCustomBasePresenter.

před 4 lety

David Grudl
Nette Core | 7148
+
+2
-

PresenterFactory má metody:

  • getPresenterClass, což je vlastně formatPresenterClass s validací, že třída existuje, je instancovatelná a implementuje rozhraní IPresenter. Validace by se možná mohla přesunout do nějaké pomocné funkce, protože totéž bude chtít dělat i custom presenter factory, pak by mezi getPresenterClass a formatPresenterClass prakticky přestal být rozdíl.
  • createPresenter, který standardní PresenterFactory deleguje pryč
  • unformatPresenterClass, která se vlastně používá jen ke kontrole malých/velkých písmenek a pro samotný framework potřebná není. Vyžadovat ji v nějakém interface může znamenat komplikaci pro autory vlastních mapperů, přece jen opačný převod nemusí být triviální a pokud nebude využitá, proč ji vyžadovat

před 4 lety

trejjam
Backer | 64
+
0
-

Myslím si, že ::getPresenterClass a ::createPresenter nebude nutné přetěžovat, pokud jim už [vlastní ]mapper/formatter vrátí požadovanou třídu.

::unformatPresenterClass bych zachoval. Jestli autor vrátí validní string, nebo např TRUE (s vědomím, že vypnul validaci) bych nechal na něm.

před 4 lety

trejjam
Backer | 64
+
0
-

Sdělili jsme tu své názory, co teď?

před 4 lety

David Grudl
Nette Core | 7148
+
0
-

Krom Edy to nikdo zadny usecase nepopsal a pro nej soucasne reseni je good enough. To na refactoring nestačí.

Předávat si unformatPresenterClass lze i jako callback.

před 3 lety

Mabar
Člen | 287
+
0
-

Co se mapování týče, používáte někdo tento zápis?

mapping:
	*: ['', *, Presenters\*Presenter]

Co jsem to začal používat, tak vlastní mapování v cms nepíšu. Funguje to pro zápis Vendor\Module\Presenters\FooPresenter a pro submoduly taky

Editoval Mabar (28. 8. 2017 9:23)