Administrace komentářů

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