Názor k článku Internetové bankovnictví banky nenabízejí všem

> Prostě WEB byl původně určen ke zobrazování obrázků a textů, a to
> co po něm chceme nyní, tedy aplikace, které by se chovali stejně
> jako Windows, Linux, MAC, atd... aplikace, už není až tak
> jednoduchá záležitost, jak si myslíte a kdo tvrdí opak, tak s tím
> nemá zkušenosti nebo lže.
Mily pane, nevim, kdo jste, ale pusobi to na me dojmem, jako byste s nejakym podobnym bankovnictvim mel co do cineni (mimochodem, aplikace by se chovalY). Ale i kdyby ne, mozna by bylo prinosne uvedomit si nasledujici fakta:
1. Pro pasivni operace (prehledy plateb, inkas, trvalych prikazu apod.) neni na strane klienta nutna zadna (tim myslim opravdu zadna) logika. Pouze staci https spojeni se serverem a veskere informace generuje server. Nejsou potreba ani cookies, zkratka staci obycejny links. A pujdou i filtrovat dokumenty apod. Navic W3C standardy problematiku kodu resi k plne spokojenosti.

2. Pro aktivni operace (zakladani trvalych prikazu, platby apod.) je treba dany prikaz podepsat. To se da udelat bud Javou (ale nikoliv nejakym zmrudlym Microsoftim nekompatibilnim paskvilem) nebo podepsat externi aplikaci (GNUPG). Opet staci vicemene libovolny prohlizec. Diky Jave nam ze seznamu z predchoziho bodu vypadava Links. Zustava Mozilla, Navigator, Explorer, Opera, Konqueror apod. Je-li pro vetsi uzivatelske pohodli vhodne nekde pouzit JavaScript (typicky kontrola syntakticke spravnosti uctu pri provadeni platby apod.), staci, aby to bylo _volitelne_, nikoliv povinne a staci dodrzovat DOM model. Nic vic, nic min. Nastesti se nekompatibility IE projevuji predevsim v CCS a jinde, DOM je relativne pouzitelny.

3. To, ze nekteri lide se radi drbou pravou rukou za levym uchem, to je jejich problem. Pri navrhu webovych aplikaci by melo platit, ze vetsinu funkcni logiky by mel delat server, nikoliv klient. Nicmene toto nekomu unika a pak se stava treba to, ze v internetovem bankovnictvi u Zivnobanky se nacte stranka s formularem s nejakymi defaultnimi hodnotami a (ted se drzte) po nacteni formulare se tam Javascriptem nasypou jine defaultni hodnoty. Takze v realu to funguje tak, ze se zacina nacitat stranka, ja menim polozky formulare a jen co se stranka donacte, Javascript vsechno prepise na ten "druhy default". Co tim chteli soudruzi s NDR rici, to opravdu netusim. Proc tam ten "jediny pravy, tudiz druhy" default nenasypali rovnou v kodu stranky (input... value="hodnota"). Jediny dusledek podobne logiky je ten, ze jsou a) kladeny podstatne vyssi naroky na klienta a b) v pripade absence Javascriptu ma dotycny smulu.

3. Jako programator vim, ze je velmi snadne psat aplikaci stylem "je prece jasne, ze uzivatel ma system v C:\Windows" a natvrdo otevirat soubory pres fopen("c:\windows\soubor.neco"). A vetsine to taky fungovat bude. Jenze pak se najde nekdo, kdo si dovolil (!!!) nainstalovat system do nevychoziho adresare (a ma ho treba v D:\Win) a tam pak muj skvely program selze. Kdybych misto toho pouzil fci GetWindowsDirectory(), fungovalo by to vzdy a vsude bez ohledu na to, kde by ten uzivatel mel sve Windows nainstalovany. To je moje odpoved na argument "programovat pro vic prohlizecu je nakladne". Neni, chce to akorat zamestnat nekoho, kdo sve praci rozumi a ne toho, kdo bez naklikani aplikace ve Visual Studiu/Delphi neni schopen nic vytvorit.

Pokud mi chcete tvrdit, ze bankovnictvi je "někde na půl cesty mezi aplikaci typu "zobraz nějaký text a obrázky..." a aplikací", udejte prosim realne argumenty, proc musi byt funkcni logika prenesena ze serveru na klienta. Ostatne - pda.ebanka.cz je potom co?