Formuláře – disable některých prvků

tichopad
Člen | 4
+
0
-

Ahoj,
chtěl bych zadefinovat formulář UI\Form, který by měl být společný pro vkládání i editaci dat. Problém je např. u editace uživatele, kde bych nechtěl editovat login a heslo. Je nějaká efektivní cesta, jak toto řešit? Díky za tip.
Honza

Kamil Valenta
Člen | 783
+
0
-

Třeba nějak takto:

$login = $this->addText('login');
$pw = $this->addPassword('pw');

if (!empty($id)) {
	$login->setDisabled();
	$pw->setDisabled();
}

Otázkou je, zda je k tomu důvod. U loginu by se asi nějaký najít mohl…

Marek Bartoš
Nette Blogger | 1230
+
+3
-

Osobně setDisabled() používám pouze pro různé stavy (od určitého okamžiku už objednávka nemůže být upravena) a pro různé úrovně oprávnění.

Formulář pro vytváření a editaci je lepší řešit společnou základní třídou (buď abstraktní implementace Nette\Application\UI\Control nebo form factory). Není tak třeba podmínkovat vytváření nového záznamu / úpravu stávajícího a různé cases specifické pro vytváření či editaci. Též se mi často stává, že je hodnota nezměnitelná a nemá tak být v editačním formuláři a nebo je naopak změnitelná teprve při editaci. Pro úpravu obecných prvků v create/edit k nim můžeš přistupovat přes array access $form['password']->setRequired();

tichopad
Člen | 4
+
0
-

Tak zatím formulář vytvářím přímo v presenteru pomocí createComponent… a pak v actionEdit před vyplněním dat udělám disable/unset na prvky, které nechci měnit nebo je tam vůbec mít. A pak také bylo potřeba udělat úpravu onSuccess funkce, která zpracovává předaná data.
S nette teprve začínám, ale přesun do form factory mám v plánu, když je to best practice podle návodu.

Taco
Člen | 50
+
0
-

setDisabled() nepoužívám. Má (pro mě) nepohodlné vedlejší důsledky.

Scénář, který popisuješ řeším tak, že si pomocí css/js/… prvek nastavím jako readonly. Alternativně je možné prvek odstranit pomocí removeComponent().

Hlavně ale! Je třeba si uvědomit, že data přicházející od uživatele jsou potencionálně (v případě užití setDisabled() méně, v případě css zcela) vždy nebezpečná. Takže co nechceš umožnit měnit, tak musíš neumožnit v modelu.

m.brecher
Generous Backer | 814
+
0
-

@Taco

Takže co nechceš umožnit měnit, tak musíš neumožnit v modelu.

Nette formuláře mají setDisabled() neprůstřelně zabezpečené a výhodou setDisabled() je, že není potřeba mít paralelní ochranu v modelu.

Dokonce i disablování odesílacího tlačítka formuláře lze pomocí setDisabled() zablokovat a i zde poskytují formuláře Nette neprůstřelnou ochranu proti útoku.

setDisabled() nepoužívám. Má (pro mě) nepohodlné vedlejší důsledky.

Doporučuji setDisabled() používat místo css/js readonly.

Taco
Člen | 50
+
0
-

m.brecher napsal(a):

@Taco

Takže co nechceš umožnit měnit, tak musíš neumožnit v modelu.

Nette formuláře mají setDisabled() neprůstřelně zabezpečené a výhodou setDisabled() je, že není potřeba mít paralelní ochranu v modelu.

IMHO je to nesprávný úhel přístupu. Model by vždy měl být prioritní. To formulář je paralelní.

Dokonce i disablování odesílacího tlačítka formuláře lze pomocí setDisabled() zablokovat a i zde poskytují formuláře Nette neprůstřelnou ochranu proti útoku.

setDisabled() nepoužívám. Má (pro mě) nepohodlné vedlejší důsledky.

Doporučuji setDisabled() používat místo css/js readonly.

Doporučuješ nedoporučuješ, při vší úctě něco víc by si tam pro podložení svého doporučení neměl?

Proč ho nepoužívám: Nettí formuláře se chovají správně a bezpečně, což je Davidovou prioritou. Na vině je HTML. Aby se dalo používat setDisabled() je nutné při každém zobrazení formuláře disablované prvky inicializovat/nastavit. Což je neintutivní a protivné. Pokud někdo před každým zobrazením formuláře inicializuje, pravděpodobně si toho nevšimne. Já to tak ale nedělám prakticky nikdy (přijde mi to architektonicky nečisté), tudíž pokaždé při použití setDisabled() narazím.