🚀 go-pugleaf

Użytkownik "Marcin Szczepaniak" <szczepan@pasztun.szczepan.pl> napisał w
wiadomości news:slrna2mdqj.dmr.szczepan@pasztun.szczepan.pl...

> Jedyne do czego to sie nadaje to do sprawdzania poprawnosci formularzy.
> Ew. do reklam. I do niczego wiecej.

A co powiesz na to, że moja firma napisała w JavaScripcie 3 duże aplikacje
webowe do obsługi szpitali? Że działają na przeglądarce bez instalowania
czegokolwiek na kompie klienta?

A, że pewne rzeczy w języku (np. obiektowość) są do dupy, to się zgadzam.

--
Pzdr.
Michał
--
"Errare chómanum est"

"Marcin Szczepaniak" <szczepan@pasztun.szczepan.pl> wrote in message
news:slrna2mdqj.dmr.szczepan@pasztun.szczepan.pl...
> I musze powiedziec ze ten caly java-script to badziewie.

"ciekawa" uwaga....

> Chcecie pisac w tym bog wie jakie programy, macie problemy z podstawowymi
> rzeczami...

hmm... kto?

> Ludzie !! to nie jest jezyk do takich rzeczy !

aha....

> Jedyne do czego to sie nadaje to do sprawdzania poprawnosci formularzy.

tez...

> Ew. do reklam. I do niczego wiecej.

cos mi sie widzi, iz nie znasz JS, nie znasz jego potencjalu,
wobec czego pierwsza uwaga nie jest ciekawa, jeno bezsensowna

BTW - po cholere w ogole sie odezwales?
tak tylko pytam, czysta ciekawoscia wiedziony...

v.

"Gupi Kaowiec" <gupi_kaowiec@o2.pl> wrote in message
news:a0fdb3$jgc$1@news.lublin.pl...

[...]

> moja firma napisała w JavaScripcie 3 duże aplikacje
> webowe do obsługi szpitali? Że działają na przeglądarce bez instalowania
> czegokolwiek na kompie klienta?

normalka, zreszta to zalezy od tego, co kto rozumie
jako "duza aplikacja" - bo jesli rozmiar, to mnie sie
zdarza pisac wylacznie "male" - bez wzgledu na to,
czy jest to sklepik, czy biblioteka wizualizacyjna
schematow decyzyjnych dosc powaznych firm ;)))

> A, że pewne rzeczy w języku (np. obiektowość) są do dupy, to się zgadzam.

a co konkretnie?
bo moze zamiast "do dupy" to macie (Ty i ECMA) odmienne
pojecie o obiektowosci ;)))

v.
PS. jedyna "ulomnosc" obiektowa, to sposob deklaracji i dziedziczenia klas,
ale powiedzmy, ze to sie robi po prostu nieco inaczej (ale sie robi).

> 
>> Jedyne do czego to sie nadaje to do sprawdzania poprawnosci formularzy.
>> Ew. do reklam. I do niczego wiecej.
> 
> A co powiesz na to, ¿e moja firma napisa³a w JavaScripcie 3 du¿e aplikacje
> webowe do obs³ugi szpitali? ¯e dzia³aj± na przegl±darce bez instalowania
> czegokolwiek na kompie klienta?

powiem, ze jest to wysoce zalezne od przegladarki.
a to IMHO bez sensu

> cos mi sie widzi, iz nie znasz JS, nie znasz jego potencjalu,
> wobec czego pierwsza uwaga nie jest ciekawa, jeno bezsensowna

fakt nie jestem ekspertem.
Ale uwazam (z doswiadczenia)  ze to techonologia wysoce zalezna 
od przegladarki. CGI nie.


> BTW - po cholere w ogole sie odezwales?
no tak - mam poglady rozne od ogolnie pojetych


> tak tylko pytam, czysta ciekawoscia wiedziony...
chcialem wywolac te dyskusje :)

> > A co powiesz na to, że moja firma napisała w JavaScripcie 3 duże
aplikacje
> > webowe do obsługi szpitali? Że działają na przeglądarce bez instalowania
> > czegokolwiek na kompie klienta?
> powiem, ze jest to wysoce zalezne od przegladarki.
> a to IMHO bez sensu
wiesz ja nie widzialem tej "duzej aplikacji" ale mozna wnioskowac ze
korzysta ona glownie z wbudowanych funkcji js i pewnie odslugi
formularzy a z tym chyba nie ma problemow z kompatybilnoscia w przegladarek

no chyba ze ta "aplikacja"to w rzeczywistosci jakac animacjaz wykorzystaniem
dhtmla w co watpie :)

Użytkownik Marcin Szczepaniak <szczepan@pasztun.szczepan.pl> w wiadomości do
grup dyskusyjnych napisał:slrna2mlbh.gt7.szczepan@pasztun.szczepan.pl...
> > cos mi sie widzi, iz nie znasz JS, nie znasz jego potencjalu,
> > wobec czego pierwsza uwaga nie jest ciekawa, jeno bezsensowna
>
> fakt nie jestem ekspertem.
> Ale uwazam (z doswiadczenia)  ze to techonologia wysoce zalezna
> od przegladarki. CGI nie.
0.co, zrobisz animacje za pomocą SAMEGO CGI :')
1.pozatym jesli to mozliwe to przy obliczeniach(lub sprawdzaniu formularzy)
zawsze lepiej wykonywac je klijent-sajd niz serwer obciązać - ale to moja
prywatna opinia :)

3.od przegladarki faktycznie nie, ale od serwera CGI jest zalezne.

> fakt nie jestem ekspertem.

Eufemizm chyba...

> Ale uwazam (z doswiadczenia)  ze to techonologia wysoce zalezna
> od przegladarki. CGI nie.

