checkbox a atribut value

Checkbox je prvek formuláře se dvěma stavy: zaškrtnuto/nezaškrtnuto, jiné hodnoty než true/false pak jaksi ztrácí smysl. Atribut value by měl sloužit jen jako nástroj k určení, co se s formulářem odešle v případě, že checkbox bude zaškrtnut (např. pro různé typy server-side jazyků). Pro reprezentaci složitějších struktur by měl sloužit RadioList nebo CheckboxList

laada napsal(a):

Myslim ze tohle je zbytecne slozity pohled a snaha napasovat to do intenci Nette. Checkbox (rozumej input type=„checkbox“) je nositelem hodnoty a ta by se mela, pokud je zaskrtnut, predat. Navic ta hodnota v POSTu je a Nette ji zbytecne nahradi booleanem.

Povedal by som skôr, že je to pohľad zdravého rozumu a logiky veci.

Mam Nette rad, ale v tomto pripade praci spis pridela.

Myslím, že v tomto smere sa Nette nezmení. Príjemnou vecou je, že nie je absolútny problém Nette\Forms\Checkbox prispôsobiť tak, aby sa správal, ako chceš ty:

class MyCheckbox extends Checkbox {

    public function setValue($value)
    {
        FormControl::setValue($value);
    }

}

Není vůbec problém to změnit, ale chybí mi tu argument nebo důvod. (že specifikaci psalo pár chytrých hlav důvod snad není)

Tohle podle mě řeší CheckboxList.

David Grudl napsal(a):

Není vůbec problém to změnit, ale chybí mi tu argument nebo důvod. (že specifikaci psalo pár chytrých hlav důvod snad není)

Mno, osobně bych za důvod aby se checkbox choval jako „normální“ input považoval třeba to že momentálně to pouze přidělává práci nestandardním chováním na které musím neustále myslet a speciálně to ošetřovat. (ale to už je v podstatě řečeno tím že to „standardní“ bylo za standardní skutečně uznáno z nějakého důvodu. Nic proti Porušování standardů, ale mělo by se to dít ze skutečně dobrých důvodů, jinak to (jako třeba zde) způsobuje jen zbytečné problémy)

důsledkem pak je to že nemohu hodnoty např. přímo ukládat do DB, odesílat emailem nebo cokoliv dalšího… (pod „přímo ukládat“ rozumněj nemuset převádět na správné hodnoty)

Taktéž předpokládám že s tím souvisí to že v důsledku „špeciálně vylepšeného chování“ nejde chceckboxu přidat např. validátor Form:INTEGER, což mi momentálně dělá opravdu těžkou hlavu ( teda hlavně proto že jsem zatím nenašel způsob jak prvku přidat validační pravidla postupně „po jednom“, ale to nesouvisí se zde řešenou otázkou)

David Grudl napsal(a):
Ufff, to je stále dokola – můžeš prosím uvést nějaký KONKRÉTNÍ příklad?

Já tedy stojím taky za přidání atributu value k checkboxu.

Checkboxy využívám hlavně v administraci stránek. Například: Vyberte fotky, které chcete smazat → vždy je náhled fotky a u ni je checkbox s ID fotky. K podobnému využití by se dalo vymyslet stovky příkladů, ale pořád by to bylo na stejném principu. Neříkám, že se to nedá udělat s nynějším chováním checkboxu, ale přijde mi to složitější. Kdyby například proměnná (pole) fotka[] obsahovala jen ID editovaných fotek, tak je to mnohem jednodušší, než procházet celé pole a kontrolovat jestli je TRUE nebo FALSE. Snadno se tato proměnná využije ve spolupráci s dibi – jinak bych musel vstup vždy nějak ošetřit.

Doufám, že to jako příklad stačí.

Jan Tvrdík napsal(a):

Tohle podle mě řeší CheckboxList.

ten to sice resi, ale IMHO je chyba ze pro dosazeni standartniho chovani je treba pouzivat nejakou extension

David Grudl napsal(a):

