Nové formuláře a dotazník

hanakus

Navrhuji do frameworku zařadit CheckboxList a nějakou základní Captchu.

jtousek

Ondřej Mirtes napsal(a):

Já ho nepochopil, ale vlastní komponenty mi fungují :o)

Tohle je „formulářový“ BaseControl, nikoli komponentový…

Honza Marek napsal(a):

Ten řádek ale vypadá pěkně. :-D Nestudoval jsem jej dopodrobna, protože to zatím nepotřebuju, ale refaktorizaci by rozhodně potřeboval. :-)

hanakus napsal(a):

Navrhuji do frameworku zařadit CheckboxList a nějakou základní Captchu.

To zní rozumně. Z důvodu kompatibility s danou verzí Nette. Jenže to už bych tam ze stejných důvodů chtěl přidat Date, DateTime, Time a možná ještě nějaké další. Sice by se mi to líbilo, ale nevím nevím jestli se do toho Davidovi bude chtít.

pozn. Symfony takhle funguje.

Editoval jtousek (17. 4. 2011 8:20)

gawan

asi už je to dávno rozhodnuté, ale nebolo by predsa len dobré oddeliť validáciu od formulárov? Veď dáta môžu prísť nielen z formuláru, ale aj cez XML alebo nejakú web service a potom treba robiť validáciu dvojmo, trojmo, … Keby existovala samostatná validačná trieda, ktorú by nezaujímalo, odkiaľ dáta prišli, akurát by sa nastavilo niečo ako $validation->setData($form->getValues()) alebo $validation->setData($xml->getValues()), to by bolo myslím univerzálnejšie…

Honza Marek

Taky bych sjednotil přístup k datům u formulářového kontejneru a políčka. Potom by šly krásně vyrábět vlastní políčka skládající se z více inputů.

namespace Blabla\Forms\Fields;

class Address extends \Nette\Forms\Container
{
    public function __construct(...)
    {
	// parent construct
        $this->addText('street');
        $this->addText('city');
    }

    // nebo getData?
    public function getValue()
    {
        return new \Blabla\Model\Address(parent::getValue());
    }
}

na1k

Honza Marek, nikdy jsem se o to nepokoušel, ale ono to teď nejde?

…

Jinak CheckBoxList ano (za předpokladu že by se nedal vyrobit nějak triviálně, například vlastním containerem), Captchu ale určitě ne – to už mi připadá jako vnucování. Existuje hromada implementací, hodně z nich i v doplňcích a nemyslím si, že je to prvek, který používají naprosto vždy naprosto všichni.

Jan Tvrdík

Teď už to myslím jde, ještě nedávno to ale šlo velmi špatně.

Martin

Vám se to nelíbí? Taková programátorská poezie …

str_replace(array('[]', ']'), '', 'a.b[c][d][]') ⇒ 'a.b[c[d'

explode('[', strtr('a.b[c[d', '.', '_')) ⇒ array('a_b', 'c', 'd')

Omlouvám se za formátování, nejde mi to zapsat jako kód včetně zvýraznění.

A taky za OT, ale třeba to někdo z dříve se vyjadřujících přepíše ještě krásněji.

K formulářům – myslím, že ve formulářích dosud není (mohu se mýlit, tolik Nette ještě neznám), přitom dost často se může hodit závislost skupiny checkboxů na jednom (typicky akce „zaškrtnout vše“). Je to samozřejmě javascriptová záležitost, ale podobné je „toggle“ a to tu (zatím) je. Mám to implementované (zapsané pak do továrničky jednořádkově nějak jako

$form->addCheckBox(...)->onCheckCopyValueTo(array($form['checkbox1'], $form['checkbox2'], ...))

), stejně jako jiné podobné věci (pravidla pro závislost jakéhokoli prvku na jiném, tedy nejen selectboxů, zapsané například jako

...->addSubmitOnChange()
...->addAjaxOnClick(prvek k ovlivnění a pravidla jak to udělat)
...->addAjaxOnChange(prvek k ovlivnění a pravidla jak to udělat)

, atp, atd.), ale po předvčerejším výprasku tady asi nějakou dobu svůj kód raději zveřejňovat nebudu :-) Ono to stejně porušuje jednu drobnost, kterou David zmiňoval na jedné z přednášek – z PHP to generuje poměrně dlouhé javascripty k jednotlivým controlům a snižuje to tak přehlednost pro kodéra. A ještě k tomu je toho skoro polovina závislá na jquery. Samozřejmě by to šlo iplementovat pro pozdní generování do samostatného souboru nebo alespoň na konec a bez jquery. Myslím, že našeptávače, závislé prvky a podobné vychytávky dnes už (bohužel) patří ke standardu a asi by na to měl framework reagovat nejen jednoúčelovými addony či obsáhlými návody na fóru nebo v dokumentaci. Samozřejmě důležité je nezaneřádit framework balastem, méně může znamenat více.

Editoval Martin (6. 5. 2011 13:52)

22

jsem jediný, komu ve validaci chybí:

->addRule(Form::DATE, 'Datum není ve formátu %d', 'dd.mm.yyyy')

Editoval 22 (6. 5. 2011 6:28)

Mikulas Dite

Datum je možné zapsat hodně způsoby, bylo by lepší buď použít regex, nebo mít speciální DATE pravidlo už s tím regexem a tedy bez parametru.

22

myslel jsem, že podle toho parametru, který popisuje formátování by se vygenroval spravný REGEX..tedy pořádí dne, měsíce, roku, formát čísla a oddělovník…

Ondřej Mirtes

Já jako validaci pro datum používám:

->addRule(function($control) {
	try {
		new DateTime($control->getValue());
		return TRUE;
	} catch (\Exception $e) {
		return FALSE;
	}
}, 'Datum v nesprávném tvaru.');

;)

jtousek

Ondřej Mirtes: lol, hezký :D

Validace data přímo ve frameworku by měla smysl pouze v případě, že by framework obsahoval i příslušný field, validátor range pro datum atd. atd. Kromě toho víc než kontrola pomocí regulárního výrazu (kterej se mění v závislosti na lokalizaci) je podstatná validace data jako takového pomocí funkce checkdate.

22

@jtatousek: to je argument, jakože framework má fields pro jiná validační pravidla? :-) Já myslím, že datum je celkem používáný formulářový vstup a mít to přímo ve frameworku mi přijde jako docela přirozený. A klidně bych se nebránil ani DATETIME, tedy včetně času.

jtousek

Když už tak přidej ještě TIME. :)

Martin

Nešlo by do Application:Run někam sem přidat $this->onPresenterCreated($this);? Pak by šly jednoduše přidávat formuláře například do panelů DebugBaru bez nutnosti dědit všechny presentery všech modulů od jednoho předka. Nikomu to zavolání neuškodí a (snad nejen) mně pomůže. Možná je to tady malinko OT, ale k formulářům to tak trochu patří. Nebo jim dát nějakou jinou možnost zpracovávat signály nezávisle na aktuálním presenteru (a pěkně mi vynadejte, jestli to tam dávno je a já zase něco přehlédl, tím nemyslím zpracování zcela mimo Nette).

Editoval Martin (12. 5. 2011 9:20)

Filip Procházka

Martin: založ si feature request, nebo lépe, použij Application::onStartup, na většinu těchto hacků to stačí

Martin

Bohužel tam ještě není vytvořený presenter. Ale už mlčím, tady se opravdu ptám na špatném místě.

Editoval Martin (11. 5. 2011 10:30)

jasir

Martin: Souhlasím, také to nyní obcházím. Založ FR nebo rovnou pull request, dám ti palec ;-)

David Grudl

Neřeší tohle právě PresenterFactory?

Martin

A sakra, že by? Hrabal jsem se v kódu dva dny, než jsem usoudil, že to nějak čistě nepůjde. Tohle jsem taky zkoušel, ale připadalo mi, že presenter potřebuje v tom místě už mít připravené některé parametry a musel by se opsat kus kódu Application. Až teď mi dochází, jak to vlastně je, ale možná jen proto, že jsem dnes cestou ve vlaku pečlivě studoval DI a další návrhové vzory (holt jsem studoval před 20 lety, při práci pro kapitalistu už nebyl čas a tak to doháním až teď).

Chápu to správně tak, že presenter si mohu vytvořit předem (i jen částečně inicializovaný), Application si pak pro něj sáhne do továrny místo vytváření (vždyť jsem na to předevčírem koukal ve zdrojáku) a dodělá, co bude potřeba? Zrovna jsem si ráno říkal, že něco takového bych si rád projel na nějakém příkladu a s tímhle jsem si to nespojil :-) Hned jak budu u počítače, vyzkouším to – předpokládám, že se to celé schová do předchozího callbacku. Nebo by se časem měly callbacky tohoto typu odbourat úplně?

Editoval Martin (13. 5. 2011 21:59)