Masz racje. I co z tego?
Jesli nie blokuje mi to uzywania JS i daje mi ogromne mozliwosci to czemu
mam rezygnowac?
CGI kolego sluzy do zupelnie czego innego. I to tak jakbys powiedzial:
"LUDZIE! Po co uzywacie przegladarek? Aplikacje WORD sa duzo lepsze!"

> > tak tylko pytam, czysta ciekawoscia wiedziony...
> chcialem wywolac te dyskusje :)

Nie komentujemy i nie wdajemy sie w dyskusje przy tak zwanych Trollach -
postach bez konkretnego powodu napisanych jedynie po to aby wywolac
dyskusje, wzburzyc grupe i podbudowac niska samoocene autora.

Wszyscy wlacznie ze mna zlamali zasade.
Wybacz, ale zanim napisales zdanie "chcialem wywolac te dyskusje" mialem Cie
za osobe z ktora moza polemizowac... teraz jestem pewien ze jestes po prostu
glupi.

Witaj w moim KF

Gandalf

--
Alladyn Team (http://alladyn.art.pl) proud member
P.S. Swietnie, grupa powstala 3 dni temu a juz sie pojawili idioci "chcacy
wywolac dyskusje nad sensem istnienia"

"Marcin Szczepaniak" <szczepan@pasztun.szczepan.pl> wrote in message
news:slrna2mlbh.gt7.szczepan@pasztun.szczepan.pl...
> > cos mi sie widzi, iz nie znasz JS, nie znasz jego potencjalu,
> > wobec czego pierwsza uwaga nie jest ciekawa, jeno bezsensowna
>
> fakt nie jestem ekspertem.

wiec moze uznajmy, ze Twoje biadolenia naleza do kategorii
marudzenia widza, ktory niewiele z ogladanego filmu zrozumial,
nie zas do recenzji krytyka (w domysle "eksperta" ;)))

wiec moze darujmy je sobie....

> Ale uwazam (z doswiadczenia)  ze to techonologia wysoce zalezna
> od przegladarki. CGI nie.

1. Kiepskie masz doswiadczenia.
2. CGI jest zalezne od platformy serwera
3. operacje client-side:
a) oszczedzaja zasoby serwera (serwer jeden, clientow tysiace)
b) minimalizuja ruch na laczach

> > BTW - po cholere w ogole sie odezwales?
> no tak - mam poglady rozne od ogolnie pojetych

Ja tez nie slucham/nie lubie np. techno czy innego biadolenia,
daleki jestem jednak od wchodzenia do knajpy i komunikowania
improzowicza, ze ich muzyka mi nie pasuje.
Wybieram inne knajpy.

> > tak tylko pytam, czysta ciekawoscia wiedziony...
> chcialem wywolac te dyskusje :)

Chyba niepotrzebna i nie bedaca w stanie _pomoc_
w _niczym_ tym, co ta grupe czytaja...

proponuje EOT

v.

Użytkownik "Vax" <vax@ircx.pl> napisał w wiadomości
news:3c2b3e17$1@news.vogel.pl...
> > A, że pewne rzeczy w języku (np. obiektowość) są do dupy, to się
zgadzam.
>
> a co konkretnie?
> bo moze zamiast "do dupy" to macie (Ty i ECMA) odmienne
> pojecie o obiektowosci ;)))
>
> v.
> PS. jedyna "ulomnosc" obiektowa, to sposob deklaracji i dziedziczenia
klas,
> ale powiedzmy, ze to sie robi po prostu nieco inaczej (ale sie robi).

Polimorfizm?
Enkapsulacja? (zwana też hermetyzacją)
Mówisz o klasach? Bo ja widzę tu prototype-based object model, w odróżnienu
od class-based znanego np. z Javy.
To jest po prostu obiektowość inaczej.

A w odpowiedzi na uwagę o ECMA ciśnie mi się na usta: co ty k** wiesz o
obiektowości?  ;-)))
--
Pzdr.
Michał
--
"Errare chómanum est"

"Gupi Kaowiec" <gupi_kaowiec@o2.pl> wrote in message
news:a0hb37$m63$1@news.lublin.pl...
[...]

> Polimorfizm?
> Enkapsulacja? (zwana też hermetyzacją)
> Mówisz o klasach? Bo ja widzę tu prototype-based object model, w
odróżnienu
> od class-based znanego np. z Javy.
> To jest po prostu obiektowość inaczej.

Nie. To Ty sie naczytales o tworzeniu obiektow w JS
i po prosty _bardzo_duzo_ jeszcze nie wiesz.

> A w odpowiedzi na uwagę o ECMA ciśnie mi się na usta: co ty k** wiesz o
> obiektowości?  ;-)))

a co Ty k**** wiesz o ECMA, a co Ty wiesz o obiektowosci
w sensie obiektowosci, a nie obiektowosci przez pryzmat
jednego, dwoch(?) jezykow? ;)))
(dobra, bez takich, niemerytoryczne i nosi znamiona "przechwalek")

o obiektowosci...
podejrzewam, ze _nie_mniej_ niz Ty, zas wiedza o ECMA
i dosc glebokie rozpracowanie JS wykraczajace poza
roznorakie "biblie", "kompendia" i "manuale" pozwala
mi miec szersze na sprawe spojrzenie, nizli powielane
(czesto bardzo naiwne) stereotypy.

Ale zeby nie bylo goloslownie... podaj jakies zagadnienie
"obiektowe", wypisz zalozenia, a sprobujemy wykazac,
ze w JS da sie to (_elegancko_ i _obiektowo_) zrobic,
choc sposob w jaki zostanie to zrealizowane nie musi
byc "powszechnie" znany.

moze na priv (zeby nie smiecic), a na grupe wystosujemy
uzgodniony "raport"? ;))

v.

> moze na priv (zeby nie smiecic), a na grupe wystosujemy
> uzgodniony "raport"? ;))
>
> v.

nienie, nie na priv :) chyba ze wpiszecie mnie do cc ;]]

    MySZ

