Joanna Milewska INTERAKTYWNA WIZUALIZACJA METADANYCH HYDROMETEOROLOGICZNYCH

Transkrypt

1 Joanna Milewska INTERAKTYWNA WIZUALIZACJA METADANYCH HYDROMETEOROLOGICZNYCH praca magisterska studia dzienne kierunek studiów: informatyka specjalność: informatyka stosowana w inŝynierii środowiska promotor: dr inŝ. Robert Szczepanek nr pracy: 2208 K RAKÓW 2009

2 1 WSTĘP ELEMENTY INTERAKTYWNEGO INTERFEJSU UśYTKOWNIKA System nawigacyjny Rodzaje nawigacji Przykłady stylów nawigacji Obsługa zdarzeń Zdarzenia myszy Zdarzenia klawiatury Zdarzenia formularzy Zdarzenia strony, okna i obrazu Formularze Projektowanie defensywne Interaktywne elementy formularza Układ strony Typografia Kolorystyka strony Teoria koloru Zasady harmonii barwnej OBSŁUGA INTERAKCJI UśYTKOWNIKA Z APLIKACJĄ Podstawy działania protokołu HTTP Metody HTTP Wersje protokołu HTTP Nagłówki HTTP Kody statusu Metody GET i POST Techniki komunikacyjne Technika ukrytej ramki Obiekt XMLHttp NARZĘDZIA WYKORZYSTANE DO STWORZENIA APLIKACJI MySQL PHP Google Maps API HTML/XHTML

3 4.5 XML CSS AJAX BUDOWA BAZY METADANYCH HYDROMETEOROLOGICZNYCH Metadane Relacyjne bazy danych ZaleŜności Normalizacja Struktura bazy danych Tabele OPIS ZAPROJEKTOWANEJ APLIKACJI Komunikacja klient-serwer oraz przetwarzanie danych Projekt interfejsu uŝytkownika Wspomagający interakcję układ strony Typografia w aplikacji Nawigacja Kolorystyka Opis działania aplikacji WNIOSKI PODSUMOWANIE BIBLIOGRAFIA ŹRÓDŁA INTERNETOWE

4 1 WSTĘP Przez długi czas aplikacje internetowe pod wieloma względami ustępowały aplikacjom stacjonarnym. Niezwykły rozwój technologii internetowych w latach całkowicie zmienił charakter sieci WWW. Coraz liczniej zaczęły pojawiać się interaktywne aplikacje, wypierające dominujące wcześniej statyczne strony. W związku z rosnącymi oczekiwaniami uŝytkowników zarówno biznesowych jak i indywidualnych, co do funkcjonalności aplikacji internetowych programiści zostali zmuszeni do opracowania nowych modeli interakcji. Powstałe rozwiązania pozwalają projektować z jednej strony przyjazne interfejsy, a z drugiej sprawną obsługę interakcji. Cel pracy Celem pracy jest stworzenie ergonomicznej i przyjaznej uŝytkownikowi aplikacji internetowej do wyszukiwania i interaktywnej wizualizacji metadanych hydrometeorologicznych przechowywanych w bazie. Na potrzeby aplikacji konieczne jest stworzenie relacyjnej bazy danych przechowującej wybrane metadane hydrometeorologiczne Zakładu Hydrologii Politechniki Krakowskiej. Aplikacja ta jest zaprojektowana w oparciu o przytoczone w pracy zasady projektowania. Kolejnym celem jest stworzenie aplikacji internetowej działającej w sposób zbliŝony do aplikacji desktopowych. Aplikacja ta ma być zbudowana wyłącznie w oparciu o darmowe komponenty. Celem jest równieŝ przestrzenna wizualizacja wyników wyszukiwania na mapie cyfrowej. Ponadto celem jest zaprezentowanie teorii dotyczącej projektowania nowoczesnych, interaktywnych aplikacji webowych. 4

5 Zawartość pracy Rozdział pierwszy stanowi wstęp do pracy. Rozdział drugi zawiera opis elementów interfejsu uŝytkownika wpływających na jakość pracy uŝytkownika z aplikacją. W rozdziale zostały opisane zasady projektowania dotyczące układu elementów na stronie, kolorystyki, typografii, a takŝe projektowania formularzy i obsługi zdarzeń Rozdział trzeci zawiera podstawy teoretyczne dotyczące komunikacji typu klient-serwer. W szczególności zostały opisane zasady działania protokołu HTTP oraz techniki komunikacji związane z technologią AJAX. Rozdział czwarty zawiera krótką charakterystykę poszczególnych narzędzi wykorzystanych do tworzenia aplikacji. Rozdział piąty stanowi dokumentację stworzonej bazy metadanych hydrometeorologicznych. W rozdziale przedstawiono metodykę tworzenia relacyjnych baz danych. Rozdział szósty opisuje specyfikę zaprojektowanej aplikacji. Zawiera opis interfejsu uŝytkownika, zaprojektowanego według dobrych praktyk programistycznych, oprócz tego opisuje proces przetwarzania i przesyłania danych pomiędzy klientem i serwerem. Rozdział siódmy przedstawia wnioski. Rozdział ósmy stanowi podsumowanie pracy. 5

6 2 ELEMENTY INTERAKTYWNEGO INTERFEJSU UśYTKOWNIKA Interfejs jest tą częścią aplikacji, dzięki której staje się moŝliwa komunikacja z uŝytkownikiem. Na interfejs składają się elementy umoŝliwiające interakcję system nawigacyjny, formularze, przyciski, suwaki itp. Projekt graficzny, na który składa się układ elementów na stronie, kolorystyka czy typografia równieŝ nie pozostaje bez znaczenia dla interakcji, powinien ułatwić uŝytkownikowi pracę z aplikacją. Interfejs powinien być zaprojektowany w taki sposób, aby uŝytkownik nie czuł się uwięziony w obrębie danej usługi. NaleŜy umoŝliwić odwiedzającemu płynne wykonanie zadania, którego realizacją był zainteresowany, jednocześnie udostępniając mu moŝliwość odkrywania innych moŝliwości aplikacji. 2.1 System nawigacyjny Nawigacja jest elementem, który w wizualny sposób przedstawia strukturę całej witryny. Informuje jakiego typu jest to witryna, jaka jest jej zawartość, gdzie się obecnie znajduje odwiedzający oraz gdzie moŝe pójść dalej i jak wrócić. Przejrzysty, intuicyjny system nawigacji odgrywa ogromną rolę w procesie poznawczym witryny, sprawia, Ŝe uŝytkownik porusza się w jej obrębie w płynny sposób, dzięki czemu moŝe skupić się na faktycznej funkcjonalności oferowanej przez aplikację Rodzaje nawigacji W większości witryn ze względu na ich obszerność tworzy się warstwowy system nawigacji. WyróŜnia się jej trzy rodzaje [Rosenfeld, 2003]: Nawigacja globalna zwana równieŝ nawigacją stałą dotyczy zwykle hierarchii informacji lub szerokich zawartości kategorii. SłuŜy do wskazania, w którym miejscu witryny uŝytkownik się znajduje oraz jak moŝe dostać się w inne miejsca. Zwykle ten rodzaj nawigacji jest niezmienny w całej witrynie znajduje się w tym samym miejscu i tej samej formie. Wyjątek moŝe jedynie stanowić strona główna witryny, która często 6

7 róŝni się od reszty. Nawigacja globalna powinna zawierać wizualny element wskazujący w jakiej części witryny uŝytkownik aktualnie się znajduje. Nawigacja lokalna zaczyna się tam gdzie kończy się nawigacja globalna. Daje moŝliwość poruszania się w obrębie konkretnej części witryny. W niektórych witrynach moŝna spotkać główne narzędzie nawigacyjne integrujące nawigację globalną i lokalną. Nawigacja kontekstowa stosowana jest w odniesieniu do elementów, które nie pasują do strukturalnego podziału na kategorie, będącego podstawą działania systemów lokalnej i globalnej nawigacji. Są to odnośniki do innych związanych tematycznie stron wewnątrz większej sieci Przykłady stylów nawigacji Istnieje wiele sposobów projektowania systemu nawigacji. Mogą to być zakładki, paski, menu, listy odsyłaczy, ścieŝki, mapy odsyłaczy. Najczęściej łączy się kilka sposobów aby dostosować je do potrzeb witryny [Cohen, 2004]. Do nawigacji globalnej i lokalnej najczęściej przeznacza się górną i lewą część strony. Obszar wzdłuŝ górnej części strony wykorzystuje się w prawie kaŝdej witrynie do celów nawigacyjnych. W niektórych witrynach w części tej znajduje się główne narzędzie nawigacyjne, w innych nawigacja globalna albo lokalna, umieszcza się tam równieŝ logo witryny jako sposób na identyfikację witryny oraz odnośnik do strony głównej. Popularnym rozwiązaniem są paski menu lub zakładki umieszczane w górnej części strony. W przypadku gdy w obrębie witryny chociaŝ kilka stron wymaga przewijania w celu zapoznania się z treścią, zaleca się by nawigacja globalna w uproszczonej wersji była powtórzona na dole kaŝdej strony. Zakładki wykorzystuje się szczególnie w przypadku gdy witryna podzielona jest na kategorie, umieszcza się je w górnej części strony (rys.2.1.1). Zakładki swoim wyglądem nawiązują do folderów. Dają uŝytkownikowi do zrozumienia, Ŝe znajduje się w jednym z równoległych obszarów wewnątrz witryny. Ta wizualna metafora została pierwszy raz uŝyta przez firmę Apple Computer w interfejsie MacOS. 7

