RFC přidat metodu setReadonly() do Forms\Controls\BaseControl

@MajklNajt

kedy potrebuješ do databáze posielať dáta, ktoré tam už sú?

Např. když vytvářím nový článek, potřebuji uložit do created_at aktuální datum, a potřebuji datum zobrazit + blokovat editaci. U nového záznamu datum v databázi ještě není.

$form->addDate('created_at', 'Datum založení')
    ->setReadonly();

// .....


$form['created_at']->setDefaultValue(DateTime:from('now'));

Editoval m.brecher (29. 3. 18:06)

@DavidGrudl

readonly

Ideální název pro prvek fomuláře, který nelze editovat, ale data zobrazuje a odesílá. Klíčové slovo readonly je takto univerzálně používáno napříč programovacími jazyky. I PHP readonly properties nelze editovat, ale data poskytují.

disabled

HTML norma definuje, že atribut disabled blokuje editaci a funkci formulářového prvku. Data se nesmazávají ale naopak zobrazují. Data se ale neodesílají a zda se data v disablovaném prvku po submitu zobrazí záleží ne na normě html, ale na způsobu zpracování formuláře na serveru. Pokud po submitu do formuláře vykreslíme data, která formulář odeslal, tak z disablovaných prvků data zmizí – protože je formulář neodeslal. Takové chování nedává smysl – data vidím a po odeslání zmizí. Můžeme ale data po submitu u disablovaných prvků obnovit z default values a potom data nezmizí. To je žádoucí a užitečná funkce. V současné implementaci setDisabled() v nette formulářích to přesně takto je a je to tak správně.

Můžeme si vybrat ze dvou variant, které se obě hodí:

a) setDisabled() – data vidím, data nezmizí, nelze editovat, data se na server NEODEŠLOU
b) setReadonly() – data vidím, data nezmizí, nelze editovat, data se na server ODEŠLOU

Názvy mě připadají výstižné, v souladu s html normou i s všeobecným povědomím o disabled a readonly

nedostatky disabled v nette

V Nette formulářích se nastavením setDisabled() aktuální default value prvku smaže a data se tedy musí do prvku dodat později. To je v rozporu s normou html, která neříká nic o smazání dat, pouze se blokuje funkce prvku, blokuje se focus a neodesílají se data. Ale data která v prvku jsou odeslána ze serveru se zobrazí a nemažou. Proto bych myšlenku, že setDisabled() má aktuální hodnotu v prvku formuláře smazat úplně opustil. Jinak bude docházet k matoucím situacím, kdy někdy data v disabled prvku budou a jindy ne.

erased

Pokud by měl někdo potřebu mít metodu na spolehlivé smazání dat z formulářového prvku, můžeme přidat metodu setErased(), která data v prvku spolehlivě smaže, ale ne v závislosti na pořadí volání metod, ale vždy za každých okolností. Mazání dat bych ale z metody setDisabled() určitě navždy odebral.

Editoval m.brecher (7. 4. 0:53)

Hele, vám to tak funguje?

$form[‚foo‘]->setDisabled()->setOmitted(true); // není vůbec ve výpise
$form[‚foo‘]->setDisabled()->setOmitted(false); // ve výpise je, ale není vyplněn; aby ne, když se vůbec nepošle

Aktuálně to řeším tím, že si posílám tu hodnotu ještě jednou v hidden, což pochopitelně není vůbec hezké.
Nebo si to nastavuju pomocí setDefaultValue(), ale to si zase vynucuje, abych tu entity vytahoval znova z databáze.

nette/forms v3.2.0

Editoval Taco (20. 4. 2:10)

m.brecher napsal(a):

$form['foo']->setDisabled()->setOmitted(false)   // funguje jako readonly

Výše uvedená kombinace funguje jako readonly nastavení na inputu, data vložená ->setDefaultValue() se zobrazí a nejdou editovat a jsou v odeslaných $values formuláře, ale za těchto dvou podmínek:

a) nejprve se na inputu zavolá ->setDisabled(), až potom se volá ->setDefaultValue()
b) ->setDefaultValue() se musí zavolat před událostí anchor formuláře

