checkbox a atribut value

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
laada
Člen | 35
+
0
-

Zdravim,
vim ze uz se to tu resilo, nicmene mi to neda.

Umi (jiz) Nette predat skutecnou hodnotu (atribut value) zaskrtnuteho checkboxu, tedy ne jenom boolean? Posledni stabilni verze (0.8) to neumi.

Reseni name=„pole[hodnota]“ je pouzitelne pouze do doby, kdy v hodnote chcete predavat jine nez alfanumericke znaky (napr.: domena.com).

Zajimave je ze v POST ta hodnota je a Nette ji odstrani.

Pokud ne uvazuje se o tom to doimplementovat?

Ve specifikaci html je tento atribut u input-checkboxu uveden a IMHO by to mel jakykoli FW respektovat.

dik

Panda
Člen | 569
+
0
-

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
Člen | 35
+
0
-

Panda napsal(a):

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

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.

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

kravčo
Člen | 721
+
0
-

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);
    }

}
laada
Člen | 35
+
0
-

kravco napsal(a):

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.

S tim nemohu souhlasit. Specifikaci elementu ‚input‘ jiste delalo par chytrych hlav a dalsich par chytrych hlav tu specifikaci oponovalo. To ze atribut ‚value‘ tam je a muze byt nositelem i neboolean hodnoty ma jiste svuj duvod.

Jakykoli FW by IMHO mel pouziti, v nasem pripade formularovych poli, zprostredkovat/zjednodusit a ne diktovat jakym zpusobem se maji pouzivat (to uz bylo vyspecifikovano v HTML specifikaci).

Rad bych znal na toto nazor autora, Davide?

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);
    }

}

diky zkusim.

David Grudl
Nette Core | 7790
+
0
-

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í)

laada
Člen | 35
+
0
-

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í)

IMHO hlavnim argumentem je ze Nette v tomto pripade neumoznuje pracovat s elementem input-checkbox tak jak implikuje specifikace HTML a jak s nim rada vyvojaru pracuje.

Ja bych to obratil. Me chybi duvod to delat tak jak je to v Nette ted.

Dam jednoduchy priklad struktury formulare:
email
datum
vycet firem (nase checkboxy) – Meda&Beda s.r.o., Nejlepsi a.s., Cuk a Gek.

Nette mi ted neumozni poslat (respektive precist) si zaskrtnute firmy v poli firmy[] a neumozni mi ani dat si nazvy firem jako klic, protoze tam muzou byt pouze alfanumericke znaky.

Selectboxem to resit nejde protoze si chci ty policka zobrazovat napriklad v tabulce.

A posilat si kazdou firmu zvlast a rozlisovat pak firmy od ostatnich dat formulare mi pripada neelegantni. Zrovna tak vyzobavat si to primo z POSTu.

Jan Tvrdík
Nette guru | 2595
+
0
-

Tohle podle mě řeší CheckboxList.

laada
Člen | 35
+
0
-

Jan Tvrdík napsal(a):

Tohle podle mě řeší CheckboxList.

Vypada to ze ano, diky.

bfu
Člen | 8
+
0
-

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
Nette Core | 7790
+
0
-

bfu napsal(a):

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í“…

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

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

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

Bernard Williams
Člen | 207
+
0
-

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
Nette guru | 2595
+
0
-

Tohle podle mě řeší CheckboxList.

laada
Člen | 35
+
0
-

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

bfu
Člen | 8
+
0
-

David Grudl napsal(a):

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

rozhodně souhlasím. Stále dokola hážeme hrách na zeď. Proč se chceckbox nemůže chovat standardně dle specifikace HTML? No dobrá, takže konkrétně:

mám formulář kde chceckbox presentuje přepínač ano/ne a do DB ukládnám hodnotu „ano“ a „ne“ je výchozí hodnotou.

Výpis tabulky je potom realizován formou jedoduchého table kde jsou zobrazeny páry (přeložený) název sloupce / hodnota. Stačí ti to takto konkrétně?

bfu
Člen | 8
+
0
-

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
Člen | 17
+
0
-

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

Nastavovat hodnotu checkboxu mi pride rovnako divne ako generovat input/text pre hodnotu true|false.

Na druhu stranu:

value = cdata [CA]
This attribute specifies the initial value of the control. It is optional except when the type attribute has the value „radio“ or „checkbox“.

http://www.w3.org/…t/forms.html

bfu
Člen | 8
+
0
-

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
Člen | 1313
+
0
-

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

bfu
Člen | 8
+
0
-

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ě. :-(

jasir
Člen | 746
+
0
-

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.

Editoval jasir (8. 9. 2009 9:24)

Honza Marek
Člen | 1664
+
0
-

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.

laada
Člen | 35
+
0
-

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.

bfu
Člen | 8
+
0
-

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ů

Ondřej Mirtes
Člen | 1536
+
0
-
  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.
  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"?

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.

bfu
Člen | 8
+
0
-

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):

  1. 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
Člen | 17
+
0
-

bfu wrote:

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í.

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.