Checkboxu validátor Form::INTEGER? Proč? Checkbox je buď zatržený nebo ne, proč mu dávat takový validátor?

Mno, třeba proto že bude mít dynmackou hodnotu přidělaenou JS? Nebo lépe třeba proto, že má nějakou hodnotu a já chci mít jistotu že mi ji nikdo nenahradil něčím jiným co by např způsobilo chybu aplikace? Taky potřebuješ konkrétní příklad?

lopasovsky napsal(a):

Nette to ma takto vyriesene, pretoze je dobrym zvykom pouzivat input/checkbox na to, na co bol povodne urceny.

Nj. celá idea řešení stojí tím pádem na teoretickém odhadu jednotlivce k čemu že to bylo původně určeno. Připomíná mi to „co tím chtěl básník říci?“ z jisté nejmenované české komedie…

bfu napsal(a):

David Grudl napsal(a):

Checkboxu validátor Form::INTEGER? Proč? Checkbox je buď zatržený nebo ne, proč mu dávat takový validátor?

Mno, třeba proto že bude mít dynmackou hodnotu přidělaenou JS? Nebo lépe třeba proto, že má nějakou hodnotu a já chci mít jistotu že mi ji nikdo nenahradil něčím jiným co by např způsobilo chybu aplikace? Taky potřebuješ konkrétní příklad?

Tak ono se zdá že ten zmíněný Form::INTEGER nelze aplikovat ani na SELECT. To je také záměr? Také tam nemůže být hodnota kterou by mohlo mít smysl validovat?

redhead napsal(a):

u selectu se kontroluje, zda-li byla zadána jedna z hodnot určena metodou setDefault (případně addSelect). Čili uživatel tam může zadat ne-číslo, ale pokud nebude v tom určeném poli (které by bylo složeno z čísel) validace neprojde

no, podle toho jak to vidím já se opravdu kontroluje zda je tam jedna ze zadaných hodnot, ovšem je již zcela nepodstatné zda je některá z těch hodnot číslo nebo ne, při pokusu o přiřazení Form::INTEGER dojde k vyjímce.

navíc celý ten problém validátorů je o tom, že formuláře „generuju“ na základě dodané konfigurace kterou je možno na různých úrovních aplikace překrýt, čímž pak dojde třeba k tomu že se pokouším přiřadit validaci integeru k selectu a tak…