> U¿ytkownik Marcin Szczepaniak <szczepan@pasztun.szczepan.pl> w wiadomo¶ci do
> grup dyskusyjnych napisa³:slrna2mlbh.gt7.szczepan@pasztun.szczepan.pl...
>> > cos mi sie widzi, iz nie znasz JS, nie znasz jego potencjalu,
>> > wobec czego pierwsza uwaga nie jest ciekawa, jeno bezsensowna
>>
>> fakt nie jestem ekspertem.
>> Ale uwazam (z doswiadczenia)  ze to techonologia wysoce zalezna
>> od przegladarki. CGI nie.
> 0.co, zrobisz animacje za pomoc± SAMEGO CGI :')

animacja to pierdola malo istotna.
w CGI tez moge (gif). Tylko po co.

> 1.pozatym jesli to mozliwe to przy obliczeniach(lub sprawdzaniu formularzy)
> zawsze lepiej wykonywac je klijent-sajd niz serwer obci±zaæ - ale to moja
> prywatna opinia :)

zgadza sie - i tutaj widze glowne zastosowanie skryptow.
Ale widzialem juz przypadki, gdzie goscie zrzucali na przegladarke 
sprawdzanie poprawnosci formularza, a CGI juz nic w tym temacie 
nie robilo.... 

> 3.od przegladarki faktycznie nie, ale od serwera CGI jest zalezne.
Co jest zalezne od "serwera" CGI ?!?
CGI konfiguruje sie RAZ a potem juz nic sie z tym nie robi (tylko pisze
skrypty/programy). I kazda przegladarka to lyknie. KAZDA.
CGI to mechanizm a nie serwer.

>> Ale uwazam (z doswiadczenia)  ze to techonologia wysoce zalezna
>> od przegladarki. CGI nie.
> 
> Masz racje. I co z tego?
Co ? 
Efektem sa "super profesjonalne" strony w stylu eragsm.pl czy sklep.plusgsm.pl...
Sproboj je poogladac w przegladarce innej niz jedyna sluszna.


> Jesli nie blokuje mi to uzywania JS i daje mi ogromne mozliwosci to czemu
> mam rezygnowac?

Rezygnowac nie. Ale brac pod uwage, ze wtedy twoje strony nie beda poprawnie
wyswietlane we wszystkich przegladarkach

> CGI kolego sluzy do zupelnie czego innego. I to tak jakbys powiedzial:
> "LUDZIE! Po co uzywacie przegladarek? Aplikacje WORD sa duzo lepsze!"
?! Nie rozumiem...

> Wszyscy wlacznie ze mna zlamali zasade.
> Wybacz, ale zanim napisales zdanie "chcialem wywolac te dyskusje" mialem Cie
> za osobe z ktora moza polemizowac... teraz jestem pewien ze jestes po prostu
> glupi.
ty za to jestes bardzo madry. 

>> fakt nie jestem ekspertem.
> 
> wiec moze uznajmy, ze Twoje biadolenia naleza do kategorii
> marudzenia widza, ktory niewiele z ogladanego filmu zrozumial,
> nie zas do recenzji krytyka (w domysle "eksperta" ;)))

zapewne 95% czytelnikow tej grupy nie jest ekspertami.
Wlacznie ze mna w tym temacie. Ale napisalem o tym na poczatku.
Co nie znaczy wcale ze nie wiem o czym pisze. Nie znam szczegolow
i niuansow - ale efekty naduzywania JS widac WSZEDZIE.

> wiec moze darujmy je sobie....
zapewne tak sie stanie
 
> 1. Kiepskie masz doswiadczenia.
to nie tylko ja jestem glupi ? :)

> 2. CGI jest zalezne od platformy serwera
to strony/serwisy przenosi sie co tydzien na inny serwer ?
Ale na wszystkich UNIX'ach CGI dziala tak samo. Chyba ze mowisz o 
"profesjonalnych" platformach serwerowych rodem z MS.

> 3. operacje client-side:
> a) oszczedzaja zasoby serwera (serwer jeden, clientow tysiace)
nieprawda. Aby aplikacja byla poprawna i bezpieczna serwer MUSI 
zanalizowac kazdy wyslany do niego pakied danych (czy tam QUERY_STRING, 
jak zwal tak zwal). Niezaleznie od tego czy przegladarka (JS) sprawdzi 
ich poprawnosc. Ale taki skrypt sprawdzajacy poprawnosc ma jedna zalete:
zle dane NIE SA wysylane do serwera. 

> b) minimalizuja ruch na laczach
zgadza sie, przy uwzglednieniu teog co powyzej
 
> Ja tez nie slucham/nie lubie np. techno czy innego biadolenia,
> daleki jestem jednak od wchodzenia do knajpy i komunikowania
> improzowicza, ze ich muzyka mi nie pasuje.
> Wybieram inne knajpy.

dokladnie !
 
>> > tak tylko pytam, czysta ciekawoscia wiedziony...
>> chcialem wywolac te dyskusje :)
> 
> Chyba niepotrzebna i nie bedaca w stanie _pomoc_
> w _niczym_ tym, co ta grupe czytaja...
> 
> proponuje EOT

racja i tak do niczego nie dojdziemy

"Marcin Szczepaniak" <szczepan@pasztun.szczepan.pl> wrote in message
news:slrna2oi2s.fbi.szczepan@pasztun.szczepan.pl...
[...]
>
> animacja to pierdola malo istotna.
> w CGI tez moge (gif). Tylko po co.

on napisal "animacja" a nie migajacy obrazek...
jezeli tak rozumiesz animacje, to faktycznie
pierdoly to malo istotne...

[o formularzach]
> zgadza sie - i tutaj widze glowne zastosowanie skryptow.

oj, zaraz glowne...

> Ale widzialem juz przypadki, gdzie goscie zrzucali na przegladarke
> sprawdzanie poprawnosci formularza, a CGI juz nic w tym temacie
> nie robilo....

pretensje do server-side'owcow
jezyk temu nie winien.