8 Rysunek Przykład zastosowania zakładek jako nawigacji globalnej wraz z powtórzeniem na dole strony [Źródło: Lewostronny panel nawigacyjny stał się juŝ pewną konwencją internetową (rys.2.1.2). Daje do dyspozycji proste, elastyczne i stałe źródło nawigacji w całej witrynie. Panel wyjaśnia strukturę witryny, odsłania sekcje, które uŝytkownik mógł wcześniej pominąć. Co waŝne umoŝliwia skalowanie, w miarę rozwoju serwisu do panelu moŝna dodawać kolejne odnośniki lub przyciski. Nie stoi nic na przeszkodzie, aby panel nawigacyjny umieścić z prawej strony jeśli taki układ jest bardziej intuicyjny. Rysunek Przykład zastosowania lewostronnego panelu jako nawigacji lokalnej [Źródło: ŚcieŜka (ang. Bread crumb-trail) jest sposobem nawigacji szczególnie przydatnym w witrynach, które zawierają duŝo powiązanych ze sobą hierarchicznie 8

9 informacji (rys.2.1.3). ŚcieŜka daje uŝytkownikowi wizualną reprezentację miejsca, w którym się znajduje oraz listę odnośników, które wskazują poziomy hierarchii znajdujące się na drodze do aktualnej strony. UmoŜliwia nie tylko cofnięcie się do strony głównej, ale takŝe do kaŝdego z etapów drogi. Dzięki czemu odwiedzający moŝe zmieniać kierunek poruszania się od pewnego momentu. Rysunek Przykładowa ścieŝka [Źródło: ŚcieŜka wielostronicowa jest stylem nawigacji stosowanym w szczególności gdy prezentowany jest długi tekst albo wiele wyników wyszukiwania (rys.2.1.4). W takich przypadkach dzieli się obszerny zbiór informacji na strony i na kaŝdej umieszcza się ścieŝkę. UmoŜliwia ona uŝytkownikowi przemieszczanie się w przód albo wstecz, po jednej stronie lub skoczenie do konkretnej strony. Informuje równieŝ, w którym miejscu uŝytkownik się znajduje. Rysunek Przykład ścieŝki wielostronicowej stosowanej przez Google [Źródło: Lista odnośników jest najprostszym rozwiązaniem, odsłania zawartość witryny przez wymienienie jej elementów (rys.2.1.5). Odnośniki stosuje się zwykle w przypadku krótkiej listy luźno powiązanych ze sobą elementów lub w przypadku długiej listy ściśle powiązanych elementów. Chyba nie istnieje witryna, w której systemie nawigowania nie stosowano by odnośników. Odnośniki stosuje się równieŝ bezpośrednio w tekście. Przyjęło się, Ŝe tekst będący odnośnikiem wyróŝnia się poprzez podkreślenie, zaleca się równieŝ stosowanie standardowego koloru. 9

10 Rysunek Wykorzystanie listy odnośników jako nawigacji kontekstowej [Źródło: Pole wyszukiwania stosuje się ze względu na internautów, którzy nie lubią przeglądać zawartości stron (rys.2.1.6). Poszukują oni konkretnych informacji i chcą je jak najszybciej odnaleźć. UmoŜliwiając dostęp do pola wyszukiwania zaleca się przeprowadzenie testów. Do testów naleŝy wybrać około 50 moŝliwych haseł jakich odbiorcy mogą szukać. Następnie naleŝy sprawdzić czy wyszukiwarka zwraca strony, które mają znaczenie w takim wyszukiwaniu. Rysunek Pole wyszukiwania [Źródło: Obsługa zdarzeń W interaktywnych serwisach internetowych najwaŝniejsza jest reakcja aplikacji na aktywność uŝytkownika. JuŜ na poziomie HTML i CSS moŝna uzyskać ciekawe efekty wizualne będące reakcją na zdarzenia wywołane przez uŝytkownika. Najprostszym przykładem moŝe być obsługa zdarzeń związanych z odsyłaczem. W zaleŝności od działań uŝytkownika zmienia się stan odsyłacza. Wykorzystując CSS moŝna określić wygląd odsyłacza w zaleŝności od jego stanu uŝywając do tego pseudoklas. Najczęściej wyróŝnia się następujące stany odsyłacza: zwykły odsyłacz, 10

11 odwiedzony, pod wskaźnikiem myszy i aktywny. Stanom tym odpowiadają selektory, dla których moŝna napisać odrębne reguły stylów. Wygląd odsyłacza będzie się róŝnił w zaleŝności od działań uŝytkownika. Zasady kaskadowości wymagają zachowania kolejności selektorów, ze względu na to, Ŝe odsyłacz moŝe znajdować się w więcej niŝ jednym stanie, np. odwiedzony i pod wskaźnikiem myszy. Zdarzenia są generowane przez uŝytkownika w sposób bezpośredni bądź pośredni, najczęściej słuŝą do uruchamiania skryptów zarówno działających po stronie klienta jak i serwera. Często wiąŝe się to z wysyłaniem danych więc w celu ich weryfikacji skrypty działające po stronie serwera są uruchamiane przez skrypty działające po stronie klienta. Pośrednikiem pomiędzy uŝytkownikiem, a skryptami działającymi po stronie serwera są skrypty JavaScript i to one najczęściej uŝywane są do obsługi zdarzeń. Zdarzenia moŝna podzielić na cztery kategorie: Zdarzenia myszy, Zdarzenia klawiatury, Zdarzenia formularza, Zdarzenia stron, okien i obrazów Zdarzenia myszy Zdarzenia myszy są najczęściej implementowanymi zdarzeniami w aplikacjach internetowych. Funkcje obsługi zdarzeń myszy moŝna umieścić w większości znaczników HTML-a, które rozpoznają zdarzenia, np. <body>, <form>, <a>, <img>. Język JavaScript rozpoznaje siedem zdarzeń myszy: onclick wywołane pojedynczym kliknięciem na wybranym obszarze, ondblclick wywołane podwójnym kliknięciem na wybranym obszarze, onmousedown wywołane naciśnięciem przycisku myszy, onmouseup wywołane zwolnieniem przycisku myszy, onmousemove spowodowane poruszeniem się myszy po aktywnym obszarze, onmouseout wywołane wyjechaniem poza granice aktywnego obszaru, onmouseover wywołane najechaniem na aktywny obszar. Ciekawą techniką, która dzięki zdarzeniom jest dostępna w serwisach internetowych jest technika przeciągnij i upuść (ang. Drag & Drop). Technika ta 11

12 wywodzi się z systemu Windows, przykładem jest wrzucanie plików do kosza. Polega na najechaniu kursorem na dany obiekt, kliknięciu, przytrzymaniu lewego przycisku myszy, przesunięciu kursora w dowolne miejsce wraz z przyklejonym do niego obiektem, a następnie zwolnieniu przycisku, czego efektem jest przesunięty obiekt. Algorytm Drag & Drop moŝe wyglądać następująco: 1. JeŜeli naciśnięto lewy przycisk myszy naleŝy sprawdzić czy kursor myszy znajduje się nad aktywnym obiektem. 2. Jeśli tak, naleŝy ustalić współrzędne kursora względem przesuwanej warstwy i rozpocząć D&D. 3. Dopóki przycisk jest wciśnięty naleŝy przesuwać warstwę wraz z kursorem. 4. Kiedy przycisk zostanie zwolniony koniec D&D. W technice Drag&Drop obsługiwane są zdarzenia myszy dotyczące ruchu oraz stanu jej przycisków Zdarzenia klawiatury Niestety przeglądarki w róŝny sposób implementują kluczowe właściwości zdarzeń klawiatury. Wobec czego projektant ma ograniczony wybór opcji implementacji zdarzeń klawiatury, które będą niezawodne i niezaleŝne od przeglądarki. JavaScript rozpoznaje trzy zdarzenia klawiatury: onkeydown zdarzenie gdy klawisz jest wciśnięty, onkeyup zdarzenie gdy klawisz zostaje zwolniony, onkeypress zdarzenie gdy klawisz jest przyciśnięty bądź przytrzymany Zdarzenia formularzy JavaScript obsługuje pięć zdarzeń, które w języku HTML kojarzone są z formularzami: onblur, onchange, onfocus, onreset, onsubmit. 12

13 Odniesienia do rozmycia (blur), zmiany (change) i zogniskowania (focus) kojarzone są z elementami tekstowymi w HTML-u. W momencie gdy w HTML-u zostanie utworzone pole tekstowe bądź obszar tekstowy uŝytkownik moŝe w nie kliknąć i wprowadzić tekst. Podczas wprowadzania tekstu okno jest uznane za aktywne. Zdarzenie onfocus oznacza, Ŝe określone pole tekstowe zostało kliknięte i jest gotowe do wprowadzania tekstu. Zdarzenie onblur oznacza, Ŝe pole zostało zaznaczone, a następnie np. poprzez przejście uŝytkownika do innego elementu odznaczone. Zdarzenie onchange sprawdza czy pole było zaznaczone czy odznaczone. Zdarzenia onblur i onfocus obsługiwane są równieŝ dla przycisków. Zdarzenia onreset i onsubmit są wywoływane w momencie gdy są naciśnięte odpowiednio przyciski Reset lub Submit. Zdarzenie onreset powoduje wyczyszczenie zawartości formularza, zdarzenie onsubmit powoduje wysłanie do serwera wartości znajdujących się w formularzu Zdarzenia strony, okna i obrazu. Ta kategoria skupia zdarzenia, które są ubocznym efektem działań uŝytkownika. NaleŜą do nich: onabort zdarzenie to zachodzi w przypadku gdy ładowanie obrazu jest przerwane, onerror zachodzi w przypadku wystąpienia błędu podczas ładowania obrazu lub innego dokumentu, onload zachodzi w momencie zakończenia ładowania się strony bądź obrazu, onresize zachodzi w przypadku zmiany rozmiaru strony lub ramki, onunload zachodzi w momencie gdy uŝytkownik opuszcza stronę. Obsługa tych zdarzeń zachodzi podczas zmian, które występują w przypadku zdarzeń nie kontrolowanych bezpośrednio przez uŝytkownika. 2.3 Formularze W wielu serwisach internetowych formularze stanowią kluczowy element komunikacji z uŝytkownikiem. Formularze umoŝliwiają między innymi załoŝenie konta, dokonanie zakupów, rezerwację biletów, wyszukanie informacji. Wobec tego 13

14 projektant musi zadbać, aby wypełnianie formularzy nie stanowiło bariery pomiędzy uŝytkownikiem i aplikacją Projektowanie defensywne Projektowanie defensywne [Linderman, 2005] nazywane równieŝ projektowaniem ubezpieczonym jest odpowiedzią na niedoskonałe witryny internetowe. NiezaleŜnie od tego jak dobrze zaprojektowana będzie witryna klienci i tak mogą mieć z nią problemy. Celem projektowania defensywnego jest opracowanie efektywnych strategii awaryjnych, które pomagają zapobiegać błędom, a jeśli juŝ takowe wystąpią wspierają uŝytkownika. Projektowanie ubezpieczone w szczególności odnosi się do formularzy. Oto lista zaleceń projektowania defensywnego odnośnie formularzy: OdróŜnienie pól opcjonalnych od obowiązkowych. Najpopularniejsze techniki słuŝące do odróŝnienia tych pól, to: o Umieszczenie symbolu, zwykle jest to gwiazdka, obok wymaganego pola, o Opisanie pól słowem Opcjonalne lub Wymagane, o WyróŜnienie tytułów pól obowiązkowych poprzez pogrubienie czy uŝycie innego koloru. Zaleca się aby maksymalnie zmniejszyć liczbę pól obowiązkowych. Dostępność powszechnie stosowanych formatów danych. Istnieją pewne rodzaje danych w przypadku, których uŝywa się równolegle kilku formatów ich zapisywania, są to np. numery telefonów, daty, numery kart kredytowych. W przypadku numerów telefonów moŝna je zapisywać z odstępami, uŝywać spacji albo kresek, moŝna zapisywać bez Ŝadnych odstępów, zdarza się, Ŝe numery kierunkowe ujmuje się w nawiasy. Zaleca się by w takich przypadkach dopuszczać wykorzystywanie wszystkich popularnych formatów. Ograniczenie zakresu wartości podawanych w polu formularza. Zaleca się, aby tam gdzie to moŝliwe ograniczyć wybór uŝytkownika do ściśle określonego zestawu właściwych opcji. Dobrym rozwiązaniem jest stosowanie: menu rozwijanego, pól list, pól wyboru, przycisków opcji. Takie ograniczenie wyborów uŝytkownika zapobiega nadmiernemu popełnianiu błędów. Podanie przykładów poprawnego formatowania. Jeśli aplikacja nie ogranicza wyborów uŝytkownika naleŝy w wyraźny sposób poinformować go jakie 14

15 formaty danych, czy jakie wartości są dopuszczalne. Sam układ formularza moŝe równieŝ być tak zaprojektowany aby sugerować jaki format jest oczekiwany. Ograniczenie liczby znaków. To rozwiązanie dotyczy głównie pól tekstowych. NaleŜy zawczasu poinformować uŝytkownika ile znaków moŝe uŝyć. UŜytkownicy cenią sobie moŝliwość zaplanowania tekstu przed wpisaniem. MoŜna równieŝ nie dopuścić do przekroczenia maksymalnej liczby znaków, uŝywając atrybutu maxlenght pola tekstowego. To drugie zalecenie odnosi się bardziej do pól gdzie z góry wiadomo ile znaków ma być wpisane. Przykładem moŝe być numer PESEL, czy kod pocztowy dla danego kraju. Sprawdzanie poprawności danych. Dobrym zwyczajem jest sprawdzanie poprawności danych juŝ na etapie wpisywania ich, zanim uŝytkownik zatwierdzi cały formularz. Warto na przykład sprawdzić czy wpisany adres zawiera czy zgadza się liczba znaków albo czy dane podane są w dopuszczalnym formacie. Często do tego celu wykorzystuje się skrypty JavaScript jako preprocesora zapewniającego, Ŝe do serwera nie trafią niepoprawne dane. Przycisk Reset, zwykle jest to przycisk z etykietą Anuluj, Wyczyść. Zaleca się aby nie stosować przycisków słuŝących do czyszczenia całej zawartości formularza. W przypadku gdy jednak taka opcja istnieje warto umoŝliwić uŝytkownikowi dodatkowe potwierdzenie tej decyzji. Przycisk Submit przycisk z etykietą Wyślij, Zatwierdź lub OK. W wielu witrynach kilkakrotne naciśnięcie przycisku zatwierdzającego formularz powoduje wysłanie kilku identycznych zestawów danych. Po pierwsze obciąŝa to serwer i cała operacja trwa dłuŝej, po drugie umoŝliwia dokonanie tej samej akcji kilka razy. Dlatego zaleca się natychmiastowe blokowanie przycisku Submit zaraz po pierwszym jego uŝyciu. Dobrze jest równieŝ w tym momencie poinformować uŝytkownika, Ŝe wpisane przez niego dane są właśnie przetwarzane. Zachowanie wpisywanych danych. Często zdarza się, Ŝe uŝytkownik zaniechał dokończenia wypełniania formularza, nie oznacza to jednak, Ŝe juŝ nigdy do niego nie wróci. Przerwanie wypełniania moŝe być spowodowane chwilowym brakiem połączenia lub zawieszeniem się przeglądarki. Warto 15

16 automatycznie na bieŝąco zapamiętywać wpisywane dane albo umoŝliwić taką opcję uŝytkownikowi. Jeśli aplikacja umoŝliwia zapisywanie danych, uŝytkownik powinien być o tym poinformowany, a takŝe powinien uzyskać wskazówki jak w łatwy sposób powrócić do rozpoczętego formularza Interaktywne elementy formularza Formularz sam w sobie jest pewną uporządkowaną strukturą w skład, której wchodzą elementy umoŝliwiające interakcję. PoniŜej przedstawiono najwaŝniejsze elementy znacznika <form>, jakim jest oznaczany formularz w HTML-u. Elementy wprowadzania tekstu Najbardziej elastycznym interaktywnym elementem strony WWW jest element wprowadzania tekstu. HTML zawiera pięć typów wejścia tekstowego [Sanders, 2002]. Pole tekstowe oznaczone znacznikiem <input type=text> umoŝliwia wprowadzanie tekstu. Znacznik ten posiada cztery waŝne atrybuty: name, size, maxlength, value. Atrybut name jest najwaŝniejszy przy identyfikacji elementu, a takŝe jako zmienna name dla skryptów serwerowych. Atrybut size dotyczy rozmiaru pola i jego wartość domyślna wynosi 20, moŝna ją zmienić w zaleŝności od potrzeb. Kolejnym atrybutem, który równieŝ jest związany z rozmiarem pola jest maxlength, umoŝliwia on ograniczenie dopuszczalnej liczby znaków. Jeśli wartość maxlength będzie ustawiona na 6, uŝytkownik nie będzie wstanie wpisać tam więcej niŝ 6 znaków. Istnieje jeszcze atrybut value, umoŝliwiający wprowadzenie domyślnego tekstu do pola tekstowego, jako podpowiedzi dla uŝytkownika. Okno tekstowe oznaczone znacznikiem <textarea></textarea> moŝe słuŝyć zarówno jako wejście, jak i wyjście dla danych. Główne atrybuty kontenera textarea róŝnią się nieco od atrybutów pola tekstowego. Dochodzą dwa dodatkowe atrybuty definiujące szerokość i wysokość, są to odpowiednio: cols i rows. Ukryte pola tekstowe oznaczone znacznikiem <input type=hidden> wykorzystywane są do przesyłania informacji pomiędzy róŝnymi stronami w zestawie ramek. Ukrytych pól tekstowych uŝywa się często w systemach 16

17 nawigacji, w których jedna strona steruje przemieszczaniem innych stron. Informacje dotyczące połoŝenia umieszcza się na stronach, którymi się steruje w ukrytym elemencie formularza, dzięki czemu Ŝaden widoczny element nie zakłóca projektu. Znajdowanie plików. Element plikowy file umoŝliwia przeglądanie plików na dyskach lokalnych. Zapisanie znacznika <input type=file> powoduje, Ŝe HTML tworzy przycisk Browse (Przeglądaj) oraz pole tekstowe. Kliknięcie tego przycisku powoduje otwarcie okna dialogowego Open (Otwórz), pozwalając wybrać pliki z własnego komputera. UŜycie elementu file umoŝliwia przeglądanie i ładowanie plików, a przy pomocy CGI równieŝ przesłanie pliku z komputera do serwera. Typ password. Ostatnim typem formularza wprowadzania tekstu jest formularz hasła. Działa on tak jak pole tekstowe, ale podczas wpisywania hasła nie pojawiają się na ekranie Ŝadne znaki alfanumeryczne. Przyciski Obiektami umoŝliwiającymi interakcję i jednocześnie będącymi elementami formularza są przyciski. Często stosuje się je niezaleŝnie do wywoływania funkcji, przez co zapomina się, Ŝe są one elementami znacznika <form>. Do najwaŝniejszych atrybutów typowego przycisku zalicza się : name nazwa, value wartość oraz zdarzenia myszy. Zdarzenia myszy związane z przyciskami: onclick, ondblclick, onmousedown, onmouseup, onmousemove, onmouseout, onmouseover, onfocus, onblur. 17

18 Dwa ostatnie zdarzenia zwykle są kojarzone z wejściem tekstowym, ale obie funkcje obsługi zdarzeń działają równieŝ z przyciskami. NajwaŜniejsze w działaniu przycisku jest to, Ŝe moŝe wywołać zdarzenie uruchamiające funkcję. Przycisk Reset oznaczony znacznikiem <input type=reset> słuŝy do oczyszczania formularzy. Oprócz wbudowanej funkcji czyszczenia formularzy posiada on takie same atrybuty jak inne przyciski. Przy okazji czyszczenia formularza moŝna za pomocą przycisku Reset uruchomić inną funkcję. Przycisk Submit słuŝy do wywoływania skryptów uruchamianych po stronie serwera. Za pomocą przycisku Submit moŝna uruchomić równoczesne zdarzenie ze znacznika <form>. Mechanizm ten często słuŝy do sprawdzania poprawności danych wpisanych do formularza zanim zostaną wysłane do bazy danych na serwerze. Przyciski przełączników (ang. radio button) i pól wyboru (ang. check box) mogą być rozpoznane jako zaznaczone lub niezaznaczone. W przypadku przełączników moŝe zostać zaznaczony tylko pojedynczy przycisk z listy o tej samej nazwie. Gdy uŝytkownik spróbuje zaznaczyć więcej pól wcześniej zaznaczony samoczynnie wyłączy się do połoŝenia niezaznaczonego. Pola wyboru charakteryzuje moŝliwość wielokrotnego wyboru. KaŜdy przycisk ma trzy podstawowe atrybuty: name, value, checked. Aby przycisk był uŝyteczny naleŝy jednocześnie podać atrybuty name i value. Atrybut checked jest opcjonalny i przyjmuje wartości boolowskie true lub false. Zarówno obiekt checkedbox jak i radio mogą słuŝyć do uruchamiania funkcji JavaScript. Do znacznika checkedbox lub radio moŝna dodać funkcję obsługi zdarzeń onclick. Menu rozwijane Ostatnim typem elementu formularzy jest menu rozwijane. W HTML-u element menu jest zbudowany w oparciu o trzy znaczniki: <select>, <select multiple>, <option>. Kontenery <select> i <select multiple> mogą zawierać dowolną liczbę opcji. Znaczniki <select> i <select multiple> działają analogicznie jak przyciski przełączników i pola wyborów. Jeśli uŝytkownik musi dokonać pojedynczego wyboru stosuje się <select>, jeśli moŝe dokonać wielokrotnego wyboru stosuje się <select multiple>. 18

19 NaleŜy pamiętać, Ŝe opisane powyŝej elementy formularza nie zawsze muszą tworzyć strukturę, kojarzącą się z kwestionariuszem. Często uŝywane są one niezaleŝnie w róŝnych miejscach witryny, ale w poprawnym składniowo języku XHTML są elementami znacznika <form>. Zawsze ich rolą jest umoŝliwienie interakcji uŝytkownika. 2.4 Układ strony Układ strony powinien juŝ na pierwszy rzut oka informować co jest najwaŝniejsze na stronie, w jaki sposób poszczególne elementy są ze sobą powiązane. Takie podejście umoŝliwia efektywną komunikację poprzez narzucenie uŝytkownikowi wizualnej hierarchii projektu. Istnieje kilka uniwersalnych zasad, które pozwalają taką hierarchię stworzyć [Williams, 2004]. Zasada bliskości mówi o tym, Ŝe jeśli jakieś elementy na stronie, są blisko siebie, sprawiają wraŝenie, Ŝe są ze sobą związane i dotyczą tego samego. Dlatego na przykład nagłówki powinny znajdować się jak najbliŝej tekstu, do którego się odnoszą, podobnie podpisy pod obrazkami. Zasada kontrastu. Zadaniem kontrastu jest zaznaczenie róŝnicy między elementami. Kontrast zawsze buduje się na tej samej zasadzie zestawieniu tych samych parametrów o róŝnych wartościach. Kontrast moŝe dotyczyć kolorów, rozmiaru fontu, krojów pisma. Szczególnie waŝne jest aby zachować odpowiedni kontrast pomiędzy tłem a tekstem. Zasada mówiąca, Ŝe najlepiej się prezentuje ciemny tekst na jasnym tle dotyczy głównie tekstu ciągłego, poniewaŝ ułatwia to czytanie. Nagłówki kontrastują rozmiarem z tekstem, którego dotyczą. Kontrast moŝna uzyskać stosując róŝne kroje czcionek. Często stosuje się kontrastu w celu odróŝnienia stanu odsyłaczy. Wyrównanie. WyróŜniamy cztery rodzaje wyrównania: do lewej, do prawej, do środka i w przypadku tekstu justowanie, czyli wyrównanie do obu stron. Wyrównanie na stronie dotyczy zarówno tekstu jak i grafiki. W przypadku tekstu w sieci nie zaleca się justowania, gdyŝ przeglądarki róŝnie interpretują ten zabieg, co moŝe doprowadzić do dziwnych efektów, na przykład duŝych przerw między wyrazami. Wyrównując elementy na stronie naleŝy zachować konsekwencję, najlepiej stosować jeden styl wyrównania, ewentualnie dodać drugi styl dla kontrastu albo 19

20 urozmaicenia. Elementy na stronie nie mogą sprawiać wraŝenia, Ŝe zostały poukładane w przypadkowy sposób. Powtórzenia dotyczą konsekwencji w stosowaniu rozwiązań. Strony wchodzące w skład serwisu muszą być zaprojektowane spójnie. NaleŜy zadbać o to, aby rozmieszczenie elementów na stronie, umiejscowienie systemu nawigacyjnego, kolory, rodzaje czcionki były stosowane konsekwentnie. Spójność ta moŝe być zachowana częściowo przez powtórzenia. Powtórzenia łączą elementy, których nie wiąŝe bezpośrednia bliskość. Nawigacja w tym samym miejscu na kaŝdej stronie serwisu, stosowanie logo firmy, te same czcionki w kilku elementach, sprawia, Ŝe są one powiązane spójnym projektem. 2.5 Typografia Typografia internetowa jest dziedziną młodą czerpiącą z tajników tradycyjnej typografii. O typografii mówi się, Ŝe jest sztuką tworzenia łatwego w odbiorze przekazu wzrokowego. Dobrze opracowany projekt pod względem typograficznym charakteryzuje się funkcjonalnością, czytelnością i estetyką. Typografowie wyróŝniają dwa funkcjonalne aspekty tekstu ciągłego: odróŝnialność i czytelność [ Są one związane z róŝnym poziomem podejścia do tekstu: do szczegółu i do całości. OdróŜnialność odnosi się do pojedynczego znaku, do identyfikacji i odkodowania jego znaczenia. Czytelność jest związana z całym tekstem, jest to łatwość czytania, która moŝe być mierzona czasem, jaki czytelnik jest w stanie czytać tekst nie męcząc się, komfortowo i bez wysiłku lub wraŝeniem przystępności tekstu. Podstawowe pojęcia z zakresu typografii: Czcionka jest rodzajem nośnika pojedynczych znaków pisma drukarskiego. Czcionka posiada zestaw trzech parametrów: krój pisma, stopień pisma i odmiana pisma. Jedna czcionka to zestaw znaków o tych samych parametrach. Krój pisma określa charakterystyczny wygląd i unikalność kaŝdej rodziny czcionek. Stanowi o konkretnym, rozpoznawalnym wyglądzie niezaleŝnie od wielkości 20

21 znaków, czy ich atrybucie pogrubienia, pochylenia, szerokości itp. Kroje pisma klasyfikuje się ze względu na wygląd. Kroje dzieli się na jedno- i dwuelementowe, szeryfowe i bezszeryfowe oraz stałe i proporcjonalne. NaleŜy zaznaczyć, Ŝe jeden krój pisma moŝe być jednocześnie sklasyfikowany jako np. bezszeryfowy i proporcjonalny. Kroje jedno- i dwuelementowe Poszczególne znaki pisarskie zbudowane są z kresek. Kroje jednoelementowe charakteryzują się tym, Ŝe wszystkie znaki pisarskie zbudowane są z kresek tej samej grubości. W przypadku krojów dwuelementowych kreski stanowiące znaki róŝnią się grubością. Kreski poziome mogą róŝnić się grubością od kresek pionowych, albo grubość kresek moŝe zmieniać się płynnie. Szeryfowe i bezszeryfowe Pismo szeryfowe charakteryzuje się tym, Ŝe znaki posiadają szeryfy, czyli krótkie kreski pełniące rolę ozdobników. Najczęściej są to poziome kreski będące stopkami liter, ale mogą występować równieŝ w innych miejscach znaków, stosowane są konsekwentnie we wszystkich znakach danego fontu. Najpopularniejszym krojem szeryfowym jest Times New Roman. Pismo bezszeryfowe nie posiada szeryfów. Odnośnie szeryfów przyjęło się, Ŝe łatwiej czyta się tekst wydrukowany krojem szeryfowym. Tekst na ekranie lepiej czyta się wyświetlony krojem bezszeryfowym. Stałe i proporcjonalne Kroje stałe zwane równieŝ pismem maszynowym są rzadko stosowane, zwykle gdy zaleŝy nam, Ŝeby ilość znaków w kaŝdym wierszu była ta sama, a znaki w pionie układały się w kolumnę. Tekst ciągły wygląda brzydko, poniewaŝ odstępy pomiędzy znakami są róŝne, zbyt małe lub za duŝe. Najpopularniejszym krojem stałym jest krój Courier New. Kroje proporcjonalne uwzględniają szerokość znaków. Odległości między środkami sąsiednich znaków zmieniają się proporcjonalnie, co powoduje, Ŝe w skali całego tekstu wyglądają identycznie, a wyrazy wyglądają naturalnie. 21

22 Stopień pisma jest to odległość między górną a dolną linią pisma i wyraŝana jest w punktach typograficznych. Odmiana nie jest cechą bezpośrednio fontu, tylko jego kroju. Odmiana jest modyfikacją kroju danego fontu poprzez zmianę grubości jego kresek oraz zmianę szerokości i pochylenia całych znaków. Co nie zmienia faktu, Ŝe font zachowuje swoje główne cechy danego kroju pisma. Font jest elektronicznym nośnikiem pisma. Często w języku potocznym uŝywa się terminu czcionka komputerowa. Font tak samo jak czcionka charakteryzuje się krojem, stopniem i odmianą pisma. Zalecenia typograficzne dotyczące publikacji internetowych [Williams, 2004]: czcionka nie moŝe być za duŝa, nie większa niŝ 14 punktów dla zwykłego tekstu, nie moŝe być teŝ za mała, nie mniejsza niŝ 10 punktów dla zwykłego tekstu, nie naleŝy formatować większych partii tekstu pogrubieniem lub kursywą, nie naleŝy stosować podwójnych wyróŝnień, naleŝy unikać bardzo długich linii tekstu, długość wiersza nie powinna przekraczać 60 znaków, łącznie ze spacjami, nie powinno się stosować więcej niŝ dwóch rodzajów jak i dwóch wielkości fontów, wielkość fontu uŝytego do tytułów naleŝy stosować konsekwentnie w obrębie całego tekstu, naleŝy się upewnić, Ŝe między tekstem a tłem jest wystarczający kontrast, podkreślenia naleŝy stosować tylko do odnośników. 2.6 Kolorystyka strony UŜycie barw w projektowaniu interfejsu ma duŝy wpływ na interakcję uŝytkownika z aplikacją. Często projektanci nie zdają sobie sprawy, Ŝe barwy to nie 22

23 tylko wraŝenie estetyczne, ale równieŝ konkretne emocje i skojarzenia. Dlatego warto zapoznać się z podstawami teorii kolorów oraz sposobami ich dobierania, aby uzyskać poŝądany efekt Teoria koloru Mówiąc o zasadach doboru kolorów w serwisach internetowych naleŝy zapoznać się z podstawowymi pojęciami z teorii koloru. Kolor w języku potocznym jest synonimem barwy. Jest to zaleŝna od długości fali cecha charakterystyczna światła odbitego lub emitowanego przez ciało. Światło, docierające do ludzkiego oka, jest bądź odbite od przedmiotów, bądź emitowane przez gorące lub świecące przedmioty [Encyklopedia fizyki, 1997]. Rysunek Widzialne spektrum elektromagnetyczne [Źródło: Koło barw jest graficznym modelem poglądowym słuŝącym do objaśniania zasad mieszania się i powstawania barw. Wokół środka koła zgodnie z kierunkiem ruchu wskazówek zegara wyrysowano widmo ciągłe światła białego w ten sposób, Ŝe barwa fioletowa, płynnie przechodzi w barwę czerwoną. W ten sposób widmo zostaje połączone w zamknięty cykl zmian. Barwy znajdujące się po przeciwnych stronach środka koła nazywane są barwami dopełniającymi. Takie barwy nałoŝone w syntezie addytywnej dają barwę białą, a w syntezie subtraktywnej barwę czarną, zmieszane dają neutralną szarość. 23

24 Rysunek Koło barw [Źródło: Synteza addytywna jest to mieszanie kolorów światła emitowanego. Odbiorniki telewizyjne oraz monitory komputerowe tworzą obraz poprzez emitowanie światła czerwonego, zielonego i niebieskiego. Stąd nazwa modelu kolorów RGB (Red czerwony, Green zielony, Blue - niebieski). Rysunek Model RGB addytywne mieszanie kolorów w monitorze [Źródło: ] Synteza subtraktywna jest to mieszanie kolorów światła odbitego. Przykładem modelu odbitych kolorów jest model CMYK, jako barwy podstawowe wykorzystywane cyjan (ang. Cyan) odcień koloru niebieskiego, magenta (ang. Magenta) kolor podobny do czerwonego, Ŝółty (ang. Yellow), czarny (ang. Black). Model CMYK wykorzystywany jest w druku kolorowym. Rysunek Model CMY subtraktywne mieszanie barw w druku [Źródło: 24

25 2.6.2 Zasady harmonii barwnej W celu zaprojektowania palety barw dla interfejsu w zaleŝności od jego tematyki i przeznaczenia moŝna posłuŝyć się zasadami harmonii barwnej dotyczącymi sposobu dobierania kolorów. Kolory analogiczne są to kolory leŝące po obu stronach danego koloru na kole barw. Zastosowanie kolorów analogicznych daje poczucie harmonii, gdyŝ często jest to zestaw barw występujących w naturze. Rysunek Kolory analogiczne [Źródło: Kolory komplementarne leŝą na przeciwko siebie na kole barw. Często uŝywa się koloru komplementarnego jako koloru wyróŝniającego. Rysunek Kolory komplementarne [Źródło: Kolory komplementarne rozszczepione są to kolory analogiczne do koloru komplementarnego danej barwy. Przy projektowaniu wybór takiej palety kolorów daje efekt kontrastu, ale nie aŝ tak duŝego jak w przypadku kolorów komplementarnych. 25

26 Rysunek Kolory komplementarne rozszczepione [Źródło: ] Triada kolorów są to trzy kolory, które na kole barw leŝą w jednakowej odległości od siebie. UŜycie takiego zestawu daje kolorowy i jednocześnie wywaŝony obraz. Rysunek Triada kolorów [Źródło: ] Monochromatyczność polega na wybraniu jednego koloru i posługiwaniu się nim w obrębie całego serwisu, wykorzystując jego róŝne stopnie nasycenia jasności. Rysunek Monochromatyczność [Źródło: ] Skala szarości jest odmianą monochromatyczności polega na wybraniu tylko kolorów neutralnych począwszy od białego do czarnego. Rysunek Skala szarości [Źródło: ] 26

27 Paleta barw ustalona dla interfejsu uŝytkownika powinna określać [ owaniu_interfejsu_uzytkownika.pdf]: Barwy przewodnie, są to barwy charakterystyczne dla danego serwisu, najczęściej zgodne z motywem graficznym czy z logo serwisu, Barwę tła, ma duŝy wpływ na ogólny charakter wizualny i emocje wywoływane u uŝytkownika, Barwę tekstu, najwaŝniejsze aby zapewnić kontrast z tłem, co wpływa na czytelność, Barwę pasków przewijania tekstu, nie moŝna dopuścić, aby ten element interfejsu wtapiał się w otoczenie ramki tekstowej, gdyŝ uŝytkownik moŝe się w ogóle nie zorientować, Ŝe moŝe przewijać tekst, Barwy nagłówków, mogą się róŝnić od barwy tekstu, którego dotyczą w celu zwrócenia uwagi, Barwy odnośników i elementów menu, zestaw barw dla odnośników odwiedzonych, nie odwiedzonych i aktywnych powinien być taki sam na wszystkich podstronach serwisu. Pomocne jest równieŝ ustalenie barwy dla aktywnego elementu menu, gdyŝ pomaga to w orientacji w przestrzeni serwisu. 27

28 3 OBSŁUGA INTERAKCJI UśYTKOWNIKA Z APLIKACJĄ Kluczowym elementem aplikacji webowej jest sprawnie działająca komunikacja typu klient serwer. Obsługa zdarzeń wywołanych przez uŝytkownika musi przebiegać w sposób jak najbardziej dla niego niezauwaŝalny. Dotychczas komunikacja była istotna przede wszystkim dla programistów tworzących rozwiązania po stronie serwerów. Obecnie programiści tworzący aplikacje klienckie, jeśli chcą tworzyć rozwiązania typu AJAX równieŝ muszą zapoznać się z podstawami działania komunikacji klient-serwer. W niniejszym rozdziale zostały opisane podstawy działania protokołu HTTP. Przedstawiono równieŝ techniki umoŝliwiające przesyłanie informacji między klientem a serwerem 3.1 Podstawy działania protokołu HTTP HTTP (ang. Hyper Text Transfer Protocol) jest protokołem uŝywanym do przesyłania stron internetowych, obrazów i innych typów plików do przeglądarki i z powrotem. Protokół HTTP składa się z dwóch elementów: Ŝądania i odpowiedzi. śądanie jest wysyłane przez przeglądarkę po wpisaniu przez uŝytkownika adresu URL. Po odebraniu Ŝądania serwer wysyła odpowiedź do przeglądarki. Zadaniem przeglądarki jest interpretacja odpowiedzi i wyświetlenie strony WWW lub innego zasobu. W tabeli przedstawiono składnię Ŝądania i odpowiedzi HTTP. Tabela Składnia Ŝądania i odpowiedzi HTTP śądanie <wiersz Ŝądania> <nagłówki> <pusty wiersz> <ciało Ŝądania> Odpowiedź <wiersz statusu> <nagłówki> <pusty wiersz> <ciało odpowiedzi> Pierwszy wiersz Ŝądania HTTP zawiera nazwę metody określającej typ Ŝądania, URL zasobu, którego ono dotyczy oraz wersję protokołu HTTP. Po wierszu Ŝądania następuje sekcja nagłówków, które zawierają dodatkowe informacje. Za nagłówkami 28

29 zawsze musi znajdować się pusty wiersz, po którym mogą następować dodatkowe dane zwane ciałem Ŝądania. Format odpowiedzi jest bardzo podobny do formatu Ŝądania. Istotna róŝnica polega na tym, Ŝe pierwszy wiersz zawiera informacje o statusie, a nie o Ŝądaniu. Wiersz statusu rozpoczyna się od potwierdzenia zastosowanego protokołu HTTP, kodu odpowiedzi oraz frazy przyczyny. Następnie podobnie jak w przypadku Ŝądania występuje sekcja nagłówków, po którym następuje pusty wiersz. Ciało odpowiedzi zawiera kod źródłowy HTML Ŝądanego zasobu lub w przypadku innych typów zasobów moŝe zawierać zwykły tekst lub dane binarne. Dane te następnie prezentowane są uŝytkownikowi przez przeglądarkę Metody HTTP Metodami HTTP nazywane są polecenia, na które odpowiada serwer WWW. Dokument RFC dotyczący protokołu HTTP opisuje osiem standardowych metod: HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT. Podczas projektowania aplikacji internetowych najczęściej korzysta się z metod GET i POST. W tabeli przedstawiono metody HTTP wraz z ich krótkimi charakterystykami. 29

30 Tabela Metody HTTP [Źródło: Wells, 2008] Polecenie HEAD GET POST PUT DELETE TRACE OPTIONS CONNECT Opis Polecenie szczególnie przydatne do pobierania metadanych zapisanych w nagłówkach odpowiedzi. śądanie prosi o przekazanie dokładnie takiej samej odpowiedzi, jaka zostałaby wygenerowana po otrzymaniu metody GET, ale bez samego dokumentu jedynie metainformacje. Jest to najbardziej popularna i najczęściej uŝywana metoda protokołu HTTP. Stanowi podstawową prośbę zwrócenia zasobu dostępnego na serwerze. Jest poleceniem, w którym przesyłane są dane od uŝytkowników do serwera. Adres URL wskazuje na odbiorcę danych (program, baza danych, bramka do innego protokołu). Przekazuje dane na serwer pod adres wskazany przez URL. Polecenie wymaga sprawdzenia poprawności danych. Usuwa z serwera wskazany zasób. Metoda rzadko implementowana. Zwraca odebrane Ŝądanie, dzięki czemu klient moŝe sprawdzić, w jaki sposób pośrednie serwery zmodyfikowały Ŝądanie. Polecenie to jest przydatne do wykrywania serwerów pośredniczących (ang. proxy) oraz innych serwerów biorących udział w przekazywaniu Ŝądania do jego miejsca docelowego. Zwraca informacje o metodach HTTP obsługiwanych przez serwer. Metoda ta jest uŝywana do sprawdzania funkcjonalności serwera WWW. Metoda uŝywana do współpracy z serwerami pośredniczącymi, które są w stanie nawiązać połączenia SSL Wersje protokołu HTTP Wiersz Ŝądania jak i wiersz odpowiedzi zawiera informację o wersji protokołu HTTP. Powszechnie wykorzystywany jest protokół w wersji 1.1 oraz Nagłówki HTTP Zarówno Ŝądanie jak i odpowiedź posiadają wiersze zwane nagłówkami HTTP. Nagłówki są metadanymi, które uwydatniają znaczenie Ŝądań i odpowiedzi HTTP. Na ich podstawie klient bądź serwer moŝe zdecydować, Ŝe fragment danych będzie interesujący dla strony odbierającej komunikat. Specyfikacja protokołu HTTP określa 30

31 kilka róŝnych rodzajów nagłówków: nagłówki ogólne, nagłówki Ŝądania, nagłówki odpowiedzi, nagłówki zasobu oraz nagłówki zawartości. Nagłówki ogólne mogą znaleźć się zarówno w Ŝądaniach, jak i odpowiedziach. UŜywane są do precyzyjnego opisania komunikatu oraz oczekiwań klienta bądź serwera. Nagłówki zaliczane do tej kategorii przedstawiono w tabeli Tabela Nagłówki ogólne HTTP [Źródło: Wells, 2008] Nagłówek Connection Date Mime Version Trailer Transfer Encoding Upgrade Via Cache Control Pragma Opis Pozwala, by klient i serwer określały opcje połączenia. Znacznik czasu określający czas wygenerowania komunikatu. Wersja MIME oczekiwana przez klienta. Zawiera zbiór nagłówków identyfikujących komunikat, który zawiera jedynie fragment całości przesyłanej odpowiedzi. Określa sposób kodowania zastosowany w danym komunikacie. Określa nową wersję protokołu, której chciałby uŝywać nadawca komunikatu. Zawiera listę pośredników biorących udział w przesyłaniu komunikatu. UŜywany do przekazywania poleceń związanych z przechowywaniem zasobów w pamięci podręcznej. Inny sposób przekazywania poleceń związanych z przechowywaniem zasobów w pamięci podręcznej. Nagłówki Ŝądania, mają jedynie sens w kontekście Ŝądania HTTP. Pola nagłówków Ŝądania pozwalają klientowi przekazywać na serwer metainformacje dotyczące Ŝądania oraz samego klienta. Informacje te są przyjmowane przez serwer w postaci oryginalnej bez poddawania ich jakiejkolwiek weryfikacji poprawności. Nic nie gwarantuje, Ŝe przesłane informacje są prawdziwe. Aplikacje działające po stronie serwera powinny uwierzytelnić klienta i zweryfikować poprawność przesyłanych przez niego informacji. Serwer nie jest zobowiązany do udzielania odpowiedzi na jakiekolwiek nagłówki Ŝądania, gdyŝ nie są one obowiązkowe. Jedynie wersja 1.1 protokołu HTTP wymaga nagłówka Host, w przeciwieństwie do starszej wersji 1.0. Typowe nagłówki Ŝądań HTTP zostały przedstawione w tabeli

32 Tabela Nagłówki Ŝądania HTTP [Źródło: Wells, 2008] Nagłówek Accept Accept-Charset Accept-Encoding Accept-Language Authorization Expect From Host If-Match If-Modified-Since If-Non-Match If-Range If-Unmodified-Since Max-Forwards Proxy-Authorization Range Referrer TE User-Agent Opis Informuje serwer, Ŝe klient akceptuje podane typy mediów. Informuje serwer, Ŝe klient akceptuje podane zbiory znaków. Informuje serwer, Ŝe klient akceptuje podane sposoby kodowania. Informuje serwer, Ŝe klient preferuje podane języki. Zawiera informacje konieczne do przeprowadzenia uwierzytelnienia. Zawiera informacje dotyczące oczekiwań klienta co do serwera. Adres poczty elektronicznej uŝytkownika korzystającego z klienta. Nazwa hosta uŝytkownika korzystającego z klienta. Dokument zostanie zwrócony, tylko jeśli pasują przesłane znaczniki zasobu. śądanie zostanie zrealizowane, jeśli zasób został zmodyfikowany po podanym czasie. Dokument zostanie zwrócony, jeśli przesłane znaczniki zasobu nie pasują. Warunkowe Ŝądanie przesłania zakresu dokumentów. śądanie zostanie zrealizowane, jeśli zasób nie został zmodyfikowany po podanym czasie. Maksymalna liczba przekierowań Ŝądania. Ma to samo znaczenie co nagłówek Authorization, z tym Ŝe jest uŝywany przez serwery pośredniczące. śąda zwrócenia grupy dokumentów (jeśli taka moŝliwość jest obsługiwana). Adres URL dokumentu zawierającego Ŝądany URL. Określa jakich dodatkowych kodowań transportowych moŝna uŝyć. Nazwa aplikacji lub klienta, które wygenerowały Ŝądanie. 32

33 Nagłówki odpowiedzi dostarczają klientowi informacji o danej odpowiedzi. Klient moŝe ich w przyszłości uŝyć do generowania Ŝądań, które będą bardziej adekwatne do danego serwera. Nagłówki odpowiedzi HTTP zebrano w tabeli Tabela Nagłówki odpowiedzi HTTP [Źródło: Wells, 2008] Nagłówek Age Public Retry-After Server Title Warning Accept-Ranges Vary Proxy-Authenticate Set-Cookie Set-Cookie2 WWW-Authenticate Opis Określa wiek odpowiedzi. Zawiera listę Ŝądań HTTP obsługiwanych przez serwer. Jeśli obsłuŝenie Ŝądania jest w danej chwili niemoŝliwe, to ten nagłówek określa, kiedy klient powinien ponownie spróbować. Zawiera nazwę oraz wersję oprogramowania serwera. W przypadku dokumentów HTML zawiera tytuł podany w dokumencie. Treść ostrzeŝenia, dokładniejsza niŝ ta podana we frazie przyczyny odpowiedzi HTTP. Typy zakresów, jakie serwer jest w stanie obsługiwać. Lista innych nagłówków, które serwer analizuje, a które mogą wpływać na zawartość odpowiedzi. Lista wezwań przesyłanych do klienta przez serwer pośredniczący. UmoŜliwia podanie ciągu znaków przez klienta. Analogiczny do Set-Cookie. Lista wezwań przesyłanych do klienta przez serwer. Nagłówki zasobu zawierają bardziej szczegółowe informacje o Ŝądanym zasobie. Tabela przedstawia te nagłówki. Tabela Nagłówki zasobu HTTP [Źródło: Wells, 2008] Nagłówek Allow Location Opis Zawiera listę metod, których moŝna uŝywać. Przekazuje klientowi informację o rzeczywistej lokalizacji zasobu. 33

34 Nagłówki zawartości zawierają przydatne metadane dotyczące zawartości komunikatu HTTP. Zwykle serwery za ich pomocą przesyłają informacje dotyczące typu zawartości, jej długości, sposobu kodowania itp. Listę nagłówków zawartości przedstawiono w tabeli Tabela Nagłówki zawartości HTTP [Źródło: Wells, 2008] Nagłówek Content-Base Content-Encoding Content-Language Content-Length Content-Location Content-MD5 Content-Range Content-Type Opis Bazowy adres URL uŝywany do wyznaczania adresów względnych. Określa zastosowane sposoby kodowania treści. Język naturalny, w którym zapisano treść. Określa długość lub wielkość treści. Określa lokalizację zasobu. Suma kontrolna MD5 treści. Zakres bajtowy treści stanowiącej fragment większego zasobu. Typ treści Kody statusu W kaŝdej odpowiedzi na Ŝądanie serwer umieszcza kod statusu HTTP. Jest to kod informujący klienta lub przeglądarkę o tym, czy Ŝądanie zostało obsłuŝone prawidłowo bądź czy w celu jego obsługi konieczne jest wykonanie jakichś dodatkowych czynności. WyróŜnia się następujące typy kodów statusu: kody informacyjne, kody powodzenia, kody przekierowania, kody błędu klienta, kody błędu serwera. Kody informacyjne jest to informacja o kontynuowaniu działania po odebraniu Ŝądania. Kody informacyjne przedstawiono w tabeli Tabela Kody informacyjne 1xx [Źródło: Wells, 2008] Kod statusu Opis 100 (ang. Continue) Kontynuacja. 101 (ang. Switching Protocols) Przełączenie protokołów. 34

35 Kody powodzenia wysyłane są w przypadku gdy polecenie zostało prawidłowo odebrane, zrozumiane i zaakceptowane. Kody powodzenia zebrano w tabeli Tabela Kody powodzenia 2xx [Źródło: Wells, 2008] Kod statusu Opis 200 (ang. OK) OK. 201 (ang. Created) Utworzono. 202 (ang. Accepted) Przyjęto. 203 (ang. Non Authoritative Information) Informacja nieautoryzowana. 204 (ang. No content) Brak zawartości. 205 (ang. Reset content) Przywróć zawartość. 206 (ang. Partial Content) Część zawartości. Kody przekierowania wysyłane gdy w celu zakończenia obsługi klient musi wykonać dodatkowe czynności prezentuje tabela Tabela Kody przekierowania - 3xx [Źródło: Wells, 2008] Kod statusu Opis 300 (ang. Multiple Choices) Wiele moŝliwości. 301 (ang. Moved Permanently) Trwale przeniesiony. 302 (ang. Moved Temporarily) Przeniesiony tymczasowo (HTTP/1.0). 302 (ang. Found) Znaleziono (HTTP/1.1). 303 (ang. See Other) Patrz inne (HTTP/1.1). 304 (ang. Not Modified) Nie zmieniono. 305 (ang. Use Proxy) Zalecane uŝycie serwera pośredniczącego (wiele przeglądarek WWW, w tym Mozilla oraz Internet Explorer, nie obsługuje poprawnie odpowiedzi z tym kodem statusu). 306 Kod nie jest juŝ uŝywany, ale wciąŝ jeszcze pozostaje zarezerwowany. 307 (ang. Temporary Redirect) Przekierowanie tymczasowe. 35

36 Kody błędu klienta zebrane w tabeli wysyłane są w przypadku, gdy Ŝądanie ma złą składnię lub nie moŝna go zrealizować. Tabela Kody błędu klienta 4xx [Źródło: Wells, 2008] Kod statusu Opis 400 (ang. Bad Request) Nieprawidłowe zapytanie. 401 (ang. Unauthorized) Dostęp nieautoryzowany podobny do kodu 403 (Forbidden), lecz generowany w sytuacji, gdy uwierzytelnienie jest moŝliwe, jednak nie zakończyło się pomyślnie bądź wymagane do niego dane nie zostały podane. 402 (ang. Payment Required) Wymagana opłata. 403 (ang. Forbidden) Dostęp zabroniony. 404 (ang. Not Found) Nie znaleziono zasobu. 405 (ang. Method Not Allowed) Niedozwolona metoda. 406 (ang. Not Acceptable) Nie moŝna przyjąć Ŝądania. 407 (ang. Proxy Authentication Required) Wymagane uwierzytelnienie do serwera pośredniczącego. 408 (ang. Request Timeout) Upłynął limit czasu oczekiwania na Ŝądanie. 409 (ang. Conflict) Konflikt. 410 (ang. Gone) Zniknął (usunięto). 411 (ang. Length required) Wymagane określenie długości. 412 (ang. Precondition Failed) Warunek wstępny nie moŝe być spełniony. 413 (ang. Request Entity Too Large) Zapytanie zbyt długie. 414 (ang. Request URI Too Long) Adres URI Ŝądania zbyt długi. 415 (ang. Unsupported Media Type) Nieznany sposób Ŝądania. 416 (ang. Requested Range Not Satisfiable) Zakres bajtowy Ŝądania nie mógł zostać obsłuŝony. 417 (ang. Expectation Failed) Brak moŝliwości zwrócenia oczekiwanej wartości. 449 (ang. Retry With) Spróbuj ponownie rozszerzenie protokołu dodane przez firmę Microsoft; Ŝądanie naleŝy powtórzyć po uprzednim wykonaniu odpowiedniej operacji. 36

37 Kody błędu serwera zebrane w tabeli wysyłane są w przypadku, gdy serwerowi nie udało się wykonać poprawnego Ŝądania. Tabela Kody błędu serwera 5xx [Źródło: Wells, 2008] Kod statusu Opis 500 (ang. Internal Server Error) Wewnętrzny kod serwera. 501 (ang. Not Implemented) Nie zaimplementowano. 502 (ang. Bad Gateway) Błąd bramy. 503 (ang. Service Unavailable) Usługa niedostępna. 504 (ang. Gateway Timeout) Przekroczony limit czasu bramy. 505 (ang. HTTP Version Not Supported) Nieobsługiwana wersja protokołu HTTP. 509 (ang. Bandwidth Limit Exceeded) Przekroczony limit szerokości pasma. (Ten kod statusu, choć często stosowany przez wiele serwerów, nie jest standardem protokołu HTTP) Metody GET i POST Jak juŝ zostało wspomniane najczęściej uŝywanymi metodami protokołu HTTP są metody GET i POST. śądanie GET GET URL HTTP/1.1 Host: host.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en- US; rv:1.7.6) Gecko/ Firefox/1.0.1 Connection: Keep Alive <pusty wiersz> W przykładzie typ Ŝądania określony został jako GET. Kolejnym elementem pierwszego wiersza Ŝądania jest URL zasobu, którego to Ŝądanie dotyczy. Następnie zdefiniowana jest wersja protokołu. Drugi wiersz jest pierwszym nagłówkiem Ŝądania. Nagłówek Host jest wymagany dla wersji 1.1 protokołu HTTP, słuŝy do rozpoznawania 37

38 hosta. Kolejny nagłówek User-Agent słuŝy do identyfikacji przeglądarki. Ostatni nagłówek Connection określa tryb połączenia w tym wypadku Keep-Alive, mówi o chęci nawiązania stałego połączenia. W przypadku gdy Ŝądanie GET ma przekazać dodatkowe parametry, to muszą być one dołączone do adresu URL. Format takiego adresu wygląda następująco: URL?nazwa1=wartosc1&nazwa2=wartosc2&...&nazwaN=wartoscN Informacja ta zwana jest łańcuchem zapytania i zostaje ona dopisana w wierszu Ŝądania w poniŝszy sposób: GET URL?nazwa1=wartosc1&nazwa2=wartosc2&...&nazwaN=wartoscN HTTP/1.1 Host: host.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en- US; rv:1.7.6) Gecko/ Firefox/1.0.1 Connection: Keep Alive <pusty wiersz> śądanie POST POST URL HTTP/1.1 Host: host.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en- US; rv:1.7.6) Gecko/ Firefox/1.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 24 Connection: Keep Alive <pusty wiersz> Login=abc&password=haslo śądanie POST pozwala serwerowi na przesłanie dodatkowych informacji w ciele Ŝądania. Zwykle zawartość formularza przesyłana jest do serwera za pomocą Ŝądania POST. śądanie POST jak widać róŝni się od Ŝądania GET, posiada dodatkowe 38

39 nagłówki. Nagłówek Content-Type informuje o sposobie kodowania ciała Ŝądania. Przeglądarki kodują dane Ŝądania, uŝywając do tego celu application/x-www-formurlencoded, czyli typu MIME określającego proste kodowanie URL. Nagłówek Content-Length informuje o rozmiarze ciała Ŝądania wyraŝonym w bajtach. Po serii nagłówków występuje pusty wiersz, a po nim ciało Ŝądania. Dla większości Ŝądań POST ciało Ŝądania składa się z par nazwa=wartosc. Przykładowa odpowiedź HTTP: HTTP/ OK. Date: Sat. 14 Jun :20:59 GMT Content-Type: text/html;charset=iso Content-Length: 122 <pusty wiersz> <html> <head> <title>strona WWW</title> </head> <body> Klasyczna strona... </body> </html> Pierwszy wiesz odpowiedzi, czyli wiersz statusu zawiera potwierdzenie wersji zastosowanego protokołu HTTP, kod statusu oraz frazę przyczyny. Następnie występują nagłówki dotyczące daty i czasu wygenerowania odpowiedzi oraz nagłówki Content- Type i Content-Length mówiące o sposobie kodowania i rozmiarze ciała odpowiedzi. Ciało odpowiedzi, które następuje po pustym wierszu zawiera kod źródłowy HTML Ŝądanego zasobu. NaleŜy zwrócić uwagę, Ŝe odpowiedź nie zawiera Ŝadnych informacji dotyczących typu Ŝądania, które spowodowało jej wygenerowanie. Klient musi wiedzieć jaki typ danych powinien otrzymać dla danego Ŝądania i w jaki sposób je prezentować. 39

40 3.2 Techniki komunikacyjne Podczas serfowania uŝytkownika w sieci przeglądarka wysyła wiele Ŝądań do serwera. Początkowo wszystkie te Ŝądania były wynikiem działania uŝytkownika. Obecnie, głównie za sprawą technik AJAX, moŝliwa jest równieŝ komunikacja z serwerem w dowolnym czasie bez konieczności oczekiwania na konkretną akcję uŝytkownika. PoniŜej zostaną zaprezentowane techniki komunikacji z serwerem, zarówno te, które były stosowane juŝ od dawna, jak i te ściśle związane z nowym podejściem do projektowania interaktywnych aplikacji Technika ukrytej ramki Technika ukrytej ramki narodziła się wraz z powstaniem ramek HTML. Początkowo kaŝdą stronę traktowano jako odrębny dokument HTML. Obsługę ramek wprowadzono w wersji HTML 4.0. Od tej pory strony moŝna było dzielić na okienka, czyli tzw. ramki, do których były wczytywane róŝne dokumenty HTML w zaleŝności od interakcji uŝytkownika. Technika ukrytej ramki polega na stworzeniu zbioru ramek, w którym znajduje się ukryta ramka słuŝąca do komunikacji pomiędzy klientem a serwerem. Ukrycia ramki dokonuje się poprzez zdefiniowanie jednego z wymiarów ramki na wartość równą zeru, dzięki czemu ramka staje się niewidoczna. Pomimo tego, Ŝe w niektórych wcześniejszych wersjach przeglądarek, granice takiej ramki były widoczne technika ta bardzo szybko przyjęła się wśród programistów, a obecnie jest równieŝ wykorzystywana w aplikacjach AJAX. Komunikacja pomiędzy klientem a serwerem za pomocą techniki ukrytej ramki wymaga zastosowania czteroetapowego wzorca (rys.3.2.1). 5. Wywołanie funkcji JavaScript. Etap ten inicjowany jest zawsze przez widoczną ramkę, która stanowi interfejs uŝytkownika. UŜytkownik podejmując akcję wymagającą pobrania dodatkowych danych z serwera, wywołuje funkcję JavaScript ukrytej ramki. 6. Wysłanie Ŝądania do serwera. Efektem wywołania funkcji JavaScript jest wysłanie Ŝądania do serwera. Bardzo często wymaga to połączenia z bazą danych, dlatego konieczne jest równieŝ wykorzystanie języka programowania działającego na serwerze np. PHP. 40

41 7. Otrzymanie odpowiedzi od serwera. Odpowiedź serwera musi być kolejną stroną WWW. Strona ta oprócz danych Ŝądanych od serwera musi równieŝ zawierać kod JavaScript umoŝliwiający przekazanie tych danych do widocznej ramki. 8. Przekazanie zawartości ukrytej ramki do ramki widocznej. Zwykle odbywa się poprzez skonfigurowanie procedury obsłuŝenia zdarzenia onload na zwracanej stronie. Procedura ta wywołuje funkcję widocznej ramki po całkowitym załadowaniu strony. Sposób prezentacji danych zaleŝy od widocznej ramki. Rysunek Wzorzec techniki ukrytej ramki [Źródło: Zakas, 2007] Kolejnym rozwiązaniem komunikacji klient serwer jest uŝycie ramek iframe, które zostały wprowadzone w HTML 4.0. Ramka iframe moŝe zostać umieszczona wewnątrz strony HTML, która nie naleŝy do Ŝadnego zbioru ramek. W ten sposób kaŝda część strony moŝe stać się ramką. Właściwość ta jest jedyną istotną róŝnicą pomiędzy zwykłą ramką a ramką iframe. Technika ramki iframe moŝe być stosowana do stron, które nie powstały jako zbiór ramek. W związku z tym nadaje się do stopniowego wprowadzania nowej funkcjonalności. Istnieją dwa sposoby wykorzystania zalet iframe. Pierwszy sposób polega na osadzeniu ramki iframe wewnątrz strony i uŝyciu jej jako ukrytej ramki do wykonywania Ŝądań. Drugi sposób zastosowania ramek iframe polega na ich dynamicznym tworzeniu za pomocą JavaScript. Wykorzystanie go jest utrudnione poniewaŝ nie wszystkie przeglądarki implementują ramki iframe w ten sam sposób. 41

42 Główną zaletą stosowania techniki ukrytych ramek jest moŝliwość zarządzania historią przeglądania stron aplikacji i tym samym skorzystania przez uŝytkowników z przycisków Wstecz i Dalej przeglądarki. PoniewaŜ przeglądarka traktuje ukrytą ramkę tak samo jak kaŝdą inną, to śledzi takŝe Ŝądania wysyłane przez tę stronę. Główna strona AJAX zwykle się nie zmienia, przyciski Wstecz i Dalej dotyczą historii zmian zachodzącej w ukrytej ramce. Technika ta jest wykorzystywana na przykład przez aplikacje Gmail i Google Maps. Wadą rozwiązania wykorzystującego ukryte ramki jest to, Ŝe jego powodzenie jest całkowicie uzaleŝnione od zwrócenia odpowiedniej strony. Jeśli załadowanie odpowiedniej strony ukrytej ramki się nie powiedzie, to uŝytkownik nie otrzyma Ŝadnej informacji o problemie, a główna strona aplikacji będzie ciągle oczekiwać na wywołanie odpowiedniej funkcji JavaScript. MoŜna temu zaradzić konfigurując dłuŝszy limit czasu oczekiwania na załadowanie strony, na przykład równy pięć minut i wyświetlając odpowiedni komunikat jeśli strona nie zostanie załadowana w tym czasie Obiekt XMLHttp Obiekt XMLHttp został udostępniony przez firmę Microsoft jako wsparcie dla klienta Outlook Web Access 2000, wchodzącego w skład produktu Exchange Server. Zaimplementowano go w postaci kontrolki ActiveX, którą udostępniono w przeglądarce Internet Explorer 5.5 w 2001 roku. Obiekt XMLHttp pozwalał na wysyłanie Ŝądań HTTP ad hoc z poziomu JavaScript. Programiści uzyskali dostęp do kodów statusu oraz nagłówków HTTP i wszystkich innych danych zwracanych przez serwer. Obiekt XMLHttp umoŝliwił dostęp do serwera na poziomie kodu JavaScript niezaleŝnie od cyklu ładowania strony. Programiści związani z projektem Mozilla, dostrzegając popularność takiego rozwiązania równieŝ zaczęli pracę nad implementacją obiektu XMLHttp. Zdecydowali oni, Ŝe zamiast umoŝliwić dostęp do ActiveX, powielą najwaŝniejsze metody i właściwości obiektu XMLHttp. W ten sposób powstał obiekt o nazwie XMLHttpRequest. Obsługa obiektu XMLHttp przez dwie najwaŝniejsze przeglądarki umoŝliwiła szybki rozwój interfejsów AJAX. W przeglądarkach Opera i Safari zaimplementowano obiekt o nazwie XMLHttpRequest. 42

43 Tworzenie obiektu XMLHttp Obiekt XMLHttpRequest tworzony jest w skrypcie JavaScript. Dla przeglądarek Mozilla, Safari i Opera wystarczy następująca linia kodu: var oxmlhttp = new XMLHttpRequest(); W Internet Explorerze naleŝy uŝyć następującego kodu: var oxmlhttp = new ActiveXObject( wersja XMLHttp ); Wraz z kolejnymi edycjami biblioteki MSXML pojawiały się nowe wersje obiektu XMLHttp oferujące coraz większą stabilność i szybkość. Sygnatury kolejnych wersji: Microsoft.XMLHttp MSXML2.XMLHttp MSXML2.XMLHttp.3.0 MSXML2.XMLHttp.4.0 MSXML2.XMLHttp.5.0 Po utworzeniu obiektu XMLHttp moŝna rozpocząć wysyłanie Ŝądań HTTP z poziomu JavaScriptu. Obiekt XMLHttp udostępnia zbiór metod [Tabela 3.2.1] umoŝliwiających komunikację pomiędzy klientem a serwerem. Pierwszym krokiem po stworzeniu obiektu XMLHttp jest jego inicjalizacja, poprzez wywołanie metody open(). Metoda ta przyjmuje trzy argumenty: RequestType łańcuch znaków informujący o typie Ŝądania HTTP, zwykle jest to GET lub POST, poniewaŝ obecnie tylko te metody są obsługiwane przez wszystkie przeglądarki. URL adres URL, do którego naleŝy wysłać Ŝądanie. Async wartość logiczna informująca o tym, czy Ŝądanie ma być wykonane asynchronicznie. 43

44 Argument async jest bardzo istotny z tego względu, Ŝe steruje on sposobem w jaki Ŝądania będą wykonane przez JavaScript. Argument ten przyjmuje dwie wartość true lub false. Jeśli wartość async jest równa true, oznacza to, Ŝe Ŝądanie zostaje wysłane asynchronicznie, a wykonanie kodu JavaScript jest kontynuowane bez czekania na odpowiedź serwera. Jeśli async ma wartość false, Ŝądanie jest wysłane do serwera w sposób synchroniczny, a Javacript musi zaczekać na odpowiedź serwera zanim przejdzie do wykonywania następnych instrukcji. Aplikacje AJAX preferują zastosowanie Ŝądań asynchronicznych do pobierania danych. UŜycie Ŝądań synchronicznych ogranicza się do krótkich komunikatów przesyłanych do serwera. Tabela Metody obiektu XMLHttpRequest [Na podstawie: Wells, 2008; Zakes, 2007] Metoda abort() getallresponseheaders() getresponseheader(nazwarnagłówka) open(requesttype, URL, Async) send() setrequestheader(etyk., wartość) Opis Anuluje bieŝące Ŝądanie. Pobiera wszystkie nagłówki odpowiedzi. Pobiera nagłówek odpowiedzi. Inicjuje obiekt XMLHttpRequest Przesyła Ŝądanie na serwer. Posiada jeden argument, którym jest łańcuch znaków zawierający ciało Ŝądania. Jeśli Ŝądanie nie ma ciała np. GET, naleŝy przekazać metodzie wartość null. Dodaje lub określa wartość nagłówka Ŝądania HTTP. 44

45 W poniŝszej tabeli przedstawiono właściwości obiektu XMLHttpRequest. Tabela Właściwości obiektu XMLHttpRequest [Na podstawie: Wells, 2008; Zakas, 2007] Właściwość ReadyState Opis Za kaŝdym razem gdy readystate zmienia swoją wartość, generowane jest zdarzenie readystatechange i wywoływana procedura obsługi onreadystatechange. Obiekt statusu, przyjmuje 5 róŝnych wartości, w zaleŝności od etapów realizacji Ŝądania: responsetext responsexml Status statustext 0 niezainicjowany. Obiekt został stworzony, ale metoda open() nie została wywołana. 1 wczytywanie. Metoda open() została wywołana, ale Ŝądanie nie zostało wysłane. 2 pobrany. śądanie zostało wysłane. 3 interaktywne. Otrzymano częściową odpowiedź. 4 zakończone. Odebrano wszystkie dane i połączenie zostało zamknięte. Zwraca łańcuch znaków zawierający ciało odpowiedzi. Obiekt reprezentujący dokument XML, uŝywany tylko wtedy gdy zwracane dane mają typ text/xml. Zawiera kod statusu HTTP przesłany w odpowiedzi. Łańcuch znaków zawierający frazę przyczyny, np. OK, Not found itd. 45

46 Cykl istnienia obiektu XMLHttpRequest (rys.3.2.2): 1. UŜytkownik generuje zdarzenie, np. poprzez wciśnięcie przycisku. Zdarzenie to wywołuje kod skryptowy napisany w JavaScript, który inicjuje działanie AJAXa. 2. Kod JavaScript tworzy obiekt XMLHttpRequest. 3. Obiekt XMLHttpRequest generuje Ŝądanie HTTP kierowane do serwera, określając jednocześnie funkcję zwrotną. 4. Serwer odpowiada na Ŝądanie, zwraca informacje w postaci dokumentu XML. 5. Dane te trafiają do silnika AJAX, skrypt modyfikuje zawartość wyświetlanej strony, stosując przy tym model DOM. Rysunek Kolejność transakcji z wykorzystaniem obiektu XMLHttp [ 46

47 4 NARZĘDZIA WYKORZYSTANE DO STWORZENIA APLIKACJI Do stworzenia prezentowanej aplikacji uŝyto szeregu ogólnie dostępnych technologii. Prawidłowy ich dobór jest waŝnym elementem projektowania. Dzięki starannie dobranym narzędziom stworzono dynamiczny, umoŝliwiający szeroką interakcję z uŝytkownikiem serwis internetowy. 4.1 MySQL MySQL [Ullman, 2004] jest najpopularniejszą bazą danych typu open source oferującą doskonałą wydajność, przenośność i niezawodność. MySQL jest rozwijany przez szwedzką firmę MySQL AB, kupioną 16 stycznia 2008 przez Sun Microsystems. MySQL jest to system zarządzania relacyjnymi bazami danych. W relacyjnych bazach danych informacje rozbijane są na składowe przechowywane w tabelach. MySQL składa się z serwera (mysqld), uruchamiającego bazy i zarządzającego nimi, klienta MySQL-a (mysql) będącego interfejsem do serwera oraz z szeregu programów narzędziowych ułatwiających zarządzanie systemem. MySQL doskonale współpracuje z PHP. Połączenie tych dwóch narzędzi często wykorzystywane jest w aplikacjach internetowych. 4.2 PHP Język PHP został stworzony w 1964 roku przez Rasmusa Lerdorfa, który poszukiwał rozwiązania umoŝliwiającego śledzenie liczby osób odwiedzających stronę WWW. Początkowo nazwa PHP traktowana była jako skrót od Personal Home Page, z czasem gdy PHP stał się bardziej uŝyteczny oraz zdefiniowano nowe funkcje, jego oficjalna nazwa została zmieniona na PHP: Hypertext Preprocessor. Z definicji PHP jest to język skryptowy osadzony w kodzie HTML [ Stwierdzenie, Ŝe PHP jest osadzony w kodzie HTML, oznacza, Ŝe wyraŝenia języka PHP przeplatają się ze znacznikami HTML, co ułatwia tworzenie dynamicznych stron internetowych. Jako język skryptowy PHP reaguje jedynie na określone zdarzenia, jak zatwierdzenie danych w formularzu lub przejście pod 47

48 określony adres URL. PHP działa po stronie serwera co oznacza, Ŝe wszystkie operacje zdefiniowane w skryptach są wykonywane na serwerze. PHP cechuje przenośność, czyli moŝe pracować na większości dostępnych systemów operacyjnych w tym Windows, Macintosh i UNIX w wielu odmianach. Skrypty napisane pod kątem jednego serwera będą pracować na pozostałych bez Ŝadnych lub prawie Ŝadnych poprawek. PHP jest projektem typu open source. Bardzo waŝne jest równieŝ, Ŝe PHP oferuje integrację z niemal kaŝdym systemem baz danych. Rysunek Działanie dynamicznych aplikacji internetowych wykorzystujących PHP i MySQL [Źródło: Google Maps API API (ang. Application Programming Interface), czyli interfejs programowania aplikacji [Wells, 2008]. Jest to zbiór funkcji, które są udostępniane przez jedną aplikację innej aplikacji, dzięki czemu mogą się one wzajemnie komunikować. Jedna aplikacja moŝe korzystać z moŝliwości funkcjonalnych innej aplikacji. RóŜnego rodzaju API mają ogromny wpływ na rozwój sieci, dzięki moŝliwości dostępu do usług świadczonych przez róŝne witryny rozsiane po całym świecie. Google Maps jest jednym z serwisów firmy Google, uwaŝanym za pierwszą prawdziwą aplikację Web 2.0, jej powstanie ogłoszono na blogu internetowym 25 marca 2005 roku [Wells, 2008]. Zaplecze Google Maps stanowi baza zawierająca mapy, zdjęcia lotnicze oraz satelitarne całego świata. Google Maps uŝywa tych samych zdjęć satelitarnych co Google Earth. Większość z tych zdjęć postało w ostatnich trzech latach. Baza ta jest cały czas powiększana, od maja 2007 roku zawiera równieŝ zdjęcia 48

49 ulic większych miast USA, w sierpniu 2008 dołączono równieŝ zdjęcia ulic Japonii i Australii. Google Maps jest dostępna w 17 wersjach językowych, w tym po polsku. Podczas konferencji 2005 O Reilly Where 2.0 Conference, która odbyła się w dniach czerwca 2005 roku udostępniono Google Maps API. Od tego czasu kaŝdy moŝe umieszczać na swojej stronie mapę Google. Pierwsze wersje API udostępniały tylko część mniej zaawansowanych funkcji Google Maps. Obecna wersja 2.8 oferuje niemal całą funkcjonalność oryginalnego serwisu między innymi są to: geokodowanie adresów, rysowanie polilinii, wyznaczanie tras przejazdu wraz z listą kroków, pełna kontrola widoku ulic, wsparcie dla języka KML/GeoRSS. Dostęp do API odbywa się przy pomocy języka JavaScript, ActionScript 3 (Google Maps API for Flash) lub w postaci obrazu (Google Static Maps API). 4.4 HTML/XHTML HTML (ang. Hypertext Markup Language), czyli hipertekstowy język znaczników. HTML jest specyfikacją definiującą pisanie stron WWW, aby te były prawidłowo interpretowane i wyświetlane przez przeglądarki. HTML jest językiem znacznikowym, za pomocą którego moŝna zdefiniować strukturę strony oraz jej prezentację. Odkąd zaczęto stosować kaskadowe arkusze stylów, nie zaleca się uŝywania znaczników HTML do definiowania wyglądu strony. XHTML (ang. Extensible Hypertext Markup Language), czyli rozszerzalny hipertekstowy język znaczników. XHTML jest językiem zdefiniowanym na bazie HTML 4.01 przy uŝyciu XML 1.0. XHTML wykorzystuje reguły składni języka XML, to znaczy, Ŝe dokumenty XHTML są poprawnymi dokumentami XML. Istnieje kilka wymagań odróŝniających język XHTML od HTML [DeBolt, 2005]: Wymagane są specyficzne deklaracje DOCTYPE, Wszystkie elementy, atrybuty i wartości muszą być pisane małymi literami, Wszystkie wartości naleŝy umieszczać w cudzysłowach albo apostrofach, z zachowaniem w całym dokumencie konsekwencji w stosowanym stylu, 49

50 Dla kaŝdego atrybutu naleŝy wyraźnie podać wartość. Oczywiście powyŝsze reguły moŝna stosować w języku HTML, ale nie są one obowiązkowe. Jedyną regułą składni języka XHTML, która nie działa w HTML jest uŝywanie ukośnika do zakończenia pustego elementu. 4.5 XML Rozszerzalny język znaczników czyli XML (ang. Extensible Markup Language), moŝna określić jako jeden z najlepszych sposobów zarządzania informacjami we współczesnych środowiskach sieciowych. Początkowo obsługa XML moŝliwa była tylko na serwerze, dopiero wersje Internet Explorer 5.0 i Mozilla zaczęły obsługiwać XML po stronie klienta przy pomocy JavaScript. Dokument XML jest zorganizowanym plikiem tekstowym, który składa się z następujących części: deklaracji XML, treści dokumentu, czyli elementów. Umieszczenie deklaracji powoduje, Ŝe dokument jest identyfikowany jako dokument XML. W deklaracji określa się obowiązkowo wersję języka XML uŝytego w dokumencie, na dzień dzisiejszy istnieje jedna wersja standardu XML 1.0. Pozostałe dwa parametry encoding i standalone są opcjonalne. Parametr encoding określa rodzaj kodowania znaków. Zaleca się uŝycie standardu Unicode, gdyŝ jest on obsługiwany przez większość systemów operacyjnych. Parametr standalone przyjmuje wartości yes lub no. Mówi o tym czy pominąć przetwarzanie zewnętrznych definicji typu dokumentu (DTD) oraz zewnętrznych jednostek. Przykładowa deklaracja XML: <?xml version= 1.0 encoding= UTF-8?> Standard UTF-8, to taki, w którym wszystkie znaki zakodowane są w zmiennej liczbie bajtów (od 1 do 6 bajtów), przy czym pierwsze 127 kodów ASCII zajmują jeden bajt, polskie znaki zajmują 2 bajty. Główną część dokumentu stanowi jego zawartość. Ta sekcja rozpoczyna się i kończy elementem głównym zwanym korzeniem. Zbudowanie hierarchii elementów 50

51 jest często najtrudniejszym problemem występującym podczas tworzenia dokumentu XML. Poprawny składniowo dokument XML, to taki, w którym: deklaracja XML występuje na początku dokumentu, istnieje tylko jeden unikatowy element główny korzeń, wszystkie pozostałe elementy występujące w dokumencie w całości zawierają się wewnątrz korzenia, wszystkie elementy niepuste posiadają znacznik początkowy i końcowy, element pusty moŝe składać się z pojedynczego znacznika elementu pustego, elementy mogą być zagnieŝdŝone, ale nie mogą na siebie zachodzić, wartości atrybutów umieszczone są w cudzysłowach lub apostrofach. Informacje mogą być przekazywane przez nazwę i treść elementu, a takŝe przez atrybuty i zaleŝności między elementami. Dokument XML moŝe równieŝ zawierać instrukcje dla parsera, którymi są: deklaracje, instrukcje przetwarzania i jednostki. Analiza i przetwarzanie dokumentu XML Dokumenty XML najczęściej są analizowane i przetwarzane. Analiza XML polega na wykorzystaniu biblioteki lub aplikacji w celu skorzystania z dokumentu XML i sprawdzenia jego poprawności składniowej. Jednocześnie informacje zawarte w dokumencie XML mogą być przetwarzane tak, aby mogły słuŝyć określonym celom. Istnieją dwa rodzaje analizatorów XML: wykorzystujące zdarzenia oraz wykorzystujące strukturę drzewa. Pierwszy rodzaj analizatora rozpoczyna działanie w przypadku wystąpienia zdarzenia. Przykładem zdarzenia jest napotkanie otwierającego znacznika w dokumencie XML. Poprzez czytanie całej zawartości pliku i wykonywanie działań w przypadku wystąpienia zdarzeń analizatory tego typu przetwarzają cały dokument XML. Analizatory drugiego typu przeglądają dokument XML i tworzą drzewiastą reprezentację całego dokumentu, którą następnie moŝna przetwarzać. 51

52 Model XML DOM Model XML DOM jest standardem W3C, definiuje obiekty, właściwości elementów dokumentu XML oraz metody dostępu do nich. Poruszanie się po XML DOM jest podobne do poruszania się po dokumencie HTML DOM, poniewaŝ jest on równieŝ hierarchiczną strukturą drzewiastą. Model DOM wszystkie składniki dokumentu XML definiuje jako węzły (ang. nodes). Węzły powiązane są hierarchicznymi zaleŝnościami: najwyŝej połoŝony element w drzewie to korzeń (root), kaŝdy węzeł z wyjątkiem korzenia ma dokładnie jeden węzeł nadrzędny (parentnode), węzeł moŝe mieć dowolną liczbę węzłów podrzędnych (childnodes), liść jest węzłem, który nie posiada dzieci, węzły posiadające tego samego rodzica to rodzeństwo (sibling). Przetwarzanie dokumentu XML rozpoczyna się od zdefiniowania korzenia przy pomocy właściwości documentelement. Korzeń stanowi punkt odniesienia uŝywany przez JavaScript do zidentyfikowania hierarchii prowadzącej do węzłów potomnych. Rozpoczynając od tego miejsca do kaŝdego elementu dokumentu bądź jego atrybutu moŝna się dostać uŝywając właściwości zebranych w tabeli

53 Tabela Właściwości dokumentu XML DOM Właściwość documentelement attributes childnodes firstchild lastchild nextsibling nodename nodetype nodevalue ownerdocument parentnode previoussibling text xml Opis Zwraca element główny dokumentu Zawiera tablicę atrybutów węzła. Zawiera tablicę węzłów podrzędnych. Zawiera referencję pierwszego bezpośredniego węzła podrzędnego danego węzła. Zawiera referencję ostatniego bezpośredniego węzła podrzędnego danego węzła. Zwraca węzeł występujący zaraz za danym węzłem. Zwraca pełną nazwę węzła. Zwraca typ węzła w sensie XML DOM Zawiera tekst związany z węzłem. Zwraca element będącym korzeniem dokumentu. Zawiera referencję węzła nadrzędnego danego węzła. Zawiera węzeł występujący bezpośrednio przed danym węzłem. Zwraca zawartość węzła lub tekst będący połączeniem zawartości danego węzła i jego węzłów potomnych. Dostępna tylko w przeglądarce IE. Zwraca dane XML danego węzła i jego węzłów potomnych w postaci łańcucha znaków. Dostępna tylko w przeglądarce IE. Standard XML DOM definiuje równieŝ metody, które zwracają specyficzne węzły lub wartości. Nie wymagają one przechodzenia całej struktury drzewa w poszukiwaniu węzłów nadrzędnych i podrzędnych. Do najczęściej stosowanych metod naleŝą getattribute() i getelementsbytagname(). Metoda getattribute() akceptuje argument będący łańcuchem zawierającym nazwę atrybutu i zwraca jego wartość. Jeśli atrybut o podanej nazwie nie istnieje, funkcja zwraca wartość NULL. Metoda getelementsbytagname() zwraca kolekcję ListNode zawierającą elementy, których nazwa została określona przez argument metody. Metoda ta wyszukuje elementy tylko w obrębie danego węzła. 53

54 4.6 CSS CSS (ang. Cascading Style Sheets) jest specyfikacją programistyczną, tworzącą przy pomocy zestawu reguł zwanych stylami, wizualną prezentację elementów w znacznikach definiowanych za pomocą języków XML czy HTML. Pojedynczy plik CSS moŝe kontrolować wygląd całej witryny, jej kolorystykę, typografię, rozmiar oraz rozmieszczenie elementów oraz grafiki. Stosowanie CSS umoŝliwia odseparowanie struktury od prezentacji. Style moŝna osadzać między znacznikami bezpośrednio w dokumencie XHTML lub zapisywać w odrębnym pliku. Drugi sposób jest bardziej elegancki i praktyczny. W dokumencie XHTML znajduje się jedynie logiczna struktura nagłówków, odsyłaczy, obrazków itd. Natomiast odrębny plik zawiera arkusz stylów. Dzięki temu moŝna zmieniać wygląd strony jedynie modyfikując sam arkusz stylów, nie ingerując w jej zawartość. Ponadto kod strony jest bardziej przejrzysty i szybciej się ładuje poniewaŝ załadowany przez przeglądarkę arkusz stylów jest zapisywany do pamięci podręcznej (ang. cache). Z jednym zewnętrznym arkuszem stylów moŝna powiązać dowolną liczbę stron WWW. Style moŝna umieścić w róŝnych miejscach, a na jednej stronie moŝe być zaimplementowanych kilka zbiorów takich reguł. Kaskadą nazywamy sposób w jaki rozwiązywane są ewentualne konflikty między regułami stylów. W tym zakresie istnieją dwie podstawowe zasady najbliŝsza reguła wygrywa oraz najbardziej konkretna reguła wygrywa [De Bolt, 2005]. WyróŜniamy następujące rodzaje stylów: Styl przeglądarki. KaŜda przeglądarka ma wbudowany swój własny zbiór reguł stylu. Reguły te zwykle definiują takie podstawowe właściwości wyświetlania jak rozmiar czy kolor czcionki. Styl uŝytkownika. Wszystkie przeglądarki umoŝliwiają uŝytkownikowi definiowanie własnych reguł stylów. Opcja ta jest bardzo waŝna na przykład dla osób słabo widzących. Zdefiniowane w ten sposób style uŝytkownika mogą być waŝniejsze od stylów definiowanych przez projektanta strony WWW. 54

55 Styl zewnętrzny (ang. External style). Jest to dokument tekstowy zawierający reguły stylów zapisany z rozszerzeniem.css. Łącze do zewnętrznego arkusza stylów umieszczane jest w sekcji head w elemencie link w dokumencie html. Styl osadzony (ang. Embadded Style). Styl osadzony równieŝ nazywany stylem wewnętrznym odnosi się tylko do dokumentu, w którym jest umieszczony. elementu. Styl lokalny (ang. inline). Umieszczane w kodzie XHTML jako atrybut Zgodnie z zasadami mówiącymi o bliskości oraz konkretności najwyŝszy priorytet ma styl lokalny, a następnie styl osadzony, zewnętrzny, styl przeglądarki. Styl uŝytkownika moŝe być ponad wyŝej wymienionymi stylami. 4.7 AJAX AJAX jest skrótem terminu Asynchronous JavaScript And XML, czyli asynchroniczny JavaScript i XML [Zakas, 2007]. Pierwszy raz pojęcia tego uŝył Jesse James Garrett w artykule zatytułowanym: AJAX: A New Approach to Web Applications, opublikowanym w sieci w lutym 2005 roku. Garrett w swoim artykule wyjaśnił w jaki sposób zaciera się granica pomiędzy aplikacjami WWW a tradycyjnymi aplikacjami uruchamianymi lokalnie. Przedstawił nowe technologie i podał kilka projektów Google jako przykład, sposobów w jakich model interakcji z uŝytkownikiem znany z tradycyjnych aplikacji moŝe zostać uŝyty w sieci. AJAX stanowi nowe podejście do problemu interakcji w aplikacjach WWW, w którym interakcja uŝytkownika z serwerem odbywa się bez przeładowania całego dokumentu. W celu zapewnienia uŝytkownikowi jak najszybszej odpowiedzi, dane do i z serwera przesyłane są w małych ilościach. AJAX róŝni się od tradycyjnego modelu aplikacji WWW, w którym przeglądarka inicjuje Ŝądania do serwera i przetwarza jego odpowiedź. Model AJAX do obsługi komunikacji wykorzystuje warstwę pośrednią, którą Garrett nazwał silnikiem AJAX. Garrett wymienił kilka technologii, które uznał za kluczowe podczas tworzenia aplikacji AJAX, jednak tylko trzy z nich są wymagane, są to HTML/XHTML, model DOM i JavaScript. 55

56 Narzędzia uŝywane w aplikacjach AJAX: HTML/XHTML są językami znacznikowymi, za pomocą których definiowana jest struktura i prezentacja strony WWW. W aplikacjach AJAX język XHTML uŝywany jest do prezentacji podstawowych treści. CSS został opracowany przez organizację W3C w 1996 roku w celu oddzielenia struktury dokumentu od formy jego prezentacji. CSS to specyfikacja programistyczna słuŝąca do ustalenia prezentacji wizualnej przez przeglądarkę zawartości elementów HTML/XHTML lub XML. CSS uŝywa w tym celu reguł zwanych stylami. DOM (ang. Document Object Model) obiektowy model dokumentu. Zgodnie z definicją W3C DOM to niezaleŝny od przeglądarki, neutralny wobec platformy oraz języka programowania interfejs, który daje programom i skryptom moŝliwość dynamicznego wglądu i uaktualniania zawartości, struktury oraz stylu dokumentów. Następnie dokument moŝe zostać przetworzony, a wyniki tego przetworzenia włączone ponownie do prezentowanej strony [ Standard W3C DOM definiuje zespół klas i interfejsów, umoŝliwiający dostęp do struktury dokumentów oraz jej modyfikację poprzez tworzenie, usuwanie i modyfikację tzw. węzłów (ang. nodes). Pierwotnie twórcy najpopularniejszych przeglądarek internetowych tworzyli własne niezgodne ze sobą modele. W odpowiedzi na co organizacja W3C przygotowała ujednolicony standard obiektowego modelu dokumentu. W modelu DOM JavaScriptu podstawowym dokumentem jest strona HTML-a. Model DOM umoŝliwia modyfikację fragmentów strony bez konieczności jej ponownego ładowania. XML jest językiem formalnym umoŝliwiającym organizację oraz strukturalizację danych dla sieci. Język XML jest utrzymywany przez organizację W3C (ang. Word Wide Web Consortium). Celem twórców XML było stworzenie standardu zapewniającego elastyczny sposób zapisywania informacji w notacji łatwej do odczytania przez ludzi oraz uŝytecznej do przetwarzania przez komputer z moŝliwością samosprawdzania poprawności i integralności [Ullman, 2002]. Dokument XML swoją budową przypomina stronę napisaną w HTML równieŝ jest językiem znacznikowym, nie są to jednak znaczniki formatujące, słuŝą jedynie do uporządkowania danych. 56

57 XSLT (XSL Transformations) jest jednym z trzech głównych języków z rodziny XSL (ang. extensible Stylesheet Language) opartym na XML, słuŝącym do przekształcania dokumentów XML na dane o innej postaci. Najpopularniejszym zastosowaniem XSLT jest przekształcanie dokumentów XML na dokumenty HTML. XMLHttp/XMLHttpRequest wykorzystywany jest do asynchronicznej komunikacji z serwerem. Obiekt XMLHttp został stworzony w celu umoŝliwienia inicjowania Ŝądań HTTP w dowolnym miejscu aplikacji. śądania te miały zwracać XML wobec czego obiekt XMLHttp dostarczał łatwego dostępu do informacji w postaci dokumentów XML. Obiekt XMLHttp moŝna było stosować zarówno w zwykłych aplikacjach jak i aplikacjach sieciowych. Obecnie jego funkcjonalność jest udostępniona przez cztery najpopularniejsze przeglądarki: Internet Explorer, Firefox, Safari i Opera. Spośród technologii wymienionych przez Garretta ma największe znaczenia dla innowacyjności i popularności AJAX. JavaScript jest zorientowanym obiektowo wieloplatformowym językiem skryptowym, stworzonym przez firmę Netscape. Pomimo, Ŝe język ten nie jest uŝyteczny samodzielnie, został stworzony z myślą o łatwym zagnieŝdŝaniu w innych aplikacjach. [ Najczęściej spotykanym zastosowaniem języka JavaScript są strony internetowe. NajwaŜniejszą cechą o jaką JavaScript moŝe wzbogacić projekt witryny jest zdolność do wprowadzenia do stron WWW dynamicznej interaktywności poprzez reagowanie na zdarzenia, sprawdzanie poprawności formularzy lub budowanie elementów nawigacyjnych. NaleŜy jednak zwrócić uwagę aby Ŝaden element serwisu nie stał się niedostępny po wyłączeniu obsługi JavaScriptu w przeglądarce. JavaScript słuŝy do zainicjowania komunikacji klient serwer i manipulowania DOM w celu aktualizacji strony. Silnik AJAX jest obiektem JavaScript lub funkcją wywoływaną za kaŝdym razem, gdy naleŝy zaŝądać danych od serwera. W przypadku tradycyjnego modelu łącze prowadzi do kolejnego zasobu, natomiast w przypadku modelu AJAX powoduje wywołanie silnika, który zleca wykonanie odpowiedniego Ŝądania. 57

58 Wymienione przez Garetta technologie dotyczą bezpośrednio silnika AJAX działającego na kliencie, niezbędne jest jednak dodanie języków skryptowych działających po stronie serwera np. PHP czy ASP.NET. 58

59 5 BUDOWA BAZY METADANYCH HYDROMETEOROLOGICZNYCH Do realizacji projektu konieczne było stworzenie bazy metadanych hydrometeorologicznych. NaleŜy zwrócić uwagę, Ŝe stworzona baza nie jest kompletną bazą metadanych hydrometeorologicznych, ogranicza się tylko do tych elementów, które zostały wybrane do wizualizacji. Zanim przystąpię do opisu etapów tworzenia bazy naleŝy się wyjaśnienie dwóch kluczowych pojęć: metadane, relacyjne bazy danych. 5.1 Metadane Metadane (ang. metadata) są to dane opisujące inne dane. Przykładem metadanych są słowniki i katalogi. Metaznacznik, opisujący zawartość strony internetowej, jest nazywany metadanymi. Termin moŝe być równieŝ uŝywany w stosunku do dowolnego pliku lub bazy danych, przechowujących informacje na temat struktury innej bazy danych jej atrybutów i modyfikacji [Freedman,2004]. Przy okazji definiowania pojęcia metadanych często przywołuje się katalog biblioteczny jako przykład dobrze ustrukturyzowanego zbioru metadanych: kaŝda karta katalogowa opisuje znacznie większy zasób informacji, którym jest skatalogowana ksiąŝka lub inny dokument i odsyła uŝytkownika do tego dokumentu [Nahotko,2000]. Tworzenie baz metadanych przez ludzi z róŝnych środowisk naukowych, wygenerowało potrzebą stworzenia standardów, które w obrębie określonej dziedziny umoŝliwiłyby porównywanie tych zbiorów. Standardy metadanych Dublin Core Metadata Element Set (DC) opisujący dokumenty tekstowe, jest standardem stworzonym przez środowisko bibliotekarskie. Dublin Core definiuje elementy, które moŝna podzielić na trzy klasy: Zawartość, Własność Intelektualna, Dookreślenie. Niektóre z nich takie jak tytuł, autor czy opis rzeczowy jest dobrze znana wszystkim, którzy choć raz widzieli rekord bibliograficzny. Niektóre z elementów słuŝą do zapisu danych technicznych i zawierają informację waŝną dla dokumentów internetowych, jaką jest rozmiar pliku. Część jednak jest typowa dla nowych potrzeb 59

60 cyberprzestrzeni i informuje np. kto posiada prawa do danego materiału [Nahotko,2000]. ISO Geographic Information Metadata jest standardem opracowanym przez Komitet Techniczny TC definiującym model opisu informacji geograficznej. Dostarcza informacji na temat identyfikacji, zakresu, jakości, przestrzennych i czasowych schematów, układów odniesienia oraz dystrybucji cyfrowych danych geograficznych. Zdefiniowany w normie schemat identyfikuje podstawowe pakiety informacyjne metadanych i ich elementy składowe oraz określa ich organizację poprzez ustanowienie pomiędzy nimi odpowiednich zaleŝności i powiązań. 5.2 Relacyjne bazy danych Twórcą relacyjnych baz danych jest dr Edgar Codd, naukowiec z firmy IBM. Sformułował on równieŝ zestaw reguł, o których sam napisał, Ŝe muszą być spełnione przez relacyjny system zarządzania bazą danych, jeśli ma on nosić miano w pełni relacyjnego 1. Reguły Codda pomimo, iŝ zostały sformułowane przeszło 20 lat temu nadal są aktualne i w oparciu o nie tworzy się bazy danych. Oto zbiór reguł warunkujący relacyjność bazy danych [Whitehorn, 2003]: 1. Dane muszą być przechowywane w tabelach. 2. KaŜda tabela musi mieć zdefiniowany klucz główny. 3. Baza danych musi wykorzystywać katalog systemowy, przechowujący metadane, czyli dane opisujące samą bazę danych. Metadane zapisywane w katalogu systemowym, równieŝ muszą być przechowywane w tabelach. 4. Reguły integralności danych, na przykład informacje niezbędne do zachowania integralności związków, muszą być przechowywane w katalogu systemowym, a nie na przykład w aplikacjach klienckich. 5. Zasady integralności występujące we wszystkich relacyjnych bazach danych: a. integralność encji 2 : Ŝaden z elementów klucza głównego nie moŝe akceptować wartości NULL, 1 Fragment artykułu napisanego przez dr Edgara Codda dla Computerworld opublikowanego 14 października 1985 roku. 2 Encja (rekord) jeden konkretny zbiór atrybutów (pól). 60

61 b. integralność odwołań: dla kaŝdej wartości klucza obcego tabeli, nie będącej wartością NULL, musi istnieć odpowiadająca jej wartość klucza głównego. 6. Musi istnieć jeden język, pozwalający na manipulowanie danymi w bazie. 7. Wspomniany język musi pozwalać na jednoczesne dokonywanie na wielu rekordach danych operacji takich jak modyfikacja, dodawanie czy usuwanie danych za pomocą pojedynczych poleceń. 8. śaden język programowania udostępniany przez system, nie powinien umoŝliwiać dokonywania takich zmian w indywidualnych rekordach, które mogłyby spowodować naruszenie integralności danych, zdefiniowanej w katalogu systemowym. 9. Zmiany fizyczne, logiczne lub dystrybucja danych, mające wpływ na strukturę bazy danych (dodanie indeksu, rozbicie tabeli na części czy tez przeniesienie tabeli na inny dysk), nie powinny być widoczne dla uŝytkownika końcowego. 10. Tabele wynikowe muszą być dostępne do modyfikacji, o ile to moŝliwe. 11. Wartości puste NULL muszą być obsługiwane w jednolity sposób. Pojęcie relacja jest matematycznym terminem tabeli. Często uŝywa się pojęcia relacja do określenia zaleŝności między danymi przechowywanymi w tabelach. Pomimo tego, Ŝe jest to błędne określenie jest szeroko uŝywane w tym znaczeniu. Relacyjna baza danych jest sposobem spojrzenia na dane. Model relacyjny składa się z trzech zagadnień dotyczących danych: struktury danych, integralności danych oraz manipulacji danymi [Date, 1995] ZaleŜności Jednym z etapów tworzenia relacyjnej bazy danych jest określenie zaleŝności jakimi powiązane są dane znajdujące się w odrębnych tabelach. ZaleŜności umoŝliwiają jednoczesne odczytywanie danych z wielu róŝnych tabel. Pomagają skonstruować strukturę bazy w sposób pozwalający na przechowywanie minimalnej ilości danych. ZaleŜności między dwiema tabelami mogą występować w postaci jeden do jednego, jeden do wielu oraz wiele do wielu. 61

62 ZaleŜność jeden do jednego występuje wówczas gdy jeden element z tabeli A odnosi się do jednego elementu z tabeli B. Tego typu zaleŝności stosuje się w przypadku gdy z jakichś względów elementy, które mogły by się znajdować w jednej tabeli są zapisywane w dwóch osobnych tabelach. Rozwiązanie takie często stosuje się ze względów bezpieczeństwa, np. w przypadku haseł dostępu. ZaleŜność jeden do wielu występuje gdy jeden element z tabeli A moŝe odnosić się do kilku róŝnych elementów z tabeli B. Jest to najczęściej stosowany rodzaj zaleŝności występujących między tabelami. ZaleŜność wiele do wielu jest zaleŝnością mającą charakter czysto teoretyczny. Z definicji jest to zaleŝność polegająca na tym, Ŝe kilka elementów z jednej tabeli moŝe się odnosić do kilku elementów z drugiej tabeli. Zwykle w sytuacjach, gdy występuje tego typu zaleŝność rozdziela się ją na dwie zaleŝności typu jeden do wielu tworząc dodatkową tabelę. Podziału dokonuje się ze względu na problemy ze spójnością oraz zwiększone prawdopodobieństwo powielania danych. Z tematem zaleŝności związane jest zagadnienie dotyczące kluczy. Kolumny kluczowe stanowią waŝny element relacyjnych baz danych, słuŝą do tworzenia zaleŝności między poszczególnymi tabelami oraz umoŝliwiają wprowadzenie róŝnego stopnia integralności danych. Pola jednoznacznie rozróŝniające rekordy relacji nazywane są kluczem głównym. Dodatkowym pojęciem jest klucz obcy. Klucz główny jest unikatowym identyfikatorem, który zawsze musi mieć stałą wartość inną niŝ NULL, a ponadto wartość ta dla kaŝdego rekordu w tabeli musi być inna. Przykładem klucza głównego moŝe być PESEL poniewaŝ kaŝdy posiada własny, niezmienny, unikatowy numer. Klucz główny moŝe być zdefiniowany w oparciu o jedno lub kilka pól, które pozwolą na jednoznaczne zidentyfikowanie danego rekordu. Często zdarza się, Ŝe wybranie prawidłowego klucza głównego sprawia trudność. Wtedy najlepszym rozwiązaniem jest wykorzystanie moŝliwości tworzenia kluczy przez systemy zarządzania bazami danych, które kaŝdemu nowemu wierszowi przypisują unikatową wartość. Warto równieŝ zwrócić uwagę aby klucz główny był liczbą całkowitą co umoŝliwia systemom zarządzania bazami osiągnąć najlepszą wydajność. 62

63 Klucz obcy w przeciwieństwie do klucza głównego nie jest wymaganym elementem kaŝdej tabeli. Jego obecność jest konieczna gdy istnieje zaleŝność pomiędzy dwiema tabelami. Klucz obcy moŝna zdefiniować jako klucz główny jednej tabeli znajdujący się w innej tabeli Normalizacja Z projektowaniem baz danych związane jest pojęcie normalizacji. Jest to proces słuŝący do określenia właściwego podziału danych na tabele. Pomaga on uniknąć nadmiarowości danych, dzięki czemu zmniejszają się rozmiary bazy i unikamy zbędnych opóźnień w korzystaniu z niej. Normalizując bazę danych naleŝy liczyć się z tym, Ŝe większy stopień spójności i skalowalności osiągany jest kosztem prostoty i szybkości [Whitehorn, 2003]. WyróŜniamy pięć postaci normalnych, w praktyce dąŝy się do doprowadzenia bazy danych do trzeciej postaci normalnej. Pierwsza postać normalna (1FN) Baza danych jest pierwszej postaci normalnej, jeśli w kaŝdej jej kolumnie moŝna umieścić tylko jedną wartość. Tego rodzaju kolumny nazywane są niepodzielnymi. Najlepszym przykładem jest tabela zawierająca pole, w którym moŝna umieścić kilka numerów telefonów (domowy, komórka, faks itd.). Taka tabela nie jest zgodna z 1FN, poniewaŝ w jednej kolumnie moŝe znaleźć się więcej niŝ jedna wartość. Zgodność z pierwszą postacią normalną wyklucza występowanie w bazie powtarzających się grup. Sprowadzenie tabeli do pierwszej postaci normalnej wiąŝe się z rozbijaniem danych na atrybuty (pola) elementarne. Definicja atrybutu elementarnego zaleŝy od przyjętych załoŝeń oraz kontekstu. W wielu przypadkach nie ma potrzeby rozbijania danych, gdy przechowywana wartość reprezentuje wystarczający poziom oczekiwanej szczegółowości. Przyjmuje się wtedy, Ŝe taka tabela jest pierwszej postaci normalnej. Druga postać normalna (2FN) KaŜda baza, która ma spełniać drugą postać normalną musi najpierw być zgodna z pierwszą postacią normalną. Jak widać proces normalizacji naleŝy przeprowadzać w odpowiedniej kolejności. Druga postać normalna mówi, Ŝe wszystkie kolumny, w których powtarzają się jakieś wartości, w róŝnych rekordach, naleŝy przekształcić na tabele. 63

64 Trzecia postać normalna (3FN) Baza danych spełnia trzecią postać normalną, jeŝeli jest ona zgodna z drugą postacią normalną, a ponadto kaŝda kolumna, dla której nie zdefiniowano klucza, jest zaleŝna tylko i wyłącznie od klucza głównego. Zadaniem tego etapu normalizacji jest wykluczenie niepoŝądanych związków pomiędzy niekluczowymi kolumnami w tabelach. Zwykle jeśli dwa pierwsze etapy normalizacji przebiegły prawidłowo, w tym momencie nie jest potrzebna Ŝadna modyfikacja. 5.3 Struktura bazy danych Niniejsza baza jest bazą relacyjną stworzoną w środowisku MySQL 4.0. Do pracy z bazą wykorzystano nakładkę graficzną MySQL Control Center. Pierwszym krokiem do utworzenia relacyjnej bazy danych jest stworzenie struktury bazy. Etap ten nazywa się projektowaniem bazy danych lub teŝ modelowaniem danych. Jest on niezbędny aby zagwarantować bezproblemowe zarządzanie przechowywanymi informacjami [Ullman, 2004]. Baza została zbudowana w oparciu o karty pomiarowe (rys.5.3.1) sporządzone przez Kingę Hajduk na podstawie zestawu danych Zakładu Hydrologii Politechniki Krakowskiej dotyczących pomiarów hydrometeorologicznych. Na początku naleŝało się zastanowić, które informacje zawarte w kartach pomiarowych będą uŝyteczne do stworzenia wizualizacji. Pewną barierą była niekompletność informacji, poniewaŝ jednak celem tej pracy nie było stworzenie bazy metadanych, do projektu uŝyto tylko tych, które tworzyły jednolitą całość. 64

65 Rysunek Przykładowa karta pomiarowa [Źródło: Hajduk, 2007] Do określenia jakie informacje powinny znaleźć się w bazie warto posłuŝyć się prostą metodą. NaleŜy zastanowić się nad tym, jakiego rodzaju pytania będą zadawane przez uŝytkowników i jakie dane będą musiały znaleźć się w odpowiedziach. Zanim przystąpiono do budowy bazy istniał juŝ pewien początkowy projekt wizualizacji, który zakładał wykorzystanie mapy i pewnych elementów wyszukiwania. W związku z tym załoŝono, Ŝe z punktu widzenia uŝytkownika interesujące będzie gdzie dokładnie znajdują się stacje pomiarowe, jakie parametry były w nich mierzone, w jakim okresie pomiarowym oraz z jaką częstotliwością dokonywano pomiarów. Do zadań stworzonej bazy naleŝy przechowywanie metadanych dotyczących pomiarów hydrometeorologicznych, które następnie zostały uŝyte do wizualizacji. Baza ma dostarczać kompleksowe informacje na temat pomiarów hydrometeorologicznych. W szczególności opracowano zestawienie stacji pomiarowych według następujących kryteriów: mierzony parametr, częstotliwość pomiarów, okres pomiarowy. Docelowo wyszukiwane są współrzędne stacji pomiarowych według zadanego kryterium, aby umoŝliwić ich zaznaczenie na mapie. Dla kaŝdej stacji istnieje moŝliwość wyświetlenia szczegółowych informacji dotyczących dokonanych w niej pomiarów. 65