Java Script (11)


Spis Treści


Od redakcji

Niniejsza książka to gotowy zestaw receptur - podobnie jak książka kucharska. O ”wirtualnym ko­szyku na zakupy” można myśleć jako o ”ciasteczkach cebulowych z pastą łososiową”. W każdym rozdziale podano kod i dokumentację przydatnej aplikacji zwykle napisanej całkowicie w Java­Scripcie. Można wszystkie dania przygotowywać tak, jak to podał autor książki, ale można też sięgnąć do pewnych sugestii, aby wykorzystać je w swoich pomysłach. Na rynku znajdują się ksią­żki zawierające proste przepisy, jak zrobić jakieś drobiazgi i jak ozdobić JavaScriptem swoją stro­nę sieciową, natomiast w tej książce znajdziemy całe aplikacje sieciowe napisane w jedynym języku skryptowym, rozumianym przez przeglądarki.

Skoro tyle już sobie wyjaśniliśmy, zastanówmy się, co należy rozumieć przez książkę z receptura­mi? Jej zadaniem nie jest na pewno podawanie treści w mało elastycznej formie, ale pomoc w two­rzeniu kodu. Zapewne takie pozycje książkowe, zawierające receptury, będzie można spotkać co­raz częściej.

Richard Koman, Redaktor


Wstęp

Czegoś dotychczas brakowało. Zgłębiałem stosy książek o JavaScripcie, oglądałem kolejne witry­ny sieciowe wprost ociekające kodem i pomysłami. Jednak kiedy już poznałem wszelakie nowe ro­dzaje składni i genialne techniki, nie wiedziałem, co z tą wiedzą mogę zrobić poza pokazywaniem przykładów. Czułem się tak, jakbym był w kuchni pełnej wszelakich składników jadła, ale bez żad­nego przepisu. Znałem rozmaite sztuczki języka JavaScriptu i miałem różne kawałki kodu, ale nie potrafiłem tego zastosować do rozwiązania typowych problemów na stronach sieciowych. Oczywi­ście niektóre książki zawierały aplikacje JavaScript, ale nie były one odpowiednie do stosowania w Sieci. Oczko to świetna gra, arkusz kalkulacyjny to ciekawa aplikacja, ale trudno je zamieszczać na swoich stronach sieciowych.

W tej książce znajduje się szereg przepisów. Nie tylko można się dowiedzieć, jak sprawdzić używaną przeglądarkę czy umożliwić przewijanie obrazków, ale można również znaleźć tu kompletne apli­kacje, których będziesz mógł używać na swoich stronach. Aplikacje te nie będą tworzone krok po kroku, od razu zostaną zaprezentowane w całości. Można je kopiować do katalogu serwera siecio­wego (lub komputera lokalnego) i natychmiast uruchamiać. Rozdziały tej książki naszpikowane są kodem JavaScript, który ma pomóc użytkownikom w realizowaniu typowych zadań, takich jak przeszukiwanie witryny, sporządzenie spisów treści, umożliwienie przewijania obrazków, ogląda­nie prezentacji, robienie zakupów i wiele innych. Oczywiście można te przykłady modyfikować tak, aby najlepiej pasowały do naszych potrzeb, ale i tak są one mniej więcej gotowe do użycia. Oprócz tego do każdej aplikacji dołączono dokładne objaśnienie jej działania, więc można sobie spraw­dzać, jak zadziała zmiana poszczególnych fragmentów kodu.

Co powinieneś wiedzieć

Nie jest to książka dla początkujących, gdyż nikt nie będzie tu nikogo uczył JavaScriptu, ale będzie można się dowiedzieć się, jak go używać. Nie trzeba być wiarusem JavaScriptu z trzyletnim sta­żem, jeśli jednak info.replace(/</g, "&lt;"), new Image() czy var itemArray = [] są dla kogoś niejasne, to najlepiej mieć pod ręką opis składni tego języka.

Użycie czcionek

Kursywa

używana jest do podawania nazw plików, ścieżek katalogów, adresów URL.

Pismo o stałej szerokości czcionki

używana do przedstawiania znaczników HTML, fragmentów kodu, funkcji, nazw obiektów i innych odwołań do kodu.

Kursywa o stałej szerokości czcionki

