Formuláře a DI Factories – best practice

v citelne verzi je to tady

prvni vec, nepojmenovavej to PageEditFormFactory je to matouci, nejedna se o tovarnu, ale o komponentu – lepsi je treba jen PageEditForm
ted k veci, v te verzi, co posilal enumag je chyba, v tom, co jsem posilal ja, je to uz opraveno, musis tam mit

$control['form']->onSuccess[] ..

ja osobne mam radsi vytvorit si vlastni onSuccess event v tom controlu, pak par veci v te ukazce od hosiplana chybi (ta komponenta potrebuje sablonu, resp render() metodu apod.)
takze:

class CategoryForm extends UI\Control
{
    private $database;

    public $onSuccess = array();

    public function __construct(Nette\Database\Connection $database)
    {
        parent::__construct();
        $this->database = $database;
    }

    protected function createComponentForm()
    {
        $form = new UI\Form;
        // mohu použít $this->database

        $form->addSubmit('send', 'Odeslat');
        $form->onSuccess[] = $this->processForm;

        return $form;
    }

    public function processForm($form)
    {
        // mohu použít $this->database
        // zpracovani formulare
        $this->onSuccess($form);
    }

    public function render()
    {
        $this->template->setFile(__DIR__ . '/categoryForm.latte');
        $this->template->render();
    }
}

v categoryForm.latte staci jen

{control form}

nebo ho muzes vykreslit manualne

s timhle zpusobem ti bude v presenteru fungovat to ->onSuccess jak jsi psal…

ja mam taky přímo u toho contrulu onSuccess, kde pak volá přímo model apod, ale potřebuji ještě po zpracování přesměrovat, což mi přijde nejlepší v presenteru. nebo je možná jiná varianta?

nevim, jestli jsme se uplne pochopili – ten onSuccess, o kterym mluvim, je vlastni event vytvoreny pres public $onSuccess = array(); a zavolany pres $this->onSuccess($form); – proste pri zpracovani formulare (pres onSuccess event formulare) zavolam vlastni vytvoreny onSuccess event komponenty (ktery uz nesouvisi s tim eventem formulare) :)) (snad je to srozumitelny)

presmerovani muzes provest i v komponente – a to bud v pres $this->presenter->redirect(), coz ale moc nedoporucuju, nebo pouze pres $this->redirect() (pouze presmerovani v ramci komponenty) – to je vhodne v pripade, ze komponenta je vice „samostatna“
pokud ta komponenta jen obaluje formular, je podle me lepsi flash message a redirect resit v onSuccess v presenteru

variantou 1 myslis jen tovarnu na formular? to jsem pouzival, neni to spatny reseni, ale ted uz na vse pouzivam vlastni komponentu – je to mnohem flexibilnejsi – muzes primo tam upravit vzhled formulare, vyresit snadnejc zpracovani a pracovat s ajaxem

EDIT: jeste k tomu zpracovani formulare, respektive co se mi nelibi na tom zpusobu, co ukazuje David s tou tovarnickou

1. kdo by cekal, ze „Factory“ se bude starat o zpracovani formulare? to by se melo postarat pouze o jeho vytvoreni
2. kdyz teda vezmu, ze factory ten formular muze zpracovavat, tak je celkem problem s prenosem nejakych stavovych promennych – v ukazce je $userId, coz se necha jeste celkem snadno prenest pres hidden pole (i kdyz se mi tenhle zpusob taky nelibi), ale je v podstate neresitelne, kdybys chtel predat primo entitu (respektive objekt) $user. v pripade formulare jako komponenty + tovarna predas $user to create() metody tovarny, ktera ho preda konstruktoru komponenty a ta si ho ulozi jako clenskou promennou

Editoval matej21 (11. 10. 2013 17:02)

EDIT: zmenil jsem nazev vlastni udalosti z onSuccess na onFormProcessed, aby bylo jasno, ktera je ktera

ok, tak jeste k tomu onSuccess :)
jedna se o vlastni udalost
formular ma v nette udalost onSuccess, na kterou muzu navazat ruzny callbacky.
v komponente si vytvorim vlastni udalost onFormProcessed, to udelam takto:

class PageEditForm extends Control
{
	public $onFormProcessed = array();
	...
}

ted budu moci pridavat na tuto udalost callbacky treba z presenteru:

