Dotaz: Opravdu pěkná PHP knihovna pro HTML formuláře

[Josef Kufner]

Dobré ráno,

už mne nebaví být věčně nespokojený s ošklivými a pracnými formuláři. Všechno, co jsem zatím potkal, bylo o pohodlném a hloupém naskládání několika políček, jakmile je potřeba nějaká atypická věc, stojí to obludně moc práce. Navíc ty propracovanější nástroje jsou součástí velkých frameworků a tahají s sebou kopec bordelu navíc, o který nestojím a který překáží.

Také mi vadí, že při vytváření formuláře programátor nemá kontrolu nad rozmístěním jednotlivých prvků. Umístění jednoho políčka trochu jinak obvykle znamená napsat si celou šablonu formuláře, nebo aspoň velkou část. Na druhou stranu to ale nechci řešit vždy, takže výchozí layout by měl být bez práce.

Další potíž je s různými implementacemi MVC, na které jsou takové formuláře navázané, takže když to mám udělané trochu jinak, je potřeba formuláře všelijak přemlouvat, ohýbat a ani pak to moc nepasuje.

Co tedy sháním? Sám nevím. Něco, co jsem ještě neviděl. Něco, co se nepodobá formulářům v Nette či Zendu. Nejlépe malou specializovanou knihovnu, která se stará jen o formuláře a nevnucuje další návaznosti. A protože to chci používat v mnoha velmi různých projektech (uzavřených, otevřených i namíchaných), musí to být pod hodně svobodnou licencí, nejlépe MIT nebo BSD, ale rozhodně ne GPL. Na druhou stranu, pokud se nic nenajde a skončím u psaní vlastní knihovny, bude se hodit jakákoliv inspirace.

Nevíš o něčem elegantním a netradičním?

Díky.

Odpovědi

[Josef Kufner]

Hmm, asi mi nezbyde, než si napsat vlastní

Sice mám nějakou představu, jak by to mohlo vypadat, ale rád bych znal i přání ostatních, aby byla lepší šance, že výsledek bude použitelný i někým jiným. Lehce tedy přeformuluji svou otázku:

Co používáte za knihovny/frameworky na tvorbu webových formulářů (bez ohledu na programovací jazyk)? A co se vám na této knihovně líbí a co vám vadí?

[Jakub Lucký]

V Pythonu WTForms...

Líbí se mi, že ve Flasku se nemusím skoro o nic starat, prostě v presenteru udělám jen:

if form.validateOnSubmit():
    pass #něco udělat s daty

Nelíbí se mi na tom příliš ten zápis formulářů, ale dá se to

[Josef Kufner]

Díky.

Co se ti na jejich zápisu nelíbí, resp. v čem je to ošklivé? (Z příkladu, co mají na webu, to není moc vidět.)

[Jakub Lucký]

je to takové neintuitivní, psát ty validátory... Vypadá to prostě divně...

[Josef Kufner]

Aha, už to vidím. Nicméně myšlenka seznamu funkcí se mi líbí, jen to bude potřeba lépe podat.

[Kit]

Pro výstupy používám jeden ze způsobů:

• Heredoc v metodě __toString(). Výhodou je, že se to dá krásně zanořovat, do šablony lze přímo vkládat další objekty. Pokud je objektem řádek tabulky, vypisuji jen ten řádek. Seznam takových objektů vypisuji jako tabulku.
• XMLwriter - spíš experimentálně, nemusím se zatěžovat s htmlspecialchars() a párovostí tagů. Trochu zlobí vkládání externích javascriptů, ale i to se dá snadno obejít.
• XSLT - jedna výstupní šablona pro celý projekt - do DOMu nastrkám data a ta šablona si s tím poradí. Výhodou je, že tu šablonu mohu dát do databáze, kde ji mohu průběžně editovat bez rizika poškození výstupu aplikace - vadná šablona neprojde jednoduchou validací a neuloží se.

[Josef Kufner]

Heredoc v metodě __toString().

Díky za připomenutí. Většinou používám prosté echo, neboť je snažší formátovat kód s cykly a pomínkami, ale tohle občas bude lepší.

Jak definuješ, která políčka ve formuláři budou, jak se budou chovat (validace, výchozí hodnota,…), kde budou umístěna a podobně?