stosowana jest do tekstu wprowadzanego przez użytkownika i tekstu podmienianego.

Pismo o stałej szerokości czcionki, pogrubione

zastosowano do tekstu wyświetlanego na ekranie.

Układ książki

Większość rozdziałów ma podobny, czteroczęściowy układ.

Wymagania programu

Ta krótka część określa środowisko wymagane do uruchomienia aplikacji. Zwykle podawana jest potrzebna wersja przeglądarek Netscape Navigator i Microsoft Internet Explorer. Tutaj także na­kreśla się tło, omawiając zagadnienia związane ze skalowaniem i monitorowanie wydajności.

Struktura programu

Kiedy już czytelnikowi znudzi się zabawa z aplikacją i będzie chciał zobaczyć, „co tam siedzi w środku”, powinien przeczytać tę część. Tutaj znajdzie omówienie kodu, zwykle wiersz po wier­szu. Jest to część najdłuższa, więc warto usiąść sobie wygodnie, zanim zacznie się ją studiować.

Techniki języka JavaScript

Kiedy będziemy przebijać się przez składnię, pojawią się miejsca, gdzie warto będzie zatrzymać się na chwilę i wskazać techniki, które można dodać do arsenału swoich środków.

Kierunki rozwoju

W tej części sugerowane są metody dalszego rozwijania aplikacji. Czasami są to sugestie, a cza­sem gotowy kod. Zdarza się, że nie potrafię się powstrzymać i piszę za czytelnika kod znajdujący się w archiwum, które można załadować z Sieci. Tak czy inaczej, warto poczuć powiew twórczej weny, a nie ograniczać się tylko do upartego zapytywania: „Niezłe, jak to wprowadzić na moją stronę?”.

O kodzie

Cała ta książka mówi o aplikacjach. Nie powinno być zatem zaskoczeniem, że znajduje się tutaj mnóstwo kodu. Niektóre aplikacje mają kilkaset wierszy, większość z nich to kolejne strony kodu. W niektórych wypadkach kod jest nawet powtarzany, aby czytelnik nie musiał co chwilę przerzu­cać kartek między kodem programu a jego omówieniem.

Jedną z wad umieszczania kodu w książce jest... no cóż, właśnie umieszczenie go w książce. Czę­sto strona jest zbyt wąska, aby umieścić w jednym wierszu tyle, ile by się chciało. Fragment kodu często kontynuowany jest w następnym wierszu, i jeszcze w następnym... Aby zwiększyć czytelność, pomi­nięto komentarze, choć znajdziemy je w plikach. Osoby odpowiedzialne za skład nieźle się napra­cowały, aby sformatować kod w miarę czytelnie, ale i tak czasem wygodniej może być czytać tenże kod w edytorze.

Jako że kod powinien być używany, a nie tylko czytany, wszystkie aplikacje dostępne są w pliku ZIP, który można załadować ze strony sieciowej wydawnictwa O'Reilly. Warto udać się pod adres http://www.oreilly.com/catalog/jscook/index.html i odnaleźć łącze Download. W każdym rozdziale będziemy odwoływać się do tego pliku.

Programowanie i testowanie

Poniżej - bez jakiejkolwiek szczególnej kolejności - podałem sprzęt i programy używane podczas tworzenia kodu prezentowanego w tej książce. W większości przypadków wszystko testowano w środowisku Windows, ale w środowiskach Unix i Mac także nie powinno być zbyt wielu proble­mów, a może nie będzie ich w ogóle.

Sprzęt: IBM ThinkPad 55/P75/16M, Compaq Presario/P233/100M, IBM Aptiva C23/P120/128M, DELL OptiPlex/P2-266/128M, Sun SPARC 20.

Systemy operacyjne: Win95, WinNT Workstation 4.0, WinNT Server 4.0, Solaris 2.5.

Przeglądarki: Netscape Navigator 3.0, 3.04 Gold, 4.0, 4.04, 4.07, 4.08, 4.5; Microsoft Internet Explorer 3.0, 3.02, 4.0, 4.01, 5.00.

Rozdzielczości: 640x480, 800x600, 1024x768, 1152x900, 1280x1024.

