Uwaga: w literaturze anglojęzycznej zamiast słowa aplet używane jest applet
Wcześniejsze rozdziały pokazywały obiektowość Javy na poziomie pojedynczych elementów tworzących program. Jeśli jednak popatrzymy na cały program napisany w tym języku, okaże się, że możemy go również potraktować jako obiekt w środowisku, w którym jest uruchomiany. Najlepszym przykładem obiektowego podejścia do całego programu są aplety. Są to specjalistyczne programy, których kod przechowywany jest na serwerach internetowych bądź intranetowych razem z innymi plikami wyświetlanymi w przeglądarce stron WWW (HTML, grafika), uruchamiany w jej środowisku (bądź osadzany w tym środowisku w przypadku gdy wersja Javy zaimplementowana w przeglądarce jest starsza niż wymagana przez kod apletu). Aplet, z punktu widzenia odbiorcy strony, jest jej fragmentem, najczęściej wizualnie nierozróżnialnym od pozostałej części, wyróżniający się jednak możliwościami funkcjonalnymi. Aplet może więc być fragmentem strony o bardziej skomplikowanym interfejsie, który zapewni szybkie działanie (strona nie musi być przeładowywana, żeby aplet nawet ekstremalnie zmienił swój wygląd). Może też być fragmentem wykonującym skomplikowane obliczenia bez potrzeby angażowania serwera internetowego. Innym przykładowym zastosowaniem apletu może być szybki dostęp do bazy danych znajdującej się na serwerze, który odbywa się bez blokowania innych operacji na stronie. Często spotyka się też aplety ułatwiające wymianę informacji między dwoma lub więcej osobami korzystającymi z tej samej strony internetowej (chat, gry dwu- bądź wieloosobowe itd.). W praktyce funkcjonalność apletu zależy od naszych umiejętności programistycznych ograniczonych tylko restrykcjami nałożonymi przez system bezpieczeństwa apletów.
Sam aplet to program uruchamiany w komputerze użytkownika przeglądającego sieć internetową po ściągnięciu go do lokalnego środowiska. Od użytkownika nie są wymagane żadne dodatkowe czynności poza posiadaniem odpowiedniej przeglądarki, która jest w stanie uruchomić ten aplet. Rozwiązanie takie, czyli przechowywanie apletu na serwerze i ściąganie go za każdym razem do użytkownika, daje twórcy oprogramowania bardzo szerokie możliwości w zakresie natychmiastowego uaktualniania wersji programu. Od chwili umieszczenia nowej, poprawionej wersji programu na serwerze otrzymują ją wszyscy użytkownicy. Bez względu na to, czy użytkowników jest dwóch czy dwa miliony. Pewna wadą może wydawać się konieczność każdorazowego ściągania pliku wykonywalnego poprzez sieć. Nie jest to jednak zbyt duży problem, gdyż pliki wykonywalne w Javie nie są zbyt obszerne. Ponadto większość przeglądarek potrafi korzystać z plików wykonywalnych zapisanych wcześniej w lokalnym katalogu dyskowym (w czasie poprzednich wizyt na tej stronie). Pliki te są ładowane z serwera ponownie tylko wtedy, gdy się zmieniły, czyli na przykład dopiero po modyfikacji programu.
Projektując aplikację osadzoną na stronie internetowej, należy pamiętać, że ma on pewne ograniczenia wynikające z konieczności zachowania bezpieczeństwa (aplet nie może odwoływać się do zasobów lokalnych komputera ani w nie ingerować). Ponadto aplety posiadają kilka ograniczeń w stosunku do standardów wynikających z niepełnej implementacji Javy w przeglądarkach internetowych. Przy tworzeniu projektu powinno się już we wstępnej fazie projektowej ogarnąć cele i możliwości, dążąc do efektywnego kompromisu między potrzebami i dostępnymi warunkami pracy.
Wszystkie dotychczasowe rozważania na temat programowania obiektowego przeprowadzałem najczęściej na krótkich, wyrwanych z większej całości fragmentach programu. Teraz chciałbym pokazać, jak napisać realnie działający program, który może być umieszczony w internecie w taki sposób, aby mógł być załadowany przez internautę z użyciem jego przeglądarki internetowej i wykonany w jej środowisku.
Każdy z języków programowania i każde środowisko lub system operacyjny posiadają swoją specyfikę, którą należy uwzględnić, aby uzyskać poprawny pod względem formalnym program wykonywalny. Dla Javy też istnieje taka specyfikacja, przy czym składa się ona z dwóch niezależnych warunków. Do poprawnej pracy oba muszą być spełnione. Jeden z warunków dotyczy sposobu stworzenia programu, aby mógł on być poprawnie wykonany. Drugi warunek dotyczy środowiska wykonania tego programu, czyli przeglądarki internetowej oraz sposobu konstrukcji strony internetowej, które posłużą za miejsce uruchomienia i otoczenie programu.
Wszystkie elementy w Javie są skrajnie obiektowe. Wyjątki, jeśli istnieją, jak na przykład interfejsy, poza tym, że można je nazwać klasami szczątkowymi, w praktyce służą jedynie podniesieniu funkcjonalności programowania obiektowego. Poza takimi drobnymi wyjątkami wszystko w Javie jest obiektem bądź klasą. Nie należy się więc dziwić, że również program internetowy, czyli aplet, musi być klasą i musi posiadać wszystkie jej charakterystyczne cechy. Najprostszy możliwy aplet ma postać pokazaną na listingu 3.1.
public class ApletZero
extends java.applet.Applet {
// opcjonalne elementy apletu
// bez których brak mu funkcjonalności
}
Ten aplet nie robi zupełnie nic. Doskonale jednak może posłużyć do zaznaczenia najważniejszych cech programu internetowego:
Pokazany tu najprostszy aplet nie wykonuje żadnych czynności poza wymuszeniem prostych działań związanych z uruchomieniem niewidocznych tu, a jednak obecnych inicjatorów klasy, obiektu oraz konstruktora. Praktyczny sposób wypełnienia tego apletu z użyciem opcjonalnych elementów pokażę dalej.
W poprzednim paragrafie zwróciłem uwagę na to, że program projektujemy jako klasę. Dopiero połączenie specyfikacji maszyny wirtualnej Javy zaimplementowanej w przeglądarkach oraz danych zawartych na stronie HTML umożliwia utworzenie i aktywację obiektu. Aby przekazać do JVM informacje, jak nazywa się klasa, na podstawie której należy utworzyć obiekt w pliku HTML, należy wstawić specjalny fragment kodu (nazywany tagiem lub sekcją apletu). Podstawowy fragment, najprostszy z możliwych, który zapewni uruchomienie apletu, pokazany jest na listingu 3.2.
<applet code="ApletZero.class" width="200" height="100"> </applet>
W zaprezentowanym fragmencie poszczególne elementy mają następujące znaczenie:
<applet - rozpoczęcie sekcji zawierającej opis programu.
</applet> - zakończenie sekcji opisującej program.
code="ApletZero.class" - ten wiersz określa plik z kodem klasy apletu. Plik wymieniony w tym miejscu musi znajdować się (poza pewnym wyjątkiem opisanym dalej w tym paragrafie) w tym samym miejscu (ten sam katalog, ten sam serwer), co plik HTML zawierający dany znacznik.
width="200" - szerokość fragmentu strony w przeglądarce zarezerwowana dla apletu (szerokość apletu). Szerokość jest liczona w pikselach ekranowych i w tym wypadku wynosi 200 pikseli.
height="100" - wysokość fragmentu strony w przeglądarce zarezerwowana dla apletu (wysokość apletu). Wysokość jest liczona w pikselach ekranowych i w tym wypadku wynosi 100 pikseli.
Na podstawie zaprezentowanej sekcji opisującej aplet przeglądarka wykonuje następujące czynności:
Poza zaprezentowanymi elementami sekcji applet mogą się w niej znaleźć inne opcjonalne elementy rozpoznawane przez przeglądarkę:
codebase="adres_URL_apletu" - jest to atrybut, który umożliwia realizację wspomnianego wcześniej wyjątku co do położenia pliku class z definicją apletu. Jak napisałem, brak tego atrybutu oznacza poszukiwanie pliku z apletem w tym samym katalogu i na tym samym serwerze co plik HTML. Jeśli codebase wskazuje inny serwer bądź inny katalog, plik wykonywalny może znajdować się również w tym drugim miejscu.
archive="nazwa_archiwum.jar" - parametr ten umożliwia wskazanie pliku bądź plików z archiwami typu jar (niektóre przeglądarki akceptują również inne typy archiwów), które mogą być wykorzystane jako biblioteki używane przez aplet. Również sam plik z klasą apletu może znaleźć się w skompresowanych plikach. W praktyce wszystkie używane przez aplet klasy, łącznie z samym apletem, z zachowaniem struktury katalogów (odpowiadającej ewentualnym pakietom) kompresuje się do jednego archiwum i wskazuje jako plik do załadowania. Zastosowanie kompresji przyspiesza ładowanie programu na stronę aż z dwóch powodów. Po pierwsze ładowanie mniejszego pliku trwa znacznie krócej (a strata czasu na dekompresję jest znacznie mniejsza niż zysk osiągnięty przez ładowanie mniejszego pliku). Po drugie przeglądarka ustanawia jedno połączenie na każdy plik. Jeśli wszystkie pliki używanego przez aplet pakietu są skompresowane do jednego pliku, przeglądarka wykonuje tylko jedno połączenie z serwerem.
name="nazwa_egzemplarza_apletu" - tworząc egzemplarz klasy apletu, JVM nadaje mu domyślną nazwę zgodną z jej wewnętrznymi regułami. Możemy wymusić zastosowanie dla egzemplarza apletu konkretnej nazwy. Takie działanie ma sens wtedy, gdy na jednej stronie znajduje się więcej niż jeden aplet i zamierzamy porozumiewać się między apletami bądź wywoływać ich metody spoza wnętrza danego apletu. Więcej na ten temat znajduje się w podrozdziale 3.3. Komunikacja ze światem zewnętrznym.
mayscript - dodanie tego słowa kluczowego umożliwia wykonywanie skryptów w języku JavaScript wewnątrz apletu w taki sposób, aby reakcja przeglądarki była taka sama, jakby skrypt był wykonywany na stronie HTML. Dodanie tego słowa umożliwia na przykład czytanie i ustawienie cookies bądź zmianę tytułu w przeglądarce. Więcej na temat uruchamiania skryptów JavaScript z wnętrza apletów znajduje się w podrozdziale 3.4. Aplet a JavaScript.
vspace="margines_pionowy", hspace="margines_poziomy" - atrybuty te określają szerokość i wysokość marginesów (odpowiednio pionowych i poziomych). Ich wartości wyrażone są w pikselach.
align="wyrównywanie" - atrybut określa położenie apletu na stronie, jeśli istnieje możliwość sterowania nim w ramach określonych rozmiarami i marginesami apletu. Atrybut ten może przyjąć wartości: left, right, top, texttop, middle, absmiddle, baseline, bottom, absbottom.
alt="tekst_wyjaśniający" - jeśli przeglądarka rozpoznaje poprawnie sekcję apletu, lecz nie może go uruchomić, wyświetla tekst znajdujący się w tym miejscu.
<param name="nazwa_parametru" value="wartość"> - wiersz taki umożliwia przekazanie apletowi wartości argumentu ze strony HTML, który może być przez niego odebrany z użyciem metody getParametr. Przekazywanie argumentów może być stosowane w przypadku, gdy jeden aplet wykorzystujemy do wielu celów na różnych podstronach tego samego serwisu (na przykład aplet łączy się z różnymi bazami danych, czy ma wiele wersji językowych). Innym miejscem, gdzie można użyć apletu z parametrami, są na przykład strony dynamicznie zmieniane na skutek działań użytkownika (ASP, JSP itp.). Jeśli wiersz ten występuje, musi być na ostatnim miejscu tagu <applet>. Wcześniejsza zawartość musi znajdować się w domkniętym tagu (musi kończyć się znakiem >). W tagu <applet> może wystąpić więcej niż jeden wiersz przekazywania parametrów. W takim przypadku aplet może odebrać ze strony większą liczbę parametrów.
alternatywnyHTML - poza domknięciem tagu <applet>, a przed jego zakończeniem </applet> może znaleźć się dodatkowy fragment kodu HTML, który zostanie użyty w przypadku, gdy używana przeglądarka nie rozpoznaje opisywanej konstrukcji. Kod ten może być zarówno prostym napisem informującym o niemożliwości uruchomienia apletu, jak i skomplikowanym fragmentem strony zastępującym ten aplet.
...