🚀 go-pugleaf

> obojętne, czy błąd został obsłuzony przez skrypt, czy przez wychwycony
> dopiero przez bazę (oczywiście w tym ostatnim przypadku nie najlepiej to
> świadczy o programiście...), istotny jest fakt, że zupełnie niepotrzebnie
> zostały zajęte zasoby serwera i sieci.

Nie zupelnie obojetnie. Jesli przesylasz dane pezposrednio do bazy,
zakladajac ze baza jest nieudolnie administrowana, mozesz zamiast danych
przeslac odpowiedni fragment zapytania SQL i przy odrobinie szczescia i
sporym doswiadczeniu sporo namieszac.

> 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).

Napisalem wyraznie - DHTML rozumiane jako manipulacja grafika, czyli
animacje itp. Wydaje mi sie, ze wiekszosc ludzi tak wlasnie odbiera DHTML.
Osobiscie oczywiscie zgadzam sie z Toba, to o czym pisze to jest szeroko
pojety DHTML.

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

Z mojego doswiadczenia wynika, ze przy umiejetnym zastosowaniu tej
technologii wielkosci wielkosc przesylanego pliku to ok. 30% jego
odpowiednika w czystym HTML-u. Co do czsu wykonania, to tez sie nie zgadzam.
Wykonuje sie niezwykle szybko.