Oczywiście nie wszystkie aplikacje były testowane we wszystkich kombinacjach, jednak starałem się kodować jak najbardziej ostrożnie, aby w większości możliwych środowisk wszystko działało poprawnie.

Podziękowania

Moje nazwisko znajduje się na okładce, mam więc obowiązek i przyjemność podziękować w tym miejscu wszyst­kim, którzy przyczynili się do powstania tej książki.

Kwestie techniczne pomogli mi rozstrzygnąć: Steve Quint, James Chan, Jim Esten, Bill Anderson, Roland Chow, Rodney Myers, Matthew Mastracci, Giorgio Braga, Brock Beauchamp i inni - dlatego im właśnie chciałbym podziękować, zwłaszcza za wspomaganie mnie swoją znajomością JavaScriptu, a także innych zagadnień programowania. Specjalne podziękowania kieruję w stronę Patricka Clarka, którego kod był inspiracją aplikacji obsługi pomocy. Dziękuję redaktorowi Richardowi Komanowi, który był otwarty na moje pomysły i umożliwił przelanie ich na papier, a także Tarze McGoldrick i Robowi Romano za ich pracę ważną, choć niewidoczną.

Serdeczne słowa podziękowania składam mojej żonie, Róndine Bradenbaugh, za to, że wytrzymała ze mną, kiedy przez miesiące wpatrywałem się w monitor i szaleńczo stukałem w klawiaturę, noc w noc. Chciałbym podziękować wreszcie moim rodzicom za ich wsparcie i zachęcanie mnie do roz­wijania umiejętności pisarskich.

Chciałbym też podziękować komuś, o kim często się zapomina - czytelnikom. To właśnie czytelnicy zostawiają w księgarni ciężko zarobione pieniądze, aby powstanie książki było w ogóle możliwe. Mam nadzieję, że wybór tej książki okaże się dla czytelnika inwestycją wartą wydanych pieniędzy.


Wprowadzenie

Ta książka jest niezwykła, gdyż mówi o pisaniu w JavaScripcie dużych aplikacji sieciowych. Wię­kszość ludzi inaczej widzi zastosowania tego języka. JavaScript zwykle jest (a przynajmniej bywał) stosowany do dodawania do obrazków suwaków przewijania, realizacji liczników gości, określania stosowanej przeglądarki i temu podobnych rzeczy.

Zalety języka JavaScript

Żaden język i żadna technologia nie uzyskały statusu najlepszego rozwiązania tworzenia aplikacji sieciowych. Każde z tych rozwiązań ma zalety i wady. Ostatnie postępy w języku JavaScript i in­nych upowszechniających się technik, jak DHTML, Java, a nawet Macromedia Flash, umożliwia­ją JavaScriptowi korzystanie z tych rozwiązań i tworzenie naprawdę złożonych systemów siecio­wych. Oto jeszcze kilka innych argumentów przemawiających za tworzeniem aplikacji w JavaScripcie.

Prostota, szybkość i efektywność

Jako że JavaScriptu dość łatwo jest się nauczyć, można od razu zacząć go używać. Jest to idealne rozwiązanie, kiedy chcemy dodać swojej witrynie nieco dodatkowej funkcjonalności. Kiedy masz już za sobą podstawy, do tworzenia naprawdę interesujących aplikacji już niedaleko.

JavaScript jest językiem wysokiego poziomu z dużymi możliwościami. Nie sposób zrobić w tym języku niczego na poziomie maszynowym, ale dostępne są różne właściwości przeglądarki, stron, a czasami także systemu, w którym przeglądarka działa. JavaScript nie musi być kompilowany, jak Java™ czy C, a przeglądarka nie wymaga ładowania maszyny wirtualnej do uruchomienia kodu. Po prostu aplikację się koduje i uruchamia.

JavaScript działa także w architekturze obiektowej, podobnie jak Java i C++. Cechy języka, takie jak konstruktory i dziedziczenie oparte na prototypach, dodają nowy poziom abstrakcji. Dzięki temu możliwe jest wielokrotne wykorzystanie tego kodu w naprawdę dużym stopniu.

Wszechobecność

