BadSignalException po odoslaní formulára

je tam

public function renderPayment($id){
		$this->template->data = $this->data = $this->getModel('Invoice')->getTotal($id);
	}

a v BasePresenteri je

public function startup(){
		parent::startup();

		$user = $this->getUser();
		if((!$user->isLoggedIn() || !$user->isInRole('admin')) && $this->name!='Admin:Log')
			$this->redirect("Log:in");
		else
			$user->setExpiration(10800, FALSE);
	}

EDIT – neni nejaký limit na počet elementov v komponentoch? či na počet komponentov? (keďže sú tam 2 dosť veľké formy a 2 datagridy)

EDIT2 – taktiež som skúšal meniť názov formy, bez úspechu

Editoval DOBss (5. 12. 2012 21:27)

Jinými slovy, $this->data musíš naplnit už v actionPayment().

Máš to sice tzv. „OK“, už Ti to funguje, ale myslím IMHO, že ten koncept jak ten formulář konstruuješ je špatně. Prostě se mě tam něco nezdá, ale co?

• proč cpeš data z databáze do formuláře již v továrničce?
• proč používáš na nacpání dat metodu setDefaults() a ne raději metodu setValues() ?

Metodu setDefaults bych doporučil IMHO použít jenom na konstantní hodnoty, na nasosání dat z databáze použij metodu setValues(), ale proboha ne v továrničce, anýbrž v metodě render<Action>(). Ono setDefaults() také bude fungovat, ale korektnější je použít setValues().

Nyní analýza jak formulář pracuje s daty:

• formulář se vykreslí a zobrazí data z databáze, potřebujeme tedy v netodě render<Action>() nasosat tyto data do formuláře
• po POSTnutí formuláře se událost onSuccess zpracuje po metodě action<Action>() a před metodou render<Action>(), protože se v ovladači onSuccess provede na závěr přesměrování, metoda render<Action>() se ani nespustí, musíš tedy data sosat v metodě action<Action>(), zde ale pozor, data jsme přece do formuláře nasosli ještě před odesláním a v ovladači onSuccess jsou k dispozici tato data v modifikované podobě, proč je tedy sosat podruhé – zbytečné že ?
• formulář bude jak pracovat s existujícími záznamy z databáze, tak bude také vytvářet nové záznamy, já to řeší tak, že buďto znám id záznamu – potom provádím UPDATE, nebo neznám ID záznamu, potom provádím INSERT

Více podrobností k tomu, jak formulář řeším já:

• klíčové pro chování formuláře je to, zda je k dispozici parametr id záznamu tabulky, pokud není NULL tahám data z databáze v metodě render<Action>(), je-li NULL nechám formulář prázdný
• odeslání formuláře obsluhuji v události onSuccess – je-li id NULL provádím INSERT a přesměruji na stejnou akci + přidám id nově uloženého záznamu, není-li NULL provedu UPDATE záznamu s tímto id a přesměruji na stejnou akci a stejné id
• protože jsme na konci ovladače události onSuccess přesměrovali, nespustí se nám metoda render<Action>()
• protože v odeslaném formuláři jsou data z databáze irelevantní tak je nesosáme a metodu action<Action>() tedy vůbec nepotřebujeme
• po přesměrování se normálně vyvolá metoda render<Action>() a zobrazí se již aktualizovaný/uložený záznam nasosaný z databáze

Myslím, že to je korektní a logický postup a prosím ostatní kolegy zda by se k této důležité problematice formuláře vyjádřili.

Samotný kód je myslím jednoduchý, proto ho nepřikládám, jde zde spíše o analýzu.

@enumag: Díky za konstruktivní opozici, zamyslel jsem se a možná také přejdu na koncept dvou action add + edit se společnou továrnou.

Jaký je rozdíl mezi nastavením a vynucením hodnot formuláře není to jen slovíčkaření ? Analyticky bych viděl rozdíl mezi daty které přednastavujeme do nového záznamu – tyto data podstrčí aplikace a mezi daty z databáze do editovaného záznamu – tyto data pocházejí od uživatelů. Tím že bych pro startovací nastavení použil setDefaults() a pro pozdější setValues() bych odlišil charakter těch dat. V dokumentaci jsem nenašel kdy použít setDefaults() a kdy setValues(), kdy použít kterou jsem odhadnul z názvu těch metod. Navíc bych si tipnul že u běžně zpracovávaného formuláře bude asi úplně jedno kterou z těch metod použijeme.

Nicméně rozdíly mezi setDefaults() a setValues() nějaké jsou – mrkni se do zdrojového kódu, ty metody mají společné jádro a liší se nějakým obalem která řeší zda je formulář někam připojen apod. Kdyby jsi mohl více objasnit o co tam jde by bylo skvělé, tomu už já nerozumím.

Pokud se nějaký prvek ve formuláři disabluje, tak jeho value zůstane beze změny a nedá se editovat. Řekl bych, že při opakované validaci formuláře původní data z databáze nepotřebujeme – musíme pracovat s daty z prohlížeče.

Reset formuláře a návrat k původním hodnotám je subrequest, který bych řešil handlerem na onClick[]-u resetovacího tlačítka které by si pro data do databáze šáhlo, nebo by mohlo formulář přesměrovat na výchozí akci – tím by se také natáhly původní data.

mildabre:
Kdyby jsi mohl více objasnit o co tam jde by bylo skvělé, tomu už já nerozumím.

V tomhle kontextu je v setDefaults důležitá tahle část podmínky:

if (... || !$form->isSubmitted()) {

Tzn. pokud uživatel ve formuláři odeslal nějaká změněná data, setValues mu je přepíše pod rukama zpátky na původní; setDefaults ne.

Musím se též přiznat, že setDefaults jsem už pěkně dlouho nepoužil. Vždy píšu něco jako

public function actionEdit($id)
{
	// základní entitu/řádek stejně potřebuji vždy
	// buď z ní plním formulář, nebo samotnou entitu updatuji
	if (!$this->row = $this->articles->get($id)) {
		$this->error('Article not found');
	}

	if (!$this['articleForm']->submitted) {
		// načítání dalších výchozích hodnot, relací, ..
		// ..
		$this['articleForm']->setValues(..);
	}
}