Formuláře – disable některých prvků
- Kamil Valenta
- Člen | 815
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 | 1260
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
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
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 | 863
@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
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.