JavaScript jest zdecydowanie najbardziej popularnym językiem skryptowym w Sieci. Nie tysiące, ale miliony witryn sieciowych zawierają JavaScript. Język ten jest obsługiwany przez większość najpopularniejszych przeglądarek (choć tak naprawdę mówimy o JScript w Internet Explorerze). Zarówno Netscape, jak i Microsoft zdają się stale poszukiwać sposobów rozbudowania tego ję­zyka. Takie wsparcie oznacza, że mamy naprawdę duże szanse na to, że przeglądarka naszego go­ścia będzie ten język obsługiwała.

Redukcja obciążenia serwera

To właśnie była jedna z podstawowych przyczyn tak powszechnego przyjęcia JavaScriptu. Język ten pozwala zrealizować po stronie klienta wiele funkcji, które inaczej musiałyby być wykonywane na serwerze. Jednym z najlepszych przykładów jest sprawdzanie poprawności danych. Programiści starej szkoły mogą pamiętać, jak kilka lat temu jedyną metodą sprawdzania poprawności danych, wprowadzonych w formularzu HTML, było przesłanie tych danych na serwer sieciowy i przekaza­nie ich skryptowi CGI w celu ich sprawdzenia.

Jeśli dane nie miały żadnych błędów, skrypt CGI działał dalej normalnie. Jeśli znalezione zostały jakieś błędy, skrypt zwracał użytkownikowi komunikat, opisując problem. Zastanówmy się teraz, jakiego obciążenia zasobów to wymaga. Przesłanie formularza wymaga żądania HTTP z serwera. Po podróży danych przez Sieć skrypt CGI powtórnie jest uruchamiany. Za każdym razem, kiedy użytkownik się pomyli, cały proces się powtarza. Użytkownik musi czekać na przesłanie komuni­katu o błędzie, zanim dowie się, gdzie się pomylił.

Teraz mamy do dyspozycji JavaScript, dlatego możemy sprawdzać zawartość poszczególnych elementów formularza przed odesłaniem ich na serwer sieciowy. Dzięki temu zmniejsza się liczba transakcji HTTP i zdecydowanie zmniejsza się prawdopodobieństwo, że użytkownik pomyli się przy wprowadzaniu danych. JavaScript może też odczytywać i zapisywać „ciasteczka” (cookies), co dotąd wymagało odpowiedniego użycia nagłówków w serwerze sieciowym.

JavaScript rozwija się

Kiedy pojawił się JavaScript 1.1, nowe właściwości: obiekt Image oraz tablica document.images, pozwalające przewijać obrazki - spowodowały szerokie poruszenie. Później pojawił się JavaScript 1.2. Otworzyły się nowe możliwości: obsługa DHTML, warstwy i mnóstwo innych udoskonaleń zdumiały wielu programistów. Wszystko to było zbyt piękne, by mogło być prawdziwe.

Na tym jednak się nie skończyło. JavaScript stał się standaryzowanym językiem skryptowym powszechnego zastosowania, zgodnym z EMCA-262. Przynajmniej jedna firma stworzyła środo­wisko mogące uruchamiać JavaScript z wiersza poleceń. Firma Macromedia wstawiła odwołania JavaScript do technologii Flash. Do ColdFusion firmy Allaire włączono JavaScript do technologii opartej na XML Web Distributed Data Exchange (WDDX, Wymiana Danych Rozproszonych przez Sieć). JavaScript ma coraz więcej właściwości, coraz więcej opcji... i coraz więcej pułapek.

Być może nie ma wyboru

Czasami mamy przed sobą tylko jedną możliwą drogę. Załóżmy, że nasz dostawca usług internetowych nie pozwala uruchamiać skryptów CGI. Co teraz, jeśli chcemy dodać do swojej strony wysyłanie poczty elektronicznej z formularza lub pragniemy skorzystać z ciasteczek? Musimy zająć się rozwiązaniami działającymi po stronie klienta. JavaScript spośród tego typu rozwiązań jest zdecydowanie najlepszy.

I wiele innych zalet

Istnieje jeszcze sporo innych zalet stosowania JavaScriptu, a i czytelnik z pewnością może tę listę jeszcze dalej rozszerzyć. Najważniejsze jest to, że mimo szeregu zalet technologii realizowanych po stronie serwera aplikacje JavaScript mają swoje miejsce w Sieci.

Podstawowa strategia programowania w JavaScript