> > 3.od przegladarki faktycznie nie, ale od serwera CGI jest zalezne.
> Co jest zalezne od "serwera" CGI ?!?
> CGI konfiguruje sie RAZ a potem juz nic sie z tym nie robi (tylko pisze
> skrypty/programy). I kazda przegladarka to lyknie. KAZDA.

Nie krzycz, piszemy, ze CGI pisane na jeden system _niekoniecznie_ (;)))
zadziala na innej platformie.

> CGI to mechanizm a nie serwer.

udanej migracji przy zmianie platformy zyczymy,
w koncu mechanizmowi powinno bys wszystko jedno...

v.
PS. server to:
a) konkretna maszyna?
b) konkretny system?
c) konkretna usluga/daemon w systemie?
d) kilka innych kontekstow tegoz sformulowania?

"Marcin Szczepaniak" <szczepan@pasztun.szczepan.pl> wrote in message
news:slrna2oiav.fbi.szczepan@pasztun.szczepan.pl...

[...]

> > Masz racje. I co z tego?
> Co ?
> Efektem sa "super profesjonalne" strony w stylu eragsm.pl czy
sklep.plusgsm.pl...

daruj sobie takie "argumenty"

czy ktos napisal, ze CGI jest do d..., bo powstaly tysiace
_spieprzonych_ guest-bookow, niedzialajacych licznikow
itp. itd.?

> Sproboj je poogladac w przegladarce innej niz jedyna sluszna.

j.w.
nieuk stosujacy technologie wystawia swiadectwo _sobie_
nie technologii.

> > Jesli nie blokuje mi to uzywania JS i daje mi ogromne mozliwosci to
czemu
> > mam rezygnowac?
>
> Rezygnowac nie. Ale brac pod uwage, ze wtedy twoje strony nie beda
poprawnie
> wyswietlane we wszystkich przegladarkach

skad to zalozenie?
i jeszcze jedno...
Docelowa grupa odbiorcow na poziomie 99.5% prawidlowo
wyswietlonej strony o funkcjonalnosci wielokrotnie wyzszej
niz czysty tekst mi odpowiada.
Karkolomny wyczyn majacy gwarantowac 100% zgodnosc
zmuszalby chocby do zarzucenia grafiki(!).
Dodatkowo, pewne kategorie serwisow maja wlasna grupe
docelowa, wiec prawdopodobienstwo napotkania browsera
"niekompatybilnego" jest praktycznie niemozliwe.

Aha... byl czas, gdy dyskutowano (i glosowano) celowosc
powstania tej grupy, jesli uwazasz, ze jest niepotrzebna
bo JS konczy sie na formularzach, a to juz zostalo setki
razy opisane, to ja sobie po prostu "wysubskrybuj".

v.

"Marcin Szczepaniak" <szczepan@pasztun.szczepan.pl> wrote in message
news:slrna2oiob.fbi.szczepan@pasztun.szczepan.pl...
> >> fakt nie jestem ekspertem.
> >
> > wiec moze uznajmy, ze Twoje biadolenia naleza do kategorii
> > marudzenia widza, ktory niewiele z ogladanego filmu zrozumial,
> > nie zas do recenzji krytyka (w domysle "eksperta" ;)))
>
> zapewne 95% czytelnikow tej grupy nie jest ekspertami.

...za to oczekuja, ze takich tu znajda, a znajduja...
marudzacego ignoranta, dla ktorego np. animacja oznacza wylacznie GIF.

> Wlacznie ze mna w tym temacie. Ale napisalem o tym na poczatku.
> Co nie znaczy wcale ze nie wiem o czym pisze. Nie znam szczegolow
> i niuansow - ale efekty naduzywania JS widac WSZEDZIE.

Poskarz sie mamusi, ludzie tu nie przychodza, zeby sie
od Ciebie dowiedziec, ze nie nalezy uzywac JS, bo ktos
inny naduzywa.
Przychodza, by sie dowiedziec _jak_ i _do_czego_ mozna go uzyc.

> > wiec moze darujmy je sobie....
> zapewne tak sie stanie

byle jeszcze w tym roku

> > 1. Kiepskie masz doswiadczenia.
> to nie tylko ja jestem glupi ? :)

grupa ta nie sluzy takze dowartosciowaniu/pocieszaniu,

> > 2. CGI jest zalezne od platformy serwera
> to strony/serwisy przenosi sie co tydzien na inny serwer ?

zapewne czesciej, niz przerabia sie strony, bo pojawila
sie nowa, _liczaca_ sie przegladarka, ktora nie realizuje
zalecen w3c, forsuje natomiast wlasny "jedynie sluszny"
model DOM, co wymaga przerobienia wszystkich stron.

CGI jest zalezne od platformy
JS jest obojetne, _gdzie_ strona z nim bedzie hostowana
JS jest w tym sensie "przenaszalny" i do wielokrotnego wykorzystania.
99% kompatybilnosci jest w _wiekszosci_ przypadkow do
zaakceptowania, zas uzycie JS zalezy wylacznie od autora serwisu
i jego oceny czy stosunek korzysci jakie uzyskal do owego 1%
hipotetycznie nieusatysfakcjonowanych jest wystarczajacy do jego uzycia.

> Ale na wszystkich UNIX'ach CGI dziala tak samo. Chyba ze mowisz o
> "profesjonalnych" platformach serwerowych rodem z MS.

Nie Ta Grupa. Masz wiele innych "unixowo-ortodoksyjnych".
Jak mniemam, w temacie MS jest rownie "dobrze zorienotwany"
jak w JS. Czyli powielasz stereotypy.

> > 3. operacje client-side:
> > a) oszczedzaja zasoby serwera (serwer jeden, clientow tysiace)
> nieprawda.

prawda

> Aby aplikacja byla poprawna i bezpieczna serwer MUSI
> zanalizowac kazdy wyslany do niego pakied danych (czy tam QUERY_STRING,
> jak zwal tak zwal).