Pokud není splněno b) tak se může stát, že po submitu formuláře $value z disablovaného inputu zmizí.

Když je splněno a) i b), potom ->setDisabled()->setOmitted(false) i samotné ->setDisabled() funguje spolehlivě.

$form[‚foo‘]->setDisabled()->setOmitted(false); // ve výpise je, ale není vyplněn; aby ne, když se vůbec nepošle

Toto by mohl být případ, kdy není splněno pravidlo b)

Tak jsem si to právě vyzkoušel, a je to trochu jinak.
Ano, podmínka a) musí být splněna, což je IMHO jen komplikace a nemá to vliv na podstatu věci.
Podmínka b) neplatí. Nezáleží na tom.

Podstata věci je, se musí zavolat ->setDefaultValue() vždy (což je ostatně logické vzhledem k tomu, jak funguje html). Na tom jsem se spálil já, protože jsem si navykl plnit formulář jen jednou při inicializaci. No, tak v tom případě to s volbou setDisabled() dělat nemůžu.

Poznámka: disablování prvků by se mělo upravit tak, aby fungovalo spolehlivě 100% za všech okolností, aby to člověk použil a nemusel řešit, že různé věci okolo smí nebo nesmí. Jakmile nějak pokročíme v setReadonly(), tak bych se na tento problém podíval.

Se obávám, že bez nějakého hnusného hacku to nepůjde. Protože ten formulář tam tu hodnotu nemůže doplnit, když ji nemá = nepřišla v POST.

@Taco

Podmínka b) neplatí. Nezáleží na tom.

Před 4 měsíci se o disablování vedla diskuse, kde se tento problém zmiňoval: https://forum.nette.org/…ba-framework#…

Zkusil jsem si teď ověřit moje tvrzení b) na nette/forms v3.2.1:

$form->addText('disabled', 'Disablováno')->setDisabled();
$form->onRender[] = fn() => $form['disabled']->setDefaultValue('abc');
$form->onValidate[] = fn() => $form->addError('error');  // vyvolám chybu, aby formulář zůstal v submitu

a potvrzuji, že máš pravdu a bod b) neplatí. Super, jeden problém je pryč.

Se obávám, že bez nějakého hnusného hacku to nepůjde. Protože ten formulář tam tu hodnotu nemůže doplnit, když ji nemá = nepřišla v POST.

Samozřejmě že funkce readonly jak ji navrhuji vyžaduje, aby se si vývojář nastavil setDefaults() a to jak pro vykreslený, tak i pro submitnutý formulář. Protože readonly prvek by měl být realizován jako html disabled s dodatečným doplněním default values po submitu.

Nejsem si vůbec vědom, že bych tam něco v poslední době měnil…

m.brecher napsal(a):

@Taco

Se obávám, že bez nějakého hnusného hacku to nepůjde. Protože ten formulář tam tu hodnotu nemůže doplnit, když ji nemá = nepřišla v POST.

Samozřejmě že funkce readonly jak ji navrhuji vyžaduje, aby se si vývojář nastavil setDefaults() a to jak pro vykreslený, tak i pro submitnutý formulář. Protože readonly prvek by měl být realizován jako html disabled s dodatečným doplněním default values po submitu.

Což mě osobně přijde pěkně na prd. Když vidím metodu setReadonly() tak očekávám, že to bude jen pro čtení. Podobně, když vidím, že je položka setDisabled(), že je disablovaná. V obou případech bych očekával, že hodnota přijde. V případě disabled možná chybně.

Vzhledem k tomu, že nejde rozumě a bez kouzel zajistit, aby tam ta hodnota, u disabled (a v důsledku ani u readonly), byla, tak bych na to rezignoval. A nechal bych to na setHtmlAttribute("disabled"). Protože to alespoň jasně přenechává zodpovědnost za chování na html.

m.brecher napsal(a):
To už je lepší aby framework měl vlastní implementaci readonly pomocí html atributu disabled, a počítat s tím, že do prvků musím dodat default values.

Vzhledem k tomu, že jsem se na tom opakovaně spálil, tak mi to lepší nepřijde. Je to neintuitivní a nepřímočaré.