Kiedy budujemy jakąkolwiek aplikację, czy to w JavaScript, czy nie, w naszym dobrze zrozumianym interesie jest mieć jakąś strategię działania. Dzięki temu łatwiej będzie uporządkować swoje pomysły, szybciej także uda się wszystko zakodować i przetestować. Istnieje mnóstwo publikacji opisujących dok­ładnie tworzenie aplikacji. Czytelnik musi wybrać strategię działania najlepiej mu odpowiadającą, nie sposób zatem tutaj zbytnio w ten temat się zagłębiać. Jeśli jednak będziemy pisać coś między znacznika­mi <SCRIPT> a </SCRIPT>, to pamiętanie o pewnych zasadach projektowych niejednokrotnie zaoszczędzi nam bólu głowy. Jest to naprawdę proste - trzeba odpowiedzieć sobie po prostu na pytania: co? kto? jak?

Co może aplikacja?

Najpierw musimy ustalić, czym aplikacja ma się zajmować. Załóżmy, że chcemy wysyłać pocztę elektroniczną z formularza. Odpowiedzmy na takie pytania:

Ta seria pytań z pewnością będzie dłuższa. Dobrą nowiną jest to, że jeśli na tyle pytań odpowiemy, będziemy znacznie lepiej wiedzieć, co właściwie chcemy osiągnąć.

Kim są nasi odbiorcy

Zidentyfikowanie adresatów informacji jest ogromnie ważne dla określenia wymagań wobec apli­kacji. Upewnijmy się, że dokładnie znamy odpowiedzi przynajmniej na pytania podane niżej:

Można by sądzić, że wszystkie pytania - poza pytaniem o przeglądarkę - nie mają nic wspólnego z JavaScriptem. „Łączność? Kogo to obchodzi? Nie muszę konfigurować routerów ani innych tego typu rzeczy”. Tak, to prawda. Nie trzeba być certyfikowanym inżynierem Cisco. Przejrzyjmy szyb­ko te pytania, jedno po drugim, i zobaczmy, co może być szczególnie ważne.

Używana przeglądarka jest jedną z najważniejszych rzeczy. W zasadzie im nowsza przeglądarka, tym nowszą wersję JavaScriptu obsługuje. Jeśli na przykład nasi odbiorcy są wyjątkowo przywią­zani do NN 2.x i MSIE 3.x (choć nie ma żadnego po temu powodu), automatycznie możemy wykreślić przewijanie obrazków - wersje JavaScript i JScript nie obsługują obiektów Image ani document.images.

Jako że większość użytkowników przeszła na wersje 4.x tych przeglądarek, przewijanie obrazków jest dopuszczalne. Teraz jednak musimy radzić sobie z konkurującymi modelami obiektów. Ozna­cza to, że Twoje aplikacje muszą być przenośne między przeglądarkami lub musisz pisać osobne aplikacje dla każdej przeglądarki i jej wersji (co może być nadaremną nauką).

Gdzie będzie znajdowała się aplikacja? W Internecie, w intranecie, czy też może na pojedynczym komputerze przerobionym na stanowisko informacyjne? Odpowiedź na to pytanie da także szereg innych wytycznych. Jeśli na przykład aplikacja będzie działała w Internecie, możemy być pewni, że do strony będą dobijały się wszelkie istniejące przeglądarki i będą używały aplikacji (a przy­najmniej będą próbowały to zrobić). Jeśli aplikacja działa tylko w intranecie lub na pojedynczym komputerze, przeglądarki będą standardowe dla danego miejsca. Kiedy to piszę, jestem konsul­tantem w firmie będącej jednym z dużych sklepów Microsoftu. Jeśli używany przeze mnie kod okazuje się zbyt dużym wyzwaniem dla Netscape Navigatora i przeglądarka ta sobie z nim nie ra­dzi, to nie muszę się tym przejmować, gdyż użytkownicy i tak korzystają z Internet Explorera.

Ważną rzeczą jest rozdzielczość monitora. Jeśli na stronę wstawiliśmy tabelę o szerokości 900 pikseli, a użytkownicy mają do dyspozycji rozdzielczość tylko 800x600, nie zauważą części nasz ciężkiej pracy. Czy można liczyć na to, że wszyscy użytkownicy będą używali jakiejś określonej rozdzielczości? W przypadku Internetu odpowiedź jest negatywna. Jeśli chodzi o intranet, można mieć szczęście. Niektóre firmy standaryzują komputery PC, oprogramowanie, przeglądarki, moni­tory, a nawet stosowaną rozdzielczość.

