přejmenovat metody render*() na view*()

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
pekelnik
Člen | 462
+
0
-

Ahoj,

když už jsme u toho přejenovávání, nebylo by od věci přejmenovat metody render*() na view*().

Argumentů pro se nabízí hned několik:

  1. Délka názvu: View je kratší a jednodušší na psaní.
  2. V metodách se nic nerenderuje: Metody mají s renderováním skutečně pramálo společného. Naopak se v nich často plní šablony – tedy provádí se obsluha „view“.
  3. Zmatek v životním cyklu: Metody afterRender() se volají před samotným renderováním. afterView by dávalo lepší smysl protože by nevadilo že se provádí před samotný renderováním
  4. Sjednocení terminologie: action a view jsou už používané termíny v routách i jinde a zatímco action-metody se jmenují action* – tak view-metody se jmenují render*()

Co si o tom myslíte?

despiq
Člen | 320
+
0
-

Zni to logicky, jen ma asi David nejaky osobni duvod proc to tak je, jinak by to asi uz prejmenoval davno?

Ale treba ne.

Patrik Votoček
Člen | 2221
+
0
-

Ono to má asi malinko historycké důvody protože view ve frameworku dříve existovalo (dnešní action) viz https://github.com/…b13a94aefef8https://forum.nette.org/…u-presenteru

JajazXbm
Člen | 29
+
0
-

Byl bych rozhodně pro, určitě se mi to líbí, ale kdyby to nebyl tak obrovský BC break.

Jan Tvrdík
Nette guru | 2595
+
0
-

Pokud to chce mít někdo přejmenované, tak to lze udělat naprosto čistě vložením metody formatRenderMethod do BasePresenteru.

protected static function formatRenderMethod($view)
{
    return 'view' . $view;
}
Honza Kuchař
Člen | 1661
+
0
-

JajazXbm napsal(a):

Byl bych rozhodně pro, určitě se mi to líbí, ale kdyby to nebyl tak obrovský BC break.

To samozřejmě až do verze 1.0.

Petr Motejlek
Člen | 293
+
0
-

Drív, když ještě existovaly metody prepare*, tak jsem je používal a render* jsem měl prázdné – řídil jsem se názvem: Když si chceš něco natáhnout z modelu, předat to šabloně, atd., udělej to v prepare* a v render* se starej jen o nějaké vykreslení. Představoval jsem si to tak, že všechno, co by ještě mohlo nějak selhat (třeba spadlá databáze, atd.), by se mělo dát do prepare*, protože se počítá s tím, že bude mít Presenter ještě čas na přesměrování na ErrorPresenter. Později, když se prepare* začaly rušit, dozvěděl jsem se, že to, co v nich dělám, by se mělo správně dělat v render*…

Název render* je strašně zavádějící, určitě mi ale přijde hezčí sloveso, než jen podstatné jméno. Když si navrhnované view* srovnám s handle*, tak je to takové nefunkční. Handle = nějak se podle * zachovej (a to je přesně to, co ta metoda dělá). View = Dívej se na * – to je ale trochu divné, já se přeci chci dívat, ta metoda mi to musí ukázat, takže raději render*.

pekelnik
Člen | 462
+
0
-

Historické důvody jsou mi jasné. Chtěl jsem vynést na světlo skutečnost, že už pominuly :)

Petr Motejlek
Člen | 293
+
0
-

pekelnik napsal(a):

Historické důvody jsou mi jasné. Chtěl jsem vynést na světlo skutečnost, že už pominuly :)

Já ale o historických důvodech pro existenci render* vůbec nemluvil…

Petr Motejlek
Člen | 293
+
0
-

Od rána přemýšlím o tom, jestli by nebylo vůbec nejlepší se render* metod úplně zbavit. Vždyť takový view není nic jiného než speciální případ signálu. Signál se od view liší jen tím, že nemá vlastní šablonu a obvykle se po jeho vykonání provede nějaký redirect.

Ono by vlastně stačilo udělat, že se ke každé handle* metodě budeme chovat stejně, jako k render* – tzn. bude mít k dispozici svoji šablonu a když skončí úspěšně, dojde k vykreslení té šablony. Když bude daná handle* metoda skutečně jen něco provádět a hned končit, udělá na svém konci redirect na nějakou jinou handle* metodu, která už bude moct kreslit šablonu.

hrach
Člen | 1823
+
0
-

Nesouhlasím. Ani s přejmenováním, ani s úvahou ohledně nějakých handle* metod s přesměrováním. Vždyť právě právě v handle* je ta krása. Proč proboha překopávat strukturu, který funguje? Naprosto zbytečné, přidanou hodnotu to dle mě nepřinese.

despiq
Člen | 320
+
0
-

Ono by vlastně stačilo udělat, že se ke každé handle* metodě budeme chovat stejně, jako k render* – > tzn. bude mít k dispozici svoji šablonu a když skončí úspěšně, dojde k vykreslení té šablony. Když > > bude daná handle* metoda skutečně jen něco provádět a hned končit, udělá na svém konci redirect na > > nějakou jinou handle* metodu, která už bude moct kreslit šablonu.

to se mi nelibi

Honza Kuchař
Člen | 1661
+
0
-

hrach napsal(a):