Tak, tak. Po wyslaniu paczki danych uzytkownik chce sobie
zmienic sortowanie z nazwisk na daty.
Serwer _musi_ nad tym czuwac i _jeszcze_raz_ pobrac(!) z bazy wyslac(!)
wszystko(!) i to w postaci sformatowanego HTML.

Czlowieku... rece opadaja.

> Niezaleznie od tego czy przegladarka (JS) sprawdzi
> ich poprawnosc. Ale taki skrypt sprawdzajacy poprawnosc ma jedna zalete:
> zle dane NIE SA wysylane do serwera.

Masz nazbyt mala wyobraznie, by wymyslec zastosowanie rozne od validacji?
Rozklad danych na stronie, sortowanie, wyszukiwanie wsrod juz wybranych
wedlug precyzyjnieszego kryterium, tworzenie wykresow, wizualizacja
na wiele rozmaitych sposobow?

Serwer moze wyslac _czyste_dane_ i _sposob_ ich prezentacji.
Moze to zrobic XML moze to zrobic JS.
Ale serwer _nie_musi_, jak to sobie wyobrazasz, robic tego,
co znacznie szybciej moze zostac zrobone client-side.
Serwer wysyla informacje, zas naprawde troszczyc sie powinien
jedynie o to, co do niego trafia.

[...]

> > Ja tez nie slucham/nie lubie np. techno czy innego biadolenia,
> > daleki jestem jednak od wchodzenia do knajpy i komunikowania
> > improzowiczom, ze ich muzyka mi nie pasuje.
> > Wybieram inne knajpy.
>
> dokladnie !

no to fajnie, spojrz na szyld: "javascript"
wlasnie to sie tu gra, muzyczka nie odpowiada,
to dopijasz browar i zmieniasz lokal... ewentualnie
siedzisz dalej, ale nie trujesz (w tonie lekko pogardliwym)
obecnym zarowno o JS jak o wyzszosciach systemow operacyjnych.

Lubie Unixa, lubie Linuxa, nie cierpie zarozumialych szowinistow,
ktorym sie wydaje, ze "system uczynil ich lepszymi".
A w Twych wypowiedziach pobrzmiewa cos, czego nie lubie...
Chcialbym sie mylic.

> > proponuje EOT
>
> racja i tak do niczego nie dojdziemy

uf.
(a i tak chyba nie bylo mi z Toba "po drodze", wiec bez zalu ;))

v.

"Marcin Szczepaniak" <szczepan@pasztun.szczepan.pl> wrote in message
news:slrna2mdqj.dmr.szczepan@pasztun.szczepan.pl...
> I musze powiedziec ze ten caly java-script to badziewie.
> Chcecie pisac w tym bog wie jakie programy, macie problemy z podstawowymi
> rzeczami...
> Ludzie !! to nie jest jezyk do takich rzeczy !
> Jedyne do czego to sie nadaje to do sprawdzania poprawnosci formularzy.
> Ew. do reklam. I do niczego wiecej.


wlasciwie od tego powinnismy zaczac...

http://www.szczepan.pl/

ladne, czyzby Twoje?
proponuje obejrzec pod NS4.x, po co zaraz jakies tam "Winternet
Explodery"...

to nic, ze oskryptowanie wylacznie pod IE...
to nic, ze inaczej wyglada pod NS4 a inaczej po NS6 i IE...
to nic, ze w NS4 galerie nie wykazuja ochoty dzialania a tabelki sie
sypia...

to wszystko NIC

tylko KTO tu do ***** nedzy ma "problemy z podstawowymi rzeczami"?
ten sam, co chce nam mowic, do czego sluzy JS, ten, ktory gardzi
Windowsem, ale strony robi wlasnie pod niego, a konkretniej
pod wyszydzanego IE? (hmm... na czym on sprawdzal, co mu wyszlo,
w _czym_ to robil?).

Eh, Szczepan... dales dupy... jak cholera.

Milo bylo, ale Twoje "osiagniecia" w dziedzinie HTML/JS
oraz "ortodoksyjne" (a jakie konsekwentne, ze hoho)
poglady w temacie systemow operacyjnych sprawily,
ze cala nasza dyskusje uznac musze za niepotrzebna.
Z "kims" Cie przez chwile musialem pomylic, troche
zbyt pozno, ale juz sie polapalem, z kim mamy do czynienia
(choc trzeba Ci oddac sprawiedliwosc, _bardzo_wyrazne_
sygnaly wysylales, tylko ja nie chcialem Cie nazbyt pochopnie
oceniac - moja wina ;)))

v.
PS. Gandalf - miales racje ;)))

[ciach]
> > 1.pozatym jesli to mozliwe to przy obliczeniach(lub sprawdzaniu
formularzy)
> > zawsze lepiej wykonywac je klijent-sajd niz serwer obciązać - ale to
moja
> > prywatna opinia :)
>
> zgadza sie - i tutaj widze glowne zastosowanie skryptow.
> Ale widzialem juz przypadki, gdzie goscie zrzucali na przegladarke
> sprawdzanie poprawnosci formularza, a CGI juz nic w tym temacie
> nie robilo....
[ciach]

Witam...

Sprawdzanie poprawnosci danych wprowadzanych do formularza realizowana po
stronie klienta to najwieksze nieporozumienie o jakim slyszalem. Owszem,
mozna sprawdzac dane np. z poziomu JS, w wiekszosci przypadkow zmniejszy to
ruch generowany w sieci, niemniej bezpieczenstwo zapewniane przez tego typu
rozwiazanie jest przyzerowe. Ominiecie kontroli poprawnosci jest dziecinnie
proste. Jesli wiec projektant aplikacji rezygnuje z powtornego sprawdzenia
poprawnosci po stronie serwera, to jedynie zaswiadcza o doglebnej ignorancji
zasad bezpieczenstwa.
Nie zgadzam sie wiec z teza jakoby sprawdzanie poprawnosci danych to
podstawowe zadanie JS.