//presenter
public function createComponentPageEditForm()
{
	$control = $this->pageEditFormFactory->create();
	$presenter = $this;
	$control->onFormProcessed[] = function() use ($presenter) {
		$presenter->redirect('default');
	};
	return $control;
}

(ta anonymni fce neni nyni navazana na onSuccess u formu, ale na moji vlastni udalost onFormProcessed u me vlastni komponenty, kterou budu muset spustit vlastnimi silami)

a posledni vec: mam vytvorenou udalost, mam na ni navazanej callback, ted uz jen staci tu udalost vyvolat, to bude nejlepsi az po zpracovani formulare (ulozeni do db atd). takze nyni na formular, ktery vytvarim v komponente navazu klasickou onSuccess udalost (ted je vazana na formular):

//komponenta
    protected function createComponentForm()
    {
        $form = new UI\Form;
        // mohu použít $this->database

        $form->addSubmit('send', 'Odeslat');
        $form->onSuccess[] = $this->processForm;

        return $form;
    }

nyni ve chvili, kdy Form spusti udalost onSuccess, tak se zavola callback $this->processForm, ten muze vypadat takto:

//komponenta
    public function processForm($form)
    {
        // mohu použít $this->database
        // zpracovani formulare
        $this->onFormProcessed($form);
    }

tam ulozim do databaze nebo cokoliv a pak – konecne onen moment :) – spustim moji definovanou udalost onFormProcessed a tim zavolam callback, ktery jsem navazal v presenteru

je to o par radku kodu vic (nechalo by se asi udelat BaseFormControl, ktery by resil ty udalosti apod a od kteryho bys dedil), ale oproti tomu, co pise hosiplan nemusim mit takovou znalost one komponenty, tedy nemusim vedet, ze obsahuje subkomponentu „form“ na kterou je potreba callback navazat – moji vlastni udalost onFormProcessed vidim na prvni pohled a je jasna. navic je kompatibilni s Kdyby\Events

Editoval matej21 (11. 10. 2013 18:03)

Tak měl bych ještě jeden dotaz, když chci nastavit defaultní hodnoty, případně nějak jinak manipulovat s formulářem. Máš nějaké lepší řešení, než si vytahovat přímo tu kompononentu v komponentně (tedy $this->getComponent(‚pageEditForm‘)->getComponent(‚form‘)) nebo si udělat nějakého společného předka pro control, od kterého pak budu dědit a tam ty metody budou?

kdyz teda vezmu, ze factory ten formular muze zpracovavat, tak je celkem problem s prenosem nejakych stavovych promennych – v ukazce je $userId, coz se necha jeste celkem snadno prenest pres hidden pole (i kdyz se mi tenhle zpusob taky nelibi), ale je v podstate neresitelne, kdybys chtel predat primo entitu (respektive objekt) $user. v pripade formulare jako komponenty + tovarna predas $user to create() metody tovarny, ktera ho preda konstruktoru komponenty a ta si ho ulozi jako clenskou promennou

a ještě kdybys mohl nějak upřesnit tohle, nějak se mi tam nedaří propašovat cokoli přes tu create() metodu…

Editoval Jiří Nápravník (12. 10. 2013 0:32)

Díky za upřesnění, to vypadá pěkně. Když budu mít defaultní hodnoty ve formulářové komponentě tak v podstatě manipulovat v presenteru nebude většinou třeba, či-li ot řeší ten problém.

Jenom se mi příliš nelíbí jedna věc a to, že budu muset zavádět instanční proměnnou u presenteru, kterou budu plnit ty defaultní data, co pak půjdou do komponenty. Přeci jen ten atribut budu používat jen v jedné metodě kvůli přenesení dat, či-li v tom presenteru je taková trochu navíc a nevím jestli dostatečně čistý. Ale ono asi nic jiného tam vymyslet nejde co? Snad jen ještě setter komponenty, který bych volal v actionEdit()

A ještě potom, když mám ted v konstruktoru té komponenty:

public function __construct(PageFacade $pageFacade)

a chi aby mi to načítalo z DIC automaticky, jako doposud a zároveň tam mít nějak tu možnost posunout tam třeba ty defaultní hodnoty. to je nějak rozumně řešitelné?

Editoval Jiří Nápravník (12. 10. 2013 16:20)