Vlákno názorů k článku Internetové bankovnictví banky nenabízejí všem od Petr Vejsada - To, co se tvrdí v úvodu článku, že...

To, co se tvrdí v úvodu článku, že je snazší napsat web pro jeden konkrétní prohlížeč než pro několik prohlížečů prostě není pravda. Touto lží ze zaštiťují pouze naprosto neschopní "tvůrci" webu, kteří neznají nic jiného než Visual Studio a prostě nejsou schopni napsat ani kousek kódu sami. HTML specifikace je daná a není nic snazšího, než napsat jednoduchou stránku, která se prostě zobrazí naprosto všude od Lynxu přes Links po Mozillu a MSIE. Naopak - je mnohem snazší napsat stránku tak, aby fungovala všude, než tak, aby fungovala jen v MSIE. Pokud se ovšem ta stránka bude opravdu psát, ne klikat v nějakém generátoru od M$.

No, z vlastni zkusenosti bych rekl, ze je problem napsat stranku (pokud chcete, aby to umelo i neco vic) tak, aby to fungovalo opravdu vsude. To, co zvladne treba Mozilla, nezvladne IE (vyjimecne i naopak) a co zvladne Mozilla a IE, nezvladne Opera atd. :-(

... a pak už standardně píšete jeden kód pro všechny hlavní prohlížeče a jen do stylů přidáte pár výjimek.

To co píšete plně platí pro WEB aplikace typu "zobraz nějaký text a obrázky, případně zobraz nějaký jednoduchý formulář pro zadání dat...".
Pokud se jedná o složitější aplikace, kde je potřeba i nějaká složitější funkčnost a logika, tak to už je o něčem jiném. Pak zjistíte, že část kódu sice napíšete, ale není to jedoduchá ani levná záležitost, a část kódu není vzhledem k určitým specifikám možné napsat vůbec. Pak hledáte složitě náhradní řešení, které už ale nezajistí přesně tu funkčnost, kterou potřebujete.
Vzhledem k tomu, že internetové bankovnictví je někde na půl cesty mezi aplikaci typu "zobraz nějaký text a obrázky..." a aplikací, kterou zde popisuji, tak se ani nedivím, že jdou banky tou cestou, kterou jdou.
Takže to co tvrdíte vy, většinou tvrdí lidé, kteří napsali nějakou tu "klasickou" WEB aplikaci, ale s psaním aplikací typu, které zde popisuji už tak moc zkušeností nemají.
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.

> 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?