Nie można też pominąć zagadnień związanych z łącznością. Załóżmy, że stworzyliśmy sekwencję animowaną, która zarobi tyle, co średni film Stevena Spielberga (jeśli to się uda, to może powinni­śmy... hm... współpracować). Dobrze, ale użytkownicy modemów 56K zapewne przed ściągnię­ciem tego filmu zdążą pójść do kina i ten film obejrzeć, zanim ściągną nasz film. Większość użyt­kowników jest w stanie pogodzić się z tym, że Sieć może się na chwilę zapchać, ale po jakiejś minucie większość z nich uda się na inne strony. Trzeba więc w swoich planach brać pod uwagę ta­kże przepustowość łączy.

Jak radzić sobie z przeszkodami?

Żonglowanie wszystkimi tymi zagadnieniami może wydawać się dość proste, ale rzecz nie jest wcale taka łatwa. Może się okazać, że nie będzie się w stanie obsłużyć wszystkich wersji przeglą­darek, rozdzielczości ekranu lub szczegółów związanych z łącznością. Co teraz? Jak uszczęśliwić wszystkich i nadal zachwycać ich obrazkiem o wielkości 500 kB?

Warto rozważyć jedną lub więcej z poniższych propozycji. Przeczytaj je wszystkie, aby móc pod­jąć decyzję, mając komplet informacji.

Uwzględniaj wszelkie używane przeglądarki

Ta szalenie demokratyczna metoda polega na daniu możliwie najlepszych wyników jak najwięk­szej liczbie odbiorców. Takie kodowanie jest zapewne najpowszechniej stosowanym i najlepszym podejściem. Oznacza to, że starasz się przede wszystkim obsłużyć użytkowników używających Internet Explorera 4.x i 5.x oraz Netscape Navigatora 4.x. Jeśli zrealizujesz wykrywanie ważniej­szych przeglądarek i zakodujesz aplikację tak, aby korzystała z najlepszych cech wersji 4.x, uw­zględniając przy tym różnice między przeglądarkami, będziesz mógł zrobić wrażenie na naprawdę dużej części użytkowników.

Dyskretnie obniżaj jakość

To jest naturalny wniosek wynikający z poprzedniej strategii. Jeśli na przykład mój skrypt zostanie załadowany do przeglądarki nieobsługującej nowych cech, otrzymam paskudne błędy JavaScriptu. Warto używać wykrywania przeglądarki, aby w przypadku niektórych przeglądarek wyłączyć nowe cechy. Analogicznie można ładować różne strony stosownie do różnych rozdzielczości monitora.

Mierz nisko

To podejście polega na założeniu, że wszyscy używają przeglądarki Netscape Navigator 2.0, ekranu w rozdzielczości 640x480, modemu 14,4K oraz procesora Pentium 33 MHz. Od razu zła wiadomość: nie można zastosować niczego poza JavaScriptem 1.0. Nie ma mowy o przewijaniu, o warstwach, wyrażeniach regularnych czy technologiach zewnętrznych (pozostaje podziękować za możliwość użycia ramek). Teraz wiadomość dobra: nasza aplikacja zawędruje pod strzechy. Jed­nak wobec ostatnich zmian samego JavaScriptu nawet to ostatnie nie musi być prawdą. Mierzę naprawdę nisko, ale rozsądnym założeniem wydaje mi się zakładanie użycia NN 3.x i MSIE 3.x. Pozostawanie nieco z tyłu ma swoje zalety.

Mierz wysoko

Jeśli odbiorca nie ma Internet Explorera 5.0, nie zobaczy naszej aplikacji, a tym bardziej - nie będzie jej używał. Dopiero w tej wersji można śmiało korzystać z obiektowego modelu dokumen­tów Internet Explorera, modelu zdarzeń, wiązania danych i tak dalej. Nadmierne oczekiwania do­tyczące wersji przeglądarek odbiorców mogą zdecydowanie okroić krąg potencjalnej publiczności.

Udostępniaj wiele wersji jednej aplikacji

