Ach ty formuláře (zamyšlení)

Ten gist je stejné řešení jako sám používám (až na to že většinou mi stačí nějaký BootstrapRenderer místo šablony) a osobně s ním nemám vůbec problém. V podstatě jako jedinou nevýhodu vnímám to že je potřeba přidat a modifikovat poměrně dost souborů na to, že „chci akorát primitivní formulář“.

Jediné usnadnění co mne napadá je napsat command pro kdyby/console který by vygeneroval základ komponenty + ten interface, přidal ho do configu etc.

Co se dá zjednodušit je přepsat továrničku v presenteru pomocí kdyby/autowired. Není to úplně čisté, ale ušetříš tu property pro inject a bude to lazy.

  	protected function createComponentFooForm(IFooFormFactory $factory)
  	{
  	  	$form = $factory->create($this->fooParam);
  	  	$form->onFormSuccess[] = function () {
  	  		$this->redirect('Nekam:presmerovat');
  	  	};
  	  	return $form;
  	}

Mimochodem řešení ze sandboxu s Factory jsem používal dříve změnil to na to co máš v tom gistu. Bylo to kvůli tomu že se mi u formulářů občas hodí přidat nějaký signál pro ajax a v tu chvíli už komponentu potřebuji. Předělávat factory na komponentu až ve chvíli kdy to potřebuju… brrr, zkoušel jsem, nikdy více. :-)

ano, je to viac pisania. ale nemas tie zavislosti nacpane v presenteri, obsluzny kod nemas v presenteri, cize mas prehladnejsie presentery, v komponente mas iba relevantny kod. a kedze je komponenta izolovana, znizuje ti moznost robit prasaciny. a nove zavislosti ti staci pridat do konstruktora komponenty a nemusis ich injektovat do presentera, potom v tovarnicke predavat komponente.

v konecnom dosledku to vedie k lepsiemu a prehladnejsiemu kodu. a lahsie sa premiestnuju komponenty z presenterov do inych, ak potrebujes, lahko ich zanoris, atd.

interface tovarniciek je u mna vacsinou copy paste, rename, cize to vela casu nezaberie. keby php podporovalo generika stacila by jedna :)

David Grudl napsal(a):

Vůbec nic se nemění! Dál si formuláře vytvářej tak, jak ti to nejlépe vyhovuje.

Udělal jsem takové jednoduché demo.

1. můžu vytvářet formuláře komplet v presenteru, tak jako doposud
2. pokud potřebuju, aby formuláře měly nějakou společnou vlastnost (nastavený translator, renderer, protection atd), tak $form = new Form v presenteru nahradím za $form = $this->factory->create() a použiju jednoduchou továrnu. Viz Sign2Presenter.php a FormFactory.php. Není třeba žádný interface.
3. Pokud budu mít stejný přihlašovací formulář na více stránkách, přemístím jej do továrny celý, viz SignPresenter.php a SignFormFactory.php. Továrna přitom může využívat základní továrnu FormFactory, když bude chtít. Není třeba žádný interface.
4. Pokud budu chtít formulář renderovat pomocí určité šablony, udělám si na to jednoduchou komponentu, viz TemplateControl.php a Sign3Presenter.php. Nepotřebuji žádný interface. A je dokonce jedno, jestli formulář vyrobím v presenteru nebo jinde, viz Sign4Presenter.php.
5. Pokud mi vadí vytváření komponenty mezi formulářem a presenterem, můžu na to jít jinak, třeba improvizovaně přes vykreslovač, viz Renderer.php a Sign5Presenter.php.

Mně to přijde krásně škálovatelné a jednoduché.

Jenže mně to právě nevyhovuje. Je to asi tím, že jsem na jakémsi pomezí, kdy 1. a 2. jsou pr mě sice jednoduché, ale vidím jejich nedostatky (zaplácnutý presenter, opakující se kód) a 3. – 5. je pro mě už těžko stravitelné, prostě se v tom nevyznám. Samozřejmě budu se snažit se v tom zorientovat a dát si vše do souvislostí, ale nyní se mi zdá, že nemohu používat formuláře přehledným způsobem, aniž bych neznal vnitřní souvislosti a principy Nette továren, komponent a jejich vazby na šablony. Rozhodně mi to nepřijde KISS, ani sexy.

Pokud jsem sám, kdo to tak vnímá, pak asi není co řešit a já budu více kroutit mozkové závity. Taky je pravděpodobné, že za půl roku mi to jasné přijde a budu se smát sám sobě.

Chtěl jsem jenom otevřít diskusi a docela by mě zajímaly názory méně zkušených Nettařů.

Taky jsem ti udělal asi nejjednodušší ukázku formuláře mimo presenter. Důležitá je ta továrnička, tady s Nette opravdu nijak nesouvisí, ani nedědí od Nette\Object. Souvislost je tedy jen přes třídu Form. Tuhle továrnu mám uloženou v modelu hned vedle entity a repozitáře (proto neřeš kód, ve kterém ukládám data – to je ORM, nikoliv Nette\Database).

V těch dvou dalších souborech je ukázka použití v komponentě, nebo v presenteru. Ještě se předpokládá, že máš tu továrnu zapsanou v configu, ale to už není věc formulářů, ale obecné DI. (Klidně si ji můžeš zcela bez DI vytvořit operátorem new, ale to se dnes už bere jako prasení – viz DI).

Komponentu se vyplatí vytvořit, pokud chceš stejný formulář používat na více místech a chceš mu vytvořit šablonu. Jinak klidně použij tu továrnu v presenteru.

