Nová verze formulářů pro 2.0

David Grudl napsal(a):

(ještě váhám nad jednou věcí: zda mít výchozí required na TRUE nebo FALSE. Vždycky jsem předpokládal FALSE, ale zdá se mi, že ve formulářích převažují spíš ty povinné položky).

Osobně jsem pro výchozí FALSE.

$form->addDynamic('items', function($dynamic) {
	$dynamic->addText('name');
	$dynamic->addHidden('id');
});

Není mi úplně jasné, jak je tohle myšlené. Kdy se volá ta funkce, která přidává tyto dynamické prvky? Jaké případy to řeší?

Nahrazuje současné Form::REGEXP. Liší se vlastně v maličkosti: regulár uvedený v PATTERN platí vždy pro celý text, je case sensitive a zapisuje se bez delimiterů. Takže /[0-9]+/ pod REGEXP znamená „obsahuje číslici“, kdežto [0-9]+ pod PATTERN znamená „je tvořen jen číslicemi“.

Jak při použití Form::PATTERN zapíšu „obsahuje číslici“? Form::REGEXP zůstane zachováno nebo označeno jako deprecated / zrušeno?

Dá se to číst i jako konec podpory XHTML v Nette. Nakonec už samotné data- atributy jsou XHTML nevalidní. Velmi zvažuji změnu atributu Html::$xhtml na false.

Je to jen moje osobní preference, ale jsem pro takzvané XHTML5 (oficiální název to asi nemá).

Formuláře se objeví v GITu během víkendu a potom nastane doba testování. Hodila by se mi zpětná reflexe hlavně od autorů vlastních rozšiřujících prvků, protože je možné, že je bude potřeba kompletně přepsat.

Z pohledu autora rozšiřujících prvků mohu už teď prohlásit jednu věc. Implementoval jsem např. náhradu pro select, ale nad složitějšími daty (tabulkou). Potřeboval jsem k tomu jednak hledací inputek (který se ale neodesílal), dále tabulku, ze které automaticky mizely prvky, nevyhovující hledanému výrazu, potom skript, který toto chování zajišťoval (i když ten jsem tahal v hlavičce) a nakonec hidden inputek, do kterého se ukládala vybraná hodnota – tj. identifikátor řádku tabulky, který uživatel kliknutím vybral.

Co tím chci říct. Rozšiřující formulářové prvky mohou zpravidla potřebovat více částí než jen input a label. Ani je nelze automaticky dát k sobě, protože třeba ta tabulka je o řádek níže než hledací inputek. Řešil jsem to samozřejmě přes šablony, nevím přesně jak a jestli by se tohle mělo zohledňovat, jen uvádím příklad, co jsem potřeboval. Podobný hledací prvek už jsem vytvářel i nad stromovou strukturou (automatické rozbalování a zvýrazňování odpovídajícíh položek).

Editoval jtousek (22. 10. 2010 18:04)

Ak sa v súčasnosti mení generovanie formulárov v Nette, uvítal by som sa nejako doriešilo použitie suffix a requiredsuffix pri manuálnom renderovaní formulára, pretože v sučasnosti to ide dosť zložito aplikovať aby sa doplnil suffix a requiredsuffix do label pri manualnom renderovaní

https://forum.nette.org/…u-za-labelem?…

Chcel by som tiež poukázať na:

V netteForms som si všimol rozdielnu interpretáciu počtu znakov pri validácii (pravidlo Form::MAX_LENGTH) prvku textarea vo Firefoxe a ostatných prehliadačoch, Firefox pri validácii javascriptom počíta nový riadok ako jeden znak (\n) ostatné prehliadače za dva znaky (\r\n), v php je to tiež dva znaky – pri aplikácii pravidla Form::MAX_LENGTH to niekedy sposobí ze v javascripte v Firefox je formulár validný ale v php už nie

Možno pomože uprava metody length v netteForms podľa

v = el.value.replace(/\r/g,"").replace(/\n/g,"\r\n");
countChars = v.length;

pripadne ako je uvedené na stránke http://pikasoftware.com/…ing_TextArea

Editoval dakota (22. 10. 2010 16:51)

paráda
na addDynamic se těším jak malej kluk až si s tím budu moct pohrát, šup sem s tím :)
Html::$xhtml na false +1 …

Zajímavé. Hlavně bych už rád viděl „Dynamic“.

ještě váhám nad jednou věcí: zda mít výchozí required na TRUE nebo FALSE. Vždycky jsem předpokládal FALSE, > ale zdá se mi, že ve formulářích převažují spíš ty povinné položky

Ono nejde o praktiku ale o logiku, proto defaultně nechat setRequired na false

Velmi zvažuji změnu atributu Html::$xhtml na false.