Představuji si, že když bych si funkcionalitu musel řešit sám pomocí setHtmlAttribute(), že by mě to trklo spíš. Dle hesla ať to FW dělá pořádně nebo vůbec.

@DavidGrudl

máš pravdu, že ohledně disabled prvků se v nette forms nic nezměnilo. Chyba tam ale skutečně je a konečně jsem vypátral, kde přesně. Disablovaný prvek po submitu formuláře při určité nepříznivé konstelaci skutečně data ztratí. Testoval jsem takovýto jednoduchý formulář:

 $form->addText('disabled', 'Disablovaný')
    ->setDisabled()->setOmitted(false);

$form->addSubmit('send', 'Odeslat')
    ->onClick[] = $form->handleSend(...);

$form['disabled']->setDefaultValue('abcd');         //  OK
$form->setDefaults(['disabled' => 'abcd']);         //    OK

$form->onRender[] = fn() => $form['disabled']->setDefaultValue('abcd');     // OK
$form->onRender[] = fn() => $form->setDefaults(['disabled' => 'abcd']);       //  NOT OK

$form->onValidate[] = fn() => $form->addError('is_submitted');

return $form;

V testovacím formuláři jsem zkoušel kombinovat nastavení default value před/po anchoru a metodou setDefaultValue() a setValues(). Vždycky jsem zkusil jeden řádek s nastavením default values a ve 3 případech to funguje OK a v jednom případě data po submitu zmizí. Problém má metoda setDefaults(), zatímco setDefaultValue() je OK.

Editoval m.brecher (20. 4. 21:20)

OT: Jsem asi blbej, ale musím se zeptat. Proč zobrazovat datum vydání článku při vstoupení do formuláře, když datum je ještě neznámé? Když bude muset jet např. do nemocnice a pak vydá rozepsaný článek, tak najednou bude o 5 hodin starý a ne mezi novými, tam je rozhodující přece to kliknutí na odeslat. Pochopil bych ještě editovatelný čas a nemyslím to nějak zle, jen z přílišné zvědavosti se musím zeptat.

Abych to upřesnil, tak se jedná o disabled prvek při vytváření nového článku, takže běžný uživatel to nedokáže nastavit do minulosti aniž by mu běžel od ledna nonstop počítač s otevřeným tabem na formuláři. Proto jsem na konci věty psal, že bych pochopil, kdyby to byl editovatelný čas :)

Ptám se na tohle: Např. když vytvářím nový článek, potřebuji uložit do created_at aktuální datum, a potřebuji datum zobrazit + blokovat editaci.

V tomto případě se totiž „aktuální datum“ bude lišit od data vytvoření článku. Článek píšeš 30 minut, něco akutního ti do toho vleze, rozepsaný článek ze včerejška apod. a najednou to je včerejší článek a to asi nebude úplně cíl autora. Takže se mi to zdá spíše jako bug než feature. Datum vytvoření článku by se měl přiřadit teprve až v onSuccess a zobrazit jako disabled v editaci.

Lépe už to asi nedokážu popsat a nerad bych to tady zaspamoval, spíše mě zajímal odpověď autora.

Editoval Martk (22. 4. 13:09)

@Martk

Takže se mi to zdá spíše jako bug než feature.

Každá sebelepší feature se musí použít správným způsobem, jak už jsem napsal před chvílí, článek byl zjednodušený příklad.

Nepochopeno z důvodu, že tady neustále čtu, že se mají data odesílat na server, takže z toho vyplývalo, že je potřeba hodnota od uživatele i když je zrovna neaktuální/nevalidní. Ale ve skutečnosti jen chceš nastavenou hodnotu od programátora a ne odeslanou. Díky za upřesnění.

Existující metodu Nette formulářů setDisabled() sice lze použít pro zobrazení needitovatelné hodnoty, ale hodnota se na server neodesílá, což v řadě případů nevyhovuje.

2. setReadonly() – data vidím, data nezmizí, nelze editovat, data se na server ODEŠLOU

Editoval Martk (22. 4. 15:19)

m.brecher napsal(a):