Nesouhlasím. Ani s přejmenováním, ani s úvahou ohledně nějakých handle* metod s přesměrováním. Vždyť právě právě v handle* je ta krása. Proč proboha překopávat strukturu, který funguje? Naprosto zbytečné, přidanou hodnotu to dle mě nepřinese.

Máš pravdu, že přidaná hodnot je malá. Resp. u přejmenování by to možná mohlo snížit wtf faktor. Ale to je asi tak vše.

hrach
Člen | 1823
+
0
-

no, já jsem pracoval s jinými frameworky, dělal jsem i vlastní, takže sem „musel objevit strukturu“ nette, a naopak mi render přijde míň wtf než nějaký view;

  • render – evokuje mi, že je to to spojeno už s konkrétní šablonou – tedy správně
  • action – spojuje se mi s tím, že „se to volá v url“
  • view – mi přijde něco na pomezí, ztrácím se v tom …
norbe
Backer | 405
+
0
-

Docela souhlasím s tím, že navrhovaná změna na viewNeco je taková divná a udělalo by to více škody než užitku.

S čím by se ale mohlo něco udělat, je metoda afterRender, to už je něco, co skutečně evokuje, že výstup byl odeslán a v současné době (kdy je volána ještě před výstupem) pro ni nemám (což neznamená, že se nehodí někomu jinému) žádné smysluplné použití.

pekelnik
Člen | 462
+
0
-

Chtěl bych podotknout, že tahle diskuse není o tom zda rušit nebo nerušit cokoliv :) Argumenty proti kterým případně můžete něco namítat jsou napsané v prvním příspěvku ;)

bazo
Člen | 620
+
0
-

norbe napsal(a):

Docela souhlasím s tím, že navrhovaná změna na viewNeco je taková divná a udělalo by to více škody než užitku.

S čím by se ale mohlo něco udělat, je metoda afterRender, to už je něco, co skutečně evokuje, že výstup byl odeslán a v současné době (kdy je volána ještě před výstupem) pro ni nemám (což neznamená, že se nehodí někomu jinému) žádné smysluplné použití.

mohlo by sa s tym spravit to, aby sa fakt vykonavala az po renderNieco

Honza Kuchař
Člen | 1661
+
0
-

pekelnik napsal(a):

Ahoj,

když už jsme u toho přejenovávání, nebylo by od věci přejmenovat metody render*() na view*().

Argumentů pro se nabízí hned několik:

  1. Délka názvu: View je kratší a jednodušší na psaní.
  2. V metodách se nic nerenderuje: Metody mají s renderováním skutečně pramálo společného. Naopak se v nich často plní šablony – tedy provádí se obsluha „view“.
  3. Zmatek v životním cyklu: Metody afterRender() se volají před samotným renderováním. afterView by dávalo lepší smysl protože by nevadilo že se provádí před samotný renderováním
  4. Sjednocení terminologie: action a view jsou už používané termíny v routách i jinde a zatímco action-metody se jmenují action* – tak view-metody se jmenují render*()

Co si o tom myslíte?

Když se vrátím opravdu k tomuto příspěvku, tak musím říct, že s ním souhlasím!

Petr Motejlek
Člen | 293
+
0
-

@hrach: trochu tvrdá reakce, podle které soudím, že sis to jen málo promyslel, než jsi to vypustil na obrazovku. Nám evidentně o nějaké tvrdé překopání nešlo, my jsme jen lehce diskutovali (proto se to taky jmenuje Diskuze o vývoji frameworku) ;)

Postupem času jsem si všiml, že se snažím většinu činností, které aplikace dělá, delegovat na Controly. Hlavní důvod pro mě je asi ten, že Control můžu použít na více místech, což se o Presenteru říct nedá. Díky tomu ale už prakticky vůbec nepotřebuju render* a action* metody u Presenterů, protože action* je pro mě handle* Controlu a render* je render Controlu.

Nikomu tohle nevnucuju, jen se to tady snažím prezentovat jako takový proof of concept, že to jde dělat i tak. Původně jsem trochu i doufal, že se někdo ozve, že to tak třeba dělá taky, nebo že to tak schválně zkusí také, ale co můžu dělat, jsem prostě jinej :D.

Honza Kuchař
Člen | 1661
+
0
-

Postupem času jsem si všiml, že se snažím většinu činností, které aplikace dělá, delegovat na Controly. Hlavní důvod pro mě je asi ten, že Control můžu použít na více místech, což se o Presenteru říct nedá. Díky tomu ale už prakticky vůbec nepotřebuju render* a action* metody u Presenterů, protože action* je pro mě handle* Controlu a render* je render Controlu.

Já to tak dělám taky. Action a render mám v aplikaci opravdu jen po málu.

Honza Marek
Člen | 1664
+
0
-

Hele jo… trochu se s těma úvahama o přejmenování všeho kroťte. Většinou po přejmenování vzniknou jen názvy, které jsou stejně špatné jako předtím, ale jsou jiné, takže si na to musí lidi znova zvykat a ani neví proč.

btw argument, proti kterému jsem něco namítal je tento:

když už jsme u toho přejenovávání

Honza Kuchař
Člen | 1661
+
0
-

Já bych to viděl spíš takto. Když už se nám blíží verze 1.0, která by to snad měla mít snad vyřešené.