Nette se posouvá směr html5 tedy vidím jasný směr: pryč s defaultním xhtml :-)

Editoval sodae (22. 10. 2010 20:27)

David Grudl napsal(a):
Silnou stránku Nette formulářů je validační jazyk, kterým lze definovat validační pravidla včetně libovolně zanořených podmínek. A ten víceméně zmizí ;-) Nebo lépe řečeno, bude skryt pod kapotou.

Dojde k vyčlenění validátorů do samostatné třídy? Chci je používat i v modelech a volání Nette\Forms\TextBase::validate metod se tam vůbec nehodí.

Honza Marek napsal(a):
Povinná políčka bych jako výchozí rozhodně nedával. Je to přesně ten krok, kdy framework začíná dělat něco neočekávaného navíc. Navíc pokud se to neosvědčí, což nelze vyloučit, bude se to z důvodu zpětné kompatibility těžko dávat pryč.

Taky s tím nesouhlasím. Sice by to ušetřilo trochu psaní, ale například pro začátečníky by to mohlo být matoucí.

To zas bude v alejich nablito :) Chvalim konecne postup, konecne se veci davaji do pohybu :) Za me +1.

S tou vychozi povinnosti vsech poli jste snad nemysleli vazne, to je typicka programatorska cunarna :) Myslete na uzivatele :)

Trochu se bojim tvorby vlastnich formularovych prvku, nekolik jsem jich v Mediu psal. Ve vsech potrebuji tu logiku, ze vice poli v HTML/POST requestu pak vyusti v jednu polozku ve $values poli. Typicky treba komponenta na psani textu, u ktere uzivatel radio buttonem vybira format (Texy/HTML). Ted jsem to delal pomoci prekryti loadHttpData, kde jsem si vytahnul tu hodnotu (vedel jsem nazev toho zprizneneho pole) a promitnul to nejak do toho, co vrati getValue(). A samozrejme potrebuji prekryti getControl. Snad to v pristi verzi vsechno pujde a pokud privetiveji, tim lip :)

Určitě nepovinný max function setRequired($required = TRUE); i když je to trochu WTF…

ostatní až při reálném osahání a styku.

Nebylo by lepší udělat jako výchozí políčka povinná? Resp. jsou následující důvody v něčem mylné?

1. nestane se mi, že zapomenu označit nějaký prvek za povinný (raději na chybu přijdu způsobem, kdy po mě formulář chce něco navíc, než když časem zjistím, že se něco neukládá)
2. většina políček bývá zpravidla povinná

Nechci se nijak hádat, spíš mě překvapuje většinová shoda pro nepovinná políčka a tak mě zajímají vaše názory.

__Martin__ napsal:

Tu to strasne pekne popisuje Honza, ktory to povedal presne ako si to myslim:

Povinná políčka bych jako výchozí rozhodně nedával. Je to přesně ten krok, kdy framework začíná dělat něco neočekávaného navíc. Navíc pokud se to neosvědčí, což nelze vyloučit, bude se to z důvodu zpětné kompatibility těžko dávat pryč.

Ano je pravda, ze velka cast (a niekedy aj vsetky) policka vo formularoch su povinne, ale aby to bolo default nie je uplne koser.

nestane se mi, že zapomenu označit nějaký prvek za povinný (raději na chybu přijdu způsobem, kdy po mě formulář chce něco navíc, než když časem zjistím, že se něco neukládá)

No to by sa ti ako programatorovi nemalo stat hadam nikdy, uz len z toho dovodu, ze verim, ze formulare testujes. Minimalne ja ich testujem viacfazovo (najskor si len dumpujem hodnoty, ktore dostavam, aby som videl ako formular reaguje na rozne vstupy, potom to pustam aj do modelu a zistujem ci ten robi s datami co ma, ale vzdy testujem aj okrajove pripady alebo uplne crazy pripady vstupov).

Ad: HTML a nie XHTML, mozno to bude uplne lame otazka, ale zavadza HTML5 nieco co je podla specifikacie vyslovene nekompatibilne s XHTML? (Specifikacie som az tak necital a o HTML5 som zatial cital len par clankov), dakujem za objasnenie.

Myslim si, ze uzavirat parove tagy v HTML je OK, ale lomitko na konci neparoveho tagu v HTML neni ok. Ale nejsem si jist.

Osobne se mi XHTML libi vic, ale HTML5 je krok spravnym smerem. Idealne XHTML5, ale to neni norma.

poznámka ad XHTML: XHTML5 nemá definované schéma, takže veškeré nové značky a atributy lze používat (nevalidují se)

vynechání koncových značek je jen optimalizace. i když nepoužívám XHTML dal bych přednost lepší čitelnosti výsledného kódu před optimalizací výkonu. jsem tedy pro výchozí nastavení xhtml = TRUE

