[ Pobierz całość w formacie PDF ]
wspierające (w środowisku Java Studio Creator nazywane komponentami stron, ang. page
beans, z uwagi na konieczność ich dodawania do wszystkich stron) z reguły są wykorzystywa-
ne przez wizualne środowiska wytwarzania aplikacji JSF. Wspomniane środowiska auto-
matycznie generują odpowiednie metody zwracające i ustawiające wartości właściwości dla
wszystkich komponentów interfejsu graficznego przeciąganych na formularz.
Jeśli zdecydujemy się na użycie komponentu wspierającego, będziemy musieli związać
komponenty interfejsu użytkownika dodane do formularza z komponentami wchodzącymi
w skład komponentu wspierającego. Możemy zrealizować ten cel, stosując atrybut binding:
Po skonstruowaniu drzewa komponentów dla danego formularza następuje wywołanie metody
getScoreComponent komponentu wspomagającego, która jednak zwraca wartość null. Oznacza
to, że komponent wyjściowy jest konstruowany i instalowany w ramach tego komponentu
wspierającego za pomocą metody setScoreComponent.
Stosowanie komponentów wspierających w niektórych przypadkach jest uzasadnione, co
nie zmienia faktu, że w pewnych sytuacjach mogą być nadużywane. Nigdy nie powinniśmy
mieszać komponentów formularza z danymi biznesowymi w ramach jednego komponentu.
Rozdział 2. Komponenty zarządzane 61
Jeśli komponenty wspierające wykorzystujemy dla danych warstwy prezentacji, dla obiektów
biznesowych powinniśmy stosować odrębny zbiór komponentów.
Zasięg komponentów
Z myślą o zapewnieniu wygody programistom aplikacji internetowych kontenery serwletów
oferują odrębne zasięgi, z których każdy zarządza tabelą związków nazwa-wartość.
Każdy z tych zasięgów zwykle obejmuje komponenty i inne obiekty, które muszą być dostępne
z poziomu innych komponentów aplikacji internetowej.
Komponenty obejmujące zasięgiem sesję
Musimy pamiętać, że protokół HTTP jest bezstanowy. Przeglądarka wysyła żądanie na serwer,
serwer zwraca odpowiedz, po czym żadna ze stron (ani przeglądarka, ani serwer) nie ma
obowiązku utrzymywać w pamięci jakichkolwiek informacji o tej transakcji. Taki model
zdaje egzamin w sytuacji, gdy przeglądarka żąda od serwera prostych informacji, ale okazuje
się dalece niedoskonały w przypadku aplikacji pracujących po stronie serwera. Na przykład
w aplikacji sklepu internetowego oczekujemy od serwera zachowywania zawartości koszyka
z zakupami.
Właśnie dlatego kontenery serwletów rozszerzają protokół HTTP o mechanizm utrzymywania
i śledzenia sesji, czyli następujących po sobie połączeń nawiązywanych przez tego samego
klienta. Istnieje wiele różnych metod śledzenia sesji. Najprostszą z nich jest stosowanie
znaczników kontekstu klienta (tzw. ciasteczek; ang. cookies) par nazwa-wartość wysy-
łanych klientowi przez serwer w założeniu, że będą zwracane w ramach kolejnych żądań
(patrz rysunek 2.6).
Rysunek 2.6.
Znacznik
kontekstu klienta
wysłany przez
aplikację JSF
Dopóki klient nie dezaktywuje znaczników kontekstu, serwer będzie otrzymywał identyfikator
sesji wraz z kolejnymi żądaniami tego klienta.
62 JavaServer Faces
Serwery aplikacji wykorzystują też strategie alternatywne (np. polegające na przepisywaniu
adresów URL) do obsługi sesji nawiązywanych przez aplikacje klienckie, które nie zwra-
cają znaczników kontekstu klienta. Strategia przepisywania adresów URL sprowadza się do
dodawania do każdego adresu URL identyfikatora sesji podobnego do poniższego:
http://corejsf.com/login/index.jsp;jsessionid=b55cd6...d8e
Aby zweryfikować funkcjonowanie tego modelu, warto wymusić na przeglądarce
odrzucanie znaczników kontekstu klienta z serwera localhost, po czym ponownie
uruchomić naszą aplikację internetową i wysłać formularz. Kolejna strona powinna
zawierać atrybut jsessionid.
Zledzenie sesji za pomocą znaczników kontekstu klienta nie wymaga żadnych dodatkowych
działań ze strony programisty aplikacji, a standardowe znaczniki JavaServer Faces automa-
tycznie zastosują strategię przepisywania adresów URL w przypadku aplikacji klienckich,
które nie obsługują znaczników.
Zasięg sesyjny oznacza, że wszelkie dane są utrwalane od momentu ustanowienia sesji aż
do chwili jej zakończenia. Sesja jest kończona wskutek wywołania przez aplikację internetową
metody invalidate obiektu klasy HttpSession lub po upływie przyjętego limitu czasowego.
Aplikacje internetowe zwykle umieszczają większość swoich komponentów w zasięgu
sesyjnym.
Na przykład komponent UserBean może przechowywać informacje o użytkownikach, które
będą dostępne przez cały okres trwania sesji. Komponent ShoppingCartBean może być wypeł-
niany stopniowo wraz z otrzymywaniem kolejnych żądań składających się na sesję.
Komponenty obejmujące zasięgiem aplikację
Komponenty obejmujące swoim zasięgiem aplikację są utrzymywane przez cały czas wyko-
nywania aplikacji. Odpowiedni zasięg jest współdzielony przez wszystkie żądania i wszystkie
sesje.
Komponenty zarządzane umieszczamy w zasięgu aplikacji, jeśli chcemy, aby były dostępne
z poziomu wszystkich egzemplarzy naszej aplikacji internetowej. Taki komponent jest konstru-
owany w odpowiedzi na pierwsze żądanie dowolnego egzemplarza aplikacji i jest utrzymy-
wany przy życiu do momentu usunięcia tej aplikacji internetowej z serwera aplikacji.
Komponenty obejmujące zasięgiem żądanie
[ Pobierz całość w formacie PDF ]