Každopádně, čím víc se v tom vrtám, tím víc dospívám k názoru, že NETTE byla opravdu špatná volba a musím říct říct, že mě opravu mrzí že jsem se nechal přesvědčit o použití NETTE na místo jakéhokoliv standadně se chovajícho nástroje, třeba i vlastnoručně napsanýho. Času by mě to stálo zhruba stejně. :-(

bfu napsal(a):

no, podle toho jak to vidím já se opravdu kontroluje zda je tam jedna ze zadaných hodnot, ovšem je již zcela nepodstatné zda je některá z těch hodnot číslo nebo ne, při pokusu o přiřazení Form::INTEGER dojde k vyjímce.

Tomu nerozumim proč dáváš uživateli na výběr hodnotu, která je špatná. U selectu má smysl snad jen validace Form::FILLED pro políčko „vyberte hodnotu“ a ta tam je.

Honza M. napsal(a):

bfu napsal(a):

no, podle toho jak to vidím já se opravdu kontroluje zda je tam jedna ze zadaných hodnot, ovšem je již zcela nepodstatné zda je některá z těch hodnot číslo nebo ne, při pokusu o přiřazení Form::INTEGER dojde k vyjímce.

Tomu nerozumim proč dáváš uživateli na výběr hodnotu, která je špatná. U selectu má smysl snad jen validace Form::FILLED pro políčko „vyberte hodnotu“ a ta tam je.

Ještě jednou a pomaleji: Já dávám uživatele hodnoty které jsou v pořádku. Dokonce takové které by prošli dodanou (a samozřejmě zbytečnou) validací. Problém je že pokud se takový zbytečný vlidátor pokusím přiřadit, dojde k chybě. A že je zbytečný ve chvíli kdy to definuju nevím.

Respektive: upravil jsem ten svůj generátor tak aby u prvků které jsou na to alergické odstranil validátory které prvky nesnesou.
Problém je, že jsem nikde nezaznamenal zmínku o tom že některé prvky (z definice HTML stejné nebo velice podobné) se chovají různě ve vztahu (nejen) k validátorům. Pokud bych toto věděl při návrhu aplikace, asi bych to zohlednil při deklaraci a nebo to celé pojal úplně jinak.

laada napsal(a):

jasir napsal(a):

Framework si bez problému upravíš jak potřebuješ. Můžeš si udělat StandardCheckBox a klidně i MyStrangeOnlyCorrectSelectBoxWithValidator.

Diskuze o změnách v chování frameworku je samozřejmě v pořádku, ale nemůžeš čekat, že se hned po pár výkřicích na fóru bude měnit chování, které spoustě vývojářů vyhovuje.

Ano upravitelnost FW je hezka vec, ale pouze kdyz si chci udelat neco specialniho. V pripade elementu input type checkbox se FW chova v rozporu se specifikaci. A je IMHO spatne ze bych si mel FW upravovat pokazde kdyz chci aby se choval v souladu se nejakou specifikaci.

Nerad bych aby Nette dopadlo jako produkty M$ ktere si vytvareji vlastni specifikace a implementace.

Zcela souhlasím, snad s vyjímkou toho že zde již dochází k tvorbě VLASTNÍCH STANDARDŮ podle toho jak si vývojáři MYSLÍ že by věci fungovat měli a zcela ignorují okolní svět :-( A každopádně zcela největší prů*er je že takové nestandardní chování není nikde zmíněno a člověk (já) na něj naráží za pochodu v místech a situacích kdy (mě) to stojí spoustu času (peněz) a hlavně nervů

LastHunter napsal(a):

1. Definice formulářů v PHP v Nette je kvůli tomu, že když by uživatel např. pomocí Firebugu podstrčil skriptu nějaké další pole či změnil definici stávajícího, aby to neprošlo validací a zabránilo se útoku. Do tohoto případu spadá i dodatečná úprava formuláře pomocí Javascriptu. Musíš holt vymyslet jinou architekturu svého řešení, určitě to nějak jde.

To je přesně ono. Aktuální stav neumožní spoustu věcí ktreré by dle definice HTML měli jít ale zde nejdou a NIKDE to člověk nezjistí předem dokud na to nenarazí.

LastHunter napsal(a):

2. Chápu, proč David nedal do Nette pro checkbox podporu value. Je to prostě boolean, zaškrtnuto ano/ne. Nelze to zaškrtnout 5× krát, půlkrát ani value-krát. Ale chápu, čeho chceš docílit – přenést pomocí checkboxu nějakou dodatečnou informaci. Co třeba pro to použít atribut name? Anebo input type="radio"?

také chápu proč to tak je a podle mě to není správně. Věc názoru? Možná.

Jo a radio použít nemohu jelikož po odkliku ho již standardně nelze odselectit a i kdyby to šlo tak by to bylo pro uživatele akorát matoucí.

LastHunter napsal(a):

Nette nemusí každému vyhovovat. Svou precizností a obsaženými myšlenkami. Když jsem si prohlížel jiné frameworky, přišlo mi, že jednotlivé věci jsou v Nette vyřešeny lépe a snadněji. Ale je to každého volba. Hlavně nezační šířit, že Nette dlabe na standardy. Není to totiž pravda.

Opět pravda, do jisté míry. Co mi na něm ovšem PŘEDEVŠÍM nevyhovuje je již zmíněná NEdokumentace odklonů od standardu, čímž se dá říci že NETTE nekašle na standard. Ono ho ohýbá stejně jako to dělá MS a kdo ví, třeba bude mít časem stejné zastoupení na trhu jako zmíněná firma… (čili ano, myslím si že se zde na standard víceméně kašle jelikož David někde výše napsal ať mu někdo dá důvod pro to to změnit JINÝ než to že to je uvedené v nějakém standardu (nebo tak mi to prohlášení a následná konverzace rozhodně vyznívá).

Každopádně děkuji za tvou reakci

lopasovsky napsal(a):

Ja som za rok pouzivania ziadne rozdiely nenasiel, takze to neviem posudit, ale ked ich je spusta a casovo uz je nezvladnutelne prepisat taku spustu zmien do vlastnych tried, pouzi radsej iny framework.

Toto je lichy argument. To si muze dovolit clovek co dela svoje veci pro zabavu, ale u z 60% rozdelaneho projektu pro zakaznika je to nemozne.

Zitra, pokud nezapomenu, sem zkusim dat nejaky jednoduchy priklad ze zivota a budu opravdu zvedav jak ho zastanci Nette implementace checkboxu elegantne vyresite se stavajici funkcionalitou.

No, musím říct, že jsem byl zprvu dost neobjektivní – protože jako David, jsem tuhle možnost nikdy nevyužil (to se mi ale jako moc dobrý přístup k vývoji frameworku nezdá), to ale neznamená že by se nemohla někde naskytnou situace, kde je to prostě zapotřebí a to bez toho abych musel využít nějaký 3rd-party plugin nebo přepisovat control, čili tím přidá práci (a jak doufám cílem FW je práci ulehčit).

Udělal jsem si totiž takový průzkum na internetu a zdá se že se to využívá celkem hojně. Našel jsem ho na email.cz, když si zaškrtávám email, u kterých chci provést nějakou akci (smazat, přesunout, …). V PHPMyAdminu to samé u tabulek, sloupců a řádků. Čili obecně v administracích, kde se pracuje s více položkami najednou. A napadá mě ještě například u těch ohromných možností (například na seznam.cz) pro zasílaní notifikací z různých oblastí světa, zde bych toho taky využil, protože by to stačilo prohnat nějakým cyklem a nekontrolovat jeden checkbox za druhým podle jména.

Doufám že se na mě nesesype celé fórum. Neberte to jako kritiku. Já Nette miluju a nedám na něj dopustit! Prostě se mi ale zdá, že v tomhle to David trochu nedotáh. A pokud to není, jak David píše, problém to přidat, tak by nad tím měl trochu zauvažovat.

Ve vší dobrotě a srdečnosti
redhead

PS: uff..

Osobně jsem pro zařazení CheckboxList do distribuce, protože mi přijde jako hodně užitečná komponenta.

já bych tohle řešil třeba až zároveň s tímto

David Grudl napsal(a):

Formuláře

• lepší podpora pro dynamický počet polí

viz: https://forum.nette.org/…ah-verze-1-0?…
tam to podle mě má smysl v aktuální podobě asi moc né…

David Grudl napsal(a):

CheckboxList určitě do distribuce přidám.

Bfu bych vřele doporučil použít co nejdříve jiný framework.

LOL. Děkuji za radu, sám bych na to nepřišel. Myslím že další komentáře jsou celkem zbytečné. HAND.

Ono jde o to, že v HTML formuláři může mít více prvků stejné jméno a přes HTTP se pošlou všechny, vždy s příslušnou hodnotou. PHP ale neumí taková data přijmout, respektive poslední prvek přebíjí všechny předcházející. Takže se používá trik s naznačeným polem name="val[]" a tak lze přijmout více prvků a hodnoty vytvoří pole.

Svým způsobem není vůbec žádný mezi

<input type=checkbox name="list[1]">
<input type=checkbox name="list[2]">

a

<input type=checkbox name="list-1">
<input type=checkbox name="list-2">

a

<input type=checkbox name="list[]" value="1">
<input type=checkbox name="list[]" value="2">

všechno sice vytvoří jinou strukturu, ale to je fuk. Programátora v Nette nemusí zajímat, jaká surová struktura vznikne, protože on s ní nepracuje, on pracuje v pohodlí komponenty.

Z pohledu architekta frameworku je pro mě klíčové, aby komponenta na výstupu vrátila jen ty data, která jsem nabídl – viz SelectBox. Volitelné value pro Checkbox to dle mého zaručit nemůže a proto tuhle vlastnost nepřidám. Mohl by to však zaručit CheckboxList, což je vlastně jakási obdoba MultiSelectbox.

Mimochodem, CheckboxList jsem ve frameworku dosud nepotřeboval, protože jsem vždycky měl něco jako

$sub = $form->addContainer('list');
foreach ($items as $key => $label) {
	$sub->addCheckbox($key, $label);
}

a na výstupu dostanu pole, vždycky klíč + boolean. A mám to se zárukou, že nikdo nic nepodvrhl. Navíc to lze přes extension method namapovat přímo do Form jako addCheckboxList. Nejsnadnější řešení.

Nicméně CheckboxList přidám, protože mi došlo, že uvedené řešení má jednu nevýhodu, byť pro mě teoretickou. Klíč $key totiž musí splňovat pravidla pro název komponenty, tedy to musí být číslo nebo alfanumerický řetězec.

laada napsal(a):

A tato nevyhoda vlastne spustila celou tuhle diskuzi, alfanumericky retrezec je bohuzel dosti limitujici.

Nerad bych začínal flame, ale mám obavy, že tato podmínka zavání špatným návrhem aplikace. Uveď mi prosímtě reálný příklad, kde k nějaké hodnotě s nejen alfanumerickými znaky neexistuje žádný jiný (například číselný) identifikátor a ani existovat nemůže.

Editoval _Martin_ (14. 9. 2009 11:31)

laada napsal(a):

co treba naparsovani csv souboru z ktereho si chces pred ulozenim do DB vyzobat jen nektere radky?

Tady přeci může být identifikátorem číslo řádku. Navíc je možné, že v CVS souboru již nějaký identifikátor bude.

laada napsal(a):

1. v tom souboru mohou byt nezadouci duplicity

A co má být? Buď to řeší automaticky nějaký parser toho souboru a nebo ty ručně – ovšem i tady zůstává číslo řádku jednoznačným ID.

2. kde vezmu tu hodnotu? Cislo radku me nezajima.

Jakou hodnotu? Naparsuješ soubor do pole, co prvek, to řádek. Vnitřní struktura každého prvku mě nezajímá, může to být pole, objekt, cokoliv. Pro pojmenování komponenty se použije číslo řádku, pro label hodnota (nějaký sloupeček name, celý řetězec, to je na tobě).

Samozřejmě, po odeslání formuláře budeš muset soubor naparsovat znovu (nebo jej již naparsovaný vyvolat třeba ze session). A proč? Protože chceš importovat soubor a ne libovolná data zaslaná uživatelem.

Pokud bys ovšem chtěl uživateli poskytnout možnost editace dat, tak potom zase použiješ tabulku s text inputy a hodnoty budeš mít přímo v nich a pro provázání textboxů a zaškrtávátka opět stačí jako ID číslo řádku.

Tobě přijde elegantní, když bude mít value atribut checkboxu hodnotu celého řádku z cvs souboru? To je přinejmenším zajímavé. Zvlášť při spojení s argumentem „řešení duplicity importovaných dat“.

Editoval Warden (14. 9. 2009 12:55)

Warden napsal(a):

Tobě přijde elegantní, když bude mít value atribut checkboxu hodnotu celého řádku z cvs souboru? To je přinejmenším zajímavé. Zvlášť při spojení s argumentem „řešení duplicity importovaných dat“.

mozna jsem to spatne vysvetlil. Konkretne v tomto pripade nepotrebuju cely radek. pole[urcity.sloupec]

David Grudl napsal(a):
Myslím že ne. Už proto, že „omezené intence“ je nesmysl

Ach ta psychologie :D

Diskuse se točí kolem best practises, tedy jak to dělat nejlépe.

Ano jde o best practice. IMHO best practice je ze FW pomaha a nevnucuje. A ja bych rad aby Nette bylo cim dal tim lepsi.

Fakt je takovej problem tu funkcionalitu implementovat aspon volitelne nebo uz je to osobni? :)