Nejde mi jen o samotné vykreslení, ale i o logiku definování formuláře a jeho zpracování (detekce odeslání formuláře, validace a postprocessing hodnot (např. převod data a času na timestamp). Tedy aby aplikační logika dostala hotová a očištěná data.

[Kit]

Místo cyklů raději používám implode(), podmínky tam většinou nepotřebuji žádné nebo skoro žádné. Funkce array_map(), array_filter() a array_reduce() v PHP fungují skvěle.

Každé políčko je objektem, formulář je kolekcí těchto objektů. Každý objekt si řeší své atributy a svou validaci. Objekt se umí i sám vypsat v HTML, kolekce se sama umí vypsat jako form. Alternativou je DOM v případech, kdy pro výstup použiji XSLT. Mezičlánek XML tedy nepoužívám. O umístění se postará CSS, to v objektech neřeším.

Validaci nechávám na modelu, případně až na databázi. Převod data a času si řeší model na vstupu. Tedy má aplikační logika často dostává surová a špinavá data a k nim jen informaci, co s nimi má udělat. Záleží na ní, zda je přijme, opraví či odmítne. Většinou to nechávám až na databázi, ta si poradí i se špinavými daty.

Časový údaj na vstupu nikdy nepovažuji za timestamp, protože není důvěryhodný. Timestamp přiděluje až databáze v okamžiku ukládání.

[Šangala]

Myslím, že píšeš minimálně o dvou, spíš o třech a věcech, jak to má vypadat a jak se s tím pracuje.

Jak to má vypadat budu tiše ignorovat, ale například to, jak se to konvertuje, jsem v minulosti úspěšně řešil přidáním vrstvy pomocí třídy „DatovýTyp“, s definičním označením

   * 'g' = int8
   * 'h' = int16
   * 'i' = int32
   * 'I' = int64
   * 'n' = float
   * 'N' = double
   * 'm' = money
   * 's' = string
   * 'S' = binary
   * 'd' = date     interně array (Y,m,d H,i,s,miliseconds)
   * 'D' = datetime interně array (Y,m,d H,i,s,miliseconds)
   * 't' = time     interně array (Y,m,d H,i,s,miliseconds)
   * 'T' = timestamp interně timestamp 
   * 'b' = blob data  undefined .. as it 
   * 'u' = error
   * '1'-'9' = string, výčet, ('0' - bool Yes/No)

A tento Variant reprezentoval hodnotu a uměl ji nastavit nebo vrátit ve třech formátech SQL, PHP, GUI dle konfigurace, lokalizačních informací či dle DBE a jejího nastavení. Typů bylo zbytečně moc, a datum by měl už být samozřejmě datetime, ale šlo to aplikovat na cokoliv. A ta písmenka se používala pro parametry předpřipraveného SQL dorazu.

Co se týká validace, tak jsem měl typy a ještě někdy mám checker-y(, ale už mě to moc nebaví, tak to moc nedělám :( ):

 
  const CHECKER_notnull   = 1000001; //0 parametru
  const CHECKER_id        = 1000002; //1 parametru
  const CHECKER_length    = 1000020; //2 parametru
  const CHECKER_number    = 1000030; //2 parametru
  const CHECKER_integer   = 1000040; //2 parametru
  const CHECKER_datetime  = 1000051; //0 parametru
  const CHECKER_date      = 1000052; //0 parametru
  const CHECKER_time      = 1000053; //0 parametru
  const CHECKER_regexp    = 1000060; //2[3] parametru, 3=true znamena ze prazdny retezec je OK
  const CHECKER_emaildomain=1000090; //
  const CHECKER_aplication= 1000099; //?

Které jsou definovány v DB a jsou navázány na konkrétní sloupec v DB a mají povinně implementaci v aplikační datové třídě, mohou mít a často mají implementaci v DB, buď na urovni SQL dotazu, nebo čistěji v trigger-u a mohou mít implementaci v JS.

V aplikaci každý DB objekt (tabulka) má svoji aplikační datovou třídu, který si získá meta informace z DB a spoustu konstantních vygenerovaných informací včetně patřičných SQL dotazů má u sebe. A pokud se přistupuje aplikačně přes tuto třídu, je vše ošetřeno a zajištěno, jednoduchý UPDATE či INSERT je nejtypičtější forma vkládání dat z formuláře, takže to pokryje 98% případů.

A pak zjednodušeně lze napsat:

$profile->setByArray($_POST['profile']);
$profile->Insert();

První metoda (aplikace app. checker-ú) může vyhodit výjimku s informací vrácenou patřičným checkerem nebo "ResultState" instanci, která ma dané informace (a může třeba být použita jak parametr při "PrintForm" k označení špatného vstupu).
Druhá metoda vlastní zápis do db.

No a co se týče vzhledu formuláře, tak díky tomu, že datové třídy umí získat i přímo vázané seznamy (pro combo-a) a díky infomacích "DatovýTyp" pro každý sloupec, tak lze velmi universální fcí (přijímající jako paramtr případně i instanci ResultState) vyflusnout celý form a to i pro více tabulek současně a pokud se jednotlivé „buňky“/„divy“ o id-čkují a o clasu-jí, tak je to už jen věcí css.

Ale měl jsem to opřené vždy o to, že celou DB včetně, app. datových tříd jsem měl vygenerovanou a overzovanou, a jakýkoliv zásah do strukturu, měl za následek nový regen, což někdy nebylo příjemné, protože automatika rozdílových SQL byla velmi slabá až žádná. Pro úpravy applikace to bylo ok - bez vlivu, samozřejmě kontrola formátu formuláře když přibyl sloupec, či doplnění nebo překlad name/title/help, ale zásah do DB modelu, pokud to nebylo jen prosté přidání tabulky, znamenalo vždy test migrace, a zabral trochu víc času než jen klik, nicméně jakékoliv změny validace či předpisu dané hodnoty bylo vždy jen v SQL a když jsem náhodu něco rozbil, tak se to hezky projevilo vyjímkou v patřičné oblasti a nemohlo dojít ke skrytým škodám. (Vedlejší pozitivní efekt byl, že meta informace o všech „objektech“ jsme měl ve stejné DB a nemusel jsem se opírat o (ne)možností daného DBE, a bylo možné ukládat přes trigery automatickou historii naprosto všeho bez jakékoliv práce (nebo s drobnou předpřípravou přes app. vrstvu) a bylo možné uložit „dokument“ k jakémukoliv objektu−>řádku rovněž bez práce, ale obojí bez integrity zajišťované přímo DBE přes FK).

[Josef Kufner]

'm' = money

Díky.

'u' = error

Co to?

'S' = binary * 'b' = blob data undefined .. as it

V čem je rozdíl?

Já si ještě přidám JSON, neboť se mi osvědčilo ukládat do databáze složitější struktury jako jeden JSON string. Tedy pokud je jeho obsah z pohledu databáze nezajímavý. Formulářové políčko pak je v browseru nahrazeno kusem Javascriptu, který se postará o GUI a naplní JSONem odpovídající skrytou textarea, podle toho, co uživatel nakreslí/nakliká.

Co se vazby na databázi týče, o tu se nechci u formulářů starat, ale na druhou stranu to budu krmit hromadou metadat z modelu, takže se bude generovat, co půjde.

Díky za připomenutí dynamických výčtů pro <select> – zatím jsem počítal jen se statickým výčtem ve stylu { "ano", "ne", "možná" }.

Řešil jsi nějak rozmisťování políček formuláře? Tedy v jakém pořadí a zda budou v tabulce, v jednom řádku, pod sebou, nebo nějak úplně obskurně rozházené?

[Šangala]

Žádné money jsem ti neposlal, ale rádo se stalo ;)

'u' = error - je to myšleno jako 'u' - undefined a byla to „volba“ pro případy, když se to používá nějak automatizovaná detekce typu, a zklame to tak, se tím označil stav instance, a každá operace s takovým typem vyhodila pak vyjímku, nevím, že bych to nějak cíleně použil (zkopnul jsem část komentáře se zdrojáku).

V čem je rozdíl? zásadní v tom, že 'S' je např. mysql varbinary takže se sním pracuje jako z řetězcem, ale binárním (žádné locale apod.) a 'b' je co se obsahu týče totéž, ale je to databázový typ (any)BLOB, a vkládání do DB a je ho čtení je řešeno speciálně, většinou zvlášť a z ohledem na limity nastavení PHP či contectoru do DB a umožňuje to zapsat do DB např. 100MiB, ale také jej přečíst a zapsat do souboru, či odeslat na výstup jako upload. (Ikdyž máš třeba jen 8MiB a velikost packet-u je nastavena jen na 4MiB). Řečí mysqli mysqli_stmt::send_long_data a čtení třeba z POST-files-u, vše ve smyčce a naopak při čtení z db, zas když to bylo nutné, tak pomalé čtení po 4MiB blocích ve smyčce, prostě tak, aby to fungovalo, i když server byl nastaven „nějak“.

zatím jsem počítal jen se statickým výčtem ve stylu { "ano", "ne", "možná" } - to jsem vždy pokryl tím (0)1-9. Ale zas na duhou stranu ve finálních věcech už byly i výčty s definovanou cestou (zas nevím jak, se tomu správně říká), tedy založeno může být jen objednáno, ale z objednáno třeba třeba zaplaceno, částečně zaplaceno či stornováno, takže se už tyto logiky neřešili, ty se vygenerovali do DB a tam sa pak už toto „workflow“ udržovalo či měnilo a na kód aplikace to nemělo vliv.

Řešil jsi nějak rozmisťování políček formuláře? většinou ne, já a design nejsme kamarádi, ale jak jsem naznačil už před tím, vysypala se buď tabulka nebo roj div-ů i o-id-ečkovaných (tedy za předpokladu existence jen jednoho formu) a o-class-ovaných a celé to zas v div-u a pak jsem se divil, jak kamarád to zhezčil přes css.

Tedy v jakém pořadí a zda budou v tabulce, v jednom řádku, pod sebou, nebo nějak úplně obskurně rozházené? jen částečně, pořadí sloupců v DB bylo to optimální a při automatickém vyspání editačního formu, se vysypal tak jak byl v DB, případně měl k sobě nějaké meta-informace (help), a přes slovník se přeložil jméno sloupce (takový ten skládaný překlad getName($lang,$modul,$tablename,$columnname"); pokud nebyl přesný překlad modul.tabulka.sloupec, a nebyl ani tabulka.sloupec tak dal překlad sloupec, pokud nebyl ani ten tak vrátil $columnname a založil do slovníku položku s flagem „přelož“, něco jako 'id' => 'Identifikátor' ale jen pro 'car.id' => 'VIN' ), dle localizace se do title (nebo jinam) vygeneroval dle nastavených checker-ů text definující předpis/limity, no a při generování se mohlo přiložit pole, které dělalo tyhle věci, specifická default hodnota/jen hidden a mimo jiné pořadí, ale moje zkušenost je taková, že to je naprd, že lepší si nechat vyjet ten form automaticky tak jak je v DB a pokud je to nutné, tak si jej pak ručně přeskládat či upravit a anomálie dělat minimálně. Jakákoliv automatika dojede na to, že pak zas potřebuješ tady maličko jinak, takže buď jednotné a sem s „ostřejší hranou“ nebo jednotně tupě vygenerovat a následně vyladit na 100 %, vždy máš možnsot daný form smáznou vygenerovat jej ostrohranný znovu. A na druhou stranu nevyšolíchané formuláře, ale naprosto jednotné i když třeba s dlouhými input-y pro zadání tří písmen (styl vše je obdélník s tabulkou name-value s jednotným řazením) jsou pro administraci spousty věcí to nejlepší co může být, jen se to někdy hůř prodává :( (OT: však i staré DOS aplikace/systémy alá foxpro či turbovision stále patří k nejrychleji ovladatelným…)

[Josef Kufner]

No mně jde právě o to, aby když potřebuju jen jedno obskurní políčko a poznámku k druhému políčku, abych se nemusel patlat i s těmi deseti dalšími.

U administrace si opravdu většina formulářů s automatikou vystačí, ale pokud lze trošku automatiku přiohnout, pokryje se tím mnohem víc případů, a ani to ohýbání nemusí být moc velké. Spíš jde o to, to udělat nějak šikovně, aby se dalo ohýbat a nahrazovat jen vybrané kousky a zbytek nechat na automatice.

[Šangala]

Jo tak na to právě sloužilo asociativní pole předávaní fci/metodě, fce normálne jela podle automatu a DB či jiných meta informací, ale pokud v asociativním poli našla klíč s názvem DB sloupce, tak si přečetla hodnotu klíče, což bylo zas asociativní pole voleb typu key-value a generační fce měla roj 'if' reagujíc na existující klíč, např.

Array(
'locale' => Array(addSstyle => 'width: 3em',
                     title => 'Jen velká písmena dle ISO XY.',
                     order => 2
                     )
     )

No a input pro locale měl jen 3em, uvedený title a zobrazil se jako druhý ve formuláři.
Prasárna s pořadím takto je, že se to musí dvoukolově (ne nutně cyklem, ale prostě se musí stanovit pořadí předem), ale zas se definují jen ty anomálie.