On Fri, 29 Nov 2002 12:56:41 +0100, plusz <p...@i...usun_spam.pl> wrote:
> "Aleksander Mauszak" <e...@d...com> wrote in message
> news:slrnauee2p.os.e-max@amber.within.nat...
> [............]
>> Co prawda przedpiśca miał na myśli M$ Java vs. Sun Java, ale to się
> stosuje
>> również do całości bankowości elektronicznej. Na początku, kiedy powstały
>> trzy banki elektroniczne, okazało się, że na inteligo moja przeglądarka
> się
>> rozsypuje, na mBanku nie działa, a na VW z trudem ale działa.
>>
>> Który bank zwyciężył w konkursie o mnie jako klienta? =:-))))
> [............]
>
> mBank nie stosuje żadnych technologii (no może poza cookies), które mogłyby
> nie działać poprawnie
> więc to że nie działało to musiała być błędna konfiguracja przeglądarki
>

Jesteś pewien?

Obejrzyj kod źródłowy http://www.mbank.com.pl/ a tam takie kwiatki:
<script type="text/javascript" language="JavaSript">
rozmumiem, że to html ?? =:-)))))


Poza tym ciągle chciałbym wiedzieć *po co*.


max

do góry

On Sat, 30 Nov 2002 18:50:07 +0000 (UTC), Aleksander Mauszak
<e...@d...com> wrote:

>Obejrzyj kod źródłowy http://www.mbank.com.pl/ a tam takie kwiatki:
><script type="text/javascript" language="JavaSript">
>rozmumiem, że to html ?? =:-)))))
>
>
>Poza tym ciągle chciałbym wiedzieć *po co*.
>
Pewnie dlatego, ze czysty html nie ma wystarczajcyh mozliwosci dla
stworzenia wystarczajaco funkcjonalnych i wygodnych stron do
zarzadzania swoimi finansami..
Ale jedno to wykorzystywanie skrptow tam gdzie sa potrzebne a co
innego opieranie calego serwisu na apletach javy.

--
Wojtek Frabinski ICQ 50443653
w...@a...net.pl GG 212730
Moja strona Meat Loafa http://www.meatloaf.3a.pl/
Galeria kart bankowych http://www.karty.3a.pl/
Wiadomość ta przedstawia wyłącznie prywatne stanowisko autora.

do góry

Wojtek Frabinski <w...@a...net.pl> wrote:
> Pewnie dlatego, ze czysty html nie ma wystarczajcyh mozliwosci dla
> stworzenia wystarczajaco funkcjonalnych i wygodnych stron do
> zarzadzania swoimi finansami..

Raczej lamerzy nie potrafią zrobić w czystym HTML-u.

> Ale jedno to wykorzystywanie skrptow tam gdzie sa potrzebne a co
> innego opieranie calego serwisu na apletach javy.

Nie znam serwisu w którym skrypty czy java byłyby rzeczywiście
niezbędne.

--
___________ (R)
/_ _______ Adam 'Trzypion' Płaszczyca (+48 608) 093 026
___/ /_ ___ ul. Ludwiki 1 m. 74, 01-226 Warszawa
_______/ /_ IRC: _555, http://mike.oldfield.org.pl/
___________/ mail: _...@i...pl UIN: 4098313 GG: 3524356

do góry

Użytkownik "Adam Płaszczyca" <_...@i...pl> napisał w wiadomości
news:asfpu7$pod$1@news.onet.pl...
> Wojtek Frabinski <w...@a...net.pl> wrote:
> > Pewnie dlatego, ze czysty html nie ma wystarczajcyh mozliwosci dla
> > stworzenia wystarczajaco funkcjonalnych i wygodnych stron do
> > zarzadzania swoimi finansami..
>
> Raczej lamerzy nie potrafią zrobić w czystym HTML-u.
>
> > Ale jedno to wykorzystywanie skrptow tam gdzie sa potrzebne a co
> > innego opieranie calego serwisu na apletach javy.
>
> Nie znam serwisu w którym skrypty czy java byłyby rzeczywiście
> niezbędne.

Ale przydaje się np. do sprawdzania poprawności danych w formularzach
odciążając serwer i łącza.

Np: wprowadziłeś 213.12 zamiast 213,12, wysyłasz formularz, czekasz,
serwer w końcu odebrał, teraz przetwarza, czekasz, znalazł bład i zwraca,
czekasz, w końcu zwrócił. I dopiero np. po 2 minutach przekonujesz się
że popełniłeś błąd.
W przypadku skryptu jesteś natychmist poinformowany o błędzie bez łączenia
się z serwerem.

do góry

> > Pewnie dlatego, ze czysty html nie ma wystarczajcyh mozliwosci dla
> > stworzenia wystarczajaco funkcjonalnych i wygodnych stron do
> > zarzadzania swoimi finansami..
>
> Raczej lamerzy nie potrafią zrobić w czystym HTML-u.
>
> > Ale jedno to wykorzystywanie skrptow tam gdzie sa potrzebne a co
> > innego opieranie calego serwisu na apletach javy.
>
> Nie znam serwisu w którym skrypty czy java byłyby rzeczywiście
> niezbędne.

Skrypty po stronie klienta czasami są niezbędne:
- dodatkowe szyfrowanie przesyłanych danych
(wiadomo że szyfrowanie SSL można w niektórych przypadkach obejść,
ostatnio było o tym głośno zarówno jeśli chodzi i implementacje w Windows, jak i
OpenSSL)
- generowanie sumu kontrolnej, przesyłanych danych w celu ich weryfokacji
(protokół HTTP nie kontroluje poprawnosci przesyłanych danych, a drobna zmiana
na przykład w numerze konta docelowego, lub przesyłanej kwoty to spory problem)
- lokale podpisywanie transakcji
(z danego komputera może korzystać kilka osób, dlatego bezpieczniej jest
dodatkowo sprawdzić jego uprawnienia)

do góry