Proki má pravdu. V tom případě nic nebrání používání XHTML syntaxe i nadále. Preferuje tady někdo HTML syntaxi před XHTML?

@gmvasek: Pro přepis by to mohlo být složitější, ovšem spíše z pohledu množství vykonané práce, nikoliv náročného přemýšlení.

@westrem: Asi je mi bližší přístup stylem „white-listů“ – čili postupně povoluji, co je nepovinné. Stejně jako u šablon se standardně escapují znaky (což by taky mohlo být chápáno jako neočekávané chování navíc, ale jeho praktické hledisko převyšuje nutnost znalosti frameworku). Proto mi ten přístup přišel správný. Zvláště, když se Nette snaží, aby jeho výchozí chování vždy vyhovovalo nejčastěji používaným případům.

Dokonce jsem si pohrával s myšlenkou zaměnit setRequired() za setOptional(). Je to opačný přístup, ale to nutně nemusí znamenat, že je špatný (Nette ostatně inovuje ve spoustě jiných „osvědčeně-zažitých-vždy-to-tak-bylo-a-proto-je-to-správně“ případech).

Edit:

Jestli specifikace HTML5 povoluje uzavírání nepárových znaků, nebylo by lepší jej využívat a umožnit tak snadné používání Nette i na webech, které v současnosti mají XHTML šablony?

Editoval _Martin_ (23. 10. 2010 11:21)

_Martin_ napsal(a):

Myslím, že ty tvoje úvahy vyplývají z dvou pomýlených předpokladů.

1. předpoklad 1: Je správné mít co nejvíce povinných atributů. Ano, to ocení programátor, ale uživatel ne. Ten se bude divit proč při registraci je povinné i rodné příjmení matky a číslo bot otce. Je jasné, že pokud budou výchozí povinné položky, tak líný programátor je nebude přenastavovat, pokud k tomu nenajde křišťálově jasný důvod.
2. předpoklad 2: Z formulářů musí vylézt zcela korektní data. Dle mého názoru je lepší vycházet z validace v modelech než z formulářové validace. Nette má sice zatím v tomto ohledu rezervy, ale dá se pomoct třeba se Symfony validací, kterou lze implementovat docela jednoduše.

ad XHTML: tady přece nejde o žádné vynechávání koncových značek, jestli je budete vynechávat se rozhodněte sami při psaní šablony. Rozdíl z pohledu třídy Html je tento:

<input value="10" checked="checked" /> // XHTML i HTML 5

<input value="10" checked> // jen HTML

Tedy v psaní / před koncem značky (mimochodem v tomto je XHTML nekompatibilní s HTML4) a v hloupém zápisu boolean atributů.

Jelikož v XHTML nelze použít nové atributy jako data- nebo required a framework tyto věci používá, tak nebude generovat XHTML validní kód. Tedy je zbytečné do kódu vkládat XHTML úlitby v podobě lomítek a hodnot logických atributů a rovnou může generovat HTML kód.

Dobře, tak ještě jinak: Nette framework nebude generovat kód kompatibilní s XHTML 1.0/1.1/2.0, což je to, co si pod pojmem XHTML představí drtivá většina lidí. Kód dokonce nebude ani kompatibilní s HTML 4. Bude tedy potřeba použít nový doctype <!DOCTYPE html> společný pro HTML5 i XHTML5.

V tomto okamžiku je otázka, když už se opouští podpora pro XHTML jak jej chápe většina lidí (tj < 5), zda se striktně držet XML serializace, tedy použití zpětných lomítek u těch několika elementů a rozvitého psaní boolean atributů, kteréžto se používaly jen kvůli dnes již mrtvému XHTML < 5.

(mimochodem, vypnutí a zapnutí Html::$xhtml vám odstraní/přidá lomítka i do výstupu šablon)

Taky bych uvítal, kdyby se přímo ve frameworku objevil nějaký TemplateRenderer pro formuláře.

Kdysi davno (uz to bude min. rok a kus) jsem neco takoveho napsal, ale nikdo o to tady neprojevil zajem…takze jsem na to od te doby nesahl. Cili kdyby byl zajem, sice by to urcite sneslo nejake ty upravy, ale v zasade je to hotove…

Editoval arron (23. 10. 2010 23:31)

Honza Marek napsal(a):

Já si radši napíšu všechno, aby se v tom i prase vyznalo. Lenost je pořešená – kostru si nechám vygenerovat. Taky mám názvy labelů v šabloně, takže vlastně tohleto tvoje řešení použít nemůžu.

Můžeš, prostě vypustíš else větev a všechno si vygeneruješ sám (nechceš použít default rendering).

David Grudl napsal:

Tak dakujem za objasnenie, nebolo mi jasne najme to s tymi data atributmi apod, takze davam hlas vypnutemu $xhtml na FALSE.

