🚀 go-pugleaf

Użytkownik "Paweł Filipiak" <pfilipiak@poczta.fm> napisał w wiadomoœci
news:a11226$q3f$1@news.tpi.pl...
> > bezposrednio HTML, mozna przeciez wygenerowac wywolanie funkcji JS z
> > dopowiednimi parametrami i pozwolic jej na budowanie po stronie klienta
> np.
> > sporych fragmentow skomplikowanych tabel wraz z zawartoscia. Taki kod
> wykona
> > kazda przegladarka potrafiaca interpretowac JS, w koncu podstawowa
funkcja
> w
> > nim uzyta to zwykle print(). Efektem ujemnym jest oczywiscie kod
> nieczytelny
> > dla przegladarek bez JS (chyba ze wylapiesz je po stronie serwera i
> > odpowiednio potraktujesz). Efektem dodatnim jest kod zajmujacy 20-30%
> > objetosci w stosunku do HTML-a w ktory rozwinie sie dopiero u klienta.
> > Jak wiec widac, nie tylko kontrola danych. Co do DHTML-a, to nie bede
sie
> > wypowiadal, bo nie jestem tu najbardziej kompetentny (pozdrowienia dla
>
> hmm, a czy to nie jest właśnie DHTML? Modyfikujesz stronę u klienta -
> obojętne, czy wykorzystujesz JS do zmiany liczby komórek w tabeli czy
> ogólnie do "wypluwania" HTML-a (funkcja print). Istnieje jeszcze jedna,
> ujemna niestety, strona takiego rozwiązania - jest ono wolniejsze niż
zwykły
> HTML. Objętościowo trzeba przesłać nie mniej danych niz przy zwykłym
HTML-u,
> a zazwyczaj nawet więcej, bo dochodzą skrypty, więc obciążenie sieci i
> serwera nie maleje. Dodatkowo jest narzut czasu na wyrenederowanie strony
u
> klienta, a to niestety trwa...
>
> Paweł Filipiak
> pfilipiak@poczta.fm
> icq 65223699; gg 1165099

Witam!

Mysle, ze jednak JS po stronie klienta zadziala szybciej niz sciaganie
dodatkowych xx% html z serwera, ktory bedzie na serwerze generowany
(dodatkowo go obciazajac). Ponadto jesli chodzi o objetosc, to stosowane
rozwiazanie jest takie, ze skrypty sciagasz tylko raz, np. do ukrytej ramki
i sprawa zalatwiona.

Pozdrawiam
ADi