Pozdro...:)
TeNciN

Użytkownik "Marcin Szczepaniak" <szczepan@pasztun.szczepan.pl> napisał w
wiadomości news:slrna2mdqj.dmr.szczepan@pasztun.szczepan.pl...
> I musze powiedziec ze ten caly java-script to badziewie.

Skoro powstał i jest używany, to widać jest pomocny.

> Chcecie pisac w tym bog wie jakie programy

JS jest dobre do pewnych zadań, do innych nie - jak z każdym narzędziem.

> , macie problemy z podstawowymi
> rzeczami...

No cóż - wybacz mi.

> Ludzie !! to nie jest jezyk do takich rzeczy !

Tak jak pisałem wyżej: do "takich" nie, a do innych tak.

> Jedyne do czego to sie nadaje to do sprawdzania poprawnosci formularzy.
> Ew. do reklam. I do niczego wiecej.
>

Są fajne stronki, z ktorych lubię kotrzystać, a nie są ani reklamą, ani
prostą kontrolą formularza. Może nie są to "bog wie jakie programy"...

Np. http://www.trimen.pl/~mozga/procenty.html

Osobistych uwag pod Twoim adresem kierować nie będę.

Pozdrawiam Grupę

Jarek

"TeNciN" <tencin@acn.waw.pl> wrote in message
news:a0sbld$144$1@pingwin.acn.pl...

[...]
> Sprawdzanie poprawnosci danych wprowadzanych do formularza realizowana po
> stronie klienta to najwieksze nieporozumienie o jakim slyszalem. Owszem,
> mozna sprawdzac dane np. z poziomu JS, w wiekszosci przypadkow zmniejszy
to
> ruch generowany w sieci, niemniej bezpieczenstwo zapewniane przez tego
typu
> rozwiazanie jest przyzerowe. Ominiecie kontroli poprawnosci jest
dziecinnie
> proste. Jesli wiec projektant aplikacji rezygnuje z powtornego sprawdzenia
> poprawnosci po stronie serwera, to jedynie zaswiadcza o doglebnej
ignorancji
> zasad bezpieczenstwa.
> Nie zgadzam sie wiec z teza jakoby sprawdzanie poprawnosci danych to
> podstawowe zadanie JS.

Poprawność danych to niezupełnie to samo co bezpieczeństwo systemu. Jak w
formularzu jest obowiązkowe pole i user przypadkiem go nie wypełni, to chyba
lepiej jak wyleci alert z informacją, niż każdorazowo w takiej sytuacji
serwer miałby generowac na przykład błąd "cannot insert null into...",
nieprawdaż? Oczywiste, że obejście JavaScriptowych zabezpieczeń jest możliwe
i względnie proste, ale dlaczego ich nie stosować (oprócz poważniejszych
zabezpieczeń, oczywiście)? Sprawdzenie poprawności danych to dokładnie jedno
z podstawowych zadań JS, znacznie gorzej z DHTML-em, jeżeli strona ma być
czytelna pod różnymi przeglądarkami.
--
pozdrawiam
Paweł Filipiak
pfilipiak@poczta.fm
icq 65223699; gg 1165099

"Gupi Kaowiec" <gupi_kaowiec@o2.pl> skribis:

>A co powiesz na to, że moja firma napisała w JavaScripcie 3 duże aplikacje
>webowe do obsługi szpitali? Że działają na przeglądarce bez instalowania
>czegokolwiek na kompie klienta?

I ze nie zawsze dzialaja, i uzalezniaja dzialanie od przegladarki...

Pozdrawiam, Leh.
-- 
- I didn't know you can fly a plane ?
- Fly - yes. Land - no.  (Indiana Jones and the Last Crusade)
{ http://www.jones.prv.pl/ }   //    mail:leh#z.pl 

[ciach]
> Poprawność danych to niezupełnie to samo co bezpieczeństwo systemu. Jak w
> formularzu jest obowiązkowe pole i user przypadkiem go nie wypełni, to
chyba
> lepiej jak wyleci alert z informacją, niż każdorazowo w takiej sytuacji
> serwer miałby generowac na przykład błąd "cannot insert null into...",
> nieprawdaż? Oczywiste, że obejście JavaScriptowych zabezpieczeń jest
możliwe
> i względnie proste, ale dlaczego ich nie stosować (oprócz poważniejszych
> zabezpieczeń, oczywiście)? Sprawdzenie poprawności danych to dokładnie
jedno
> z podstawowych zadań JS, znacznie gorzej z DHTML-em, jeżeli strona ma być
> czytelna pod różnymi przeglądarkami.

Witam...

Przeczytaj jeszcze raz to co napisalem ja i moj przedmowca. On pisal
wyraznie o sprawdzaniu danych z poziomu JS jako jedynym zastosowanym
zabezpieczeniu i z tym sie wlasnie nie zgadzam. Ja natomiast pisalem o
dublowaniu kontroli poprawnosci danych celem unikniecia nadmiarowego ruchu w
sieci i jednoczesnie spelnieniu wymogow bezpieczenstwa.
Piszesz, ze poprawnosc danych to nie to samo co bezpieczenstwo serwera.
Niestety nie zawsze jest tak wesolo. Jesli w przytoczonym przez Ciebie
przykladzie komunikatu bledu - "cannot insert null into..." - masz na mysli
komunikat generowany przez skrypt ktory sam przechwycil taki blad i
odpowiednio go obsluzyl, to wszytko jest OK. Jesli natomiast komunikat jest
wynikiem bledu zwroconego przez baze danych, to mozna przypuszczac, ze
projektant aplikacji wysyla do bazy dane bez sprawdzenia ich zawartosci, a
to juz smierdzi naruszeniem zasad bezpieczenstwa.
Zgadzam sie, ze kontrola poprawnosci danych to wazne zastosowanie JS,
niemniej jest jeszcze kilka innych ciekawych zastosowan nie koniecznie
dotyczacych DHTML-a (rozumianego jako manipulacja grafika).
Osobiscie JS bardzo mi sie przydal przy pisaniu wysoce modularnych stron z
czesto powielanymi partiami kodu. Zamiast generowac po stronie serwera
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
Alladynorobcow :) ).