Napriklad Zend checkboxy zvlada podla standardu (ci zvlada tu spustu dalsich rozdielov oproti Nette ale netusim, ale kde zacat asi vies: http://framework.zend.com/manual/en/)

laada
Člen | 35
+
0
-

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.

lopasovsky
Člen | 17
+
0
-

laada wrote:

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.

Stale vychadzam z faktu, ze tych rozdielov je podla slov „bfu“ spusta a ako uz sam „bfu“ uz povedal, mrzi ho ze Nette vobec pouzil, takze na dalsi projekt uplne evidentne pouzije nieco ine (aj keby David chovanie checkboxu teraz hned zmenil).

Pokial je 60% projektu uz napisaneho a problem je v jednoduchej uprave checkboxu (pripadne dalsich upravach veci, ktore nie su podla standardu – ale stale neviem, ktore to su, aj ked ich je, podla slov „bfu“, spusta a fakt by som o nich rad vedel) bude jednoduchsie tie upravy proste vykonat a pri dalsom projekte pouzit iny framework.

Tie upravy su otazkou minut, pricom diskusia a vymyslanie prikladov zabrala dokopy viac casu ako jedno zdedenie Checkboxu s upravou par metod.

laada wrote:

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.

Na ten som tiez zvedavy :-)

redhead
Člen | 1313
+
0
-

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..

nAS
Člen | 277
+
0
-

Tohle jsou všechno případy, kdy je potřeba vybrat několik možností ze seznamu. Na to tu máme již zmiňovaný CheckboxList.

Jan Tvrdík
Nette guru | 2595
+
0
-

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

laada
Člen | 35
+
0
-

Ha, tak spoustu prikladu za me napsal redhead. ;)

CheckboxList by se urcite v distribuci hodil nicmene zmena stavajiciho Checkbox mi pripada systemovejsi.

Patrik Votoček
Člen | 2221
+
0
-

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
Nette Core | 7790
+
0
-

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

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

bfu
Člen | 8
+
0
-

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.

_Martin_
Generous Backer | 679
+
0
-

redhead napsal(a):

… spousta příkladů =)

Já si myslím, že jde pouze o změnu uvažování programátora. Jde přeci o to, že identifikátor se z místa value="ID" přesouvá do name="delete[ID]".
Druhý způsob má tu výhodu, že je automaticky zaručena validita dat. U prvního způsobu jí musím donastavovat dodatečnými validačními pravidly. Opravdu tu nevidím technický problém, naopak, přijde mi to jako zjednodušení.

Edit: A druhý způsob – pokud mě znalosti neklamou – lze také „jen prohnat cyklem“.

P.S. Doufám, že mi nikdo nebude tvrdit, že název firmy je vyhovující identifikátor.

Editoval _Martin_ (11. 9. 2009 20:45)

David Grudl
Nette Core | 7790
+
0
-

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
Člen | 35
+
0
-

David Grudl napsal(a):
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.

Ale value prece v tomto pripade je pouze pomocna vec, ve sve podstate je to porad boolean, protoze nezaskrtnuty checkbox v POST vubec nepride a to Nette pozna ne. Takze proc tu moznost nedat tem co ji pouzijou.

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.

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

_Martin_
Generous Backer | 679
+
0
-

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
Člen | 35
+
0
-

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

_Martin_
Generous Backer | 679
+
0
-

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
Člen | 35
+
0
-

_Martin_ napsal(a):

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.

  1. v tom souboru mohou byt nezadouci duplicity
  2. kde vezmu tu hodnotu? Cislo radku me nezajima.
_Martin_
Generous Backer | 679
+
0
-

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.

laada
Člen | 35
+
0
-

_Martin_ napsal(a):

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.

Jasne tohle je klasicka snaha problem za kazdou cenu vyresit v, tomto pripade, omezenych intencich Nette. Ja vim jak by se to dalo vyresit na sto zpusobu, ale ja to chci elegantne vyresit bez zbytecnosti okolo.

zapis pole[hodnota] mi elegantne vyresi duplicity i predani hodnoty, kterou uz budu mit v Nette::Form. Mene elegantni by bylo pole[]=hodnota, ale furt lepsi nez stavajici obstrukce.

Ondřej Brejla
Člen | 746
+
0
-

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)

_Martin_
Generous Backer | 679
+
0
-

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“.

Asi tak (a zvláště pak ty duplicity).

laada napsal(a):

S tím nemohu souhlasit, ale v této diskuzi již nechci pokračovat, neboť nemám chuť někoho přesvědčovat o důvodech používání jednoznačných ID ani o tom, proč není dobrý nápad slepě spoléhat na data zaslaná klientem (jako třeba hodnotám v pole[hodnota]).

laada
Člen | 35
+
0
-

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
Nette Core | 7790
+
0
-

laada napsal(a):

Jasne tohle je klasicka snaha problem za kazdou cenu vyresit v, tomto pripade, omezenych intencich Nette.

Myslím že ne. Už proto, že „omezené intence“ je nesmysl (CheckboxList si přece můžeš stáhnout, nebo Checkbox upravit). Diskuse se točí kolem best practises, tedy jak to dělat nejlépe.

laada
Člen | 35
+
0
-

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? :)