Citat:
Problem je u sinhronosti operacije, ovo bi mozda i funkcionisalo u statefull sistemu, ali web to nije. Operacija je u potpunosti asinhrona i ne garantuje procesiranje zahteva za stampom i dobijanje feedback-a u vremenskom periodu alociranom za per-request PHP (ili asp.net) strane, niti postoji pouzdani mehanizam da se operacija stornira.
U praksi bi to znacilo ovako, podesimo max_execution_time = 30 i posaljemo zahtev preko browsera zahtev web serveru da odstampa fiskalni racun, medjutim u tom trenutku je opterecene web servera 100% i dok cekamo odgovor, tih 30 sekundi istekne, a fiskalna kasa je vec odstampala racun, sto i jeste veliki problem. Postoje jos i drugi moguci problemi, kao na primer napuni se hard disk i nemoguce je upisati fajl sa povratnom informacijom ili dodje do prekida mreznog kabla do servera, tj. svaki posrednik do kase uvecava verovatnocu outsynca sa kasom.
Za potpuno sigurnu transakciju je u svakom slucaju potrebna povratna potvrda od klijenta ka kasi da je racun ispravno upisan u bazu podataka i tek tada kasa treba da overi fiskalni racun, nesto kao two-phase commit. Inace ako se iz bilo kog razloga racun ne memorise u bazu podataka fiskalna kasa bi morala da uradi rollback prethodnog racuna :).
Zbog smanjenja mogucnosti greske, vise naginjem fat clijentu kada je u pitanju POS terminal, koji moze biti u obliku swing-a, .NET, gtk, tk, tekstualni ili bilo koji drugi.
Sto se tice backend baze, sadasanji RDBMS-ovi uglavnom zadovoljavaju ACID specifikaciju i zbog toga njima dajem prednost u odnosu na dbase/fajl/cobol baze.
Stampa je najmanji problem koji sam sreo kod web aplikacija. Dobro podesenim css-om uglavnom svi pregledi (sve sto se vidi na ekranu) mogu da se odstampaju direktno iz browsera, da se povecaju slova, smanje i da budu potpuno upotrebljivi kao izvestaj, dokument. Cesto sam vidjao da su nekada ljudi pokusali neki pregled da odstampaju print screenom. Vide ga, imaju unesenog, ali ne mogu nista vise da urade sa svojim podacima ako im to nije omoguceno programom.
Takodje web strane mogu i da se snime u html, a zatim otvore u excellu, gde uz malo ciscenja/formatiranja postaju korisni. Korisniku su za jedan korak blize njegovi podaci, sto je vrlo korisno. I sve sto vidi na ekranu moze da markira i pomocu copy prenese u tekst procesor ili drugu aplikaciju.
Do sada nisam imao problem ni sa forward/back dugmicima, cak su se pokazali i kao prednost.
Najveca prednost kod fat clijenta je bolja kontrola unosa, tj. unosa koriscenjem samo numericke tastarure.
Problem kod unosa web browserom se jos javlja na vise mesta:
- browser pamti history, pa tako po defaultu otvara combobox sa ponudjenim prethodnim unosima, sto moze da smeta gde je unesen veliki broj numerickih vrednosti. Za neke druge aplikacije je koristan, ali za cisto racunovodstvo ga treba iskljuciti.
- imao sam problem kada je ukljucen spell checking u firefoxu, pa su vrednosti u tekst boxovima podvucene crvenom linijom, sto smeta i prilikom stampe.
- potrebni su workaroundi za formatiranja unosa numerickih vrednosti
- problem kontrola submita da ne reaguje na pritisak enter-a
S druge strane korisnik moze da otvori vise pregleda odjednom ctrl-t, bez ikakvih ogranicenja i da brzo seta ctrl-pgup/down, ili otvori vise prozora odjedno, smanji/uveca slova uporedjuje podatke i slicno, u bookmarku sacuva sta mu je interesantno, ili koristi bookmark toolbar kao brze precice (sto vidim kao vrlo laku i za korisnika poznatu metodologiju customizacije menija), sto je vec sve dato po defaultu bez dodatnog programiranja.