Można napisać szereg wersji swojej aplikacji, na przykład jedną dla Netscape Navigatora, inną dla Internet Explorera. Taki sposób działania nadaje się jednak tylko dla osób dobrze znoszących mo­notonię, jednak może on przynieść jedną wyraźną korzyść. Przypomnijmy sobie, co było mówione o łączności z Siecią. Jako że często nie da się sprawdzić szerokości pasma użytkowników, można pozwolić im dokonać wyboru. Część łączy ze strony głównej umożliwi użytkownikom z połączeniem E1 ładować pełną grafikę, natomiast użytkownicy modemów będą mogli skorzystać z wersji okrojonej.

Użycie języka JavaScript
w prezentowanych aplikacjach

Opisane strategie są strategiami podstawowymi. W przykładach z tej książki użyto różnych strate­gii. Warto jeszcze wspomnieć o konwencjach programowania w JavaScripcie. W ten sposób lepiej zrozumiesz przyjęte przeze mnie rozwiązania oraz ustalisz, czy są one dobre w każdej sytuacji.

Pierwsze pytanie o aplikację powinno dotyczyć tego, czy przyda się ona do czegoś gościom odwie­dzającym stronę. Każda aplikacja rozwiązuje jeden lub więcej podstawowych problemów. Wyszu­kiwanie i wysyłanie wiadomości, pomoc kontekstowa, sprawdzanie lub zbieranie informacji, prze­wijanie obrazków i tak dalej - to są rzeczy, które lubią sieciowi żeglarze. Jeśli planowana aplikacja nie znalazła dostatecznego uzasadnienia swojego zaistnienia, nie poświęcałem jej swojego czasu.

Następną kwestią jest to, czy JavaScript pozwala osiągnąć potrzebną mi funkcjonalność. To było dość łatwe. Jeśli odpowiedź brzmiała „tak”, stawałem do walki. Jeśli nie, to tym gorzej dla JavaScriptu.

Potem przychodziła kolej na edytor tekstowy. Oto niektóre zasady używane w prezentowanych kodach.

Wielokrotne użycie kodu przyszłością narodu

To właśnie tutaj do głosu dochodzą pliki źródłowe JavaScriptu. W aplikacjach tych używane są pliki z kodem, ładowane za pomocą następującej składni:

<SCRIPT LANGUAGE="JavaScript1.1" SRC="jakisPlikJS.js"></SCRIPT>

Plik jakisPlikJS.js zawiera kod, który będzie używany przez różne skrypty. W wielu aplikacjach tej książki używane są pliki źródłowe JavaScriptu. To się sprawdza. Po co wymyślać coś od nowa? Można także użyć plików źródłowych w celu ukrycia kodu źródłowego przed resztą aplikacji. Wygodne może być umieszczenie bardzo dużej tablicy JavaScriptu w pliku źródłowym. Użycie pli­ków źródłowych jest tak ważne, że poświęciłem im cały rozdział 6.

Niektóre aplikacje zawierają kod po prostu wycinany i wklejany z jednego miejsca w inne. Kod taki może być dobrym kandydatem na wydzielenie w plik źródłowy. Wklejanie stosowałem po to, aby zbyt często nie powtarzać „zajrzyj do kodu pliku bibliotecznego trzy rozdziały wcześniej”. W ten sposób cały czas masz kod przed oczami, póki go nie zrozumiesz. Kiedy już aplikacja na stronie będzie działała tak, jak sobie tego życzysz, zastanów się nad wydzieleniem części kodu do plików źródłowych.

Wydzielanie JavaScriptu

Między znacznikami <HEAD> i </HEAD> należy umieszczać możliwie dużo kodu w pojedynczym zestawie <SCRIPT></SCRIPT>.

Deklarowanie zmiennych globalnych i tablic na początku

Nawet jeśli globalne zmienne i tabele mają początkowo wartości pustych ciągów lub wartości nieokreślone, definiowanie ich blisko początku skryptu jest dobrym sposobem poradzenia sobie z nimi, szczególnie jeśli używane są w różnych miejscach skryptu. W ten sposób nie musisz prze­glądać zbyt wiele kodu, aby zmienić wartość zmiennej: wiesz, że znajdziesz ją gdzieś na początku.

