PresenterMapper, IPresenterFormatter apod

David Grudl

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.

trejjam

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.

Eda

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.

Jan Tvrdík

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

Filip Procházka

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.

David Grudl

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

trejjam

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.

trejjam

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

David Grudl

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.

Marek Bartoš

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)