Ten template renderer nie je zla vec, tiez sa mi par krat stane, ze napr jeden fieldset potreubjem vykreslit uplne nestandardne a zvysok pekna tabulkova struktura :).

o5 napsal(a):

Mohl bych vedet kterej vikend si mel namysli? (ze jsem tak smelej) :)

+1 (jsem pro to, abych se taky zeptal)

@DG: Pevně doufám, že tě přesvědčí. Možná si i najdu čas abych nějaký kousky napsal sám, nebo třeba udělal korektury…

<OT>Davide, pls jak se teď mají přidávat do Latté vlastní makra když používají LatteMacros::fetchToken a formatArray, které nyní nejsou statické? Už je to nové API nějak vyřešené? Díky.</OT>

David Grudl napsal:
Ten, co byl, když jsem to psal. Ale pak se nějak přesunul fokus na Latte a nedošlo k tomu.

S vypuštěním uvidíme, jak dopadne zítřejší debata s Vrtakem nad stavem dokumentace. Pokud mě nepřesvědčí, zmrazím tak na měsíc až dva vývoj a půjdu ji psát.

Presne tohto som sa obaval, ze sa stane.

Co sa tyka dokumentacie. Plne chapem chalanov, ze je to v takomto stave, proste panuje „nepohoda“ v tom, co sa bude a nebude menit a potom sa ani nechce dokumentovat – vsak naco pisat o niecom, co sa mozno zmeni a teda cela robota vyjde nazmar.

Vsak kolko novych veci je public? Neon tak spolky (skor vobec), formulare vobec, Latte sa tiez meni neustale, Context rozpracovany, Ajax a snippety afaik tiez napoly rozpracovane (sice si na Webexpu ukazoval dost silnu fintu ako zajaxovat cely web pomocou jedneho znaku, ale to tiez nie je public zatial), to je z tych main veci asi vsetko, resp. na nic ine si nespominam.

Nechcem aby si to bral ako utok – osocovanie, to vobec nie. Kadzy FW sa raz za cas ocita v takejto faze, ked sa prechadza na vecsie zmeny (viac BC breakov) a vypusta sa nieco evolucne a preto podla mna komunite neostava nic ine, len cakat na releasy, pripadne pullovat drobne opravy bugov alebo feature requesty, ktore su lahke na implementaciu aby tak odbremenili teba a dopriali ti viac casu na core veci Nette.

Preto si myslim, ze zmrazit vyvoj a ist pisat dokumentaciu je to najhorsie mozne riesenie ake by mohlo teraz nastat. Staci ked si clovek prejde par prispevkov na fore, od ludi, co uz maju Nette otukane a kazdy viac menej spomina jedno – ze ostal zaseknuty na urcitom release, pretoze ten dalsi prinasa rozhaseny Ajax a rozpracovany Context. Zamrazenie vyvoja by teda tomuto nepomohlo. Kde je problem v tom, ze by sa pokracovalo normalne na vyvoji ako doteraz (kludne s prebiehacim charakterom, raz to, potom zase hento) ale dokumentacia by sa poriadne zacala pisat az ked by boli veci verejne pristupne a teda by dokumentaristi aj mali o com pisat. Vsak komunita za ten cas moze zacat pouzivat a testovat Nette 2.0 beta a dokumentaristi budu dokumentovat – neocakavaju sa uz totiz ziadne vecsie zmeny.

Pre novacikov to taktiez nemusi znamenat uplny problem. Vela veci podla mna bude fungovat aj podla navodov pre 0.9 verziu a najme je tu forum, kde sa budu moct spytat a ludia Nette znalejsi radi poradia, pretoze sa napr vyznaju v commitoch a vedia kde co treba a ako spravit.

A najme ak sa bude dokumentacia pisat k niecomu co je uz viac menej v ucelenej podobe na 100% bude lepsia ako keby sa mala pisat k niecomu rozpracovanemu.

Na zaver silne subjektivna veta:

Ovela viac sa uspokojim s vydanou Nette beta 2 bez dokumentacie, ktora ma bude nutit citat zdrojaky kazdu chvilu ako s dokumentaciou k niecomu, co este nie je dostupne

Myslím, že kdyby to bylo trochu lépe koncipované a organizované, našlo by se hodně lidí, kteří by s dokumentací pomohli. I já bych velmi rád přispěl, ale jak mám o něčem psát, když nevím jak to bude fungovat a jak moc se to změní. Nehledě na to, že i určité procento z těch nových commitů, nejsou konečným řešením daného problému. Také by se mi zdálo logičtější nejdříve něco uvolnit, lidi se s tím naučí pracovat, dikutují, zapracují se připomínky a pak to zdokumentují.