Deklarowanie konstruktorów po zmiennych globalnych

W zasadzie funkcje tworzące obiekty definiowane przez użytkownika umieszczam blisko początku skry­ptu. Robię tak po prostu dlatego, że większość obiektów musi powstać na początku działania skryptu.

Definiowanie funkcji zgodnie z porządkiem „chronologicznym”

Innymi słowy - staram się definiować funkcje w takiej kolejności, w jakiej będą wywoływane. Pierwsza funkcja definiowana w skrypcie jest wywoływana na początku, druga funkcja jest wy­woływana jako następna, i tak dalej. Czasem może to być trudne lub wręcz niemożliwe, ale dzięki temu przynajmniej poprawia się sposób zorganizowania aplikacji i pojawia się szansa, że funkcje wywoływane po sobie będą w kodzie obok siebie.

Każda funkcja realizuje jedno zadanie

Staram się ograniczyć funkcjonalność poszczególnych funkcji tak, aby każda z nich realizowała dokładnie jedno zadanie: sprawdzała dane od użytkownika, odczytywała lub ustawiała ciasteczka, przeprowadzała pokaz slajdów, pokazywała lub ukrywała warstwy i tak dalej. Teoria jest doskona­ła, ale czasem trudno ją wcielić w życie. W rozdziale 5. zasadę tę bardzo mocno naruszam. Fun­kcje tamtejsze realizują pojedyncze zadania, ale są naprawdę długie.

W miarę możliwości używaj zmiennych lokalnych

Stosuję tę zasadę w celu zaoszczędzenia pamięci. Jako że zmienne lokalne JavaScriptu znikają zaraz po zakończeniu realizacji funkcji, w której się znajdują, zajmowana przez nie pamięć jest zwracana do puli systemu. Jeśli zmienna nie musi istnieć przez cały czas działania aplikacji, nie tworzę jej jako globalnej, lecz jako lokalną.

Następny krok

Teraz powinieneś mieć już jakieś pojęcie o tym, jak przygotować się do tworzenia aplikacji Java­Script i jak tworzę swoje aplikacje. Bierzmy się więc do zabawy.


Cechy aplikacji:

  • Wydajne wyszukiwanie po stronie klienta

  • Wiele algorytmów wyszukiwania

  • Sortowanie i dzielenie wyników wyszukiwania

  • Skalowalność

  • Łatwe zapewnienie zgodności z JavaScriptem 1.0

Prezentowane techniki:

  • Użycie separatorów wewnątrz łańcuchowych do rozdzielania pól rekordów

  • Zagnieżdżanie pętli for

  • Rozsądne użycie metody document.write()

  • Zastosowanie operatora trójargumentowego

1

Wyszukiwanie danych
po stronie klienta

Mechanizm wyszukiwawczy może się przydać w każdej witrynie, czy jednak trzeba zmuszać ser­wer do przetwarzania wszystkich zgłaszanych w ten sposób zapytań? Prezentowane tu rozwiązanie umożliwia realizację przeszukiwania stron WWW całkowicie po stronie klienta. Zamiast przesyłać zapytania do bazy danych lub do serwera aplikacji, użytkownik pobiera „bazę danych” wraz z żą­danymi stronami. Baza ta jest zwykłą tablicą JavaScriptu, zawierającą w każdym elemencie poje­dynczy rekord.

Takie podejście daje kilka znaczących korzyści - głównie redukcję obciążenia serwera i skrócenie czasu odpowiedzi. Nie należy zapominać, że opisywana tu aplikacja jest ograniczona zasobami klienta, szczególnie szybkością procesora i dostępną pamięcią. Mimo to w wielu przypadkach może ona okazać się doskonałym narzędziem. Kod programu zamieszczono w katalogu ch01 ar­chiwum przykładów, zaś na rysunku 1.1 pokazano pierwszy ekran aplikacji.

Program udostępnia dwie metody wyszukiwania, nazwane umownie AND i OR. Poszukiwanie informacji może odbywać się według tytułu i opisu lub według adresu URL dokumentu. Z punktu widzenia użytkownika obsługa aplikacji jest całkiem prosta: wystarczy wpisać szukany termin i nacisnąć Enter. Możliwości wyszukiwania są następujące: