Administrace komentářů

Žá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…)