Nová verze formulářů pro 2.0

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
David Grudl
Nette Core | 7790
+
0
-

Chystám pustit do frameworku novou verzi formulářů. Dopředu musím upozornit, že jde asi o největší změnu za čtyřletou existenci Nette formulářů, takže zpětná kompatibilita nebude taková, na jakou jste zvyklí.

1) rozdělení prvků FormControl na „field“ a „control“

Současná podoba je pevně spojena s HTML a tedy existuje tolik formulářových prvků, kolik jich HTML definuje. Co před 4 lety mohlo být pragmatické rozhodnutí, je dnes už passé, HTML 5 zamíchalo kartama a věci se (konečně) mění. Do formulářů se nyní budou přidávat prvky IFormField, které ponesou pouze informaci o svém datovém typu. Datový typ je přitom komplexnější informace, může jím být třeba „nepovinný email“ nebo „výběr ze seznamu hodnot“.

Projekci do HTML bude zajišťovat až FieldRenderer. Zmíněný „výběr ze seznamu hodnot“ tak bude možno vykreslit v podobě HTML prvků select, radio nebo checkbox, případně zcela virtuálního prvku tvořeného JavaScriptem.

Z hlediska kompatibility to bude mít dopad na metody jako getControlPrototype(), setHtmlId() apod., které bude třeba volat jako getRenderer()->getControlPrototype() apod.

Nový přístup by měl zjednodušit tvorbu vlastních formulářových prvků a také být krokem k validaci na straně modelů.

2) validační pravidla

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.

Popis pravidel mi s odstupem času připadá zbytečně složitý a „programátorský“ – například taková definice validačního pravidla pro nepovinný email. Věc se zjednodušší v tom smyslu, že voláním metody setRequied() řeknu, zda je položka povinná či nikoliv, a pokud je nepovinná a nevyplněná, další pravidla se nebudou aplikovat. Podmínky typu „položka je povinná, pokud je zatržený určitý checkbox“ budou fungovat nadále, jen se budou řešit trošku jinak.

3) skupiny FormGroup

Skupiny se přesunou zcela na bedra vykreslovače (tj. ConventionalRenderer, nově DefaultFormRenderer) a měly by tak i zmizet problémy s odstraněním prvků a pod.

4) nové metody $form->add…

Pro často používané prvky se objeví nové továrničkové metody. Přidání políčka pro email včetně validačních pravidel se tak zkrátí na:

$form->addEmail('email')->setRequired(TRUE);

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

5) dynamické prvky

Implementace téhle věci čekala na PHP 5.3:

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

Myslím, že k tomu není potřeba víc dodávat. Dodám později ;-)

6) validační pravidlo Form::PATTERN

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

7) podpora HTML 5

Nyní se budou naplno využívat HTML 5 attributy jako required, min, max, chování prohlížeče však bude potlačeno atributem novalidate. 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.


Formuláře se objeví v GITu během víkendu (změna priorit, odloženo na neurčito) 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.

jtousek
Člen | 951
+
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)

David Grudl
Nette Core | 7790
+
0
-

„Obsahuje číslici“ se dá zapsat jako .*[0-9].* nebo (?=.*[0-9]).*. Ten druhý zápis má výhodu v tom, že se dá obdobně zapsat „obsahuje číslici, velké a malé písmeno“: (?=.*[0-9])(?=.*[a-z])(?=.*[A-Z]).* Což by ve variantě s REGEXP představovalo nachlup stejně dlouhý regulár.

PATTERN je postaven tak, aby byl kompatibilní s HTML5.

dakota
Člen | 148
+
0
-

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)

PJK
Člen | 70
+
0
-

Vyki napsal(a):

Super, super, super už se moc těším hlavně na ty dynamické prvky.

David Grudl napsal:
(ještě váhám nad jednou věcí: zda mít výchozí required na TRUE nebo FALSE).

Osobně bych byl pro TRUE. Když se mrknu do zdrojáků, tak v 80% případů je většina položek povinných. Bylo by fajn kdyby to šlo např nějakou statickou proměnnou nastavit. Každému může vyhovovat jiná varianta.

Souhlasím, defaultně by měli být všechny položky povinné

rokerkony
Člen | 122
+
0
-

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 …

bene
Člen | 82
+
0
-

Jestli to dobře chápu, tak můžeme čekat ->addInteger(), ->addFloat().

Pokud bude ještě možné nastavit výchozí vrácenou hodnotu, když nebude prvek vyplněn. Něco ve smyslu ->addInteger()->setRange(0, null)->setDefaultReturnedValue(null) a hodnota ve výstupu bude buď číslo typu int pro vyplněné nebo null pro nevyplněné políčko, tak to bude bomba.

sodae
Nette Evangelist | 250
+
0
-

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)

Cifro
Člen | 245
+
0
-

Dnes som akurat premyšľal, že kedy prídu tie väčšie commity s novinkami v 2.0 a prvý commit „už“ je tu :))

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

Podľa mňa už jednoznačne na false. Btw: issue/52

jansfabik
Člen | 193
+
0
-

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

Jsem zvědav. Ale připomínky přijdou až si s tím budu moci pohrát.

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

Výchozí HTML je logické, pokud používáme věci z HTML5.

jansfabik
Člen | 193
+
0
-

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

David Grudl
Nette Core | 7790
+
0
-

Jsem rád, že jste mi potvrdili ty výchozí nepovinné :-)

Ondřej Mirtes
Člen | 1536
+
0
-

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

phx
Člen | 651
+
0
-

Uz se tesim…

Urcite vychozi HTML a formulare NEpovinny!

O ostatnim az to testnu:)

Patrik Votoček
Člen | 2221
+
0
-

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.

pekelnik
Člen | 462
+
0
-

xhtml sucks :) políčka samozřejmě defaultně nepovinné :)

_Martin_
Generous Backer | 679
+
0
-

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.

Aurielle
Člen | 1281
+
0
-

Přijde mi poněkud blbé měnit zažitý princip a místo ->addRule(Form::FILLED, ...) začít psát něco ve smyslu ->removeRule(Form::FILLED). Tohle by bylo pro přechod velké WTF.

westrem
Člen | 398
+
0
-

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

jtousek
Člen | 951
+
0
-

@westrem: afaik HTML5 povoluje nepovinně párové tagy (jako neukončené <p>), narozdíl od XHTML. Jako programátorům nám asi všem z logiky věci více vyhovuje syntaxe XHTML, kde je vše ukončené ať už lomítkem na konci nebo párovým tagem. Proto jsem zde už zmínil myšlenku použít XHTML5, to používá syntaxi XHTML, ale také novinky z HTML5.

phx
Člen | 651
+
0
-

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.

Aurielle
Člen | 1281
+
0
-

V (X)HTML5 nijak uzavírání /> nevadí… nebo aspoň podle toho co jsem četl v několika článcích…

paranoiq
Člen | 392
+
0
-

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

V HTML5 je i lomítko na konci nepárového tagu OK (viz např.: http://dev.w3.org/…/syntax.html#…).

jtousek
Člen | 951
+
0
-

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?

Honza Marek
Člen | 1664
+
0
-

Já bych byl pro uzavírání pouze párových tagů (p, td, th, tr…). Uzavírání nepárových (br, hr, input, meta, …) se mi v HTML(5) moc nezdá.

Edit:

Teď jen zbývá zodpovědět otázku, kolik lidí toto podporuje pod pojmenováním XHTML5 a kolik pod HTML5 :)

Edit 2:

Konec konců mi to moc nezajímá. Klidně budu mít v botstrapu řádek Nette\Web\Html::$xhtml = false; i nadále.

_Martin_
Generous Backer | 679
+
0
-

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

Proki
Člen | 66
+
0
-

Já osobně zase raději uzavírám vše včetně nepárových tagů. Nicméně pokud zůstane ve třídě Html možnost nastavit si zdali generovat HTML nebo XHTML (a o jejím zrušení se tu myslím vůbec nepsalo), tak mi je jedno jaká bude výchozí hodnota.

Honza Marek
Člen | 1664
+
0
-

_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.
jtousek
Člen | 951
+
0
-

@Honza Marek: Ta ActiveEntity se Symfony validací vypadá ale zatraceně dobře!

Bylo by moc fajn kdyby podobné validace na bázi anotací Nette umělo také. :)

EDIT: Jak koukám tak Symfony ty svý anotační validace používá i u formulářů a vypadá to moc hezky. Osamostatnění validátorů v Nette a přidání API na bázi anotací by bylo super.

Editoval jtousek (23. 10. 2010 13:49)

David Grudl
Nette Core | 7790
+
0
-

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.

jtousek
Člen | 951
+
0
-

@DG: To co říkáš je sice pravda, ale pouze pro XHTML 1.0/1.1/2.0, nikoli pro XHTML5 (až na ty booleany).

Editoval jtousek (23. 10. 2010 16:13)

David Grudl
Nette Core | 7790
+
0
-

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)

jtousek
Člen | 951
+
0
-

Dobře, uznávám, že máš v tomhle pravdu. Souhlasím tedy s výchozím nastavením $xhtml na FALSE s možností vlastního nastavení na TRUE v bootstrapu.

Btw. ještě jedna věc. HTML5 nevyžaduje ve všech případech uvozovky kolem hodnot atributů, to by se též dalo využít.

Honza Marek
Člen | 1664
+
0
-

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

mancze
Člen | 58
+
0
-

Honza Marek napsal(a):

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

+1.

Nicméně často potřebuji vyrenderovat odlišně jen několik málo komponent. Byl bych rád, kdyby se podařilo vyřešit tak, abych se z šablony mohl odkázat na výchozí rendering.

// pseudo-Latte kód (ano, je to fuj, ale myslím, že je zřejmé, jak to myslím)
{render $form as $component}
	{if $component->getName() == 'myControl'}
		// custom rendering
	{else}
		{include #parent}
	{/if}
{/render}

Editoval mancze (23. 10. 2010 23:24)

arron
Člen | 464
+
0
-

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

arron
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…

Však já už něco takového taky používám. Akorát to není hezké – jen jsem si přebastlil metodu render na BaseFormu. Byl i nějaký pokus o napsání opravdického rendereru.

mancze napsal(a):

// pseudo-Latte kód (ano, je to fuj, ale myslím, že je zřejmé, jak to myslím)
{render $form as $component}
	{if $component->getName() == 'myControl'}
		// custom rendering
	{else}
		{include #parent}
	{/if}
{/render}

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.

mancze
Člen | 58
+
0
-

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

Patrik Votoček
Člen | 2221
+
0
-

pokud se nic nezměnilo tak https://doc.nette.org/…lates/macros#…

westrem
Člen | 398
+
0
-

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

David Grudl napsal:

Formuláře se objeví v GITu během víkendu a potom nastane doba testování.

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

Editoval o5 (4. 11. 2010 17:33)

Honza Marek
Člen | 1664
+
0
-

o5 napsal(a):

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

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

David Grudl
Nette Core | 7790
+
0
-

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.

jtousek
Člen | 951
+
0
-

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

crempa
Člen | 198
+
0
-

Jen poznamka nezavisleho pozorovatele

Neni lepsi dokumentovat neco hotoveho nez rozpracovaneho? Minimalne ve stavu kdy neni jiste nazvoslovi a struktura nekterych klicovych casti je pak zbytecne prepisovat hotovou dokumentaci. A dokumentovat to co uz je komplet hotove je zase zbytecne, protoze to stejne nejde poradne pouzivat, kdyz je zbytek rozkopanej (viz. aktualni stav snippetu, formularu etc.)

BTW: stejne tu dokumentaci musi napsat jeden clovek aby to melo cele stejny pristup k vykladu, popisu problemu apod. (o prekladu do jinych jazyku ani nemluve). Nechal bych komunitu placat doc10, dospal bych Nette 2 a pak behem par mesicu sepsal kompletni dokumentaci a tu vydal treba knizne (nizkonakladove nebo jen elektronicky) za nejakou tu kacku at z toho trapeni taky neco mas… :) tu pak uz pujde snadno prekladat a dal sirit. Spousta projektu to tak resi, takze na tom mozna neco bude.

westrem
Člen | 398
+
0
-

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

Matúš Matula
Člen | 248
+
0
-

+1 westrem

Vyki
Člen | 388
+
0
-

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