Pozdro...:)
TeNciN

witam ponownie :)

> Przeczytaj jeszcze raz to co napisalem ja i moj przedmowca. On pisal
> wyraznie o sprawdzaniu danych z poziomu JS jako jedynym zastosowanym
> zabezpieczeniu i z tym sie wlasnie nie zgadzam.

no chyba niezupełnie... napisał bowiem
<cytat>
zgadza sie - i tutaj [tutaj czyli w sprawdzaniu poprawnosci danych jeszcze
przed submitem formularza- pf]
widze glowne zastosowanie skryptow.
Ale widzialem juz przypadki, gdzie goscie zrzucali na przegladarke
sprawdzanie poprawnosci formularza, a CGI juz nic w tym temacie
nie robilo....
</cytat>

jak widzisz zaznaczył wyraźnie, że sama kontrola danych po stronie klienta
to za mało

> Niestety nie zawsze jest tak wesolo. Jesli w przytoczonym przez Ciebie
> przykladzie komunikatu bledu - "cannot insert null into..." - masz na
mysli
> komunikat generowany przez skrypt ktory sam przechwycil taki blad i
> odpowiednio go obsluzyl, to wszytko jest OK. Jesli natomiast komunikat
jest
> wynikiem bledu zwroconego przez baze danych, to mozna przypuszczac, ze
> projektant aplikacji wysyla do bazy dane bez sprawdzenia ich zawartosci, a
> to juz smierdzi naruszeniem zasad bezpieczenstwa.

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.

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

--
pozdrawiam
Paweł Filipiak
pfilipiak@poczta.fm
icq 65223699; gg 1165099

Użytkownik "l.eh" <leh.NIELUBIESPAMU@z.pl> napisał

> I ze nie zawsze dzialaja, i uzalezniaja dzialanie od przegladarki...

Widziałeś je? Może jesteś jednym z naszych klientów? Jeżeli masz z nimi
problemy, zadzwoń do nas. Ktoś Ci na pewno pomoże.

--
Pzdr.
Michał

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

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.

jeżeli zachodzi potrzeba wielokrotnego wyświetlenia dokładnie tego samego
kodu html (na przykład w kilku ramkach), to rzeczywiście masz rację -
szybsze będzie jednorazowe sciągnięcie skryptu, a następnie wielkorotne
odrysowanie tego samego kodu html w wielu miejscach u klienta (pomijając
oczywiście sytuacje krańcowe, kiedy sieć i serwer są szybkie, a klient
pracuje na jakiejś archaicznej stacji...). Pytanie tylko, jak często
zachodzi taka sytuacja (wielokrotnie powtarzający się kod html w wielu
ramkach na tej samej stronie).

--
pozdrawiam
Paweł Filipiak
pfilipiak@poczta.fm
icq 65223699; gg 1165099

Użytkownik "Paweł Filipiak" <pfilipiak@poczta.fm> napisał w wiadomoœci
news:a117sa$3tr$1@news.tpi.pl...
> 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.
>
> jeżeli zachodzi potrzeba wielokrotnego wyświetlenia dokładnie tego samego
> kodu html (na przykład w kilku ramkach), to rzeczywiście masz rację -
> szybsze będzie jednorazowe sciągnięcie skryptu, a następnie wielkorotne
> odrysowanie tego samego kodu html w wielu miejscach u klienta (pomijając
> oczywiście sytuacje krańcowe, kiedy sieć i serwer są szybkie, a klient
> pracuje na jakiejś archaicznej stacji...). Pytanie tylko, jak często
> zachodzi taka sytuacja (wielokrotnie powtarzający się kod html w wielu
> ramkach na tej samej stronie).

Chodzilo mi raczej o ramke wielkosci 0px, chociaz nn4.x na to leje i zrobi
ramke okolo 5px - ale jak sie dobierze odpowiednio kolor tla to nie widac.
Mozna w takiej ramce przechowywac zmienne itp. do ktorych bedzie latwiejszy
dostep niz np. przez ciacha. Przykladem moze byc strona ktora zrobilem:
www.zebyd.com.pl. Tam musialem zrobic dokladnie wszystko w js, bo klient
uparl sie ze strona bedzie u niego i ze nie zainstaluje zadnego php. Mysle,
ze dziala to calkiem niezle, nawet na nn6 (choc mozna znalezc pare bledow).

Faktem jest ze lynx pewnie niewiele pokaze, a opery nawet nie testowalem -
to sa te minusy.

Pozdrawiam
ADi

> Przykladem moze byc strona ktora zrobilem:
> www.zebyd.com.pl. Tam musialem zrobic dokladnie wszystko w js,

Gdzie tam procz sladowych ilosci jest JS?????????????

Gandalf

--
Alladyn Team (http://alladyn.art.pl) proud member

> I ze nie zawsze dzialaja, i uzalezniaja dzialanie od przegladarki...

Staryyyyyyyyyyyyyyyyyyyyyyy... Mam cynk!!!!
Wiesz ze systemy operacyjne uzalezniaja swoje dzialanie od
procesora,wielkosci ramu,typu karty graficznej,plyty glownej i od formatu
dysku????

To moze.... moze by ich nie uzywac wiecej, co???

Gandalf

--
Alladyn Team (http://alladyn.art.pl) proud member

"Gupi Kaowiec" <gupi_kaowiec@o2.pl> skribis:

>Użytkownik "l.eh" <leh.NIELUBIESPAMU@z.pl> napisał
>
>> I ze nie zawsze dzialaja, i uzalezniaja dzialanie od przegladarki...
>
>Widziałeś je? Może jesteś jednym z naszych klientów? 

Nie widzialem :) Ale skoro to aplikacje webowe w javascripcie, to sa chyba
client-side ?
Choc oczywiscie moge sie mylic.



Pozdrawiam, Leh.
-- 
- I didn't know you can fly a plane ?
- Fly - yes. Land - no.  (Indiana Jones and the Last Crusade)
{ http://www.jones.prv.pl/ }   //    mail:leh#z.pl 

"Zbigniew Braniecki" <gandalf@alladyn.art.pl> skribis:

>> I ze nie zawsze dzialaja, i uzalezniaja dzialanie od przegladarki...
>
>Staryyyyyyyyyyyyyyyyyyyyyyy... Mam cynk!!!!
>Wiesz ze systemy operacyjne uzalezniaja swoje dzialanie od
>procesora,wielkosci ramu,typu karty graficznej,plyty glownej i od formatu
>dysku????

Mowimy o aplikacjach a nie systemach operacyjnych.


Pozdrawiam, Leh.
-- 
- I didn't know you can fly a plane ?
- Fly - yes. Land - no.  (Indiana Jones and the Last Crusade)
{ http://www.jones.prv.pl/ }   //    mail:leh#z.pl 

> Mowimy o aplikacjach a nie systemach operacyjnych.

A jakaz to roznica?????????

Ale ok. Browser rowniez tak ma...
Internet Explorer zupelnie inaczej renderuje np. Opacity w Windows a inaczej
na Macach (powodem jest biblioteka DX)
Opera na kazdej platformie zachowuje sie zupelnie, ale to zupelnie
inaczej... czy to znaczy ze mam z niej zrezygnowac?

Przyklady mozna mnozyc...
Jak ktos nie umie stworzyc strony dzialajacej wszedzie to niech wpisze sobie
w onloadzie alert dla innych browserow i ush.

pozdr.
Gandalf

--
Alladyn Team (http://alladyn.art.pl) proud member

"Zbigniew Braniecki" <gandalf@alladyn.art.pl> skribis:


>Przyklady mozna mnozyc...
>Jak ktos nie umie stworzyc strony dzialajacej wszedzie to niech wpisze sobie
>w onloadzie alert dla innych browserow i ush.

Ale uzywajac JAVASCRIPTU jako waznego elementu nie da sie stworzyc strony
dzialajacej w kazdej przegladarce. Chyba ze tekt " Przepraszamy, ale nie
masz javascriptu" uznac za dzialanie :)


Pozdrawiam, Leh.
-- 
- I didn't know you can fly a plane ?
- Fly - yes. Land - no.  (Indiana Jones and the Last Crusade)
{ http://www.jones.prv.pl/ }   //    mail:leh#z.pl 

> Ale uzywajac JAVASCRIPTU jako waznego elementu nie da sie stworzyc strony
> dzialajacej w kazdej przegladarce. Chyba ze tekt " Przepraszamy, ale nie
> masz javascriptu" uznac za dzialanie :)

A na macach nie ma przezroczystosci w IE i co z tego????

Podasz mi przegladarke ktorej uzywalnosc w polsce jest wyzsza niz 1% w
ktorej nie mozna zastosowac JavaScriptu (hint -> http://alladyn.art.pl)
Alladyn nie obsluguje Opery, to fakt, ale jestem w stanie wykonac prawien
wszystkie metody Alladyna dla Opery

pozdr.
Gandalf

Użytkownik "Zbigniew Braniecki" <gandalf@alladyn.art.pl> napisał w
wiadomości news:3c34b4a1$1@news.vogel.pl...
> > Przykladem moze byc strona ktora zrobilem:
> > www.zebyd.com.pl. Tam musialem zrobic dokladnie wszystko w js,
>
> Gdzie tam procz sladowych ilosci jest JS?????????????
>
> Gandalf

Przed Toba wypada mi sie wytlumaczyc :)
Nie chodzilo mi o to, ze ta strona, to jest 100% js i do tego zastosowalem
takie sztuczki o jakich nikt nie slyszal i ze wogole to jestem guru. Mialem
na mysli to, ze pewne problemy na tej stronie rozwiazalbym po stronie
serwera w php, ale zostalem zmuszony do tego, zeby stosowac tylko js. I
chcialem pokazac przyklad, ze mozna zrobic _cos_ w js, co bedzie dzialalo
dobrze na najpopularniejszych przegladarkach, troche odciazy serwer i
jeszcze wykorzysta ramke zerowej wielkosci (bo o to chodzilo w poprzednich
postach).

Z wyrazami szacunku
ADi

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

> Pytanie tylko, jak często
> zachodzi taka sytuacja (wielokrotnie powtarzający się kod html w wielu
> ramkach na tej samej stronie).

Witam...

Czesciej niz nyslisz i to nie w oddzielnych ramkach, tylko w jednej. Np.
typowp portalowe strony o modulowej budowie, odzwierciedlajace scisle
okreslona strukture danych wypluwanych z bazy.

Pozdro...:)
TeNciN

> Faktem jest ze lynx pewnie niewiele pokaze, a opery nawet nie testowalem -
> to sa te minusy.

Witam...

Lynksa (jak i inne przegladarki nie obslugujace JS) mozesz wychwycic po
stronie serwera i wyslac mu strone czysto HTML-wa.

Pozdro...:)
TeNciN

"Vax" <vax@ircx.pl> skribis:

>Karkolomny wyczyn majacy gwarantowac 100% zgodnosc
>zmuszalby chocby do zarzucenia grafiki(!).

I bardzo dobrze - po co komu tyle grafiki - nie wiem skad ten wykrzyknik
:))


Pozdrawiam, Leh.
-- 
- I didn't know you can fly a plane ?
- Fly - yes. Land - no.  (Indiana Jones and the Last Crusade)
{ http://www.jones.prv.pl/ }   //    mail:leh#z.pl