Otázka trochu offtopic na @DavidGrudl: Dá se nějak při základním renderování DefaultRendererem říct, že pokud nemám vyplněný label, tak že se má vzít name? Jde mi o to, že ten formulář v modelu chci mít zcela prost všech textů a dalších s modelem nesouvisejících věcí. Všechno se mi podařilo eliminovat, naposledy chybové hlášky které se dají zapsat externě. Ale pro testování dokud formulář ještě nemá šablonu chci vědět, které políčko je které. Proto bych se přimlouval, jestli by DefaultRenderer nemohl vzít $name, pokud je $label === NULL.

No já teda nevim, osobně mám formy jako komponenty a daná komponenta si řeší vše, tj. sestavení formuláře a i jeho zpracování. Vůbec se mi nelíbí kdybych měl v presenteru psát handle na zpracování formuláře, sice je většina formů jen na jednom místě, ale občas se stane že jej potřebuju na dvou a více místech a takto je to úplně jednoduché, jen si přidám vytvoření komponenty formuláře a mám hotovo, nemsuím řešit kopírování handle atd…za mě je to jednodušší a přehlednější kompletně ten form oddělit včetně všech jeho závislostí.

@Šaman to myslím neumí.

@medhi je mi jasné, že to vůbec nemusí vypadat jednoduše, takže neváhej a ptej se.

@Šaman: tak to je už jen doplnění události, to samo taky na vybraných místech dělám, ale to je již jen dokončení chování. Flash zprávičky jsem taky řešil a vyřešil jsem to tak že si prostě té komponentě co dělá form, či něco jiného předám informaci kde ta flash bude zobrazena a o zbytek se postará komponenta, takže buď je flash v dané komponente formuláře a nebo probublá až do presenteru…to sem řešil hlavně pro případy kdy mám form či jinou komponentu s akcemi v modálním okně, tam by mě bylo vykresleni flashe v presenteru trochu na nic ;)

@akadlec: Nešly by tam předat spolu se šablonou pomocí {control fooFrom $template} ?

Jaký případ máš třeba na mysli?

S dovolením nad celou věcí pořád přemýšlím a myšlenky se mi trochu urovnávají. Zkusil jsem skoro všechny způsoby navrhované @DavidGrudl a popsal k nim jednotlivé nevýhody:

1. můžu vytvářet formuláře komplet v presenteru, tak jako doposud

• moc kódu v presenteru
• nelze použít opakovaně
• opakující se kód (translator, render, protection)

2. pokud potřebuju, aby formuláře měly nějakou společnou vlastnost (nastavený translator, renderer, protection atd), tak $form = new Form v presenteru nahradím za $form = $this->factory->create() a použiju jednoduchou továrnu. Viz Sign2Presenter.php a FormFactory.php. Není třeba žádný interface.

• moc kódu v presenteru
• nelze použít opakovaně

3. Pokud budu mít stejný přihlašovací formulář na více stránkách, přemístím jej do továrny celý, viz SignPresenter.php a SignFormFactory.php. Továrna přitom může využívat základní továrnu FormFactory, když bude chtít. Není třeba žádný interface.

• Nelze mít vlastní šablonu

4. Pokud budu chtít formulář renderovat pomocí určité šablony, udělám si na to jednoduchou komponentu, viz TemplateControl.php a Sign3Presenter.php. Nepotřebuji žádný interface. A je dokonce jedno, jestli formulář vyrobím v presenteru nebo jinde, viz Sign4Presenter.php.

• Cestu k šabloně píšu v presenteru ⇒ opakovaný kód ⇒ když se cesta k šabloně změní, musím to přepisovat ve všech presenterech, kde je formulář použit.
• do šablony se blbě posílají další parametry (?)

5. Pokud mi vadí vytváření komponenty mezi formulářem a presenterem, můžu na to jít jinak, třeba improvizovaně přes vykreslovač, viz Renderer.php a Sign5Presenter.php.

• do šablony se blbě posílají další parametry (?). Předpokládám použití formuláře v oddělené továrně, nikoli v presenteru, jako je v příkladu.

Chápu, že to lépe už asi vymyslet nejde a musím prostě zvolit vždy ten způsob, který se hodí na danou situaci. Z nějakého důvodu (přehlednost, pochopitelnost kódu po čase, rychlé přidání dalšího formuláře) mi ale přijde mít dělané v jedné aplikaci všechny formuláře stejným způsobem.

Pokud tedy jsou mé myšlenky správným směrem a formulář by měl splňovat všechny tyto podmínky,

• oddělenost v souboru
• vlastní šablona, definovaná na jednom místě, s možností předat parametry

tak existuje pouze jeden způsob, a to komponenta s interfacem. Tam je navíc nutné definovat interface, render metodu a vlastní event, aby šel použít v presenteru.

No a moje původní zamyšlení právě spočívalo v tom, jestli tento způsob, který je jinak perfektní – ale složitě se zapisuje – by nemohl umět framework „obalit“ nebo „nahradit“ pomocí nějaké syntaxe a sám třeba potřebné věci vygenerovat za mě. Jako to dělá třeba DI a Nette 2.3 už s určitým zjednodušením vlastně přišlo, když není v configu potřeba vypisovat všechny předáváné parametry navíc.

Editoval medhi (4. 2. 2015 11:47)

@akadlec: Tak to mi přijde jako to řešení s interfacem, které zmiňuji na konci, a které vidím i v Tvém kódu.