@Taco

Představuji si, že když bych si funkcionalitu musel řešit sám pomocí setHtmlAttribute(), že by mě to trklo spíš. Dle hesla ať to FW dělá pořádně nebo vůbec.

Myslím, že Nette Framework podceňuješ. Pokud totiž použiješ html atribut readonly nebo disabled místo setDisabled()/setReadonly(), může Ti kdokoliv do “readonly” nebo “disabled” prvku podstrčit cokoliv a pak se může stát, že si uživatel přidělí vyšší roli než na kterou nemá právo apod…

Já Nette rozhodně nepodceňuji.

Opakováním pro zdůraznění: Mě sejří, že nemůžu vytvořit formulář, kterému nastavím hodnotu jednou při inicializaci. S volbou setDisabled() to přestane fungovat. Nejen, že mi to tu hodnotu nevrátí, ale při první chybě se to celé rozbije. Vím jak funguje html, a vadí mi to u něj úplně stejně.

Výsledek v mém případě je ten, že metodu setDisabled nepoužívám vůbec, a řeším to pomocí CSS, nebo jinak.

Argumentace podstrkáváním mě přijde zcela scestná. Protože všechna data posílaná a získaná od klienta jsou potencionálně nebezpečná bez ohledu na disabled. Třeba aktuální problém: chci editovat záznam, a chci disablovat typ záznamu, protože ten se měnit nemůže. I kdyby si to uživatel na své straně upravil, tak mi to chcípne na validaci, kterou samozřejmě dělám. Takže disabled tak jak existuje je pro mě jenom komplikace.

@Taco

Mě sejří, že nemůžu vytvořit formulář, kterému nastavím hodnotu jednou při inicializaci.

s tím je nejlépe se smířit, protože např. pro select nebo radio prvky musíš také dodat data vždycky – při inicializaci i po submitu. Já formuláře dědím z abstraktního předka a ten naplní formulář daty automaticky a ručně řešit to nemusím. Když nastavím prvku setDisabled(), nemusím už dělat nic dalšího, protože data se tam plní automaticky vždycky. Je to celé rozsáhlé a OT tohoto vlákna tak jenom to hlavní:

V modelové třídě mám VŽDY tyto metody kterými plním data do formuláře:

public function getDefaultOne(): array
{
	return [
        'state' => 'Draft',
        'created_at' => new DateTime()
    ];
}

public function getOne(): ?ActiveRow
{
    return $this->database->table('article')->get($this->id);
}

Formulář dědí z abstraktního předka FormControl, který dědí z UI\Control. FormControl má v sobě mimo jiné tento kód:

abstract protected function build(): BaseForm;

public function startup(): void
{
    if(isset($this->model) && $this->model->mode === Mode::Update && !$this->model->getOne()){
        $this->error('Záznam nebyl nalezen');
    }
    // ......
    $form = $this->build();
    $this->addComponent($form, 'form');
   // .......
    $form->onRender[] = $this->setDefaultData(...);  / zde se automaticky a vždycky naplní data
}

private function setDefaultData(BaseForm $form): void  // vybere z modelu správnou metodu podle módu formuláře
{
    match($this->model->mode){
        Mode::Create => $form->setDefaults($this->model->getDefaultOne()),
        Mode::Update => $form->setDefaults($this->model->getOne()),
        default => throw .....,
    };
}

Finální třídu formuláře podědíš z FormControl, implementuješ metodu build() která vytvoří formulář. Abstraktní předek se automaticky postará o naplnění formuláře daty a nemusíš psát hromadu nudného opakujícího se kódu. Potomek FormControl dělá kompletní servis formuláři, který má kompozicí vnořen ve svojí metodě. Obstará úkony, které v Nette aplikacích běžně dělá presenter nebo factory. Presentery, modelové třídy i finální formuláře mám jednoduché, protože ten kdo nejvíc pracuje a maká je abstraktní předek FormControl. Presenter v akci přidá finální třídu formuláře a spustí na ní startup().

Napsal jsem to sem proto, že si myslím, že problém nudného opakujícího se kódu vyřeší jedině nějaký systém a chytře vymyšlené abstraktní třídy, které by převzaly opakující se činnosti na svoje bedra.

Editoval m.brecher (23. 4. 1:55)

Pavel Kravčík napsal(a):

Martk napsal(a):

OT: Jsem asi blbej, ale musím se zeptat. Proč zobrazovat datum vydání článku při vstoupení do formuláře, když datum je ještě neznámé? Když bude muset jet např. do nemocnice a pak vydá rozepsaný článek, tak najednou bude o 5 hodin starý a ne mezi novými, tam je rozhodující přece to kliknutí na odeslat. Pochopil bych ještě editovatelný čas a nemyslím to nějak zle, jen z přílišné zvědavosti se musím zeptat.

Protože ho chceš nastavit do minulosti například. Abys měl každý měsíc třeba 2 články, ale píšeš je až v dubnu… protože jsi líný prase a chtěl si je napsat v lednu. :)

Pokud chci umožnit publikovat v minulosti, pak přece nebudu řešit readonly / disabled.

Naopak mně připadá nežádoucí, aby se disabled / readonly prvky na server odesílaly. Proč, když na ně uživatel nesmí sahat? Pokud si backend ta data neobstará jinak a sáhne pro ně do values, slepě důvěřuje, že uživatel ta data skutečně nezměnil. Jenže toho readonly / disabled zárukou není.

m.brecher napsal(a):

tak se data jakoby „odesílají“

Pokud řešíme „jakoby odesílají“ vs. „odesílají“, tak je to v pořádku.
Já myslel, že vlákno je o odesílaných datech na server, protože v úvodním postu jsi napsal:
„Ideální tedy je použít pro readonly prvky formulářů setDisabled(), který by ale odesílal hodnotu na server.“
A taková metoda imho potřeba není právě pro její nebezpečnost.

Položím otázku – věděl Jsi, že metoda setDisabled() poskytuje 100% ochranu proti podstrčení dat ??

Ano.

Já ne, protože v dokumentaci to napsané není a tak jsem předpokládal, že případně podstrčená data si musím ošetřit sám.

Deaktivace prvku – Mně z dokumentace přijde jasný, že setDisabled() automaticky ochrání před podvržením dat. Je tam vysvětlený téměr všechno o čem tu mluvíš. Vzhledem k tomu jak málo by se něco takovýho stejně dalo využít, proč prostě v takovém případě nenapsat o pár znaků navíc.
setReadOnly() je matoucí, vzhledem k tomu jak readonly v html normálně funguje.

Ještě k tomu příkladu jak jsi uváděl před tím. Datum, které se ukáže uživateli ve formuláři je pouze informace kdy právě uživatel začal vytvářet příspěvek. Přijde mi jako špatný desgin takovou informaci pojmenovat created at, protože to nevystihuje co ta informace říká.
Lepší by to bylo pojmenovat například draft started at a jak se formulář odešle, tak do databáze created_at uložit opravdový datum vytvoření příspěvku.

Popravdě bych řekl, že readonly má málo kdy využití v dobře navrženym formuláři.

Ps: Myslim, že to v dokumentaci bylo už před tím, ale nejsem si na 100% jistý. Každopádně bylo to tam ještě než David napsal, že neví proč by měl něco do dokumentace přidávat, protože mu to přišlo jasné.

Editoval jeremy (23. 4. 14:27)

Já bych to nechal jako setDisabled() protože to pořád je disabled prvek. Pokud na zkratce pro setDisabled()->setOmitted(false) tak trváš, tak mi jako nejlepší nápad přijde přidat parameter: bool $preserveDefault → setDisabled(bool $value = true, bool $preserveDefault = false).
Pak by použití bylo: setDisabled(preserveDefault: true). (Popřípadě to zkrátit jen na bool $preserve)

To skutečně každá dvojice metod, ze které je na první pohled jasný význam, potřebuje wrapper metodu, kde k názvu vs. významu potřebujeme 2 vlákna fóra a upravenou dokumentaci?

Pokud je navíc ojedinělá využitelnost pro pár lidí, proč si takový wrapper nedáte do společného předka pro Form?