Geary D. Cay S. Horstmann - Core JavaServer Faces. Wydanie II

Proszę wpisać nazwę i hasło użytkownika

26 28 29 30 31

s r

lilR liÉ lI [ 'J R SŁjT; ;:;i±... ..... ISII

Proszę wpisać «azwę i hasło użytkownika. Nazwa ‘ Hasie :



i

i ¿śfam 1

Zawartość tego pliku szczegółowo omówimy w dalszej części tego rozdziału, w punkcie „Strony technologii JS F ". Na razie ograniczymy się do następujących punktów: ■ Znaczna część użytych konstrukcji to standardowe znaczniki HTML-a, jak body czy Labie. ■ Dla niektórych znaczników dodatkowo użyto przedrostków , np. f •v i ew i h •mputText. Są to znaczniki technologii JS F . Dwie deklaracje Lagi ib na początku pliku deklarują biblioteki znaczników JSF . ■ Znaczniki h input Text, Lr inputSecret i h: cornmanclButton definiują odpowiednio pole tekstowe, pole hasła i przycisk akceptacji z rysunku 1.3.

Zakończono

W rzeczywistej aplikacji internetowej odpowiednia strona zostałaby oczywiście udekorowana dodatkowymi elementami opracowanymi przez utalentowanego grafika.

■ Pola tekstowe (w tym pole hasła) są powiązane z właściwościami odpowiedniego obiektu. Na przykład atrybut va 1ue="#{user nanie}" sygnalizuje implementacji JS F konieczność powiązania danego pola tekstowego z właściwością name obiektu user. Tego rodzaju powiązania zostaną szczegółowo omówione w punkcie „Komponenty” w dalszej części tego rozdziału.

20

JavaServer Faces

RozdziaM. ■ Wprowadzenie

Kiedy użytkownik wpisze nazwę i hasło, po czym kliknie przycisk Zaloguj, w oknie przeglą­ darki powinien się pojawić ekran powitalny (patrz rysunek 1.4). Kod źródłowy odpowiedniej strony zostanie przedstawiony na listingu 1.3 w dalszej części lego rozdziału. W punkcie „Naw igacja" wyjaśnimy, jak wygląda proces przechodzenia aplikacji pomiędzy ekranem logowania a ekranem powitalnym.

Rysunek 1.4.

f , Prosta a p t o g a i w W

Ekran powitalny

| Plik

Edycja

Widok

j II

‘u1

4HF

F a ce, - M o z f e f o t a

^

Listing 1.2. Zawartość pliku login/src/java/com/corejsf/UserBean.java 1

1 htt> -1 3lh0t

3

Pomoc

gm md- fa.-

► TCV

package com c o r e j s f

2

______________________________________________

Historia Zakład« Narzędzia

21

^

Witamy w świecie JavaServer Faces, inowak!

publ ic c lass userBean

\

4

p r i v a t e S t r in g name

5

p r i v a t e S t r in g password

6 7

// Właściwość name.

8

public S t r i n g getNameO

9

public void sethame (Strm g newVaiue)

j

return name

[ {

name = newValue

\

10 11

// Właściwość password: 12 pu blic S t r in g getPóSSw(Xd( ) | return password \ 13 public void setPassword(String newValue) { password = newValue, } 14 }

Struktura katalogów Komunikat powitalny zawiera podaną nazwę użytkownika. Na tym etapie ignorujemy wpisane hasło. Celem tej aplikacji oczywiście nie jest próba zaimponowania komukolwiek, tylko prezentacja rozmaitych elementów składowych niezbędnych do skonstruowania aplikacji w technologii JavaServer Faces.

Elementy składowe Nasza przykładowa aplikacja składa się z następujących elementów: ■ Stron definiujących ekran logowania i ekran powitalny. Odpowiednie strony nazwano indexjsp i welcomejsp.

M Komponentu (ang. bean) zarządzającego danymi użytkownika (w naszym przypadku jest to nazwa użytkownika i hasło). Komponent ma postać klasy Javy udostępniającej odpowiednie właściwości, które zwykle definiuje się zgodnie z prostymi konwencjami nazewniczymi dla metod zwracających i ustawiających. Kod tego komponentu zawarto w pliku UserBeanjava (patrz listing 1.2). Warto zwrócić uwagę na fakt przynależności tej klasy do pakietu com. corejsf. ■ Pliku konfiguracyjnego aplikacji, który opisuje zasoby komponentu i reguły nawigacji pomiędzy stronami. Domyślną nazwą tego pliku jest faces-config.xml. ■ Rozmaitych plików dodatkowych niezbędnych do właściwego funkcjonowania kontenera serwletów, czyli pliku web.xml i pliku index.html, który kieruje użytkownika pod adres U R L właściwy dla strony logowania. Bardziej zaawansowane aplikacje JS F charakteryzują się identyczną strukturą, tyle że zawie­ rają dodatkowe klasy Javy odpowiedzialne za obsługę zdarzeń, weryfikujące dane wejściowe i definiujące komponenty niestandardowe.

Aplikacja JavaServer Faces jest wdrażana w formie pliku W A R , czyli w istocie pliku Z IP z rozszerzeniem .war, który obejmuje strukturę katalogów zgodną z poniższym standardem. Oznacza to, że plik W A R skonstruowany dla naszej aplikacji przykładowej mógłby zawierać strukturę katalogów przedstawioną na rysunku 1.5. Jak widać, klasa UserBean należy do pakietu com. corejsf.

Rysunek 1.5. Struktura katalogów w ramach przykładowego pliku WAR

¡3 l o g i n . w a r f Q j

META-INF

' ...D

f-

MANIFEST.MF

w e b -inf

i j I I

i j ;

c las se s

j

r

I!

D

\ D

ł

3 com 9- £3 c o r e j s f ;

O

D

w e b .x m l in d e x, htm l

F D

in d e x .js p

;

w e tc o m e .js p

D

U s e r B e a n . class

fa c e s -c o n fig .x m l

Katalog META-INF jest tworzony automatycznie przez program jar w ramach procesu kon­ struowania pliku W A R . Kod źródłowy naszej aplikacji umieszczamy w nieco innej strukturze katalogów (zgodnie z konwencjami sformułowanymi w ramach projektu Java BluePrints — patrz strona interne­ towa http://java.sun.com/blueprints/code/projectconventions.html). Kod źródłowy znajduje się w katalogu src/java, natomiast strony JS F i pliki konfiguracyjne umieszczono w katalogu web (patrz rysunek 1.6).

22

Rozdziali. ■ Wprowadzenie

JavaServer Faces

W innych systemach możemy stanąć przed koniecznością dodania wielu plików JA R .

login

Rysunek 1.6.

23

k c a src

Struktura katalogów naszej przykładowej aplikacji

;

9 c a java com 9 9 S3 corejsf Q UserBean.java

Typowe polecenie kompilacji ma następującą postać: javac -classpath .g lassfish /} ib/javaee.jar -d /. /web/WEB-INF/classes com/corejsf/* java

web D index.html D index.jsp D welcome.jsp r c a WEB-INF Q faces-config.xml Q web.xml

W systemie Windows należy użyć średników oddzielających poszczególne ścieżki: javac -classpath .g la s s fi sh \] ib\javaee.jar -d \ \web\WEB-1NF\classes com\corejsf\* java

Musimy się upewnić, że ścieżka do klas obejmuje bieżący katalog (reprezentowany przez kropkę).

Kompilacja przykładowej aplikacji W tym punkcie przeanalizujemy kolejne kroki składające się na proces ręcznej kompilacji aplikacji JavaServer Faces. Na końcu tego rozdziału omówimy sposób automatyzacji tego procesu. 1. Uruchom powłokę poleceń.

2. Przejdź do katalogu zawierającego przykładowy kod źródłowy dla tej książki. 3. Wykonaj następujące polecenia: cd chl/1ogin/src/java nikdir /. /web/WEB-INF/classes javac -d / /web/WEB-INF/classes com/corejsf/UserBean.java

W systemie Windows użyj lewych ukośników: cd chl\login\src\java nikdir ,\. .\web\WEB-INF\classes javac -d . A \web\WEB-INF\classes com\corejsf\UserBean.java

4. Przejdź do katalogu chi/login/web. 5. Wykonaj następujące polecenie:

Analiza przykładowej aplikacji Aplikacje internetowe składają się z dwóch podstawowych części: warstwy prezentacji i logiki biznesowej. Warstwa prezentacji odpowiada za wygląd aplikacji. W kontekście aplikacji wyświetlanych w oknie przeglądarki wygląd zależy oczywiście od znaczników HTM L-a opisujących układ, czcionki, obrazy itd. Logika biznesowa jest implementowana w formie kodu Javy definiującego zachowania aplikacji. Niektóre technologie internetowe wymagają mieszania kodu HTML-a z właściwym kodem źródłowym aplikacji. Taki model jest o tyle kuszący, że umożliwia zapisywanie prostych aplikacji w pojedynczych plikach. Z drugiej strony, w przypadku poważnych aplikacji mie­ szanie znaczników z kodem źródłowym prowadzi do poważnych utrudnień. Profesjonalni projektanci stron internetowych potrafią tworzyć dokumenty cechujące się doskonałym wyglądem, ale zwykle korzystają z narzędzi, które automatycznie tłumaczą ich wizje graficzne na kod HTML-a. Trudno oczekiwać, by chcieli mieć do czynienia z osadzonym kodem źródłowym. Z drugiej strony, typowy programista nie ma pojęcia o projektach graficznych (doskonałym przykładem są aplikacje opracowane dla tej książki właśnie przez programistów).

jar cvf login.war

(Warto zwrócić uwagę na użytą na końcu tego polecenia kropkę, która reprezentuje katalog bieżący). 6. Skopiuj plik login.w ar do katalogu glassfish/domains/domainl/autodeploy.

7. Upewnij się, że uruchomiono serwer GlassFish. W oknie przeglądarki wpisz adres: http://localhost:8080/1ogin

Oznacza to, że projektując profesjonalną aplikację internetową, należy oddzielić warstwę prezentacji od logiki biznesowej. Takie rozwiązanie umożliwia zarówno projektantom stron internetowych, jak i programistom implementującym właściwą logikę aplikacji koncentro­ wanie się wyłącznie na swoich zadaniach. W technologii JavaServer Faces kod aplikacji jest umieszczany w komponentach, natomiast projekt ma postać stron internetowych. W pierwszej kolejności zajmiemy się komponentami.

Ostatni krok powinien uruchomić naszą aplikację. Klasy komponentów w bardziej złożonych aplikacjach mogą wymagać interakcji z frameworkiem JSF . W takim przypadku krok kompilacji jest bardziej skomplikowany. Ścieżka do klas musi wówczas obejmować biblioteki JavaServer Faces. Jeśli korzystamy z serwera aplikacji GlassFish, powinniśmy dodać pojedynczy plik JA R : g7assf7's/7/lib/javaee. jar

Komponenty Komponent Javy (ang. Java bean) jest klasą udostępniającą właściwości i zdarzenia środo­ wisku zewnętrznemu, np. JSF . Właściwość jest wartością nazwaną określonego typu, która może być przedmiotem operacji odczytu i (lub) zapisu. Najprostszym sposobem definiowania

24

Rozdziali ■ Wprowadzenie

JavaServer Faces właściwości jest stosowanie standardowej konwencji nazewniczej dla metod odczytujących (zwracających) i zapisujących (ustawiających), czyli poprzedzanie nazw właściwości przed­ rostkami get i set. W każdym takim przypadku pierwszą literę nazwy właściwości należy zmienić z małej na wielką. Na przykład klasa UserBean zawiera dwie właściwości typu String nazwane name i password: p u b l ic c la s s UserBean { pub 1ic S t r i n g geiName() ] [ public void setNametS t r i n g newValue) { public S t r in g g etP a ssw o rd () \ f public void se tPasswo rcK Strmg newValue)

}

{

25

Kod interesującej nas strony rozpoczyna się od następujących deklaracji bibliotek znaczników: tag 1lb u r u " h t t p //javd Sun com /j sf/core" p r e f l x = " f tagl ib un=-"http //java sun.com/jsf/utnil" pre fix ="h "

%> %>

Implementacja JS F definiuje dwa zbiory znaczników. Znaczniki języka H TM L generują konstrukcje właściwe dla stron HTML-a. Gdybyśmy chcieli, aby nasza aplikacja intemelowa prezentowała strony w jakiejś alternatywnej technologii klienckiej, musielibyśmy użyć innej biblioteki znaczników. Znaczniki podstawowe (biblioteki core) są niezależne od technologii wizualizacji. I tak znacznik f ■view jest potrzebny zarówno dla stron H TM L, jak i dla stron prezentowanych na przykład na ekranie telefonu komórkowego.

f

Metody get i set mogą podejmować dowolne działania. W wielu przypadkach ich funkcjo­ nowanie ogranicza się do zwracania i ustawiania odpowiednich pól egzemplarzy. Tego rodzaju metody mogą jednak uzyskiwać dostęp do katalogów interfejsu JN D I (od ang. Java Naming

and Directory Interface). Zgodnie ze specyfikacją komponentów istnieje możliwość rezygnacji z metod odczytu i zapisu. Jeśli na przykład nie zdefiniujem y m etody getP assw ord, w łaściw ość password będzie dostępna tylko do zapisu. Takie rozwiązanie m oże być korzystne ze względów bezpieczeństwa. Z drugiej strony, technologia JSF nie do końca radzi sobie z podobnymi sytuacjami i w razie braku m etody odczytu lub zapisu generuje stosowne wyjątki (zam iast podejmować domyślne działania). Oznacza to, że najlepszym wyjściem je s t definiowanie odpowiednich m etod dla wszystkich właściwości kom ponentów. W aplikacjach JavaServer Faces wykorzystuje się komponenty dla wszystkich danych, które muszą być dostępne z poziomu stron internetowych. Komponenty pełnią funkcję swoistych łączników pomiędzy interfejsem użytkownika a wewnętrznymi mechanizmami aplikacji.

| Dla znaczników m ożna stosow ać dowolne przedrostki, np. fa c e s :view i h t m l: ^ in p u tT e x t. W tej książce będziem y się konsekw entnie posługiwali przedrost­ kiem f dla znaczników podstawowych i h dla znaczników HTML-a. Zdecydowana większość elementów opisywanej strony bardzo przypomina zwykły formularz języka H TM L. Warto jednak zwrócić uwagę na kilka różnic: ■ Wszystkie znaczniki technologii JS F zawierają się w znaczniku f •view. ■ Zamiast stosować znacznik f orni języka HTM L, umieszczono wszystkie komponenty JS F w znaczniku h : form. ■ Zamiast korzystać z popularnych znaczników input języka H TM L, korzystamy ze znaczników h. input Text, h- input Secret oraz h : commandBut ton. Wszystkie znaczniki standardowe technologii JS F wraz z ich atrybutami zostaną omówione w rozdziałach 4. i 5. W pierwszych trzech rozdziałach tej książki będziemy korzystali wyłącz­ nie z pól tekstowych i przycisków poleceń. Wartości pól tekstowych są wiązane z właściwościami komponentu nazwanego user:

Strony technologii JSF Potrzebujemy po jednej stronie JS F dla każdego ekranu prezentowanego w oknie przegłądarki. W zależności od środowiska programowania, w którym pracujemy, strony JS F z reguły mają postać plików z rozszerzeniami .jsp lub jsf. W czasie, kiedy pisano tę książkę, pliki z rozsze­ rzeniem .jsp wymagały mniej zabiegów konfiguracyjnych. Właśnie dlatego w prezentowanych przykładach będziemy się posługiwali rym rozszerzeniem. O ile pliki stron są oznaczane rozszerzeniami jsp lub jsf, o tyle zgodnie z zalecaną konfiguracją adresy URL stron powinny się kończyć rozszerzeniem .faces. Jeśli na przykład w przeglądarce internetowej wpiszemy adres URL http://localhost:8080/login/ index.faces, użyte rozszerzenie .faces zostanie odwzorowane w rozszerzenie jsp, po czym kontener serwletów załaduje plik indexjsp. Opisywany proces sprawia wra­ żenie niepotrzebnie zagm atw anego, jedn ak wynika wprost z koncepcji im plem entacji technologii JSF ponad technologią serwletów. Wróćmy raz jeszcze do pierwszej strony naszej przykładowej aplikacji, której kod przed­ stawiono na listingu 1.1.

Deklaracją zmiennej user zajmiemy się w punkcie „Nawigacja" w dalszej części tego podroz­ działu. Składnia separatorów #{ .. | zostanie wyjaśniona w podrozdziale „Składnia wyrażeń reprezentujących wartości" w rozdziale 2. W momencie wyświetlania interesującej nas strony framework wywołuje metodę get Name celem uzyskania bieżącej wartości odpowiedniej właściwości. W chwili akceptacji formularza (kliknięcia przycisku Zaloguj ) framework wywołuje metodę setName, aby ustawić wartość wpisaną przez użytkownika. Znacznik h: commandBut ton zawiera atrybut action, którego wartość jest wykorzystywana w procesie definiowania reguł nawigacji:

Reguły nawigacji zostaną omówione w punkcie „Nawigacja". Atrybut value reprezentuje łańcuch wyświetlany wewnątrz przycisku. Druga strona JS F naszej aplikacji jest jeszcze prostsza od pierwszej. Wykorzystano w niej znacznik h:outputText celem wyświetlenia wpisanej wcześniej (na stronie logowania) nazwy użytkownika (patrz listing 1.3).

26

Rozdziali. ■ Wprowadzenie

JavaServerFaces

Listing 1.3. Zawartość pliku I



2 3 4

^T,(a t a g l i b u n = ‘ htt p //java sun c om /j sf/core" prefix--"f t a g l i b u r 1 ="h 11 p //javd sun com/JS f / h t m l " prefix="h

5 6 /

<1 1 11e >Pros t a a p li k a c j d Ja v a S e r v e r F dces

8 9 10 11 12 13 14 15 16 17 18

witdmy w sw iec ie J a v a S e r v e r taces !

27

K E j Zdarza się, że mniej doświadczeni autorzy stron tworzą dokumenty rozpoczynające m M się od deklaracji DOCTYPE języka HTML w następującej form ie: taglib uri="http://java.sun.com/jsf/html” prefix="h" %> taglib uri="http://java.sun.com/jsf/core" prefix®’T ' %>

Na pewnym etapie takie rozwiązanie można było zaakceptow ać, jed n ak obecnie po­ dobne próby należałoby uznać za karygodne. Nie m a wątpliwości, źe dokum ent w tej form ie z pewnością nie je s t zgodny z typem HTML 4.01 Transitional, a jedynie ma naśladować ten typ. Wiele edytorów i narzędzi języka XML odm awia obsługi podobnych konstrukcji. Oznacza to, że powinniśmy albo całkowicie zrezygnować z deklaracji DOCTYPE, albo stosować się do zaleceń sformułowanych w poprzedniej uwadze.



Nawigacja W naszych stronach JSF stosujem y tradycyjny, uproszczony form at, aby prezen­ tow ane listingi były możliwie czytelne.

Czytelnicy, którzy w odpowiednim stopniu opanowali język XML, prawdopodobnie będą mieli pewne zastrzeżenia. Po pierwsze, warto rozważyć użycie takiego znacznika XML-a w deklaracjach bibliotek znaczników, który umożliwi rezygnację ze stosowanych dotych­ czas znaczników <%,. ,%>. Co więcej, powinniśmy użyć właściwej deklaracji DOCTYPE dla generowanego dokum entu HTML-a. Poniżej przedstawiono form at, który elim inuje oba te problemy:


doctype-pub11c=” -//W3C//DTD XHTML 1.0 Transitional//EN” docty pe-syst em="http rjf’/www.w3. org/TR/ xhtml 1/DTD/xhtmlltransitianal .dtd'7>

Aby nasza pierwsza aplikacja JS F była kompletna, musimy jeszcze zdefiniować reguły na­ wigacji. Pojedyncza reguła nawigacji sygnalizuje stosowanej implementacji JS F , którą stronę należy odesłać do przeglądarki po akceptacji formularza na bieżącej stronie. W tym przypadku nawigacja jest bardzo prosta. Kiedy użytkownik kliknie przycisk Zaloguj, powinien zostać skierowany ze strony indexjsp na stronę welcomejsp. Opisywaną regułę można zdefiniować w pliku faees-eonfig.xml\ ^ n d v i g a t i o n ■r u l e > / in d e x . jsp< / f rom- v ipw- i(J> < n d v i g a t ion

cd se>

login n o -view -id>/weicome j sp < / n d v i g d t io n

case>

< / n d v i g d t i o n ■r u l e >

Wartość zdefiniowana w znaczniku f r o m - o u t c o m e odpowiada wartości atrybutu ściwego dla przycisku Zaloguj zdefiniowanego w kodzie strony indexjsp :
v d 1 u e = " Z d 1o g u j "

a ctio n

wła­

a ctio n = "lo g in "/ >

Oprócz reguł nawigacji plik faees-eonfig.xml zawiera definicje komponentu. Poniżej przed­ stawiono definicję komponentu u s e r : u ser co m c o r e j s f







Czytelnicy korzystający z edytora przystosowanego do pracy na plikach w formacie XML koniecznie powinni rozważyć możliwość definiowania stron w tej form ie.

userBean< /m andg ed-bean -class>

s e s s i o n < / m a n a g e d ■b e a n ■scope >

Nazwę komponentu (w tym przypadku u s e r ) możemy wykorzystywać w atrybutach elemen­ tów interfejsu użytkownika. Na przykład kod strony indexjsp zawiera następujący znacznik:
v a l u e = " # { u s e r . n a m e } "/>

Atrybut value odnosi się do właściwości name komponentu user.

28

Rozdziali ■ Wprowadzenie

JavaServer Faces Znacznik managed-bean-class wskazuje na klasę komponentu (w tym przypadku com.corejsf. ^UserBean). I wreszcie znacznik managed-bean-scope reprezentuje zasięg — w tym przy­ padku session, ponieważ komponent ma obejmować swoim zasięgiem sesję. Oznacza to, że obiekt komponentu jest dostępny dla pojedynczego użytkownika niezależnie od aktualnie wyświetlanej strony. Różni użytkownicy korzystający z naszej aplikacji internetowej będą mieli przydzielane różne egzemplarze obiektu komponentu. Kompletny kod zawarty w pliku faces-config.xml przedstawiono na listingu 1.4.

Listing 1 A Zawartość pliku login/web/WEB-INF/faces-config.xml_______________________________________ 1. 2
http

6

v p n s i on=" 1 2 ">

7

/ / j a v a sun com/xml/ns/javaee/web- f a c e s c o n f i g _ l _ 2

xsd"

^ n a v ig a tio n - ru le^

8

< f r o m 'v i e w - i d > / 1 npex j s p < / f rorn-v i e w ■i d >

9

< n a v i g a t i o n case>

Konfiguracja serwletu Wdrażając aplikację JavaServer Faces na serwerze aplikacji, musimy dysponować plikiem konfiguracyjnym nazwanym web.xml. Szczęśliwie okazuje się, że ten sam plik web.xml można stosować dla większości tworzonych aplikacji JSF. Plik opracowany z myślą o naszej aplikacji przedstawiono na listingu 1.5.

Listing 1.5. Zawartość pliku login/web/WEB-INF/web.xml_______________________________________________ 1. 2.
6 7

8 9 10 11

h up

//java sun com/xml/ns/javaee/web-app_2_5 xsd"

v e r s i o n - "2 5"^ < s e r v l e t -name>Se^wlet Ja v a S e r v e r Faces ja va x faces webapp F ac e s S e rv le t< / s e rv le t - c la s s > l

10

< f rom•Outcome^1ogin

12

11

< t o ■v i e w ■i d>/we1come j s p < / to - v ie w - i d >

13 14 15 16 17

Senwlet Ja v a S e r v e r Face s< /s en vl et■name> < u n l ■pattern.>* faces

12 13

< / n a v i g a t i o n case>

14 15



16

user

18

17 18

com corejsf userBean session

19

index

20



19 20



29

21

html





H H W technologii JSF 1 .2 składnię pliku konfiguracyjnego definiuje się w formie deklara■KaJ cji schem atu obejm ującego znaczniki konfiguracyjne: < /faces-config>

Jedynym elementem tego pliku, na który warto zwrócić uwagę, jest odwzorowywanie (mapowanie) serwletów. Wszystkie strony JS F są przetwarzane przez serwlet specjalny będący częścią kodu stosowanej implementacji technologii JSF. Aby zagwarantować właściwe aktywowanie tego serwletu w momencie żądania strony JS F , stosujemy specjalny format adresów U R L. W naszej konfiguracji wspomniane adresy będą się kończyły rozszerzeniem

.faees. Na przykład nie możemy wpisać w przeglądarce adresu http://localhost:8080/login/index.jsp. Musimy się posłużyć adresem U RL http://localhosi:8080/login/index.faces. Kontener serwletu wykorzystuje do aktywowania serwletu JS F regułę odwzorowywania, która odcina przyrostek faces i ładuje stronę index.jsp.

W technologii JSF 1.1 zam iast deklaracji schem atu stosowano deklarację DOCTYPE: < !OOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN" "h ttp :/ / ja v a .sun.com/dtd/web-facesconfigJL_ 0. dtd"> Zalecam y korzystanie z edytora XML, który właściwie interpretuje deklarację schem a­ tów języka XML. Czytelnicy pracujący w środowisku Eclipse mogą skorzystać z wtyczki XMLBuddy (http://xmlbuddy.com).

Możemy też zdefiniować odwzorowywanie przedrostków (zam iast odwzorowywania I rozszerzenia .faces). Wystarczy użyć następującej dyrektywy w pliku web.xml: Faces Serviet /faces/*

M ożem y następ n ie użyć adresu URL http://iocalhost:8080/iogin/faces/index.jsp. W spom niany adres aktywuje serw let JSF, który następnie obcina przedrostek faces i ładuje plik /login/index.jsp.

30

Rozdziali. ■ Wprowadzenie

JavaServer Faces

I Gdybyśmy chcieli stosować dla plików stron JSF rozszerzenie .jsf, musielibyśmy I tak skonfigurować naszą aplikację internetow ą, aby wywoływała dla plików z tym rozszerzeniem serwlet JSP. W tym celu należy w pliku web.xml zdefiniować następujące odwzorowanie: j$p *.jsf

Musimy jeszcze zasygnalizować implementacji JSF konieczność odwzorowywania rozsze­ rzenia .faces stosowanego w adresach URL w rozszerzenie .jsf powiązanych plików: ': javax.faces.DEFAULT_SUFFIX .j sf

Łatwo zauważyć, że opisywane zabiegi konfiguracyjne są istotne wyłącznie z perspektywy programistów i nie mają żadnego wpływu na pracę użytkownika naszej aplikacji interne­ towej. Adresy URL nadal mogą obejmować rozszerzenie .faces lub przedrostek /faces.

Jeśli korzystamy ze starszego serw era aplikacji obsługującego specyfikację serw wersji 2 .3 , powinniśmy użyć w pliku web.xml deklaracji DTD (DOCTYPE) zam iast deklaracji schem atu. Odpowiednia deklaracja DTD powinna m ieć następującą postać:

■Kfeil wletów



Strona powitalna Kiedy użytkownik wpisuje w oknie przeglądarki adres U R L wskazujący na katalog (np. http:/ W localhost:8080/login), serwer aplikacji automatycznie ładuje stronę index.jsp (jeśli taka strona jest dostępna). Okazuje się jednak, że opisywany mechanizm nie zdaje egzaminu w przypadku stron JS F , ponieważ pomija niezbędny proces przetwarzania. Można ten problem obejść, tworząc plik index.html, który automatycznie będzie kierował użytkownika pod adres U R L wskazujący na odpowiednią stronę .faces. Przykładowy kod takiego pliku przedstawiono na listingu 1.6.

Listing 1.6. Zawartość pliku login/web/index.html 1. 2 3 4 5. 6.

7 8

Proszq cze^ac na uruchomienie a p l i k a c j i

31

int ernetowej

9 I wreszcie warto zdefiniować w pliku web.xml stronę index.html jako dokument powitalny (patrz znacznik w e l c o m e file na listingu 1.5). BSJJ Plik index.html kieruje przeglądarkę pod adres URL wskazujący na stronę index. ■ ¡¡J faces. Nieznacznie bardziej efektywne byłoby użycie akcji przekierowania tech­ nologii JSP. Wystarczy utworzyć stronę (np. start.jsp) zaw ierającą następujący wiersz:

Następnie należy wskazać tę stronę w znaczniku welcome-f i Te w pliku konfiguracyjnym web.xml.

środowiska wytwarzania dla JSF Strony i pliki konfiguracyjne dla prostej aplikacji JavaServer Faces można opracować w zwy­ kłym edytorze tekstu. Z drugiej strony, w miarę wzrostu poziomu złożoności naszej aplikacji musimy dobierać coraz bardziej wyszukane narzędzia. W tym podrozdziale omówimy zintegrowane środowiska programowania (ID E ) i wizualne narzędzia projektowe oferujące obsługę technologii JSF , a także sposób automatyzacji procesu kompilacji z wykorzystaniem narzędzia Ant.

Zintegrowane środowiska programowania Zintegrowane środowiska programowania (wytwarzania), takie jak Eclipse czy NetBeans, nieprzypadkowo zyskały ogromne uznanie w świecie programistów. Obsługa automatycznego uzupełniania kodu, możliwość refaktoryzacji kodu, narzędzia diagnostyczne (tzw. debugery) itp. znacznie podnoszą produktywność programisty (szczególnie w przypadku wielkich projektów). W czasie, kiedy pisano tę książkę, istniała eksperymentalna implementacja wtyczki JS F dla środowiska Eclipse, która bez wątpienia wymagała wielu udoskonaleń. Lepszą obsługę technologii JavaServer Faces oferują liczne produkty komercyjne zbudowane na bazie Eclipse (w tym MyEclipse, Exadel Studio, B E A Workshop Studio i Rational Application Developer), jednak niektóre spośród wymienionych środowisk są dość drogie. Dla wszystkich tych pro­ duktów istnieją wersje próbne, które można pobrać za darmo z intemetu. Z drugiej strony, programiści mają do dyspozycji środowisko NetBeans, które nie dość, że jest darmowe, to oferuje doskonałą obsługę wbudowaną technologii JSF . Czytelnicy, którzy nie są usatysfakcjonowani obsługą tej technologii w ramach swoich ulubionych środowisk ID E, koniecznie powinni dać szansę środowisku NetBeans i sprawdzić jego możliwości.

32

Rozdziali ■ Wprowadzenie

JavaServer Faces Środowisko NetBeans oferuje mechanizm automatycznego uzupełniania kodu stron JS F i plików konfiguracyjnych. Co więcej, środowisko NetBeans bardzo ułatwia uruchamianie i diagnozowanie aplikacji JS F — realizacja tych zadań wymaga od programisty klikania odpowiednich przycisków na pasku narzędzi. Na rysunku 1.7 przedstawiono ekran debugera środowiska NetBeans w momencie wstrzymania wykonywania wewnątrz klasy UserBean.

lego środowiska. Użytkownik (projektant) może przeciągać komponenty z tej palety nad cen­ tralny obszar okna i dostosowywać ich właściwości za pośrednictwem arkusza właściwości w prawym, górnym rogu okna. W odpowiedzi na te działania środowisko Sun Java Studio Creator automatycznie tworzy odpowiednie znaczniki JavaServer Faces (patrz rysunek 1.9).

Rysunek 1.8.

. jĘjj^

Na rysunku 1.8 przedstawiono okno narzędzia Sun Java Studio Creator (patrz http://www.sun.com/ K->software/products/jscreator). Paleta komponentów znajduje się w lewej, górnej części okna

=7Sl SZT

a apiikaąn JayaSwver Fwes - ffe ń fe firefc*

m

http,-//'[ocalhosfc8080/iogrn/tndex.faces

<|Łłocgit Z

Wizualne środowisko wytwarzania aplikacji JSF

*

Proszę wpisać nazwę i hasło użytkownika. N arw a taowak Hasło

s a s s s iiia i,?* t i f t y/eg fi « q « «

i

i

fer m

R«fsvtsip fetid FUgi CVS I w N

¥

pr- ^ «itjjggĘ

" Ociekiwamt- na iocaiho;

'«Sin

%

w eb Daqes $ ConfiqurdClon Files , jetvei Desources

n V* T* € ji®userBeaP.^ a | _____

Mfj j,, * | ^ ^ ^ ; I (~~ !ji |

ia i ~ iV yi a a

P

^ ń # L.1

UajS -

*

tan

p r i v a t e S t r in g name; p r iv a t e S t r in g passw ord;

; r e t u r n name;

:

;B

p u b li c S t r in g g et Password, r j I r e t u r n passw ord; p u b li c v o id s e t P a s s w o r d iS t r in g n ew Valuei

d is t

j1Local Variables

Name - #

*L

y~

rhis name

¡ j nU|l

# password

U nul'

variable■n^oimacion.sno- 3'-a-u

□

c o n n e c t -d en a g g ei

Attached JPPA genagaei

Rysunek 1.9.

<§* 8 j , CallStack

ivp

# L n o r e i a e n t a l l v d e p l o y i n g L o g in _ L a u s l h o s t 4 3 4 3 _ s e r v e r C o m p le te d m c r e m e m a J d i F t r i b u t i o n 01 l o g i n

>

i passw ord ■ new'^alne;

si ; HTTP Monitor

ioqin (debug ■

3

roon

§

w.ndom.

"eio

M m

# J

|An-Bi2e

# ~y

NazwguZVIhOwniKc “*BStO

f” iS S iS '

- >@ WebApplication1 .-•>'¿M '">&>page^

Output

S RaouestBeanl IBSessIonBeartl S.ApplicationBeanl

••P-iEPT-'. .-assr-oi I

, :m

Oats

** t* y s s ? mm®.* *| Desiqr IS0 lava $3 >

Ce^rf-eial S"’roift'-eio? <£JiDuttoni ¿aioau.

p u b lic S t r in g g etH am et'

_De^imaer£onsBte„

Ve«.oni"q

* m

mstatic'e-ri -las1

:B

uiL

3

J Brat« 'e-' g~" 'e^i Ł,eia | ¡¡¡, 'em->rea «i Butron | -wnni ¿HQlmace“v;e>-n. | Ęl D > -odDO lM T-LlSI .I jJbLlSrDO > j $ Cnec«DO> ¿j1Cnec«DO>Group .] i,®' RaOicButton | ■¡tfy'l OaaioButtonGrOuD , || W^oS^Ctips Components

ppr.p£ pr..-

JavaOBDatab

fc?

-■Basic

t ‘¿j UserBean.ić

¡8

mew Bund Run Reraao-

y

iSPagel 1- iŚl Pagel 1 --i£lprm,i * P^ead! I ■^boovi

p u b li c c la s s U serBean i

core coreisf

c>if

;! c

-------

package co m .co ie q si ;

I SourcePackages ®

W ;nd*w

m 0

cr

Q

□ ; y !! i

' Localhost. 9009

Tnread LitpWorKerThreaa-ftOSO-O stopped at userBean.ia^a 9

Rysunek 1.7. Przykład użycia środowiska NetBeans w procesie diagnozowania aplikacji JSF

Harzędzia projektowania wizualnego Narzędzia projektowania wizualnego wyświetlają reprezentację graficzną komponentów i umożliwiają projektantom przeciąganie i upuszczanie komponentów dostępnych na palecie. Tego rodzaju narzędzia mogą mieć albo postać autonomicznych programów (jak Sun Java Studio Creator), albo postać modułów pracujących w ramach zintegrowanych środowisk wytwarzania.

33

Przykład automatycznie wygenerowanych znaczników JavaServer Faces

‘ł

9X

ti^fageł.jsp -±. ^

rn.me>

Mar.aqeaPcar.i +,^'“-ApDiiraricipBean ii ^"'Oeaues' Bean it ^'"SessionBean i '-fia Bourcef’acKagei Wuorana, .+ • DataBoufceOererer

34

JavaServer Faces

Rozdziali ■ Wprowadzenie

Co więcej, narzędzia projektowania wizualnego oferują interfejsy graficzne umożliwiające definiowanie regui nawigacji i komponentów (patrz rysunek 1.10). Odpowiedni p\\k facesconfiig.xmljest generowany automatycznie.

OT

Rysunek 1.10. Przykład wizualnego definiowania reguł nawigacji

iz j [Servers

ib 0 * # m i dietce-

<0 x

n r

y

# s

m

35

Czytelnicy, którzy zdecydują się korzystać z opracowanego przez nas skryptu, szczęśliwie nie muszą dysponować szczegółową wiedzą o narzędziu Ant. W pierwszej kolejności należy pobrać to narzędzie z witryny internetowej http://ant.apache.org i zainstalować je w wybranym katalogu. Użytkownicy serwera aplikacji GlassFish mogą skorzystać z narzędzia asant do­ stępnego w katalogu glassfis h/bin.

m m

qe V>. w o n •

}

i

r .r ,

i

Podczas kompilacji narzędzie Ant kieruje się zapisami zawartymi w pliku kompilacji. Domyślną nazwą tego pliku jest build.xml. Na potrzeby tego materiału opracowaliśmy plik build.xml umożliwiający kompilację aplikacji JSF . Wspomniany plik można znaleźć w ka­ talogu corejsf-examples. Nasz plik build.xml zawiera instrukcje opisujące sposób kompilacji, kopiowania, pakowania i wdrażania aplikacji na serwerze — całość w formie konstrukcji składniowych języka X M L (patrz listing 1.7).

Listing 1.7. Zawartość pliku kompilacji build.xml D'oieui,

-

0» x ;Files,

OfrWebApplicdtionl

1

O T O j e c t defdu 11 =" m s t a l l ">

2

g;‘UeijtOSSS«0 § __r,em Nav,qatl0n ®'“lanaqojgear5ł;,ApDI|i.ariC'BBfiar. ^"'b-auia-si Bi^an Bear'

3


environment=“ eny"/>

4

^property

fi 10 ="bu 1 Id p r o p e r t 1e s 1/>

^property

ndme="appdir'


property-"dppndme ' fi 1e=’

7


name=” bui 1d d i r " vd 1ue="

8 9


nanne= "war f 1 1e" va 1ue="

10 11

Środowisko Java Studio Creator generuje strony, których struktura jest na tyle sztywna i niedoskonała, że trudno na ich podstawie opanowywać techniki programowania w tech­ nologii JS F . W związku z tym zalecamy korzystanie z innego środowiska podczas pracy z przykładami prezentowanymi w tej książce. Po przestudiowaniu tych przykładów wiedza Czytelnika o technologii JS F powinna być na tyle bogata, że wystarczy do efektywnego ko­ rzystania ze środowiska Java Studio Creator. Firma Sun zapowiada, że narzędzia projektowania wizualnego dostępne obecnie w ramach środowiska Java Studio Creator zostaną zintegrowane z przyszłymi wersjami środowiska Net­ Beans. Podobne funkcje mają być dostępne także w przyszłych wersjach środowiska Eclipse.

Automatyzacja procesu kompilacji za pomocą narzędzia Ant Wielu programistów jest na tyle mocno przywiązanych do swoich ulubionych edytorów tekstu lub środowisk ID E, że z góry odrzucają możliwość korzystania z innych narzędzi, nawet jeśli dotychczasowe oprogramowanie nie oferuje dostatecznej obsługi technologii JS F . Proces ręcznej kompilacji, który opisano we wcześniejszej części tego rozdziału, może być dość nużący, jeśli będzie wielokrotnie ponawiany. W tym punkcie omówimy sposób automatyzacji tego procesu z wykorzystaniem narzędzia Ant. Niniejszy materiał nie jest konieczny do pracy w technologii JavaServer Faces — jeśli wykorzystywane zintegrowane środowisko progra­ mowania oferuje dobrą obsługę technologii JS F lub jeśli ręczne kompilowanie aplikacji nie sprawia Czytelnikowi problemów, można bez obaw zrezygnować z lektury tego punktu.

v d 1ue=" % { based 1 r [ /%{app\"/>

5 6

12 13

M

dppd1 r }"/> dppdI rI/bu 11d " />

bu i Iddi r}/$|appnamef war"/>


l o c a tio n = "$ {jdvaee api j a r } " / >

< f 1 1esec d i r = " S j a p p d i r (">



15



16 17 18. 19.



20

21 22. 23. 24 25 26 27 28 29 30 31. 32. 33. 34 35 36. 37. 38 39



36

JavaServer Faces

40

Rysunek 1.11.



41.



42.



43. 44.

Rozdziali. ■ Wprowadzenie



45 46 47



53. 54



compile: [javac] Compiling 1 source file to /home/cay/corejsf-examples/chl/login/buil d/WEB-INF/classes war:

^include name="**/* java"/>

fjarl Building jar: /home/cay/corejsf-examp Les/chl/logm/bui ld/login.war install: [copy} Copying 1 file to /usr/local/glassfish/domains/domainl/autodeploy



BUILD SUCCESSFUL Total time: 3 seconds ~/corejsf-examples$ _____________

58 59

^target name="war" depends="compile" d e s c n p t ion= "Budowanie p li k u wAR ">

60 61



62


63 64



65


66 67 68




■Dapp=Ch1 / 1 o g l n

W tym konkretnym przypadku apache-ant jest katalogiem, w którym zainstalowano narzędzie Ant (np. e:\apache-ant-l.6.5). Użytkownicy serwera GlassFish mogą się posłużyć poleceniem: g/assf/s/i/bi n/a san t

Dapp^cnl/ login



72 73 74

Otwórz powlokę poleceń i przejdź do katalogu corejsf-examples.

d P â C h e - â n t /D in/ant

">



71

1.

2. Wykonaj polecenie:

69 70

i nit: prepare: [rakdir] Created dir: /home/cay/corejsf-examples/chl/login/build

[copy] Copying 5 files to /horae/cay/corejsf-exainples/chl/login/build [copy] Copied 4 empty directories to 3 empty directories under /horae/cay/co rej sf-examples/chl/login/build

51. 52.

55

EHe fitfit View lermirtai Tafes Help

~/corejsf~examples$ ant -Dapp=chl/login Buildfile: build.xml

copy:


48

56 57

Instalacja aplikacji internetowej z wykorzystaniem narzędzia Ant

37



Aby korzystać z tego pliku kompilacji, musimy odpowiednio zmienić zawartość pliku

build.propenies składowanego w tym samym katalogu. Domyślną zawartość lego pliku przedstawiono na listingu 1.8.

ffS 9j Prezentowany skrypt języka Ant nieznacznie różni się od skryptów, które z reguły « 1 są dostarczane wraz z rozm aitym i aplikacjam i przykładowym i. Za pom ocą tego jedn ego skryptu m ożna kom pilow ać wszystkie aplikacje opracow ane dia tej książki. Nazwa kompilowanej aplikacji je s t reprezentowana przez flagę -Dapp= Wydaje się, że takie podejście je s t lepsze niż każdorazowe opracowywanie niemal identycznych skryp­ tów. Warto też podkreślić, że nasz skrypt nie jest wywoływany z poziomu katalogu aplika­ cji, tylko katalogu corejsf~examples.

Listing 1,8. Plik build.properties________________________________________________________________________ 1 appserver d m $ | e n v GLASSF!SH_hOME} 2

javaee api jar =4{appser ver d i r } / ] ib/java ee j a r

3

depioy dir -$|ap p se rv e r dir}/domams/domain 1/autodep 1oy

Instalacja lokalna na serwerze aplikacji wymaga zmodyfikowania katalogu docelowego. W tym celu należy odpowiednio zmienić pierwszy wiersz w pliku build.properties. Możemy teraz przystąpić do właściwej kompilacji naszej przykładowej aplikacji (patrz ry­ sunek 1.11).

Usługi frameworka JSF Skoro dokonaliśmy już analizy naszej pierwszej aplikacji JavaServer Faces, wyjaśnienie usług oferowanych programiście przez framework JS F powinno być dużo prostsze. Ogólną archi­ tekturę tej technologii przedstawiono na rysunku 1.12. Jak widać, framework JS F odpowiada za interakcję z urządzeniami klienckimi i oferuje narzędzia niezbędne do łączenia w jedną całość prezentacji graficznej, logiki aplikacji i logiki biznesowej aplikacji internetowej. Funk­ cjonalność tego frameworku kończy się jednak na warstwie prezentacji — obsługa utrwalania obiektów w bazie danych, usług sieciowych i połączeń wewnętrznych wykracza poza moż­ liwości tej technologii.

38

Rozdziali. ■ Wprowadzenie

JavaServer Faces

39

Weryfikacja danych i obsługa błędów — technologia JS F ułatwia definiowanie

Rysunek 1.12. Architektura frameworku JavaServer Faces

- Kontener serwletów — * Aplikacja internetowa

Urządzenia klienckie

Prezentacja

Logika aplikacji Nawigacja Weryfikacja Obsługa zdarzeń

Logika biznesowa

1 Framework JSF

Poniżej wymieniono i krótko opisano najważniejsze usługi frameworku JSF :

Architektura model-widok-kontroler — wszystkie aplikacje umożliwiają użytkownikom operowanie na pewnych danych, np. koszykach zamówień, planach podróży lub dowolnych innych danych właściwych dla danej dziedziny problemu. Wszystkie te dane określamy mianem modelu. Podobnie jak artysta malarz tworzy obraz, obserwując modelkę w swoim studiu, tak programista aplikacji JS F tworzy widoki na podstawie danych modelu. W aplikacjach internetowych widoki są „malowane” w języku H T M L (lub innej, podobnej technologii wizualizacji). Technologia JS F wiąże widok z modelem. Mieliśm y już okazję się przekonać, że komponent widoku może się odwoływać do właściwości obiektu modelu:

reguł weryfikacji danych dla pól tekstowych (w tym pól wymaganych i pól, w których użytkownicy powinni wpisywać wartości liczbowe). W odpowiedzi na wpisanie błędnych danych nasza aplikacja powinna oczywiście wyświetlić stosowny komunikat o błędzie. Oznacza to, że framework JavaServer Faces zwalnia programistę z obowiązku samodzielnej implementacji tych elementów. Problemem weryfikacji danych zajmiemy się w rozdziale 6.

Umiędzynarodowienie — framework JavaServer Faces zarządza takimi elementami umiędzynarodawiania aplikacji jak kodowanie znaków czy dobór właściwych pakietów zasobów. Problem wyboru pakietów zostanie omówiony w podrozdziale „Pakiety komunikatów” w rozdziale 2. Komponenty niestandardowe — programiści komponentów mogą tworzyć własne, często bardzo wyszukane komponenty, które projektanci stron mogą następnie umieszczać na tworzonych stronach. Przypuśćmy na przykład, że programista komponentów opracował komponent kalendarza ze wszystkimi niezbędnymi elementami graficznymi i funkcjonalnymi. Takiego komponentu można by użyć na stronie, stosując następujące polecenie:

Szczegółowe omówienie zagadnienia tworzenia komponentów niestandardowych można znaleźć w rozdziale 9.

Alternatywne metody wizualizacji — framework JS F domyślnie generuje znaczniki dla stron H TM L. Okazuje się jednak, że można ten framework bez trudu rozbudować o mechanizmy generujące znaczniki innych języków opisu stron, w tym języków W M L i X U L .



Co więcej, framework JS F pełni funkcję kontrolera reagującego na działania podejmowane przez użytkownika, przetwarzając akcje i zdarzenia zmian wartości oraz kierując je do kodu odpowiedzialnego za aktualizację modelu lub widoku. Możemy na przykład zaimplementować rozwiązanie polegające na wywoływaniu odpowiedniej metody za każdym razem, gdy użytkownik może się zalogować. W tym celu wystarczy użyć następującego znacznika JS F : < td>H as i o r cinput type= "password" tiajne=Bj_id_idl3:3 _id_id:

Jak wiemy, każdy z tych znaczników daje początek odpowiedniemu komponentowi graficz­ nemu. Każdy taki komponent obejmuje mechanizm renderingu (wizualizacji) generujący dane wyjściowe (w formacie H TM L) odzwierciedlające bieżący stan komponentu. Na przykład mechanizm wizualizacji komponentu właściwego dla znacznika h:iriputText generuje nastę­ pujące dane wyjściowe:
name="u n i k a l n y i d e n t y f i k a t o r "

v a l u e = " a k t u a I n a w a r t o ś ć " />

Opisywany proces jest określany mianem kodowania (ang. encoding). Mechanizm renderujący obiekt klasy UTTnput żąda od frameworka JS F łznalezienia unikatowego identyfikatora i bieżącej wartości wyrażenia use^ name. Łańcuchy identyfikatorów domyślnie są przypisy­ wane właśnie przez ten framework. Generowane identyfikatory sprawiają wrażenie przypad­ kowych, np. _n d_i d12._i d_i d21. Zakodowana strona jest przesyłana do przeglądarki, która wyświetla otrzymany kod HTML-a w tradycyjny sposób (patrz rysunek 1.14).

_i.-d_idl3 :3_xd_id3 6 n val’ae="Zalogu3 ” />

Dekodowanie żądań Po wyświetleniu strony w oknie przeglądarki użytkownik wypełnia pola formularza i klika przycisk Zaloguj. Wówczas przeglądarka odsyła na serwer W W W wpisane dane sformatowane w formie żądania POST. Jest to format specjalny zdefiniowany w ramach protokołu HTTP. Żądanie POST zawiera zarówno adres U R L formularza (w tym przypadku /login/index.faces), jak i dane formularza.

aP« Sï3 ssf I Í W m A

doprowa; bezpośrednio

Rysunek 1.14. Kodowanie i dekodowanie stron JSF

- Serwer

%,-4 4 3 i L

Dane formularza mają postać podobnych par identyfikator-wartość:

Drzew o kom p o n en tó w

Przeglądarka '..

7d/=ja&/d^sekret&/d3=login

HTML j

L ............................... .

W ramach standardowego procesu przetwarzania serwletu dane formularza są umieszczane w tablicy mieszającej, do której mają dostęp wszystkie komponenty.

HTTP POST Kodo wanie/dekodowĄiie f Framework JSF

W kolejnym kroku framework JS F umożliwia wszystkim komponentom analizę zawartości tej tablicy mieszającej (w procesie nazywanym dekodowaniem). Każdy komponent sam decyduje o sposobie interpretacji danych formularza.

42

RozdziaM. ■ Wprowadzenie

JavaServer Faces Dla formularza logowania istnieją trzy obiekty komponentów graficznych: dwa obiekty klasy Ullnput właściwe dla pól tekstowych na formularzu oraz obiekt klasy UlComniand właściwy dla przycisku akceptacji. ■ Komponenty graficzne typu U11nput aktualizują właściwości komponentów wskazane w atrybutach val ue (w yw ołują metody ustawiające, przekazując na ich wejściu wartości wpisane przez użytkownika). ■ Komponent graficzny UlComniand sprawdza, czy odpowiedni przycisk został kliknięty. Jeśli tak, generuje zdarzenie akcji, aby wykonać akcję logi n wskazaną w formie atrybutu action. Wspomniane zdarzenie sygnalizuje mechanizmowi odpowiedzialnemu za obsługę nawigacji konieczność odnalezienia kolejnej strony (w tym przypadku welcome.jsp).

43

W fazie przywracania widoku (ang. restore view) odczytujemy dla żądanej strony (jeśli była już wcześniej wyświetlana) lub konstruujemy (jeśli dana strona jest wyświetlana po raz pierw­ szy) drzewo komponentów. Jeśli dana strona była już wyświetlana, odtwarzamy (przywracamy) poprzedni stan wszystkich komponentów. Oznacza to, że framework JS F automatycznie zachowuje informacje z formularza. Jeśli na przykład użytkownik wpisze nieprawidłowe dane, które zostaną odrzucone w procesie dekodowania, ponownie wyświetlony formularz będzie zawierał wszystkie wprowadzone wcześniej dane, które użytkownik będzie mógł skorygować. Jeśli żądanie nie obejmuje żadnych danych formularza, implementacja JavaServer Faces pomija fazę wizualizacji odpowiedzi (ang. render response ). Taka sytuacja ma miejsce wtedy, gdy strona jest wyświetlana po raz pierwszy.

Cały ten cykl jest powtarzany.

W przeciwnym razie przechodzimy do fazy kolejnej: stosowania wartości żądania (ang. apply request values). W lej fazie implementacja JS F iteracyjnie przeszukuje obiekty komponentów

Właśnie zapoznaliśmy się z dwoma najważniejszymi krokami przetwarzania w ramach firameworku JS F . czyli kodowaniem i dekodowaniem. Okazuje się jednak, że sekwencja przetwa­ rzania (określana też mianem cyklu życia; ang. life cyc/e) jest nieco bardziej zawiła. Jeśli wszystkie mechanizmy działają zgodnie z naszymi oczekiwaniami, nie musimy się zajmować szczegółowymi aspektami cyklu życia. Jeśli jednak w trakcie wykonywania naszej aplikacji będzie miał miejsce jakiś błąd. będziemy się musieli zainteresować faktycznym funkcjonowa­ niem frameworku. W kolejnym punkcie dokonamy szczegółowej analizy cyklu życia aplikacji JavaServer Faces.

składowane w drzewie komponentów. Każdy z tych obiektów sprawdza, czy wartości dołą­ czone do żądania nie należą do niego i (w razie konieczności) zapisuje je w swoich właści­ wościach.

Cykl życia aplikacji JSF Specyfikacja JS F definiuje sześć odrębnych faz cyklu życia aplikacji (patrz rysunek 1.16). Standardowy przepływ sterowania oznaczono liniami ciągłymi; przepływ alternatywny jest reprezentowany przez linie przerywane.

Zakończono o dp o w ie dź ----

Zakończono o dp o w ie dź

<

-o

W fazie stosow ania w artości żądania im plem entacja JSF nie tylko w yodrębnia inform acje zaw arte w żądaniu, ale też dodaje do kolejki zdarzenia właściwe dla kliknięć przycisków lub łączy na danej stronie. Tem atyką związaną z obsługą zdarzeń zajm iem y się w rozdziale 7 . Jak widać na rysunku 1 .1 6 , zdarzenia mogą być przetwa­ rzane po każdej fazie. W skrajnych przypadkach m etoda obsługująca zdarzenie m oże wymusić natychmiastowe przejście do fazy wizualizacji odpowiedzi lub nawet całkowicie przerwać proces przetwarzania żądania. W fazie weryfikacji danych (ang. process validations) przekazane wartości łańcuchowe są w pierwszej kolejności konwertowane na odpowiednie „wartości lokalne", które mogą mieć postać obiektów dowolnego typu. Projektując stronę JS F , możemy zdefiniować mechanizmy weryfikacji odpowiedzialne za sprawdzanie prawidłowości tych wartości lokalnych. Jeśli weryfikacja przebiegnie pomyślnie, cykl życia aplikacji JavaServer Faces może być normalnie kontynuowany. Jeśli jednak w czasie tego procesu zostaną wykryte jakieś błędy, implementa­ cja JS F od razu wywoła fazę wizualizacji odpowiedzi, wymuszając ponowne wyświetlenie bieżącej strony, aby użytkownik raz jeszcze mógł wpisać prawidłowe dane wejściowe. Dla wielu programistów właśnie to działanie jes t najmniej spodziewanym aspektem cyklu życia aplikacji JSF. Jeśli działanie m echanizm u konwertującego lub m echa­ nizmu weryfikującego zakończy się niepowodzeniem , bieżąca strona zostanie ponow­ nie wyświetlona. Oznacza to, że powinniśmy dodać znaczniki inform ujące użytkownika o wykrytych błędach, aby w iedział, dlaczego aplikacja wróciła do wysłanego wcześniej form ularza. W ięcej informacji na ten te m a t można znaleźć w rozdziale 6 .

Błędy ko n w ersji/w izua liza cja o d p o w ie d zi

;

Błędy w e ryfika cji lu b konw ersji/w izua liza cja od p o w ie d zi

Rysunek 1.16. Cykl życia aplikacji JSF

Po pomyślnej realizacji zadań przez mechanizmy konwersji i weryfikacji implementacja JS F przyjmuje, że można bezpiecznie zaktualizować dane modelu. W fazie aktualizacji wartości modelu (ang. update model values) wartości lokalne są wykorzystywane do zmiany wartości w ramach komponentów właściwych dla poszczególnych elementów formularza.

44

JavaServer Faces W fazie wywołania aplikacji (ang. invoke application) implementacja JS F wykonuje me­ todę action przycisku lub łącza, którego kliknięcie doprowadziło do wysłania danego for­ mularza. Wspomniana metoda może wykonywać dowolne operacje na otrzymanych danych i zwraca łańcuch wynikowy, który jest następnie przekazywany do mechanizmu obsługują­ cego nawigację. Na tej podstawie mechanizm nawigacji identyfikuje stronę, która powinna zostać wyświetlona jako następna.

2

I wreszcie w fazie wizualizacji odpowiedzi, odpowiedź jest kodowana i wysyłana do przeglą­ darki. Kiedy użytkownik wysyła formularz, klika łącze lub w inny sposób generuje nowe żądanie, cały ten cykl zaczyna się od nowa. Przedstawiliśmy podstawowe mechanizmy umożliwiające funkcjonowanie aplikacji Java­ Server Faces. W kolejnych rozdziałach dokonamy szczegółowej analizy poszczególnych etapów cyklu życia tych aplikacji.

Komponenty zarządzane Centralnym elementem projektów aplikacji internetowych jest rozdział warstw prezentacji i logiki biznesowej. W technologii JavaServer Faces za taki rozdział odpowiadają komponenty (ang. beans ). Strony JS F odwołują się do właściwości komponentów. Kod implementacji tych komponentów definiuje właściwą logikę programu. Ponieważ właśnie komponenty są kluczem do programowania aplikacji JSF , w niniejszym rozdziale skoncentrujemy się na ich szczegółowym omówieniu. W pierwszej części tego rozdziału przeanalizujemy podstawowe elementy komponentów, 0 których powinien wiedzieć każdy programista aplikacji JS F . W dalszej części omówimy program przykładowy, który dobrze ilustruje łączne funkcjonowanie tych elementów. W pozo­ stałych podrozdziałach skupimy się na technicznych aspektach konfiguracji komponentów 1wyrażeń reprezentujących wartości. Czytelnicy, którzy mają tę książkę w rękach po raz pierwszy, mogą te podrozdziały pominąć i wrócić do nich w przyszłości.

Definicja komponentu Zgodnie ze specyfikacją JavaBeans (dostępną na stronie internetowej http://java.snn.com 'products/javabeans/) komponent Javy ma postać „wielokrotnego komponentu oprogra­ mowania, który można modyfikować za pomocą narzędzia do projektowania” . Przytoczona definicja jest bardzo szeroka, co jest o tyle zrozumiałe, że — jak się niedługo okaże — kom­ ponenty można wykorzystywać do rozmaitych celów. Na pierwszy rzut oka komponent wydaje się bardzo podobny do zwykłego obiektu Javy. Okazuje się jednak, że komponent Javy odpowiada za realizację innych zadań. Obiekty są tworzone i wykorzystywane w ramach programów Javy (odpowiednio przez wywołania konstruktorów i wywołania metod). Nieco inaczej jest w przypadku komponentów, które mogą być konfigurowane i wykorzystywane bez konieczności programowania.

46

Rozdział 2. ■ Komponenty zarządzane

JavaServer Faces

K M Część Czytelników zapewne zastanawia się, skąd się wziął angielski term in bean. ■ ¡li W Stanach Zjednoczonych słowo Java je s t synonim em kawy, a sm ak kawy kryje się w jej ziarnach (ang. beans). Opisywana analogia części programistów wydaje się wyjątkowo zmyślna, innych po prostu denerwuje — nam nie pozostaje nic innego, ja k pogodzić się z przyjętą term inologią. „Klasycznym " zastosowaniem komponentów JavaBeans jest konstruowanie interfejsów użytkownika. Okno palety oferowane przez narzędzia do projektowania takich interfejsów obejmuje takie komponenty jak pola tekstowe, suwaki, pola wyboru itp. Zamiast samodzielnie pisać kod Swinga, korzystamy z narzędzia do projektowania interfejsu, który umożliwia nam przeciąganie komponentów dostępnych na palecie i upuszczanie ich na tworzonym formu­ larzu. Możemy następnie dostosowywać właściwości tych komponentów przez ustawianie odpowiednich wartości w odpowiednim oknie dialogowym (patrz rysunek 2.1).

Dostosowywanie komponentu do potrzeb aplikacji za pośrednictwem narzędzia do projektowania graficznego interfejsu użytkownika

Ftie Edit View Navigate

A „ / s»

Retactor Borta Run CVS foob Window Help

0y ë i S ? A

„.ectojj s'Veic«» » j Ö Newjf-i-ame ,a>n ’

** 1



Jak widać, programista aplikacji JavaServer Faces nie musi pisać żadnego kodu konstruującego i operującego na komponencie user. Za konstruowanie komponentów zgodnie z elementami zdefiniowanymi w znaczniku managed bean (w ramach pliku konfiguracyjnego) odpowiada implementacja JS F . W aplikacjach JS F komponenty są zwykle wykorzystywane do następujących celów: ■ w roli komponentów interfejsu użytkownika (w formie tradycyjnych komponentów interfejsu); w roli elementów łączących w jedną całość zachowanie formularza internetowego (są to tzw. komponenty wspomagające; ang. baeking beans):

■ w roli obiektów biznesowych, których właściwości są wyświetlane na stronach W W W ;

# S3

! I Palette

»[

Do tak zdefiniowanego komponentu JavaBean można uzyskiwać dostęp z poziomu kompo­ nentów JSF. Na przykład poniższe pole tekstowe odczytuje i aktualizuje właściwość password komponentu user:

a

MËÊÈÈSÊÊÈ m

'Ęi NetBeans IDE 5.5,1 -)avaApplication!

Rysunek 2.1.

47

Swing

& A P ;

-» 'Labę1

¡1

GS> Button

i l

■ w roli takich usług jak zewnętrzne źródła danych wymagające skonfigurowania w momencie wdrażania aplikacji.

Ci, PoggieBuccon JCne,.KBo> r 1

.■'lexcfifiiai. i l«Atheia2 ■ j Zaiogu)

!'■'

JPadioBuron

Z uwagi na wszechobecność i uniwersalność komponentów skoncentrujemy się wyłącznie na tych elementach specyfikacji JavaBeans, które znajdują zastosowanie z perspektywy programistów aplikacji JavaServer Faces.

BUtCOPbtOuO

j a t iComDoBo^

-

{ r_i HextP'eid ■jButtonl IJButton]

ss :

Properties Code

•-CProperties

A

■ nl IP

naukątouna

*

□

QOs j O

action

componentPop1ipMeni.. [

D »U

j

t.jnt

i on,.,ma 11 p|am

□

foreground

■ 10,0 LI] null

0

ï

0

}

Zalodui

n

mnemonic (int) the keyboard character mnemonic

Właściwości komponentu

i I

T 1 m

Klasy komponentów muszą być tworzone w zgodzie z pewnymi konwencjami programowania, aby odpowiednie narzędzia mogły swobodnie operować na ich składowych. W niniejszym punkcie zajmiemy się właśnie tymi konwencjami.

1

Do najważniejszych elementów klasy komponentu należą udostępniane właściwości. Właściwością jest każdy atrybut komponentu, który obejmuje: W technologii JavaServer Faces zadania komponentów nie kończą się na obsłudze elementów interfejsu użytkownika. Stosujemy je za każdym razem, gdy musimy wiązać klasy Javy ze stronami W W W lub plikami konfiguracyjnymi.

■ nazwę, ■ typ, ■ metody zwracające i (lub) ustawiające wartość tej właściwości.

Wróćmy na chwilę do aplikacji login przedstawionej w podrozdziale „Prosty przykład” w roz­ dziale 1. Egzemplarz komponentu UserBean skonfigurowano w pliku faces-config.xml\ user com.corejsf.UserBean session

Znaczenie tych zapisów można by wyrazić następującymi słowami: skonstruuj obiekt klasy com.corejsf .UserBean, nadaj mu nazwę user i utrzymuj go przy życiu w czasie trwania sesji (czyli dla wszystkich żądań wygenerowanych przez tego samego klienta).

Na przykład klasa UserBean zdefiniowana i wykorzystywana w poprzednim przykładzie zawiera właściwość typu S tri ng nazwaną password. Za zapewnianie dostępu do wartości tej właściwości odpowiadają metody getPassword i setPassword. Niektóre języki programowania, w szczególności Visual Basic i C#, oferują bezpośrednią obsługę właściwości. Z drugiej strony, w języku Java komponent ma postać zwykłej klasy zaimplementowanej zgodnie z pewnymi konwencjami kodowania.

48

JavaServer Faces Specyfikacja JavaBeans definiuje pojedyncze wymaganie stawiane klasom komponentów — każda taka klasa musi definiować publiczny konstruktor domyślny, czyli konstruktor bezparametrowy. Z drugiej strony, aby definiowanie właściwości było możliwe, twórca kompo­ nentu musi albo stosować wzorzec nazewniczy dla metod zwracających i ustawiających, albo definiować deskryptory właściwości. Drugi model jest dość kłopotliwy i nie zyskał popu­ larności, więc nie będziemy się nim zajmować. Szczegółowe omówienie tego zagadnienia można znaleźć w rozdziale 8. książki Core Java™ 2. vol. 2 — Advanced Features (7th ed.)1 autorstwa Caya Horstmanna i Gary'ego Cornelia. Definiowanie właściwości w zgodzie ze wzorcami nazewniczymi jest bardzo proste. Prze­ analizujmy teraz następującą parę metod: pub 1tc J getFoo() pub 11 c void setFoo { I newvalue)

Przedstawiona para definiuje właściwość dostępną do odczytu i zapisu, typu T, nazwaną foo. Gdybyśmy użyli tylko pierwszej z powyższych metod, nasza właściwość byłaby dostępna tylko do odczytu. Pozostawienie samej drugiej metody oznaczałoby, że jest to właściwość dostępna tylko do zapisu. Nazwy i sygnatury metod muszą gwarantować pełną zgodność z tym wzorcem. Nazwa metody musi się rozpoczynać od przedrostka get lub set. Metoda get nie może otrzymywać żadnych parametrów. Metoda set musi otrzymywać jeden parametr, ale nie może zwracać żadnych wartości. Klasa komponentu może zawierać inne metody (odbiegające od opisanej konwencji), które jednak nie definiują dodatkowych właściwości.

Rozdział 2. ■ Komponenty zarządzane

49

P M | Specyfikacja JavaBeans przewiduje też możliwość stosowania właściwości indekktóry przed­ stawiono poniżej:

■¡¡3 sowanych definiowanych w formie zbiorów metod podobnych do tego, public public public public

713 getFooO 7 getFoodnt index) void setFoo(7I] newArray) void setFoo(int index. T newValue)

Okazuje się jed n ak, że technologia JSF nie zapewnia obsługi operacji dostępu do in­ deksowanych wartości. Klasa komponentu może też zawierać metody inne niż te odpowiedzialne za zwracanie i ustawianie wartości właściwości. Takie metody oczywiście nie definiują kolejnych wła­ ściwości komponentu.

Wyrażenia reprezentujące wartości Wiele komponentów interfejsu użytkownika aplikacji JS F definiuje atrybut val ue, który umoż­ liwia określanie wartości bądź odwołania do wartości uzyskiwanej z właściwości komponentu JavaBean. Wartość stosowaną bezpośrednio można zdefiniować na przykład w następujący sposób:

Można też użyć wyrażenia reprezentującego wartość:

Warto pamiętać, że nazwa samej właściwości jest identyczna jak nazwa metod uzyskujących dostęp do jej wartości po usunięciu przedrostka get lub set oraz zamianie pierwszej litery na małą. Tworząc na przykład metodę get Foo, definiujemy właściwość nazwaną foo (z pierw­ szą literą F zamienioną na f). Jeśli jednak za przedrostkiem znajdują się co najmniej dwie wielkie litery, pierwsza litera nazwy właściwości pozostaje niezmieniona. Na przykład metoda nazwana get URL definiuje właściwość URL, nie uRL.

W większości przypadków wyrażenia podobne do #{user. name} odwołują się do właściwości. Warto pamiętać, że wyrażenie w tej formie może być stosowane nie tylko do odczytywania wartości, ale też do ich zapisywania, jeśli zostanie użyte dla komponentu wejściowego:

W przypadku właściwości typu boolean mamy do wyboru dwa różne prefiksy dla metod zwracających ich wartości. Obie wersje:

W momencie renderowania danego komponentu zostanie wywołana metoda zwracająca właściwość będącą przedmiotem odwołania. Metoda ustawiająca zostanie wywołana w czasie przetwarzania odpowiedzi użytkownika.



public boolean lsCcmnecteclO

i public boolean get Connected O

są prawidłowymi nazwami metod zwracających wartość właściwości connected. Specyfikacja JavaBeans milczy na temat zachowań metod zwracających i ustawiających. W wielu przypadkach działanie tych metod sprowadza się do prostego operowania na polach egzemplarza. Z drugiej strony, te same metody mogą równie dobrze obejmować bardziej wyszukane operacje, jak dostęp do bazy danych, konwersję danych, weryfikację danych itd.

1 Polskie wydanie: Java 2. Techniki zaawansowane. Wydanie IL Helion, 2005 — przyp. tłum.

Wyrażenia reprezentujące wartości stosowane w aplikacjach JSF m ają ścisły związek z językiem wyrażeń znanym z technologii JSP. Dla tego rodzaju wyrażeń stosuje się je d n a k separator (zam iast sep arato ra # { . . . } ) , W stan d ardach JSF 1 .2 i JSP 1 .2 zunifikowano składnię obu języków wyrażeń. (Kom pletną analizę tej składni można znaleźć w podrozdziale „Składnia wyrażeń reprezentujących w artości”).

liii

Separator $ { . . . } oznacza, że dane wyrażenie ma zostać przetworzone natychmiast, czyli w czasie przetwarzania odpowiedniej strony przez serwer aplikacji. Separator # { . . . } sto­ suje się dla wyrażeń, które m ają być przetwarzane możliwie późno. W takim przypadku serwer aplikacji zachowuje wyrażenie w niezmienionej formie i przystępuje do jego prze­ twarzania dopiero wtedy, gdy odpowiednia wartość je s t naprawdę potrzebna. W arto pam iętać, że wyrażenia odroczone stosuje się dla wszystkich właściwości kom ­ ponentów JSF, natom iast wyrażenia przetwarzane natychm iast są wykorzystywane dla tradycyjnych konstrukcji JSP lub JSTL (od ang. Java$erver Pages Standard Template Library), które rzadko są niezbędne w procesie tworzenia stron JSF.

50

JavaServer Faces

Rozdział 2. ■ Komponenty zarządzane

Szczegółowe omówienie składni wyrażeń reprezentujących wartości można znaleźć w pod­ rozdziale „Składnia wyrażeń reprezentujących wartości".

To wszystko, czego nam trzeba! Kjedy zdecydujemy się na lokalizację naszej aplikacji z myślą o innych ustawieniach regionalnych, będziemy musieli tylko opracować odpowiednie pliki z komunikatami.

Pakiety komunikatów

K M Element resource-bundle zapewnia większą efektywność niż elem ent f:loadBundie, ■ H ponieważ zapew nia, że pakiet kom unikatów będzie odczytywany jednorazow o dla całej aplikacji. W arto jedn ak pam iętać, że elem ent resource-bundl e je s t obsługiwany, począwszy od wersji JSF 1 .2 . Oznacza to, że jeśli chcem y zapew nić zgodność naszej aplikacji ze specyfikacją JSF 1 . 1, m usimy się posługiwać elem entem f: loadBundie.

Implementując aplikację internetową, warto rozważyć zgromadzenie wszystkich łańcuchów komunikatów w jednym, centralnym miejscu. Taki proces ułatwi zachowanie spójności komunikatów i — co bardzo ważne — upraszcza lokalizowanie (internacjonalizację) apli­ kacji z myślą o -wnych ustawieniach regionalnych. W tym podrozdziale przeanalizujemy mechanizmy lecnnologii JS F umożliwiające organizację komunikatów. W podrozdziale „Przy­ kładowa aplikacja" przeanalizujemy przykład komponentów zarządzanych pracujących łącznie z pakietami komunikatów.

Lokalizując pakiety komunikatów, musimy nadawać odpowiednim plikom nazwy z przy­ rostkiem właściwym dla ustawień regionalnych, czyli dwuliterowego kodu języka (zgodnego ze standardem iSO-639) poprzedzonego znakiem podkreślenia. Na przykład łańcuchy w języku niemieckim należałoby zdefiniować w pliku com/corejsf/messciges de.properties.

Łańcuchy komunikatów należy zebrać w pliku, którego format odpowiada przyjętemu porząd­ kowi chronologicznemu: guessNextOdgadnij następny

51

Listę wszystkich dwu- i trzyliterowych kodów języków standardu IS O -6 3 9 m ożna znaleźć na stronie internetowej http://www.loc.gov/standards/iso639-2/ .

IlczDę w s e k w e n c ji !

answe^Twoja odpowiedz

Mechanizmy obsługi umiędzynarodawiania aplikacji Javy automatycznie ładują pakiety komunikatów właściwe dla bieżących ustawień regionalnych. Pakiet domyślny (bez przy­ rostka języka ISO-639) jest swoistym zabezpieczeniem na wypadek, gdyby zlokalizowany pakiet był niedostępny. Szczegółowe omówienie problemu umiędzynarodawiania aplikacji Javy można znaleźć w rozdziale 10. książki Core Java™ 2, vol. 2 — Advanced Features (7th ed.)2 autorstwa Caya Florstmanna i Gary‘ego Cornelia.

I Precyzyjne om ów ienie form atu tego pliku m ożna znaleźć w dokum entacji API dla I metody load klasy ja v a .u t il .Properties. Należy ten plik zapisać w katalogu, w którym składujemy klasy — np. jako /nsrc/java/com/ ^ c o r e jsk messages.properties. Można oczywiście wybrać dowolną ścieżkę do katalogu i nazwę piiku, jednak musimy użyć rozszerzenia .properties.

Przygotowując tłumaczenia aplikacji, należy mieć na uwadze jeden dość specyficzny

■ i i aspekt — pliki pakietów komunikatów nie są kodowane z wykorzystaniem schematu UTF-8 . Znaki Unicode spoza zbioru pierwszych 1 2 7 znaków są kodowane za pom ocą

Pakiety komunikatów możemy deklarować na dwa sposoby. Najprostszym rozwiązaniem jest umieszczenie następujących elementów w pliku konfiguracyjnym faees-eonftg.xmk.

sekw encji specjalnej \uxxxx. Tego rodzaju pliki m ożna tworzyć za pom ocą narzędzia native2ascii pakietu Java SDK.



;resOurce-Dundle> com co^ ej sf messages <'var>msgs

Dla tych samych ustawień regionalnych może istnieć wiele pakietów komunikatów. Możemy na przykład opracować odrębne pakiety dla najczęściej wykorzystywanych komunikatów o błędach.





Alternatywnym rozwiązaniem jest dodanie elementu f ■1oacIBunct 1e do każdej strony JavaServer Faces wymagającej dostępu do danego pakietu komunikatów:

Komunikaty obejmujące zmienne



Komunikaty często obejmują elementy zmienne, które — co oczywiste — wymagają w y­ pełnienia przed wyświetleniem. Przypuśćmy na przykład, że chcemy wyświetlić na ekranie zdanie Masz n punktów , gdzie a? jest wanością uzyskiwaną z komponentu. W tym celu musimy utworzyć łańcuch źródłowy z symbolem zastępczym:

W obu przypadkach dostęp do komunikatów wchodzących w skład pakietu odbywa się za pośrednictwem zmiennej odwzorowania (mapy) nazwanej msgs. (Nazwa bazowa, czyli com.corejsf .messages, przypomina nazwę klasy i rzeczywiście okazuje się, że plik właści­ wości jest wczytywany przez mechanizm ładowania klas).

CurrentScore=MdSZ |0} plinkiow

Możemy teraz uzyskiwać dostęp do łańcuchów komunikatów w ramach wyrażeń reprezen­ tujących wartości: < h: o u tp u tT e x t

v a l u e = "# {m s g s . g u e s s N e x t } "/>

2

Polskie wydanie: Java 2. Techniki zaawansowane. Wydanie //, Helion, 2005 — przyp. tłum.

52

JavaServer Faces Symbole zastępcze (ang. placehorders) mają postać {0}, {1}, {2} itd. W kodzie naszej strony JS F powinniśmy użyć znacznika h : outputFormat i zdefiniować wartości dla tych symboli zastępczych w formie elementów potomnych f : param:

Rozdział 2. ■ Komponenty zarządzane 1- Możemy pozostawić wybór ustawień regionalnych przeglądarce. Ustawienia domyślne i wszystkie ustawienia obsługiwane należy zdefiniować w pliku konfiguracyjnym WEB-INF/faces-config.xmI (lub innym zasobie konfiguracyjnym aplikacji): pl de

Znacznik h: outputFormat wykorzystuje do formatowania łańcuchów komunikatów klasę MessageFormat biblioteki standardowej. Wspomniana klasa oferuje szereg mechanizmów opracowanych z myślą o formatowaniu łańcuchów zależnych od ustawień regionalnych. Za pomocą przyrostka number, currency dołączanego do symbolu zastępczego możemy formatować liczby jako kwoty w lokalnej walucie:

Kiedy przeglądarka nawiązuje połączenie z naszą aplikacją, zwykle dołącza do nagłówka protokołu HTTP wartość Accept -Language (patrz http://www.w3.org/ W htemational/questions/qa-aceept-lang-locales.htmI). Implementacja technologii JavaServer Faces odczytuje ten nagłówek i odnajduje najlepsze dopasowanie wśród obsługiwanych ustawień regionalnych. Możemy sprawdzić funkcjonowanie tego mechanizmu, ustawiając język preferowany w swojej przeglądarce (patrz rysunek 2.2).

currentTotal =Dysponujesz kwotc} {0 .number.currency}

W Stanach Zjednoczonych wartość 1023.95 zostanie sformatowana jako $1,023.95. Ta sama wartość w Niemczech zostałaby wyświetlona jako € 1.023,95 (w Polsce 1 023,95 zl) — z uwzględnieniem symbolu lokalnej waluty i konwencji separatora części dziesiętnej. Format choice umożliwia nam Formatowanie liczb na różne sposoby (w zależności od wartości poprzedzającej jednostkę), czyli: zero punktów, jeden punkt, dwa punkty, 3 punkty, 4 punkty, 5 punktów itd. Poniżej przedstawiono łańcuch formatu zapewniający oczekiwany efekt: currentScore=Mesz {0 .choice,0#zero punktów|1#jeden purikt|2#dwa punkty|3#trzy punkty |4#cztery punkty|5#{0} punktów}

Rysunek 2.2.

Języki

Wybór preferowanego języka

f -S

Niektóre srrony WV»Ajv dostępu

lęsyfcounyc» U^tai lute P^erowanych fezyi-onnr ctia Teqo rodzaju

lezyk'-n,p>efero«vane( koiej^oseD Uk. [pij

Ntemiecli/Nienjcv [de-del

1

j N'eP-'eCk- [de]

Łatwo zauważyć, że symbol zastępczy 0 występuje dwukrotnie: raz na etapie wyboru formatu i drugi raz w ostatniej, szóstej opcji, gdzie generuje wynik w postaci komunikatu 5 punktów.

Dodatkowych informacji na temat klasy MessageFormat należy szukać w dokumentacji A P I lub w rozdziale 10. książki Core Java™ 2, vol. 2 — Advanced Features (7th e d .f autorstwa Caya Horstmanna i Gary’ego Cornelia.

lif iJ S iJ

Angie' ki/Staru Zienr"-.^T0r,r len-,ul *r,gie|.k. len]

Mamy do czynienia z sześcioma możliwymi przypadkami (0, l, 2, 3, 4 oraz >5), z których każdy definiuje odrębny łańcuch komunikatu.

Przykłady użycia tej konstrukcji można znaleźć na listingach 2.5 i 2.6 w podrozdziale „Przy­ kładowa aplikacja” . O ile angielskie ustawienia regionalne (z komunikatem Your score is ...) w ogóle nie wymagają stosowania formatu choice w naszej przykładowej aplikacji, o tyle niemieckie wyrażenie Sie haben ... punkte (podobnie jak polskie Masz ... punktów) nie jest uniwersalne, ponieważ nie uwzględnia liczby pojedynczej einen punkt.

1

w wetu uuers^th

L ii /

| ]

Anuluj

I

i |

tiiun

|

Doclaj

~]

Poniec__j

2. Możemy dodać atrybut 1oca 1e do elementu f : vi ew — oto przykład:

Ustawienia regionalne można też określać dynamicznie:

Kod reprezentujący ustawienia regionalne ma teraz postać łańcucha zwracanego przez metodę getLocal e. Takie rozwiązanie jest wygodne w przypadku aplikacji, które umożliwiają użytkownikowi wybór preferowanych ustawień.

3. Ustawienia regionalne można też definiować programowo. W tym celu wystarczy

Konfigurowanie ustawień regionalnych aplikacji Po opracowaniu pakietów komunikatów musimy zdecydować, jak zdefiniować ustawienia regionalne naszej aplikacji. Mamy do dyspozycji trzy rozwiązania:

3 Polskie wydanie: Java 2. Techniki zaawansowane. Wydanie II, Helion, 2005 — przyp. tłum.

wywołać metodę setLocale obiektu klasy UIViewRoot: UIViewRoot viewRoot = FacesContext.getCurrentInstance() .getViewRoot(); viewRoot.setLocale(new LocaleCde"));

Przykład praktycznego użycia tego mechanizmu można znaleźć w punkcie „Stosowanie łączy poleceń” w rozdziale 4.

53

54

JavaServer Faces

Rozdział 2. ■ Komponenty zarządzane Listing 2.1. Kod zdefiniowany w pliku numberquiz/src/java/com/corejsf/ProblemBean.java

Przykładowa aplikacja Po omówieniu tych dość abstrakcyjnych reguł i obostrzeń warto przystąpić do analizy kon­ kretnego przykładu. Działanie naszej aplikacji będzie się sprowadzało do prezentowania szere­ gu pytań swoistego quizu. Każde z nich będzie obejmowało sekwencję cyfr i wymagało od użytkownika wskazania kolejnej cyfry danej sekwencji. Na rysunku 2.3 przedstawiono przykładowy ekran aplikacji z prośbą o podanie kolejnej liczby dla następującej sekwencji: 3 14 15 Quiz liczbowy

Rysunek 2.3. Quiz liczbowy

Pilic

fcctycja

Vf|§ * ¿1p

-

[o j©

Mozilte Firefox

Wtdok ||f

55

Historo fj| !

¿aktadki

Narzędzia

Pomoc

http://loca1host:808O/t.wrrtLerquiz, i , d e . . f a | * ^ | ; f l r ł

8

■

y

1 package com.corejsf, 2 import java.util.ArrayList. 3 4. public class ProblemBean { 5 private ArrayList sequence, 6 private int solution; 7 8 public ProblemBean() {} 9 10. public ProblemBean(int[] values, int solution) { 11 sequence = new ArrayList(), 12. for (int i = 0. i < values length, i++) 13 sequence add(valuesfi]) 14

O

if iie

Milej zabawy z programem Quiz liczbowy! Tw o i wynik 11

t n is

SO

łut ion =

SO

1ution

IB 16

)

17

18

// właściwość sequence. public ArrayList geiSequencet ) { return sequence

19

publ ic void se tSeque nc e( Ar ra yL is t< lntege r> newValue) { sequence = newValue

} 1

20

Zgadmi. idka będzie następna li.-z1 a tej s^kwcn« 11 ‘

21

p 1. . 1 1 4 4 1 i TUJ

// właściwość solution. pu blic int g e t S o l u t i o n ( ) { retunn so l u t i o n . }

22 23

T woi a ■dj'-wiMz

24

publ ic void s e t S o l u t i o n ( i n t

newValue)

{

so lu t io n = newValue

\

}

i Daiej 1

Zafconczcmo

----------

Musimy teraz zdefiniować właściwy komponent quizu z następującymi właściwościami:

Podobne łamigłówki często są stosowane w testach na inteligencję. Rozwiązanie tej zagadki wymaga znalezienia pewnego wzorca (w tym przypadku mamy do czynienia z pierwszymi cyframi liczby n).

■

problems: właściwość dostępna tylko do zapisu i reprezentująca pytania quizu;

■

score: właściwość dostępna tylko do odczytu i reprezentująca bieżącą punktację;

Kiedy prawidłowo określimy kolejną cyfrę tej sekwencji (w tym przypadku 9), nasz wynik zostanie powiększony o jeden punkt.

■

istnieje angielski zwrot (wprost idealnie pasujący do środowisk opartych na Javie), którego zapamiętanie ułatwia identyfikację pierwszych ośmiu cyfr liczby r . Can I have a small container of coffee? Wystarczy policzyć litery w kolejnych wyrazach, aby otrzymać sekw encję 3 1 4 1 5 9 2 6. W ięcej inform acji o podobnych konstrukcjach m ożna znaleźć na stronie internetowej http://dir.yahoo.com/Science/Mathematlcs/Numerical y*_Analysi$/Numbers/Specific_Numbers/Pi/Mnemonics/ MĘ . "Ji . ■ ■ : W naszym przykładzie kolejne pytania zaimplementujemy w klasie QuizBean. W rzeczywistej aplikacji najprawdopodobniej wykorzystalibyśmy bazę danych do składowania tego rodzaju informacji. Celem tego przykładu jest jednak demonstracja sposobu wykorzystywania kom­ ponentów JavaBeans o złożonej strukturze. W pierwszej kolejności przeanalizujemy kod klasy Prob 1emBean, która definiuje dwie wła­ ściwości: solution typu mt oraz sequence typu ArrayList (patrz listing 2.1).

■ current: właściwość dostępna tylko do odczytu i reprezentująca bieżące pytanie; answer: właściwość umożliwiająca odczyt i zapis bieżącej odpowiedzi podanej

przez użytkownika. Właściwość problems w ogóle nie jest wykorzystywana przez nasz przykładowy program — ograniczamy się do inicjalizacji zbioru problemów w konstruktorze klasy QuizBean. Z drugiej strony, w punkcie „Wiązanie definicji komponentów” w dalszej części tego roz­ działu omówimy sposób definiowania zbioru problemów wewnątrz pliku faees-config.xml , a więc bez konieczności pisania jakiegokolwiek kodu. Właściwość current jest wykorzystywana do wyświetlania bieżącego problemu. Warto jednak pamiętać, że wspomniana właściwość reprezentuje obiekt klasy ProblemBean, którego nie możemy bezpośrednio wyświetlać w polu tekstowym. W związku z tym sekwencję liczb uzyskujemy za pośrednictwem jeszcze jednej właściwości: < n.output Text

va 1u e = " # { q u i z . c u r r e n t . s e q u e n c e } " / >

Właściwość sequence reprezentuje wartość typu ArrayList. W procesie wyświetlania można ją przekonwertować na łańcuch, wywołując metodę toStnng. W wyniku tego wywołania otrzymamy następujący łańcuch wynikowy: [3, 1, 4, 1, 5]

56

JavaServer Faces

Rozdział 2. ■ Komponenty zarządzane

I wreszcie musimy się zmierzyć z problemem obsługi właściwości answer. W pierwszej kolejności wiążemy ją z polem tekstowym formularza:

W momencie wyświetlania tego pola tekstowego następuje wywołanie metody zwracającej getAnswer, którą zaimplementowano w taki sposób, aby zwracała pusty łańcuch. Po wysłaniu formularza implementacja JS F wywołuje metodę ustawiającą, przekazując na jej wejściu wartość wpisaną przez użytkownika w tym polu tekstowym. Metoda setAnswer sprawdza odpowiedź, aktualizuje wynik punktowy (w przypadku prawidłowej decyzji użytkownika) i przechodzi do kolejnego problemu.

Na tym możemy zakończyć analizę naszej przykładowej aplikacji. Na rysunku 2.5 przedsta­ wiono strukturę katalogów. Pozostały kod źródłowy przedstawiono na listingach od 2.2 do 2.6.

Rysunek 2.5.

£3 numberquiz.war

f ES

Struktura katalogów przykładowej aplikacji łamigłówki liczbowej

meta-inf

j

'

f

£ 3 W EB-INF

j

f

£ 3 classes

j

j

f

D M ANIFEST.MF

IS

public void setAnswer(String newValue) { try { int answer = Integer.parseInt(newValue.trimO); if (getCurrent() ,getSolution() == answer) score++; currentlndex = (currentlndex + 1) % problems.size();

£3 com F £ü2 corejsf \

Q ProblemBean.class

F

D QuizBean. class

I

I

|

j..................Q messages_de. properties

| D messages.properties

| Q faces-config.xml ‘ Q web.xml D ¡ndex.html

; D index.jsp_____________________

}

catch (NumberFormatException ex) {

Umieszczanie w metodzie ustawiającej wartość właściwości kodu niezwiązanego z jej ory­ ginalnym przeznaczeniem nie jest najlepszym rozwiązaniem. Operacje aktualizacji wyniku i przejścia do kolejnego problemu powinny być realizowane przez metodę obsługującą akcję kliknięcia przycisku. Ponieważ jednak nie analizowaliśmy mechanizmów reagujących na tego rodzaju zdarzenia, na razie będziemy korzystać z elastyczności oferowanej przez metody ustawiające. Inną wadą naszej przykładowej aplikacji jest brak mechanizmu przerywania działania po ostatnim pytaniu ąuizu. Ograniczyliśmy się do rozwiązania polegającego na powrocie do pierwszej strony, aby umożliwić użytkownikowi uzyskiwanie coraz lepszych rezultatów. W następnym rozdziale omówimy sposób implementacji lepszego modelu. Warto raz jeszcze przypomnieć, że celem tej aplikacji jest pokazanie, jak w praktyce konfigurować i wyko­ rzystywać komponenty.

Listing 2.2. Zawartość pliku numberquiz/web/index.jsp 1. 2. taglib uri="http://java.sun.com/jsf/html " prefix="h" %> 3. taglib uri="http://java.sun.com/jsf/core" prefix="f" £> 4_ 5. 6. 7. 8 9. 10. 11.

12. 13.

14.

15. 16. 17. 18. 19.

20. 21.

22.

23. 24.

25.

26 27

28.

29. 31. 32. 33 34. l

A C V

Na koniec warto zwrócić uwagę na mechanizm umiędzynarodowienia naszej aplikacji przez opracowanie dodatkowych pakietów komunikatów. Zachęcamy do przełączenia przeglądarki na język niemiecki, aby naszym oczom ukazał się ekran podobny do tego z rysunku 2.4.

Rysunek 2.4. Viel SpaS mit dem Zahlenquiz!

Raten Sie die nächste Zahl in der Folge I

57

58

Rozdział 2. ■ Komponenty zarządzane

JavaServer Faces

Listing 2.3. Zawartość pliku numberquiz/src/java/com/corejsf/QuizBean.java 1 package com.corejsf. 2 import java.util.ArrayList. 3 4. public class QuizBean { 5 private ArrayList problems = new ArrayList(). 6 private int currentlndex: 7 private int score. 8

9 10 11 12. 13 14 15 16

public QuizBeanO { problems.add( new ProblemBeanCnew in t[] { 3, 1. 4, 1. 5 }, 9)) //liczbapi problems.add( new ProblemBeanCnew in t[] { 1, 1, 2. 3. 5 }. 8)), //ciągFibonacciego problems.add( new ProblemBeanCnew in t[] { 1, 4. 9, 16, 25 }. 36)), //kwadraty problems.add(

17

new ProblemBeanCnew i n t [ ] { 2.

18 19

problems.add( new ProblemBeanCnew i nt [] { 1.

20

21. 22 23 24 25 26 27 28 29. 30 31 32 33. 34 35. 36 37 38 39 40. 41. 42 43 44 45 46 47 48. }

3, 5, 7,

11 },

1 3 )), // liczby pierwsze

2. 4. 8, 16 }. 32)). //potęgi dwójki

} // Właściwość problems: public void setProblems(ArrayList newValue) { problems = newValue: currentlndex = 0: score = 0. } // Właściwość score: public int getScoreC)

4 xsi •schemaLocation="http://java.sun.coni/xml /ns/javaee 5 http://java.sun.com/xml/ns/javaee/web-facesconfig_l_2.xsd" 6 version="l,2"> 7 8 9 pl 10 de 11 12 13 14. 15 /index.jsp 16 17 next 18 /index.jsp 19. 20 21. 22 23 quiz 24. com.corejsf.QuizBean 25 session 26. 27. 28. 29 30. com.corejsf,messages 31. msgs 32 33. 34

{ return score, }

// Właściwość current: public ProbleniBean getCurrentO { return problems.get(currentlndex); } // Właściwość answer: public String getAnswerO { return } public void setAnswerCString newValue) { try { int answer = Integer.parselntCnewValue.trimO), i f CgetCurrentC) .getSolutionC) == answer) score++, currentlndex = (currentlndex + 1) % problems.size(), } catch (NumberFormatException ex) { } }

Listing 2.4. Zawartość pliku numberquiz/web/WEB-INF/faces-config.xml 1. 2.
Listing 2.5. Zawartość pliku numberquiz/src/java/com/corejsf/messages.properties 1 2 3 4 5. 6

ti1 1e=Quiz liczbowy heading=Miłej zabawy z programem Quiz liczbowy! currentScore=Twój wynik: {0}. guessNext=Zgadnij. jaka będzie następna liczba tej sekwencji! answer=Twoja odpowiedź. next=Dalej

Listing 2.6. Zawartość pliku numberquiz/src/java/com/corejsf/messsages_de.properties 1. 2 3. 4 5. 6.

ti tle=Zahlenqui z heading=Viel Spa\uOOdf mit dem Zahlenquiz! currentScore=Sie haben (0,choice,0#0 Punkte|l#einen Punkt|2#{0} Punkte} guessNext=Raten Sie die n\u00e4chste Zahl in der Folge! answer=Ihre Antwort. next=Weiter

59

60

Rozdział 2. n Komponenty zarządzane

JavaServer Faces

Komponenty wspierające W niektórych sytuacjach najwygodniejszym rozwiązaniem jest zaprojektowanie kompo­ nentu obejmującego wybraną część lub wszystkie obiekty komponentów właściwe dla danego formularza W W W . Taki komponent określa się mianem komponentu wspierającego, wspo­ magającego (ang. backing bean). Możemy zdefiniować komponent wspierający dla formularza quizu przez dodanie odpo­ wiednich właściwości do komponentu tego formularza: public class QuizFormBean { private UlOutput scoreComponent, private UIInput answerComponent; // Właściwość scoreComponent: public UIQutput getScoreComponent() { return scoreComponent. } public void setScoreComponentdJIOutput newValue) { scoreComponent = newValue, } // Właściwość answerComponent: public UIInput getAnswerComponentO { return answerComponent. } public void setAnswerComponent(UIInput newValue) { answerComponent = newValue. }

} Komponenty wyjściowe interfejsu użytkownika należą do klasy UlOutput, natomiast kom­ ponenty wejściowe należą do klasy UI Input. Obie te klasy szczegółowo omówimy w punkcie „Zestaw narzędzi programisty komponentów niestandardowych” w rozdziale 9. Po co właściwie mielibyśmy tworzyć tego rodzaju komponenty? Podczas lektury punktu „W eryfikacja relacji łączących wiele komponentów” w rozdziale 6. Czytelnicy dowiedzą się, że w niektórych przypadkach mechanizmy weryfikujące i obsługujące zdarzenia muszą mieć dostęp do komponentów interfejsu użytkownika na formularzu. Co więcej, komponenty 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 JS F . 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:

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 odpowiedź, 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

..

U l Ciasteczka

SzuKd) ! Na tym tom p u tętze przechow yw ane są •'>astępu1actr ctasceczica

Nazwa cia^teczla

N a w a : ‘.SESSION®



Zawartość: c 2 1 4 5 b2 2 d d b6b h a ia 4f3 ?5 6 60d 40 Host: tocałhost Ścieżka; /lo g io

Po skonstruowaniu drzewa komponentów dla danego formularza następuje wywołanie metody getSconeComponent komponentu wspomagającego, która jednak zwraca wartość nul 1. Oznacza

to, że komponent wyjściowy jest konstruowany i instalowany w ramach tego komponentu wspierającego za pomocą metody setSconeComponent. 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.

Wyślij dla; D ow olny rodzaj połączenia W ygasa: na końcu sesji Usuń c

U5g$|łs®,j

¡UJsun wszystkie ciasteczka j

I

Zamkną

Dopóki klient nie dezaktywuje znaczników kontekstu, serwer będzie otrzymywał identyfikator sesji wraz z kolejnymi żądaniami tego klienta.

62

Rozdział 2. n Komponenty zarządzane

JavaServer Faces Serwery aplikacji wykorzystują leż strategie alternatywne (np. polegające na przepisywaniu adresów U R L) do obsługi sesji nawiązywanych przez aplikacje klienckie, które nie zwra­ cają znaczników kontekstu klienta. Strategia przepisywania adresów U R L sprowadza się do dodawania do każdego adresu U R L identyfikatora sesji podobnego do poniższego: http / / corejsf com/ logm/mele* jsp. jses siom d-=P55cd6

d8e

też nie zdaje egzaminu w sytuacji, gdy chcemy zachowywać niezbędne dane pomiędzy żądaniami. W zasięgu żądania powinniśmy umieszczać obiekty tylko wtedy, gdy chcemy je przekazywać do innej fazy przetwarzania w ramach bieżącego żądania. Na przykład znacznik f ■loadBundle umieszcza w zasięgu żądania zmienną pakietu komu­ nikatów, która jest potrzebna tylko w czasie trwania fazy wizualizacji odpowiedzi dla tego samego żądania.

Aby zweryfikować funkcjonowanie tego m odelu, warto wymusić na przeglądarce B iga odrzucanie znaczników kontekstu klienta z serwera localhost, po czym ponownie uruchomić naszą aplikację internetow ą i wysłać form ularz. Kolejna strona powinna zawierać atrybut js e s s io n id .

I B S Tylko kom ponenty obejm ujące zasięgiem żądania m ają charakter jednowątkowy mJm i jako takie gw arantują bezpieczeństwo wątków. Co ciekawe, jednowątkowe nie są kom ponenty sesyjne. Użytkownik może na przykład jednocześnie wysyłać odpowiedzi z wielu okien przeglądarki internetowej. Każda odpowiedź jes t przetwarzana przez odrębny wątek żądania. Gdybyśmy chcieli zapewnić bezpieczeństwo przetwarzania wielowątkowego w naszych komponentach sesyjnych, powinniśmy opracować odpowiednie mechanizmy blokowania.

Śledzenie 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 U R L 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 inval ldate 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 ShoppmgCartBean może być wypeł­ niany stopniowo wraz z otrzymywaniem kolejnych żądań składających się na sesję.

63

idnotacje cyklu życia Począwszy od wersji JS F 1.2, istnieje możliwość wskazywania metod komponentów zarzą­ dzanych, które mają być wywoływane automatycznie bezpośrednio po skonstruowaniu tych komponentów i bezpośrednio przed ich wyjściem poza odpowiedni zasięg. Takie rozwiązanie jest szczególnie wygodne w przypadku komponentów ustanawiających połączenia z zasobami zewnętrznymi, np. bazami danych. Metody komponentu zarządzanego można oznaczać adnotacjami @ P o s tC o n s tru c t lub @ P re D e s lro y : pub1ic c la s s MyBean

Komponenty obejmujące zasięgiem aplikację

\

(SPoSlConsiruCl puDl ic void im u a 11z e t ) {

// kod inicjalizujący

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 Zasięg na poziomie żądań charakteryzuje się wyjątkowo krótkim czasem życia. Jest konstru­ owany w momencie wysłania żądania protokołu HTTP i utrzymywany do momentu odesłania odpowiedzi klientowi. Jeśli umieścimy komponent zarządzany w zasięgu żądania, nowy egzemplarz tego kompo­ nentu będzie tworzony dla każdego żądania. Takie rozwiązanie jest nie tylko kosztowne, ale

} @PreDestroy public void shutdownO { // kod zamykający

} // pozostałe metody komponentu

} Tak oznaczone metody będą wywoływane automatycznie, pod warunkiem że dana aplika­ cja internetowa zostanie wdrożona w kontenerze zapewniającym obsługę standardu Java Specification Request (JS R ) 250 (patrz http://wwwjcp.org/en/jsr/detail?id=250). Adnotacje w tej formie są obsługiwane przez serwery aplikacji zgodne ze standardem Java E E 5, w tym serwer GlassFish. Oczekuje się, że w niedalekiej przyszłości adnotacje będą obsługiwane także przez kontenery autonomiczne (np. Tomcata).

64

Javaserver Faces

Konfigurowanie komponentów W niniejszym podrozdziale omówimy techniki konfigurowania komponentów w plikach konfiguracyjnych. Ponieważ szczegółowe rozwiązania w tym zakresie mają charakter ściśle techniczny, część Czytelników zapewne zdecyduje się tylko przejrzeć ten podrozdział i wrócić do niego dopiero wtedy, gdy stanie przed koniecznością skonfigurowania komponentów ze złożonymi właściwościami. Najczęściej wykorzystywanym plikiem konfiguracyjnym jest WEB~INF/faces-config.xml. Okazuje się jednak, że możemy ustawienia konfiguracyjne umieścić także w następujących miejscach: ■ W plikach nazwanych META-INF/faces~config.xml w ramach dowolnych plików JA R wczytywanych przez mechanizmy ładowania klas kontekstu zewnętrznego. (Opisywany mechanizm jest wykorzystywany w sytuacji, gdy dostarczamy komponenty wielokrotnego użytku w formie plików JA R ). ■ W plikach zdefiniowanych za pośrednictwem parametru inicjalizacji javax. faces. ^CONFIG_FILES w ramach pliku WEB-INF/web.xml. Przykład definicji tego parametru przedstawiono poniżej: javax.faces.CONFIG_FILES WEB-INF/navigation.xml,WEB-INF/beans.xml

(Opisany mechanizm jest szczególnie korzystny, jeśli korzystamy z narzędzi do projektowania oprogramowania, ponieważ skutecznie izoluje nawigację, komponenty itd.). Dla uproszczenia będziemy w tym rozdziale stosowali tylko plik konfiguracyjny WEB-INF/

^faces-config. xm /. Komponent jest konfigurowany przez element managed-bean wewnątrz elementu faces-config najwyższego poziomu. Dla każdego tak konfigurowanego komponentu musimy określić przynajmniej nazwę, klasę i zasięg: user com.corejsf.UserBean session

Zasięg może być reprezentowany przez słowa request, session, appl i cation lub none. Zasięg none oznacza, że dany obiekt nie jest utrzymywany w żadnej z trzech map zasięgów. Obiekty z tym zasięgiem wykorzystuje się w roli elementów składowych podczas wiązania skompli­ kowanych komponentów. Przykład takiego rozwiązania przeanalizujemy w punkcie „Wiązanie definicji komponentów” w dalszej części tego podrozdziału.

Rozdział 2. ■ Komponenty zarządzane

65

Ustawianie wartości właściwości Nasze rozważania rozpoczniemy od analizy prostego przykładu. Poniżej modyfikujemy egzemplarz komponentu UserBean: user com.corejsf UserBean session name ja password sekret

Kiedy komponent user jest po raz pierwszy odnajdywany, serwer aplikacji tworzy nowy egzemplarz za pomocą konstruktora domyślnego UserBeanO. Następnie są wykonywane metody setName i setPassword. Aby zainicjalizować właściwość wartością nul 1, należy użyć elementu nul 1-val ue. Przykład takiego rozwiązania przedstawiono poniżej: password

Inicjalizacja list i map Do inicjalizacji wartości typu L is t lub Map służy specjalna konstrukcja składniowa. Poniżej przedstawiono przykład inicjalizacji listy: <1ist-entries> java.lang. Integer 3 l 4 l 5

W powyższym fragmencie kodu użyto opakowania w formie typu danych java.lan g .In teg er, ponieważ struktura Li st nie może zawierać wartości typów prostych. Lista może zawierać wymieszane elementy val ue i nul 1-val ue. Element val ue-cl ass jest opcjonalny — jeśli z niego zrezygnujemy, zostanie wygenerowana lista obiektów klasy ja v a .lang.String.

66

JavaServer Faces

Rozdział 2. ■ Komponenty zarządzane

Z nieco bardziej skomplikowaną sytuacją mamy do czynienia w przypadku map. W odpo­ wiednich konstrukcjach możemy stosować opcjonalne elementy key class i value class (gdzie typem domyślnym ponownie jest klasa java 1ang. String). Musimy następnie zdefi­ niować sekwencję elementów map-entry, z których każdy obejmuje element key oraz element value lub nul 1-value. Poniżej przedstawiono przykładową konfigurację struktury typu Map: java lang I nteger ] ■walue>George washington 3 thomas Jefferson 16Apranam Lincoln< /va 1ue>

26 Tneodore Ro oseveit

Za pomocą elementów 1ist entries i niap-entnes można inicjalizować struktury managedbean lub managed property, pod warunkiem że odpowiedni komponent lub właściwość jest egzemplarzem typu List lub Map. Na rysunku 2.7 przedstawiono diagram składni definicji elementu managed bean i wszystkich jego elementów potomnych. Strzałki na tym diagramie dobrze ilustrują, które konstrukcje można stosować w ramach elementu managed-bean. Na przykład z drugiego z przedstawionych grafów wynika, że element managed-property rozpoczyna się od zera, jednego lub wielu elementów descri pti on, po których następuje zero, jeden lub wiele elementów di spl ay-name, zero, jeden lub wiele elementów icon, wymagany element property-name, opcjonalny ele­ ment property-class oraz dokładnie jeden z elementów value, null-value, map-entries lub lis t- e n trie s .

Wiązanie definicji komponentów Bardziej skomplikowane konstrukcje możemy definiować, stosując w elementach value wyrażenia reprezentujące wartości, które zwiążą ze sobą więcej komponentów. Wróćmy na chwilę do komponentu quizu użytego w aplikacji numberqui z. Quiz obejmuje zbiór problemów reprezentowanych przez właściwość problems dostępną tylko do zapisu. Możemy ten komponent skonfigurować za pomocą następujących elementów:

Rysunek 2.7. Diagram składni definicji elementów komponentu zarządzanego quiz com.corejsf.QmzBean session problems <1ist-entries> com.corejsf.ProblemBean #{probleml} #{problem2} #{problem3} #{problem4} #{problem5}

Oczywiście musimy teraz zdefiniować komponenty nazwane od probl eml do probl em5: probl enil com.corejsf ProbleniBean

67

68

Rozdział 2. ■ Komponenty zarządzane

JavaServer Faces none sequence <1i st-entri es> java.lang.Integer 3 l 4 l 5 solution 9

W odpowiedzi na żądanie kierowane do komponentu quiz nastąpi automatyczne utworze­ nie komponentów od probl eml do probl em5. Kolejność, w jakiej wskazujemy komponenty zarządzane, nie ma większego znaczenia. Warto zwrócić uwagę na zasięg none komponentów problemów wynikający z tego, że żądania pod ich adresem nigdy nie pochodzą ze strony JS F , a ich egzemplarze są tworzone wskutek żądań wskazujących na komponent quiz. W iążąc ze sobą różne komponenty, musimy być pewni co do zgodności ich zasięgów. W tabeli 2.1 wymieniono wszystkie dopuszczalne kombinacje.

Dla pozostałych typów właściwości implementacja JS F próbuje zlokalizować pasującą imple­ mentację interfejsu PropertyEditor. Jeśli taki edytor właściwości istnieje, następuje wywołanie metody setAsText tego edytora celem konwersji łańcuchów na wartości właściwości. Edytory właściwości są bardzo często wykorzystywane przez komponenty pracujące po stronie klienta i mają na celu konwersję wartości właściwości na reprezentację tekstową lub graficzną umożli­ wiającą ich wyświetlanie w oknie właściwości (patrz rysunek 2.8).

Rysunek 2.8.

: jLabeM [JL a b e l] - P ro p erties

Okienko właściwości narzędzia do projektowania graficznego interfejsu użytkownika

fFrooertfes 1

Events

... możemy korzystać z komponentów o takich zasięgach

none

none

application

none, application

session

none, application, session

request

none, application, session, request

Konwersje łańcuchów Wartości właściwości i elementy list lub map konfigurujemy za pomocą elementu value obejmującego łańcuch. Łańcuch zawarty w tym elemencie musi zostać przekonwertowany na odpowiedni typ właściwości lub elementu. W przypadku typów prostych taka konwersja jest bardzo prosta. Możemy na przykład zdefiniować wartość typu boolean, stosując łańcuch true lub false. Począwszy od wersji JS F 1.2, możemy wykorzystywać elementy value także do definiowania wartości typów wyliczeniowych. Niezbędna konwersja jest realizowana za pomocą metody

T

^Properties background

'□

componentPopupMenu

(

[240,240,240]

displayedMnemonic font foreground horizontalAlignment icon labelFor

Tahorna 11 Plain ■ [0,0,0] H e a d in g null

text

Nazwa użytkownika null

verticalAlignrnent B o th e r Properties

jCENTER, m ■

UlClassID

LabeliJI

alignmentX

0.0

alignment'/

0.5

autoscrolls

□

border

(No Border)

debugGraphicsOptions

¡NOjCHANGES

disabledlc-on

null

displayedMnemoniclndex

-1

doubleBuffered enabled

Q

UB Q y: B : Æ m■ □

|
toolTipText

focusT,ra versalPolicy

Definiując komponent o takim zasięgu...

a> «

Code

m

focusCycleRoot

Tabela 2.1. Zgodne zasięgi komponentów

69

null

TQ Q -IQ -J □ □ □ 0 Q , rD a

□ B Q □ □-

Definiowanie edytora właściwości jest zadaniem dość złożonym, zatem zainteresowanych Czytelników zachęcamy do lektury rozdziału 8. książki pt. Core Java™ 2, vol 2 — Advanced Features (7th e d .f autorstwa Caya Horstmanna i Gary’ego Cornelia. Musimy pamiętać, że reguły konwersji są dość restrykcyjne. Jeśli na przykład dysponujemy właściwością typu URL, nie możemy po prostu zapisać adresu U R L w formie łańcucha, mimo że istnieje konstruktor URL (String). Musimy albo opracować edytor właściwości dla typu URL, albo ponownie zdefiniować typ tej właściwości jako String. Reguły konwersji podsumowano w tabeli 2.2. Identyczne reguły są stosowane dla akcji jsp :setProp erty specyfikacji JSP.

Składnia wyrażeń reprezentujących wartości W tym podrozdziale szczegółowo omówimy składnię wyrażeń reprezentujących wartości. Można niniejszy materiał traktować jak swoisty leksykon. Czytelnicy, którzy mają tę książkę w rękach po raz pierwszy, mogą ten podrozdział pominąć i wrócić do niego w przyszłości.

Enum.v a 1 u e 0 f(k la s a _ w ła ś c iw o ś c i , w a rto ś ć _ te k s to w a ).

4 Polskie wydanie: Java 2. Techniki zaawansowane. Wydanie 77, Helion, 2005 — przyp. tłum.

70

JavaServer Faces

Rozdział 2. ■ Komponenty zarządzane

Tabela 2.2. Konwersje łańcuchów

71

Stosowanie nawiasów kwadratowych Konwersja

Typ docelowy

int, byte, short, long, float, double Metoda val ueOf typu opakowania lub 0, jeśli dany łańcuch jest pusty.

lub odpowiedni typ opakowania boolean lub Boolean

Wynik metody Boolean.valueOf lub fal se, jeśli dany łańcuch jest pusty.

char lub Character

Pierwszy znak danego łańcucha lub (cha r ) 0, jeśli ten łańcuch jest pusty.

String lub Object

Kopia danego łańcucha lub new Stri ng(""), jeśli ten łańcuch jest pusty.

właściwość komponentu

Typ, który wywołał metodę setAsText edytora właściwości (jeśli taki edytor istnieje). Jeśli edytor właściwości nie istnieje lub generuje wyjątek, właściwość ma przypisywaną wartość nul 1 (w przypadku łańcucha pustego) lub jest generowany błąd.

W pierwszej kolejności skoncentrujemy się na wyrażeniach w postaci a.b. Przyjmijmy, że wiemy, jaki obiekt jest reprezentowany przez zmienną a. Jeśli a jest tablicą, listą lub mapą, musimy stosować pewne reguły specjalne (patrz punkt „Stosowanie nawiasów kwadratowych” w dalszej części tego podrozdziału). Jeśli a jest dowolnym innym obiektem, b musi być nazwą właściwości tego obiektu. Dokładne znaczenie wyrażenia a.b zależy od tego, czy dane wyra­ żenie jest wykorzystywane w trybie r-wartości (ang. r - v a l u e ) czy 1-wartości (ang. l - v a lu e ) . Przytoczona terminologia jest stosowana w teorii języków programowania w kontekście wyrażeń po prawej stronie operatora przypisania, traktowanych inaczej niż wyrażenia po lewej stronie tego operatora.

Podobnie jak w języku JavaScript zamiast notacji kropki możemy stosować nawiasy kwa­ dratowe. Oznacza to, że wszystkie trzy przedstawione poniżej wyrażenia reprezentują do­ kładnie to samo: a.b

arb"] a ['b '] Na przykład wyrażenia user.password, user["passwordM] oraz u s e r[' password'] są sobie równoważne. Po co ktokolwiek miałby stosować wyrażenie u s e r [ "password” ], skoro dużo łatwiejsze do zapisania jest wyrażenie u s e r password? Z kilku powodów: ■ Kiedy uzyskujemy dostęp do tablicy lub mapy, notacja [] jest bardziej intuicyjna. ■ Notację [ ] można stosować łącznie z łańcuchami zawierającymi kropki i myślniki, np. msgs["error password"]. ■ Notacja [ ] umożliwia nam dynamiczne wyznaczanie nazwy interesującej nas właściwości, np. afD.propname]. J T W W wyrażeniach reprezentujących wartości należy stosować apostrofy, jeśli w roli

1 U I separatora atrybutów wykorzystujemy cudzysłowy:

value* ,'# {u s e r[,pa$sword, ] } \ .

Apostrofy i cudzysłowy można stosować zamiennie: value=,# {u se r[Hpassword” ] } ’ . Przeanalizujmy następującą operację przypisania: le ri

= right.

Kompilator generuje inny kod dla wyrażenia left i inny dla wyrażenia right. Wyrażenie right zostanie przetworzone w trybie r-wartości, a wynikiem tego przetworzenia będzie pojedyncza wartość. Wyrażenie 1eft zostanie przetworzone w trybie 1-wartości, co doprowadzi do zapisania jakiejś wartości w pewnym miejscu. Ten sam model jest stosowany w przypadku wyrażeń reprezentujących wartości stosowanych w komponentach interfejsu użytkownika:

W czasie wizualizowania tego pola tekstowego wyrażenie user.name jest przetwarzane w trybie r-wartości, co wiąże się z koniecznością wywołania metody getName. Na etapie dekodowania to samo wyrażenie jest przetwarzane w trybie 1-wartości, zatem jest wywoływana metoda setName. Ogólnie wyrażenie a .b jest przetwarzane w trybie r-wartości przez wywołanie metody zwraca­ jącej wartość właściwości oraz w trybie 1-wartości przez wywołanie metody ustawiającej wartość właściwości.

Wyrażenia odwołujące się do map i list Język wyrażeń reprezentujących wartość nie ogranicza się do odwołań do właściwości kom­ ponentów. Przykładowo: niech mbędzie obiektem dowolnej klasy implementującej interfejs Map. Wyrażenie m["key"] (lub wyrażenie równoważne w postaci m.key)jest wówczas łączem do odpowiedniej wartości. W trybie r-wartości nastąpi wywołanie metody: m.get("key")

W trybie 1-wartości zostanie wykonane następujące wyrażenie: m.putCkey", right);

W tym przypadku rig h t reprezentuje wartość prawej strony, która ma zostać przypisana elementowi m.key. Możemy też uzyskiwać dostęp do wartości dowolnego obiektu klasy implementującej interfejs L is t (np. klasy A rrayList). Pozycja na liście jest reprezentowana przez indeks całkowitoliczbowy. Na przykład wyrażenie a [i ] (lub a . i) wiąże i-ty element listy a. Zmienna i musi mieć albo postać liczby całkowitej, albo łańcucha, który można na taką liczbę przekonwertować. Ta sama reguła znajduje zastosowanie w przypadku typów tablicowych. Jak zawsze wartości indeksów rozpoczynają się od zera.

72

Rozdział 2. ■ Komponenty zarządzane

JavaServer Faces Opisane powyżej reguły przetwarzania podsumowano w tabeli 2.3.

Tabela 2.3. Przetwarzanie wyrażenia reprezentującego wartość w postaci a.b

73

Tabela 2.4. Obiekty predefiniowane języka wyrażeń reprezentujących wartości Nazwa zmiennej

Znaczenie

header

Struktura typu Map reprezentująca parametry nagłówka protokołu HTTP (obejmująca tylko po pierwszej wartości dla każdej nazwy).

headerValues

Struktura typu Map reprezentująca parametry nagłówka protokołu HTTP w formie tablicy typu String[] obejmującej wszystkie wartości dla danej nazwy.

Param

Struktura typu Map reprezentująca parametry żądania protokołu HTTP (obejmująca tylko po pierwszej wartości dla każdej nazwy).

paramValues

Struktura typu Map reprezentująca parametry żądania protokołu HTTP w formie tablicy typu Stri ng[] obejmującej wszystkie wartości dla danej nazwy.

cookie

Struktura typu Map reprezentująca nazwy i wartości znaczników kontekstu klienta dla bieżącego żądania.

Typ zmiennej a

Typ zmiennej b

Tryb l-wartości

Tryb r-warlości

nuli

dowolny

błąd

riul 1

dowolny

nul 1

błąd

nul 1

Map

dowolny

a.putCb. right)

a.get(b)

List

możliwy do przekonwertowania na typ i nt

a.set(b. right)

a.get(b)

tablica

możliwy do przekonwertowania na ryp i nt

a[bl = ri ght

a[b]

i ni tParam

komponem

dowolny

Wywołanie metody ustawiającej wartość właściwości nazwanej

Wywołanie metody zwracającej wartość właściwości nazwanej

Struktura typu Map reprezentująca parametry inicjałizacji danej aplikacji internetowej. Parametry inicjalizacji zostaną omówione w rozdziale 10.

requesiScope

Struktura typu Map reprezentująca wszystkie atrybuty obejmujące zasięgiem żądanie.

b t o S t ri n g i ).

b toSt r i ng( ).

sessionScope

Struktura typu Map reprezentująca wszystkie atrybuty obejmujące zasięgiem sesję.

applicationScope

Struktura typu Map reprezentująca wszystkie atrybuty obejmujące zasięgiem aplikację.

facesContext

Egzemplarz klasy FacesConiext właściwy dla danego żądania. Klasa FacesContext zostanie omówiona w rozdziale 6.

v i ew

Egzemplarz klasy Ul ViewRoot właściwy dla danego żądania. Klasa Ul ViewRoot zostanie omówiona w rozdziale 7.

■ p n Okazuje się niestety, że wyrażenie reprezentujące wartość nie zdaje egzaminu w przyK m II padku właściwości indeksowanych. Jeśli p je s t właściwością indeksowaną kom­ ponentu b, a i jest liczbą całkowitą, wówczas wyrażenie b ,p [i] nie uzyskuje dostępu do i-te j w artości tej w łaściw ości. W yrażenie w tej form ie zostanie zakw alifikow ane jako błędne składniowo. Brak obsługi tego rodzaju wyrażeń technologia JSF odziedziczyła po technologii JSP.

Rozwiązywanie wyrazu początkowego Wiemy już, jak wygląda proces przetwarzania wyrażeń w postaci a . b. Okazuje się, że te same reguły mogą być wielokrotnie stosowane dla wyrażeń w formie a . b. c . d (lub, co oczywiste, a [ ' b' ] . c[ "d" ]). Musimy jednak przeanalizować faktyczne znaczenie wyrazu początkowego a. W prezentowanych do tej pory przykładach wyraz początkowy odwoływał się albo do kom­ ponentu skonfigurowanego w pliku faces-config.xml, albo do mapy pakietu komunikatów. Chociaż te dwa rozwiązania są stosowane zdecydowanie najczęściej, wyraz początkowy może reprezentować także inne konstrukcje. Istnieje wiele predefiniowanych obiektów. Kompletną listę przedstawiono w tabeli 2.4; poniżej przedstawiono wybrany przykład wyrażenia: header[’User-Agent']

które reprezentuje wartość parametru User-Agent żądania H TTP, wartość tego parametru identyfikuje przeglądarkę internetową użytkownika.

Jeśli wyraz początkowy nie jest żadnym z wymienionych obiektów predefiniowanych, im­ plementacja JS F poszukuje tego wyrazu kolejno w zasięgu żądania, zasięgu sesji i zasięgu aplikacji. Wym ienione zasięgi mają postać obiektów map zarządzanych przez kontener serwletów. Kiedy więc definiujemy na przykład komponent zarządzany, jego nazwa i wartość są dodawane do mapy odpowiedniego zasięgu. Dopiero kiedy okaże się, że użytej nazwy nie można odnaleźć w tych zasięgach, następuje jej przekazanie do implementacji VariableResol ver właściwej dla danej aplikacji JSF. Działa­ nie domyślnego mechanizmu interpretacji zmiennych sprowadza się do przeszukania elemen­ tów managed-bean w zasobach konfiguracyjnych (czyli z reguły w pliku faces-config.xml). Przeanalizujmy następujące wyrażenie przykładowe: #{user password}

W yraz user nie jest żadnym z opisanych powyżej obiektów predefiniowanych. Kiedy po raz pierwszy zostanie odkryty w kodzie źródłowym, okaże się, że nie jest nazwą atrybutu w zasięgu żądania, sesji ani aplikacji. W tej sytuacji mechanizm interpretacji zmiennych przetwarza następujący wpis znaleziony w pliku konfiguracyjnym faces-config.xmk

74

Rozdział 2. ■ Komponenty zarządzane

JavaServer Faces user com.corejsf UserBean session

Mechanizm odpowiedzialny za interpretację zmiennych wywołuje konstruktor domyślny klasy com.corejsf .UserBean, po czym umieszcza nowo utworzony związek w mapie sessionScope. Ostatecznie mechanizm interpretujący zwraca ten obiekt jako wynik operacji przeszukiwania. Jeśli wyraz user będzie wymagał ponownej interpretacji w ramach tej samej sesji, gotowe roz­ wiązanie zostanie zlokalizowane w zasięgu sesji (reprezentowanym przez mapę sessi onScope).

Wyrażenia złożone W ramach wyrażeń reprezentujących wartości możemy stosować ograniczony zbiór operatorów: ■

Operatory arytmetyczne: oraz %. Dla ostatnich dwóch operatorów istnieją wersje alfabetyczne, odpowiednio di v i mod.

■

Operatory relacyjne: <, <=, >, >=, = i !=, a takżeich wersjealfabetyczne: 11 ,1e, gt, ge, eq oraz ne. Cztery pierwsze odpowiedniki alfabetyczne są niezbędne w sytuacji, gdy chcemy zagwarantować bezpieczne przetwarzanie danych w formacie X M L.

■ Operatory logiczne: &&, | | i ! oraz ich wersje alfabetyczne: and, or i not. Stosowanie pierwszego odpowiednika alfabetycznego jest warunkiem prawidłowego przetwarzania danych w formacie X M L. ■ Operator empty. Wyrażenie empty a jest prawdziwe (ma wartość true), jeśli a ma wartość nul 1, jest tablicą lub łańcuchem zerowej długości bądź pustą kolekcją lub mapą (odpowiednio typu Col 1ecti on lub Map). ■

Trój argumentowy operator selekcji ? :.

Dla wymienionych operatorów stosuje się te same reguły poprzedzania, które znamy z Javy. Operator empty charakteryzuje się identycznym priorytetem jak operatory jednoargumentowe - oraz !. Ogólnie chcemy, aby możliwie niewielka część obliczeń związanych z przetwarzaniem wyrażeń była realizowana na naszych stronach internetowych, ponieważ takie rozwiązanie naruszałoby zasadę rozdziału warstwy prezentacji od logiki biznesowej. Okazuje się jednak, że w pewnych rzadkich sytuacjach możliwość stosowania operatorów w warstwie prezentacji jest warta rozważenia. Przypuśćmy na przykład, że chcemy ukrywać jakiś komponent interfejsu graficznego, gdy właściwość hide pewnego komponentu aplikacji ma wartość true. Aby ukryć komponent interfejsu, należy przypisać wartość false jego atrybutowi rendered. Odwrócenie tej wartości wymaga użycia operatora ! (lub not):

I wreszcie możemy konkatenować zwykłe łańcuchy i wyrażenia reprezentujące wartość przez umieszczanie ich w bezpośrednim sąsiedztwie. Przeanalizujmy poniższy przykład:

75

Powyższe wyrażenie konkatenuje cztery łańcuchy: łańcuch zwrócony przez wyrażenie #{messages. greeting}, łańcuch złożony z przecinka i spacji, łańcuch zwrócony przez wyraże­ nie # {u se r. name} oraz łańcuch złożony z samego wykrzyknika.

Zaprezentowaliśmy wszystkie reguły stosowane w procesie przetwarzania wyrażeń repre­ zentujących wartości. Oczywiście w praktyce zdecydowana większość wyrażeń ma postać #{komponent .właściwość}. Czytelnicy, którzy staną przed koniecznością obsługi bardziej złożonych wyrażeń, będą mogli w każdej chwili wrócić do tego materiału.

Wyrażenia odwołujące się do metod Wyrażenie odwołujące się do metody obejmuje obiekt wraz z metodą, którą można dla tego obiektu zastosować. Typowy przykład użycia takiego wyrażenia przedstawiono poniżej:

Zakładamy, że user jest wartością typu (obiektem klasy) UserBean, natomiast checkPassword jest metodą tej klasy. Wyrażenie odwołujące się do metody jest wygodnym sposobem opisania wywołania, które wymaga realizacji w niedalekiej przyszłości. W czasie przetwarzania takiego wyrażenia odpowiednia metoda jest wykonywana na wska­ zanym obiekcie. W naszym przypadku kliknięcie komponentu przycisku spowoduje wywołanie metody user. checkPassword() i przekazanie zwróconego łańcucha do mechanizmu odpowiedzialnego za obsługę nawigacji. Reguły składniowe dla tego rodzaju wyrażeń bardzo przypominają te, które stosuje się dla wyrażeń reprezentujących wartości. Wszystkie składowe poza ostatnią służą do identyfikacji obiektu będącego przedmiotem wywołania metody. Ostatnią składową musi być nazwa metody, którą można zastosować dla obiektu wskazywanego przez poprzednie składowe. Wyrażenie odwołujące się do metody można przypisać czterem atrybutom komponentów: ■ acti on (patrz podrozdział „Nawigacja dynamiczna” w rozdziale 3.); ■

v a lid a to r (patrz punkt „W eryfikacja za pomocą metod komponentów” w rozdziale 6.);

■

val ueChangeLi stener (patrz podrozdział „Zdarzenia zmiany wartości” w rozdziale 7.);

■

acti onLi stener (patrz podrozdział „Zdarzenia akcji” w rozdziale 7.).

Typy parametrów i wartości zwracanej przez daną metodę zależą od kontekstu, w którym stosujemy nasze wyrażenie. Przykładowo atrybut action można związać z metodą bezparametrową zwracającą wartość typu String, natomiast atrybut acti onLi stener można związać z metodą otrzymującą pojedynczy parametr typu ActionEvent i nie zwracającą wartości. Za dostarczanie wartości parametrów i przetwarzanie wartości zwracanych odpowiada oczywiście kod wywołujący wyrażenie odwołujące się do metody.

76

JavaServer Faces

3 Nawigacja W tym krótkim rozdziale omówimy sposób konfigurowania reguł nawigacji w ramach bu­ dowanej aplikacji internetowej. W szczególności wyjaśnimy, jak aplikacja może przechodzić od jednej do drugiej strony internetowej w zależności od działań podejmowanych przez użytkownika i decyzji podejmowanych na poziomie logiki biznesowej.

Nawigacja statyczna Przeanalizujmy teraz sytuację, w której użytkownik aplikacji internetowej wypełnia formularz na stronie internetowej. Użytkownik może wpisywać dane w polach tekstowych, klikać przyci­ ski opcji i wybierać elementy list. Wszystkie te działania są realizowane na poziomie przeglądarki internetowej użytkownika. K iedy użytkownik klika przycisk akceptujący i w ysyłający dane formularza, zmiany są przekazywane na serwer. Aplikacja internetowa analizuje wówczas dane wpisane przez użytkownika i na ich podstawie decyduje, której strony JS F należy użyć do wizualizacji odpowiedzi. Za wybór kolejnej strony JS F odpowiada mechanizm obsługujący nawigację. W przypadku prostych aplikacji internetowych nawigacja pomiędzy stronami ma charakter statyczny. Oznacza to, że kliknięcie określonego przycisku zawsze powoduje przejście do tej samej strony JS F odpowiedzialnej za wizualizację odpowiedzi. W podrozdziale „Prosty przykład” w rozdziale 1. Czytelnicy mieli okazję zobaczyć, jak można definiować reguły nawigacji statycznej pomiędzy stronami JS F w pliku konfiguracyjnym faces-config.xml. Dla każdego przycisku definiujemy atrybut action — przykład takiego rozwiązania przed­ stawiono poniżej:

78

Rozdział 3. ■ Nawigacja

JavaServer Faces

79

Jeśli okaże się. że żadna reguła nawigacji nie pasuje do danej akcji, nastąpi ponowne w yświetlenie bieżącej strony.

I Podczas lektury rozdziału 4. będzie się można przekonać, źe akcje nawigacji można | przypisywać także do hiperłączy. Tak skonfigurowana akcja musi odpowiadać elementowi from-outcome reguły nawigacji: <1rom-view-id>/index JSD

<1r om-outcome>iogin /we korne jsp



Powyższa reguła określa, że akcja login ma powodować przejście do strony /welcome.jsp, jeśli miała miejsce na stronie /index.jsp. Musimy pamiętać o konieczności rozpoczynania wszystkich łańcuchów identyfikujących strony od znaku prawego ukośnika (/). Stosowane rozszerzenia muszą odpowiadać faktycznym rozszerzeniom plików (.jsp), nie rozszerzeniom stosowanym w adresach U R L. Gdybyśmy w elemencie from-view-id umieścili np. łańcuch /index.faces, odpowiednia reguła nie działa­ łaby prawidłowo. Jeśli uważnie dobierzemy łańcuchy akcji, będziemy mogli skutecznie grupować wiele reguł nawigacji. Moglibyśmy na przykład powielać przyciski powiązane z akcją logout na wszyst­ kich stronach naszej aplikacji internetowej. Okazuje się, że za pomocą zaledwie jednej reguły moglibyśmy wymusić nawigację do strony logout.]sp w odpowiedzi na kliknięcie każdego z tych przycisków: logout /logout.jsp

Powyższa reguła jest stosowana dla wszystkich stron, ponieważ nie wskazuje na żaden kon­ kretny element from-view-id.

Nawigacja dynamiczna W przypadku większości aplikacji internetowych nawigacja nie ma charakteru statycznego. Ścieżka przechodzenia pomiędzy stronami nie zależy tylko od klikanych przycisków, ale także od danych wejściowych wpisywanych przez użytkownika. Na przykład wysyłając dane ze strony logowania (zwykle nazwę użytkownika i hasło), możemy oczekiwać dwóch odpowiedzi ze strony serwera: akceptacji tych danych bądź ich odrzucenia. Odpowiedź serwera zależy więc od pewnych obliczeń (w tym konkretnym przypadku od poprawności nazwy użytkownika i hasła). Aby zaimplementować nawigację dynamiczną, przycisk akceptacji formularza należy związać z wyrażeniem odwołującym się do metody :

W naszym przypadku wyraz 1ogi nControl 1er odwołuje się do komponentu pewnej klasy, która musi definiować metodę nazwaną veri fyUser. Wyrażenie odwołujące się do metody, które przypisujemy atrybutowi acti on, nie otrzymuje żadnych parametrów, ale może zwracać wartość jakiegoś typu. Zwracana wartość jest konwer­ towana na łańcuch za pomocą wywołania metody to S tri ng. W standardzie JSF 1 .1 metody będące przedmiotem odwołań w tego rodzaju wyraże­ niach m usiały zw racać w artości typu String. W technologii JSF 1 . 2 'zw racana wartość m oże być obiektem dowolnego typu. Taka możliwość je s t szczególnie ważna w przypadku typów wyliczeniowych, ponieważ elim inuje ryzyko przeoczenia literów ek w nazwach akcji (wychwytywanych przez kom pilator). Przykład metody akcji przedstawiono poniżej: String verifyUserO { i f (. .) return "success": else return "failure":

Reguły nawigacji z identycznymi łańcuchami w elemencie from-view-id można swobodnie scalać — odpowiedni przykład przedstawiono poniżej: /index.jsp logi n /wel eonie. jsp signup /newuser.jsp

Scalanie jest dość dobrym rozwiązaniem, choć nie jest wymagane.

Powyższa metoda zwraca jeden z dwóch łańcuchów wynikowych: "success" lub "fa ilu re ". Mechanizm odpowiedzialny za obsługę nawigacji wykorzystuje ten łańcuch do odnalezie­ nia właściwej reguły nawigacji.

K

m

I M etoda akcji m oże zwrócić wartość n u li, aby zasygnalizować.konieczność ponownego wyświetlenia tej sam ej strony.

80

JavaServer Faces

Rozdział 3. ■ Nawigacja

Krótko mówiąc, za każdym razem, gdy użytkownik klika przycisk polecenia, dla którego zdefiniowano wyrażenie odwołujące się do metody w atrybucie a c l i o n , implementacja JS F podejmuje następujące kroki: ■ uzyskuje dostęp do wskazanego komponentu;

Rysunek 3.2.

81

ÿ Dstecionte prosty quiz o Javte - Moziiia Fkefox i

Jedna błędna odpowiedź — spróbuj ponownie

«01/* ^ * ||P ’||jp |j| j

httpVylQC3lho;t:8080/jav3qutz/mde/.faces:jŚ

.........

Przvkro nam. Tw oja odpowiedz lesi błędna Spiobnj ponownie1 Ja k ł 'rzmiał slogan reklamowy opisująrv programowanie w Javie ■ Write onte.

■ wywołuje wskazaną metodę;

0)0 many f'mes

■ przekazuje łańcuch wynikowy do mechanizmu odpowiedzialnego za obsługę nawigacji (zgodnie z procedurą opisaną w punkcie „Algorytm nawigacji" w kolejnym podrozdziale wspomniany mechanizm otrzymuje też łańcuch wyrażenia odwołującego się do metody); ■ na tej podstawie mechanizm nawigacji odnajduje następną stronę. Oznacza to, że implementacja rozgałęzień (ang. branching) wymaga przekazania referencji do metody klasie odpowiedniego komponentu. Mamy dużą dowolność w kwestii miejsca umieszczenia tej metody. Najlepszym rozwiązaniem jest znalezienie klasy obejmującej wszystkie dane potrzebne do podejmowania właściwych decyzji.

Rysunek 3.3. Dwie błędne odpowiedzi — kontynuuj

Przeanalizujmy teraz funkcjonowanie tego procesu w rzeczywistej aplikacji. Nasz przykła­ dowy program prezentuje użytkownikowi sekwencję pytań quizu (patrz rysunek 3.1).

Rysunek 3.1. Pytanie quizu

|§/ Dziecinnie prosty ą u \z o Jasvie ■ ■Mcaite Firefox Pîtk

Edycja

Widok

■Hutena

Zakładki

Naaędzia

,

"Ł.'1,,

.

Pomoc

nttp.//1o l oihu i t; S 08u/j av aq uiz/1 n d e .ra ce.

LSLL.iM.L-.I'L .

*>

l l B | c jJS f e l

Jdk brzmiał slogan reklam o w v opisująco piog ram ow an ie w J a v ip? W rite on re. ■de t1u g e .e iy w n e re

Rysunek 3.4.


Quiz zakończony i punktacja

ą itiz ■

40* 'Mjt * Hf

<

?

f j l'iS 1

WI ś i Ę k f Ę Ę Ż

i..sj

I_______ ji>,j _

1 Spm vytH odpow iedz J

Dziękujemy za udział w qume. Tv/oj wynik, punktowy. 5 Rozpocznij od nowa [

Zakończono

Kiedy użytkownik klika przycisk Sprawdź odpowiedź, aplikacja sprawdza, czy podana od­ powiedź jest prawidłowa. Jeśli nie, użytkownik otrzymuje jeszcze jedną szansę rozwiązania tego samego problemu (patrz rysunek 3.2). Po dwóch błędnych odpowiedziach aplikacja prezentuje użytkownikowi kolejny problem do rozwiązania (patrz rysunek 3.3). Oczywiście także w razie podania prawidłowej odpowiedzi aplikacja przechodzi do następ­ nego problemu. I wreszcie po rozwiązaniu ostatniego problemu następuje wyświetlenie strony podsumowania z uzyskaną liczbą punktów i propozycją ponownego przystąpienia do ąuizu (patrz rysunek 3.4).

Nasza aplikacja składa się z dwóch klas. Klasa Problem (przedstawiona na listingu 3.1) opisuje pojedynczy problem, czyli pytanie, odpowiedź oraz metodę weryfikacji, czy dana odpowiedź jest prawidłowa.

Listing 3.1. Zawartość pliku javaquiz/src/java/com/corejsf/Probiem.java 1. package com.corejsf; 2.

3. public class Problem { 4. private String question;

82

JavaServer Faces 5.

private String answer;

6

7. 8 9

public Problem(String question, String answer) { this.question = question; this.answer = answer;

}

10 11.

12 13 14 15 16 17 18. 19. 20

public String getQuestionO { return question; } public String getAnswerO { return answer; } //implementacja bardziej wyszukanych mechanizmów weryfikacji wymaga nadpisania tej metody: public boolean isCorrect(String response) { return response.trim O.equalslgnoreCase(answer); }

}

Klasa QuizBean opisuje quiz obejmujący szereg pytań. Egzemplarz tej klasy dodatkowo śledzi bieżące pytanie i łączną punktację uzyskaną przez użytkownika. Kompletny kod tej klasy przedstawiono na listingu 3.2.

Listing 3.2. Zawartość pliku ja vaquiz/src/java/com/corejsf/QuizBean.ja va package com.corejsf: public class QuizBean { private int currentProblem; private int tries, private int score, private String response; private String correctAnswer,

15. 16. 17. 18. 19. 20 21.

22 23 24. 25 26. 27. 28 29. 30.

// Poniżej zakodowano problemy na stałe. W rzeczywistej aplikacji / / problemy najprawdopodobniej zostałyby odczytane z bazy danych. private Problem[] problems = { new Problem( "Jak brzmiał slogan reklamowy opisujący programowanie w Javie? Write once, ...", "run anywhere"), newProblem( "Jak wygląda reprezentacja szesnastkowa czterech pierwszych bajtów każdego pliku klasy?", "CAFEBABE"), newProblem( "Co zostanie wyświetlone przez następujące wyrażenie? System.out.pri ntln( l+\"2\" );", " 12" ) ,

new Problem( "Które słowo kluczowe Javy służy do definiowania podklasy?", "extends"), newProblem( "Jak brzmiała oryginalna nazwa języka programowania Java?", "Oak"), new Problem( "Która klasa pakietujava.util opisuje punkt wczasie?", "Date")

Rozdział 3. ■ Nawigacja 31 32. 33. 34 35 36 37 38. 39. 40. 41. 42 43. 44. 45. 46. 47. 48. 49 50. 51. 52. 53. 54. 55. 56. 57. 58 59 60. 61. 62. 63. 64 65.

}, public QuizBeanO { startOverO, } // Właściwość question: public String getQuestionO { return problems[currentProblem],getQuestion(), } // W łaściwość answ er ■ public String getAnswerO { return correctAnswer; } // Właściwość score: public int getScoreO { return score; } // Właściwość response: public String getResponseO { return response; } public void setResponse(String newValue) {response = newValue, } public String answerActionO { tries++; i f (problems[currentProblem].isCorrect(response)) { score++; nextProblemO; i f (currentProblem == problems.length) return "done", else return "success", } else i f (tries == 1) { return "again", } else { nextProblemO; i f (currentProblem == problems.length) return "done"; else return "failure", }

66.

67. 68. 69 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80 81. 82. 83. 84. 85. 86

}

public String startOverActionO { startOverO; return "startOver"; } private void startOverO { currentProblem = 0; score = 0; tries = 0; response = ""; } private void nextProblemO { correctAnswer = problems[currentProblem].getAnswerO, currentProblem++; tries = 0; response = }

}

83

84

JavaServer Faces W analizowanym przykładzie właśnie klasa QuizBean jest właściwym miejscem dla metod odpowiedzialnych za nawigację. Wspomniany komponent dysponuje pełną wiedzą o działaniach użytkownika i może bez trudu określić, która strona powinna być wyświetlona jako następna. Warto się przyjrzeć fragmentowi kodu użytego wewnątrz metody answerActi on klasy Qui zBean. Metoda answerAction zwraca jeden z kilku możliwych łańcuchów: "success" lub "done" (jeśli użytkownik prawidłowo odpowiedział na pytanie), "again" (jeśli użytkownik po raz pierwszy udzielił błędnej odpowiedzi) oraz "fai 1ure" lub "done" (jeśli po raz drugi padła zła odpowiedź). public String answerAction() { tries++, i f (problems[currentProblem].isCorrect(response)) { score++: i f (currentProblem == problems.length - 1) { return "done": } else { nextProblem(): return "success"; } } else i f (tries == 1) { return "again"; } else { i f (currentProblem == problems.length - 1) { return "done"; } else { nextProblem(); return "failure";

Z przyciskami na każdej z tych stron wiążemy wyrażenie odwołujące się do metody answer W \cti on. Na przykład strona index.jsp zawiera następujący element:

W tym przypadku quiz jest egzemplarzem klasy (komponentu) QuizBean zdefiniowanym w pliku konfiguracyjnym faces-config.xml. Na rysunku 3.5 przedstawiono strukturę katalogów naszej aplikacji. Na listingu 3.3 przedsta­ wiono kod strony głównej aplikacji quizu: index.jsp. Kodem stron success.jsp i failure.jsp nie będziemy się zajmować, ponieważ różnią się od kodu strony index.jsp tylko komunikatem wyświetlanym w górnej części.

Listing 3.3. Kod strony javaquiz/web/index.jsp_________________________________________________________ 1. 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. taglib uri="http://java.sun.com/jsf/htnil" prefix="h" %> 4. 5.

Rozdział 3. ■ Nawigacja Rysunek 3.5. Struktura katalogów aplikacji quizu o Javie

85

Z3 javaquiz.war L META-INF

j

L Q MANIFEST. MF

f -0 5 web-inf j f • classes

|

j

f

j

|

j

j

|

|

j

|

\

j

j

(¡3 c o m f - [¡3 corejsf - Q

Problem.class

j~- Q QuizBean. class L Q messages.properties Q faces-config.xml Q web.xml

j Q index.html ; D again.jsp I- Q done.jsp i

Q failure.jsp

j Q Index.jsp Q success.jsp_______________________

6. 7. 8. 9 10. 11 12. 13. 14 15. 16. 17. 18. 19 20 21 22. 23. 24.

Strona done.jsp, której kod przedstawiono na listingu 3.4, prezentuje użytkownikowi ostateczny wynik i zachęca go do ponownej gry. Warto zwrócić uwagę na jedyny przycisk dostępny na tej stronie. Na pierwszy rzut oka może się wydawać, że mamy do czynienia z nawigacją statyczną, ponieważ każde kliknięcie tego przycisku powoduje powrót na stronę index.jsp. Okazuje się jednak, że element definiujący ten przycisk wykorzystuje wyrażenie odwołujące się do metody:

Listing 3.4. Zawartość pliku javaquiz/web/done.jsp_____________________________________________________ 1. 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4 5. 6. 7

86

JavaServer Faces 8. 9.

Rozdział 3. ■ Nawigacja



10 11. 12.

13 14

< f: pa ram v a lu e = "# {q u iz .sc o re }"/>

15. 16. 17

18. 19 20. 21.

22.

a c t i on="#{qui z . s ta rtO v e rA c ti o n }"/>

Metoda startOverAction wykonuje wszelkie działania niezbędne do przywrócenia oryginal­ nego stanu gry. W tym przypadku jej funkcjonowanie sprowadza się do wyzerowania wyniku punktowego i ustawienia znacznika bieżącego pytania tak, aby wskazywał na pierwsze pytanie w serii: p u b lic S t r in g s ta r t O v e r A c tio n () { s ta rtO v e r(); re tu rn "s ta r t O v e r " ;

Ogólnie metody akcji pełnią dwie funkcje: ■ aktualizują model w reakcji na działania podejmowane przez użytkownika; ■ sygnalizują mechanizmowi nawigacji konieczność skierowania użytkownika w określone miejsce. Podczas lektury rozdziału 7. Czytelnicy przekonają się, że istnieje możliwość dołą­ czania do przycisków także obiektów nasłuchujących akcji. Kiedy użytkownik klika ta k zdefiniowany przycisk, następuje wykonanie kodu metody processAction obiektu nasłuchującego. W arto jed n ak pam iętać, że obiekt nasłuchujący akcji nie kom unikuje się z m echanizm em odpowiedzialnym za nawigację. Na listingu 3.5 przedstawiono plik konfiguracyjny tej aplikacji obejmujący między innymi reguły nawigacji.

10 11. 12 13 14. 15 16 17 18. 19. 20 21. 22. 23. 24 25 26. 27. 28 29. 30. 31. 32. 33. 34. 35 36. 37. 38. 39. 40. 41. 42.

/success.jsp agai n /again.jsp fai1ure /failure.jsp done /done.jsp startOver /index.jsp quiz com.corejsf.QuizBean session com.corejsf nessages msgs

Ponieważ tak dobraliśmy nasze łańcuchy wynikowe, aby umożliwiały jednoznaczną identyfi­ kację kolejnych stron internetowych, możemy się ograniczyć do pojedynczej reguły nawigacji: < n a vig a tio n •fule> success /success jsp< /to-view -id> < / n a v ig a lion case> aga i n

Listing 3.5. Zawartość pliku javaquiz/web/WEB-INF/faces-config.xml___________________________________ 1 2
A 5

*inlns xsi ="htLp //www w3 org/2001/xMLSchema-instance" xsi schemaLocation="http //ja va .sun com/xml/ns/javaee ve rsion= "l 2">

7



8 9

n o -view - id>/again jsp < /navigauon -case> < /navigation-rule>

Diagram przejść pomiędzy stronami przedstawiono na rysunku 3.6.

http //java sun.coni/xml/ns/javaee/web-facesconfig_l_2.xsd"

6

success

87

I wreszcie na listingu 3.6 przedstawiono łańcuchy komunikatów.

88

Rozdział 3. ■ Nawigacja

JavaServer Faces

Rysunek 3.6.

Rysunek 3.7.

Diagram przejść aplikacji quizu o Javie

Diagram składni elementów nawigacji

89

navigaiion-rule

navigation-case

| Ś i, ’m m m m

Listing 3.6. Zawartość pliku javaquiz/src/java/com/corejsf/messages.properties 1 2 3

t u le=Dziec m m e prosty quiz o J a v i e answerButton-Sprawdź odpowiedz Stari0verBuUon=RozpOCZmj od nowa

4 5 6

c or re c t= G ra tu la c je . prawidłowa odpowiedz notCorrect=Przykro nam Twoja Odpowiedz je s t płpdna Spróbuj ponownie! s t i 1IN o tC o rre ct=Przykro nam także tym razem podałeś blednq odpowiedź

l

correctAnswer-Prawidłowa odpowiedz

8

SCOre= Twój

9

tiiankYou=Dzi pk ujemy za udział w qu i z i e

w ynik

p u n k to w y

Z diagramu przedstawionego na rysunku 3.7 wynika, że każdy element navigation rule i navigat ion-case może obejmować dowolną liczbę elementów description, display-name i icon. Wymienione elementy w założeniu mają być stosowane na poziomie narzędzi do wizu­ alnego projektowania interfejsów, zatem nie będziemy ich poddawać szczegółowej analizie.

Przekierowanie

{0}

{0[

Zaawansowane techniki nawigacji Techniki opisane w poprzednich podrozdziałach powinny w zupełności wystarczyć do im­ plementacji mechanizmów nawigacji w większości aplikacji. W niniejszym podrozdziale skoncentrujemy się na pozostałych regułach, które można konfigurować za pośrednictwem elementów nawigacji w pliku faces-config.xmI. Diagram składni tych elementów przedsta­ wiono na rysunku 3.7. Z lektury podrozdziału „Konfigurowanie kom ponentów ” w rozdziale 2 . wiemy, że informacje o nawigacji można umieszczać także w innych plikach konfiguracyjnych niż plik standardowy faces~config.xml.

Jeśli element redirect umieścimy za elementem to view-id, kontener JS P wstrzyma prze­ twarzanie bieżącego żądania i odeśle klientowi polecenie przekierowania protokołu HTTP. Odpowiedź przekierowania przekazuje przeglądarce adres U RL, pod którym znajduje się kolejna strona. Przeki ero wywanie stron jest mechanizmem wolniejszym niż przekazywanie żądań, ponieważ wymaga dodatkowego cyklu komunikacji z przeglądarką. Z drugiej strony, przekierowanie umożliwia przeglądarce aktualizację zawartości jej pola adresu. Na rysunku 3.8 pokazano, jak zmienia się pole adresu wskutek dodania do pliku konfigura­ cyjnego następującego elementu przekierowania: suc cess /suce ess j sp c r e d 1rect/>

90

JavaServer Faces

Rozdział 3. ■ Nawigacja

Rysunek 3.8.

T^TM l K

Dziecinnie prosty quiz o J<

Przykład aktualizacji adresu URL przeglądarce na skutek dodania elementu przekierowania

PUK 4

fcdycja

» •I #

Widok

Historia

• ®

t2

Zakładki I.

Narzędzia

j

Pomoc

http://localhost: 8 U80 /|avaquiz/index.taces i

6 oogie

Tak zdefiniowana reguła będzie stosowana dla wszystkich stron rozpoczynających się od przedrostka /secure/. Dopuszczalny jest tylko jeden znak gwiazdki (*), który musi się znaj­ dować na końcu łańcucha identyfikatora.

lak brzmiał slogan reklam'\vv ipisuią..v programowarur w Ja^ier Write onre

Jeśli będzie istniało wiele dopasowań do wzorca zdefiniowanego z użyciem symbolu wielo­ znacznego, zostanie wykorzystane dopasowanie najdłuższe.

r,,n p..et .whptp | S prawdź papowted ; ]

lĘfr Dziecinnie prosty quiz o iavie -Mozilla Ftłefox Plik

Edycja

'sfTŚ v

Widok -

Historia

Ęjjjs Utffi

fjj^ |

Zakładki

Narzędzia

I Zam iast rezygnować z elementu from-view-id, można zastosować jedną z dwóch I poniższych konstrukcji definiujących regułę stosowaną dla wszystkich stron:

Pomoc

http;,7localho5t:80S" ja.

j u c c e >s£ace1 ^ j

j ¡[Ćf^iboogia___

/*

'jiauik-i- ip prawirlł^Wct •''dpnwir '!" T w - -1 vwtul-- punktów; I O t" następne pvtame

lub *

Jak wvglqJa reprezentai ia szesnastkowa ■zterci L pierwszvch K m kw każdego pliku klasy'

i Spiaw dz odpow iedz

W razie braku elementu przekierowania oryginalny adres U R L (w tym przypadku localhost: ^ 8080/javaquiz/index.faces) pozostanie niezmieniony, mimo że użytkownik przejdzie ze strony JS F /index.jsp na stronę /success.jsp. Element przekierowania spowoduje wyświetlenie w polu adresu przeglądarki nowego URL-a (w tym przypadku localhost:8080/javaquiz/ ^ success.faces). Elem ent r e d ir e c t należy stosow ać dla stron, które m ogą być dodaw ane przez użytkowników do zbioru stron ulubionych. tęcti;. - . ■& , . _ '. . .. ..

□

W przypadku braku elem en tu red i rect m echanizm obsługujący nawigację prze kazuje bieżące żądanie do kolejnej strony, która w ten sposób otrzymuje wszystkie pary nazwa-wartość składowane w zasięgu danego żądania. Okazuje się jednak, że użycie elem entu redirect powoduje utratę danych składowanych w tym zasięgu.

0

Stosowanie elementu from-action Struktura elementu navigation case jest bardziej złożona od tej, do której ograniczaliśmy się w naszych dotychczasowych przykładach. Oprócz elementu f nom-outcome mamy do dyspozycji także element from action. Taka elastyczność okazuje się szczególnie istotna w sytuacji, gdy dysponujemy dwiema odrębnymi akcjami z identycznym łańcuchem akcji lub dwoma wy­ rażeniami odwołującymi się do metod zwracających ten sam łańcuch akcji. Przypuśćmy na przykład, że w naszej aplikacji quizu o Javie metoda startOverAct ion zwraca łańcuch "agam" zamiast łańcucha "stantOven". Ten sam łańcuch może zostać zwrócony przez metodę answerAction. Do rozróżnienia obu przypadków (z perspektywy mechanizmu nawigacji) można wykorzystać element from action. Zawartość tego elementu musi jednak być identyczna jak łańcuch wyrażenia odwołującego się do metody zastosowany w atrybucie action: -#{quiz answerAcnon}

again /aga in jsp ^jquiz s t a r t O v e r A c t i on| aga i n< / f rom -outcome>

Symbole wieloznaczne W elementach

91

fro m -view - id

/ind ex.jsp < / na vig a ti o n -case>

wykorzystywanych w ramach reguł nawigacji można stosować

symbole wieloznaczne. Poniżej przedstawiono odpowiedni przykład: ^ n a v ig a t io n - rule> / s e c u r e / * < / fro m - v iew-id> < n avig a tio n - ca se >

< / n a v i g a t i o n ■r u l e >

Mechanizm odpowiedzialny za nawigację nie wywołuje metody zawartej w znaczniku ■ i i # { . . . } , Odpowiednia m etoda je s t wywoływana, zanim jeszcze wspom niany m e­ chanizm przystępuje do pracy. W tej sytuacji mechanizm nawigacji ogranicza się do wyko­ rzystania łańcucha zdefiniowanego w elem encie from-action w roli klucza um ożliwia­ jącego odnalezienie pasującego przypadku.

92

Rozdział 3. ■ Nawigacja

JavaServer Faces

Algorytm nawigacji Nasze rozważania w tym rozdziale zakończymy precyzyjnym omówieniem algorytmu sto­ sowanego przez mechanizm nawigacji do rozwiązywania problemów niejednoznaczności reguł. Czytelnicy, którzy na tym etapie poznawania technologii JS F nie są tym zaintereso­ wani, mogą ten punkt pominąć i wrócić do niego dopiero wtedy, gdy będą zmuszeni anali­ zować reguły autorstwa innych programistów lub wygenerowane przez zautomatyzowane narzędzia. Algorytm otrzymuje trzy dane wejściowe: 1. wynik, czyli wartość atrybutu acti on lub łańcuch otrzymany wskutek przetworzenia wyrażenia odwołującego się do metody;

2. identyfikator bieżącego widoku; 3. akcję, czyli wartość stałą atrybutu acti on zdefiniowaną dla komponentu interfejsu, który zainicjował procedurę nawigacji. Pierwsza z dwóch faz działania tego algorytmu ma na celu odnalezienie pasującego elementu navigation-rule i obejmuje następujące kroki: 1.

Jeśli wynik ma wartość nul 1, natychmiast zwraca sterowanie i ponownie wyświetla bieżącą stronę.

2. Scala wszystkie reguły nawigacji z identyczną wartością elementu f rom- vi ew-i d.

3. Próbuje odnaleźć regułę, której wartość f rom-vi ew-i d dokładnie odpowiada identyfikatorowi widoku. Jeśli taka reguła istnieje, jest od razu wykorzystywana.

4. Analizuje wszystkie reguły nawigacji, których wartości elementu f rom- vi ew- i d kończą się symbolem wieloznacznym (np. secure). Dla każdej takiej reguły sprawdza, czy przedrostek (czyli łańcuch po usunięciu gwiazdki) jest identyczny jak odpowiedni przedrostek identyfikatora widoku. W razie wykrycia pasujących reguł wykorzystuje tę z najdłuższym pasującym przedrostkiem. 5. Jeśli istnieje reguła bez zdefiniowanego elementu f roni -vi ew-i d, wykorzystuje ją.

6. W razie braku jakiejkolwiek pasującej reguły ponownie wyświetla bieżącą stronę. Druga, ostatnia faza działania tego algorytmu polega na analizie wszystkich elementów navigation-case dopasowanej reguły nawigacji (która może obejmować wiele scalonych elementów navi gati on -rui e z pasującymi wartościami elementu from-vi ew-i d). Poszukiwanie pasującego przypadku wymaga wykonania następujących kroków: 1.

Jeśli istnieje przypadek z pasującymi wartościami elementów from-outcome i from-action, właśnie on jest wykorzystywany.

2. W przeciwnym razie jest wybierany (jeśli istnieje) przypadek z pasującą wartością elementu from-outcome, ale z inną wartością elementu from-action.

3. W przeciwnym razie jest wybierany (jeśli istnieje) przypadek z pasującą wartością elementu from-action, ale z inną wartością elementu from-outcome.

93

4. W przeciwnym razie jest wybierany (jeśli istnieje) przypadek, któiy nie obejmuje ani elementu from-outcome, ani elementu from-action.

5. Jeśli nie istnieje żadne dopasowanie, następuje ponowne wyświetlenie bieżącej strony. Oczywiście nie zachęcamy nikogo do tworzenia niejednoznacznych, nieczytelnych reguł nawigacji w budowanych programach. Dopóki będziemy unikali stosowania symboli wielo­ znacznych i elementów from-action, najprawdopodobniej nie będziemy się musieli zagłębiać w podobne algorytmy.

94

JavaServerFaces

4 Znaczniki standardowe JSF Tworzenie atrakcyjnych aplikacji JS F wymaga stosowania odpowiedniego zbioru bibliotek znaczników technologii JavaServer Faces — zarówno podstawowych, jak i znaczników języka H TM L, czyli łącznie 45 znaczników. Z uwagi na znaczenie i liczbę tych znaczników dla frameworku JS F w tym i kolejnym rozdziale zatytułowanym „Tabele danych” skoncentrujemy się właśnie na analizie znaczników, ich atrybutów i ich optymalnych zastosowań. Nawet najprostsze strony JS F wykorzystują znaczniki obu bibliotek. W iele stron aplikacji JavaServer Faces cechuje się strukturą zbliżoną do przedstawionej poniżej: taglib un="http://java.sun.com/jsf/core" prefix="f" %> taglib uri="http://java.sun.com/jsf/htmT' prefix="h" %>

Aby korzystać z bibliotek znaczników frameworku JSF, musimy je zaimportować za pomocą dyrektywy tagl i b (podobnie jak w powyższym fragmencie kodu). W roli przedrostków pro­ gramista może stosować dowolne wybrane przez siebie nazwy. Zgodnie z konwencją stosujemy przedrostki f oraz h odpowiednio dla bibliotek znaczników podstawowych i znaczników HTML-a. Nasze rozważania w tym rozdziale rozpoczniemy od krótkiego przeglądu elementów biblioteki podstawowej. Wspomniana biblioteka obejmuje 18 znaczników i jest nieznacznie mniejsza od swojego odpowiednika w postaci biblioteki H TM L (obejmującej 25 znaczników). Z uwagi na prostotę tej biblioteki i fakt, że większość jej znaczników została lub zostanie omówiona w innych rozdziałach tej książki, w tym rozdziale będziemy się koncentrować przede wszystkim na bibliotece znaczników języka H TM L. W dalszej części tego rozdziału przystąpimy do omawiania biblioteki znaczników HTM L-a ze szczególnym uwzględnieniem popularnych atrybutów wspólnych dla większości tych znaczników. Na końcu dokonamy analizy poszczególnych znaczników, czemu towarzyszyć będzie prezentacja tabel atrybutów i przykładów kodu, którą w przyszłej pracy można trak­ tować jak swoisty leksykon.

96

Rozdział 4. ■ Znaczniki standardowe JSF

JavaServer Faces

Biblioteka podstawowa obejmuje średnio po 3 ,5 atrybutów na znacznik; w bibliotece HTML-a ta średnia wynosi aż 2 8 .9 .

97

Większość znaczników podstawowych reprezentuje obiekty dodawane do komponentów : ■ atrybuty; ■ mechanizmy nasłuchujące; ■ konwertery;

Przegląd podstawowych znaczników JSF

■ mechanizmy weryfikujące; ■ facety;

Biblioteka podstawowa obejmuje znaczniki, które są niezależne od stosowanej technologii wizualizacji. Znaczniki podstawowe wymieniono i krótko opisano w tabeli 4.1.

■ parametry; ■ elementy selekcji.

Tabela 4.1. Znaczniki podstawowe JSF Znacznik

Opis

Patrz rozdział

view

Tworzy widok najwyższego poziomu.

i.

subview

Tworzy podwidok określonego widoku.

8.

attribute

Ustawia atrybut (parę klucz-wartość) komponentu macierzystego.

4.

param

Dodaje parametr komponentu potomnego do komponentu macierzystego.

4.

facet

Dodaje facetę do komponentu.

4.

actionListener

Dodaje do komponentu obiekt nasłuchujący akcji.

7.

setPropertyActi onLi stener

Dodaje obiekt nasłuchujący akcji i ustawiający właściwość.

7.

valueChangeListener

Dodaje do komponentu obiekt nasłuchujący zmian wartości.

7.

phaseListener(JSF 1.2)

Dodaje do widoku macierzystego obiekt nasłuchujący faz.

7.

converter

Dodaje do komponentu dowolny konwerter.

6.

convertDateTime

Dodaje do komponentu konwerter daty i godziny.

6.

convertNumber

Dodaje do komponentu konwerter liczb.

6.

validator

Dodaje do komponentu mechanizm weryfikujący.

6.

validateDoubleRange

Rejestruje walidator Doubl eRangeVal i dator do weryfikacji wartości komponentu.

validateLength

Weryfikuje długość wartości komponentu.

6.

validateLongRange

Rejestruje walidator LongRangeVal idator do weryfikacji wartości komponentu.

6.

loadBundle

Ładuje pakiet zasobów, zapisując właściwości w strukturze typu Map.

2.

selectitems

Wskazuje wiele elementów dla komponentu umożliwiającego wybór jednej lub wielu opcji.

4.

selectitem

Wskazuje pojedynczy element dla komponentu umożliwiającego wybór jednej lub wielu opcji.

4.

verbatim

Przekształca tekst zawierający znacznik w komponent.

4.

(JSF 1.2)

6.

Biblioteka podstawowa obejmuje też znaczniki umożliwiające definiowanie widoków i podwidoków, ładowanie pakietów zasobów oraz umieszczanie na stronie dowolnego tekstu. Wszystkie znaczniki podstawowe wymienione w tabeli 4.1 zostały lub zostaną szczegóło­ wo omówione w innych częściach tej książki. Przyjrzyjmy się teraz znacznikom f : a ttri bute, f : parani i f : facet. Każdy komponent może składować w swojej mapie atrybutów dowolne pary nazwa-wartość. Istnieje możliwość ustawienia atrybutu w kodzie strony i jego późniejszego odczytania na poziomie programu. Przykład takiego rozwiązania przedstawiono w punkcie „Przekazywanie atrybutów mecha­ nizmom konwertującym” w rozdziale 6., gdzie zastosowano następującą definicję separato­ ra grup cyfr numeru karty kredytowej:

/>

Konwerter odpowiedzialny za formatowanie danych wynikowych otrzymuje ten atrybut z komponentu umieszczonego na stronie.

f:

Znacznik parani dodatkowo umożliwia nam definiowanie par nazwa-wartość, w których część wartości znajduje się w odrębnym komponencie potomnym. Na pierwszy rzut oka taki mechanizm składowania sprawia wrażenie niepotrzebnie skomplikowanego, musimy jednak pamiętać, że komponenty potomne tworzą listę (zamiast mapy). Znacznik f : param stosujemy w sytuacji, gdy chcemy przekazać wiele wartości dla pojedynczej nazwy (lub w ogóle bez nazwy). Z przykładem takiego rozwiązania mieliśmy do czynienia w podrozdziale „Kom uni­ katy obejmujące zmienne” w rozdziale 2., gdzie komponent h :outputForm at zawierał listę potomków w formie znaczników f: pa ram. 1 1 1 ! Komponent h;commandl i nk przekształca swoje elem enty potom ne f: pa ram w pary I m I nazwa-wartość żądania protokołu HTTP. M echanizm nasłuchiwania zdarzeń, który je s t aktywowany w odpowiedzi na kliknięcie łącza przez użytkownika, m oże następnie uzyskiwać te pary nazwa-wartość za pośrednictwem mapy żądania. Opisywana technika zostanie zadem onstrow ana w rozdziale 7. I wreszcie element f : fa c e t dodaje nazwany komponent do mapy facet danego komponentu. Wbrew pozorom faceta nie jest komponentem potomnym — każdy komponent obejmuje zarówno listę swoich komponentów potomnych, ja k i mapę nazwanych komponentów facet.

98

Rozdział 4. ■ Znaczniki standardowe JSF

JavaServerFaces Komponenty facet z reguły są wizualizowane w specjalnym miejscu. Sposób korzystania w tabelach danych z facet nazwanych "header" i "footer" omówimy w podrozdziale „N a­ główki, stopki i tytuły” w rozdziale 5. Atrybuty znaczników f :attribute, f: parani i f: facet przedstawiono w tabeli 4.2.

Tabela 4.2. Atrybuty elementów f:attribute,

i f:facet

Tabela 4.3. Znaczniki JSF HTML Znacznik

Opis

form

Formularz HTML

inputText

Kontrolka jednowierszowego pola tekstowego

inputTextarea

Kontrolka wielowierszowego pola tekstowego

inputSecret

Kontrolka pola hasła

iriputHidden

Pole ukryte

Atrybut

Opis

name

Nazwa atrybutu, komponentu parametru lub facety.

value

Wartość atrybutu lub parametru komponentu (poza elementem f: facet).

outputLabel

Etykieta innego komponentu

binding, id

Patrz tabela 4.4 (tylko f: param).

outputLink

Kotwica HTML-a

outputFormat

Odpowiednik kontrolki outputText umożliwiający formatowanie komunikatów złożonych

outputText

Jedno wierszo we, wyjściowe pole tekstowe

commandButton

Przycisk akceptacji, czyszczenia formularza lub opcji

commandLink

Łącze działające jak przycisk

message

Wyświetla najnowszy komunikat dla komponentu

messages

Wyświetla wszystkie komunikaty

graphiclmage

Wyświetla obraz

selectOneListbox

Lista umożliwiająca wybór pojedynczego elementu

selectOneMenu

Menu umożliwiające wybór pojedynczego elementu

selectOneRadio

Zbiór przycisków opcji

selectBooleanCheckbox

Pole wyboru

selectManyCheckbox

Zbiór pól wyboru

selectManyListbox

Lista umożliwiająca wybór wielu elementów

selectManyMenu

Menu umożliwiające wybór wielu elementów

panel Grid

Tabela języka HTML

panelGroup

Dwa lub wiele komponentów rozmieszczanych łącznie

dataTable

Kontrolka tabeli oferująca bogatą funkcjonalność

column

Kolumna w tabeli dataTabl e

- “A 1

-■■■■ ■ — -r-r-?— T7 7 7 —

t

^

7

......

■ .■ X

77

¡^ ■ W s z y s tk im atrybutom znaczników (z wyjątkiem var oraz id ) m ożna przypisywać H wyrażenia reprezentujące wartości lub wyrażenia odwołujące się do m etod. Atry­ butowi v a r zawsze należy przypisywać łańcuchy, natom iast atrybutowi id m ożna przy­ pisywać łańcuchy lub wyrażenia bezpośrednie $ { . . . - } .

Przegląd znaczników JSF reprezentujących znaczniki HTML (JSF HTML) Znaczniki JS F H T M L reprezentują następujące rodzaje komponentów: ■ komponenty wej ściowe, ■ komponenty wyj ściowe, ■ polecenia, ■ komponenty selekcji, ■ inne. Do kategorii „inne” zaliczamy formularze, komunikaty i komponenty odpowiedzialne za roz­ mieszczanie pozostałych komponentów. Wszystkie znaczniki HTML-a wymieniono w tabeli 4.3.

99

Znaczniki języka H T M L można podzielić na następujące kategorie: ■ rozmieszczenia (panel Gri d); ■ wejściowe (in p u t.. .); ■ tabeli danych (dataTable) — patrz rozdział 5.; ■ wyjściowe (output.. .); ■ błędy i komunikaty (message, messages). ■ poleceń (commandButton i commandLi nk); ■ wyboru (checkbox, 1i stbox, menu, radi o);

Znaczniki JS F H T M L wykorzystują atrybuty wspólne, atrybuty przenoszone HTM L-a oraz atrybuty obsługujące dynamiczny H TM L.

100

Rozdział 4. ■ Znaczniki standardowe JSF

üavaServerFaces

K M Znaczn ki MTV IL-a m ogą sprawie >ć w rażeni przesadr lie długich — na prz ykład ■ J znaczni k sele ctManyListbox m ożna by z pow odzeń e m zas tą p ić znaczn ikiem multiList. 0 kazuje się jednak, że takie opisowe ilazwy dobr ze reprezentują komb ¡nacje komponentóv i mecł lanizmów wizualiza«;ji, stąd ws pomniany z nacznik selectManyLi stbox reprezentuje kom po nent selectMany fwłączony ; mechanlz m em wizualizacji lis ¡tbox, Znajom ość t ypu ko m ponentu repreze ntowanege przez zn
É É | Zarówni progrsimiści technologii JS5F, jak i prctgramiści fr ameworku Struts impl emenK i t u j ą śtr ony inteîm eto w e , korzysta jąc ze zna czników ni estandardowych JSP Okażuje się, że o ile z naczniki fram ewot ku Struts bezpośred nio generują kod H I ‘ML-a, o tyle znaczi lik i JS re p rezen tu ją ko m ponenty niezależn e od technologii zn aczników oraz metchanlzrn wizualizacji odpo wiedzialny za genero« ranie kodu języka HTI'4L. Ta kluczowa róz.nica ułlatwia dostosowyv vanie aplileacji JSF cio potrzeb a ltern aty wnych technologii vvizualiz acji.

Atrybuty wspólne Istnieją trzy rodzaje atrybutów znaczników, które mogą być współdzielone przez wiele znacz­ ników komponentów HTML-a: ■ atrybuty podstawowe, ■ atrybuty HTM L-a 4.0, ■ atrybuty zdarzeń DHTML-a. Poszczególne typy przeanalizujemy w kolejnych podpunktach.

Atrybuty podstawowe Jak wynika z tabeli 4.4, atrybuty podstawowe są współdzielone przez zdecydowaną większość znaczników HTM L-a technologii JSF . Atrybuty id oraz binding, które można stosować dla wszystkich znaczników HTML-a, odwo­ łują się do komponentu — atrybut id jest wykorzystywany przede wszystkim przez autorów stron, natomiast atrybut bi ndi ng częściej wykorzystują programiści Javy.

101

Tabela 4.4. Atrybuty podstawowe znaczników języka HTMÛ Atrybut

Typy komponentów

Opis

id

A (25)

Identyfikator komponentu

binding

A (25)

Łączy dany komponent z właściwością komponentu wspomagającego

rendered

A (25)

Atrybut logiczny; wartość fa 1se wstrzymuje wizualizację

styleClass

A (23)

Nazwa klasy CSS (od ang. Cascading Style Sheet)

value

1. 0 , C (19)

Wartość komponentu (zwykle w formie wyrażenia reprezentującego wartość)

valueChangeListener

1(11)

Wyrażenie odwołujące się do metody, która reaguje na zmiany wartości

converter

1 ,0 (1 5 )

Nazwa klasy konwertera

validator

1(11)

Nazwa klasy weryfikującej utworzonej i dołączonej do komponentu

required

1(H)

Atrybut logiczny; wartość true oznacza konieczność wpisania wartości w odpowiednim polu

converterMessage, validatorMessage, requi redMessage (JSF 1.2)

1( H)

Komunikat niestandardowy wyświetlany w razie wystąpienia błędu konwersji lub weryfikacji poprawności albo braku wymaganych danych wejściowych

Wszechobecne atrybuty rendered i styleClass mają wpływ na sposób wizualizacji kompo­ nentów. W dalszej części tego podrozdziału dokonamy krótkiej analizy tych ważnych atrybutów.

Identyfikatory i związki Uniwersalny atrybut id umożliwia realizację następujących zadań: ■ uzyskiwanie dostępu do komponentów JS F z poziomu pozostałych znaczników JSF ; ■ uzyskiwanie referencji do komponentów na poziomie kodu Javy; ■ uzyskiwanie dostępu do elementów HTM L-a z poziomu skryptów.

Atrybuty value i converter umożliwiają definiowanie wartości komponentów oraz ich kon­ wertowanie z reprezentacji łańcuchowych na obiekty (i odwrotnie).

W tym podpunkcie omówimy pierwsze dwa z wymienionych powyżej zadań. Szczegółową analizę ostatniego zadania można znaleźć w punkcie „Elementy formularza i język JavaScript” w dalszej części tego rozdziału.

Atrybuty validator, required i valueChangeListener można stosować dla komponentów wejściowych; umożliwiają weryfikowanie podawanych wartości oraz reagowanie na ich zmiany. Więcej informacji o mechanizmach weryfikacji poprawności i konwersji można znaleźć w rozdziale 6.

Atrybut i d umożliwia autorom stron odwoływanie się do komponentów z poziomu innych znaczników. Istnieje na przykład możliwość wyświetlenia dla komponentu komunikatu o błę­ dzie z wykorzystaniem następującej konstrukcji:

A — wszystkie, I — wejściowe, O — wyjściowe, C — polecenia, (n) — liczba znaczników, dla których można stosować dany atrybut.

102

JavaServerFaces

Rozdział 4. ■ Znaczniki standardowe JSF



Atrybut converter (wspólny dla znaczników kontrolek wejściowych i wyjściowych) umoż­ liw ia nam dołączanie do komponentów mechanizmów konwertujących, tzw. konwerterów. Dla znaczników kontrolek wejściowych możemy dodatkowo stosować atrybut v a lid a to r dołączający do odpowiednich komponentów mechanizmy weryfikujące. Konwertery i me­ chanizmy weryfikujące zostaną szczegółowo omówione w rozdziale 6.

Identyfikatory komponentów można wykorzystywać także do uzyskiwania odpowiednich referencji na poziomie kodu źródłowego Javy. Za pomocą następującego wyrażenia mogli­ byśmy uzyskać dostęp do komponentu name na przykład w obiekcie nasłuchującym: UlComponent component = event.getComponentO.findComponent("name").

W przedstawionym wywołaniu metody findComponent mamy do czynienia z pewnym istotnym ograniczeniem: komponent, który wygenerował dane zdarzenie, musi należeć do tego samego formularza (lub tabeli danych) co komponent name. Istnieje lepszy sposób uzyskiwania dostępu do komponentów z poziomu kodu Javy. Komponent można zdefiniować w formie pola egzemplarza jakiejś klasy, zdefiniować dla niego metody zwracające i ustawiające wartość właściwości, po czym użyć w kodzie strony JS F odpowiedniego atrybutu binding:
/>

Atrybutowi binding przypisujemy wyrażenie reprezentujące wartość, które w tym przypadku odwołuje się do właściwości (dostępnej do odczytu i zapisu) komponentu Javy. Więcej infor­ macji na temat tego atrybutu można znaleźć w podrozdziale „Komponenty wspierające" w rozdziale 2. Implementacja JS F przypisuje tej właściwości komponent interfejsu użytkow­ nika, dzięki czemu możemy na nim operować z poziomu naszego programu. Istnieje też możliwość programowego tworzenia komponentów, które będą stosowane zamiast komponentów definiowanych w kodzie stron JS F . Na przykład właściwość komponentu formularza slatePrompt można by zaimplementować w następujący sposób: p r i v a t e UlComponent slatePrompt = new u lO u t p u t O . public UlComponent getSt aie Prom pL( ) { return statePrompt. } pu blic void setStatePrompt(UlComponent statePrompt) { }

Kiedy framework JavaServer Faces po raz pierwszy odkrywa wyrażenie reprezentujące wartość w postaci # {form.statePrompt}, wywołuje metodę Form.getStatePrompt(). Jeśli wspomniana metoda zwróci wartość nul 1 (co jest zupełnie naturalne), implementacja JS F utworzy kompo­ nent zgodnie z opisem zawartym na stronie JSF. Jeśli jednak metoda Form.getStatePrompt() zwróci referencję do komponentu (jak w przypadku powyższego fragmentu kodu), zostanie wykorzystany właśnie ten komponent.

103

Style Możemy stosować — albo w formie konstrukcji wbudowanych (atrybut style), albo w formie klas (atrybut styl eCl ass) — style CSS, które mają wpływ na sposób wizualizowania kompo­ nentów. W większości przypadków odpowiednim atrybutom przypisuje się stałe łańcuchowe (zamiast wyrażeń reprezentujących wartości):

:

W kolejnym kroku powinniśmy użyć atrybutu styleClass:

'

-



Od tej pory możemy modyfikować wygląd kontrolek h:outputText, aktualizując wyłącznie arkusz stylów styles.css.

Wartości, konwertery i mechanizmy weryfikacji Komponenty wejściowe, wyjściowe, poleceń i tabel danych reprezentują jakieś wartości. Odpowiednie znaczniki biblioteki znaczników języka H TM L, jak h: i nputText czy h:dataTabl e, obejmują atrybut val ue. Za pośrednictwem tego atrybutu możemy definiować wartości w for­ mie łańcuchów:

W zdecydowanej większości przypadków przypisujemy temu atrybutowi wyrażenia repre­ zentujące wartości:

Wizualizacja warunkowa Atrybut rendered może być wykorzystywany do włączania komponentów do procesu wizu­ alizacji strony lub ich wyłączania z tego procesu (w zależności od zdefiniowanych wcześniej warunków). Możemy na przykład uzależnić prezentację przycisku Wyloguj od tego, czy dany użytkownik jest załogowany:

104

JavaServer Faces Aby warunkowo wyświetlać grupę komponentów, należy je umieścić w elemencie h : panel Gr i d obejmującym atrybut rendered. Więcej informacji na len lemat można znaleźć w podrozdziale „Panele" w dalszej części lego rozdziału.

Rozdział 4. ■ Znaczniki standardowe JSF

105

Tabela 4.5. Atrybuty przekazywane standardu HTML 4.Cr

Warto pam iętać o możliwości stosowania operatorów w wyrażeniach reprezentują­ cych w artości. M ożna by na przykład zdefiniow ać w idok przypom inający panel z zakładkam i przez warunkową (opcjonalną) wizualizację poszczególnych paneli w zależ­ ności od wybranej zakładki. W takim przypadku należałoby użyć elem entu hrpanelGrid w następujący sposób:

Q

Atrybut

Opis

accesskey (14)

klawisz dostępu (zwykle połączony z systemowymi klawiszami dostępu) umożliwiający aktywowanie danego elementu.

accept ( 1)

Lista oddzielonych przecinkami typów zawaności akceptowanych przez dany formularz.

accepicharset ( 1) Lista oddzielonych przecinkami lub spacjami schematów kodowania znaków dla danego

formularza. Atrybut zbioru znaków HTML-a określa się za pomocą atrybutu JSF nazwanego acceptcharset.


Formularze Działanie aplikacji internetowych, w tym aplikacji JS F , opiera się na formularzach języka H TM L. W tabeli 4.7 wymieniono i krótko opisano wszystkie atrybuty elementu h: form.

W przeciwieństwie do znacznika form języka H TM L znacznik h: form nie obsługuje atrybutów method i action. Ponieważ istnieje możliwość zapisywania stanu klienta (za pośrednictwem mechanizmu pól ukrytych), zrezygnowano z rozwiązania polegającego na przesyłaniu formularzy za pomocą metody GET protokołu HTTP. Ilość danych w takich ukrytych polach może przekraczać rozmiar bufora parametrów żądania typu GET, stąd wszystkie operacje przesyłania formularzy JS F zaimplementowano z wykorzystaniem metody POST. Stosowanie atrybutu anchor nie jest konieczne, ponieważ operacja wysyłania formularza JS F zawsze dotyczy bieżącej strony. (Nawigacja do nowej strony następuje dopiero po wysłaniu danych formularza na serwer). Znacznik h: form generuje element form języka H TM L. Jeśli na przykład w kodzie strony JS F nazwanej /index.jsp użyjemy znacznika h:form bez żadnych atrybutów, mechanizm odpo­ wiedzialny za wizualizację tej strony wygeneruje następujący kod HTML-a:

Rysunek 4.1. Przykład wykorzystania skryptu JavaScript do zarządzania dostępem do elementów formularza

109

Irinę

< input id="registerForm;password" t ype ="text" name=" registerFor m password"/>

woitek

Hasło



Potwierdź hasł*

4 | Przykład uzyskiwania dostępu do eleitentów formularza z poaon^kryp.. t& a w » Z akończono

Naaçdaa

* A f S ! nttp.viocai^on.8080.! T Ä ' f t T " ------------- --- ~-----J - w - i - — iu— i. Lmiç

fApiikacja JavaScript!

TmTW

Pornag, ................. ^ ' --------

...



Wszystkie kontrolki formularza generowane przez implementację JS F mają nazwy zgodne z następującą konwencją:

Hasło Ją

Pce hasta rozrv ne od pola potwierdzenia hasła'

Potwierdź

Zakończono

Za pomocą atrybutu id możemy przypisywać nazwy generowanym elementom języka H TM L i tym samym umożliwiamy dostęp do tych elementów z poziomu skryptów języka JavaScript:

Kiedy użytkownik klika przycisk, następuje wywołanie funkcji checkPassword JavaScriptu, którą zdefiniowano w następujący sposób: function checkPassword(form) { var password = forni["registerForm:password"].value: var passwordConfirm = form["registerForm:passwordConfirm"].value; i f (password == passwordConfirm) form.submitO: else alert("Pole hasła różni się od pola potwierdzenia hasła!");

ndZwdFormuldrzd.ndZwdKomponentu

gdzie ndzwdFormuidrzd reprezentuje nazwę formularza, do którego należy dana kontrolka, natomiast ndzwaKomponentu reprezentuje nazwę samej kontrolki. Jeśli nie określimy wartości atrybutów id, framework JavaServer Faces utworzy odpowiednie identyfikatory automa­ tycznie (co było widać na przykładzie przycisku zdefiniowanego w powyższym fragmencie kodu HTML-a). Wówczas uzyskanie dostępu do pola hasła będzie wymagało użycia nastę­ pującej konstrukcji: document.forms. registerFormL" registerForm:password"J .va 1ue

Strukturę katalogów aplikacji z rysunku 4.1 przedstawiono na rysunku 4.2. Kod odpowiedniej strony JS F przedstawiono na listingu 4.1, natomiast pakiet komunikatów dla polskiej wersji aplikacji przedstawiono na listingu 4.2.

Rysunek 4.2. Struktura katalogów przykładowej aplikacji ilustrującej sposób korzystania ze skryptów języka JavaScript

¡¡3 javascript, war META-INF |

’ Q MANIFEST. MF

f Q WEB-INF \ f (^3 classes I

|

f (¡3 com corejsf 0 messages, properties

|

L Q faces-config.xmi

I

!....Q web.xml

F

D styles, css

r Q index.html '■ Q index.jsp

110

Rozdział 4. ■ Znaczniki standardowe JSF

JavaServer Faces

Listing 4.1. Kod strony

java

1. 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. <%® taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. 5. 6. 9

116

JavaServer Faces

Rysunek 4.4. Struktura katalogów przykładowej aplikacji prezentującej jednoi wielowierszowe pola tekstowe

Rozdział 4. ■ Znaczniki standardowe JSF S3 personafData.war f ą MET A-INF | L D MANIFEST.MF f- £ 3 WEB-IMF |

[ 3 classes

| i | |

f [¡3 com Ÿ (¡3 corejsf

|

|

I D UserBean.class

!

|

' Q messages, properties

\

r - D faces-config.xml

i ' Q web.xml | Q index.html j~ Q

in d e x .jsp

L D tharikYou.jsp_____________________

10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37 38. 39. 40. 41. 42. 43. 44. 45.



Listing 4.4. Kod strony personalData/web/thankYou.jsp 1. 2. <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4.

5. 6. 10. 11. 12. 13. 14. 15. 22. 29. 30.

16. 18. 20. 21.

23. 25. 27. 28.

31.

32. 34.

35. 36. 37. 40. 48. 51. 52. 53.

56 60. 61. 62. 66. 67.

38. 39.	41. 47.	49. 50.
54. 55.	57 59
63. 65.

68. 69. 70 71.

Listing 4.9. Zawartość pliku flags/src/java/com/corejsf/UserBean.java__________________________ 1. package com.corejsf; 2.

3. public class UserBean { 4. private String name: 5. private String password; 6. private String aboutYourself; 7. 8. // Właściwość name: 9. public String getNameO { return name; } 10. public void setName(String newValue) { name = newValue; } 11.

12. 13. 14. 15. 16. 17. 18. 19. }

// Właściwość password: public String getPasswordO { return password; } public void setPassword(String newValue) { password = newValue; } // Właściwość aboutYourself: public String getAboutYourselfO { return aboutYourself; } public void setAboutYourself(String newValue) { aboutYourself = newValue; }

Listing 4.10. Kod komponentu flags/src/java/com/corejsf/ChangeLocaleBean.java 1. package com.corejsf; 2

.

3. import java.util.Locale; 4. import javax.faces.context.FacesContext; 5. 6. public class ChangeLocaleBean { 7. public String polishAction() { 8. FacesContext context = FacesContext,getCurrentInstance(); 9. context.getViewRootO,setLocale(Locale.POLISH); 10. return nul1; 11. } 12.

13. 14. 15.

public String englishAction() { FacesContext context = FacesContext.getCurrentInstance(); context.getViewRootO,setLocale(Locale.ENGLISH);

129

130

Javaserver Faces 16

U

Rozdział 4. ■ Znaczniki standardowe JSF

return nul 1,

131

■ h:selectManyLi stbox

}

■ h:selectOneMenu

18 }

■ h:selectManyMenu

Listing 4.11. Plik konfiguracyjny flags/web/WEB-INF/faces-config.xml Praktyczne przykłady zastosowań każdego z tych znaczników przedstawiono w tabeli 4.19. 1 2 7. 8. /index.jsp 9 10 thankYou 11. /thankYou.jsp 12. 13 14. 15 16. localeChanger 17. -managed-bean-class>com.corejsf.ChangeLocaleBean 18. session 19. 20. 21 22. user 23. com.corejsf UserBean 24 session 25 26 27. 28 29. com.corejsf,messages 30. msgs 31. 32 33.

Tabela 4.19. Przykłady użycia znaczników selekcji Znacznik

Wygenerowany kod HTML-a

Przykłady

h:selectBooleanCheckbox



Chcę otrzymywać pocztę: ff]

h:selectManyCheckbox

<1abel>

h:selectOneRadio

<1abel> Ser

h:selectManyListbox

Ser

Znaczniki selekcji

Ser

hiselectManyMenu

■ h:selectManyCheckbox

Niedziela

■ h:selectOneRadio



■ h:selectBooleanCheckbox

■ h:selectOneListbox

''6 ‘ Średnie '"*) Licencjat O "Wyższe O Doktorat



h:selectOneMeriu

Technologia JavaServer Faces oferuje siedem znaczników kontrolek umożliwiających wybór opcji:

B Czerwony BI Niebieski

[sier Marynata Musztarda1 Sa ła ta

132

JavaServer Faces

Rozdział 4. ■ Znaczniki standardowe JSF

Zdecydowanie najprostszym znacznikiem selekcji jest h: sel ectBool eanCheckbox, czyli element reprezentujący pole wyboru, które można łatwo związać z właściwością typu boolean kom­ ponentu JavaBean. Zbiór pól wyboru można też prezentować na stronie za pomocą znacznika h: sel ec1:ManyCheckbox. Znaczniki, których nazwy rozpoczynają się od przedrostka selectOne, umożliwiają użytkow­ nikowi zaznaczanie po jednym elemencie kolekcji. Za pomocą tego rodzaju znaczników generujemy zbiory przycisków opcji oraz menu i listy jednokrotnego wyboru. Znaczniki sel ectMany opisują zbiory pól wyboru oraz menu i listy wielokrotnego wyboru. Wszystkie znaczniki selekcji obsługują niemal identyczne zbiory atrybutów (patrz tabela 4.20).

Pola wyboru i przyciski opcji Pola wyboru mogą być reprezentowane przez dwa znaczniki JS F : ■ h:selectBooleanCheckbox ■ h:se lectManyCheckbox Znacznik h: sel ectBool eanCheckbox reprezentuje pojedyncze pole wyboru, które można związać z właściwością typu boolean komponentu JavaBean. Poniżej przedstawiono prosty przykład takiego rozwiązania: Proszę o kontakt g)

Tabela 4.20. Atrybuty znaczników h:selectBooleanCheckbox, h:selectManyCheckboxf hiselectOneRadio, h:seiectOneUstbox, h:selectManyListbox, h:selectOneMenu oraz h:selectManyMenu

Atrybuty

Opis

disabledClass

Klasa CSS dla kontrolek wyłączonych (atrybut nie może być stosowany dla znacznika h: sel ectBool eanCheckbox.

enabledClass Layout

Klasa CSS dla kontrolek włączonych (atrybut nie może być stosowany dla znacznika h: sel ectBool eanCheckbox. Określa sposób rozmieszczenia elementów: 1i neDi recti on (poziomo) lub pageDi recti on (pionowo). Atrybut może być stosowany tylko dla znaczników h: sel ectOneRadi o i h: sel ectManyCheckbox.

label (JSF 1.2)

Opisuje komponent, który należy wykorzystać w razie konieczności wyświetlenia komunikatu o błędzie.

binding, converter, converterMessage

Atrybuty podstawowe21.

(JSF 1.2), requiredMessage (JSF 1.2), id, immediate, styleClass, required, rendered, validator, validatorMessage (JSF 1.2), value, valueChangeListener accesskey, border, dir, disabled, lang, HTML 4.022 — atrybut border można stosować tylko dla znaczników readonly, style, size, tabindex, t it le h: sel ectOneRadi o i h; sel ectManyCheckbox. atrybut size można stosować dla znaczników h: sel ectOneLi stbox i h;selectManyListbox. onblur, onchange, onclick, ondblclick, Zdarzenia języka DHTML23. onfocus, onkeydown, onkeypress, orikeyup, onmousedown, onmousemove, onmouseout, onmouseover, onmouseup, onselect

133

W kodzie strony JS F należy umieścić następującą konstrukcję:

W komponencie wspierającym powinniśmy zdefiniować następującą właściwość dostępną do odczytu i zapisu: private boolean contactMe, public void setContactMe(boolean newValue) { contactMe = newValue;

} public boolean getContactMeO { return contactMe;

} Na tej podstawie zostanie wygenerowany następujący znacznik języka H TM L:

Grupę pól wyboru można utworzyć za pomocą znacznika h: sel ectManyCheckbox. Już na podstawie jego nazwy można się domyślić, że istnieje możliwość zaznaczenia jednego lub wielu pól wyboru wchodzących w skład takiej grupy. Pola wyboru tej grupy definiujemy w ciele znacznika h: sel ectManyCheckbox (w formie jednego lub wielu znaczników f: select Item lub jednego znacznika f : select Items). Więcej informacji o tych znacznikach można znaleźć w punkcie „Elementy” w dalszej części tego podrozdziału. Poniżej zdefiniowano przykłado­ wą grupę pól wyboru umożliwiających wybór kolorów: fU Czerwony @ Niebieski □ Zoty p Zielony 0 Pomarańczowy Znacznik h: sel ectManyCheckbox mógłby mieć następującą postać:

21 Patrz tabela 4.4. 22 Patrz tabela 4.5. 23 Patrz tabela 4.6.



Same pola wyboru definiujemy za pomocą znaczników f : selectltem lub f : select Items (patrz punkt „Elem enty” ).

134

Rozdział 4. ■ Znaczniki standardowe JSF

JavaServer Faces Znacznik h:selectManyCheckbox generuje element ta ble języka H TM L; poniżej przedstawiono kod HTML-a wygenerowany dla naszego przykładu:

Czerwony

Każdy kolor jest reprezentowany przez odrębny element i nput otoczony znacznikiem 1abel i ułatwiający uzyskiwanie dostępu do jego stanu. Element 1abel jest z kolei umieszczany w ciele znacznika td. Przyciski opcji zaimplementowano w formie znacznika h:selectOneRadio. Poniżej przed­ stawiono efekt jego użycia w kodzie strony JS F : O Średnie O Licencjat Ęj Wyższe O Doktorat Atrybut va 1ue znacznika h: sel ectOneRad i o reprezentuje aktualnie zaznaczony element. Także w tym przypadku wypełnienie przycisków opcji wymaga użycia wielu znaczników f •sel ect I tern:

Podobnie jak znacznik h:selectManyCheckbox, tak i znacznik h: seiectOneRadio generuje tabelę języka H TM L. Poniżej przedstawiono kod tabeli wygenerowanej na podstawie powyższego fragmentu:

<1abel for="Jd2:_idl4"> Średnie

Generowanie tabel HTM L-a nie jest jedyną cechą wspólną znaczników h: sel ectOneRadi o i h: sel ectManyCheckbox — w obu możemy też stosować unikatowe atrybuty: ■ border ■ enabledClass

135

■ disabledClass ■ 1ayout Atrybut border określa szerokość obramowania. Poniżej przedstawiono przykładowe przy­ ciski opcji i pola wyboru z obramowaniami o grubości odpowiednio jednego i dwóch pikseli: ¡ O Ś r e d n ie j# L ic e n c ja t ] £> W y fc s a e jO D o k to r a tj f f i C z e rw o n y j S I N ie b ie s k i ¡121 Z ś łty ¡ 0 -Z ie lo ny j Q P om arań czow y j

Atrybuty enabledClass i disabledClass wskazują klasy C SS wykorzystywane w sytuacji, gdy pola wyboru lub przyciski opcji są odpowiednio aktywne i nieaktywne. Na poniższym rysunku przedstawiono efekt zastosowania klasy C SS, która w przypadku aktywnych pól wyboru stosuje czcionkę pisaną kursywą, niebieski kolor liter i żółte tło: M Czerwony O Mebieski g j Żółty © Zwiany □ Pomarańczowy

Atrybutowi 1ayout możemy przypisać wartość 1meDirection (w poziomie) lub pageDi rect i on (w pionie). Dla grupy pól wyboru po lewej stronie zastosowano układ pageDi rect i on, natomiast dla grupy pól wyboru po prawej stronie zastosowano układ 11neDi rect i on: Ci Czerwony 1 Niebieski

pj Czerwony © Niebieski D Ż-5łty □ Zielony 121 Pomarańczowy

□ Zielony

Część programistów nie rozumie, dlaczego atrybutowi layout nie można przypisywać wartości horizontal ani vertical (zam iast odpowiednio lineDirection i page ^D irection). O ile w językach wywodzących się z łaciny kojarzenie określeń lin e ^Direction i pageDi rect i on z orientacją poziomą i pionową jes t dość naturalne, w innych językach podobne związki nie są tak oczywiste. Na przykład przeglądarki wyświetlające strony w języku chińskim, gdzie tekst je s t prezentowany z góry do dołu, mogą interpre­ tować w artość lineDirection jako układ pionowy i wartość pageDi rect i on jak o układ poziomy.

Menu i listy Menu i listy są reprezentowane przez następujące znaczniki JS F języka H TM L: ■ h:selectOneListbox ■ h:selectManyLi stbox ■ h:selectOneMeriu ■ h:selectManyMenu Atrybuty, które można stosować w tych znacznikach, wymieniono już w tabeli 4.20, zatem nie będziemy ich poddawać ponownej analizie.

136

JavaServer Faces Znaczniki menu i list generują elementy select języka H TM L. Znaczniki menu dodają do generowanego elementu select atrybut size="l". Właśnie wspomniany atrybut jest jedynym aspektem różniącym konstrukcje reprezentujące menu od konstrukcji reprezentujących listy.

Rozdział 4. ■ Znaczniki standardowo JSF

137

Do definiowania menu służą znaczniki h : selectOneMenu i h:selectManyMenu. Poniżej przed­ stawiono przykład menu jednokrotnego wyboru:

__

Przykład listy jednokrotnego wyboru przedstawiono poniżej: Znacznik h: sel ectOneMenu reprezentujący menu w tej formie ma następującą postać: 1902 1903 1904

Odpowiedni znacznik listy będzie miał następującą postać:

Łatwo zauważyć, że liczbę widocznych elementów listy określiliśmy za pośrednictwem atry­ butu si ze. Na podstawie tego kodu zostanie wygenerowany następujący kod języka H TM L: 1900 1901

Stosując znacznik h:selectManyListbox, możemy definiować listy wielokrotnego wyboru podobne do tej, którą przedstawiono poniżej:



A tak wygląda odpowiedni kod języka H TM L: N1edziela

Za pomocą znacznika h: sel ectManyMenu możemy definiować menu wielokrotnego wyboru. Na jego podstawie jest generowany kod HTML-a podobny do fragmentu przedstawionego poniżej: N1edziela

Okazuje się, że przedstawiony kod języka H TM L powoduje różne rezultaty w różnych przeglą­ darkach internetowych. Poniżej przedstawiono odpowiednie kontrolki wyświetlone w oknach przeglądarek Internet Explorer (z lewej strony) i Mozilla Firefox (z prawej strony): Znacznik opisujący tę listę ma następującą postać:

<1 selectItem itemValue="Polski" itemLabei="Polski"/>

Tym razem nie zdefiniowaliśmy atrybutu size, co oznacza, że lista zostanie wydłużona do rozmiarów umożliwiających prezentację wszystkich dostępnych elementów. Na podstawie tej konstrukcji zostanie wygenerowany następujący fragment kodu HTML-a: Angielski Polski

H H W języku HTML rozróżnienie pomiędzy menu a listami je s t dość sztuczne. Zarówno H ü l m enu, ja k i listy są reprezentowane przez elem enty select tego języka. Jedynym a sp e ktem dzielącym obie konstrukcje je s t stały atrybut $i ze=’T Tstosowany dla wszyst­ kich m enu. Zgodnie z naszymi oczekiwaniami wszystkie przeglądarki wyświetlają menu jednokrotnego wyboru w form ie list rozwijanych. Okazuje się jed n ak , że podobna spójność nie je s t zachow ana w przypadku m enu wielokrotnego wyboru definiowanych z wykorzystaniem atrybutów size—ł " i multiple. Za m ia st list rozwijanych umożliwiających wybór wielu elem entów — co byłoby zupełnie naturalne — niektóre przeglądarki wyświetlają dziwacz­ ne konstrukcje, ja k niem al bezużyteczne, m ikroskopijne paski przew ijania (In tern et Explorer 6 ), lub w cale nie w yśw ietlają pasków przew ijania, co w ym aga korzystania z klawiszy strzałek (Firefox 1 .5 ).

138

Rozdział 4. ■ Znaczniki standardowe JSF

JavaServer Faces Od początku podrozdziału „Znaczniki selekcji” konsekwentnie wykorzystywaliśmy wiele znaczników f:selectltem do wypełniania komponentów select. Skoro opanowaliśmy już podstawy znaczników selekcji, warto przystąpić do bliższej analizy znacznika f :selectltem i znacznika pokrewnego f : sel ectltenis.

Elementy Wszystkie znaczniki selekcji poza elementem h: sel ectBool eanCheckbox wykorzystują do definiowania dostępnych elementów znaczniki f : sel ectltem lub f : sel ectItems. Te kluczowe znaczniki przeanalizujemy w kolejnych podpunktach tego punktu (począwszy od znacznika f : selectltem ).

Znacznik f:selectltem Za pomocą znacznika f : sel ectltem możemy definiować elementy jednokrotnego wyboru:

Wartości w poszczególnych elementach (Ser, Marynata itd.) są przekazywane w formie wartości parametrów żądania w czasie wysyłania formularza, do którego należy tak zdefiniowane menu. Wartości przypisane atrybutom i temLabel są wykorzystywane w roli etykiet elementów menu. W pewnych sytuacjach warto rozważyć stosowanie innych wartości parametrów żądania i innych etykiet elementów: <1 selectltem itemValue="l" itemLabel-"Ser"/>

Opisy elementów tworzymy wyłącznie z myślą o narzędziach odwołujących się do kodu naszych stron JS F , ponieważ ich treść nie wpływa na kształt generowanego kodu HTML-a.

139

Z nieco inną sytuacją mamy do czynienia w przypadku atrybutu itemDi sabl ed, którego wartość jest przekazywana do kodu języka H TM L. W tabeli 4.21 wymieniono i krótko opisano atrybuty znacznika f: selectltem.

Tabela 4-21. Atrybuty znacznika f¡selectltem Atrybut

Opis

binding

Reprezentuje związek z komponentem JavaBean — więcej informacji na temat związków z komponentami można znaleźć w rozdziale 2.

id

Identyfikator komponentu.

itemDescription

Opis wykorzystywany wyłącznie przez narzędzia zewnętrzne.

itemDisabled

Wartość logiczna ustawiająca dla danego elementu atrybut di sabl ed języka HTML.

itemLabel

Tekst wyświetlany przez dany element.

itemValue

Wartość danego elementu (przekazywana na serwer w formie parametru żądania).

value

Wyrażenie reprezentujące wartość i wskazujące na egzemplarz klasy Selectltem.

escape (JSF 1.2)

Ma wartość true, jeśli znaki specjalne użyte w wyrażeniu przypisanym atrybutowi val ue mają być konwertowane na odpowiednie sekwencje; lub fal se, jeśli wyrażenie przypisane atrybutowi val ue nie ma podlegać konwersji.

Za pośrednictwem atrybutu value znacznika f: sel ectltem możemy uzyskiwać dostęp do egzemplarzy klasy Sel ectltem utworzonych w ramach komponentu JavaBean:

Wyrażenie reprezentujące wartość, które w przedstawionym przykładzie przypisano atrybutowi val ue, wskazuje na metodę zwracającą egzemplarz klasy javax. faces .model. Sel ectltem: public Selectltem getCheeseltemO return new SelectTtemCSer"):

{

} fflffl javax.faces.model.Selectltem ■ S e le c t!temCObject value) Tworzy obiekt klasy Selectltem na podstawie przekazanej wartości. Etykieta konstruowanego elementu jest uzyskiwana przez zastosowanie dla argumentu value metody toStnngO. ■ SelectitemCObject value. String label) Tworzy obiekt klasy Se l ect Ltem na podstawie przekazanej wartości i etykiety. ■ SelectitemCObject value. String label. String description) Tworzy obiekt klasy Select I tem na podstawie przekazanej wartości, etykiety i opisu. ■ SelectitemCObject value. String label. String description, boolean disabled) Tworzy obiekt klasy Sel ectltem na podstawie przekazanej wartości, etykiety, opisu i stanu aktywności.

140

JavaServer Faces

Znacznik f:selectltems Z lektury podpunktu „Znacznik f:selectltem” wiemy, że znacznik f : sel ectItem jest stosowany niemal na każdym kroku w konstrukcjach reprezentujących kontrolki selekcji. Definiowanie więcej niż kilku elementów za pośrednictwem tego znacznika jest jednak dość kłopotliwe. Okazuje się, że pierwszy fragment kodu ze wspomnianego punktu można by zredukować do wyrażenia w następującej formie:

Wyrażenie reprezentujące wartość #{ form, condiment Items} może wskazywać np. na tablicę obiektów klasy Sel ect I tern: private static Selectltem[] condimentltems = { new Selectltemd, "Ser"), new Selectltem(2. "Marynata"), new SelectltemO, "Musztarda"), new Selectltem(4, "Sałata"), new Selectltem(5, "Cebula")

}.

public Selectltem[] getCondimentItems() { return condimentltems:

Atrybutowi value znacznika f: sel ect Items musimy przypisać wyrażenie reprezentujące wartość, które wskazuje na jedną z następujących konstrukcji: ■ pojedynczy obiekt klasy Sel ect Item; ■ kolekcję obiektów klasy Sel ect Item; ■ tablicę obiektów klasy Sel ectltem; ■ mapę, której elementy reprezentują etykiety i wartości obiektów klasy Sel ectltem. | Programistom, którzy nie potrafią zapam iętać możliwych konstrukcji przypisywanych I atrybutowi value znacznika f: sel ect Items, być może pomoże następujący skrót: PKTM , czyli Pojedynczy elem ent selekcji, Kolekcja elem entów selekcji, Tablica elementów selekcji oraz M a p a .

P S I Stosow anie pojedynczego znacznika f :selectltem$ zwykle je s t lepszym rozwią■ ■ ¡a zaniem niż korzystanie z wielu znaczników f: sel ectltem. Jeśli użyjemy znacznika f: sel ectltem, zm iana liczby elem entów będzie się wiązała z koniecznością zmodyfiko­ wania zarówno kodu Javy, ja k i kodu stron JSF. W przypadku znacznika f : sel ect I tenis ta k a zm iana spowoduje, że będziem y m usieli dostosować tylko kod Javy, Jeśli przypiszemy temu atrybutowi mapę, implementacja JS F utworzy po jednym obiekcie klasy Sel ectltem dla każdego elementu (pary) w ramach tej mapy. Klucze tych par zostaną wykorzystane w roli etykiet elementów, natomiast wartości zostaną użyte w roli wartości elementów. Poniżej przedstawiono przykład definicji składników potrawy właśnie w formie struktury mapy:

Rozdział 4. ■ Znaczniki standardowe JSF

141

private Map condimentItem = null: public Map getCondimentItems0 { i f (condi nient Item == null) { condi nient Item = new LinkedHashMap() condimentltem.putC'Ser", 1): / / etykieta, wartość condinientItem.put("Marynata", 2) : condimentltem.put( "Musztarda", 3), condimentltem.putCSałata", 4), condimentItem.put( "Cebula", 5);

i

return condimentltem;

Warto pamiętać, że jeśli zdecydujemy się na wykorzystanie struktury mapy, nie będziemy mogli definiować opisu ani stanu poszczególnych elementów. Stosując obiekt klasy Sel ectltem, z natury rzeczy wiążemy nasz kod z interfejsem JS F A PI. Tylko użycie struktury typu Map eliminuje tego rodzaju związki, co czyni z tego rozwiązania atrakcyjną alternatywę względem pozostałych dostępnych konstrukcji. Przed podjęciem osta­ tecznej decyzji warto jednak mieć na uwadze następujące aspekty: 1.

Większość programistów preferuje stosowanie struktur typu LinkedHashMap (zamiast struktur TreeMap czy HashMap). Klasa LinkedHashMap daje nam kontrolę nad porządkiem elementów, ponieważ kolejność ich przeszukiwania odpowiada kolejności ich dodawania do tej struktury. Gdybyśmy użyli struktury typu TreeMap, etykiety prezentowane użytkownikowi (reprezentowane przez klucze tej mapy) zostałyby posortowane w kolejności alfabetycznej. Takie zachowanie nie zawsze jest zgodne z naszymi oczekiwaniami. Nie chcielibyśmy na przykład, aby lista dni tygodnia obejmowała elementy w następującej kolejności: czwartek, niedziela, piątek, poniedziałek, sobota, środa, wtorek. Co ciekawe, gdybyśmy użyli struktury typu HashMap, elementy zostałyby uporządkowane w sposób zupełnie przypadkowy.

2. Klucze mapy są przekształcane w etykiety elementów, natomiast wartości są wykorzystywane w roli wartości elementów. Kiedy użytkownik zaznacza jakiś element, komponent wspomagający otrzymuje odpowiednią wartość (zamiast klucza). Na przykład w przypadku kodu przedstawionego powyżej przekazanie do komponentu wspomagającego wartości 5 będzie się wiązało z koniecznością iteracyjnego przeszukania elementów celem odnalezienia pasującego klucza ("Cebul a"). Ponieważ wspomniana wartość jest z perspektywy naszej aplikacji łatwiejsza w interpretacji niż etykieta, opisany mechanizm nie stanowi większego problemu (jednak musimy o nim pamiętać).

Crupy elementów Elementy menu i list można grupować (zobacz rysunek na następnej stronie). Poniżej przedstawiono znaczniki JS F definiujące tę listę:

142

Rozdział 4. ■ Znaczniki standardowe JSF

JavaServer Faces new Selectltem!"Kawa"), new Selectltem!"Herbata"),

Kanapki Poczwórna Pojedyncza Wegetariańska

};

private new new new new new

Napoje Coca-Cola Pepsi W oda Kawa Herbato

Dodatki ser marynato musztardo. sałata cebula

Selectltem[] condimentltems = { Selectltem!"ser"), Selectltem!"marynata"), Selectltem!"musztarda"), Selectltem!"sałata"), Selectltem!"cebula"),

}; Egzemplarze klasy SelectltemGroup dekodowane są do elementów optgroup języka H TM L. Powyższy kod wygeneruje następujący fragment kodu HTML-a:

Właściwość menultems reprezentuje tablicę obiektów klasy Selectltem: public Selectltem[] getMenuItems() { return menultems, }

Tablicę menultems zdefiniowano w następujący sposób:

Poczwórna Pojedyncza Wegetariańska

private static Selectltern[] menultems = { burgers, beverages, condiments }:

Zmienne burgers, beverages i condiments reprezentują obiekty klasy SelectlteniGroup skon­ struowane za pomocą następujących wyrażeń: private SelectltemGroup burgers = new SelectItemGroup( "Kanapki ", "kanapki w menu", fal se, burger Items ) :

//wartość //opis //stan //elementy selekcji

private SelectltemGroup beverages = new SelectltemGroup!"Napoje", //wartość "napoje w menu", //opis fal se, //stan beveragel tems ). //elementy selekcji

Coca-cola Pepsi Woda Kawa Herbata ser marynata musztarda sałata cebula

private Select 1lemGroup condiments = new S e le c t 1temGroup( "Dodatk i ". //wartość "przyprawy w menu". f a 1s e . COnd i men 11tems ).

//opis //stan // elementy selekcji

Warto zwrócić uwagę na wykorzystanie obiektów klasy SelectltemGroup w procesie wy­ pełniania tablicy egzemplarzy klasy Selectltem. Takie rozwiązanie jest możliwe, ponieważ klasa SelectltemGroup rozszerza klasę Selectltem. Same grupy są tworzone i inicjalizowane w następujący sposób: private Selectltem[] burgerltems = { new Select 1tem("Poczwórna"). new Select1tem("Pojedyncza" ). new Select 1tem("wegetamańska" ).

f

143

private SelectItem[] beverageLtems = { new Select 1tem("Coca-cola"). new Selectltem!"Pepsi"), new Selectltem!"Woda"),

K M Specyfikacja HTM L 4 .0 1 nie przewiduje m ożliwości zagnieżdżania elem en tó w M i l optgroup, co byłoby korzystne, gdybyśmy chcieli konstruować m enu kaskadow e. Co więcej, w spom niana specyfikacja nie wspom ina o planach wprowadzenia tej moż­ liwości w przyszłych wersjach HTML-a.

javax.faces.model.SelectltemGroup ■ SelectItemGroup(Stnng label) Tworzy grupę z etykietą, ale bez elementów selekcji. ■ SelectrtemiGroup(String label. Stnng description. boolean disabled. SelectltemLJ items) Tworzy grupę na podstawie otrzymanej etykiety, opisu (ignorowanego w implementacji referencyjnej JavaServer Faces), wartości logicznej określającej

144

Rozdział 4. ■ Znaczniki standardowe JSF

JavaServer Faces stan wszystkich elementów oraz tablicy elementów selekcji (użytych do wypełnienia tej grupy). ■ setSelectItems( SelectItem [] i tems) Wskazuje dla danej grupy tablicę obiektów klasy Sel ectltem.

Wiązanie atrybutu value Niezależnie od tego, czy stosujemy pola wyboru, menu czy listy, najprawdopodobniej bę­ dziemy chcieli mieć dostęp do informacji o zaznaczonych elementach. Do tego celu służą znaczniki selectOne i selectMany, których atrybut value reprezentuje właśnie zaznaczony element lub elementy. Możemy na przykład określić zaznaczony element za pośrednictwem atrybutu value znacznika h:selectOneRadio:

Wyrażenie reprezentujące wartość # {form, beverage} odwołuje się do właściwości beverage komponentu JavaBean nazwanego form. Właściwość beverage zaimplementowano w nastę­ pujący sposób: private Integer beverage, public Integer getBeverage!) { return beverage;

}

public void setBeverage!Integer newValue) { beverage = newValue;

} Łatwo zauważyć, że właściwość beverage jest obiektem typu Integer. Oznacza to, że dla przycisków opcji musimy zdefiniować wartości całkowitoliczbowe. Same przyciski definiu­ jemy za pomocą znacznika f :selectltems z atrybutem value wskazującym na właściwość beverageltems komponentu form: private static Selectltem[] beverageltems = { new Sel ectltem! 1, "Woda"), / / wartość, etykieta new Selectltem(2, "Coca-cola"), new Selectltem(3, "Sok pomarańczowy")

}; public Selectltemf] getBeverageltems!) { return beverage;

} W powyższym przykładzie napoje są reprezentowane przez wartości typu Integer. Mogliby­ śmy wybrać dowolny inny typ, jednak pod warunkiem zachowania zgodności typów wła­ ściwości reprezentujących elementy i zaznaczony element. W tym przypadku lepszym roz­ wiązaniem byłoby użycie typu wyliczeniowego (przykład takiego podejścia przedstawiono na listingu 4.14). Za pośrednictwem znacznika selectMany możemy śledzić zaznaczenie wielokrotne. Znacz­ nik selectMany obejmuje atrybut value, który umożliwia nam określanie jednego lub wielu zaznaczonych elementów. Wartość tego atrybutu musi mieć postać tablicy lub listy obiektów typu umożliwiającego niezbędną konwersję.

145

Przyjrzyjmy się teraz różnym typom danych. Aby umożliwić użytkownikowi wybór wielu dodatków, w kodzie odpowiedniej strony JS F użyjemy znacznika h : sel ectManyLi stbox:

Poniżej przedstawiono definicje właściwości condinientI tenis i condiments: private static Selectltem[] condimentItems = { new Selectltem!1, "Ser"), new Selectltem(2, "Marynata"), new Selectltem(3, "Musztarda"), new Selectltem(4, "Sałata"), new Selectltem(5, "Cebula"),

};

public Selectltem[] getCondimentItems!) { return condimentltems;

} private Integer[] condiments; public void setCondiments(Integer[] newValue) { condiments = newValue;

}

public Integer[] getCondiments() { return condiments;

} Zamiast tablicy obiektów typu Integer właściwość condiments mogłaby równie dobrze reprezentować tablicę typu prostego i nt: private i nt[] condiments; public void setCondiments(int[] newValue) { condiments = newValue:

}

public in t[] getCondiments() { return condiments;

} Gdybyśmy atrybutom wartości elementów przypisali łańcuchy, moglibyśmy wykorzystać do reprezentowania zaznaczonych elementów właściwości w formie tablicy lub listy łańcuchów: private static Selectltem[] condimentltems = { new Selectltem!"ser", "Ser"), new Selectltem!"marynata", "Marynata"), new Selectltem!"musztarda", "Musztarda"), new Selectltem!"sałata", "Sałata"), new Selectltem!"cebula", "Cebula"),

};

public Selectltem[] getCondimentltems() { return condimentltems;

}

private String[] condiments; public void setCondiments(String[] newValue) { condiments = newValue;

}

public String[] getCondiments() { return condiments;

146

JavaServer Faces

Rozdział 4. ■ Znaczniki standardowe JSF

W powyższym przykładzie właściwość condiments ma postać tablicy łańcuchów. Okazuje się, że zamiast tej tablicy można by użyć kolekcji: private static Collection condiments, static { condiments = new ArrayListList(); condiments.add(new Selectltem!"ser", "Ser")), condiments.add(new Selectltem!"marynata", "Marynata")); condiments.add(new Selectltem!"musztarda", "Musztarda")); condiments.add(new Selectltem!"sałata", "Sałata")); condiments.add(new Selectltem!"cebula", "Cebula"));

Listę umożliwiającą wybór roku urodzenia zaimplementowano z wykorzystaniem znacznika h : sel ectOneLi stbox; pola wyboru języka zaimplementowano za pomocą znacznika h : sel ect ^ManyCheckbox; wybór poziomu edukacji jest możliwy dzięki użyciu znacznika h: sel ect ^OneRadio. Kiedy użytkownik wysyła wypełniony formularz, mechanizm nawigacji JavaServer Faces wyświetla stronę prezentującą wpisane dane. Strukturę katalogów aplikacji z rysunku 4.7 przedstawiono na rysunku 4.8. Kod stron JS F , komponentu Regi sterForm, pliku konfiguracyjnego oraz pliku pakietu komunikatów przed­ stawiono na listingach od 4.12 do 4.16.

}

public List getCondiments() { return condiments; }

¡ 3 select.war

Rysunek 4.8.

Podsumowanie: pola wyboru, przyciski opcji, menu i listy Nasze rozważania w podrozdziale poświęconym znacznikom selekcji zakończymy analizą przykładu ilustrującego praktyczne zastosowania niemal wszystkich opisanych elementów. Nasza przykładowa aplikacja (patrz rysunek 4.7) implementuje formularz, w którym użytkow­ nik powinien wpisać swoje dane osobowe. Do określenia, czy użytkownik chce otrzymy­ wać wiadomości poczty elektronicznej, wykorzystano znacznik h;selectBooleanCheckbox. Znacznik h;selectManyMenu umożliwia użytkownikowi wybór dni tygodnia, w którym oczekuje kontaktu.

9 C3

Struktura katalogów przykładowej aplikacji gromadzącej dane osobowe

Q

lĘfy Poia wyboru, .przyciski opqj '

Edycja

W.dok

Historia

Zakładki

■ t C3 com I

?

m.

!

I I

|

f-

.

é i:

I

Prosimy podać następujące informacje Dawkujemy za wysłanie ds

Imię i nazwisko: Proszę o kontakt

Możliwość kontaktu

i

!Jan Kowalski

;

Wybrane dni kontaktu: 2 ,'. Rok urodzenia

19

Języki

Pl

Wiorst Środa Czosnek Piątek

Kolory:

C*

Sobota

9

com E 3 corejsf ‘ Q messages properties

Listing 4.12. Kod strony select/web/indexjsp

1901 ( 190? >903 190-a

13 Czerwony §3 Niebieski D

Rółty

Angielski Włoski Hiszpański Rosyjski €• Średnie Jakie masz wykształcenie?

C3

Q showlnformatton jsp

1

Wybierz język, którym się posługujesz.

£ ¡3 bm

r Q index jsp

Wykształcenie:

Wybierz swoje ulubione kolory:

Q faces-config xml Q web xml

j Q index ht ml

m' ’ Nieazieia

Wybierz rok urodzenia.

Q messages properties

I Q styles css

truj

Wybierz dzień (dni) tygodnia, w którym mamy się z Tobą skontaktować

; Q RegisterForm class

) I D "b

9

ië

C3 co rejsf Q RegisterFormJ Education class

,

Pomoc

] ntrp.1 .-iio^air>oit:bU8u^ciecvmde^’

M A N IF E S T MF

9 ET3 Classes

[ ca ; iii j g

jp Pata wybaw, przyciski opcji, menu »foty -

m e t a - in f

9 UWEB-iMF

i

Plik

%

147

Licencjat Wyższe

i Ę $ Doktorat . ' ^ M a n ę osobową j

Rysunek 4.7. Przykład użycia w praktyce pól wyboru, przycisków opcji, menu i list

D

Zielony

0

Pomarańczowy



2 3

tagl ib u n -"http://java sun com/jsf/core" pref ix=" f ’’ %> <%@ taglib u n ="http://java.sun.com/jsf/html" pref îx-'V %>

4



5



6



7

8 9 10 11

12 13 14 15 16



17

82 83.

18 19. 20	148 Rozdział 4. ■ Znaczniki standardowe JSF JavaServer Faces 21. 22. 23. 24. 25. 26. 27. 28 29. 30. 31. 32. 33. 34. 35. 36. 37 38. 39. 40. 41. 42. 43. 44. 45. 46 47 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77.
	78. layout="pageDirection"> 79. 80 81

84 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4 5. 6 7. 9 10. 11 12. 15
16 17 18 19 20 21 22 25 26 27 28 29 30 31 32 33 34. 35. 38. 39. 40. 41. 42. 43. 44.
45 46. 47. 48. 49. 50.

Listing 4.18. Zawartość pliku messages,/src/java/com/corejsf/messages.properties 1. windowTitle=Przykład użycia znaczników h:messages i h:message 2. greeting=Proszp wypełnić poniższe pola 3. namePrompt=Imię:

159

4. agePrompt=Wiek• 5. submitPrompt=Wyślij formularz

Listing 4.19. Arkusz stylów messages/web/styles.css 1. .errors { 2. font-style: ita lic ; 3. color: red;

4• } 5. .emphasis { 6. font-size: 1.3em;

7- }

P H I Znacznik h:messages domyślnie wyświetla podsum owania kom unikatów , ale nie H a l wyświetla ich szczegółów. Z drugiej strony, znacznik h:message domyślnie wyświetla szczegóły, ale nie wyświetla podsumowań. Jeśli stosujemy znaczniki h:messages i h:me$$age łącznie (jak w powyższym przykładzie), podsum owania są wyświetlane w górnej części strony, natom iast szczegóły są prezentowane obok odpowiednich pól wejściowych.

Panele W dotychczasowych przykładach prezentowanych w tym rozdziale konsekwentnie wykorzy­ stywaliśmy tabele języka H TM L do zarządzania układem komunikatów i pól wejściowych. Ręczne tworzenie znaczników tabel jest jednak dość nużące i może prowadzić do rozmaitych błędów. Warto więc przeanalizować znacznik h•panelGnd, który generuje element taD1e HTML-a i który łagodzi skutki wspomnianych niedogodności. Liczbę kolumn tabeli możemy określić za pośrednictwem atrybutu columns:

Atrybut col umns nie jest wymagany — jeśli go nie zdefiniujemy, zostanie użyta domyślna liczba kolumn, czyli 1. Znacznik h: panelGrid umieszcza komponenty w kolumnach od lewej do prawej strony i od góry do dołu. Jeśli na przykład zdefiniujemy siatkę panelu obejmującą trzy kolumny i dziewięć komponentów, formularz zostanie podzielony na trzy wiersze, z któ­ rych każdy będzie obejmował trzy kolumny. Jeśli podzielimy siatkę na trzy kolumny i umie­ ścimy na niej dziesięć komponentów, siatka będzie obejmowała cztery wiersze, a ostatni wiersz będzie zawierał (dziesiąty) komponent tylko w pierwszej kolumnie. Atrybuty znacznika h; panel Gr i d wymieniono i krótko opisano w tabeli 4.23. Dla różnych obszarów tabeli (nagłówka, stopki, wierszy i kolumn) możemy stosować odrębne klasy C S S . Za pośrednictwem atrybutów col uninCl asses i rowClasses możemy definiować listy klas C S S stosowanych odpowiednio dla kolumn i wierszy. Jeśli wspomniane listy obejmują nazwy klas w liczbie mniejszej, niż wynosi liczba kolumn lub wierszy, sekwencja klas C S S będzie wykorzystywana wielokrotnie. Oznacza to, że możemy wskazać klasy dla wierszy oraz kolumn parzystych i nieparzystych, stosując następujące konstrukcje: rowClasses= ^"evenRows, oddRows" i columnClasses="evenColumns, oddColumns".

160

JavaServen Faces

Rozdział 4. ■ Znaczniki standardowe JSF

Tabela 4.23. Atrybuty znacznika h:panelGrid Atrybuty

opis

bgcolor

Określa kolor tła w danej tabeli.

border

Określa szerokość obramowania tabeli.

cellpadding

Określa szerokość wypełniania wokół komórek tabeli.

cel 1spacing

Określa szerokość przestrzeni dzielącej komórki tabeli.

columnClasses

Definiuje listę klas CSS dla kolumn (oddzielonych przecinkami).

col unins

Określa liczbę kolumn tabeli.

footerClass

Wskazuje klasę CSS dla stopki danej tabeli.

frame



Grupowanie pola tekstowego i komunikatu o błędzie powoduje umieszczenie obu tych kon­ strukcji w tej samej komórce tabeli. Bez takiego grupowania komunikat o błędzie znalazłby się w odrębnej komórce. W razie braku takiego komunikatu odpowiedni komponent nie będzie prezentował żadnych danych wyjściowych, ale zajmie swoją komórkę (w tej sytuacji nasza siatka będzie zawierała komórkę pustą).

Specyfikacja krawędzi ramki wyświetlanej wokół danej tabeli; prawidłowe wartości: none, above, below, hsides, vsides, Ihs, rhs,

W ramach znacznika h: panel Group możemy stosować zaledwie kilka atrybutów. Atrybuty tego znacznika wymieniono w tabeli 4.24.

box, border. headerClass rowClasses rules summary

Wskazuje klasę CSS dla nagłówka tabeli.

Tabela 4.24. Atrybuty znacznika h:panelGroup

Definiuje listę klas CSS dla wierszy (oddzielonych przecinkami).

Atrybuty

Opis

Specyfikacja linii rysowanych pomiędzy komórkami; prawidłowe wartości: groups, rows, columns, all.

layout (JSF 1.2)

Jeśli przypiszemy temu atrybutowi wartość "bl ock", do musi zostać wyrenderowany element di v języka HTML. W przeciwnym razie zostanie wyrenderowany element span.

Podsumowanie celu konstruowania danej tabeli i jej struktury napisane z myślą o przeglądarkach renderujących stronę w sposób inny niż wizualnie (np.: mówiony lub Braille’m).

binding, id, rendered, styleClass

Atrybuty podstawowe29.

style

HTML 4.030.

captionClass (JSF 1.2), captionStyle (JSF 1.2)

Klasa lub styl CSS podpisu; opcjonalny podpis panelu możemy zdefiniować za pośrednictwem facety nazwanej "caption".

binding, id, rendered, styleClass, value

Atrybuty podstawowe26.

dir, lang, style, title , width

HTML 4.027.

oncl ick, ondblcl ick, orikeydown, onkeypress, onkeyup, onmousedown, orimousemove, onmouseout, onmouseover, onmouseup

Zdarzenia języka DHTML28.

Na rysunku 4.11 przedstawiono prosty przykład użycia znaczników h:panel Gri d i h: panel Group. Prezentowana aplikacja obejmuje formularz, za pośrednictwem którego użytkownik może podać swoje imię i wiek. Za pomocą atrybutu required znacznika h:inputText dodaliśmy do pola imienia walidator sprawdzający czy pole zostało wypełnione. Wykorzystaliśmy też znacznik h: message do wyświetlania stosownych komunikatów o błędach w razie naruszenia istniejących ograniczeń. Dla pola tekstowego Wiek nie zdefiniowaliśmy żadnych ograniczeń. Łatwo zauważyć, że wspomniane ograniczenia wymagają podziału pierwszego wiersza na trzy kolumny — po jednej dla etykiety, właściwego pola oraz komunikatu o błędzie. Drugi wiersz podzielono tylko na dwie kolumny: etykietę Wiek oraz pole tekstowe. Ponieważ znacz­ nik h: panel Grid nie daje możliwości przypisania więcej niż jednej wartości atrybutowi co1umns, można ten brak spójności rozwiązać, umieszczając pole tekstowe Imię i komunikat 0 błędzie w jednej grupie. Oba komponenty będą wówczas traktowane jak jeden komponent, zatem pierwszy wiersz zostanie podzielony na dwie kolumny.

Atrybuty cellpadding, cellspacing, f ranie, rui es i summary mają charakter atrybutów prze­ kazywanych języka H TM L, które mogą być stosowane wyłącznie dla tabel. Więcej informacji na ich temat można znaleźć w specyfikacji standardu H T M L 4.0. Znacznik h: panel Grid często jest stosowany łącznie ze znacznikiem h: panel Group, który tak grupuje dwa lub więcej komponentów, aby były traktowane jak jeden komponent. Możemy na przykład związać pole wejściowe z odpowiednim komunikatem o błędzie:

Strukturę katalogów aplikacji z rysunku 4.11 przedstawiono na rysunku 4.12. Kod strony JS F 1plików pokrewnych przedstawiono na listingach od 4.20 do 4.22.

26 Patrz tabela 4.4. 27 Patrz tabela 4.5. 28 Patrz tabela 4.6.

161

90

Patrz tabela 4.4.

30 Patrz tabela 4.5.

162

JavaServer Faces

Rysunek 4.11.

ty

Praktyczny przykład użycia znaczników h:panelGrid i h:panelGroup

Rozdział 4. t usa- ! fgł ! S

Przykład użycia znaczników hipaneiGrid i h:paneK3roup - Mozifia Frrefox

Plik

Edycja

Widok

■# ’ * *

Historia

Zakładki

Narzędzia

.. o-

Pomoc

<ł* ¿S

o

M-

i : ,

..

ty

,

Przykład uźycta znaczników hipaneiGrkt i

Plik

Edycja

Wtdok

Historia

* üjl» " I p f

Zakładki

!

fjaraęctaa

S] i

,vnP-"iocalho>i-.8080/panels/inciexłące- j

ifWysifj torm,t»łjB«7!

r


taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <1ink href="styles.css" rel="stylesheet" type="text/css"/>

italic.

6 }

|

* Q indexJ5p_________________

2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.

1 body { 2 background #eee.

10 11 12

evenRows { background

PowderBlue.

oddRows { background MediumTurquoise.

}

163

164

JavaServer Faces

5 Tabele danych Klasyczne aplikacje internetowe niemal na każdym kroku wykorzystują dane stabelaryzowane. Tabele języka H T M L były niegdyś stosowane także w roli menedżerów układu na stronach aplikacji internetowych. Mimo że zadanie to można obecnie z powodzeniem realizować za pomocą arkuszy stylów CSS, wciąż nie ma alternatywy dla tabel wykorzystywanych do pre­ zentowania danych stabelaryzowanych. W niniejszym rozdziale skoncentrujemy się na znaczniku h:dataTable, czyli wygodnym, ale dość ograniczonym komponencie umożliwiającym nam operowanie na danych stabelary­ zowanych.

P | j Znacznik h :d a ta T a b le reprezentuje w istocie parę kom ponentu i m echanizm u H mI odpowiedzialnego za wizualizację. M ożem y więc bez trudu wyświetlać komponenty JSF w komórkach tabel, dodawać do tabel nagłówki i stopki, a także zarządzać wyglądem i sposobem obsługi tych tabel za pośrednictwem klas CSS. Okazuje się jednak, że znacz­ nik h ;d a ta T a b le nie oferuje zaawansowanych funkcji, których m ożna by oczekiwać od tego rodzaju kom ponentów. Gdybyśmy na przykład chcieli posortować zawartość kolumn tabeli, m usielibyśm y sam i opracować odpowiedni kod. W ięcej informacji ną ten te m a t można znaleźć w punkcie „Sortowanie i filtrow anie” w dalszej części tego rozdziału.

Znacznik tabeli danych— h:dataTable Znacznik h: dataTabl e iteracyjnie przeszukuje zdefiniowane przez nas dane celem utworzenia tabeli języka H TM L. Przykład użycia tego znacznika przedstawiono poniżej: < % — komponenty w lewej kolumnie

—%>



166

JavaServer Faces

Rozdział 5. ■ Tabele danych

<%—komponenn’ w kolejnej kolumnie —%>

Rysunek 5.1. Przykład prostej tabeli

Przykład prostej tabeli - Mozilia Firefox £tik

Edycja

Widok

Historia

Zakładki

Naraęctzia

i, ca j EO i

S3

Pomoc-

0

167

I

Tablica nazwisk

<% — w razie potrzeby

możemy dodawać kolejne kolumny —%>



Dopierała,

Wojciech

K owalska.

Anna

Reszczyński Maimsz

Atrybut value reprezentuje dane będące przedmiotem iteracyjnego przeszukiwania przez znacznik h; da ta Table. Możemy temu atrybutowi przypisywać następujące konstrukcje:

Winczorek

Zakończono

■ obiekt Javy, ■ tablicę, ■ egzemplarz klasy ja va . uti 1. Li st, ■ egzemplarz klasy java. sql .ResultSet, ■ egzemplarz klasy javax .servlet .js p .js tl .sql .Result, ■ egzemplarz klasy javax. faces .model .DataModel. Znacznik h: dataTabl e iteracyjnie przetwarza każdy z elementów zdefiniowanej w swoim ciele tablicy, listy, zbioru wynikowego itp. Nazwę tego elementu możemy określić za po­ średnictwem atrybutu var znacznika h:dataTable. W powyższym fragmencie kodu każdy element (item) kolekcji (items) jest udostępniany w trakcie iteracyjnego przeszukiwania tej kolekcji. Do wypełniania kolumn bieżącego wiersza wykorzystujemy właściwości bieżącego elementu.

Jan

*

Strukturę katalogów aplikacji z rysunku 5.1 przedstawiono na rysunku 5.2. Na listingu 5.1 pokazano kod jedynej strony JS F tej aplikacji.

Rysunek 5.2. Struktura katalogów aplikacji demonstrującej prostą tabelę

E3 simpie.war f C3 META-INF |

L Q MANIFEST. MF

f |

WEB-INF f - £¡¡3 classes

| |

| j

? •G3 corn £ £¡3 corejsf

j

|

| 0 Name.class

|

j

[- 0 TableData.class

{

f~ Q faces-conflg.xml

[

0 messages, properties

\ L-0web.xml 0 index.html 1 0 index.jsp______________________

Atrybutowi value znacznika h:dataTable możemy przypisać dowolny obiekt Javy, jednak sens takiego rozwiązania jest dyskusyjny. Jeśli przypiszemy temu atrybutowi obiekt skalamy (czyli taki, który nie ma postaci kolekcji), znacznik h:dataTabl e wykona tylko jedną iterację celem udostępnienia wspomnianego obiektu w ciele tego znacznika. W ciele znacznika h: dataTabl e możemy umieszczać wyłącznie znaczniki h: col umn; znacznik h:dataTable ignoruje wszystkie inne znaczniki komponentów. Każda kolumna może obej­ mować dowolną liczbę komponentów; tabela może też zawierać opcjonalne komponenty nagłówka i stopki. Znacznik h:dataTable wiąże komponent UIData z mechanizmem wizualizacji Table. Taka kombinacja umożliwia efektywne generowanie tabel z uwzględnieniem stylów CSS, dostępu do bazy danych, modeli tabel niestandardowych itd. Nasze rozważania poświęcone znaczni­ kowi h: dataTabl e rozpoczniemy od analizy prostej tabeli.

Prosta tabela Na rysunku 5.1 przedstawiono przykładową tabelę imion i nazwisk.

Listing 5.1. Kod strony simple/web/index.jsp 1. 2. taglib uri="http://java.sun.com/jsf/core" prefix: 3. <%$ taglib uri="http://java.sun.com/jsf/html" prefix^ 4. 5. 6. 9. 10. 11. 12. 13.

14. 15. 17. 18. 19. 20. 21. 22. 23. 24. 25.

168

Rozdział 5. ■ Tabele danych

JavaServer Faces 26 27. 28.

W kodzie przedstawionym na listingu 5.1 wykorzystano znacznik h:dataTable do przeszu­ kiwania tablicy imion i nazwisk. Nazwisko wraz z przecinkiem jest umieszczane w lewej kolumnie, natomiast imię jest umieszczane w kolumnie prawej. Wykorzystana w tym przykładzie tablica nazwisk i imion jest tworzona przez komponent JavaBean zarządzany przez framework JSF. Wspomniany komponent jest egzemplarzem klasy com.corejsf .TableData (patrz listing 5.3). Na listingu 5.2 przedstawiono kod klasy Name. Plik konfiguracyjny i pakiet komunikatów przedstawiono odpowiednio na listingach 5.4 i 5.5.

Listing 5.2. Kod komponentu

5. 6. 7. 8. 9. 10. 11. 12. 13. 14 15. 16. 17. 18 19.

169

http://Java.sun.com/xml/ns/javaee/web-facesconfi g_l_2.xsd" version="l,2"> com.corejsf.messages msgs tableData com.corejsf.TableData sessi on

simple/src/ja

1. package com.corejsf: 0-. L 3. public class Name { private String firs t: 4. private String last; 5. a 0 public Name(String first. String last) { 7 th is .firs t = first, 8. this.last = last: 9. 10. } 11. public void setFirst(String newValue) { firs t = newValue; } 12. public String getFirstO { return firs t, } 13. 14. public void setLast(String newValue) { last = newValue; } 15. public String getLastO { return last; } 16. 17. }

Listing 5.5. Zawartość pliku simple/src/java/com/corejsf/messages.properties 1. windowTitle=Przyklad prostej tabeli 2. pageTitle=Tablica nazwisk:

Tabela widoczna na rysunku 5.1 została celowo zubożona. W dalszej części tego rozdziału omówimy metody doskonalenia wyglądu i sposobu obsługi tabel (między innymi przez wprowadzanie stylów C SS i nagłówków kolumn). Najpierw jednak skoncentrujemy się na przeglądzie atrybutów znacznika h: dataTabl e. i | M | Dane w tabeli reprezentowanej przez znacznik h: dataTabl e są porządkowane według m M wierszy — na przykład nazwiska z listingu 5 .3 odpowiadają wierszom tabeli i w żaden sposób nie określają, co m a być składow ane w poszczególnych kolum nach (za okre­ ślanie zaw artości kolumn odpowiada autor strony). Taki m odel nie zaw sze odpowiada oczekiw aniom program istów przyzwyczajonych na przykład do pracy z biblioteką Swing, gdzie istnieje możliwość zarządzania wierszam i i kolum nam i.

Listing 5.3. Kod komponentu simple/src/java/com/corejsf/TableData.java 1.

package com.corejsf;

9 L ..

3. public class TableData { private static final Name[] names = new Name[] { 4. new Name("Wojciech", "Dopierała"), 5. new Name("Anna", "Kowalska"), 6. new Name("Mariusz", "Reszczyński"), 7. new NameC'Jan", "Winczorek") 8. Q y . 1■ 10. public Name[] getNamesO { return names;} 11. 12. }

Listing 5.4. Plik konfiguracyjny simple/web/WEB-INF/faces-config.xm\ 1.. 2..
Rysunek 5.3.

Lista oddzielonych przecinkami klas CSS dla wierszy.

rows

Liczba wierszy wyświetlanych w danej tabeli (począwszy od wiersza reprezentowanego przez atrybut f i rst); jeśli atrybutowi rows przypiszemy wartość 0, zostaną wyświetlone wszystkie wiersze tabeli.

rules

Specyfikacja linii rysowanych pomiędzy komórkami; prawidłowe wartości: none, groups, rows, CO 1umns,all.

summary

Podsumowanie celu konstruowania danej tabeli i jej struktury napisane z myślą o elementach innych niż wizualne.

var

Nazwa zmiennej utworzonej przez tę tabelę danych i reprezentującej bieżący element przetworzonej struktury danych.

binding, id, rendered, styleClass, value

Atrybuty podstawowe.

lang, style, title , width

Atrybuty języka HTML 4.0.

oncli ck, ondblcli ck, onkeydown, onkeypress, orikeyup, onmousedown, onmousemove, onmouseout, onmouseover, orimouseup

Zdarzenia języka DHTML.

-f a t « * »

Edycja komórek tabeli - Mozitta Firefox

Efekt zastosowania nagłówków i stopek kolumn

Plik

Edycja

Widok

Historia

Zakładki

Narzędzia

Nazwisko

Lmie

picidła

W oinech

I' favaM a

Anna

Wmczritek Jaii

Jak widać, kolumny tabeli z rysunku 5.3 obejmują nie tylko nagłówki, ale też stopki opisujące typ danych odpowiednich kolumn (w tym przypadku są to wartości [a lfa ] właściwe dla danych alfanumerycznych). Nagłówki i stopki kolumn definiujemy za pomocą odpowiednich facet zgodnie z poniższą konwencją:



<%—w tym miejscu należy dodać komponenty nagłówka —%>

<%—w tym miejscu należy dodać komponenty kolumny —%>

<%—w tym miejscu należy dodać komponenty stopki —%>

Atrybuty znacznika h: col unnn wymieniono i krótko opisano w tabeli 5.2.

O

EcszLZvnski Mamisz



Atrybuty znacznika h:column

Pomoc

f i - V -'i? • s f i

Klasa CSS dla nagłówka tabeli.

rowClasses

171



172

JavaServer Faces Znacznik h: dataTabl e umieszcza komponenty wskazane w facetach nagłówka i stopki od­ powiednio w nagłówku i stopce tabeli HTML-a. Warto zwrócić uwagę na sposób wykorzy­ stania atrybutów headerClass i footerClass znacznika h; col urnn do określenia stylów CSS odpowiednio dla nagłówków i stopek kolumn. Wymienione atrybuty zaimplementowano dopiero w wersji JS F 1.2. W standardzie JavaServer Faces 1.2 dodatkowo rozbudowano znacznik h:dataTabl e o opisy tabel. Facetę capti on możemy dodać do znacznika h; dataTabl e w następujący sposób: Tablica imion i nazwisk:

Jeśli dodamy tę facetę do tabeli przedstawionej na rysunku 5.3, strona naszej aplikacji będzie podobna do tej, którą przedstawiono na rysunku 5.4.

Rysunek 5.4. Przykład opisu tabeli

Styl lub klasę CSS dla opisu tabeli możemy definiować odpowiednio za pośrednictwem facet captionStyle i captionClass: Tablica imion i nazwisk:

W powyższym fragmencie kodu umieściliśmy w facecie capti on zwykły tekst, jednak — tak jak w przypadku pozostałych facet — równie dobrze moglibyśmy zastąpić ten tekst kom­ ponentem JSF . Kompletny kod strony z rysunku 5.4 przedstawiono na listingu 5.6. Pakiet komunikatów tej aplikacji przedstawiono na listingu 5.7. Struktura katalogów pozostaje taka sama jak w przy­ padku aplikacji, której strukturę przedstawiono na rysunku 5.2.

Listing 5.6. Kod strony headersAndFooters/web/index.jsp______________________________________________ 1. 2. <%C taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. 5.

Rozdział 5. ■ Tabele danych 6. <1ink href="styles.css" rel="stylesheet" type="text/css'7> 7 10 11. 12. 13. 17. 18. 19. 20. 21. 22. 24. 25. 26. 27. 28. 29. 30. 31. 33. 34. 35. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51.

Listing 5.7. Plik właściwości headersAndFooters/src/java/corejsf/messages.properties 1. 2. 3. 4. 5.

windowTitle=Nagłówki, stopki i podpisy lastnameColumn=Nazwisko firstnameColumn=Imię editColumn=Edytuj alphanumeric=[alfa]

173

174

JavaServer Faces

Rozdział 5. ■ Tabele danych

Warto zwrócić uwagę na fakt użycia dla komponentów wyjściowych atrybutu style celem odpowiedniego sformatowania nagłówków i stopek kolumn. Więcej informacji na temat tego atrybutu można znaleźć w podpunkcie „Atrybuty języka H TM L 4.0*" w rozdziale 4.; szcze­ gółowe omówienie klas stylów C SS i tabel JS F można znaleźć w podpunkcie „Style" w tym samym rozdziale. Aby umieścić w nagłówku lub stopce tabeli wiele kom ponentów, musimy je albo pogrupować w ram ach znacznika h: panel Group, albo um ieścić w kom ponencie kontenera za pośrednictwem znacznika h: panelGri-d lub h:dataTab1e. Jeśli umieścimy wiele komponentów w pojedynczej facecie, zostanie wyświetlony tylko pierwszy z nich.

□

Strukturę katalogów naszej przykładowej aplikacji z rysunku 5.5 przedstawiono na rysunku 5.6. Kod strony JS F , pliku konfiguracyjnego i pakietu komunikatów przedstawiono na listin­ gach od 5.8 do 5.10.

Rysunek 5.6.

components war 9 G3 META-INF

Struktura katalogów prezentowanej aplikacji

Q

MANIFEST MF

9 ( 3 WEB—iN F 9 (¡¡3 classes 9 C3 com 9 [ 3 corejsf Q

messages D ra p e r les

Q laces-config «mi

,

D '/"'eo :dni

9 £3

images Q d 'c e lg if

D dice: gif

Komponenty JSF

i

Efekt umieszczenia komponentów JSF w komórkach tabeli

lĘfc Przykład użycia komponentów JSF w tabeli

Phk

Edycja

Widok ©

Historia o

{S

Zakładki i z e c

_ M° * S eE Z Z i . Z ź i Z ^ . . . . Narzędzia Pomoc

f

1

r r j

1

[T l

:

3

fa Siilfe \

/localhost:8080/components/index.face | ▼ \ §►! jjG
%

L '■

1

j i [T ]

B

m

s

a

a

1

tak ' me

ł

1? 0

^ talt

' me

13 [t]i O tak # me

B

¡ 4 .... ' i

r a

a

4

j

¡5..... Z

E

a

5

Zakończono

m

B

i 4 ¡T]; '5' tak €> me

f f Q

# tak O nie

gif gif

Q

s t y le s

Q

inoe* htrrn

css

D incie k jsp__________

1 2 4

ta i C"- Crnoze

5 6

ra !

7

L.v i: może r„e

8

o>

9

być może rue ok

nie ok tak * być może me ok

|

Komponenty stosowane w tabeli nie różnią się od komponentów umieszczanych poza tabelą — możemy na nich operować w dowolny sposób — możliwa jest więc wizualizacja warun­ kowa za pośrednictwem atrybutu rendered, obsługa zdarzeń itp.

sun com /jsf/cone"

p re fix = "f"

Lag 1 1D u n = "h t ip / / ja v a .su n.com /jsf/htm l"

ta g lib u ri ="iu tp ./ / ja v a

p refix = "h "



outputText value="#{msgs w in d o w T itle }"/>



13. 14 15. 16. 17. 18. 19.

20. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.

%> %>



10.

21

Ponieważ znacznik h:dataTable iteracyjnie przeszukuje dane, na podstawie tabeli przed­ stawionej na rysunku 5.5 zostanie utworzona lista liczb całkowitych. Bieżącą wartość całkowitoliczbową wykorzystujemy w procesie konfigurowania komponentów w kolumnach Liczba , Pola tekstowe, Przyciski oraz Menu.

ch tm l>

11. 12.

tak 1 4

■

3

Lis ty

B1I1I1B

;3..... :j

5

ciice3 gil

Listing 5.8. Kod strony components/web/index jsp

■_ .

Liczba Pola tekstowo Przyciski Pola-wyboru Lacza G ra fik a M en u Przyciski opcji

1

D

| D d":e4 D dices

Do tej pory w kolumnach tabel umieszczaliśmy wyłącznie komponenty wyjściowe, co nie oznacza, że nie możemy w komórkach stosować dowolnych komponentów JSF . Na rysun­ ku 5.5 przedstawiono przykład aplikacji prezentującej tabelę z rozmaitymi komponentami.

Rysunek 5.5.

175





176

Rozdział 5. ■ Tabele danych

JavaServer Faces 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 77. 78. 79. 80. 81. 82. 83. 84. 85.

177

Listing 5.9. Plik konfiguracyjny components/web/WEB-INF/faces-config.xml com.corejsf.messages msgs numberList java.u ti1.ArrayList session <1ist-entries> l 2 3 4 5

Listing 5.10. Plik komunikatów components/src/java/com/corejsft'/messages.properties 1. windowTitle=Przyklad użycia komponentów JSF w tabeli

2. 3. 4. 5. 6. 7. 8. 9. 10. 11.

numberHeader=Liczba textfieldHeader=Pola tekstowe buttonHeader=Przyciski checkboxHeader=Pola wyboru 1inkHeader=Łącza menuHeader=Menu graphicHeader=Grafika radioHeader=Przyciski opcji 1istboxHeader=Listy

Edycja komórek tabeli Edycja tabeli wymaga umieszczenia w jej komórkach komponentów wejściowych. Na ry­ sunku 5.7 przedstawiono stronę aplikacji umożliwiającej edycję zawartości wszystkich ko­ mórek tabeli. Aby edytować pola tekstowe w danym wierszu, należy kliknąć pole wyboru w kolumnie Edytuj. Po zakończeniu edycji użytkownik powinien kliknąć przycisk Zapisz zmiany. Kolejne etapy edycji widać na następujących po sobie zrzutach z rysunku 5.7.

178 *

JavaServerFaces

Rozdział 5. ■ Tabele danych

Edycja komórek tabeli -Mosilla PI*

goycj»

Widok

H.stona

-m7

Zakładki

a

Edytuj Nazwisko

Narzędzia

Pomoc

<-h inputText va lue=' tt{ name last}' rendered='#{name.editable)' size= 10'/>

<>

;

179

^

Linie

Popierała

W»iciech

K owalska

ty



Edycja komórek tabeli -Mozifo Firefcw Widok

Historia

Zakładki

Narzędzia

Pomoc



0

_http://localhost:8080/editi_[» | '.!►] fO J n iocol-:

I ¿api$?¿iruai»

Edytuj



N azwisko

®

Dopie'8'o

J ■

K owalska

l_!

Less zvnski

Wmuzoi eł



■'Oiaeen

ty

Edycja komórek tabeli -Mozilła Firnie».

Plik

Edycja

Widok

Historia

Zakładki

(¡łanzęiizia



“%

'

Poijtoc

♦ * # -® %i {¡¡| f , http:^to>o'L8n«(yed,t:i. Edytuj

Powyższy fragment kodu obejmuje wyłącznie konstrukcje definiujące kolumny pól wyboru i nazwisk. Wartość pola wyboru zależy od tego, czy odpowiednie imię i nazwisko jest edytowalne; jeśli tak, pole wyboru jest zaznaczone. Kolumna nazwiska zawiera w każdym wierszu po dwa komponenty interfejsu użytkownika: h-inputText i h;outputText. Jeśli nazwisko ma być edytowane, jest wyświetlany komponent wejściowy. Z drugiej strony, jeśli edycja nazwiska ma być niemożliwa, we wspomnianej kolumnie jest wyświetlany komponent wyjściowy.

Nazwisko

i^.

■'■■x -pianst ■

r

Eeszczvnsk

K •■'walska

ty

Edycja komórek tabełi - Mo; .Ita c -efos

Wjnczor4

E dytuj

N azwisko

#

-'-"vsoiafst•

■•

Kowalska

U

Reszczvnski

L

Wjnczo,^

linie :n. Kj

ty

Edycja komórek tabeli -Mozilla firefox';

PWc

fcaycją

Wiacie

Historia

■*0®' 4 i# * @ Edytuj Nazwisko

Zakładki

Narzędzia

Pomoc

(j£ ! http://iocaP.-st8n,ftn/.dit-j Lmie

9.7vspiaiiski EcnrvL Kowalska

Kompletny kod strony JS F z rysunku 5.7 przedstawiono na listingu 5.I l. Pakiet komunikatów dla tej aplikacji przedstawiono na listingu 5.12. Układ katalogów analizowanej aplikacji jest identyczny jak w przypadku aplikacji prezentowanej we wcześniejszej części tego rozdziału (patrz rysunek 5.2).

niina

Rrszczvnski Mariusz

LiStiny 5.11. Kod strony editing/web/index.jsp__________________________________________________________

Wmczorek Jan

1 ; ¿SptŁŁ ¿mi&fiy j

2

<°4@

3 4 5 uzono

Rysunek 5.7. Edycja komórek tabeli Komórki tabeli z rysunku 5.7 zawierają komponenty wejściowe, jeśli odpowiednie komórki są wyświetlane w trybie edycji, oraz komponenty wyjściowe, jeśli użytkownik nie zaznaczył właściwych pól wyboru. Sposób implementacji tego rozwiązania przedstawiono poniżej:
—>







6 7. 8. 9 10 11 12 13 14. 15. 16 17. 18. 19. 20. 21. 22. 23. 24. 25 26. 27. 28 29

tag l i t ) tdglib

<1

u n ="htLp./ / j d v d . S u n

u ri= "http

//jdvd

com/jsf/core"

prefix="f"

%>

Sun c o m / j s f / h i m l "

prefix="h"

%>

vi0w>



180

JavaServer Faces 30. 31. 32. 33. 34. 35. 36. 37 38. 39. 40. 41. 42. 43. 44. 45


ĘjĘ; Stosowanie stylów dia kolumn - MoziKa Firefox

Rysunek 5.8. Efekt zastosowania stylów dla kolumn i nagłówków

Plik

Edycja

Widok

4§i

Historia k j|

Zakładki I

Narzędzia

Pomoc

• http://localhost:8080/database-orders/index.f.j^y l ^ ; ^ ^ 0 o o ę [ i e

0 jl| | f

ilNuiuer zamówienia; ¡Data zmnówieniaildentyfikator klienta-

2002^05-24 2002-05-23

.

2002-05-22 ■ 2002-05-20 2002-05-22

i

2002-05-21' -

2002-05-23

\

2002-0^-2 ..

vi e w>

Listing 5.12. Plik właściwości editing/src/java/com/corejsf/messages.properties 1 2 3 4 5 6

Rozdział 5. ■ Tabele danych

windowTitle=Edycja komorek tabeli lastnameColumn=Nazwisko firstnameColumn=Imip ediLColumn=EdytUJ alphanumeric=[alfa] saveChangesButtonText=Zapisz zrrnany

Atrybuty rowCl asses i col umnCl asses znacznika h: dataTabl e wykluczają się wza­ jem nie. Jeśli zdefiniujemy oba atrybuty jednocześnie, atrybut col umnCl asses będzie m iał wyższy priorytet.

Style stosowane dla kolumn Poniższy kod ilustruje sposób, w jaki zastosowano klasy C SS dla tabeli z rysunku 5.8: <11nk nref=’styles css' rel =' stylesreet1 Lype='text/css'/>

Kod samych klas C SS przedstawiono poniżej:

Style

.orders { border- thin solid black;

W ramach znacznika h: dataTabl e możemy stosować atrybuty wskazujące na klasy C SS dla następujących elementów:

}

■ całej tabeli (atrybut styl eCl ass); ■ nagłówków i stopek kolumny (atrybuty headerCl ass i footerCl ass); ■ pojedynczych kolumn (atrybut col umnCl asses); ■ pojedynczych wierszy (atrybut rowCl asses). Na rysunku 5.8 przedstawiono tabelę skonstruowaną z wykorzystaniem atrybutów styl eCl ass, headerClass i col umnClasses.

ordersHeader { text-align: center; font-style: ita lic ; color: Snow; background: Teal,

} .oddColumn { height: 25px; text-align: center; background: MediumTurquoise,

}

.evenColumn { text-align: center, background: PowderBlue;

181

182

Rozdział 5. ■ Tabele danych

JavaS erver Faces Mimo że nasza tabela obejmuje pięć kolumn, zdefiniowaliśmy dla nich tylko dwie klasy CSS. W prezentowanej aplikacji znacznik h:dataTable wielokrotnie wykorzystuje istniejące klasy (począwszy od pierwszej). Definiując klasy tylko dla dwóch pierwszych kolumn, możemy łatwo określić style C SS dla kolumn parzystych i nieparzystych.

Style stosowane dla wierszy

183

Tabele bazy danych Ponieważ bazy danych składują informacje w tabelach, komponent tabel danych JS F wprost idealnie nadaje się do prezentowania danych składowanych w bazie danych. W niniejszym podrozdziale przeanalizujemy sposób wyświetlania wyników zapytania wykonywanego na bazie danych.

Za pośrednictwem atrybutu rowClasses możemy wskazywać klasy C SS dla poszczególnych wierszy (zamiast kolumn). Przykład strony skonstruowanej z wykorzystaniem tego atrybutu przedstawiono na rysunku 5.9. Tabelę danych zaimplementowano w następujący sposób:

Stronę aplikacji JS F prezentującej tabelę bazy danych przedstawiono na rysunku 5.10. Í

Rysunek 5.10. Wyświetlanie tabel bazy danych

Prezentacja tabel bazy W.dok

fi Hutona

Zakładki

Narzędzia

Pomoc

:;;€^

http./7iocalhost;8030/database/inaeA.facaJ j *



Rysunek 5.9.

£§P Stosowanie stylów dla kolumn • Moziüa Firefox

Przykład zastosowania stylów dla wierszy

Plik

Edycja

Widok

Historia

Zakładki

Narzędzia

Pomoc

¡Numer zamówienia ¡Data zamówienia ¡Identyfikator klienta j Cena j

Młynek do kawy

Strona JS F przedstawiona na rysunku 5.10 wykorzystuje znacznik h: da La Table w następu­ jącej formie:

Podobnie jak w przypadku klas stylów przypisywanych kolumnom, także klasy właściwe dla wierszy są wykorzystywane wielokrotnie, jeśli ich liczba jest mniejsza niż liczba wier­ szy. W powyższym fragmencie kodu wykorzystaliśmy tę cechę znacznika mdataTable do zdefiniowania klas C SS dla wierszy parzystych i nieparzystych. ■ fflj Z myślą o większej czytelności stosujemy w naszych klasach stylów CSS angielskie L j i nazwy kolorów, np. PowderBłue i MediumTurąuoise. W prawdziwej aplikacji lepszym rozwiązaniem byłoby stosowanie odpowiednich stałych szesnastkowych, które (w prze­ ciwieństwie do nazw) gwarantują właściwą przenośność.



Komponent zarządzany customer odpowiada za nawiązywanie połączenia z bazą danych i wykonywanie zapytania zwracającego zbiór wszystkich reprezentowanych tam klientów. Wspomniane zapytanie możemy wykonać za pośrednictwem metody CustomerBean.al 1.

184

JavaServer Faces

Rozdział 5. ■ Tabele danych

W przytoczonym powyżej kodzie strony JS F uzyskujemy dostęp do danych w kolumnach, odwołując się do ich nazw — na przykład wyrażenie #{customer. Cust_ID} odwołuje się do kolumny Cust_ID. Strukturę katalogów przykładowej aplikacji przedstawiono na rysunku 5.11. Na listingach od 5.13 do 5.16 przedstawiono kod strony, komponentów i plików konfiguracyjnych.

Rysunek 5.11. Struktura katalogów przykładowej aplikacji prezentującej informacje z bazy danych

¡ 3 d a ta b a s e .w a r f j

META-INF L D MANIFEST.MF WEB-INF

| y - i ¡ 3 c la s se s ¡ j y C2I com ! | f Q c ore js f | |

j

j~ D L~Q

\

C u s t o m e r B e a n .c la s s m e s s a g e s , p ro p e rtie s

j

| D fa ce s- co n fia .xml

|

'‘- Q

w eb . xml

f •£ 2 mise j

L- Q

| D r D [ D

custom ers, sql

styles, css index.htm l in d e x .jsp ___________________________

Listing 5.13. Kod strony database/web/index.jsp 1. 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. <£@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. 5. 6. <1irik href="styles.css" rel="stylesheet" type="text/css"/> 7. 10. 11. 12 13. 16. 1/. 18. 19. 20 21. 22. 23 24. 27. 28. 29. 30. 31

32. 33. 34. 35 36. 37. 38. 39 40 41. 42. 43. 44. 45. 46. 47. 48 49. 50. 51. 52. 53. 54. 55. 56.

Listing 5.14. Kod komponentu database/sre/java/com/corejsf/CustomerBean.java 1 package com.corejsf; 2 3 import java.sql.Connection; 4 import java.sql.ResultSet; 5 import java.sql.SQLException; 6 import java.sql.Statement; 7 import javax.naming.Context; 8 import javax.naming.InitialContext; 9 import javax.naming.NamingException; 10 import javax.servlet.jsp.jstl sql.Result; 11 import javax.servlet.jsp.jstl sql.ResultSupport; 12 import javax.sql.DataSource; 13 14 public class CustomerBean { private Connection conn; 15 16 public void openO throws SQLException, NamingException { 17 i f (conn != null) return; 18 Context ctx = new InitialContext(); 19 DataSource ds = (DataSource) ctx.lookup("java:comp/env/jdbc/mydb"); 20 conn = ds,getConnection(); 21 22

23 24 25 26 27 28 29

public Result getAllO throws SQLException, Nami ngExcepti on { try { openO; Statement stmt = conn.createStatementO; ResultSet result = stmt.executeQuery("SELECT * FROM Customers" return ResultSupport.toResult(result);

185

186

Rozdział 5. ■ Tabele danych

JavaServer Faces 30. 31 32 33. 34. 35. 36 37. 38 39 40. }

} finally { close(), } } public void closeO throws SQLException { i f (conn == null) return; conn.closeO; conn = nul1, }

LiStfng 5.15. Zawartość pliku konfiguracyjnego database/web/WEB-INF/web.xml 1. 2. 7. Faces Servlet 8. 9. javax.faces.webapp.FacesServlet 10. l 11. 12 13. 14. Faces Servlet 15 * faces 16. 17. 18. 19. i ndex.html 20 21. 22. 23. jdbc/mydb 24. javax.sql.DataSource 25. Container 26. 27.

Listing 5.16. Pakiet komunikatów zdefiniowany w pliku database/src/java/com/corejsf/messages.properties 1. 2. 3. 4 5. 6. 7. 8.

pageTitle=Prezentacja tabel bazy danych customerIdHeader=Identyfikator klienta nameHeader=Imię i nazwisko phoneHeader=Numer telefonu addressHeader=Adres cityHeader=Miasto stateHeader=Województwo refreshFromDB=0dczytaj z bazy danych

187

Obiekty wyników biblioteki JSTL kontra zbiory wynikowe Atrybutowi value znacznika h:dataTable można przypisać między innymi egzemplarz kla­ sy javax. serví e t . jsp. js t l .Result lub egzemplarz klasy java. sql .ResultSet (jak w przy­ kładzie przedstawionym w poprzednim podrozdziale). Znacznik h:dataTable opakowuje te obiekty odpowiednio w ramach egzemplarzy klas Resul tDataModel i Resul tSetDataModel. Warto się więc zastanowić, czym się różnią wymienione modele i który model powinniśmy wybrać. Każdy, kto kiedykolwiek wykorzystywał w swoim oprogramowaniu zbiory wynikowe, do­ skonale wie, że mają one postać wysoce zmiennych obiektów wymagających od programi­ sty skutecznych mechanizmów kontrolnych. Klasa Result biblioteki JS T L jest komponentem opakowującym zbiór wynikowy i implementującym niezbędne mechanizmy kontrolne. Oznacza to, że operowanie na danych reprezentowanych za pomocą tej klasy jest prostsze niż w przy­ padku tradycyjnych zbiorów wynikowych. Z drugiej strony, opakowywanie zbiorów wynikowych wiąże się z pewnymi kosztami w y­ nikającymi choćby z konieczności konstruowania obiektów klasy Result, co może prowadzić do istotnego spowolnienia pracy aplikacji. W aplikacji omówionej w podrozdziale „Tabele bazy danych” zdecydowaliśmy się na roz­ wiązanie polegające na zwracaniu przez metodę Custonier Bean .a ll właśnie obiektu klasy Result biblioteki JS T L .

Modele tabel Jeśli do reprezentowania danych w tabeli wykorzystujemy obiekt Javy, tablicę, listę, zbiór wynikowy lub obiekt wyników biblioteki JS T L , znacznik h:dataTable opakowuje te kon­ strukcje w ramach modelu rozszerzającego klasę javax. faces .model. DataModel. Wszystkie wymienione poniżej klasy modeli należą do pakietu javax. faces. model: ■ ArrayDataModel ■ ListDataModel ■ ResultDataModel ■ ResultSetDataModel ■ ScalarDataModel Znacznik h: dataTabl e zawsze wykorzystuje wymienione powyżej modele — nigdy nie uzy­ skuje bezpośredniego dostępu do obiektu (tablicy, listy itd.) wskazanego za pomocą atrybutu value. Okazuje się jednak, że sami możemy uzyskiwać dostęp do tych obiektów za pośred­ nictwem metody DataModel .getWrappedData. Wspomniana metoda jest szczególnie wygodna, jeśli chcemy dodawać i usuwać wiersze tabeli.

188

Rozdział 5. ■ Tabele danych

JavaServerFaces

189

int i=0; for (Name name : currentNames) { i f (Iname.isMarkedForDeletionO) { newNames[ i ++] = name;

Edycja modeli tabel Dodawanie i usuwanie wierszy tabeli jest bardzo proste, ponieważ mamy do dyspozycji dwie metody implementowane przez wszystkie modele danych: getWrappedData( ) i setWrapped ^D ataO . Przeanalizujmy teraz faktyczne działanie tego mechanizmu w aplikacji umożli­ wiającej użytkownikom usuwanie wierszy z tabeli (patrz rysunek 5.12).

} } model.setWrappedData(newNames); return nul 1;

} }

J p Usuwanie wierszy tabel» - MoziiU» firefa*

Rysunek 5.12. Usuwanie wierszy tabeli

j Piik

Edycja

Widok s £i?tow#-; Zakładki

Narzędzia .. P
http://localhost:8080/editi |

6uog!e

Usuwanie wierszy tabełi -Mozilta fi Płtk

Edycja

Widok

Historia

W 'W :

Zakładki

j Plik |$ (J ?

Kowalska I

■/ j

~'}>uv~7. .rek I

Narzędzi*

Pomoc

W W W i. Edycja

w,i[^ *

Widok

* (¿J

Historia

Zakładki

^

o

w

i

□

M

l

Narzędzi*

1"ł '

Pomoc

r " " 1" ' ^ ,C’

— m,.. J j

1 E d W l^

Ł4wtui

| Zakończono

gdycja

4s

Widok

'

0

Historia

Zakładki

Narzędzi*

Pomoc

i>

© ' f i l 1... M>|).«Kw>«m»M»T,T O

Plik

Edycja.

Widok , Historia

S3'

Zakładki . Narzędzia

m m

Kiedy użytkownik klika przycisk Usuń zaznaczone nazwiska , implementacja JavaServer Faces wywołuje metodę TableData.deleteNames. Metoda deleteNames uzyskuje referencję do bieżącej tablicy nazwisk za pośrednictwem metody getWrappedData modelu danych, po czym tworzy nową tablicę (już bez nazwisk przeznaczonych do usunięcia) i umieszczają w modelu za pomocą metody setWrappedData. Mimo że prezentowany przykład nie ilustruje operacji dodawania wierszy, dobrze demonstruje ogólną procedurę — w pierwszej kolejności należy użyć metody getWrappedData() celem uzyskania bieżącego obiektu opakowanego przez model, następnie należy ten obiekt zmo­ dyfikować (przez dodanie lub usunięcie wierszy), po czym odświeżyć ten obiekt za pomocą metody setWrappedDala().

1%/ Usuwanie wierszy taiiełi -Mozilla firefox Ptik

Metoda deleteNames uzyskuje referencję do bieżącego zbioru nazwisk za pośrednictwem metody getWrappedData modelu, po czym tworzy nową tablicę, której rozmiar jest równy rozmiarowi tablicy bieżącej pomniejszonemu o liczbę nazwisk przeznaczonych do usunięcia. Ta sama metoda dodaje następnie bieżące nazwiska do nowej tablicy z pominięciem nazwisk przeznaczonych do usunięcia. 1wreszcie metoda deleteNames wywołuje metodę setWrappedData modelu celem jego odświeżenia z nową tablicą nazwisk.

Pomoc

'^caihost:8080rediti i 1

Na rysunku 5.13 przedstawiono strukturę katalogów tej aplikacji. Na listingach od 5.17 do 5.19 przedstawiono zawartość plików składających się na aplikację z rysunku 5.12.

Edytui il|

Edytuj 1

Rysunek 5.13.

¡ 2 delete.war

Struktura katalogów aplikacji demonstrującej usuwanie wierszy

f - t S m e t a -inf \ ’L Q MANIFEST.MF

|

|

|

!

f a

\... Q Name.class

|

|

f~ Q TableData. class

\

|.0 faces-config.xml

|

!..D web. xml

| D styles, css | D index.html L- D index.jsp_________________________

i p i Jednym ze sposobów usuwania wierszy jes t wywoływanie metody setWrappedData () ■ M d m odelu, która odświeża dane modelu, istnieje też możliwość odświeżenia sam ego

modelu: Name[] currentNames = (Name[]) model.getWrappedData(); Name[] newNames = new Name[currentNames.length getNumberOfNamesMarkedForDeletionO]:

corejsf

L~ D messages, properties

Na kolejnych zrzutach przedstawionych na rysunku 5.12 widać kompletną procedurę usu­ wania pojedynczego wiersza. Kiedy użytkownik klika przycisk Usuń zaznaczone nazwiska , implementacja JS F wywołuje metodę obiektu nasłuchującego akcji, której zadaniem jest usunięcie zaznaczonych wierszy. Wspomnianą metodę zaimplementowano w następujący sposób: public String deleteNames() { i f ( IgetAnyNamesMarkedForDeletionO) return n u li;

WEB-INF j f 1 /3 classes j j f ITS corn

model = new ArrayDataModel(newNarnes);

190

Rozdział 5. ■ Tabele danych

JavaServer Faces

Listing 5.17. Kod strony 1. 2 3. 4 5 6. 7 8 9 10 11. 12 13 14. 15. 16. 17. 18 19 20. 21. 22 23. 24 25. 26. 27. 28. 29. 30. 31 . 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46.

<«a taglib uri="http://java.sun.com/jsf/core" prefix=”f ' %>

Listing 5.18. Kod komponentu deiete/src/java/com/corejsf/Name.java 1. package com.corejsf,

2. 3. public class Name { 4. private String firs t; 5. private String last; 6. private boolean markedForDeletion = false;

7 8 9 10. 11. 12. 13 14. 15. 16. 17 18. 19. 20. 21. 22. 23 ]

public Name(String first, String last) { th is .firs t = first, this.last = last; } public void setFirst(String newValue) { firs t = newValue, } public String getFirstO { return first, } public void setLast(String newValue) { last = newValue, } public String getLastO { return last; } public boolean isMarkedForDeletionO { return markedForDeletion public void setMarkedForDeletion(boolean newValue) { markedForDeletion = newValue; }

Listing 5.19. Koc/ /c/asy cfe/ete/src/iav'a/co/D /corejsf/T abteD ata.yat'a 1. package com.corejsf,

2 3 import javax.faces.model.DataModel; 4. import javax.faces.model.ArrayDataModel; 5 6. public class TableData { 7. private boolean editable = false; 8. private ArrayDataModel model = null; 9. 10. private static final Name[] names = { 11. new Name("Anna", "Kowalska"), 12. new NamedJan", "Winnicki"), 13 new Name("Mariusz", "Reszczyński"), 14. new Name("Wojciech", "Dopierała"), 15. }; 16. 17 public TableDataO { model = new ArrayDataModel(names); } 18. 19. public DataModel getNamesO { return model; } 20. 21. public boolean isEditableO { return editable, } 22. public void setEditable(boolean newValue) {editable = newValue; } 23. 24 public String deleteNames() { 25. i f (IgetAnyNamesMarkedForDeletionO) 26. return null; 27. 28 Named currentNames = (Named) model ,getWrappedData(); 29. Named newNames = new Name[currentNames.length 30. - getNumberOfNamesMarkedForDeletionO]; 31. 32. for(int i =0, j = 0; i < currentNames.length; ++i) { 33. Name name = (Name) currentNames[i]; 34. i f ( ! name.isMarkedForDeletion()) { 35. newNames[j++] = name; 36. } 37. }

191

192

Javaserver Faces 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63.

Rozdział 5. ■ Tabele danych

model setwrappedData(newNdmes). return nu11.

Na rysunku 5.15 przedstawiono aplikację omówioną w podrozdziale „Edycja komórek tabeli"" i przebudowaną z myślą o obsłudze kolumn tabeli umożliwiających sortowanie.

} public int gelNumperOfNamesMarkedForDeletionO { Name[] currentNames - ( Namef]) modelgetWrappedData(). int cnt = 0. for (int i =0. i < currentNames length, Name name - (Name) currentNames[i]. if (name isMarkedForDe1et ionO ) +--cnt. } return cnt.

193

Rysunek 5.15.

|||i Przykład komponentu sortuj;

Sortowanie zawartości kolumn tabeli

{

Plik

Edycja

\Vtdok

Histona

Firefox Zakładki

Narzędzia

Pomoc

lisim N azw isk o Wmczor K owalska

Anna

D opier ała

W oj cie ch

Reszczyński M< PI«

Edycja

Widok

Historia

4 lU ff ł | I

f* } | I

Zakładki

Narzędzia

Pomoj

http://localhost.8080/sorti ▼

} U suń N azw isko IH

public boolean getAnyNamesMarkedForDeletionO { Named currentNames = (Named) model .getWrappedDataO; for(int i = 0; i < currentNames.length; ++i) { Name name = (Name) currentNames[i]; i f (name.isMarkeclForDeletionO) return true; } return false; } }

W iem y już, jak wykonywać proste operacje na modelu danych. W pewnych sytuacjach mu­ simy jednak stosować bardziej wyszukane formy przetwarzania polegające np. na sortowaniu lub filtrowaniu danych.

Dopierała [^W ojciech K ow alska

file;///C;/Users/Amol d/Do

Anna

Reszczyński Mariusz Winczorek Jan

Aplikacja przedstawiona na rysunku 5.15 umożliwia sortowanie kolumn tabeli, ponieważ dekoruje oryginalny model danych tabeli. Aby takie rozwiązanie było możliwe, w pierwszej kolejności musimy odpowiednio zdefiniować atrybut val ue znacznika h: dataTabl e:

Sortowanie i filtrowanie Aby sortować lub filtrować zawartość tabel reprezentowanych przez znacznik h: dataTabl e, musimy zaimplementować model tabeli dekorujący jeden z modeli już istniejących (wymie­ nionych na początku tego podrozdziału). To, na czym faktycznie polega dekorowanie modelu tabeli, przedstawiono na rysunku 5.14.

Rysunek 5.14.

Metoda Tabl eData. names zwraca model danych: public class TableData { private DataModel filterModel= nuli; private static final Name[] nanieś = { new NameC'Anna", "Kowalska"), new NameCJan", "Winnicki"), new NameCMariusz", "Reszczyński"), new Name( "Wojciech", "Dopierała"),

};

Filtr modelu danych

Obiekty klasy UIData (czyli komponentu związanego ze znacznikiem h; dataTabl e) wywołują metody swojego modelu. Jeśli zdecydujemy się udekorować ten model, nasz model (dekorator) musi przechwytywać te wywołania. Model dekoratora musi kierować te wywołania dalej, do modelu oryginalnego (z wyjątkiem metody setRowIndex zwracającej posortowane indeksy, zamiast oryginalnych indeksów modelu). Funkcjonowanie tego mechanizmu szczegółowo przeanalizujemy w dalszej części tego punktu.

public TableDataO { ArrayDataModel model = new ArrayDataModel(names); filterModel = new SortFiIterModel(model);

} public DataModel getNamesO { return filterModel;

} }

W momencie tworzenia obiektu tabl eData tworzony jest także egzemplarz klasy ArrayDataModel, którego konstruktor otrzymuje na wejściu tablicę nazwisk. Jest to nasz model oryginalny. W kolejnym kroku konstruktor klasy TableData opakowuje ten model modelem sortującym.

194

JavaServer Faces

Rozdział 5. ■ Tabele danych

Od tej chwili w wyniku wywołań metody get Names (odpowiedzialnej za wypełnianie tabeli danych) otrzymujemy model sortujący, który zaimplementowano w następujący sposób: public class SortFilterModel extends DataModel { private DataModel model: private Row[] rows; public SortFilterModel(DataModel model) this.model = model; int rowCnt = model .getRowCountO; i f (rowCnt != -1) { rows = new Row[rowCnt]; for (int i=0, i < rowCnt; ++i) rows[ i ] = new Row(i);

Rysunek 5.16.

S3 sorting.war ę C3 META-INF

Struktura katalogów analizowanej aplikacji

j

;

Q MANIFEST.MF

f £3 WEB-INF j y classes

! ! f Pcorn

{

I

|

|

j

j

L Q Name, class

;

j

i Q SortFilterModel$l.class

j

i

I Q SortFilterModel$2.class

\

j

IQ

\

]

$ (¡3 corejsf

So rtFilte rM odel $ Row. cIas s

j Q SortFilterModel.class

I

I

! Q TableData.class

j

|

! Q messages, properties

i

1 D faces-contlg *ml Q weto m1

i public void setRowIndex(int rowIndex) { if (rowlndex == 1 || rowlndex >= model getRowCount()) { model setRowlndex(rowlndex).

D Tvles

css

Q indei* fitn.I D mde* jsp_____________________________

1 else { model.setRow!ndex(rows[rowlndex].row);

Łatwo zauważyć, że w powyższym fragmencie kodu tworzymy tablicę indeksów reprezentu­ jącą indeksy posortowane. Jeśli indeks przekazany na wejściu metody seiRowIndex mieści się w przedziale, wykorzystujemy indeks posortowany. Jak przebiega sam proces sortowania? Klasa SortF 1 1terModel definiuje dwie metody, sort ByF i rst () oraz sortByLasU ): public String sortByLastO { Arrays.sort(rows, byLast); return nul1;

} public String sortByFirst() { Arrays.sort(rows, byFirst); return nul1;

} Zmienne byLast i by Fi rst reprezentują komparatory. Pierwszy z nich porównuje nazwiska, drugi porównuje imiona. Implementację tych komparatorów przedstawiono na listingu 5.21 w dalszej części tego podrozdziału. Strukturę katalogów przykładowej aplikacji sortującej przedstawiono na rysunku 5.16. Na listingach od 5.20 do 5.26 przedstawiono kompletny kod źródłowy tej aplikacji.

Specyfikacja JSF 1 ,2 zaleca definiowanie co najmniej dwóch konstruktorów w kom Bfeal kretnych klasach potomnych względem klasy DataModel: konstruktora bezargumentowego wywołującego m etodę setWrappedData(nuU) oraz konstruktora przekazującego opakow ane dane do m etody setWrappedDataO. Przykład definicji tych konstruktorów m ożna znaleźć na listingu 5 .2 1 .

Listing 5.20. Kod strony sorting/web/index.jsp 1



2


3

<°^0 bag 11 b

4 5 6. 7 8. 9. 10 11. 12. 13. 14. 15. 16. 17. 18 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.

or i ="ht ip .

/ /j a v a . sun com /jsf/ntm l"

prefix-="f" °^> p refix = "h " ^0>

<1ink href="site.css" rel="stylesheet" type="text/css"/>

195

196

JavaServer Faces 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48.



Listing 5.21. Kod komponentu sorting/src/java/com/corejsf/SortFilterModelJava 1. package com.corejsf;

2. 3. 4. 5. 6. 7.

import import import import import

java.util.Arrays; java.util.Comparator; javax.faces.model.DataModel; javax.faces.model.DataModelEvent; javax.faces.model.DataModelListener;

8. 9. public class SortFiIterModel extends DataModel { 10. private DataModel model; 11. private Row[] rows; 12.

13. 14. 15. 16. 17. 18. 19. 20.

21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.

private static Comparator byLast = new Comparator() { public int compare(Row rl, Row r2) { Name nl = (Name) rl.getDataO; Name n2 = (Name) r2.getData(); return nl,getLast() .compareTo(n2.getLast()); } };

private static Comparator byFirst = new Comparator() { public int compare(Row rl, Row r2) { Name nl = (Name) rl.getDataO; Name n2 = (Name) r2.getData(); return n l.g etFirst() .compareTo(n2.getFirstO); } }; private class Row { private int row; public Row(int row) { this.row =row;

Rozdział 5. ■ Tabele danych 35. 36 37. 38 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50 51. 52. 53. 54 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85.

} public Object getDataO { int original Index = model.getRowIndexO; model.setRowIndex(row); Object thisRowData = model.getRowData(); model.setRowIndex(originalIndex), return thisRowData, } } publ i C SortFi 1terModel () { / / wymagany przez specyfikację J S F thi s( ( NameF] ) nu ll), } public SortFi 1terModel (Name[] names) { / / zalecany przez specyfikację J S F setWrappedData( names); } public SortFiIterModel(DataModel model) { this.model = model; initializeRows(); } public String sortByLastO { Arrays.sort(rows, byLast); return null; } public String sortByFirst0 { Arrays.sort(rows, byFirst), return null; } public void setRowIndex(int rowlndex) { if(rowIndex == -1 || rowlndex >= model .getRowCountO) { model.setRowIndex(rowlndex); } else { model.setRowIndex(rows[rowIndex].row); } }

I I Poniższe metody delegują wywołania bezpośrednio // do udekorowanego modelu: public boolean isRowAvailable() { return model. isRowAvai lableO ; } public int getRowCountO { return model .getRowCountO; } public Object getRowDataO { return model .getRowDataO ;

86.

}

87. 88. 89. 90. 91.

public int getRowIndexO { return model .getRowIndexO; } public Object getWrappedDataO { return model .getWrappedDataO ;

197

198

Rozdział 5. ■ Tabele danych

JavaServer Faces 92 93. 94 95. 96 97 98. 99 100

101 102 103 104. 105. 106 107 108 109.

110 111.

import ja vax.faces.model.ArrayDataModel,

public void removeDataModelListener(DataModelListener listener) { model removeDataModelListenerdistener);

4. 5 6. 7 8 9. 10. 1112. 13 14. 15. 16-

}

N.

}

18. 19.

public DataModel getNamesO { return fi 1terModel;

20.

}

}

public void setWrappedData(Object data) { model setWrappedData(data), initializeRowsO; public void addDataModelListener(DataModelListener listener) { model.addDataModelListenerdistener),

}

public DataModelListener[] getDataModelListenersO { return model.getDataModelLi sterers(),

}

private void initializeRowsO { int rowCnt = model .getRowCountO: i f (rowCnt != -1) { rows = new Row[rowCnt], for(int i=0; i < rowCnt, ++i) { rows[ i ] = new Row(i);

112

113 114. 115 }

Listing 5.22. Kod klasy sorting/src/java/conn/corejsf/Name.Java________________________ 1 package com.corejsf;

2. 3 public class Name { 4 private String first; 5 private String last; 6 private boolean markedForDeletion =false, 7. 8. public Name(String first, String last) { 9. th is .firs t = first; 10. this.last = last; 11. 12

}

13. 14 15. 16. 17. 18. 19. 20. 21

public void setFirst(String newValue) { firs t = newValue, } public String getFirstO { return firs t; }

22.

}

public void setLast(String newValue) { last = newValue; } public String getLastO { return last, } public boolean isMarkedForDeletionO { return markedForDeletion, } public void setMarkedForDeletion(boolean newValue) { markedForDeletion = newValue;

23 }

Listing 5.23. Kod klasy sorting/src/java/conn/corejsf/TableData.java 1. package com.corejsf;

2. 3 import javax.faces.model.DataModel;

public class TableData { private DataModel filterModel = nuli; private static final Name[] names = { new NameOAnna", "Kowalska"), new Name("Jan", "Winnicki"), new Name("Mariusz", "Reszczyński"), new Name("Wojciech", "Dopierała"), }. public TableDataO { filterModel = new SortFilterModel(new ArrayDataModel(names)),

21. public String deleteNamesO { 22. i f (IgetAnyNamesMarkedForDeletiorO) 23. return null; 24. 25. Named] currentNames = (Named]) fi 1terModel,getWrappedData(); 26. Named] newNames = new NamedcurrentNames length 27 - getNumberOfNamesMarkedForDeletionO] 28. 20.for(int i =0, j = 0; i < currentNames.length, ++i) { 30. Name name = (Name) currentNamesdi]; 31 i f ( ! name.isMarkedForDeletionO) { 32. newNamesdj++] = name; 33. } 34. } 35. fi 1terModel.setWrappedData( newNames); 36. return nul 1, 37. } 38. 39. public int getNumberOfNamesMarkeclForDeletionO { 40. Named] currentNames = (Named]) f i 1terModel.getWrappedDataO; 41. int cnt = 0; 42. 43. for(int i = 0; i < currentNames.length; ++i) { 44. Name name = (Name) currentNamesdi], 45. i f (name.isMarkedForDeletionO) 46. ++cnt; 47. } 48. return cnt; 49. } 50. 51. public boolean getAnyNamesMarkedForDeletionO { 52. Named] currentNames = (Named]) f i 1terModel.getWrappedDataO, 53. for(int i = 0; i < currentNames.length, ++i) { 54. Name name = (Name) currentNamesdi]; 55. i f (name isMarkedForDeletionO) 56. return true; 57. } 58. return false, 59. } 60. }

199

200

JavaServer Faces

Listing 5.24.

Plik

Rozdział 5. ■ Tabele danych konfiguracyjny soriing/web/Wt

1 2 6 7 8 com corejsf messages 9 msgs 10 11 12 13. 14. tableData 15. com.corejsf.TableData 16. session 17. 18. 19.

Listing 5.25. Arkusz stylów sorting/web/styles.css 1. .names { border: thin solid black: 2. o \ ó. I 4. .namesHeader { text-align- center; 5. font-style: ita lic : 6. 7. color: Snow; background: Teal; 8. Q j . \ ) 10. last { height: 25px; 11. text-align: center; 12. background: MediumTurquoise; 13. 14. } 15. firs t { text-align: left: 16. background: PowderBlue; 17. 18. } 19. .caption { font-size: 0.9em; 20. font-style: ita lic : 21. 22. }

Listing 5.26. Plik komunikatów sorting/src/java/com/corejsf/messages.properties 1. 2. 3. 4 5 6

windowTitle=Przyklad komponentu sortującego JavaBeans pageTitle=Tabli ca nazwisk: fi rstColumnHeader=Imip 1astColumnHeader=Nazwi sko deleteColumnHeaderHJsun deleteButtonText=Usuń zaznaczone nazwiska

201

M javax.faces.model.DataModel ■

mt getRowCounU) Zwraca łączną liczbę wierszy, jeśli jest znana; w przeciwnym razie zwraca wartość -1. Metoda getRowCounK ) klasy Resul tSetDataModel zawsze zwraca wartość -1.

■ Object getRowData() Zwraca dane związane z bieżącym wierszem. ■ boolean isRowAvai lableO Zwraca wartość t cue, jeśli dla indeksu bieżącego wiersza istnieją prawidłowe dane. ■

int getRowlndexO Zwraca indeks bieżącego wiersza.

■ void setRowIndex(int index) Ustawia indeks bieżącego wiersza i aktualizuje zmienną reprezentującą bieżący element kolekcji (zmienną wskazaną za pośrednictwem atrybutu var znacznika h: dataTabl e). ■ void addDataModelListener(DataModelListener listener) Dodaje obiekt nasłuchujący na modelu danych, który będzie informowany o zmianach indeksu wierszy. ■ void removeDataModelListener(DataModelListener listen er) Usuwa obiekt nasłuchujący na modelu danych. ■ void setWrappedDataCObject obj) Wskazuje obiekt, który ma być opakowywany przez model danych. ■ Object getWrappedData() Zwraca opakowane dane modelu danych.

Techniki przewijania Istnieją dwie metody przewijania zawartości tabel złożonych z dużej liczby wierszy: z w y­ korzystaniem paska przewijania lub za pomocą kontrolki jakiegoś innego typu, która także może zmieniać aktualną pozycję na stronie. W tym podrozdziale przeanalizujemy obie te techniki.

Przewijanie z użyciem paska przewijania Najprostszym rozwiązaniem jest przewijanie z wykorzystaniem paska przewijania. W tym celu należy umieścić znacznik h: dataTabl e w ciele znacznika di v języka H TM L:

202

JavaServer Faces

Rozdział 5. ■ Tabele danych

<-div sty 1e="overf 1owauto. widtmlOOV heighi 2Û0px

tego rodzaju konstrukcji między innymi dla tabel tworzonych za pomocą znacznika h; da ba labie (patrz punkt Ja k prezentować wielkie zbiory danych stronami?" w rozdziale 13.). Przykład takiego rozwiązania przedstawiono na rysunku 5.18.



Rysunek 5.18.



Aplikacja przedstawiona na rysunku 5.17 różni się od aplikacji omówionej w podrozdziale „Tabele bazy danych" wyłącznie pionowym paskiem przewijania (wyświetlanym wskutek zastosowania powyższej konstrukcji HTML-a).

Rysunek 5.17. Przykład przewijania zawartości tabeli możliwego dzięki użyciu znacznika div

§

Edyąa Widok

Historia

Nsreędzia

Przewijanie za pomocą dodatkowych odwołań JSF

■ ■• ■

Przewijanie tabel bazy danych Mailla Firetov

Plik

203

Pomot

, http://localhost:8080.)

Identyfikator klienta

Imięinasińska ■Wojciech Dopierała

ul Kwiatowa 12

i wielkopolskie !

Anna K owalska Mannsz Eeszczyńskt Jan ^Jaiczorek

daiusławJabłoński ;■Krystyna Sobieraj Tomasz W ilk

,

OS: Kościuszki 3 A

^ląskift . _|

i

uł TroznańskaS? ul Falista 3

malopoUkie

iwie&opolsèàè'!

os Lecha 93/7 ul Bolesława Chtobreg.’

îV'irkre

Ę fr Przewijanie tabei bazy danych •Mpzilla Fke|ox;

p l ►! !C-i os. Ulanów8

; mazowiecki

ul Zakątek 21/2 "

;

tj

ul Gwarna 6

i' małopolskie 1

ul Kościuszki 3E

i

Wojciechowski Elżbieta M ąka

al W h kw arry 32* 1 os. Tysiąclecia 12/31

Jan Wieszczycki

ul Akacjowa 3

Franciszek Kikut.

ul Bajkowa 4/1

Ignacy Sowa

, os. Kosynierów 2A.

łódzkie ; wtefeppólskie ' wielkopolskie ' ;

tnkopolskie i

Paski przewijania są atrakcyjnym rozwiązaniem z punktu widzenia użyteczności, ale mogą się okazać zbyt kosztowne w przypadku szczególnie dużych tabel, ponieważ nie eliminują konieczności jednoczesnego ładowania wszystkich danych. Mniej wymagającą alternatywą jest użycie dodatkowych odwołań (łączy), które umożliwiają ładowanie tylko jednej, wybranej przez użytkownika strony danych.

Przewijanie za pomocą dodatkowych łączy Przewijanie dużych tabel za pomocą dodatkowych odwołań jest nie tylko bardziej efektywne niż przewijanie z wykorzystaniem paska przewijania (i znacznika di v języka H T M L), ale też dużo bardziej skomplikowane. W rozdziale 13. przeanalizujemy sposób implementowania

Aplikacja przedstawiona na rysunku 5.18 wykorzystuje tabelę danych obejmującą kody państw ISO (reprezenaijące właściwe ustawienia regionalne). Uzyskaliśmy tę listę za pośrednictwem wywołania metody statycznej java u t il Loca 1e . get ( SOCount r i es () zwracającej tablicę łańcuchów.

JavaServerFaces

6 Konwersja i weryfikacja poprawności danych W tym rozdziale omówimy sposoby konwersji danych formularzy na obiekty Javy i techniki weryfikacji poprawności uzyskiwanych w ten sposób wyników. Za realizację tych kroków przed aktualizacją modelu odpowiada kontener JS F , co daje nam pewność, że błędne (nie­ sprawdzone) dane wejściowe nigdy nie trafią do logiki biznesowej. W pierwszej kolejności skoncentrujemy się na ogólnej koncepcji procesu konwersji i wery­ fikacji poprawności. W kolejnych podrozdziałach przeanalizujemy standardowe znaczniki technologii JavaServer Faces opracowane właśnie z myślą o tych ważnych krokach. Prezen­ towane znaczniki powinny w zupełności wystarczyć do większości typowych zastosowań. W dalszej części tego rozdziału omówimy techniki wiązania aplikacji z własnym, niestandar­ dowym kodem konwertującym i weryfikującym na potrzeby bardziej złożonych scenariuszy. Istnieje też możliwość implementowania własnych znaczników reprezentujących mechani­ zmy konwersji i weryfikacji wielokrotnego użytku, które mogą być bez trudu konfigurowane przez autorów stron. Sama implementacja takich znaczników wymaga jednak dużo większego zaangażowania programisty. Szczegółowych informacji na ten temat należy szukać w podroz­ dziale „Implementacja niestandardowych mechanizmów konwersji i weryfikacji” w rozdziale 9.

Przegląd procesu konwersji i weryfikacji poprawności W tym podrozdziale dokonamy szczegółowej analizy drogi pokonywanej przez dane użyt­ kownika od formularza wyświetlanego w oknie przeglądarki do komponentów JayaBeans składających się na logikę biznesową.

206

JavaServer Faces Rozdział 6. ■ Konwersja i weryfikacja poprawności danych W pierwszej kolejności użytkownik wypełnia pole formularza intemeiowego. Kiedy użyt­ kownik klika przycisk akceptacji i wysłania formularza, przeglądarka wysyła wprowadzone dane na seiwer. Będziemy tę wartość nazywać wartością żądania (ang. request value).

Stosowanie wartości żądania

W fazie stosowania wartości żądania dane wejściowe są zapisywane w obiektach kompo­ nentów. (Musimy pamiętać, że dla każdego znacznika wejściowego użytego w kodzie strony JS F istnieje odpowiedni obiekt komponentu). Wartość zapisaną w obiekcie komponentu określamy mianem wartości wysianej (ang. submitted value). Wszystkie wartości żądania mają oczywiście postać łańcuchów, co jest o tyle normalne, że przeglądarka kliencka wysyła na serwer łańcuchy wpisane przez użytkownika. Z drugiej strony, aplikacja internetowa może operować na danych dowolnych typów, w tym typów int czy DaLe, a nawet najbardziej wyrafinowanych strukturach danych. Proces konwersji ma na celu przekształcenie łańcuchów przychodzących w obiekty tych typów. Szczegółowe omówienie konwersji można znaleźć w kolejnym podrozdziale. Przekonwertowane wartości nie są przekazywane bezpośrednio do komponentów JavaBeans składających się na logikę biznesową. W pierwszej kolejności są zapisywane w obiektach komponentów właściwych dla znaczników wejściowych w formie wartości lokalnych. Już po konwersji wspomniane wartości lokalne są poddawane procesowi weryfikacji poprawności. Warunki tej weryfikacji mogą być definiowane przez projektantów stron — na przykład dła niektórych pól można określić minimalną i (lub) maksymalną długość łańcucha. Do szcze­ gółowej analizy procesu weryfikacji poprawności przystąpimy w podrozdziale „Stosowanie standardowych mechanizmów weryfikacji” w dalszej części tego rozdziału. Po sprawdzeniu poprawności wszystkich wartości lokalnych, framework JS F przystępuje do realizacji fazy aktualizacji wartości modelu, w której wartości lokalne są umieszczane w komponentach JavaBeans (zgodnie z odpowiednimi referencjami). Część programistów zastanawia się, po co framework JS F w ogóle operuje na wartościach lokalnych. Czy nie byłoby lepiej, gdyby wartości żądania były składowane bezpośrednio w modelu? W technologii JS F zastosowano podejście dwukrokowe, które ma na celu ułatwienie zacho­ wywania integralności modelu. Nawet niedoświadczeni programiści doskonale wiedzą, że użytkownicy z zadziwiającą regularnością wpisują w formularzach błędne dane. Przypuśćmy, że jakieś wartości modelu zaktualizowano przed wykryciem pierwszego błędu w danych wejściowych. Model może się wówczas znaleźć w stanie niespójności, a przywrócenie orygi­ nalnego, prawidłowego stanu może się okazać bardzo kłopotliwe. Właśnie dlatego framework JS F w pierwszej kolejności dokonuje konwersji i weryfikacji wszystkich danych wejściowych użytkownika. W razie wykrycia błędów, strona formularza jest ponownie wyświetlana w oknie przeglądarki, stwarzając użytkownikowi możliwość uzu­ pełnienia lub poprawienia danych. Faza aktualizacji wartości modelu rozpoczyna się dopie­ ro wtedy, gdy wszystkie mechanizmy weryfikacji potwierdzą poprawność danych. Na rysunku 6.1 przedstawiono drogę pokonywaną przez wartość wpisaną w polu wejścio­ wym od przeglądarki internetowej do obiektu komponentu pracującego po stronie serwera i (dalej) do komponentu modelu.

207

Aktuałizacja wartości

Rysunek 6.1. Droga pokonywana przez wartość od przeglądarki internetowej do modelu

Stosowanie konwerterów standardowych W tym i kolejnym podrozdziale omówimy mechanizmy konwersji i weryfikacji poprawno­ ści oferowane w ramach biblioteki JS F . W dalszej części tego rozdziału skoncentrujemy się na technikach konstatowania własnych mechanizmów weryfikacji, niezbędnych w sytuacji, gdy dostępne rozwiązania nie spełniają naszych oczekiwań.

Konwersja liczb i dat Aplikacja internetowa może operować na danych wielu różnych typów, ale interfejs użyt­ kownika tej aplikacji oferuje wyłącznie obsługę łańcuchów. Przypuśćmy na przykład, że użytkownik ma w pewnym polu edytować datę (reprezentowaną w logice biznesowej przez obiekt klasy Date). W pierwszej kolejności istniejący obiekt klasy Date wymaga konwersji na łańcuch i wysłania do przeglądarki klienckiej celem wyświetlenia w odpowiednim polu tekstowym. Użytkownik edytuje następnie zawartość tego pola tekstowego. Wówczas łańcuch wynikowy zwrócony na serwer wymaga ponownej konwersji na obiekt klasy Date. Ta sama procedura jest stosowana — co oczywiste — także dla takich typów prostych jak int, double czy boolean. Użytkownik aplikacji internetowej edytuje łańcuchy, które są na­ stępnie konwertowane przez kontener JS F na typy wymagane przez logikę biznesową tej aplikacji. Aby przekonać się, jak działa konwerter wbudowany, wyobraźmy sobie aplikację internetową wykorzystywaną do przetwarzania danych o płatnościach kartą kredytową (patrz rysunek 6.2). Dane o każdej płatności obejmują: ■ wysokość płatności, ■ numer karty kredytowej, ■ datę ważności karty kredytowej.

208

Javaserver Faces

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych Ęji Aplikacja testująca m

Rysunek 6.2.

£Mc

Przetwarzanie danych o płatnościach

lętycja

Jgto*

'

jrłfjton?

Zakładki

j? i

f^ałięcbia

209

Konwertery i atrybuty

Pomoc

'D- 1 ’......... ’ u

[ś, 1 W tabelach 6.1 i 6.2 wymieniono i krótko opisano konwertery oraz ich atrybuty.

Prosimy wpisać dane o płatności

Tabela 6.1. Atrybuty znacznika f:convertNumber

Kwota Karta kredytowa Data ważności (miesiąc/rok)

Atrybut

Typ

Wartość

Type

String

number (domyślnie), currency lub percentage

pattern

String

wzorzec formatowania (zgodnie z dokumentacją API klasy java.text.Decimal Format)

Dołączamy do pierwszego pola tekstowego konwerter i sygnalizujemy konieczność takiego formatowania wartości bieżącej, aby za separatorem dziesiętnym zawierała przynajmniej dwie cyfry:

Konwerter f : convertNumber jest jednym ze standardowych konwerterów oferowanych przez implementację JSF. Na tym etapie, dla drugiego pola tego formularza, nie stosujemy żadnego konwertera. (W dalszej części tego rozdziału dołączymy do niego konwerter niestandardowy). Dla trzeciego pola tekstowego użyto konwertera f :convertDateTime, a jego atrybutowi pattern przypisano łańcuch MM/yyyy. (Format łańcucha pattern opisano w dokumentacji A P I klasy java.te x t.Si mpleDateFormat).

maxFractionDigits

i nt

maksymalna liczba cyfr w części ułamkowej

minFractionDigits

int

minimalna liczba cyfr w części ułamkowej

maxintegerDigits

i nt

maksymalna liczba cyfr w części całkowitej

mirilntegerDigits

i nt

minimalna liczba cyfr w części całkowitej

integerOnly

boolean

wartość true, jeśli analizie składniowej ma być poddawana tylko część całkowita (wartością domyślną jest fal se)

groupingUsed

boolean

wartość true Je śli mają być stosowane separatory grup cyfr (wartością domyślną jest true)

locale

java.util.Locale

ustawienia regionalne, które mają zostać użyte w procesie analizy składniowej i formatowania

currencyCode

String

kod walutowy zgodnie z normą ISO 4217 wykorzystywany w procesie konwersji wartości walutowych

currencySymbol

String

symbol waluty wykorzystywany w procesie konwersji wartości walutowych

Tabela 6.2. Atrybuty znacznika f:convertDateTime Na stronie result.jsp wyświetlamy dane wejściowe podane przez użytkownika, stosując dla wysokości płatności inny konwerter niż wcześniej: < f •CO nve rtN um De r

t y p e = " c u r r e n c y " />



Tym razem nasz konwerter automatycznie dopisuje do prezentowanej wartości symbol waluty i stosuje separator cyfr (patrz rysunek 6.3).

Rysunek 6.3. Wyświetlanie informacji o płatnościach

0.

Aplikacja testująca racę

fdycja Widok- Jl«tona

Nawgtoa |

Kwota

lOOUO.OOd

Karta kredvtowa

4 1 1111 1111 11 111J 1

Data ważności (miesiącu ok) 04'200ó

Typ

Wartość

type

String

date (domyślnie), time lub both

daLeStyle

String

defaulL, short, medium, long lub ful 1

CimeS tyle

String

default, short, medium, long lub ful l

pattern

String

wzorzec formatowania (zgodnie z dokumentacją API klasy java, text .SinipleDateFormat)

locale

java.util Locale

ustawienia regionalne, które mają zostać użyte w procesie analizy składniowej i formatowania

timeZone

java.util TimeZone

strefa czasowa wykorzystywana w procesie analizy składniowej i formatowania

/'i0l.3i«o^ 8080 'eon.! »

Informacje o płatności

FyMk j

,r

Atrybut

W H Jeśli użyjemy wyrażenia reprezentującego wartość typu prostego bądź (począwszy I H i od wersji JSF 1 .2 ) typu wyliczeniowego albo typów B ig in te g e r lub BigDecim al, nie musimy stosować konwertera. Im plem entacja JSF autom atycznie wybierze odpowiedni konwerter za nas. W arto jednak pam iętać o konieczności każdorazowego wskazywania konwertera dla wartości typu Date.

210

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

JavaServer Faces

Atrybut converter Alternatywnym sposobem dołączania konwerterów do komponentów interfejsu użytkownika jest dodawanie atrybutów converter do znaczników tych komponentów. Identyfikator kon­ wertera można wskazać, stosując następującą konstrukcję składniową: Znaczenie tego znacznika jest identyczne jak w przypadku elementu f :convertDateTime zdefiniowanego bez żadnych atrybutów: Trzecim sposobem dołączania konwertera jest użycie następującej konstrukcji składniowej: Wszystkie implementacje JS F muszą definiować zbiór konwerterów z następującymi (pre­ definiowanymi) identyfikatorami: ■ javax.faces.DateTime (wykorzystywany w znaczniku f :convertDateTime); ■ javax.faces.Number (wykorzystywany w znaczniku f :convertNumber); ■ javax. faces.Boolean, javax.faces.Byte, javax.faces.Character, javax.faces.Doubl e, javax.faces.FI oat, javax.faces. Integer, javax.faces.Long, javax.faces.Short (stosowane automatycznie dla typów prostych i ich klas opakowujących); ■ javax.faces.BigDecim al, javax.faces.Biglnteger (stosowane automatycznie dla typów BigDecimal i Big Integer). W razie konieczności dodatkowe identyfikatory konwerterów można konfigurować w pliku konfiguracyjnym (więcej szczegółów można znaleźć w podpunkcie „Wskazywanie konwer­ terów" w dalszej części tego rozdziału).

211

Błędy konwersji W razie wystąpienia błędu konwersji zostają podjęte następujące działania: ■ Komponent, którego konwersja zakończyła się niepowodzeniem, wysyła stosowny komunikat i deklaruje swoją niepoprawność. (Sposób prezentacji tego komunikatu omówimy w dalszej części tego punktu). ■ Bezpośrednio po zakończeniu fazy weryfikacji danych, implementacja JS F ponownie wyświetla bieżącą stronę. Wyświetlona strona obejmuje wszystkie wartości wpisane wcześniej przez użytkownika (żadne dane wejściowe nie są tracone). Opisywane zachowania w większości przypadków zdają egzamin. Jeśli na przykład użyt­ kownik wpisze błędne dane w polu tekstowym wymagającym podania liczby całkowitej, aplikacja w żadnym razie nie powinna podejmować prób wykorzystania niewłaściwych danych wejściowych. W takim przypadku implementacja JS F automatycznie wyświetla ponownie bieżącą stronę, stwarzając użytkownikowi jeszcze jedną szansę wpisania prawi­ dłowych wartości. Z drugiej strony, powinniśmy unikać nadmiernie restrykcyjnych opcji konwersji dla pól

wejściowych. Przeanalizujmy przykład pola tekstowego Kwota aplikacji obsługującej płat­ ności. Gdybyśmy zastosowali format walutowy, wartość wpisywana w tym polu byłaby odpo­ wiednio formatowana. Przypuśćmy jednak, że użytkownik wpisze liczbę 100 (bez symbolu waluty). Mechanizm odpowiedzialny za formatowanie kwot wyrażonych w walutach zasy­ gnalizuje niezgodność otrzymanej wartości ze wzorcem. Takie podejście wydaje się zbyt restrykcyjne w przypadku wartości wpisywanych przez użytkowników. Można ten problem rozwiązać, implementując własny, niestandardowy konwerter. Konwerter niestandardowy może jednocześnie formatować wartości zgodnie z naszymi oczekiwaniami estetycznymi i akceptować niedoskonałe dane wejściowe wpisywane przez użytkowników. Zagadnienia związane z takimi konwerterami omówimy bardziej szczegółowo w podrozdziale „Programowanie z wykorzystaniem niestandardowych konwerterów i mechanizmów wery­ fikujących" w dalszej części tego rozdziału. Decydując się na gromadzenie danych wpisywanych przez użytkownika, powinniśmy stosować albo bardziej wyrozumiałe konwertery, albo tak przebudować formularz, aby użytkownik nie m iał wątpliwości co do oczekiwanych danych. Przykładowo: zam iast zmuszać użytkownika do podawania daty ważności karty kredytowej w formacie MM/yyyy, m ożem y um ieścić na form ularzu dwa pola w ejściowe — jedno dla m iesiąca i drugie dla roku.

□ ■ ffij Jeśli atrybutowi converter przypiszemy łańcuch, przypisana wartość będzie reprewLm zentow ała identyfikator konw ertera. Jeśli je d n a k przypiszem y tem u atrybutowi wyrażenie reprezentujące wartość, wartość tego wyrażenia będzie wymagała konwersji na obiekt (a konkretnie egzemplarz klasy implementującej interfejs Converter). Interfejs Converter zostanie omówiony w podrozdziale „Programowanie z wykorzystaniem nie­ standardowych konwerterów i m echanizm ów weryfikujących”.

Wyświetlanie komunikatów o błędach P | l Specyfikacja JSF 1 .2 wspom ina o atrybucie opcjonalnym binding, który może być l w i stosowany w znacznikach f :convertNumber, f :convertDateTime i f:converter. W ten sposób możemy wiązać egzemplarze konwerterów z właściwościami typu javax. ^ fa c e s . convert. Converter kom ponentu w spom agającego.

Musimy oczywiście zadbać o prezentowanie użytkownikowi komunikatów o błędach wy­ krywanych w procesie konwersji i weryfikacji poprawności. Wszędzie tam, gdzie stosujemy konwertery i mechanizmy weryfikujące, powinniśmy korzystać także ze znaczników h:message.

212

JavaServer Faces

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

Z reguły chcemy wyświetlać komunikaty o błędach bezpośrednio obok komponentów, któ­ rych te komunikaty dotyczą (patrz rysunek 6.4). Komponentowi należy nadać identyfikator, do którego można się następnie odwoływać w znaczniku h;message. Specyfikacja JS F 1.2 dodatkowo nakłada na programistę obowiązek zdefiniowania etykiety komponentu, która będzie wyświetlana w ramach komunikatu o błędzie.

Jeśli nie odwołujemy się wprost do konwertera f :convertNumber, tylko bazujemy na standardowych konwerterach dla typów liczbowych, powinniśmy wyświetlać na stronie podsum ow ania kom unikatów (zam iast kom unikatów szczegółowych). Okazuje się, że w takim przypadku kom unikaty szczegółowe są zbyt drobiazgowe. Na przykład konw erter standardow y dla w artości typu doubl e generuje kom unikaty szczegółowe w postaci: ... must be a number between 4.9E-324 and 1 .7 9 7 6 9 3 1 3 4 8 6 2 3 1 5 7E308 Example: 1 9 9 9 9 9 9 .

□

message for="amount"/>

Rysunek 6.4. Przykład wyświetlonego komunikatu o błędzie konwersji

tM m ' H

i»

^ =

ia s iA u ł . . = ^ 1 1 5 * .

213

Komunikaty o błędach z reguły są wyświetlane w kolorze innym niż standardowe opisy na stronie. Zmiana wyglądu komunikatu wymaga użycia atrybutu styleClass lub style:

Prosim y wpisać dane o płatności lub Kw ota

¡zbyt wiele

Karta kredytowa

Î 4 Ï1 Ï Ï ÏÏ 1 Ï Ï 1 1 Ï Ï Ï Ï

Data ważności (miesiąc/rok)

¡10/2005



Zaleca się stosowanie atrybutu styl eCl ass wskazującego na zewnętrzny arkusz stylów (zamiast stylu zapisanego na stałe w kodzie strony).

Zakończono

Wyświetlanie wszystkich komunikatów o błędach Programiści, którzy pracują w technologii JS F 1.1, powinni pominąć atrybut 1abel.

Komunikat może występować w dwóch wersjach: podsumowania i wersji szczegółowej.

Sytuacja, w której musimy wyświetlać wiele komunikatów dla pojedynczego komponentu, zdarza się dość rzadko, ale nie można jej wykluczyć. Znacznik h:message generuje tylko pierwszy komunikat. Nie mamy niestety pewności, czy pierwszy komunikat rzeczywiście jest najbardziej przydatny z perspektywy użytkownika. Mimo że nie istnieje znacznik w y­ świetlający wszystkie komunikaty dla określonego komponentu, za pośrednictwem znacznika h :messages możemy uzyskać dostęp do wszystkich komunikatów właściwych dla wszystkich komponentów interfejsu użytkownika.

W przypadku konwertera liczb, szczegółowy komunikat o błędzie powinien obejmować ety­ kietę odpowiedniego komponentu, odrzuconą wartość oraz przykład poprawnej wartości, np.:

Znacznik h:messages domyślnie prezentuje podsumowanie komunikatu (zamiast jego szcze­ gółów), a więc działa odwrotnie niż znacznik h:message.

W ramach znacznika h:message możemy definiować wiele atrybutów opisujących wygląd komunikatu (więcej szczegółów na ten temat można znaleźć w podrozdziale „Komunikaty” w rozdziale 4.). W tym podpunkcie omówimy tylko atrybuty właściwe dla komunikatów o błędach.

Wartość 'zbyt wiele' nie jest liczbą. Przykład: 99 Podsumowanie komunikatu nie obejmuje części przykładu.

Atrybutowi layout znacznika h;messages z reguły przypisujemy wartość "table", aby kolejne komunikaty były wyświetlane w kolejnych wierszach tabeli. Gdybyśmy tego nie zrobili, treść komunikatów zostałaby skonkatenowana.

Za każdym razem , gdy tworzymy kom unikat, m usim y się upewnić, że kończy się kropką i dodatkową spacją, aby w razie konkatenacji wielu kom unikatów ich treść była czytelna.

□ Znacznik h:message domyślnie wyświetla informacje szczegółowe i ukrywa podsumowanie. Jeśli chcemy, aby na stronie było prezentowane tylko podsumowanie komunikatu, powinniśmy użyć następujących atrybutów: message for=''amount" showSummary="t;rue" showDetai l="false” />

Znacznik h: messages je s t szczególnie przydatny w procesie diagnozowania opro­ gram owania. Za każdym razem , gdy nasza aplikacja w nieskończoność prezentuje jed n ą stronę i odrzuca kolejne żądania użytkownika, warto dodać do jej kodu znacznik , aby sprawdzić, czy faktyczną przeszkodą nie je s t błąd konwersji lub weryfikacji poprawności.

□

214

JavaServer Faces

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

'P S j W technologii JSF kom unikaty o błędach nie obejm owały etykiet. Takie podejście ■■JB znacznie ograniczało przydatność znacznika h:messages, ponieważ użytkownicy musieli sami analizować form ularz pod kątem kontrolek wejściowych, które doprowa­ dziły do sygnalizowanego błędu.

Stosowanie niestandardowych komunikatów o błędach Począwszy od wersji JS F 1.2, istnieje możliwość definiowania własnych, niestandardo­ wych komunikatów o błędach konwerterów dla poszczególnych komponentów. W tym celu należy przypisać łańcuch komunikatu atrybutowi converterMessage komponentu interfejsu użytkownika, którego wartość podlega konwersji. Przykład takiego rozwiązania przedsta­ wiono poniżej:
Tabela 6.3. Standardowe komunikaty o błędach konwersji Identyfíkator zasobu

Komunikat domyślny

javax faces.converter J ntegerConverter ^-INTEGER

digits.

javax faces converter 1ntegerConverter ^ 1NTEGE R_det a 1 1

¡21: "!Oi" must be a number between -2 I47483648 and 2147483647.

W przeciwieństwie do łańcuchów kom unikatów, które omówimy w kolejnym pod­ punkcie, łańcuchy przypisywane atrybutowi corwerterMessage są wyświetlane na stronie w niezmienionej postaci. Oznacza to, że takie symbole zastępcze jak {0} w ogóle nie są zastępow ane.

Modyfikowanie treści standardowych komunikatów o błędach W niektórych przypadkach będziemy zmuszeni zmodyfikować standardowe komunikaty o błędach konwersji wyświetlane na rozmaitych stronach naszej aplikacji internetowej. W ięk­ szość typowych komunikatów standardowych przedstawiono w tabeli 6.3. Łatwo zauważyć, że wszystkie klucze komunikatów szczegółowych kończą się przyrostkiem _detai 1. Aby wspomniana tabela nie zajmowała zbyt dużo miejsca, zrezygnowano z prezentacji odrębnych łańcuchów podsumowania i szczegółów w sytuacji, gdy łańcuch podsumowania jest podłańcuchem łańcucha szczegółów. W większości komunikatów symbol {0} reprezentuje nie­ prawidłową wartość, symbol {1} reprezentuje przykładową wartość poprawną, a symbol (2) reprezentuje etykietę komponentu. Okazuje się jednak, że w przypadku konwertera wartości logicznych etykieta komponentu jest reprezentowana przez symbol {1}. Zastąpienie komunikatu standardowego wymaga zdefiniowania pakietu komunikatów (patrz rozdział 2.). Dodanie własnego komunikatu wymaga oczywiście odwołania do właściwego klucza z tabeli 6.3. Przypuśćmy na przykład, że nie chcemy, aby konwerter f :convertNuiriber, raportując o błędzie, odwoływał się do etykiet lub przykładów prawidłowych wartości. W tym celu wystarczy umieścić w pakiecie komunikatów następującą definicję: javax.faces.converter.NumberConverter.NUMBER_detai1= ''{0 }'' nie jest liczbą.

/2/; 7 0}" must be a number consisting o f one or more

Example: /// javax faces converter DoubleConverter ^DOUBLE

¡2j: "¡01" must be a number consisting o f one or more digits.

javax faces converter DoubleConverter ^►DOUBLE detai 1

¡21: "¡01" must be a number between 4.9E-324 and 1.7976931348623157E308.

converterMessage="NieprdwicHowa liczba "/>

0

Example: ¡11 javax faces.converter BooieanConverter ^B00LLAN_deta 1 1

¡I,1: "¡01" must be 'true' or 'false'. Any value other than 'true' will evaluate to 'false'.

javax faces converter NumberConverter ^NUMBER detai l

¡21: "¡01" is not a number.

javax faces converter NumberConverter ^CuRRENCv_detai 1 javax faces converter NumberConverter ^►PERCENT_deiai1 javax faces converter Date!meConverter ^DATE_deta 1 1 javax faces converter DateT meConverter ^TIME_detail

Example: /// ¡ 2 f "¡01" could not be understood as a currency value. Example: ¡11 ¡21: "¡01" could not be understood as a percentage. Example: ¡11 ¡2(( : "¡01" could not be understood as a date. Example: ¡11 ¡2j: "10/ " could not be understood as a time. Example: {1}

javax.faces.converter .DateTimeConverter ^PATTERNJYPE

{1}: A 'pattern' or 'type' attribute must be specified to convert the value "{0} ".

javax.faces.converter EnumConverter ENLIM

{2}: "{0}" must be convertible to an enum.

javax.faces.converter EnumConverter. ^ENUM_detail

{2}: "{0}" must be convertible to an enum from the enum that contains the constant "{1} ".

javax.faces.converter EnumConverter ^ENUM_NO_CLASS

{!}: "{0}" must be convertible to an enum from the enum, but no enum class provided.

javax.faces.converter EnumConverter ^ENUM_NO_CLASS_detai 1

{!}: "{0}" must be convertible to an enum from the enum, but no enum class provided.

Musimy jeszcze ustawić nazwę bazową tego pakietu w pliku konfiguracyjnym (np. faces-

config.xml):

215

com.corejsf.nessages

216

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

JavaServer Faces Opisaną procedurę musimy stosować wyłącznie dla komunikatów, które chcemy nadpisać. W technologii JSF 1 .1 uniwersalny komunikat Conversion error occurred jest repre­ zentowany przez klucz javax. faces, component. Ul Input .Conversion.

Kompletny przykład konwertera Nadszedł czas na analizę naszego pierwszego, kompletnego przykładu konwertera. Strukturę katalogów przykładowej aplikacji przedstawiono na rysunku 6.5. Prezentowana aplikacja internetowa prosi użytkownika o podanie informacji o płatności (patrz listing 6.1), po czym wyświetla odpowiednio sformatowane dane na stronie potwierdzenia (patrz listing 6.2). Komu­ nikaty zdefiniowano na listingu 6.3, natomiast kod klasy komponentu JavaBean przedstawiono na listingu 6.4.

21 22 23



24 25 26 28 < f COnvertDateT ime pat tern-'l M M / y iy y y " / > 29 30 31 32 33 34 35. 36

Listing 6.2. Kod strony converter/web/result.jsp Rysunek 6.5.

¡¡3 co n ve rte r.w ar

Struktura katalogów aplikacji ilustrującej działanie konwertera

t Q META-INF I f

'

Q MANIFEST.MF

|33 WEB-INF

|

f

;

|

C 5 classes

\

\

\

j...................... |.. Q Paym ent Be an. cl ass

com k C 3 co rejsf

I

\

|

T Q

faces-config.xm l

L Q

m essag es, p rop erties

\

L Q

w eb. xml

j - Q styles, css i

Q

index.htm l

| D

in d e x .jsp

L

result.jsp ______________________________

Q

Listing 6.1. Kod strony converter/web/indexJsp 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17 18. 19. 20.

<%$ taglib uri="http://Java.sun.com/jsf/core" prefix="f" %> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" <1ink href="styles.css" rel="stylesheet" type="text/css"/>

1. 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 19 20. 21. 22. 23. 24 25. 26 27. 28. 29. 30.

Listing 6.3. Zawartość pliku converter/src/java/com/corejsf/messages.properties 1. title=Apli kacja testująca mechanizm konwersji danych 2. enterPayment=Prosimy wpisać dane o płatności 3. amount=Kwota

217

218

JavaServer Faces

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

4. creditCard=Karta kredytowa 5 expirationDate=Data ważności (miesiąc/rok) 6. process=Przetwórz 7. paymentInformation=Informacje o płatności

Weryfikacja długości łańcuchów i przedziałów liczbowych

Listing 6.4. Kod komponentu converter/src/java/com/corejsf/PaymentBean.java 1.

219

Stosowanie mechanizmów weryfikacji JS F w ramach stron JavaServer Faces jest bardzo proste — wystarczy w ciele znacznika komponentu interfejsu użytkownika umieścić odpo­ wiednie znaczniki:

package com.corejsf;

2 3. import java.util Date, 4 5. public class PaymentBean { 6. private double amount; 7 private String card = 8 private Date date = new Daten. 9

Właściwość amouni:

10

//

11 12

public void setAmount(double newVaiue) {amount - newValue. } pubhc double getAmounti) { return amount. \

Powyższy fragment kodu dodaje do pola tekstowego mechanizm weryfikujący; w czasie wysyłania formularza, do którego należy to pole, wspomniany mechanizm sprawdza, czy wpisany łańcuch składa się z co najmniej 13 znaków. W razie niepowodzenia weryfikacji (czyli wykrycia, że dany łańcuch składa się z 12 lub mniejszej liczby znaków) zostaną wyge­ nerowane komunikaty o błędach związane z właściwym komponentem. Komunikaty o błę­ dach można następnie wyświetlać na stronie JS F za pomocą znacznika h:message lub h;messages.

13

Właściwość card:

14

//

15 16

public void setCard(Strmg newValue) { cand public String getCardO { return card. [

- newValue.

\

17 18

II Właściwość date:

19 20

public void set Dat e(Da t e newValue) j date public Date getDateO { return date. }

21

=newValue. \

}

P M | Technologia JavaServer Faces l.x nie oferuje bezpośredniej obsługi weryfikacji ■¡¡¡■1 poprawności danych wejściowych po stronie klienta. Wszystkie operacje związane z taką weryfikacją są wykonywane po stronie serwera już po wysłaniu przez użytkownika danych form ularza. Gdybyśmy chcieli przenieść te rozwiązania na poziom przeglądarki internetow ej, musielibyśm y opracować w łasne, niestandardow e znaczniki zaw ierające o dpow iednie p o lecen ia języka JavaS cript. Szczegółowych inform acji na te n te m a t należy szukać w rozdziale 1 3 . Technologia JavaServer Faces oferuje mechanizmy wbudowane, które umożliwiają nam realizację następujących zadań związanych z weryfikacją danych wejściowych:

Stosowanie standardowych mechanizmów weryfikujących

■ sprawdzanie długości łańcuchów; ■ sprawdzanie przedziałów, do których powinny należeć wartości liczbowe (np. > 0 lub < 100); ■ sprawdzanie, czy wymagane wartości w ogóle zostały wpisane przez użytkownika.

Trudno sobie wyobrazić aplikację internetową bez jakichkolwiek mechanizmów weryfika­ cji danych. Ponieważ tego rodzaju mechanizmy są wszechobecne w świecie aplikacji inter­ netowych, należy oczekiwać, że ich stosowanie i rozbudowa nie powinny stanowić większego problemu. Okazuje się, że technologia JavaServer Faces spełnia oba te wymagania przez udostępnienie szeregu standardowych mechanizmów weryfikacji i oferowanie prostego modelu implementowania własnych, niestandardowych mechanizmów tego typu. Kluczowym zadaniem stawianym mechanizmom weryfikacji danych wejściowych jest ochrona modelu. Ponieważ w technologii JS F stosuje się odrębne etapy dla weryfikacji danych i aktuali­ zacji wartości modelu, możemy być pewni, że nasz model nie znajdzie się w stanie niespójno­ ści, nawet jeśli dane wejściowe zostaną odrzucone.

W tabeli 6.4 wymieniono standardowe mechanizmy weryfikacji oferowane przez technolo­ gię JSF. Przykład mechanizmu weryfikującego długość łańcucha przedstawiono na początku tego punktu. Weryfikacja numerycznych danych wejściowych wymaga użycia mechanizmu sprawdzającego przynależność do przedziału. Przykład takiego rozwiązania przedstawiono poniżej:

Atrybut required jest obsługiwany przez wszystkie znaczniki wejściowe technologii Java­ Server Faces. Atrybut requi red można stosować łącznie z zagnieżdżonym mechanizmem weryfikacji: <7h inputText>

M 9 Jeśli nie przypiszemy atrybutowi required wartości true i jeśli użytkownik nie wpisze l U l w odpowiednim polu wejściowym żadnych danych, nie zostaną podjęte żadne kroki weryfikacyjne! W takim przypadku puste pole zostan ie zinterpretow ane ja k o żądanie pozostawienia istniejącej wartości w niezm ienionej form ie. Alternatywna składnia dołączania mechanizmów weryfikacji do komponentów interfejsu użytkownika bazuje na znaczniku f :val idator. Identyfikator mechanizmu weryfikacji i jego parametry można zdefiniować w następujący sposób:

Jeszcze inny sposób wskazywania mechanizmów weryfikacji polega na definiowaniu atrybutu va 1idator w ramach znacznika komponentu (patrz punkt „W eryfikacja za pomocą metod komponentów JavaBeans” w dalszej części tego rozdziału).

221

1.2n zaczniki f : val i dateLength, f : val i dateLo

Wyświetlanie komunikatów o błędach weryfikacji Komunikaty o błędach weryfikacji danych wejściowych są obsługiwane w taki sam sposób jak komunikaty o błędach konwersji. Każdy taki komunikat jest dodawany do komponentu, który nie przeszedł procesu weryfikacji. Odpowiedni komponent interfejsu użytkownika jest wówczas oznaczany jako nieprawidłowy, a bieżąca strona jest ponownie wyświetlana bezpośrednio po zakończeniu fazy weryfikacji procesu. Do wyświetlania komunikatów o błędach weryfikacji służą znaczniki h :message i h . messages. Szczegółowe omówienie tych znaczników można znaleźć w podpunkcie „Wyświetlanie komu­ nikatów o błędach” we wcześniejszej części tego rozdziału. Technologia JS F 1.2 oferuje nam możliwość definiowania komunikatów niestandardowych dla komponentów interfejsu użytkownika za pośrednictwem atrybutu requi redMessage lub validatorMessage: requiredMessage="#{msgs.cardRequired}" validatorMessage="#{msgs.cardInvalid}">
W tym punkcie przeanalizujemy przykładową aplikację prezentującą formularz, dla którego zastosowano wszystkie standardowe mechanizmy weryfikacji technologii JSF : pola wymagane, łańcuchy określonej długości oraz przedziały liczbowe. Prezentowana aplikacja sprawdza, czy użytkownik wypełnił wszystkie pola, czy kwota płatności mieści się w przedziale od 10 do 10 000, czy numer karty kredytowej obejmuje co najmniej 13 znaków i czy numer PIN jest liczbą z przedziału od 1000 do 9999. Typowe komunikaty o błędach weryfikacji przed­ stawiono na rysunku 6.6. Nasz formularz zawiera też przycisk Anuluj , którego kliknięcie powoduje pominięcie procesu weryfikacji.

Rysunek 6.6.

I

Typowe komunikaty o błędach weryfikacji danych wejściowych

Plik

Edycja

W idok

Historia

Zakładki

Naizęttzia

| \

P om oc

http://locaIhost:8U80/yali dator/mdex.fact|J.jpk] [j C ^ ^ o g le

P rosim y w p isać dane o płatności — •>Kwola tiąU v.rrJ>ytik.,icv'. lYrekazany •¡irTut mc- mtś> i

Tlę

10■ ©i1 '1'¡001

¡.L.:irtrikre--i;c!'cv,:! BiąV. weiyfsri!' u Lu A

javax faces.validator. ^DoubleRangeValidator MINIMUM javax.faces.validator ^►LongRangeValidator MINIMUM javax.faces.validator '-►DoubleRangeVali dator.TYPE javax.faces.validator. ^►LongRangeValidator.TYPE javax.faces.validator. '-►LengthVal idator .MAXIMUM

javax.faces.validator. ^LengthValidator.MINIMUM

223

{I}: Validation Error: Value Obiekty klas DoubleRangeVal idator i LongRangeValidator w sytuacji, is less than allowable gdy podana wartość nie mieści się minimum of"{0 w przedziale i gdy zdefiniowano tylko wartość minimalną. {0}: Validation Error: Value Obiekty klas DoubleRangeVal idator is not o f the correct type. i LongRangeVal idator w sytuacji, gdy konwersja danej wartości na liczbę typu doubl e lub 1ong jest niemożliwa. {1}: Validation Error: Value Obiekt klasy LengthVal idator w sytuacji, gdy długość łańcucha is greater than allowable wejściowego jest większa maximum of"{0 }”. od długości maksymalnej.

1maietssa

a

cyh

i Data

.1

tvaai->$ci •untsiĄchck} pj.f w^r-rnkacjt Bnik ' wvirtv .¿ci v

Strukturę katalogów tej aplikacji przedstawiono na rysunku 6.7. Na listingu 6.5 przedsta­ wiono kod strony JS F , w którym odwołano się do mechanizmów weryfikacji. 3

Rysunek 6.7. Struktura katalogów przykładowej aplikacji

v a lid a to r , w a r

f- S3 META-IMF j [ Q MANIFEST.MF f- E3 WEB-INF

j f- (¡3 c l a s s e s | |

| |

f E 3 com | 7 Q ' D

{!}: Validation Error: Value Obiekt klasy LengthVal i dator w sytuacji, gdy długość łańcucha is less than allowable wejściowego jest mniejsza minimum o f "{0} ". od długości minimalnej.

t ( ¡3 c o r e js f )-” Q P a y m e n t B e a n . cla s s G m e s s a g e s .p r o p e r t i e s f a c e s - c o n f i g .x m l w eb.xm l

■Q styles, css ~ Q index, htrnl r- Q canceled.jsp

Oczekiwanie od użytkowników wypełniania pól wymaganych nawet wtedy, gdy mogą się decydować na anulowanie całego formularza, byłoby nielogiczne. Okazuje się, że istnieje mechanizm umożliwiający pomijanie procesu weryfikacji. Jeśli przypiszemy wartość true atrybutowi immediate kontrolki polecenia, odpowiednie polecenie zostanie wykonane w fazie stosowania wartości żądania. Przycisk Anuluj można by zaimplementować w następujący sposób: 3. taglib uri="http7/java.sun.com/jsf/html" prefix="h" %> 4. 5. 6. 8.

224

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

JavaServerFaces 9. 10 11 12. 13. 14. 16. 18 19 . 20. 21. 22. 24. 30. 32. 33. 34. 37. 38. 39. 40. 41.

225

Implementacja klas konwerterów niestandardowych Konwerter ma postać klasy odpowiedzialnej za konwersję danych pomiędzy postacią łańcu­ chową a odpowiednimi obiektami. Każdy konwerter musi implementować interfejs Converter obejmujący następujące metody: Object getAsObject(FacesContext context, UlComponent component, String newValue) String getAsString(FacesContext context. UlComponent component, Object value)

Pierwsza metoda konwertuje łańcuch na obiekt odpowiedniego typu i generuje wyjątek ConverterException w sytuacji, gdy taka konwersja okaże się niemożliwa. Metoda getAsObject jest wywoływana w chwili wysłania przez klienta danych w formie łańcucha (zwykle jest to wartość wpisana w polu tekstowym). Metoda getAsString konwertuje istniejący obiekt na re­ prezentację łańcuchową, która może być wyświetlana za pośrednictwem interfejsu klienckiego. Aby przekonać się, jak w praktyce działają te metody, spróbujemy opracować konwerter niestandardowy dla numerów kart kredytowych. Nasz konwerter umożliwi użytkownikom wpisywanie numerów zarówno ze spacjami, jak i bez spacji. Oznacza to, że będą akcepto­ wane dane wejściowe w następujących formatach: 1234567890123456 1234 5678 9012 3456

Kod tego konwertera przedstawiono na listingu 6.6. Metoda getAsObject klasy naszego kon­ wertera eliminuje z łańcucha wejściowego wszystkie znaki inne niż cyfry, po czym tworzy obiekt klasy CreditCard. W razie wykrycia błędu opisywany konwerter konstruuje obiekt klasy FacesMessage i generuje wyjątek ConverterException. Szczegółowe omówienie tych kroków można znaleźć w podpunkcie „Raportowanie o błędach konwersji” w dalszej części tego podrozdziału.

Listing 6.6. Kod konwertera con verter2/src/ja va/com/coresjf/CreditCardCon verierja va_______________ 1. package com.corejsf,

Programowanie z wykorzystaniem niestandardowych konwerterów i mechanizmów weryfikujących Standardowe konwertery i mechanizmy weryfikacji technologii JS F okazują się wystarczające w przypadku większości zastosowań, jednak wiele aplikacji internetowych wymaga bardziej zaawansowanych rozwiązań. Możemy na przykład stanąć przed koniecznością konwersji typów innych niż liczby czy daty lub przeprowadzania procesu weryfikacji właściwego dla budowanej aplikacji, np. dotyczącego karty kredytowej. W kolejnych punktach tego podrozdziału omówimy sposób implementacji niestandardowych, własnych konwerterów i mechanizmów w eryfikacji z m yślą o konkretnych aplikacjach. Implementacja tego rodzaju rozwiązań wymaga od programisty sporo pracy.

2. 3. 4. 5. 6. 7.

import import import import import

javax.faces.application.FacesMessage, javax.faces.component.UlComponent; javax.faces.context.FacesContext; javax.faces.convert.Converter; javax.faces.convert.ConverterException;

8.

9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.

public class CreditCardConverter implements Converter { public Object getAsObject(FacesContext context, UlComponent component, String newValue) throws ConverterException { StringBuilder builder = new StringBuilder(newValue); boolean foundlnvalidCharacter= false; char invalidCharacter = 707 int i = 0; while (i < builder.lengthO && !foundlnvalidCharacter) { char ch = bui1der.charAt( i ); i f (Character.isDigit(ch)) i++; else i f (Character.isWhitespace(ch)) builder,deleteCharAt(i); else {

226

JavaServer Faces 23. 24. 25. 26 27 28 29 30.

foundlnvalidCharacter = true; invalidCharacter = ch; } i f (foundlnvalidCharacter) { FacesMessage message = com.corejsf.uti1.Messages.getMessage( "com.corejsf.messages", "badCreditCardCharacter", new Object[]{ new Character(invalidCharacter) }). message.setSeveri ty(FacesMessage.SEVERITY_ERROR), throw new ConverterException(message); }

32

33 .

43 .

44. 45. 46. 47. 48 49 50 51. 52. 53 54.

return new CreditCard(builder.toStringO); } public String getAsString(FacesContext context, UlComponent component, Object value) throws ConverterException { I I długość: 13 cyfr — xxxx xxx xxx xxx I I długość: 14 cyfr — xxxxx xxxx xxxxx I I długość: 15 c y fr — x x xx x xxxxx x x xxx / / długość: 16 cyfr — xx xx x x xx x x xx xx xx I I długość: 22 cyfry — xxxxxx xxxxxx xx xxxxxxxx

58 59. 60 61 62. 63. 64 65. 66. 67.

String v = value.toStringO ; in t[] boundaries = null; int length = v lengthO; i f (length == 13) boundaries = new in t[]{ 4, 7, 10 }; else i f (length ==14) boundaries = new in t[]{ 5, 9 }; else i f (length ==15) boundaries = new in t[]{ 4, 10 }, else i f (length ==16) boundaries = new in t[]{ 4, 8 , 12 }; else i f (length ==22 ) boundaries = new in t[]{ 6, 14 }; else return v; StringBuiIder result = new StringBuilder(); int start = 0; for (int i = 0; i < boundaries length; i++) { int end = boundaries[i]; result.append(v.substring(start, end)); result.appendC "); start = end;

68.

}

55 56

57

69. result.append(v.substri ng(start)), 70. return result.toStringO , 71. } 72. }

Metoda getAsStri ng klasy konwertera odpowiada za formatowanie numeru karty kredytowej w sposób zgodny z oczekiwaniami użytkownika. Cyfry pogrupowano zgodnie ze wzorcami właściwymi dla poszczególnych rodzajów kart kredytowych. Formaty numerów najbardziej popularnych rodzajów kart kredytowych przedstawiono w tabeli 6.6.

227

Tabela 6.6. Formaty numerów kart kredytowych Rodzaj Karty

Liczba cyfr

Format

MasterCard

16

5xxx xxxx xxxx xxxx

Visa

16

4xxx xxxx xxxx xxxx

Visa

13

4xxx X X X

Discover

16

6xxx xxxx xxxx xxxx

American Express

15

31XX xxxxxx xxxxx

American Express

22

3xxxxx xxxxxxxx xxxxxxxx

Diners Club, Carte Blanche

14

3xxxx xxxx xxxxx

}

31

34 35 36 37 38. 39. 40. 41. 42.

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

X XX X XX

W analizowanym przykładzie klasa CreditCard ma charakter pomocniczy, a jej rola ogranicza się do reprezentowania numeru karty kredytowej (patrz listing 6.7). Moglibyśmy oczywiście pozostawić oryginalną reprezentację numeru karty kredytowej w formie obiektu klasy S tri ng, a tym samym ograniczyć zakres funkcjonowania konwertera do zadań właściwych raczej dla formatera. Z drugiej strony, większość konwerterów ma na celu przekształcanie oryginalnych danych wejściowych w obiekty typów innych niż String. Aby uprościć ewentualne wyko­ rzystywanie prezentowanego przykładu w innych aplikacjach, zdecydowaliśmy się zdefi­ niować wyspecjalizowany typ docelowy.

Listing 6.7. Kod klasy converter2/src/java/com/corejsf/CreditCard.java___________________ 1. package com.corejsf;

2 3. public class CreditCard { 4. private String number; 5. 6. public CreditCard(String number) { this.number = number; } 7. public String toStringO { return number; }

8- }

Wskazywanie konwerterów Jednym ze sposobów wskazywania konwerterów jest korzystanie z symbolicznych identy­ fikatorów rejestrowanych za pośrednictwem aplikacji JSF. Dla naszego konwertera numerów kart kredytowych wykorzystamy identyfikator com.corej s f .Credi tCard. Poniżej przedstawiono wpis umieszczony w pliku konfiguracyjnym faces-config.xml i wiążący wspomniany iden­ tyfikator konwertera z klasą, która ten konwerter implementuje: com.corejsf.CreditCard com.corejsf.CreditCardConverter

Od tej pory przyjmujemy, że właściwość card komponentu PaymentBean reprezentuje obiekt klasy CreditCard (patrz listing 6.13 w dalszej części tego podrozdziału). Możemy teraz wyko­ rzystać znacznik f .-converter do określenia identyfikatora konwertera:

228

JavaServer Faces <1-Converter converterld="com corejsf OeditCard"/>

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych ffl

229

javax. faces.convert.Converter

■ Object getAsObject(EacesContext context. UlComponent component. String value)

Możemy też użyć bardziej zwięzłej konstrukcji składniowej w postaci atrybutu Converter:

Konwertuje daną wartość łańcuchową na obiekt, który może być składowany w ramach danego komponentu.



W tym konkretnym przypadku komponent JavaBean nazwany bb musi obejmować właści­ wość convert typu Converter. W razie konieczności możemy zaimplementować metodę zwracającą wartość tej właściwości, czyli obiekt klasy wewnętrznej:

Raportowanie błędów konwersji Po wykryciu błędu, konwerter powinien wygenerować wyjątek typu ConverterException. Na przykład metoda getAsObject naszego konwertera numerów kart kredytowych sprawdza, czy wpisany numer nie zawiera znaków innych niż cyfry i separatory. W razie wykrycia niewłaściwego znaku wspomniana metoda sygnalizuje wystąpienie błędu:

public class BacKingBean { pub11 c Converter getConvertO { r e t u r n new Convertern { puPhc Object getAsObject(FacesContext context. UlComponent component. String newValue) tnrows ConverterException { } public String getAsStrmgtFacesContext context. UlComponent component. Object value) tnrows ConverterException { }

f }

if (foundlnvalidCharacter) { FacesMessage message = new FacesMessage( "Wystąpił błąd Konwersji ". "Błędny numer K a r t y message.setSeventy(FacesMessage.SEVERltY_ERR0R). throw new ConverterException(message).

K re d y to w e j."

).

} Obiekt klasy FacesMessage reprezentuje podsumowania i szczegóły komunikatów, które można wyświetlić za pośrednictwem odpowiednich znaczników.

} javax. faces.appli cati on.FacesMessage

Prezentowane podejście jest o tyle wygodne, że umożliwia metodom odpowiedzialnym za konwersję uzyskiwanie dostępu do danych prywatnych komponentu JavaBean.

■ FacesMessage(FacesMessage.Seventy severity. String summary. String d etail) Konstruuje komunikat na podstawie przekazanej na wejściu wagi (poziom dotkliwości), podsumowania i szczegółowego opisu. Za pośrednictwem parametru wagi (seven ty) możemy przekazać stałą SEVER1 TY_ERR0R, SEVERlTY_FATAL, SEVER!TY_LNF0 lub SEVER1 TY_WARN klasy FacesMessage.

Alternatywnym rozwiązaniem jest zarejestrowanie konwertera w roli konwertera domyślnego dla klasy CreditCard (warunkiem takiego podejścia jest pewność co do możliwości jego wykorzystywania do wszystkich konwersji pomiędzy obiektami klas String i CreditCard):

■ FacesMessage(Strmg summary. String d etail)

com corejsf CreduCard com.corejsf DechtCardConverter

Konstruuje komunikat oznaczony wagą SEVERITYJMFO i reprezentujący przekazane na wejściu podsumowanie oraz szczegółowy opis.

Od tej pory nie musimy nawet wspominać o tym konwerterze w innych miejscach. Nasz konwerter będzie bowiem wykorzystywany automatycznie wszędzie tam, gdzie zostanie wykryta referencja do wartości typu CreditCard. Przeanalizujmy na przykład następujący znacznik:

■ void setSeverity(EacesMessage.Seventy severity) Ustawia określoną wagę komunikatu o błędzie. Waga może być reprezentowana przez stałą SEVERITY JRROR, SEVER1 T Y J ATAL, SEVERl TYJNFO lub SEVER1TY_WARN klasy FacesMessage.

com.mycompany.myapp.messages

Poniżej przedstawiono fragment kodu uzyskujący nazwę pakietu komunikatów: Application app = context.getApplication(); String appBundleName = app.getResourceBundle();

Przed odwołaniem się do komunikatów domyślnych powinniśmy przeszukać zasoby zawarte w tym pakiecie. I wreszcie możemy podjąć decyzję o zdefiniowaniu komunikatów obejmujących szczegółowe informacje o charakterze błędów. Możemy na przykład zasugerować użytkownikowi, który znak w numerze karty kredytowej spowodował jego odrzucenie. Okazuje się, że łańcuchy komunikatów mogą obejmować symbole zastępcze {0 }, {1} itd. Poniżej przedstawiono prosty przykład: Podany numer karty kredytowej zawiera niewłaściwy znak: {0}.

Klasę java .text .MessageFormat można wykorzystać do zastąpienia tych symboli właściwymi wartościami: Object[] pa rams = MessageFormat formatter = new MessageFormat(resource, locale), String message = formatter format(params);

3. Uzyskanie dostępu do pakietu komunikatów właściwego dla danej nazwy, ustawień regionalnych i mechanizmu ładowania klas: ResourceBundle bundle = ResourceBundle.getBundle(bundleName, locale, loader):

4. Uzyskanie ze wspomnianego pakietu komunikatów łańcucha zasobu właściwych dla danego identyfikatora: String resource = bundle.getString(resourceld),

Przedstawiony proces nie jest wolny od wad. Jego realizacja wymaga istnienia dwóch ko­ munikatów: podsumowania komunikatu i komunikatu szczegółowego. Zgodnie z konwen­ cją identyfikator zasobu właściwy dla komunikatu szczegółowego uzyskujemy przez doda­ nie do klucza podsumowania przyrostka _detai 1. Poniżej przedstawiono prosty przykład: badCreditCardCharacter=Błędny numer karty kredytowej. badCreditCardCharacter_detail=Podany numer karty kredytowej zawiera niewłaściwe znaki.

W przedstawionym przykładzie tablica params zawiera wartości, które mają zostać użyte w miejsce symboli zastępczych. (W ięcej informacji o klasie MessageFormat można znaleźć w rozdziale 10. książki Core Java™ 2, vol. 2 — Advanced Features (7th ed.)x autorstwa Caya Horstmanna i Gary’ego Cornelia). Idealnym rozwiązaniem byłoby przeniesienie odpowiedzialności za realizację tych zadań na poziom frameworku JSF. Mimo że odpowiedni kod można znałeźć wewnątrz implementacji referencyjnej, projektanci tego frameworku nie zdecydowali się na udostępnienie tego mecha­ nizmu programistom JSF .

1 Polskie wydanie: Java 2. Techniki zaawansowane. Wydanie //, Helion, 2005 — przyp. tłum.

232

JavaServer Faces Rozdział 6. ■ Konwersja i weryfikacja poprawności danych Opracowaliśmy pakiet com.corejsf.uti 1 obejmujący klasy pomocnicze, które implementują brakujące elementy funkcjonalności. Zachęcamy programistów do swobodnego korzystania z tych rozwiązań w kodzie budowanych aplikacji. Klasa com.co rejsf.u til .Messages obejmuje metodę statycznągetMessage, która zwraca obiekt klasy FacesMessage reprezentujący określoną nazwę pakietu komunikatów, identyfikator zasobu i dodatkowe parametry: FacesMessage message = com.corejsf u ti1.Messages,getMessage( "com.corejsf.messages", "badCreditCardCharacter". new Object[] { new Character(invalidCharacter) }),

Jeśli dany komunikat nie obejmuje symboli zastępczych, zamiast tablicy parametrów po­ winniśmy przekazać wartość nuli. Nasza implementacja jest zgodna z konwencją obowiązującą w świecie JSF , gdzie brakujące zasoby są zastępowane łańcuchem r?.V.identyfikator_zasobuRV.. Kod źródłowy klasy Messages przedstawiono na listingu 6.8.

Listing 6.8. Kod klasy converter2/src/java/com/corejsf/util/Messages.java 1. package com.corejsf. u t il,

2. 3. 4. 5. 6 7. 8. 9. 10.

import import import import import import import import

java.text.MessageFormat; java.util Locale; java.util.MissingResourceException; java.u ti1.ResourceBundle, javax.faces.application.Application; javax.faces.application.FacesMessage; javax faces.component.UIViewRoot; javax.faces.context.FacesContext;

11

12 publK class Messages { 13 public static FacesMessage getMessage(Stmng bundleName. S t r in g resourceld. 14 Object[ ] params) { 15 FacesContext context - FacesContext getCurrentlnstance(). 16 Application app = context.getApplication(). 17 String appBundle = app.getMessageBundle(). 18 Locale locale - geUocale(context). 19 ClassLoader loader = getClassLoader(). 20 String summary = getStrmgtappBundle. bundleName. resourceld. 21 locale, loader, params). 22 if (summary == null) summary = ■'???" + resourceld + "???". 23 S t r in g detail = getStnng(appBundle. bundleName. resourceld + "_detail". 24 locale, loader, params). 25 return new FacesMessageCsummary. detail). 26 } 27 28 P u b lic static String getString(String bundle. String resourceld. 29 Object[] params) | 30 FacesContext context = FacesContext.getCurrentlnstanceO. 31 Application app = context.getApplication(). 32 S t r in g appBundle - app.getMessageBundle(). 33 Locale locale = getLocaleicontext). 34 ClassLoader loader = - getC1assLoader( ).

35. 36. 37

}

38.

return getString(appBundle,

bundle, resourceld. locale, loader, params):

public static String getString(String bund!el, String bundle2, String resourceld, Locale locale. ClassLoader loader, Object[] params) { String resource = null, ResourceBundle bundle,

39.

40 41 42 43. 44 45. 46. 47 48. 49. 50 51. 52 53. 54. 55 56. 57. 58. 59. 60. 61.

i f (bundlel != riul 1) { bundle = ResourceBundle.getBundle(bundlel. locale, loader), i f (bundle != riul 1) try { resource = bundle.getString(resourceld), } catch (MissingResourceException ex) { } } i f (resource == nul1) { bundle = ResourceBundle.getBundle(bundle2, locale, loader), i f (bundle != nul1) try { resource = bundle.getString(resourceld), } catch (MissingResourceException ex) { } }

62. 63. 64.

i f (resource == null) return null; // brakdopasowania i f (params == null) return resource,

65. 66 67 68.

}

MessageFormat formatter = new MessageFormat(resource, locale); return formatter.format(params);

69

public static Locale getLocale(FacesContext context) f

70

Lo cale loca 1e = n u l 1.

71

UlViewRoot viewRoot - context getViewRooti ).

72 73 74 75 76

i f (viewRoot != n u l l ) loc a le - viewRoot g e t L o c a le ( ) . i f ( l o c a l e == n u l l ) l o c a le = Lo cale g e t D e f a u I t ( ) re tu rn l o c a le . f

77

public s t a t i c ClassLoader getC 1a s s L o a d e r() j

78 79 80 81 82

ClassLoader loader - thread c u r r e n t t h r e a d ( ) g e tC o n te xtC las sLo a d ert ). i f (l o ad e r == n u l l ) loader - ClassLoader g et Sy st em Class Lo ader( ). retu rn loader. } }

H H Program iści, którzy preferują stosow anie standardowych kom unikatów JSF dla K w i błędów konwersji, mogą wywołać następującą m etodę:

.

.

..

..

.... . ■.

FacesMessage message ■ =com.corejsf..u t il.Messages.getMessage( "javax.faces.Messages“ . "j avax.faces.component.üî Input.CONVERS1ON",

null); . >: .. y.. ■ ; V.

233

234

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

JavaServer Faces

m t i e x h outputText va lue="#{msgs t u i e [ "/>

7

25] ja vax.faces.context.FacesContext

8 9

■ static FacesContext getCurrentinstance!) Zwraca kontekst żądania obsługiwanego przez bieżący wątek lub wartość nul 1, jeśli wątek bieżący nie obsługuje żadnego żądania. ■ UlViewRoot getViewRoot() Zwraca komponent główny właściwy dla żądania opisywanego przez dany kontekst.



10


11 12 13

M 15 16 17


18

EHI javax. faces.component.UlViewRoot

19

■ Locale getLocaleO Zwraca ustawienia regionalne właściwe dla danego widoku.

Przykładowa aplikacja zbudowana na bazie konwertera niestandardowego W tym podpunkcie przeanalizujemy pozostałe elementy naszej kolejnej aplikacji przykładowej. Na rysunku 6.8 przedstawiono strukturę katalogów tej aplikacji. Na listingach 6.9 i 6.10 przed­ stawiono odpowiednio kod strony z formularzem wejściowym i kod strony wynikowej. Warto zwrócić uwagę na znaczniki inputText i outputText reprezentujące numery kart kredytowych, w których stosujemy dwa style wskazywania naszego konwertera niestandardowego. (Obie konstrukcje można by pominąć, gdybyśmy zarejestrowali ten konwerter jako konwerter domyślny typu CreditCard). ^ converters.war

Struktura katalogów aplikacji ilustrującej działanie niestandardoweg o konwertera

f~ £3 META-l WF I

f ifsl Util L D Messages.class

j

\

j

|

i-

\

\

\

1 I

r

Q CreditCard. class Q

CreditCardConverter.class

D PaymentBean. class -- Q messages, properties

! I



21 23 24 25. 26. 27 28. 30.

20

Rysunek 6.8.

form>

M COnvertNumper minFractlOnDigits=,2"/>

| Q faces-config.xmt Q web.xml

U D styles, css L- Q index.html I- Q index.jsp □ result.jsp__________ ___________________

Listing 6.9. Kod strony converter2/web/indexjsp_____________________________________ 1. 2. <%@ taglib uri= "http7/java.sun.com/jsf/core" prefix="f" %> 3 <%$ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4 5. 6.

Listing 6.10. Kod strony converter2/web/resultjsp 1. 2 3.

4. 5. 6. 7. 8. 9. 10 11. 12. 13. 14. 15. 16. 17

18 19 20.

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%@ taglib uri="http.7/java.sun.com/jsf/htnil" prefix="h" %> <1ink href=”styles.css" rel="stylesheet" type="text/css"/> <(rform>

21. 22.

< h : o u t p u t T e x t v a l u e = " # { m s g s . e x p i r a t i o n D a t e } "/>

235

236

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

JavaServer Faces 23. 24 25. 26 27 28 29. 30 31

39. 40. com.corejsf.messages 41 msgs 42. 43. 44.

Listing 6.12. Plik właściwości converter2/src/java/com/corejsf/messages.properties 1. badCreditCardCharacter=Błędny numer karty kredytowej. 2. badCreditCardCharacter_detail=Podany numer karty kredytowej zawiera niewłaściwy znak. {0}. 3 title=Aplikacja testująca mechanizm konwersji danych 4. enterPayment=Prosimy wpisać informacje o płatności 5. amount=Kwota 6 creditCard=Karta kredytowa 7 expirationDate=Data ważności (miesiąc/rok) 8 process=Przetwórz 9. paymentInformation=Informacje o płatnościach

Konwerter niestandardowy zdefiniowano w pliku konfiguracyjnym faces-config.xml (patrz listing 6.11). W pliku messages.properties (patrz listing 6.12) zdefiniowano komunikaty o błędach konwertera numerów kart kredytowych. I wreszcie na listingu 6.13 przedstawiono komponent JavaBean obsługujący płatności i definiujący trzy właściwości typów double, Date i CreditCard.

Listing 6.11. Plik konfiguracyjny converter2/web/WEB-INF/faces-config.xml_____________________________ 1 2
Listing 6.13. Kod komponentu converter2/src/java/com/corejsf/PaymentBean.java

xsi :schemal_ocation="http://ja v a .sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_l_2.xsd" version="1.2"> com.corejsf.messages

1. 2 3 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.

10

11. 12. 13 14. 15 16 17 18 19. 20 21. 22. 23 24 25 26. 27. 28. 29. 30. 31. 32. 33 34. 35. 36. 37 38.

/i ndex.jsp process /re su lt.jsp /result.jsp back /i ndex.jsp com.c o re jsf.Credi tCard com.corejsf.CreditCardConverter payment com.corejsf.PaymentBean session

237

package com.corejsf, import java.util.Date; public class PaymentBean { private double amount; private CreditCard card = new CreditCardC"); private Date date = new DateO, / / W łaściwość amount: public void setAmount(double newValue) { amount = newValue; } public double getAmountO { return amount, }

/ / W łaściwość card: public void setCardCCreditCard newValue) { card = newValue; } public CreditCard getCardO { return card; } / / W łaściwość date:

public void setDate(Date newValue) { date = newValue; } public Date getDateO { return date; } }

Implementacja klas niestandardowych mechanizmów weryfikacji Implementacja własnych, niestandardowych klas mechanizmów weryfikacji jest procesem dwuetapowym (podobnym do tego, który analizowaliśmy we wcześniejszej części rozdziału): 1.

Implementacja mechanizmu weryfikacji w formie klasy implementującej interfejs javax.faces.v a lidator.Validator.

2. Rejestracja tego mechanizmu w pliku konfiguracyjnym (np.faces-config.xml).

238

JavaServer Faces

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

Interfejs Val idator definiuje tylko jedną metodę:

32. 33 34 35. 36 37 38. 39 40. 41 42. 43 44. 45 46

void validate(FacesContext context, UlComponent component, Object value)

Jeśli proces weryfikacji zakończy się błędem, metoda val i date powinna utworzyć obiekt klasy FacesMessage opisujący ten błąd, a następnie utworzyć i rzucić wyjątek Val i datorExcepti on: if

( .walidacja s i ę n i e p o w i e d z i e ) {

FacesMessage message = ; message.setSeveri ty ( FacesMessage.SEVERITY_ERROR): throw new ValidatorException(message).

} Opisany proces bardzo przypomina procedurę raportowania błędów konwersji, z tą różnicą, że generuje wyjątek Val i datorExcepti on (zamiast wyjątku ConverterException).

1f (i > 0) { int d = 2 * Integer parseInt(cardNumber.substring(i - 1, i) ) . if(d > 9) d -= 9; sum += d,

} } return sum % 10 == 0;

} private static String getDigitsOnly(String s) { StringBuiIder digitsOnly = new StringBuiIder (), char c, for(int i = 0, i < s.length (), i++) { C = S charAt

47

Na listingu 6.14 przedstawiono mechanizm weryfikacji opracowany z myślą o cyfrach nu­ meru karty kredytowej i zbudowany na bazie wzoru Luhna. Na rysunku 6.9 przedstawiono stronę tej przykładowej aplikacji w działaniu. Zgodnie z konwencją opisaną w podpunkcie „Uzyskiwanie dostępu do komunikatów o błędach zapisanych w pakiecie komunikatów” wykorzystujemy do lokalizowania łańcuchów komunikatów w pakiecie komunikatów klasę pomocniczą com. corejsf u til Messages.

Listing 6.14. Kod klasy validator2/src/java/com/corejsf/CreditCardValidatorjava______________________ 1

package com c o r e j s f

2 3 4 5 6 7 o 0 9 10

import import import import

javax javax javax javax

faces faces faces faces

appiicatio n.F ac es M es sag e. component UlComponent. c o n tex t.F a c esC o n tex t. va lid a to r v a iid ato r.

import javax faces v a l i d a t o r va i id a to r E x c e p ti o n . publ ic c la s s Cre duCardVal ida to r

implements V a li d a t o r j

p u blic void v a l idate(FacesConte xt context . UlComponent component Object va lue ) { lue == null ) re turn . S t r in g cardhumber.

11 12

1 f(va

13 14

if

(v alu e mstanceo f C re du C a rd ) cardhumber = value t o S t n n g ( ) .

15

el s e cardhumber = g e t D i g u s O n ly t v a l u e t o S t r m g u ) . i f ( ! luhnCheckicardhumber)) {

16 17 18

21

FacesMessage message = com.corejsf u t i l Messages. getMessage( "com c o r e j s f messages". "badLuhnCheck". null ).

22

message se tSe ve rity(F ace sM es sa ge SEV ERirv_ERR0R)

19 20

26 27 28

1 I p r i v a t e s t a t i c boolean luh nCheck(Stnng cardhumber) { int sum = 0

29 30. 31

(i)

(C haracter

i s D i g m c ))

c h g ils O n ly

append(c).

\

\ \ return cHgitsOnly to Strin g ( ) .

|M

Rysunek 6.9.

Aplikacja testująca

Przykład błędu wykrytego z wykorzystaniem algorytmu Luhna

i

£•»*

Wycja

v

Widok

jmUSiMEM j

-ttm ija Htrtona

Zakładki

Narzędzia

Pomoc

Al fc c is

*|§f typ ||J [. ttp•''.Qcaiho«"i:iOfiii/vail.iato^rnide...idcej *

j P rosim y w pisać dane o płatności 1 Kwmta i Karta k rn h to w a

n000n

i*»«««“ 11 imiesiąaroki k] i Ptąełwętri ]

iM

i l 1l i n n f n 111?

~~.......... i (i

; 1 •'

•* " -

•»

||l Zakończono ;j ^ j Wzór Luhna (opracowany przez grupę m atem atyków w drugiej połowie lat sześć“ dziesiątych ubiegłego wieku) umożliwia weryfikację i generowanie zarówno numerów kart kredytowych, ja k i num erów ubezpieczeń społecznych stosowanych w Kanadzie. Stosując ten wzór, możemy łatwo sprawdzić, czy podana sekwencja cyfr je s t prawidłowa i czy dwie cyfry nie zostały przestawione. Więcej informacji o tym wzorze można znaleźć n a stronie internetow ej http://www.merriampark.com/anatomycc.htm. Na potrzeby dalszych eksperymentów warto podkreślić, że numer 41111111 l i i i i m je s t zgodny z tym schem atem .

throw new Va 1id a t o rE x c e p t îon(message).

23 24 25

48 49 50 51 52 53

i f

fo r ( i n t i = carclNumber.lengthO - 1: i >=0; i -= 2) { sum += In tege r p a r s e In t( c a r d N u m b e r , s u b s tr i n g (i , i + 1 ) ) ;

QQQjavax. faces, val idator. Validator ■ void v a lidate(FacesContext context. UlComponent component. Object value) Weryfikuje komponent, do którego dołączono dany mechanizm weryfikacji. W razie wystąpienia błędu weryfikacji generuje wyjątek Va 11datorExcepti on.

239

240

üavaServer Faces

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

Rejestrowanie wtasnych mechanizmów weryfikacji Skoro dysponujemy już klasą mechanizmu weryfikacji, możemy przystąpić do jego rejestracji w pliku konfiguracyjnym (np. faces-config.xml). Można to zrobić, stosując następującą kon­ strukcję składniową:

Rysunek 6.10. Struktura katalogów aplikacji przykładowej

¡3 vaiidator2.war f a META-INF j L Q MANIFEST.MF f 1 ¡¡a WEB-INF | F S3 classes ; j F £3 com j i F- d corejsf ! |

com.corejsf.CreditCard com.corejsf.Credi tCa rdValidator

Do niestandardowych mechanizmów weryfikacji możemy się odwoływać za pośrednictwem znacznika f : val i dator — w poniższym fragmencie kodu wykorzystujemy omówiony przed chwilą mechanizm weryfikacji numerów kart kredytowych:

241

\ j

Ÿ" ESI Util j '■■■■-D Messages.class

|

|

j Q

i

\

| D CreditCardConverter. class

CredltCard. class

j

|

| O CreditCardValldator. class

\

|

|

j

|

'■... D messages, properties

Q PaymentBean. class

|....|.. Q faces-config.xml O web xml i Q styles css ; D index htmi



| D index jsp • D result jsp_____________________________



Wartość atrybutu valid ato rld użyta w znaczniku f : validator musi odpowiadać identyfi­ katorowi mechanizmu weryfikacji zdefiniowanemu w pliku konfiguracyjnym. Znacznik f-val i dator wykorzystuje ten identyfikator do odnalezienia właściwej klasy, utworzenia jej egzemplarza (w razie konieczności) i wywołania metody val idate. R H W technologii JSF stosuje się odrębne przestrzenie nazw d la identyfikatorów l w i konwerterów i m echanizm ów weryfikacji. Oznacza to, że wykorzystywanie identy­ fikatora corn. corejsf. CreditCard zarówno dla konwertera J a k i mechanizm u weryfikacji nie stanowi żadnego problemu.

.

■

.

Framework JSF rejestruje trzy standardowe mechanizmy weryfikacji z następującymi identyfikatoram i: ja'vax.faces.LongRange, javax.faces.DoubleRange i javax.

^faces. Length. Pozostałe elementy naszej przykładowej aplikacji są już bardzo proste. Na rysunku 6.10 przed­ stawiono strukturę jej katalogów, natomiast na listingu 6.15 przedstawiono kod odpowiedniej strony JSF.

Listing 6.15. Kod strony validator2/web/index.jsp______________________________________________________ 1. 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. 5 6. <1ink href="styles.css" rel="stylesheet" type="text/css"/> 7. 8 9. 10. 11. 12.

13 14 15 16 17 18 19 20 2L 22 23 24 25 26 27 28. 29. 30. 31. 32. 33. 34. 35. 36 37. 38. 39.

<1-conventNumber minFractlonDigilS="2"/>
Miesiąc R c.y

¡2006

,

....

. • .i Ł.~; ,

.

['Wyślij j

Przekazywanie konwerterom atrybutów Każdy komponent interfejsu użytkownika JS F może obejmować dowolną liczbę atrybutów. Atrybuty komponentów możemy definiować za pomocą znaczników f ■attribute. Istnieje też możliwość ustawiania atrybutów dołączanych do konwertera. Nasz konwerter może następnie uzyskiwać dostęp do tak zdefiniowanych atrybutów za pośrednictwem odpowied­ niego komponentu. W tyra punkcie przeanalizujemy przykład wykorzystania atrybutów do zdefiniowania łańcucha separatora dla konwertera numerów kart kredytowych. Dołączając konwerter, należy zagnieździć znacznik f : a ttri bute w ramach znacznika kom­ ponentu:

Jeśli użytkownik wpisze błędną datę, np. 30 lutego, nasza aplikacja powinna wygenerować błąd weryfikacji i uniemożliwić przekazanie tych danych do modelu. Rozwiązaniem tego problemu jest przypisanie mechanizmu weryfikacji ostatniemu z tych komponentów. W momencie jego wywołania możemy być pewni, że poprzednie komponenty zakończyiy już przetwarzanie i przypisały stosowne wartości swoim zmiennym lokalnym. Ostatni komponent przeszedł już proces konwersji — wynik tej konwersji jest przekazywany do metody weryfikującej za pośrednictwem parametru typu ObjecL.

244

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

JavaServer Faces Opisany model wymaga oczywiście dostępu do pozostałych komponentów. Można ten ceł łatwo osiągnąć, stosując komponent wspomagający, który będzie obejmował wszystkie komponenty bieżącego formularza (patrz listing 6.16). Metodę weryfikującą można związać z tym komponentem wspomagającym w następujący sposób: public class BackingBean { private UIInput daylnput; private UIInput monthlnput; public void validateDate(FacesContext context, UlComponent component. Object value) { int d =((Integer) daylnput.getLocalValue() ) .intValueO: int m =((Integer) monthlnput.getLocalValue() ) .intValueO: int y =((Integer) value) .intValueO; if ( !isValidDate(d, m, y)) { FacesMessage message = throw new VaiidatorException(message);

} Warto zwrócić uwagę na pewną asymetrię w konstrukcji, w której uzyskujemy dostęp do ustawionych wartości. Ostatni komponent nie ustawił wartości lokalnych, ponieważ nie prze­ szedł jeszcze procesu weryfikacji. Na rysunku 6.12 przedstawiono strukturę katalogów tej aplikacji. Na listingu 6.17 przed­ stawiono kod odpowiedniej strony JS F . Warto zwrócić uwagę na właściwość converter ostatniego pola tekstowego. Innym ważnym aspektem jest użycie atrybutów binding celem związania komponentów wejściowych interfejsu użytkownika z komponentem wspomaga­ jącym JavaBean. validator3.war Q META-INF

Rysunek 6.12. Struktura katalogów analizowanej aplikacji

'

Q MANIFEST. MF

WEB-INF f - [ 3 classes | | \

f ■£3 corn f £3 corejsf util

\

j

j

|..Q BackingBean.class

■ ..Q Messages.class

!

'L.Q

messages, properties

| Q faces-config.xmf { Q web.xml

D styles.css Q index.html Q index, jsp D result.jsp

Listing 6.16. Kod komponentu vaiidator3/src/java/com/corejsf'/BackingBean.java 1. package com.corejsf:

2. 3.

import javax.faces.application.FacesMessage:

4 5. 6. 7

import javax.faces.component.UlComponent, import javax.faces.component.UlInput; import javax.faces.context.FacesContext, import javax.faces.vaiidator.VaiidatorException,

8. 9. public class BackingBean { 10 private int day: 11 private int month: 12 private int year, 13. private UIInput daylnput, 14 private UIInput monthlnput: 15 private UIInput yearlnput; 16 17. I I Właściwość day: 18. public int getDayO { return day, } 19 public void setDay(int newValue) { day = newValue; } 20. 21 // Właściwość month: 22 public int getMonthO { return month: } 23 public void setMonth(int newValue) { month = newValue: } 24. 25. // Właściwość year: 26. public int getYearO { return year, } 27 public void setYear(int newValue) { year = newValue: } 28 29. / / Właściwość daylnput: 30. public UIInput getDayInput() { return daylnput: } 31. public void setDaylnputdllnput newValue) { daylnput = newValue: } 32. 33 I I Właściwość monthlnput: 34 public UIInput getMonthInput() { return monthlnput, } 35. public void setMonthInput(UIInput newValue) { monthlnput = newValue; } 36 37 // Właściwość yearlnput: 38 public UIInput getYearInput() { return yearlnput; } 39. public void setYearlnputdlllnput newValue) { yearlnput = newValue, } 40. 41. public void vaiidateDate(FacesContextcontext,UlComponent component, 42 Object value) { 43 int d = ((Integer) daylnput. getLocal Valued) intValueO: 44. int m = ((Integer) monthlnput. getLocal Valued) .intValueO , 45. int y = ((Integer) value) intValueO, 46 47 i f ( !isValidDate(d, m, y)) { 48 FacesMessage message 49. = com.corejsf util Messages,getMessage( 50 "com.corejsf messages", "invalidDate", null): 51 message.setSeverity(FacesMessage.SEVERITY_ERROR), 52. throw new VaiidatorException(message); 53. } 54. } 55 56 private static booleanisValidDatednt d, int m, int y) { 57. i f (d < 1 || m < 1 || m> 12) return false, 58. i f (m == 2) { 59. i f (isLeapYear(y)) return d <= 29: 60. else return d <= 28:

245

246

JavaServer Faces

Rozdział 6. ■ Konwersja i weryfikacja poprawności danych

61

Pole ukryte jest reprezentowane przez pole wejściowe typu hi dden języka HTM L. Mechanizm weryfikujący jest wywoływany w chwili, w której wartość tego pola jest odsyłana na serwer. (Kluczowym warunkiem jest zdefiniowanie jakiejś wartości tego pola — w przeciwnym razie wartość odpowiedniego komponentu nigdy nie zostałaby zaktualizowana). Takie podejście gwarantuje symetrię funkcji weryfikującej, ponieważ wszystkie pozostałe komponenty in­ terfejsu użytkownika ustawiają swoje wartości lokalne przed przystąpieniem do wykony­ wania tej funkcji.

else if (rn == 4 || m == 6 II m == 9 || m == 11

62

retu rn

63

d <= 30

el se

64

66 66

retu rn

d <= 31

67

68

private sta tic return

69

boolean i sLeapYear ( int y )

y % 4 == 0 &&

( y % 400

== 0

|

| | y % 100

247

0)

70 71

W ybór niestandardow ego kom ponentu daty obejm ującego trzy pola wejściow e i pojedynczą wartość typu Date nie je s t przypadkowy — prezentowane rozwiązanie znacznie upraszcza weryfikację tego rodzaju danych. Okazuje się jedn ak, że technikę opisaną w tym podrozdziale można z powodzeniem stosować także w przypadku innych danych złożonych z wielu pól wejściowych.

Listing 6.17. Kod strony validator3/web/index.jsp Lag l ID u n =" h t tp //Java sun c om /j sf /c ore ” p r e f i x - ' T Lag l lb ur i =" ht Lp / /J a va sun com /jsf/html" p refix = ” h"

%> %>

c’t u l e x h outputText ve iu e- 'T jn sg s t it l e }"/> pane 1Grid columns-"3">



Alternatywnym rozwiązaniem jest związanie mechanizmu weryfikującego z ukrytym polem wejściowym wchodzącym w skład tego samego formularza (ale zdefmiowanym za pozostałymi polami):

Jak widać, technologia JS F oferuje rozbudowany i rozszerzalny model obsługi zadań konwersji i weryfikacji danych wejściowych. Korzystanie ze standardowych konwerterów i mechani­ zmów weryfikacji tej technologii wymaga zdefiniowania zaledwie jednego dodatkowego wiersza w kodzie strony JSF. W razie konieczności programista może bez trudu zdefiniować własną logikę bardziej złożonych procesów konwersji i (lub) weryfikacji. W rozdziale 9. dodatkowo omówimy sposób definiowania własnych, niestandardowych znaczników kon­ wersji i weryfikacji.

248

JavaServer Faces

7

Obsługa zdarzeń Aplikacje internetowe często muszą reagować na takie zdarzenia wywoływane przez użytkow­ ników jak zaznaczenie opcji menu czy kliknięcie przycisku. Nasza aplikacja może reagować na przykład na wybór kraju, w którym mieszka użytkownik, dostosowaniem ustawień regio­ nalnych i ponownym załadowaniem bieżącej strony — takie rozwiązanie powinno ułatwić zadanie użytkownikom. Metody odpowiedzialne za obsługę zdarzeń z reguły rejestrujemy dla poszczególnych kom­ ponentów interfejsu użytkownika — możemy na przykład zarejestrować metodę nasłuchu­ jącą zmian wartości dla kontrolki menu na stronie JS F :

W powyższym fragmencie kodu, wyrażenie #{forni.countryChanged} odwołuje się do metody countryChanged komponentu nazwanego form. Wspomniana metoda jest wywoływana przez implementację JS F bezpośrednio po tym, jak użytkownik zaznaczy którąś z opcji tak zdefi­ niowanego menu. Dokładne określenie momentu tego wywołania jest jednym z zagadnień, którymi zajmiemy się w tym rozdziale. Technologia JavaServer Faces obsługuje trzy rodzaje zdarzeń: ■ zdarzenia zmiany wartości; ■ zdarzenia akcji; ■ zdarzenia fazy. Zdarzenia zmiany wartości są generowane przez komponenty wejściowe interfejsu użytkow­ nika (takich jak h: inputText, h:selectOneRadio i h:selectManyMenu) w reakcji na zmiany wartości tych komponentów. Zdarzenia akcji są generowane przez komponenty poleceń (takie jak h: commandButton i h: commandLi nk) w momencie aktywacji odpowiedniego przycisku lub łącza. Zdarzenia fazy standardowo są generowane przez cykl życia aplikacji JS F . Oznacza to, że jeśli chcemy

250

JavaServer Faces

Rozdział/. ■ Obsługa zdarzeń

obsługiwać tego rodzaju zdarzenia, musimy opanować podstawy tego cyklu życia. Właśnie tym problemem zajmiemy się w pierwszej kolejności.

251

Obiekty nasłuchujące zdarzeń mogą wpływać na cykl życia aplikacji JSF na jeden z trzech sposobów: 1. um ożliwiając norm alną kontynuację cyklu życia; 2. wywołując m etodę FacesContext. renderResponse(), aby pom inąć pozostałe fazy cyklu życia z wyjątkiem fazy wizualizacji odpowiedzi;

Zdarzenia cyklu życia W aplikacjach JavaServer Faces żądania są przetwarzane przez implementację JS F z wyko­ rzystaniem serwletu kontrolera, który z kolei odpowiada za zarządzanie cyklem życia JSF . Schemat cyklu życia JS F przedstawiono na rysunku 7.1.

Zakończono o d p o w ie dź

Z a kończono o d p o w ie dź

Î

r-------{>

Stosowanie wartości żądania

Przywrócenie

widoku

O

-o

l & S iu . j

Wizualizacja odpowiedzi

Z a kończono o d p o w ie dź

■

-----

o-

Aktualizacja wartości m odelu

W ywołanie aplikacji

B łędy ko n w ersji/w izua liza cja o dp o w ie dzi

—

Przykład użycia metody FacesContext. renderResponse() można znaleźć w podrozdziale „Kom ponenty bezpośrednie” w dalszej części tego rozdziału.

Zdarzenia zmiany wartości

Weryfikacja

W izualizacja o dp o w ie dzi

Z a kończono o dp o w ie dź • o

3 . wywołując m etodę FacesContext. responseComplete(), aby pom inąć wszystkie pozostałe fazy cyklu życia.

;

Błędy w e ryfika cji lu b ko n w ersji/w izua liza cja od p o w ie d zi

Komponenty interfejsu użytkownika aplikacji internetowej często są ze sobą powiązane rozmaitymi zależnościami. Na przykład w aplikacji przedstawionej na rysunku 7.2 tekst etykiety Stan zależy od wartości wybranej w Kraj. Zdarzenia zmiany wartości (generowane przez komponenty wejściowe bezpośrednio po zakończeniu weryfikacji nowych wartości) umożliwiają synchronizację komponentów zależnych.

Rysunek 7.2.

a i łgl i

!f!> Przykład wykorzystania zdarzeń zmiany wartości - Mozilla Rretox

Przykład użycia zdarzeń zmiany wartości

Plik

Ectycja

Widok

-

9

Historia

&

f

Zakładki

i '

Narzędzia

P om oc

££ O

l~'ttp-n|ocalhost:8080/ !

Google___

Proszę wpisać adres Adíes i

Rysunek 7.1. Cykl życia JSF

Pinc

tdycja

Widok

Historia

Zakładki h—p

Cykl życia aplikacji JS F obejmuje następujące fazy: ■ przywrócenie widoku;

Narzędzia

Pomoc

Miasto !

Kraj

; Stany Zjednoczone jr j:

*o c a tH05t: 808 0/ j *

Son g la___j | g | j t

Proszę wpisać adres

Wyślij .adres j

■ stosowanie wartości żądania;

Adres

!

Miasto

i

Prowincja j _ K ra j

■ weryfikacja danych;

! Kanada

IZB

f Wyślij ad;e¿~j

■ aktualizacja wartości modelu;

I Zakończono

■ wywołanie aplikacji; ■ wizualizacja odpowiedzi. Począwszy od fazy stosowania wartości żądania, implementacja JS F może generować zda­ rzenia i dodawać je do kolejki zdarzeń. Po zakończeniu wszystkich faz następujących po fazie stosowania wartości żądania implementacja JS F rozsyła zakolejkowane zdarzenia do zare­ jestrowanych obiektów nasłuchujących. Zdarzenia i powiązane z nimi obiekty nasłuchujące będą przedmiotem naszych rozważań w tym rozdziale.

Aplikacja przedstawiona na rysunku 7.2 wiąże metodę nasłuchującą zmian wartości z menu

Kraj i wykorzystuje atrybut onchange do wymuszenia wysyłania całego formularza po każdej zmianie wartości tego menu:



Kiedy użytkownik wybiera kraj ze wspomnianego menu, następuje wywołanie funkcji submi t języka JavaScript, które z kolei powoduje wysłanie całego formularz i w konsekwencji

252

Rozdział 7. ■ Obsługa zdarzeń

JavaServer Faces wywołanie cyklu życia JS F . Po zakończeniu fazy weryfikacji implementacja JS F wywołuje metodę countryChanged komponentu JavaBean nazwanego form. Metoda countryChanged zmienia ustawienia regionalne widoku zgodnie z nową wartością wybraną z menu Kraj : private static String US = "Stany Zjednoczone": public void countryChanged(ValueChangeEvent event) { FacesContext context = FacesContext,getCurrentInstance();

¡ 3 valuechange.war ^ £3 META-INF

Rysunek 7.3. Struktura katalogów aplikacji ilustrującej zdarzenia zmiany wartości

|

| \ S |

if (US.equals((String) event.getNewValue())) context.getViewRoot( ) .setFocale(Focale.US); else context.getViewRoot( ) ,setFocale(Fócale.CANADA),

1

QBD javax.faces.event.ValueChangeEvent

Zwraca komponent wejściowy, który wywołał dane zdarzenie. ■ Object getNewValue() Zwraca nową wartość danego komponentu wejściowego (już po jej konwersji i weryfikacj i). ■ Object getOldVa 1ue() Zwraca poprzednią wartość danego komponentu.

j

*

|.Q

RegisterForm.class

j

;

I.D

messages.properties

|

!

|.Q

messages_en_CAproperties

I

j

'■.Q

messages_en_US.properties

|

1

Q faces-config.xml

|

'■

D web.xml

\

D index htrnl

'

D index jsp________________________________

Listing 7.1. Kod strony valuechange/web/index.jsp 1



2

ta g lib

u r i= " h t t p : / / j a v a .s u n .c o m / js f/ c o re " p r e f i x ^ " f"

%>

3

ta g h b

u n =" h t t p : / / j a v a . s u n . c o n i / j s f / h t i r i l " p r e f i x = - " h "

%>

4 5

< f •v ie w >

6

< 1 1 nk h r e f - " s t y l e s . c s s "

7

< tiU e >

8

■ Ul Component getComponentO

f* t 3 com ( 3 corejsf

j Q st'y4es.css

} Tak jak się dzieje w przypadku wszystkich metod nasłuchujących zmian wartości, także metoda zdefiniowana powyżej otrzymuje na wejściu obiekt zdarzenia zmiany wartości. Na­ sza metoda wykorzystuje ten obiekt do uzyskania referencji do nowej wartości komponentu interfejsu użytkownika. Klasa Val ueChangeEvent rozszerza klasę FacesFvent (obie należą do pakietu javax. faces .event). Poniżej wymieniono i krótko opisano najczęściej stosowane metody tych klas:

'.....Q MANIFEST.MF

f C3 WEB-INF | f classes

9 10


r e l= " s iy le s h e e t " ty p e - " t e x t /css"/>

v a lu e= "# lm s g s .w in clo w T itlei"/ >

< / L 1 11 e>

11 12



13

< h :outp utT ext

14

15



16

va lu e= "# {m sg s.p a g eT it l e } "

s ty le C la s s = "e m p h a s is "/ >

< h : pane 1G r i d c o l u m n s = " 2 " >

17

< h :outp uiTe xt

18


19

inp u tT e xt

v a lu e = " # { m s g s .s tr e e tA d d r e s s P r o m p t}"/> id= "streetA d duess"

v a lu e = "# {fo rm .s tre e iA d d re s s }"

r e q u ired = "true"/>

20

M javax.faces.event.FacesEvent ■ voidqueueO Umieszcza dane zdarzenie w kolejce celem jego przekazania na końcu bieżącej fazy cyklu życia. ■ Phaseld get Phase 1d()

21


22


■ void setPhaseld(Phaseld) Ustawia identyfikator fazy właściwy dla fazy, w trakcie której przekazano dane zdarzenie.

24 25


v a lu e = " # { m s g s . s t a i e P r o m p t }"/>

v a lu e - "# !fo rm .s ta te }"/ >

26 27

< h : O u t p u t T e x t va 1u e = " # ! m s g s . C O u n t r y P r o m p t } " / >

28 < h:selectO neM enu

v a lu e = "# {fo rm .c o u n try }"

30

o nchange= "subm u()"

31

v a lu eC h a n g e L is ten er= "# {fo nii.countryC hanged}">

32 33

< f- selectIte m s



35

37.

va 1u e = " # ! f o r m . c o u n t r y N a m e s } " / >

< /h:select0 neM en u>

34

36

Strukturę katalogów aplikacji z rysunku 7.2 przedstawiono na rysunku 7.3. Kod źródłowy tej aplikacji przedstawiono na listingach od 7.1 do 7.5.

v a l u e = " # { r i i s g s . c i ty P r o m p t } " / >

23

29

Zwraca identyfikator fazy właściwy dla fazy, w której przekazano dane zdarzenie.

id= "c lty P ro m p t"

v a lu e - "# !fo rm .c ity }"/>



< / h :fo rm >

253

254

Rozdział 7. ■ Obsługa zdarzeń

JavaServer Faces 51. 52. 53. 54. 55. 56 }

38 39 40

Listing 7.2. Kod klasy valuechange/src/java/com/corejsf/RegisterFormjava 1 package com.corejsf, 3 import java.util.ArrayList. 4 import java.util.Collection. 5 import java.util.Locale: 6 import javax.faces.context.FacesContext, 7 import javax.faces.event.ValueChangeEvent: 8 . import javax.faces.model.Select Item, 9 10. public class RegisterForm { 11 private String streetAddress: 12. private String city, 13 private String state: 14. private String country, 15. 16. private static final String US = "Stany Zjednoczone", 17 private static final String CANADA = "Kanada", 18. private static final StringF] COUNTRY_NAMES = { US, CANADA }; 19. private static ArrayFist countryltems = null, 20

// Właściwość countryNames: public Collection getCountryNames() { i f (countryltems == null) { countryltems = new ArrayList(): for (int i = 0; i < COUNTRY_NAMES.length, i++) { countryltems,add(new SelectItem(COUNTRY_NAMES[i] ) ) , } } return countryltems: }

I I Właściwość streetAddress: public void setStreetAddress(String newValue) { streetAddress = newValue, } public String getStreetAddress() { return streetAddress: }

I I Właściwość city: public void setCity(String newValue) { city = newValue, public String getCityO { return city: } //

}

Listing 7.3. Plik konfiguracyjny valuechange/web/WEB-INF/faces-config.xml

2

21 22 23. 24 25 26 27. 28. 29 30. 31. 32. 33. 34. 35. 36. 37. 38. 39 40 41. 42 43. 44 45. 46 47 48. 49. 50.

i f (US.equals( (String) event.getNewValueO)) context.getViewRoot( ) ,setLocale(Locale.US), else context.getViewRoot( ) ,setLocale(Locale.CANADA).

}

Właściwość state:

public void setState(String newValue) { state = newValue; } public String getStateO { return state: } / / Właściwość country:

public void setCountry(String newValue) { country =newValue: } public String getCountryO { return country; } public void countryChanged(ValueChangeEvent event) { FacesContext context = FacesContext,getCurrentInstance():

1 . 2 .
6 7

8 9

10 11 12

xml ns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_l 2 .xsd" version="l,2 "> com.corejsf messages msgs

13 14 15 form 16 com.corejsf Regi sterForm 17 session 18 19

Listing 7.4. Plik właściwości valuechange/src/javaj/com/corejsf/messages_en_US.properties 1 . windowTitle=Przykład wykorzystania zdarzeń zmiany wartości 2 . pageTitle=Proszq wpisać adres

Q O 4. 5. 6. 7.

streetAddressPrompt=Adres cityPrompt=Miasto statePrompt=Stan countryPrompt=Kraj 8 submit=Wyśli j adres

Listing 7.5. Plik właściwości valuechange/src/java/com/corejsf/messages_en_CA.properties 1 . windowTitle=Przykład wykorzystania zdarzeń zmiany wartości 2 pageTitle=Proszę wpisać adres 3 4 5. 6. 7. 8.

streetAddressPrompt=Adres cityPrompt=Miasto statePrompt=Prowi ncja countryPrompt=Kraj submit=Wyślij adres

255

256

JavaServer Faces

Rozdział 7. ■ Obsługa zdarzeń

Zdarzenia akcji Zdarzenia akcji są wywoływane przez komponenty poleceń (przyciski, łącza itp.) w reakcji na aktywowanie tych komponentów. W podrozdziale „Zdarzenia cyklu życia” wspomniano, że zdarzenia akcji są generowane w trakcie trwania fazy wywołania aplikacji, a więc pod koniec cyklu życia JSF . Metody nasłuchujące zdarzeń akcji z reguły wiążemy z komponentami poleceń interfejsu użytkownika w kodzie stron JSF . Możemy na przykład dodać odwołanie do takiej metody do znacznika definiującego łącze:

Komponenty poleceń wysyłają żądania bezpośrednio po swojej aktywacji, stąd brak koniecz­ ności dodatkowego wykorzystywania atrybutu onchange do wymuszania wysyłania formu­ larza (jak w przypadku komponentów wejściowych i zdarzeń zmiany wartości opisanych w podrozdziale „Zdarzenia zmiany wartości” ). Kiedy aktywujemy przycisk lub łącze, formularz, do którego ta kontrolka należy, jest automatycznie wysyłany na serwer, gdzie implementacja JS F generuje kolejno zdarzenia akcji.

Kiedy użytkownik klika twarz prezydenta, nasza aplikacja przenosi go na stronę JS F obej­ mującą informacje o wskazanym prezydencie. Warto pamiętać, że opisanych zachowań nie da się zaimplementować z wykorzystaniem samej akcji — akcja może powodować nawigację do właściwej strony, ale nie może tej strony zidentyfikować, ponieważ nie dysponuje żadną wiedzą o przycisku reprezentowanym przez obraz, ani o fakcie kliknięcia przycisku myszy. Aplikacja przedstawiona na rysunku 7.4 wykorzystuje przycisk z obrazem zdefiniowany w następujący sposób:

Kiedy użytkownik klika fragment reprezentujący wybranego prezydenta, metoda nasłuchująca, która ma dostęp do współrzędnych kursora w chwili kliknięcia, wybiera właściwego prezy­ denta (którego biografia zostanie wyświetlona na kolejnej stronie). Ponieważ jednak metoda nasłuchująca nie może decydować o nawigacji, ogranicza się do umieszczenia wyniku wska­ zującego na właściwego prezydenta w polu obiektu: public class Rushmore { private String outcome; private Rectangle washingtonRect =new Rectangle(70,30,40,40); private Rectangle jeffersonRect =new Rectangle(115,45,40,40); private Rectangle rooseveltRect =new Rectangle(135,65,40,40); private Rectangle lincolnRect =new Rectangle(175,62,40,40);

Metod nasłuchujących akcji w żadnym razie nie należy mylić z samymi akcjami. Najkrócej rzecz ujmując, akcje projektuje się z myślą o logice biznesowej i są uwzględniane w proce­ sie obsługi nawigacji. Metody nasłuchujące akcji z reguły odpowiadają za funkcjonowanie logiki interfejsu użytkownika i jako takie nie mają wpływu na obsługę nawigacji.

public void 1isten(ActionEvent e) { FacesContext context = FacesContext,getCurrentInstance(); String clientld = e.getComponent() .getClientld(context); Map requestParams = context.getExternalContext(). getRequestParameterMap();

Metody nasłuchujące akcji w niektórych przypadkach współpracują z akcjami (np. w sytuacji, gdy akcje wymagają informacji o interfejsie użytkownika). Na przykład aplikacja przed­ stawiona na rysunku 7.4 wykorzystuje akcję i metodę nasłuchującą akcji do reagowania na zdarzenia klikania przyciskiem myszy przechodzeniem do określonej strony JSF .

Rysunek 7.4. Aplikacja prezentująca Mount Rushmore

lĘl Naje i metody £“* -idycj» gWiaok

4P1

fiłefo* | N a r z ę d z i a

'I

int x = new Integer((String) requestParams,get(clientld + " .x")).intValueO ; int y = new Integer((String) requestParams,get(clientld + " .y")).intV alu eO ; outcome = n u ll. if (wash!ngtonRect.contains(new Po m tU .y))) outcome = "Washington".

0 "L l§L L JIL j komoę

®®®5'^ii'

257

JŁ 2- SÉ

if (jeffersonRect,contains(new Point(x.y))) outcome = "jefferson".

Aby u?yskuć więcej informacji o prezydencie, kliknijjego rzeźbę.

if UooseveltRect.contains(new Po intu.y ))) outcome = "rooseveli". if (1 mcolnRect. conta ms (new PomL(x.y))) outcome = "lm coln". http^'ocalnostiSOSO/taoDeapane/’naex.race' Zakończono

}

jThomas Jefferson! jTheodore Rooseyelti ¡AbrahamLincolnj

S

George Washington był pierwszym prezydentem Stanów Zjednoczonych. Urodził się w roku 1732 w stanie Wirginia. W roku 1775 został mianowany naczelnym wodzem Armii Kontynentalnej. Sześć lat później zmusił do złozema kapitulacji Charlesa Cornwalhsa pod Yorktown. Urząd prezydenta Stanów Zjednoczonych objął 30 kwietnia 17W roku.

Akcja związana z danym przyciskiem wykorzystuje tę wartość do określenia kierunku nawigacji: public String act O { return outcome. 1

258

JavaServer Faces

Rozdział 7. ■ Obsługa zdarzeń

Warto mieć na uwadze, że implementacja JS F zawsze wywołuje metody nasłuchujące akcji przed samymi akcjami.

19

21 Technologia JavaServer Faces wymusza na programistach oddzielanie logiki inter­ fejsu użytkownika od logiki biznesowej przez eliminowanie możliwości uzyskiwania przez akcje dostępu do zdarzeń i komponentów, które te zdarzenia generują. W przed­ stawionym przykładzie akcja nie m a dostępu do identyfikatora klienckiego kom ponen­ tu, który wygenerował dane zdarzenie, czyli informacji niezbędnej do uzyskania współ­ rzędnych kursora myszy z param etrów żądania. Ponieważ akcja nie dysponuje żadną wiedzą o interfejsie użytkownika, kompletna implementacja wymaga od nas uzupełnienia prezentowanego modelu o m etodę nasłuchującą. Strukturę katalogów aplikacji z rysunku 7.4 przedstawiono na rysunku 7.5. Kod źródłowy tej aplikacji przedstawiono na listingach od 7.6 do 7.13. J 3 ru sh m o re.w ar

Rysunek 7.5.

f P

Struktura katalogów przykładowej aplikacji

META-INF D MANIFEST. MF WEB-INF

j

f- p j

f- p

|

|

i

;

\

\

classes

f -p

com

F f l co rejsf i..D L- Q

\

Rush more, class m e ssag es.p ro p e rtie s

\.....Q faces-config.xm t

j

!..... Q w e b .x m l

r

Q

j

Q

index, ht.ml

j

Q

m o untrushm ore.jp g

styles, css

j -- Q

in d e x .js p

'

Je ffe rso n .jsp

Q

1 0 lincQln.jsp

j~ D roo sevelt.jsp L- D Washington, js p _______________________

action="-#{rushmore navigatef'/>

20 22 23





listing 7.7. Kod strony rushmore/web/lincoln.jsp 1 2 3 4

Lag 1ib uri =' h t t p :/ / j a v a sun com/jsf/core" p r e f i x - ' T %> t a g l i D uri= 'hL Lp //java Sun com/jsf/html" p r e f i x - ' h ' 1 %>

5



57. 8 9.

<1 ink hreK'sty les.css" re I ="sty lesneet" type- 1text/css" />

10 11.

12 .

13 14 16.

1/ 19.

20 22. ${msgs. i ndexLi rikText} 23. 24.

25. 26. 27. 28.

Listing 7.6. Kod strony rushmore/web/index.jsp

Listing 7,8. Kod strony rushmore/web/jefferson.jsp 2. 3. 4. 5. 6. 7. 8. 9. 10 .

<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> taglib uri="http://Java.sun.com/jsf/html" prefix="h" %> <1 ink href="styles.css" rel="stylesheet" type="text/css"/>

11.

12 . 13. 14. 15 16 17. 18.


1 . 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" 3. 4. 5.

6 7. 8.

%>

taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <1 ink href="styles.css" rel="stylesheet" type="text/css"/> ${msgs.jeffersonWi ndowTitle}

9.

10 . 11. 12. 13. 14. 15. 16. 17.

259

260

r

üavaServer Faces 18. 20. ${msgs.indexLinkText} 21. 22 .

23. 24. 25. 26.

Listing 7.9. Kod strony rushmore/web/rooseveltjsp 1 . 2. taglib uri="http;//java.sun.com/jsf/core" prefix="f" £> 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. 5. 6. 7. 8. 9. 10 .

<1 i nk href="styles.css" rel="stylesheet" type="text/css"/>

11.

12 .

13. 14. 16.

17 19.

20. 22. ${msgs indexLinkText} 23. 24.

25. 26. 27. 28.

Listing 7.10. Kod strony rushmore/web/Washington._¡sp 1 . 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" 4. 5. 6. 7. 8. 9. 10 .

<1 i nk href="styles.css" rel="stylesheet" type="text/css"/>

11.

12 . 13.

%> %>



Rozdział 7. ■ Obsługa zdarzeń 14. 16

1/ 19.

20. 22 . ${msgs.indexLinkText} 23. 24.

25. 26. 27. 28

Listing 7.11. Kod klasy rushmore/src/java/com/corejsf/RushmoreJava 1 . package com.corejsf; 2. 3. 4. 5. 6. 7.

import import import import import

java.awt.Point; java.awt.Rectangle; java.util.Map; javax.faces.context.FacesContext; javax.faces.event.ActionEvent,

8. 9. public class Rushmore { 10. private String outcome = null; 11. private Rectangle washingtoriRect = new Rectangle(70, 30, 40, 40); 12. private Rectangle jeffersonRect = new Rectangle(115, 45, 40, 40); 13. private Rectangle rooseveltRect = new Rectangle(135, 65, 40, 40); 14. private Rectangle lincolnRect = new Rectangle(175, 62, 40, 40); 15. 16. public void handleMouseClick(ActionEvent e) { 17. FacesContext context = FacesContext,getCurrentInstance(); 18. String clientld = e.getComponentO.getClientld(context); 19. Map requestParams = context.getExternal Context0 .getRequestParameterMapO; 20. 21. int x = new Integer((String) requestParams.get(clientld + ".x ")) 22 . . intValueO ; 23. int y = new Integer( (String) requestParams,get(clientld + ".y ")) 24. .intValueO ; 25. 26. outcome = nul 1 ; 27. 28. i f (washingtonRect.contains(new Point(x, y ))) 29. outcome = "Washington"; 30. 31. i f (jeffersonRect.contains(new Point(x, y ))) 32. outcome = "jefferson"; 33. 34. i f (rooseveltRect.contains(new Point(x, y ))) 35. outcome = "roosevelt"; 36. 37. i f (lincolnRect.contains(new Point(x, y ))) 38. outcome = "1incoln"; 39. }

261

262

Rozdział 7. ■ Obsługa zdarzeń

JavaServer Faces 40 41 public String navigateO { 42 return outcome, 43. } 44 }

Listing 7.12. Plik konfiguracyjny rushmore/web/WEBANF/faces-config.xml 1 2
5 6 7. 8. 9 10 . 11.

12 13 14. 15. 16. 17 18. 19 20.

21 22 .

xmlns;xsi="http;//www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http;//Java.sun.com/xml/ns/javaee/web-facesconfi g_l_ 2 .xsd" version="1 . 2 "> com.corejsf,messages msgs index /index.jsp /index.jsp washi ngton /washington.jsp jefferson /jefferson.jsp roosevelt /roosevelt.jsp li ncoln /lincoln.jsp

23 24 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35 36. 37 38. 39. 40 41. 42 rushmore 43. com.corejsf.Rushmore 44. session 45. 46 47.

263

Listing 7.13. Plik właściwości rushmore/src/java/com/corejsf/messages.properties_________ 1 instruct!'ons=Aby uzyskać więcej informacji o prezydencie, kliknij jego rzeźbę

2. 3 indexWindowTitle=Akcje i metody nasłuchujące akcji 4. i ndexLi nkText=Powrót... 5. jeffersonlAlindowTitle=Prezydent Jefferson 6 rooseveltWindowTitle=Prezydent Roosevelt 7. lincolnWindowTitle=Prezydent Lincoln 8. washingtonWindowTitle=Prezydent Washington 9. 10. jeffersonPageTitle=Thomas Jefferson 11 rooseveltPageTitle=Theodore Roosevelt 12. lincolnPageTitle=Abraham Lincoln 13 washingtonPageTitle=George Washington 14. 15. jeffersonTabText=Jefferson 16. rooseveltTabText=Roosevelt 17. lincolnTabText=Lincol n 18. washingtonTabText=Washi ngton 19 20. lincolnDiscussion=Prezydent Lincoln przeszedł do historii jako Wielki \ 21. Emancypator, ponieważ w ogromnym stopniu przyczynił się do zniesienia \ 22. niewolnictwa na terenie Stanów Zjednoczonych. Urodzony w 1809 roku wychował \ 23 się w biednej rodzinie w stanie Kentucky. Na urząd prezydenta został wybrany \ 24. w roku 1860. Zginął w zamachu w 1865 roku z rąk Johna Wilkesa Bootha. 25. 26. washingtonDiscussion=George Washington był pierwszym prezydentem Stanów \ 27. Zjednoczonych. Urodził się w roku 1732 w stanie Wirginia. W roku 1775 został \ 28. mianowany naczelnym wodzem Armii Kontynentalnej Sześć lat później \ 29. zmusił do złożenia kapitulacji Charlesa Cornwall isa pod Yorktown Urząd \ 30 prezydenta Stanów Zjednoczonych objął 30 kwietnia 1789 roku. 31. 32. rooseveltDiscussion=Theodore Roosevelt był 26 prezydentem Stanów Zjednoczonych \ 33. Został prezydentem w roku 1901 po zamachu na prezydenta McKinleya. Urząd \ 34. prezydenta objął w wieku 42 lat i przeszedł do historii jako najmłodszy \ 35 prezydent w historii Stanów Zjednoczonych. 36. 37. jeffersonDiscussion=Thomas Jefferson, trzeci prezydent Stanów Zjednoczonych, \ 38. urodził się w roku 1743 w stanie Wirginia. Jefferson był znany z doskonałych \ 39. przemówień. W roku 1785 objął urząd ministra ds. Francji, na którym zastąpił \ 40. Benjamina Franki i na. W roku 1796 Jefferson niechętnie zgodził się kandydować \ 41. na urząd prezydenta, ale przegrał wybory zaledwie trzema głosami. Prezydentem \ 42 Stanów Zjednoczonych został w 1801 roku i pełnił ten urząd przez 8 lat

Znaczniki metod nasłuchujących zdarzeń Do tej pory dodawaliśmy do komponentów interfejsu użytkownika metody nasłuchujące akcji i zmian wartości odpowiednio za pomocą atrybutów actionListener i valueChangeListener. Okazuje się jednak, że metody nasłuchujące można wiązać z komponentami także za pomocą następujących znaczników:

264

JavaServer Faces

Rozdział 7. ■ Obsługa zdarzeń

■

f :actionl_istener

■

f :valueChangeLi stener

265


actionListener="#{rushmore.handleMouseClick)" acti on="#{rushmore.navi gate}"/>

Znaczniki f:actionListener i UvalueChangeListener Znaczniki f : a c ti onLi stener i f: val ueChangeLi stener są odpowiednikami atrybutów actionListener i val ueChangeLi stener. Na przykład menu z listingu 7.1 można by równie dobrze zdefiniować w następujący sposób:
v a l u e = "# {form .co u n try}"

onchang e= "sub m it()"

valueChangeLi stener="#{form.countryChanged}"> < f; s e le c tIte m s

v a l u e = "# {fo rm . countryNam es}"/>



Alternatywnym rozwiązaniem byłoby użycie znacznika f: val ueChangeLi stener w ramach następującej konstrukcji: < h : s e l ec tO ne M en u v a l u e = " # { f o r m . c o u n t r y } " o n c h a n g e = " s u b m i t ( ) " >

< f •s e l e c t I t e m s

v a l u e = "# {fo rm . countryNam es}"/>





Klasy nasłuchujące akcji muszą implementować interfejs ActionListener definiujący metodę processAction. Oznacza to, że dla powyższego fragmentu kodu implementacja JS F wywoła metodę RushmoreLi stener .processAction bezpośrednio po aktywacji (kliknięciu) przycisku z obrazem. Stosując wiele znaczników f: actionLi stener lub f: val ueChangeLi stener, możemy zdefi­ niować wiele klas nasłuchujących dla pojedynczego komponentu interfejsu użytkownika. Możemy na przykład dodać jeszcze jedną metodę nasłuchującą akcji do zdefiniowanego wcześniej przycisku polecenia:



Prezentowane znaczniki mają jedną zasadniczą przewagę nas stosowanymi wcześniej atry­ butami — um ożliwiają nam wiązanie pojedynczego komponentu z wieloma metodami nasłuchującymi. Warto zwrócić uwagę na różnicę dzielącą wartość przypisaną atrybutowi val ueChangeLi stener od wartości przypisanej atrybutowi value znacznika f : val ueChangeLi stener w powyższym kodzie. W pierwszym przypadku mieliśmy do czynienia z wyrażeniem reprezentującym metodę, w drugim przypadku odwołujemy się do klasy Javy. Klasę wskazaną w powyższym fragmencie kodu można by zaimplementować w następujący sposób: Count r y L i s tener implements ValueChangeListener { p r i v a t e s t a t i c f in a l S t r in g US - " S t a n y Z j e d n o c z o n e " .

p u b lic

Zamiast wskazywać metody nasłuchujące zdarzeń akcji za pośrednictwem atrybutu action ^ L is te n e r, możemy użyć znacznika f:actio n Listen er:

cla ss



W powyższym fragmencie kodu klasa ActionLogger pełni funkcję prostego mechanizmu nasłuchiwania akcji, którego funkcjonowanie ogranicza się do rejestrowania zdarzeń akcji. Jeśli dla pojedynczego komponentu zdefiniujemy wiele klas nasłuchujących (jak w powyższym fragmencie kodu), odpowiednie metody będą wywoływane w następującej kolejności: ■ metoda nasłuchująca wskazana za pośrednictwem atrybutu; ■ metody klas nasłuchujących wskazanych za pośrednictwem znaczników (w kolejności deklaracji).

public void processValueChange(ValueChangeEvent event) { FacesContext if

context

= FacesContext

( U S . e q u a 1s ( ( S t r i n g ) context

g e tC u rre n tIn s ta n c e d .

e v e n t . g e t N e w V a 1u e ( ) ) )

g etV iew R o o t( )

s e tL o ca le (L o ca le .u S ),

else c o n te x t.g e tV ie w R o o t( ) .s e tL o c a le (L o c a le .C A N A D A ).

Podobnie jak wszystkie obiekty nasłuchujące wskazywane w ramach znacznika f : valueChange ^Listener, także powyższa klasa musi implementować interfejs Val ueChangeLi stener. Nasza klasa definiuje tylko jedną metodę: void processValueChange(ValueChangeEvent). Znacznik f : actionL i stener jest odpowiednikiem znacznika f : val ueChangeLi stener stoso­ wanym dla mechanizmów nasłuchiwania akcji. Za pośrednictwem atrybutu type tego znacz­ nika należy zdefiniować nazwę klasy implementującej interfejs ActioriLi stener. Poniżej przedstawiono nową wersję definicji przycisku z listingu 7.6:

W ielu program istów nie rozumie, dlaczego za pośrednictwem atrybutów acti on ^ L i stener i vał ueChangeLi stener należy bezpośrednio wskazywać m etody na­ słuchujące, podczas gdy znaczniki f: acti onLi stener i f wal ueChangeLi stener wska­ zuj ą na klasy obejm ujące tego rodzaju metody. Okazuje się, że ta oczywista niezgodność atrybutów i znaczników m echanizm ów nasłuchiwania wynika z-przeoczenia grupy eksperckiej pracującej nad standardem JSF.

" I

Komponenty bezpośrednie W podrozdziale „Zdarzenia cyklu życia” we wcześniejszej części tego rozdziału wspomniano, że zdarzenia zmiany wartości zwykle są wywoływane po fazie weryfikacji, natomiast zda­ rzenia akcji z reguły są wywoływane po fazie wywołania aplikacji. W większości przypadków

266

Rozdział 7. ■ Obsługa zdarzeń

JavaServer Faces takie działanie jest jak najbardziej pożądane. Zwykle chcemy być informowani o zmianach wartości tylko wtedy, gdy nowe wartości są poprawne, natomiast wywołań akcji oczekujemy po przekazaniu wszystkich nadesłanych wartości do modelu.

Rysunek 7.7. Przykład niechcianej weryfikacji

ł|§/ Przykład wykorzystania zdarzeń zmiany wartośd - Mozilł^ F?relbx Plik

fcaytja

Wictok

Historia

Zakładki

Narzędzia

%

267

.

Pomoc

* # Q S rij-P ' Proszę wpisać adres

Zdarza się jednak, że generowania zdarzeń zmiany wartości lub akcji oczekiwalibyśmy ra­ czej na początku cyklu życia, aby pominąć fazę weryfikacji danych udostępnianych przez jeden lub wiele komponentów interfejsu użytkownika. Potencjalne uzasadnienie takiego podejścia można znaleźć w punkcie „Stosowanie bezpośrednich komponentów wejściowych" (w dalszej części tego podrozdziału) oraz w punkcie „Pomijanie procesu weryfikacji" (w roz­ dziale 6.). W pierwszej kolejności skoncentrujemy się na analizie mechanizmu umożliwia­ jącego dostarczanie zdarzeń bezpośrednich (patrz rysunek 7.6).

:

Akcje bezpośrednie: 1. Sygnał d ia m e to d nasłuchujących a kcji w yyw w oołanie ła n ie a kcji 2.i W

i Bezpośrednie p o la wejściowe: I 1. Konwersja i w eryfikacja zrm an w artości I 2. Sygnał d la m e to d nnasłuchujących asłuchuj

Przywrócenie 1 w id oku f

I

Zakończono odp o w ie dź

Zakończono o dpow iedź

......-ł>

r............

Stoso w anie w artości żądania

(

\

j j

Weryfikacja

W izualizacja o dp o w ie dzi

Zakończono odp o w ie dź

.....

Za kończono o dp o w ie dź

W yw o ła n ie aplikacji

Wizualizacja odp ow ie dzi

Aktualizacja wartości m o d elu

Błędy konw ersji/w izua liza cja odpow iedzi Błędy w e ryfika cji lu b konw ersji/w izua liza cja o dp o w ie dzi

Rysunek 7.6. Komponenty bezpośrednie Zdarzenia bezpośrednie są generowane po fazie stosowania wartości żądania. W przypadku komponentów wejściowych procesy konwersji i weryfikacji (poprzedzające generowanie zdarzeń zmiany wartości) są realizowane bezpośrednio po fazie stosowania wartości żąda­ nia. W przypadku komponentów poleceń wywołania metod nasłuchujących akcji następują przed wywołaniam i samych akcji, a cały ten proces decyduje o działaniu mechanizmu odpowiedzialnego za obsługę nawigacji i eliminuje dalsze fazy cyklu życia aż do fazy wizualizacji odpowiedzi.

Stosowanie bezpośrednich komponentów wejściowych Na rysunku 7.7 przedstawiono przykład obsługi zdarzeń zmiany wartości zaczerpnięty z pod­ rozdziału „Zdarzenia zmiany wartości” . Warto przypomnieć, że prezentowana aplikacja wykorzystuje metodę nasłuchiwania zmian wartości do modyfikowania ustawień regionalnych widoku, które z kolei decydują o opisie jednego z pól tekstowych formularza.

Adres

. ••

.

-o

Miasta i Stan Kraj

Stam, żiecmocrone [_^j

vVysti) aflres j

Wydaje się, że wprowadzona zmiana jest zupełnie nieszkodliwa z punktu widzenia prezento­ wanej aplikacji — do pola wejściowego Adres dodaliśmy mechanizm weryfikujący, nato­ miast do całego formularza dodaliśmy znacznik komunikatu. Takie rozwiązanie oznacza jednak, że wybór kraju przed wypełnieniem pola Adres doprowadzi do błędu procesu weryfi­ kacji (menu Kraj wysyła bowiem cały formularz bezpośrednio po zmianie jego wartości). Można ten problem sformułować w następujący sposób: chcemy weryfikować dane w sytuacji, gdy użytkownik aktywuje przycisk akceptacji formularza, ale też chcemy ten proces wyeliminować w sytuacji, gdy użytkownik zmienia ustawienia w menu kraju. Jak dopro­ wadzić do stosowania mechanizmu weryfikacji w jednym przypadku i zrezygnować z jego stosowania w innym? Rozwiązaniem tego problemu jest przekształcenie menu Kraj w komponent bezpośredni (ang. immediate component). Bezpośrednie komponenty wejściowe same realizują zadania związane z konwersją i weryfikacją, po czym dostarczają zdarzenia zmian wartości na po­ czątku cyklu życia JS F (bezpośrednio po fazie stosowania wartości żądania, zamiast po fazie weryfikacji). Komponenty bezpośrednie należy definiować za pomocą atrybutu immediate, który może być stosowany dla wszystkich komponentów wejściowych i komponentów poleceń:

Jeśli przypiszemy atrybutowi immediate wartość true, nasze menu będzie generowało zda­ rzenia zmian wartości bezpośrednio po fazie stosowania wartości żądania, a więc na długo przed weryfikacją danych komponentów wejściowych. Część Czytelników zapewne zasta­ nawia się, dlaczego późniejsza weryfikacja miałaby być lepsza od wcześniejszej, skoro nie ma wątpliwości, że weryfikacja i tak zostanie przeprowadzona, a odpowiedni błąd wyświe­ tlony. Aby zapobiec weryfikacji danych wejściowych pozostałych komponentów danego formularza, musimy podjąć jeszcze jeden ważny krok polegający na wywołaniu metody renderResponse kontekstu stron na końcu metody nasłuchującej zmian wartości: private static final String US = "Stany Zjednoczone"; public void countryChanged(ValueChangeEvent event) {

268

JavaServer Faces FacesContext context = FacesContext g e i C u r r e m I n s t a n c e ( ). i f (US e q u a l s ü S t n n g ) event getNewValue( ) )) context getvlewRooL( ) . s e t L o c a l e ( l o c a le US), e is e context getViewRoot( ) . s e t L o c a l e ( L o c a l e CANADA),

context. renderResponse():

1

Rozdział 7. ■ Obsługa zdarzeń

269

■4ahaiBM~

Rysunek 7.8.

Zmiana ustawień regionalnych za pośrednictwem łączy

Plik

tdycja

Widok

tttstona

Zakładki

Naizjctoa

Pomoc

ii

.: http://localhost:8080/flags/index.f j ▼ j j£ ł Ijc IR jF t

,4>ł

¡5 -* »

in r t ili j!

j Proszę wpisać następujące dane osobowe f

Inuę

1 Hasło jj Proszę napisać coś o sobie

Wywołanie metody renderResponsef ) powoduje pominięcie pozostałych faz cykJu życia (łącznie z fazą weryfikacji danych dostarczonych przez pozostałe komponenty wejściowe) z wyjątkiem fazy wizualizacji odpowiedzi. Za jej pomocą możemy pominąć proces weryfi­ kacji bez konieczności rezygnacji z normalnej wizualizacji (w tym przypadku polegającej na ponownym wyświetleniu bieżącej strony). Podsumowując, możemy pominąć proces weryfikacji danych wejściowych (w razie wyge­ nerowania zdarzenia zmiany wartości) w następujący sposób: 1.

Dodając atrybut i mmedi ate do znacznika komponentu wejściowego.

2. Wywołując metodę FacesContext. renderResponse( ) na końcu metody nasłuchującej. Przy okazji analizy tego przykładu warto wspomnieć o jeszcze jednym aspekcie. Łatwo za­ uważyć, że do naszego znacznika h:selectOneMenu dodano atrybut onchange wskazujący na funkcję submit( ). Takie ustawienie wspomnianego atrybutu oznacza, że za każdym razem, gdy użytkownik zmieni opcję zaznaczoną w danym menu, zostanie wywołana funkcja submit języka JavaScript, która spowoduje wysłanie na serwer całego formularza. Opisane rozwiązanie jest kluczowe, ponieważ implementacja JavaServer Faces obsługu­ je wszystkie zdarzenia po stronie serwera. Gdybyśmy usunęli atrybut onchange ze znacz­ nika h : sei ectOneMeriu, formularz nie zostałby wysłany na serwer w reakcji na zmianę opcji w menu Kraj , co wykluczyłoby możliwość wywołania cyklu życia JS F i — tym samym — wywołania naszej metody nasłuchującej zmian wartości (w tym przypadku odpowiedzialnej za dostosowanie ustawień regionalnych). To, że w technologii JS F wszystkie zdarzenia są obsługiwane po stronie serwera, wielu programistom wydaje się dość dziwne. Z drugiej strony, powinniśmy pamiętać, że istnieje możliwość obsługi zdarzeń także po stronie klienta za pośrednictwem skryptów JavaScript dołączanych do komponentów (z wykorzystaniem takich atrybutów jak onbl ur, onfocus czy onclick). Co więcej, dodanie mechanizmów obsługi zdarzeń po stronie klienta jest planowane już w kolejnej wersji technologii JSF .

Stosowanie bezpośrednich komponentów poleceń W rozdziale 4. omówiono aplikację oferującą możliwość zmiany ustawień regionalnych za pomocą łączy poleceń (patrz rysunek 7.8).

1

i

11 Zakończono

11

Jeśli do jednego z pól wejściowych tego formularza dodamy mechanizm weryfikujący czy została do niego wprowadzona jakakolwiek wartość, będziemy się musieli zmierzyć z tym samym problemem, o którym była mowa w punkcie „Stosowanie bezpośrednich kompo­ nentów wejściowych” . Próba zmiany ustawień regionalnych przez kliknięcie łącza (w tym przypadku flagi) spowoduje wygenerowanie błędu weryfikacji. Tym razem jednak będzie­ my potrzebowali bezpośredniego komponentu polecenia (zamiast — jak wcześniej — bez­ pośredniego komponentu wejściowego). W tym celu wystarczy dodać do istniejącego znacznika h: commandLi nk atrybut immediate:

Warto zwrócić uwagę na różne akcje przypisane do poszczególnych łączy: 1ocal eChanger. ^englishAction dla flagi brytyjskiej oraz 1ocal eChanger .poi i shActi on dla flagi polskiej. Okazuje się, że implementacje tych akcji mają postać bardzo prostych metod:

270

JavaServerFaces public class ChangeLocaleBean { public String polishAction!) { FacesContext context = FacesContext.getCurrentlnstance!); context.getViewRoot() .setLocale(Locale.POLISH), return nu ll;

} public String englishAction() { FacesContext context = FacesContext,getCurrentInstance(), context.getViewRoot!) . setLocale(Locale.ENGLISH); return riul 1 ,

Każda metoda nasłuchująca określa właściwe ustawienia regionalne widoku głównego i zwraca wartość nuli, która sygnalizuje implementacji JS F konieczność ponownego załadowania tej samej strony. To bardzo proste. Wyobraźmy sobie teraz sytuację, w której chcemy zaimplementować obsługę wielu języków — gdybyśmy zdecydowali się na obsługę np. 100 języków, musielibyśmy zaimplementować aż 100 akcji, które różniłyby się tylko stosowanymi ustawieniami regionalnymi. To już nie byłoby takie proste. Aby wyeliminować ten nadmiarowy kod (który wymaga nie tylko napisania, ale też kon­ serwacji), warto przenieść kod języka z poziomu interfejsu użytkownika na poziom serwe­ ra. Takie rozwiązanie umożliwiłoby nam zmianę ustawień regionalnych z wykorzystaniem zaledwie jednej akcji lub metody nasłuchującej akcji. Technologia JS F oferuje aż trzy w y­ godne mechanizmy umożliwiające przekazywanie informacji z interfejsu użytkownika na serwer (wszystkie w formie znaczników JS F ): ■ f:pa ram

Rozdział 7. ■ Obsługa zdarzeń

271


Niezależnie od liczby flag, które zdecydujemy się umieścić na naszej stronie JS P , możemy stosować komponent ChangeLocaleBean w niezmienionej postaci. Oznacza to, że udało nam się wyeliminować nadmiarowość kodu.

Znacznik 1:attribute

■ f :setPropertyActi onLi stener ■ f : attribute W dalszej części tego podrozdziału przeanalizujemy kolejno poszczególne znaczniki pod kątem oferowanych możliwości w zakresie eliminowania nadmiarowego kodu.

Znacznik Uparam Znacznik f:param umożliwia nam dołączanie do komponentów dodatkowych parametrów. Co ciekawe, znaczenie tego znacznika zależy od rodzaju komponentu, dla którego zostanie użyty. Jeśli na przykład dołączymy znacznik f :param do komponentu reprezentowanego przez znacznik h: outputText, implementacja JS F wykorzysta tak zdefiniowany parametr do wypełnienia symboli zastępczych, czyli {0}, {1} itd. Jeśli dołączymy ten sam znacznik do komponentu polecenia (czyli przycisku lub łącza), implementacja JS F przekaże wartość odpowiedniego parametru na serwer w formie parametru żądania. Poniżej przedstawiono możliwy sposób wykorzystania znacznika f : param w przykładowej aplikacji z flagami:

Warto zwrócić uwagę na dwa aspekty tego rozwiązania. Po pierwsze, do ustawienia dodatko­ wego atrybutu łącza wykorzystano znacznik f :attribute. Sam atrybut nazwano languageCode, a jego wartości (w tym konkretnym przypadku) mogą mieć postać łańcuchów " en" lub " p l".

272

JavaServer Faces Po drugie, tym razem odwołujemy się do metody nasłuchującej akcji (zamiast samej akcji). Zdecydowaliśmy się na takie rozwiązanie, ponieważ metody nasłuchujące akcji otrzymują na wejściu obiekty umożliwiające dostęp do komponentu, który spowodował dane zdarzenie (w tym przypadku będzie to oczywiście jedno z łączy). Naszym celem jest zapewnienie dostępu do wartości atrybutu 1anguageCode. Poniżej przedstawiono odpowiedni fragment kodu wykonywanego po stronie serwera: public class ChangeLocaleBean { public void changeLocale(ActionEvent event) { UlComponent component = event.getComponent(), String 1anguageCode = getLanguageCode(component); FacesContext,getCurrentInstance() ,getViewRoot() . setLocale(new Locale(languageCode));

}

private String getLanguageCode(UlComponent component) { Map attrs = component,getAttributes(); return (String) attrs.get ("languageCode");

Tym razem nie wyodrębniamy interesującej nas wartości z parametru żądania — możemy uzyskać tę wartość (w tym przypadku kod wybranego języka) za pośrednictwem atrybutu komponentu. Niezależnie od wybranego modelu przedstawione implementacje komponentu ChangeLocaleBean są kompletne i nie wymagają przebudowy w razie konieczności dodania obsługi nowych języków.

Znacznik i:setPropertyActionUstener Jak wiemy, znaczniki f: pa ram oraz f :a ttrib u te okazują się bardzo wygodne, jeśli chcemy przekazywać informacje interfejsu użytkownika na serwer, jednak wymagają samodzielnego, ręcznego wyodrębniania tych informacji odpowiednio z parametru żądania lub atrybutu komponentu. Znacznik f: setPropertyActi onLi stener (dostępny począwszy od wersji JS F 1.2) eliminuje taką konieczność. Za pośrednictwem tego znacznika możemy wymuszać na implementacji JS F ustawianie wartości określonej właściwości komponentu wspomagającego. Poniżej przedstawiono przykład użycia tego mechanizmu w aplikacji z flagami:

Rozdział 7. ■ Obsługa zdarzeń

273

W powyższym fragmencie kodu JS F sygnalizujemy implementacji JS F konieczność przy­ pisania właściwości languageCode komponentu wspomagającego local eChanger łańcucha "p l" lub "en". Implementację komponentu 1ocal eChanger przedstawiono poniżej: public class ChangeLocaleBean { private String languageCode; public String changeLocale() { FacesContext context = FacesContext,getCurrentInstance(); context,getViewRoot() .setLocale(new LocaleOanguageCode)); return n u ll;

} public void setLanguageCode(String newValue) { languageCode = newValue;

Na potrzeby przedstawionej implementacji komponentu ChangeLocaleBean zdefiniowano właściwość languageCode (dostępną tylko do odczytu), która jest automatycznie ustawiana przez implementację JSF . W analizowanym przykładzie właśnie użycie znacznika f: setPropertyActi onLi stener wydaje się najlepszą metodą przypisania wartości właściwości languageCode komponentu local eChanger, ponieważ wymaga najprostszej implementacji klasy tego komponentu (ChangeLocaleBean). Okazuje się jednak, że w pewnych przypadkach lepiej sprawdzają się znaczniki f : parani i f a ttrib u te umożliwiające ustawianie odpowiednio parametrów żądania i atrybutów komponentu. Do tej pory koncentrowaliśmy się na technikach dołączania metod obsługujących zdarzenia do egzemplarzy komponentów. Technologia JavaServer Faces dodatkowo umożliwia nam definiowanie mechanizmów obsługi zdarzeń globalnych wywoływanych na różnych etapach cyklu życia JS F . Tego rodzaju zdarzenia omówimy w kolejnym podrozdziale.

Zdarzenia fazy Implementacja JavaServer Faces generuje zdarzenia, nazywane zdarzeniami fazy (ang. phase events), bezpośrednio przed i bezpośrednio po każdej fazie cyklu życia. Tego rodzaju zda­ rzenia są obsługiwane przez fazowe obiekty nasłuchujące, których — w przeciwieństwie do metod nasłuchujących zmian wartości i akcji — nie wiążemy z poszczególnymi kom­ ponentami. Fazowe obiekty nasłuchujące wskazuje się w pliku konfiguracyjnym: <1 i fecycle> com.corejsf.PhaseTracker

W powyższym fragmencie kodu wskazano tylko jeden obiekt nasłuchujący, co nie oznacza, że w razie konieczności nie można wskazać dowolnej liczby potrzebnych obiektów. W takim przypadku metody obiektów nasłuchujących będą wywoływane w kolejności zgodnej z po­ rządkiem w pliku konfiguracyjnym.

274

Rozdział 7. ■ Obsługa zdarzeń

JavaServer Faces KJasy nasłuchujące zdarzeń fazy muszą implementować interfejs PhaseL i stener należący do pakietu javax faces, event. Interfejs PhaseL i stener definiuje trzy metody: ■

Phaseld getPhaselcK )

■

void afierPhase(PhaseEvent)

■

void beforePhase(PhaseEvent)

Rysunek 7.9.

Ź&i Zdarzema fazy

Przykład użycia fazowego obiektu nasłuchującego

Plik

MoziBa h*eiox

Widok

~ i i Wybierz fazę

Historia

Zakładki

Narzędzia

Pomoc

t 3 l i...-. httP://l° -jlt- i * 1 * 1 O . T

P E CT '-,P E „iEv-'

•

lliij

i

„ p p L , _ B E 'JU F < T T _ - a L i i E':.

P R O C E S S ■■-LlE'ATinriS ■j B D ^ t e . m O P E L .» « l u E E It J- Ol E P E ' l E 'E P .P E S P ' 'OSE ^ ■ P h «S E ^ i vW siij lomiuiatz j

Metoda get Phase 1d sygnalizuje implementacji JS F konieczność przekazania informacji 0 zdarzeniu fazy metodzie nasłuchującej — metoda get Phase i d może zwrócić na przykład wartość Phase Id. APPly_REQUEST_VALUES. W takim przypadku metody befonePhase oraz aftenPhase zostałyby wywołane tylko raz w całym cyklu życia (bezpośrednio przed i po fazie stosowania wartości żądania). Ta sama metoda może też zwrócić wartość Phase Id ^ANY PhASE, która w praktyce reprezentuje wszystkie fazy. W takim przypadku każda z metod beforePhase oraz afterPhase zostałaby wywołana aż sześć razy w jednym cyklu życia: przed 1po każdej fazie tego cyklu.

1© u

Zdarzenia fazy - Mozilta Firefox

is T 4 8

Edycja *

# '

Widok

Historia

* @

f jJ

W ybierz tazę i P E 3 TQ PE

Zakładki s

Narzędzia

Pomoc

• httpy/local h . l d » , ! í E b

-•'E'- ■ ■

B M g f B g ia P R O C E S S ■•.••^l i D - T IO I i E H P | j« r E m o d e l ■■-l i 'E S

U,-"i E.^PPU'.~Tir'N REN D ER R ESP O N SE

-u. { wysitj tormutyz ! :ĘĘi Zdarzenia fazy - Mozilta Firefox Plik

Fazowe obiekty nasłuchujące są szczególnie przydatne w procesie diagnozowania opro­ gramowania i w przypadku wysoce wyspecjalizowanych rozwiązań. Jeśli na przykład uży­ jemy komponentów JS F w aplikacji internetowej opracowanej na bazie innego frameworku, np. Struts, możemy dążyć do aktualizacji ustawień regionalnych tego frameworku po fazie stosowania wartości żądania (czyli wtedy, gdy implementacja JS F wewnętrznie okre­ śla swoje ustawienia regionalne). Fazowe obiekty nasłuchujące także w przypadku aplikacji wykorzystujących technikę A JA X służą do poprawy funkcjonalności interfejsu użytkownika (patrz rozdział II.). Aplikacja przedstawiona na rysunku 7.9 ilustruje możliwe zastosowanie fazowych obiektów nasłuchujących. Nasza przykładowa aplikacja wykorzystuje pojedynczy obiekt nasłuchujący do rejestrowania komunikatów:

Edycja

275

Edycja

Widok

Histeria

T ,‘ ":r S -z Zakładki

Narzędzia

S W vbi^rz fazę

phLse

Pomoc

B

tj

ilii EJ

R E E T ' .
«U,.Ph-SE W ysit; tormuiąrz ¡

mmmmi pub 11C C lass FormBear { //

public class PhaseTracker implements PhaseListener {

METODA NASŁUCHUJĄCA ZMIAN WARTOŚCI: phaseChange

public void phas eCra rg e (v a lueCrargeEvert e) ]

/ / uzyskujemy referencję do bieżącego cyklu życia. private static final Logger logger = Logger.getLogger!"com.corejsf.phases"); PhaseListener[] listeners = 1ifecycle.getPhaseListeners!), for (int i=0; i < listeners length; i++) { PhaseListener listener = listeners[i]; i f (listener instanceof com.corejsf.PhaseTracker) ( (com.corejsf.PhaseTracker) 1i stener).setPhase((String) e.getNewValue());

public void beforePhase(PhaseEvent e) { logger.info("PRZED " + e.getPhaseldC));

}

public void afterPhase(PhaseEvent e) { logger.infoC'PO " + e.getPhaseldO);

}

} } Identyfikator fazy jest wybierany (na potrzeby tego obiektu) z listy zdefiniowanej w kodzie strony JS F w następujący sposób:

Kiedy użytkownik zaznacza fazę i aktywuje przycisk akceptacji formularza, metoda nasłu­ chująca zmian wartości ustawia właściwy identyfikator fazy (na potrzeby fazowego obiektu nasłuchującego):

} } Na pierwszym ze zrzutów widocznych na rysunku 7.9 przedstawiono początkową stronę analizowanej aplikacji — łatwo zauważyć, że na tym etapie nie zaznaczono jeszcze żadne­ go elementu listy. Ponieważ domyślną fazą obiektu nasłuchującego jest PhaseId.ANY_PHASE, wspomniany obiekt będzie wywoływany bezpośrednio przed i po każdej fazie (aż do momentu zaznaczenia któregoś z elementów listy i wysłania formularza na serwer). Poniżej przedsta­ wiono dane wyjściowe zapisane na początku działania aplikacji przez analizowany obiekt nasłuchujący w pliku dziennika kontenera serwletu:

276

Rozdział 7. ■ Obshiga zdarzeń

JavaServer Faces INFO: INFO INFO: INFO:

PRZED RESTORE_VIEW 1 PO RESTOREJIEW 1 PRZED RENDER_RESPONSE 6 PO RENDER_RESPONSE 6

Dlaczego obiekt nasłuchujący nie został poinformowany o fazach od drugiej (stosowanie wartości żądania) do piątej (wywołanie aplikacji)? W momencie uruchamiania aplikacji nie istnieje widok, który można by przywrócić, ponieważ nie załadowano jeszcze żadnej strony JSF . Skoro nie istnieje drzewo komponentów i — tym samym — weryfikacji danych wej­ ściowych, aktualizacja wartości modelu ani wywoływanie akcji nie ma najmniejszego sensu; najlepszym rozwiązaniem jest przejście cyklu życia JS F bezpośrednio do fazy wizualizacji odpowiedzi. Taka sytuacja ma miejsce tylko na początku działania aplikacji i zmienia się w chwili jej ponownego załadowania przez kontener serwletów. Oznacza to, że jeśli użytkow­ nik aktywuje przycisk wysyłający formularz bez zaznaczania któregokolwiek z elementów listy, w pliku dziennika zostaną umieszczone następujące dane wyjściowe: INFO: INFO: INFO: INFO: INFO. INFO: INFOINFO: INFO: INFO: INFO: INFO:

PRZED RESTORE_VIEW 1 PO RESTOREJ/IEW 1 PRZED APPLY_REQUEST_VALUES 2 PO APPLY_REQUEST_VALUES 2 PRZED PROCESS_VALI DATIONS 3 PO PROCESSJ/ALIDATIONS 3 PRZED UPDATE_MODEL_VALUES 4 PO UPDATE_MODEL_VALUES 4 PRZED I NVOKE_APPLICATION 5 PO INVOKE_APPLICATION 5 PRZED RENDER_RESPONSE 6 PO RENDER_RESPONSE 6

Jak widać, tym razem obiekt nasłuchujący jest informowany o wszystkich fazach, ponieważ jako fazę domyślną ustawiono Phaseld. ANY_PFIASE. W kolejnym kroku zaznaczamy element listy nazwany APPLY REQUEST VALUES (repre­ zentujący fazę stosowania wartości żądania) i aktywujemy przycisk akceptacji formularza (patrz środkowy zrzut ekranu na rysunku 7.9). Poniżej przedstawiono dane wynikowe zapisane w pliku dziennika przez obiekt nasłuchujący: INFO INFO 1NF0 [NFO [NFO

Ponieważ faza stosowania wartości żądania już się zakończyła, nasz obiekt nasłuchujący nie został poinformowany o pozostałych fazach danego cyklu życia JSF. Jeśli ponownie klikniemy przycisk akceptacji formularza, dane wynikowe będą już w pełni zgodne z naszymi ocze­ kiwaniami, ponieważ identyfikator fazy w ramach obiektu nasłuchującego od początku nowego cyklu życia będzie wskazywał na fazę stosowania wartości żądania: INFO- PRZED APPLY_REQUEST_VALUES 2 INFO- PO APPLY_REQUEST_VALUES 2

I wreszcie zaznaczamy element INV0KE_APPLICAT10N i wysyłam y formularz na serwer. W wyniku tego kroku otrzymamy następujące dane wyjściowe: INFO: INFO: INFO: INFO

PRZED APPLY_REQUEST_VALUES 2 PO APPLY_REQUEST_VALUES 2 PRZED INVOKE_APPLICATION 5 PO INVOKE_APPLICATION 5

Czy na tym etapie przedstawione dane wynikowe mają jakiś sens? Na początku nowego cyklu życia identyfikator fazy obiektu nasłuchującego wskazuje na fazę stosowania wartości żądania, zatem właśnie o niej jest informowany. W dalszej części tego cyklu życia (po fazie wery­ fikacji) metoda nasłuchująca zmian wartości przypisuje temu identyfikatorowi wartość INVOKE_APPLICATION. Chwilę później ten sam obiekt nasłuchujący jest informowany o fazie wywołania aplikacji. Jeśli ponownie klikniem y przycisk akceptacji formularza, w pliku dziennika zostaną umieszczone następujące dane wyjściowe: INFO. PRZED INVOKE_APPLICATION 5 INFO PO INVOKE_APPLICATION 5

Strukturę katalogów tej prostej aplikacji przedstawiono na rysunku 7.10. Kod źródłowy aplikacji z rysunku 7.9 przedstawiono na listingach od 7.14 do 7.19.

Rysunek 7.10. Struktura katalogów analizowanej aplikacji przykładowej

3 phase-track.er.war

Y

META-INF ! L Q MANIFEST.MF f CaWEB-INF f [ 3 classes ? (¡3 com t k3 corejsf

PRZED RESTORE_VJEW 1 PO RESTORE_VIEW 1 PRZED APPLY_REQUEST_VALuES 2 PO APPLY_REQUEST_VALllES 2 PRZED PROCESSJALI DATIONS 3

Q Form B ean class Q P h as eT racke r class Q m essag es p ro p e rtie s Q fa c e s -c o n tig xml

¡2 w e b xm i D

Część Czytelników zapewne oczekiwała informacji tylko o fazie stosowania wartości żądania. Dlaczego nasz obiekt nasłuchujący został poinformowany o zdarzeniach przed i po fazie przywracania widoku oraz przed fazą weryfikacji? Po pierwsze, w momencie wysyłania for­ mularza w obiekcie nasłuchującym nadal obowiązuje faza ANY_PFiASE. Oznacza to, że jeszcze na początku danego cyklu życia nasz obiekt nasłuchujący byl zainteresowany wszystkimi fazami (i byl o nich informowany). Po drugie, musimy pamiętać, że identyfikator fazy w ramach naszego obiektu nasłuchują­ cego jest ustawiany przez metodę nasłuchującą zmian wartości, a tego rodzaju metody są wywoływane po fazie weryfikacji (patrz rysunek 7.1). Na końcu fazy weryfikacji metoda nasłuchująca zmian wartości przypisuje odpowiedniej składowej fazowego obiektu nasłu­ chującego wartość APPLY_REQUEST_VALUES.

277

styles css

Q in d e x html Q index jsp_______________________

Przedstawiony mechanizm śledzenia faz można wykorzystywać we własnych aplika­ cjach celem sprawdzania, kiedy poszczególne zdarzenia są generowane — wszystkie generowane przez nas kom unikaty dziennika będą występowały w łącznej sekwencji kom unikatów generowanych przez opisany m echanizm . Aby stosow anie tego m echa­ nizmu było m ożliw e, koniecznie należy um ieścić odpowiedni plik klasy w pliku WAR i w łaściw ą deklarację w pliku konfiguracyjnym faces~config.xml (patrz listing 7 .1 7 ). Omówienie bardziej rozbudowanego i zaawansowanego mechanizmu śledzenia JSF można znaleźć w punkcie „Jak diagnozow ać a p lik ac ję, która u tkn ę ła na ja k ie jś stronie?" w rozdziale 1 3 .

□

278

JavaServer Faces

Rozdział 7. ■ Obsługa zdarzeń

Listing 7.14. Kod strony

phase-

1 2 <%@ taglib uri="http;//java.sun.com/jsf/core" prefix="f" 3 4 5

6 7

8. 9

10 11

%> <%@ taglib uri="http://Java.sun.com/jsf/html" prefix="h" %>



12

13. 14 15 16 17 18 19 20 21 22. 23 24. 25 26. 27.



Listing 7.15. Kod komponentu phase-tracker/src/java/com/corejsf/FormBeanJava 1 package com.corejsf, 3 import javax.faces.FactoryFinder; 4 import javax.faces.event.PhaseEvent, 5. import javax.faces.event.PhaseListener: 6 import javax.faces.event.ValueChangeEvent, 7. import javax.faces.lifecycle.Lifecycle; 8 . import javax.faces.lifecycle.LifecycleFactory. 9 import javax.faces.model.Selectltem; 10

11. public class FormBean { TO -------1— _-i __i ti 12 private Selectltem[] phases = { 13. new Selectltem("RESTORE_VIEW"), 14. new Selectltem ("APPLYJREQUESTJ/ALUES"), 15 new Selectltem ("PROCESS_VALIDATIONSM), 16 new Selectltem("UPDATE_MODEL_VALUES") , 17. new Selectltem (" INVOKE_APPLICATION"), 18. new Selectltem("RENDER_RESPONSE"), 19 new SelectItem("ANY_PHASE"), 20 },

21. 23 24. 25.

public SelectltemE] getPhasesO {

FactoryFinder LIFECYCLE_FACTORY), Lifecycle lifecycle = factory.getLifecycle(LifecycleFactory. DEFAULT_LIFECYCLE); PhaseListener[] listeners = lifecycle.getPhaseListenersO: for (int i = 0. i < listeners length; i++) { PhaseListener listener = 1isteners[i]; i f (listener instanceof com.corejsf.PhaseTracker) ((com.corejsf PhaseTracker) 1istener).setPhase( (String) e.getNewValue()); } } public void afterPhase(PhaseEvent event) { System.out.printlnC'PO FAZIE " + showEvent(event)), } public void beforePhase(PhaseEvent event) { System.out.printIn("PRZED FAZĄ " + showEvent(event)); } private String showEvent(PhaseEvent event) { return "Zdarzenie fazy. " + event.getPhaseId(); }

Listing 7.16. Kod klasy phase-tracker/src/java/com/corejsf/PhaseTracker.java___________________ 1. package com.corejsf;

2. 3 import java.util.logging.Logger; 4. import javax.faces.context.FacesContext, 5. import javax.faces.event.PhaseEvent, 6. import javax.faces.event.PhaseListener; 7. import javax.faces.event.Phaseld;

8

2.

22

26 27 28. 29 30 31 32 33. 34 35. 36 37. 38 39. 40. 41 42. 43. 44 45. 46 47 }

return phases; }

public void phaseChange(ValueChangeEvent e) {

LifecycleFactory factory = (LifecycleFactory) FactoryFinder.getFactory(

9. public class PhaseTracker implements PhaseListener { 10. private static final String PHASE_PARAMETER ="com.corejsf.phaseTracker phase"; 11 private sta tic final Logger logger = Logger.getLoggerC'com.corejsf.phases"); 12. private s ta tic String phase = null; 13. 14. public void setPhase(String newValue) { phase = newValue, } 15. 16. 17. 18. 19. 20 21. 22. 23. 24. 25 26. 27. 28. 29. 30. 31.

public Phaseld getPhaseldO { i f (phase ==n u ll) { FacesContext context = FacesContext.getCurrentInstance(), phase = (String) context.getExternalContextO.getInitParameter( PHASE_PARAMETER);

} Phaseld phaseld = Phaseld.ANY_PHASE; i f (phase != null) { i f ("RESTOREJ/IEW" equals(phase)) phaseld =Phaseld.RESTOREJ/IEW; else i f ("APPLY_REQUEST_VALUES".equals(phase)) phaseld =Phaseld.APPLY_REQUEST_VALUES; else i f ( " PROCESSJ/ALIDATI0NS".equals(phase)) phaseld =Phaseld.PROCESSJ/ALIDATI0NS. else i f ( "UPDATE_M0DEL_VALUES".equals(phase)) t

-j

m — ..— t

iin n A T r

M nnn

\/a l l IC C

279

280

JavaServer Faces 33 34. 35 36 37 38. 39. 40. 41. 42. 43. 44. 45. 46 47 48.

Rozdział 7. ■ Obsługa zdarzeń else i f ( " INV0KE_APPLICATI0N" .equals(phase)) phaseld =Phaseld. INV0KE_APPLICATI0N. else i f ("RENDER_RESPONSE" equals(phase)) phaseld =Phaseld.RENDER_RESPONSE. else i f ( "ANY_PHASE".equals(phase)) phaseld =Phaseld.ANY_PHASE;

} return phaseld; } public void beforePhase(PhaseEvent e) { logger infoC'PRZED " + e.getPhaseId()), } public void afterPhase(PhaseEvent e) { logger.infoC'PO "+ e.getPhaseId()); } }

Listing 7.17. Plik konfiguracyjny phase-tracker/web/WEB-\NF/faces-config.xml

5. 6. 7.

vertical-align, top, font-style: ita lic ; font-size l.lem;

8- } 9

10 .

.columns { vertical-align: top;

1 1 .}

Podsumowanie całego materiału w jednym miejscu Bodaj najlepszym zakończeniem tego rozdziału będzie analiza przykładu prostej implementa­ cji panelu podzielonego na zakładki. Nasza aplikacja demonstruje zarówno obsługę zdarzeń, jak i zaawansowane aspekty stosowania znaczników JS F języka H TM L. Wykorzystamy następujące techniki:

1 . 2 .
■ zagnieżdżania znaczników h: panel Gri d;

3.

xmlns:xs i ="http://www.w3.org/2001/XMLSchema- instance" xsi.schemaLocation="http;//java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfi g_l_ 2 .xsd" version="1 . 2 "> com.corejsf messages msgs

■ stosowania facet;

form com.corejsf FormBean session

■ statycznego dołączania stron JSF.

4. 5. 6. 7

8 9

10 11. 12 13. 14 15 16. 17 18. 19.

20 2 1. 22 23.

com.corejsf PhaseTracker

Listing 7.18. Plik właściwości phase-tracker/src/java/com/corejsf/messages.properties 1. indexWindowTitle=Zdarzenia fazy

■ definiowania indeksów zakładek; ■ dodawania podpowiedzi do komponentów za pośrednictwem atrybutu t i t l e; ■ dynamicznego określania klas stylów; ■ stosowania metod nasłuchujących akcji; ■ wizualizacj i opcj onalnej;

Technologia JS F 1.2 nie oferuje gotowego komponentu panelu podzielonego na zakładki, stąd przed opracowaniem odpowiedniej strony musimy się zdecydować na jedno z dwóch rozwią­ zań: implementację komponentu niestandardowego lub użycie znaczników już istniejących (łącznie z komponentem wspomagającym). Na rysunku 7.11 przedstawiono efekt zastoso­ wania drugiego z tych rozwiązań. Analizę pierwszego rozwiązania można znaleźć w pod­ rozdziale „Stosowanie komponentów i facet potomnych” w rozdziale 9. Przedstawiony na rysunku 7.11 panel podzielony na zakładki zaimplementowano wyłącznie za pomocą istniejących znaczników JS F języka H T M L oraz komponentu wspomagającego — nie korzystaliśmy z żadnych niestandardowych mechanizmów wizualizacji ani własnych komponentów. Kod strony JS F obejmującej ten panel przedstawiono poniżej:

2 . phasePrompt=Wybierz fazę3. submitPrompt=Wyślij formularz

Listing 7.19. Arkusz stylów phase-tracker/web/styIe s.css 1 . body { 2 background: #eee; 3- } 4. .phaseFormColumns {

281

<%-- Zakładki --%>
282

JavaServer Faces

Rysunek 7.11.

Rozdział 7. ■ Obsługa zdarzeń

Pfzvttad pareiu pocsziesoneqo na zagadki -MözWafsrefoac '

Przykład panelu podzielonego na zakładki

Pt*

Edycja

Widok

•cy * i,iÿP i>

Historii i »

jj j| !

Zakłsaw

Narzędas

’

- 1 @ L U E JL S J

Pomoc

http://localhost:8080/tabbedpane/index.faces

.;■> ] f kjfcj-.

Ooorçic

p tł

TŁeodore Rooseyeltl jAbrahamLincolnI IGeorge Washingtoni ir2ect prczydenł Stanów Zjednoczonych urodził się w mku 17&3 w stanie Wirginia Jefferson byt znany z doskonałych przemówień Wraku ł 786 nbjał urząd ministra d&

Thomas Jeffersonj

■AbrahamUrnolrT ¡George Washington’

Theodore Roosevelt byt 26 prezydentem Sianów Zjednoczonych. Zostałprezyaentem w mku ¡901 po zamachu na prezydenta McKinley a. Urząd prezydenta objął w wieku ¿7 lat i orzeszedł kistom jako n aj*iłodszv w histom Stanów Zjednoczonych.

jThomas Jefiersonl ¡Theodore Rooseveltj ¡AbrahamLiftccffij ¡George Washington! "

Prezydent Lincoln przeszedł do hislom jako Wielki Bmancypator , ponieważ w ogromnym stopniu przyczynił się Jo zniesienia niewolnictwa na tereme Stanów Zjednoczonych Urodzony vu ¡809 roku wychował się w biednej rodzime w stanie Kentucky. Na nnądprezydenta został wybrany w r0ku 1860.

IThgraas JeftersoBj

Kiedy użytkownik klika zakładkę, następuje wywołanie odpowiedniej metody nasłuchującej akcji (związanej z danym łączem polecenia), która modyfikuje dane składowane w kompo­ nencie wspomagającym. Ponieważ dla zaznaczonej zakładki stosujemy inny styl C SS niż dla pozostałych zakładek, wartość atrybutu sty 1eClass każdego znacznika h:commandl_ ink jest odczytywana z komponentu wspomagającego za pośrednictwem wyrażenia reprezentującego referencję do wartości. Jak widać na pierwszym zrzucie z rysunku 7.11, wykorzystaliśmy atrybut t it le do przypi­ sania poszczególnym zakładkom łańcuchów podpowiedzi. Innym ważnym elementem funkcjonalności jest mechanizm umożliwiający przełączanie zakładek za pomocą klawiatury (bez konieczności klikania odpowiednich nagłówków). Zaimplementowaliśmy ten mecha­ nizm, przypisując odpowiednie wartości atrybutom tab index poszczególnych znaczników h:commandLink. Treść właściwa dla poszczególnych zakładek jest dołączona statycznie za pomocą dyrektywy include znanej z technologii JSP. W tym konkretnym przypadku treść ma postać prostego obrazu i niedługiego tekstu, co nie oznacza, że nie można by tego mechanizmu rozbudować o bardziej zaawansowany zbiór komponentów. Warto zwrócić uwagę na to, że mimo dołą­ czania wszystkich stron JS F reprezentujących właściwą treść (w tym przypadku material o czterech prezydentach) wizualizacji podlega wyłącznie treść właściwa dla wybranej zakładki. Takie rozwiązanie jest możliwe dzięki zastosowaniu atrybutu rendered — w przypadku strony jefferson.jsp odpowiednia konstrukcja ma następującą postać:

Oeorge Washington był pierwszym prezydentem Stanów Zjednoczonych. U''odziiste w roku i? 32 w stanie Wirgsma. W roku ¡775 został mianowany naczelnym wodzem Armn Kontynentalnej. Szesc łat później zmusił do zbzenm kapitulacji Charlesa Carnwalłtsapad Yorklown. Urząd prezydenta Stanów Zjednoczonych objął 30 kwietnia ¿789 roku.

s ly 1eClass ="#{ip .jeffersonStyle}" act i oriL i s tener-"#{ Lp. jef f ersonAct i on} "> <%-- Panel główny --%>

include file="jefferson.jsp" %> <%$ include file="roosevelt.jsp" %> <%@ include file="lincoln.jsp" %> include file="washington.jsp" %>

Panel podzielony na zakładki zaimplementowano z wykorzystaniem znacznika h: panel Gri d. Ponieważ zrezygnowaliśmy z przypisywania jakiejkolwiek wartości atrybutowi col umns, nasz panel będzie się składał tylko z jednej kolumny. Nagłówek panelu (zdefiniowany w formie znacznika f: facet) zawiera zakładki zaimplementowane za pomocą kolejnego znacznika h: panel Gri d obejmującego po jednym znaczniku h:commandLink dla każdej zakładki. Jedyny wiersz naszego panelu zawiera opis właściwy dla wybranej zakładki.

283

Na rysunku 7.12 przedstawiono strukturę katalogów opisywanej aplikacji. Kod źródłowy tego przykładu przedstawiono na listingach od 7.20 do 7.28.

Rysunek 7.12. Struktura katalogów naszej przykładowej aplikacji

¡3 tabbedpane.war y-|«I META-INF | L D MANIFEST.MF f-ü3 WEB-INF | classes | | fcom j | f ■(¡3 corejsf | | f Ew3util | ! I L-D Messages.class !

|

j-- Q TabhedPane.class

\

|

L~ Q messages, properties

|

A Q faces-config.xml

| D web.xml f - (¡3 images | D jefferson.jpg |

j-~ D iirtcoln.jpg

|

S'- Q roosevelt.jpg

s

L Q washington.jpg

j- D styles.css !" D index.html j-- Q index.jsp

[ -D jefferson.jsp j- D tincoin.jsp I—Q roosevelt.jsp L‘ - Q washington.jsp

284

Rozdział 7. ■ Obsługa zdarzeń

JavaServer Faces

I M Implementacja referencyjna JSF obejmuje katalog sampłes> w którym można znaleźć ■ ¿ J całkiem sporo aplikacji przykładowych. Jedna z nich (umieszczona w pliku Jsf-components.war) ilustruje działanie kom ponentu panelu podzielonego na zakładki. M im o że dołączane kom ponenty przykładowe m ają na celu bardziej prezentowanie ogólnych koncepcji i założeń niż im plem entow anie gotowych rozwiązań, warto je wykorzystywać na wczesnych etapach realizacji własnych projektów (w tym prac nad własnymi kom­ ponentam i niestandardowym i).

Listing 7.20. Kod strony tabbedpane/web/index.jsp 1 2 3 4. 5. 6. 7. 8. 9. 10 . 11.

<%G laglib un-"h|;tp7/java.sun.com/jsf/core" prefix="f" %> Laglib un ="nttp://java.sun corn/jsf/htrnl" prefix="h' %>

12.

13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36 37. 38. 39 40. 41. 42. 43. 44. 45. 46.

<%- Zakładki --*>
47 48

sty leClass="/f{ tp.wasrnngtonStyle}" act i onus tener=“#{ tp.washmgtonAct ion}">

49

50 51 52 53 54 55 <%■ ■ Zawartość panelu z zakładkami ■■%> 56 57 <%G include fi le="wasmngton.jsp" °x> 58 <%G include i i le="rooseveU. jsp" %> 59 include f i ie=" 1incoln. jsp" %> 60 <70@ include f 11e="jefferson.jsp" 70> 61. 62 63. 64. 65.

Listing 7.21. Kod strony tabbedpane/web/jefferson Jsp 1. 3.

4. 7. 8.

Listing 7.22. Kod strony tabbedpane/web/roosevelt.jsp______________________________ 1. 3. 4. 5. 7. 8 .

Listing 7.23. Kod strony tabbedpane/web/lincoln.jsp________________________________ 1. 3.

4. 5. 7. 8 .

285

286 Listing 7.24.

Rozdział 7. ■ Obsługa zdarzeń

JavaServer Faces Kod strony

tabbedpan

1. 3. 4 5. 7. 8

Listing 7.25. Plik właściwości tabbedpane/src/java/com/corejsf'/messages.properties windowTitle=Przykład panelu podzielonego na zakładki lincolnTooltip=Abraham Lincoln 1incolnTabText=Abraham Lincoln lincolnDiscussion=Prezydent Lincoln przeszedł do historii jako Wielki \ Emancypator, ponieważ w ogromnym stopniu przyczynił się do zniesienia \ niewolnictwa na terenie Stanów Zjednoczonych. Urodzony w 1809 roku wychował \ się w biednej rodzinie w stanie Kentucky. Na urząd prezydenta został wybrany \ w roku 1860. Zginął w zamachu w 1865 roku z rąk Johna Wilkesa Bootha. 10

washi ngtoriTooltip=George Washi ngton

1 1 . washi ngtoriTabText=George Washi ngton 12 washingtoriDiscussion=George Washington był pierwszym prezydentem Stanów \

13. Zjednoczonych Urodził się w roku 1732 w stanie Wirginia. W roku 1775 został \ 14. mianowany naczelnym wodzem Armii Kontynentalnej. Sześć lat później \ 15. zmusił do złożenia kapitulacji Charlesa Cornwallisa pod Yorktown Urząd \ 16. prezydenta Stanów Zjednoczonych objął 30 kwietnia 1789 roku. 17. 18 rooseveltToolti p=Theodore Roosevelt 19 rooseveltTabText=Theodore Roosevelt 20 rooseveltDiscussion=Theodore Roosevelt był 26. prezydentem Stanów Zjednoczonych. \ 21. Został prezydentem w roku 1901 po zamachu na prezydenta McKinley’a. Urząd \ 22. prezydenta objął w wieku 42 lat i przeszedł do historii jako najmłodszy \ 23. prezydent w historii Stanów Zjednoczonych. 24. 25 jeffersonTooltip=Thomas Jefferson 26. jeffersonTabText=Thomas Jefferson 27. jeffersonDiscussion=Thomas Jefferson, trzeci prezydent Stanów Zjednoczonych, \ 28. urodził się w roku 1743 w stanie Wirginia. Jefferson był znany z doskonałych \ 29. przemówień. W roku 1785 objął urząd ministra ds. Lrancji, na którym zastąpił \ 30. Benjamina Lranklina. W roku 1796 Jefferson niechętnie zgodził się kandydować \ 31. na urząd prezydenta, ale przegrał wybory zaledwie trzema głosami. Prezydentem \ 32. Stanów Zjednoczonych został w 1801 roku i pełnił ten urząd przez 8 lat.

Listing 7.26, Plik arkusza stylów tabbedpane/web/styles.css 1 body { 2. background- #eee; 3 } 4. .tabbedPaneHeader { 5. vertical-align: top, 6. text-align: left; 7 padding. 2px 2px Opx 2px,

9. tabbedPaneText { 10. font-size: l.Oem, 11. font-style- regular, 12 padding 3px; 13 border thin solid CornflowerBlue, 14 } 15. tabbedPaneTextSelected { 16 font-size l.Oem, 17 font-style. regular. 18. padding 3px; 19. background. PowderBlue; 20 border thin solid CornflowerBlue, 21

}

22 23 24 25. 26 27. 28. 29 30 31. 32 33. 34. 35. 36. 37. 38. 39 40. 41. 42. 43.

.tabbedPane { vertical-align: top, text-align- left; padding lOpx, } .displayPanel { vertical-align: top; text-align left; padding. 10px; } .tabbedPaneContent { width- 100%; height. 100%, font-style ita lic ; vertical-align top; text-align. left; font-size- 1 . 2m; } .presidentDiscussionColumn { vertical-align- top, text-align: left; }

Listing 7.27. Plik konfiguracyjny tabbedpane/web/WEB-iNF/faces-config.xmi 1 . 2
9 10 . 11. 12 .

xmlns:xsi="http://www.w3.org/2001/XMLSchema-i nstance" xsi •schemaLocation="http://java.sun.com/xml/ns/javaee http ://java.sun.com/xml/ns/javaee/web-facesconfi g_l_ 2 .xsd" version="1 . 2 "> com.corejsf messages msgs

13. 14. 15. tp 16. coni.corejsf.TabbedPane 17. session 18. 19.

287

288

JavaServer Faces

Rozdział 7. ■ Obsługa zdarzeń

Listing 7.28. Kod klasy tabbedpane/src/java/com/corejsf/TabbedPane.java 1 . package com.corejsf; 2. 3. import javax.faces.event.ActionEvent; 4. 5. public class TabbedPane { 6. private int index; 7. private static final int JEFFERSON_INDEX = 0; 8 private static final int ROOSEVELT_INDEX = 1; 9. private static final int LINCOLN_INDEX = 2; 10. private static final int WASHINGT0N_INDEX = 3, 11 .

12. 13. 14. 15. 16. 17. 18. 19. 20 2 1. 22 . 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40 . 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55.

private String[] tabs = { "jeffersonTabText", "rooseveltTabText", "lincolnTabText", "washingtonTabText", }; private String[] tabTooltips = { "jeffersonTooltip", "rooseveltTooltip", "lincolnTooltip", "washingtonTooltip" }; public TabbedPaneO { index = JEFFERSON_INDEX;

} I I metody nasłuchujące akcji odpowiedzialne za ustawianie bieżącej zakładki public public public public

void void void void

jeffersonAction(ActionEvent e) { index =JEFFERSON_INDEX, } rooseveltAction(ActionEvent e) { index =R00SEVELT_INDEX; } lincolnAction(ActioriEvent e) { index =LINC0LN_INDEX; } washingtonAction(ActionEvent e) { index =WASHINGT0N_INDEX; }

// style CSS public public public public

String String String String

getJeffersonStyleO { return getCSS(JEFFERSON_INDEX); } getRooseveltStyle() { return getCSS(R00SEVELT_INDEX); } getLincolnStyle() { return getCSS( LINC0LN_INDEX); } getWashingtonStyleO { return getCSS(WASHINGT0N_INDEX); }

private String getCSS(int forlndex) { return forlndex == index ? "tabbedPaneTextSelected" : "tabbedPaneText"; }

I I metody określające bieżącą zakładkę public public public public

boolean boolean boolean boolean

isJeffersonCurrentO { return index == JEFFERSON_INDEX; } isRooseveltCurrentO { return index == ROOSEVELTJ NDEX; } isLincolnCurrentO { return index == LINCOLN_INDEX; } isWashingtonCurrentO { return index ==WASHINGT0N_INDEX; }

U metody zwracające podpowiedzi dla tytułów zakładek public String getJeffersonTooltip() { return com.corejsf.util.Messages.getString( "com.corejsf.messages", tabTooltips[J EFFERSON_INDEX], nuli); } public String getRooseveltTooltipO { return com.corejsf.util.Messages.getString( "com.corejsf.messages", tabToolti ps[ROOSEVELT_INDEX], nuli);

56 57. 58. 59. 60. 61. 62. 63. 64. 65. }

} public String getLincolnTooltipO { return com.corejsf.util.Messages.getString( "com.corejsf messages", tabTooltips[LINCOLN_INDEX], nuli); } public String getWashingtonTooltip() { return com.corejsf.util.Messages.getString( "com.corejsf messages", tabToolti ps[WASHI NGT0N_INDEX], nuli); }

289

290

JavaServer Faces

8

Podwidoki i pakiet Apache Tiles Interfejsy użytkownika z reguły cechują się największą zmiennością w procesie wytwarzania aplikacji internetowych, stąd konieczność tworzenia możliwie elastycznych i rozszerzalnych rozwiązań w tym obszarze. W niniejszym rozdziale przeanalizujemy techniki osiągania ta­ kiej elastyczności i rozszerzalności przez dołączanie do wielu stron wspólnych elementów. W pierwszej kolejności skoncentrujemy się na standardowych mechanizmach technologii JS P (konstrukcjach dołączania i importowania biblioteki JS T L ), które można z powodzeniem wykorzystywać do definiowania wspólnych elementów interfejsu w ramach aplikacji JSF . W dalszej części tego rozdziału omówimy techniki stosowania pakietu Apache Tiles (umoż­ liwiającego między innymi definiowanie zarówno właściwej treści, jak i jej rozmieszczenia) łącznie z technologią JavaServer Faces.

Typowe rozmieszczenia Wiele popularnych witryn internetowych, w tym nytimes.com, allegro.pl i amazon.com, zbu­ dowano na bazie tego samego, bardzo popularnego układu. Wszystkie wymienione witryny cechuje typowe rozmieszczenie: nagłówek, menu, treść (patrz rysunek 8.1).

Rysunek 8.1. Typowe rozmieszczenie elementów na stronie internetowej

NAGŁÓWEK

MENU

TREŚĆ

292

JavaServer Faces

Rozdział 8. ■ Podwidoki i pakiet Apache Tiles

Efekt rozmieszczenia przedstawionego na rysunku 8.1 można oczywiście osiągnąć z wyko­ rzystaniem ramek języka H TM L, jednak stosowanie ramek jest z kilku względów niepożą­ dane. Ramki powodują na przykład utrudnienia w dodawaniu stron do zbioru stron ulubio­ nych. Ramki generują też odrębne żądania, co w przypadku aplikacji internetowych może stwarzać poważne problemy. Ogólnie, lepszą techniką jest dołączanie treści, czyli rozwiązanie, którym zajmiemy się w tym rozdziale.

293

Rysunek 8.3. Biblioteka

K IŁ

\

Piotruś Pan

Przeglądarka książek i biblioteka

Rozdział 5 Rozdaał 2 Rozdaał 3.

Aby jak najlepiej zilustrować techniki implementacji rozmieszczeń (układów), dołączania wspólnych elementów treści oraz stosowania pakietu Tiles, przeanalizujemy w tym rozdziale dwie przykładowe aplikacje: przeglądarkę książek i bibliotekę. Wybrane strony tych aplikacji przedstawiono odpowiednio na rysunkach 8.2 i 8.3.

Rozdaał 4. B-ozdaał 5

Rysunek 8.2. Przeglądarka książek

s* *** » «

h««»

Rozdaał 8

Rozdaał i 1 Rozdaał U Rozdaał 14 Rozdaał i o

**•*•

m

tmp./'iocahost;9O9O/bool'-viewe>-tile>/tiO0k feces'c ła )

Znacie zapewne wszyscy Mak; Domek w parku Jest to jedyny domek na swiecie który elfy zbudowały dla luda Mało daem jednak widaało go naprawdę, może dwoje albrt najwvzei troie. i

Rozdział i I Przeglądarka k^ąże|— M

Mały domek

to musiały w mm przenocować ł'>o inaczej mo mogłyby go zolaczyć

Bo b e J v daeck-,- się J,; snu

ubada, domku me ma jeszcze wcale, a b edy się obuda z rana. w ida go jak na dłom Tylko coś mec oś tn^zna zen zobduzyc, a mianowicie światło w tego oknach, ale i to dopieio „po dzwonku

Amelcia Claie (ta. co tak chętnie dair sobie plombować zęby, bo za to biorą ją do

cubemi) widuje czasem po kilkaset świateł na raz Zapewne w tej chwik elfy budują swói domek bo teraz buduią g> każdego wieczora, ale co daen w mnei części parku Aniela się wydawało, ze ledno światełko bvło większe od innych, ale na pewno tego puwi^darc me mogła, bo tyle innych świateł migotało i przesłaniało go. ze trudno Kyło rozpoznać, czy to lest to samo Jeżeli lednak między światełkami migocącymi w Parku Leśnym iest jedno największe będzie to z pewnością latarka Piotrusia Pana Bardzo duzo dzieci widziało te svziatelka w parku, ale pierwszym dzieebern. dla którego elfy zbudowały swój domek była Toma Mamenng Toma była zawsze niezwykłą dziewczynką, a iuz wieczorem stawała się wprosi nadzwyczajną M ała juz ezteiy lata i w dzień zachowywała się iak inne dziewczynb w iej wieku Cieszyła się

Alicja w Krainie Czarów

bardzo, jeżeli jei sześcioletni braciszek Jas pozwolił się jei bawtr z sobą, naśladowała go we wszystkim i me gniewała się wrale, jeżeli w zabawie poturbował ją nawei troszkę W ogolę z Jasia była baidzo dumna, uważała go bowiem za ideał rozumu i dzielności Potrafiła także pokazać, ze

Rozdział 1.

Rozdział 1

ma nowe b u aczb na nóżkach w chwili gdy powinna bvła złapać rzuconą jei piłkę Jednym

Rozdział .2, Rozdział 3.

słowem w dzień Toma podobna była do wszystbeh małych dziewczynek

Przez króliczą norę

Rozdział 4

Ale po.d wieczór b ed y zmrok zaczynał zapadać, dziea zmieniały się najzupełniej Tęgi bajeczny

Rozdaał 5.

Alicja miała juz dość siedzenia na ławce obok siostry i próżnowania Raz czy dwa razy zerknęła do

Rozdział $ .

książki, którą czytała siostra Niestety w książce me było obrazkow amrozmow "A cózjesl warta

niespokojnie, bo im ciemniej i obiło się w pokoju tvm mocniej błyszczały oczy małej Tom Wztok

Rozdział ?

książka

jej lasmal spokojnym taiemmczym bbsbem , a oczy Jasia pełne były lęku i grozy W tabej chwili

Rozdział 9.

Alicja rozmyślała właśnie

Rozdaał 10.

niemrawą - czy warto męczyć się przy zrywaniu stokrotek po to, abv uwić z mch wianek Nagle tuz

Rozdział 11.

obok mej przebiegł Biały K rólik o rozowych ślepkach

pomyślała Alicja

w której me ma rozmow am obrazków-?"

Jas, który w dzień tak przewodził nad młodszą siostrzyczką, raz po raz oglądał się na mą

Jaś oddawał Tom naiulubieńsze swoje zabawb i.nazajutrz odbierał je z powrotem) a Toma a raczej starała się rozmyślać, ponieważ upał czynił ją bardzo senną i

Rozdział 12. 'Właściwie me było w tym mc nadzwyczajnego Alicja me dziwiła się nawet zbytnio słysząc, jak K rólik szeptał do siebie 'O rety, o rety, na pewno się spóźnię' Dopiero b edy Królik wyjął z beszonb od kamizelb zegarek, spojrzał nań i puścił się pędem w dalszą drogę. Akcja zerwała się na równe nogi Przyszło jej bowiem na myśl, ze nigdy przedtem me widziała królika w kamizelce am królika z zegarbem Płonąc z ciekawości pobiegła na przełaj przez pole za Białym Królibem i zdązyła jeszcze spostrzec, ze znikł w sporej norze pod żywopłotem Wczołgała się więc za mm do krókczej nory me myśląc o rym, jak się pózmej stamtąd wydostanie N o ra była początkowo prosta niby tunel, po czvm skręcała w dół tak nagle, ze Akcja me mogła juz się zatrzymać i runęła w orwor przypominający wylot głębobej studni Studnia była widać tak głęboka, czy może Akcja spadała tak wolno, ze miała dość czasu, aby

Obsługa aplikacji przeglądarki książek jest dość intuicyjna. Po kliknięciu łącza reprezentu­ jącego rozdział odpowiedni rozdział jest prezentowany w obszarze treści na danej stronie. Aplikacja biblioteki jest w istocie rozszerzeniem przeglądarki książek i umożliwia użytkow­ nikowi czytanie więcej niż jednej publikacji. Książki można wybierać z menu widocznego w górnej części strony internetowej. Przykład przeglądarki książek poddamy analizie w następujących punktach: ■ „Monolityczne strony JS F ";

rozejrzeć się dokoła i zastanowić nad tym, co się dalej stanie Przede wszystkim starała się dojrzeć dno studni, ale jak to zrobić w ciemnościach9 Zauważyła jedynie, ze ściany norv zapełnione bvły szafami i półkami na ksiązb Tu i ówdzie wisiały mapy i obrazb M ijając jedna z półek Akcja zdązyła zdjąć z mej słój z nabejką Marmolada pomarańczowa Niestety był on pusty Akcja me upuściła słoja, obawiając się, ze może zabić mm kogoś na dole Postawiła go po drodze na jednej z mzszych półek 'No. no

■ „Dołączanie wspólnej treści"; ■ „Prezentacja pakietu Apache Tiles"; ■ „Parametryzacja kafelków";

pomyślała - po tej przygodzie żaden upadek ze schodów me zrobi juz na mnie wrażenia

W domu zdziwią się. ze jestem taka dzielna Nawet gdybym spadła z samego wierzchołka

---

„Rozszerzanie kafelków",

294

JavaServer Faces

Rozdział 8. ■ Podwidoki i pakiet Apache Tiles

Przykład aplikacji biblioteki ilustruje zagadnienia omówione w następujących punktach:

295

Klasa Book wykorzystuje właściwość numChapters do wyznaczenia odpowiednich kluczy rozdziałów.

■ „Kafelki zagnieżdżone” ;

W implementacji klasy Book trudno się doszukać szczególnie interesujących aspektów. Kod tej klasy przedstawiono na listingu 8.3 w dalszej części rozdziału. Poniżej przedstawiono kod definiujący egzemplarz tej klasy w pliku konfiguracyjnym faces-config.xml:

■ „Kontroler kafelków” . Do analizy aplikacji przeglądarki książek przystąpimy już w kolejnym podrozdziale zatytu­ łowanym „Przeglądarka książek” . Aplikację biblioteki omówimy w podrozdziale „Biblioteka” .



P U Na potrzeby przykładów prezentowanych w tym rozdziale wykorzystamy tekst książek ■MW pt. Alicja w Krainie Czarówautorstwa Gharlesa Lutwidge’a Dodgsona oraz Przygody Piotrusia Pana autorstw a Jam esa M a tth ew B arrie'ego, które podzielono na rozdziały i przekonwertowano na form at HTML.

Przeglądarka książek Aplikacja przeglądarki książek oferuje dość ograniczoną funkcjonalność. Prezentuje zaledwie jedną książkę reprezentowaną przez komponent zarządzany, który zdefiniowano w pliku konfiguracyjnym. Wspomniany komponent nazwano book. Komponent book obejmuje następujące właściwości: ■ titleKey ■ image ■ numChapters ■ chapterKeys Właściwość titleKey reprezentuje klucz tytułu książki składowanego w pliku komunikatów. W pliku właściwości aplikacji przeglądarki książek zdefiniowano następującą parę kluczwartość: titleKey=Al icja w Krainie Czarów. Właściwość titleKey wykorzystujemy podczas wyświetlania tytułu strony:

Właściwość image reprezentuje łańcuch. Aplikacja interpretuje ten łańcuch jako adres U R L wskazujący na obraz wyświetlany w nagłówku strony:

Właściwość chapterKeys reprezentuje listę kluczy (po jednym dla każdego rozdziału) i jest dostępna tylko do odczytu. Aplikacja przeglądarki książek wypełnia obszar menu odpowied­ nimi wartościami odczytanymi z pakietu komunikatów:


tytuł i poziomą linię —%>

296

Rozdział 8. ■ Podwidoki i pakiet Apache Tiles

JavaServer Faces

---

297

¡3 book-viewer.war fm eta-inf

Rysunek 8.4. Struktura katalogów aplikacji przeglądarki książek

I

L Q MANIFEST.MF

f C3 WEB-INF j

L ( ¡ 3 c la s s e s

M Î Ö com Ï I f ö corejsf ; ! i Q Book, class

obejmująca menu z łączami do rozdziałów —%>



1 Q messages, properties

‘

\

j

! Q faces-config.xml

\

’ - Q web. xml

; D styles, css j- Q chapterl.html j- Q chapterl0.html : Q chapterll.html : D chapte.rl2.html 0 cnapter2 html



Q cnapter3 html



Q chapter4 html Q coaoTerS htmi



Q chapter^ htmi



____

Listing 8.1. Kod strony book-viewer/web/book.jsp 1. 2. taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> 3. taglib uri="http://java.sun.com/jsf/core" prefix="f" 70> 4. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 5. 6. 7. 8. 9. <1ink href="styles.css" rel="stylesheet" type="text/css"/> 10. 11. 12.

13. 14 15. 16. 17. 18. 19. 20. 21.


Dołączanie treści w ramach aplikacji przeglądarki książek

[ D chapter6.html F D chapter7.html [- D chapter8.html F

D

chapter9.html

j D index.html r D cheshire.jpg j- D book.jsp

Aby dołączyć treść w ramach przeglądarki książek, należy podzielić naszą monolityczną stronę JS F na cztery odrębne pliki: oryginalną stronę JS F oraz strony /header.jsp, /menu,jsp i /contentjsp. Do naszej oryginalnej strony JS F będziemy dołączali nagłówek, menu i wła­ ściwą treść:

303

p Q bookContent.jsp F Q bookH.e-ader.jsp ! - D bookMenu.jsp__________

Listing 8.6. Kod strony book-viewer-inciude/web/book.jsp 1. <%@ tagllb uri="http7/java.sun.com/jsp/jstl/core" prefix="c" %> 3. <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 4. <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>

2.

5.

6. A 8.



305

Prezentacja pakietu Apache Tiles W iem y już, jak dołączać treść do stron aplikacji internetowych i jak stosowanie tej techniki wpływa na poprawę elastyczności budowanych rozwiązań — jeśli właściwa treść nie jest wymieszana z pozostałym kodem, tylko dołączana, jej ponowne wykorzystywanie jest dużo łatwiejsze. Skoro możemy teraz tworzyć interfejsy użytkownika z wymiennymi elementami, wydaje się, że osiągnęliśmy właściwy poziom elastyczności. Warto jednak zwrócić uwagę na jeszcze jedno, bardzo kuszące rozwiązanie. Dołączanie treści to nie wszystko — można jeszcze wykorzystać pakiet Apache Tiles do dołączania rozmieszczenia (układu strony). W przypadku aplikacji z rysunku 8.2 dołączanie rozmieszczenia umożliwiłoby wielokrotne wykorzystywanie kodu układu (czyli znacznika h: panel Gri d i jego zawartości przedstawionych na listingu 8.6). Kod układu przedstawiony na listingu 8.6 może być wykorzystywany wyłącznie przez stronę JS F przedstawioną na ry­ sunku 8.2. Oznacza to, że gdybyśmy chcieli stosować identyczny układ na innych stronach JS F , w każdej z nich musielibyśmy ten kod powielić. Za pomocą pakietu Tiles możemy zdefiniować pojedynczy układ, by następnie wielokrotnie go wykorzystywać w ramach wielu tzw. kafelków (ang. tiles). Takie rozwiązanie umożliwiłoby nam implementację kodu rozmieszczenia tylko raz i wielokrotne stosowanie tej konstrukcji w ramach wielu stron aplikacji.

Listing 8.7. Kod strony book-viewer-include/web/bookHeaderjsp 1. taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 2. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 3. 4. 5. 6. 7.

---

8.

Listing 8.8. Kod strony book-viewer-include/web/bookMenu.jsp 1. taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 2. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 3. 4. 6. 7. 8. 9. 10. 11.



12.



Listing 8.9. Kod strony book-viewer-include/web/bookContent.jsp_________________ 1. <7@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

2. 3.

Okazuje się, że wielokrotne wykorzystywanie rozmieszczeń jest tylko jednym z zastosowań pakietu Apache Tiles. Część z nich wymieniono poniżej: ■ zagnieżdżanie kafelków; ■ rozszerzanie kafelków; ■ ograniczanie dostępu do kafelków dla użytkowników występujących w określonych rolach; ■ dołączanie do kafelków kontrolerów (obiektów Javy) wywoływanych bezpośrednio przed wyświetlaniem tych kafelków. Te najważniejsze elementy funkcjonalności pakietu Tiles mają na celu osiąganie możliwie wysokiej elastyczności w procesie wytwarzania interfejsów użytkownika aplikacji interne­ towych.

Instalacja pakietu Tiles Stosowanie pakietu Tiles wymaga użycia autonomicznego pliku JA R . Odpowiedni plik dołączono do kodu źródłowego opracowanego z myślą o tej książce. Kiedy już będziemy dysponowali plikiem JA R pakietu Tiles, instalacja tego pakietu w ramach naszej aplikacji będzie polegała na wykonaniu następujących kroków: 1.

Skopiowanie pliku JA R pakietu Tiles do katalogu WEB-INF/lib tej aplikacji.

306

JavaServer Faces 2. Dodanie serwletu Tiles do deskryptora wdrożenia [web.xml). Stosując element 1oad- on -startup, możemy zagwarantować ładowanie serwletu Tiles w momencie

uruchamiania naszej aplikacji internetowej. W naszym przypadku wspomniany deskryptor wdrożenia powinien mieć następującą postać: Faces Serviet javax.faces.webapp.FacesServlet l Tiles Servlet org.apache.t i l es.servlets.TilesServlet 2

Stosowanie pakietu Tiles w ramach aplikacji przeglądarki książek Stosowanie pakietu Apache Tiles łącznie z technologią JS F jest procesem trzy etapowym: 1. wykorzystanie znacznika t i 1es: i nsert do wstawienia definicji kafelka w ramach stron JS F ;

2. zdefiniowanie kafelka w pliku konfiguracyjnym pakietu Tiles; 3. implementacja układu kafelka. W przypadku aplikacji przeglądarki książek powinniśmy w pierwszej kolejności umieścić kafelek nazwany book w kodzie strony book.jsp : <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>

Kafelek book należy zdefiniować w pliku konfiguracyjnym /WEB-INF/tiles.xml: d efin ition name="book" path="/headerMenuContentLayout.jsp">

Rozdział 8. ■ Podwidoki i pakiet Apache Tiles

307

Powyższy fragment kodu XM L-a definiuje pojedynczy kafelek. Układ tego kafelka definiu­ jem y za pośrednictwem atrybutu path elementu def i ni ti on. Tak zdefiniowane rozmiesz­ czenie jest uzależnione od atrybutów kafelka (określone z wykorzystaniem elementów put). Układ analizowanej aplikacji można by opisać następująco: < % — kod strony /headerMenuContentLayout.jsp

—%>

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>

Znacznik t i 1es: i nsert dynamicznie dołącza odpowiednią treść. Dołączana treść jest repre­ zentowana przez wartość atrybutu a ttri bute użytego w ramach znacznika t i 1es: i nsert. Na przykład w powyższym fragmencie kodu jednemu z atrybutów przypisano wartość header. Ponieważ wspomniana wartość reprezentuje stronę /bookHeader.jsp, odpowiedni znacznik ti 1es: i nsert dynamicznie dołączy właśnie ten plik. Łatwo zauważyć, że we wszystkich znacznikach t i l es: i nsert dodatkowo przypisaliśmy atrybutowi flush wartość false. Taki krok jest konieczny w przypadku większości współ­ czesnych kontenerów serwletów, które nie oferują możliwości opróżniania buforów w ramach znaczników niestandardowych. Jeśli nasz kontener generuje wyjątek wskazujący na brak możliwości opróżniania bufora z poziomu znacznika niestandardowego, możemy być pewni, że faktyczną przyczyną błędu jest omyłkowe pominięcie tego atrybutu (którego domyślną wartościąjest false). Co właściwie zyskujemy, stosując pakiet Apache Tiles w naszej przykładowej aplikacji? Oddzielenie układu (rozmieszczenia) od właściwej treści, umożliwia nam jego wielokrotne wykorzystywanie w imiych kafelkach (zamiast powielać kod układu we wszystkich stronach JS F ). Moglibyśmy na przykład wykorzystać układ aplikacji przeglądarki książek (zaim­ plementowany w kodzie strony /headerMenuContentLayout.jsp) w pozostałych stronach tej samej aplikacji.

308

Rozdział 8. ■ Podwidoki i pakiet Apache Tiles

JavaServer Faces

Rozszerzanie kafelków

Parametryzacja kafelków Układ przedstawiony w poprzednim punkcie ma jedną zasadniczą wadę — obejmuje trwale zakodowane klasy C SS nazwane gridClass, headerClass, menuClass i contentClass. Ozna­ cza to, że wszystkie strony zbudowane z wykorzystaniem rozmieszczenia nagłówek, menu, treść będą się cechowały identycznym wyglądem i sposobem obsługi. W tej sytuacji bardzo pożądana byłaby możliwość parametryzacji nazw klas CSS. Pozostałe kafelki wykorzystujące układ nagłówek, menu, treść mogłyby wówczas definiować własny wygląd i sposób obsługi. W tym punkcie dokonamy analizy sposobu realizacji tego celu. W pierwszej kolejności dodamy trzy atrybuty do kafelka book:

Użyte w powyższym fragmencie kodu atrybuty kafelków (w tym headerClass, menuClass itp.) obejmują zasięgiem tylko kafelki i jako takie nie są dostępne z poziomu kodu JS F . Aby udostępnić nasze atrybuty stronie JS F definiującej rozmieszczenie, należy użyć znacznika ti les: importAttribute. Znacznik tile s : ímportAttnbute importuje wszystkie atrybuty do zakresu wskazanego za pośrednictwem atrybutu scope. W powyższym przykładzie zaimpor­ towano atrybuty do zasięgu żądania. Możemy teraz stosować różne klasy C SS dla poszczególnych kafelków:

dodatkowo umożliwia nam im portowanie poje óego rozwiązania je s t następująca konstrukcja:

’Class" scope»"...






1 ■Q messages.properties

j ?■ E S lib I j • Q tiles-core-SNAPSHOT.jar ; j- Q faces-config, xml j ¡- Q tiles.xml ;

Q web.xml

f ■D sîytes.css i- D chapterl.html j- D chapteri0.html j-- Q chapterll.htmf

F D chapterl2.html D chapter2.html j- Q chapter3.html |-- Q chapter4.html \ Q chapter5.html F

D chapters, html

r D chapter7.html F

D chapter8.html

F Q chapters*.htmf

Listing 8.11. Kod strony book-vlewer-tiles/web/headerMenuContentLayout.jsp 1. 2 3. 4. 5.

<%@taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%@taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <%@taglib uri="http://jakarta.apache.org/tiles" prefix="tiles"

%>



6.

7. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.

F Q index.htmf F

D cheshire.jpg

|~ D book.jsp F D bookContent.jsp F Q bookHeader.jsp F

D bookMenu.jsp Q headerMenuContentLayout.jsp

Na listingach od 8.10 do 8.12 przedstawiono plik definicji kafelków, plik opisujący układ strony oraz kod strony JS F prezentującej książkę Alicja w Krainie Czarów. Zrezygnowano z ponownego przedstawiania listingów pozostałych plików tej aplikacji, ponieważ niczym się nie różnią od listingów zaprezentowanych we wcześniejszej części tego rozdziału.

Listing 8.10. Plik definicji kafelków book-viewer-tiles/web/WEB-INF/tiles.xml____________________________ 1. 4. 5. 6 d efinition name="book" path=,7headerMeriuContentLayout.jsp"> 7. 8. 9. 10 11.

12 13. 14. 15. 16.

Listing 8.12, Kod strony book-viewer-tiles/web/bookjsp 1. 2. <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> 3. <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 4. <%G taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 5. <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %>

6. 7 8. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.

311

312

JavaServer Faces

Rozdział 8. ■ Podwidoki i pakiet Apache Tiles

Biblioteka

313

Kafelki zagnieżdżone

W tym podrozdziale spróbujemy przekształcić przeglądarkę książek w bibliotekę (patrz rysunek 8.7).

Aplikacja biblioteki, którą przedstawiono na rysunku 8.7, obejmuje przeglądarkę książek. W tej sytuacji przeglądarka książek powinna być zawarta także w kafelku 1i b r a r y :

Rysunek 8.7.



Biblioteka zaimplementowa na w technologii JSF z wykorzystaniem kafelków



__ ■! Phk

laycjs *

Widok

Historia

Ćy - ¡Ęj

¿¡udacr,:,

^ j

■

Naaęozia



: :

Parncc.

90

http://locaino>t: U'J .'library.'libraiy.face ch.aptet=.:h

E j !|C|.r!

■ •

!>vj

Warto zwrócić uwagę na wartość przypisaną atrybutowi book — tym razem nie jest to strona JSP , tylko kafelek. Stosowanie nazw kafelków (zamiast stron JS P ) umożliwia nam zagnież­ dżanie kafelków, w tym przypadku kafelka book, w ramach biblioteki. Aficja w Krainie Czarów f/Ęj SMoteka Gutenfcercja Plik

Edycja

wtem

• si!$& -

Historia i?',f | j) | !

¿akraaki

Kontroler kafelków

tera

Irttp://localhost|9090/libiaiy/libraiyi»ces

iWybierz książkę j

W naszej aplikacji przeglądarki książek wykorzystywaliśmy tylko jeden komponent zarzą­ dzany, nazwany book (więcej informacji o tym komponencie można znaleźć w podrozdziale „Przeglądarka książek"). Z drugiej strony, nasza biblioteka musi oferować obsługę więcej niż jednej książki.

Bvii>v ,vam trudn' zrozumie' przvgn L Piotrusia Pana

rn- w r laeL i
Leśny Park ten jest olbrzymi i lezy w pobliżu bardzo wielkiego miasta, w którym mieszka król Prawie codziennie chodzimy z Daniem do parku i Danio jest wprost oszołomiony mnóstwem wrażeń, jakich tam doznaje Nigdy jeszcze żadne dziecko me zwiedziło całego parku za jednym razem, bo malcy w wieku Dama muszą sypiać od dwunastej do pierwszej w południe i dlatego trzeba spieszyć z powrotem do domu Gdyby jednak wasze mamy me przestrzegały tak koniecznie tego spania od dwunastej do pierwszej w południe, to może moglibyście zwiedzić cały Park Leśny w jednym i tym samym dniu Przed parkiem ciągnie się nieskończenie długi sznut dorożek, nad którymi wasze piastunki mają taką władzę, ze skoro palec do góry podniosą, dorożka staje, a wtedy dzieci przechodzą swobodnie na drugą stronę ulicy i zatrzymują się przed wielką, zelazną bramą Bram w parku jest kilka, ale zwykle wchodzi się tą pierwszą U wejścia można zamienić parę słów z „parną od baloników” Pani ta z takim natęzemem całą swą przysadzistą postacią przyciska stołek do bruku chodnika, a plecy do żelaznego ogrodzenia parku, ze twarz jej jest czerwona jak burak Ostrożność ta jest bardzo wskazana, bo gdyby choć na chwilkę puściła się sztachet i stołka,

Przedstawiona na rysunku 8.7 aplikacja biblioteki zawiera między innymi menu w górnej części strony. Za pośrednictwem tego menu użytkownik może wybrać interesującą go książkę: Alicję w Krainie Czarów lub Piotrusia Pana. Pozostałe elementy aplikacji pracują dokładnie tak samo jak w przeglądarce książek, którą omówiliśmy we wcześniejszych podrozdziałach tego rozdziału. W aplikacji biblioteki wykorzystano dwa szczególnie interesujące elementy funkcjonalności pakietu Apache Tiles: zagnieżdżanie kafelków oraz kontrolery kafelków.

W tym punkcie pokażemy, jak opracować rozwiązanie umożliwiające obsługę wielu ksią­ żek bez konieczności modyfikowania istniejącej przeglądarki książek. Nasza przeglądarka nadał będzie operować na komponencie book, ale nie będzie to już komponent zarządzany. Komponent book będzie teraz reprezentował książkę, która została jako ostatnia wybrana z menu rozwijanego w górnej części strony biblioteki. Opisywane rozwiązanie jest możliwe dzięki użyciu kontrolera kafelków. Pakiet Tiles oferuje możliwość dołączania do kafelków obiektów Javy nazywanych kontrolerami kafelków (ang. tile controllers). Klasy tych obiektów muszą implementować interfejs org .apache. struts. ^ t i 1e s. Control 1er definiujący tylko jedną metodę: perform. Pakiet Tiles wywołuje tę metodę bezpośrednio przed załadowanie kontrolera właściwego dla danego kafelka. Kon­ trolery kafelków mają dostęp do kontekstu kafelków, zatem mogą uzyskiwać dostęp do ich atrybutów, a także tworzyć nowe atrybuty. Zdecydowaliśmy się dołączyć kontroler do kafelka 1ibrary. Nasz kontroler próbuje odna­ leźć atrybut 1ibrary w zasięgu sesji. Jeśli taki atrybut nie istnieje, automatycznie tworzy bibliotekę i umieszcza ją w zasięgu sesji. W kolejnym kroku kontroler uzyskuje dostęp do właściwości selectedBook biblioteki, aby sprawdzić, czy wybrano już jakąś książkę. Jeśli tak, kontroler przypisuje wybraną książkę atrybutowi sesji nazwanemu book. W razie braku wybranej książki kontroler przypisuje atrybutowi book wartość właściwą dla Piotrusia Pana. Kod tego kontrolera przedstawiono na listingu 8.20 w dalszej części tego punktu.

314

Rozdział 8. ■ Podwidoki i pakiet Apache Tiles

JavaServer Faces Na rysunku 8.8 przedstawiono strukturę katalogów aplikacji biblioteki. Dla uproszczenia pominięto w prezentowanej strukturze pliki H T M L z treścią oferowanych książek.

Listing 8.14. Plik kotffiguracyby library/web/WEB-INF/tiles.xml 1

9. L library, war C3 META-IMF F Q MANIFEST. MF

Rysunek 8.8. Struktura katalogów aplikacji biblioteki

£3 WEB-INF f -£3 classes | t (¡3 com I T £3 corejsf | t util j | ! Q Messages.class !

f Q Book, class

|

F Q LibraryTHeController.class

i

! Q messages.properties

T D Library, class y ( 3 rtb i 1 Q tiles-core-SNAPSHOT.jar j- Q faces-config.xmf — Q tiles.xml ■ Q web.xml (¡3 books f [¡3 alicelnWonderland

| r-Dj /

Q cheshire.jpg [¡3 peterpan

I j- D |

••

! D peterpan.jpg

Kod zawarty w plikach widocznych na rysunku 8.8 (z wyjątkiem plików H T M L) przedstawiono na listingach od 8.13 do 8.27. Analizując te listingi, warto zwrócić uwagę na łatwość, z jaką możemy dodawać do biblioteki nowe książki — aby utworzyć i dodać do istniejącej struktury nową książkę, wystarczy zmodyfikować konstruktor w pliku Library.java (patrz listing 8.19).

Listing 8.13. Kod strony library/web/library.jsp <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%@ taglib un="http://java.sun.com/jsf/html" prefix="h" %> <%@ taglib uri="http://jakarta.apache.org/tiles" prefix="tiles" %> <1ink href="styles.css" rel="stylesheet" type="text/css"/> 9 10. 11 12. 13

14. 15 / 16. 19 20. 21. 22.

Listing 9,6. Kod klasy spinner/src/java/com/corejsf/CreditCardExpirationjava

Rozdział 9. ■ Niestandardowe Komponenty, Konwertery i mechanizmy weryfikujące 19. 20. 2 1. 22.

349

/index.jsp

23. 24. com.corejsf.Spinner 25. com.corejsf.UISpinner 26. 27. 28. 29. cardExpirationDate 30. com.corejsf.CreditCardExpiration 31. session 32. 33 34. 35. 36. com.corejsf,messages 37. msgs 38. 39. 40.

1. package com.corejsf; 2.

3. 4. 5.

public class CreditCardExpiration { private int month = 1; private int year = 2000;

6. 7.

I I Właściwość month:

8. 9

public int getMonthO { return month; } public void setMonth(int newValue) { month = newValue; }

10. 11.

I I Właściwość year:

12. 13. 14.

public int getYearO { return year; } public void setYear(intnewValue) { year = newValue; } }

Listing 9.7. Plik konfiguracyjny spinner/web/WEB-INF/faces-config.xml 1. 2.
4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17 18.

Listing 9.8. Plik właściwości spinner/src/java/com/corejsf'/messages.properties_________ 1. 2. 3. 4. 5. 6. 7. 8.

windowTitle=Test komponentu kontrolki CreditCardExpirationPrompt=Proszę wpisać datę ważności karty kredytowej: monthPrompt=Miesiąc: yearPrompt=Rok: nextButtonPrompt=Dalej youEnteredPrompt=Wpisałeś: expirationDatePrompt=Data ważności: changes=Zmiany:

Listing 9.9. Arkusz stylów spinner/web/styles.css 1. 2. 34. 5. 6.

body { background: #eee; } .pageTitle { font-size: 1.25em; }

xsi:schemaLocati on="http://java.sun.com/xml I n s /javaee http ://java.sun.com/xml/ns/javaee/web-facesconfi g_l_2.xsd version="1.2,,> /index.jsp next /next.jsp /next.jsp agai n

Definiowanie klas obsługujących znaczniki w technologii JSF 1.1 W technologii JS F 1.1 model klas obsługujących znaczniki nie był tak elegancki jak w tech­ nologii 1.2. W tym punkcie dokonamy szczegółowej analizy najważniejszych różnic dzielących oba modele. Czytelnicy, którzy nie muszą tworzyć komponentów gwarantujących zgodność wstecz z technologią JS F 1.1, mogą ten punkt pominąć. Technologia JS F 1.1 oferuje dwie odrębne nadklasy znaczników: UIComponentTag i UlCom ^ponentBodyTag. Pierwszą z tych nadklas rozszerzamy, jeśli nasz komponent nie przetwarza swojego ciała (czyli znaczników potomnych i tekstu umieszczonego pomiędzy znacznikiem

350

JavaServer Faces

Rozdział 9. ■ Niestandardowe Komponenty, konwertery i mechanizmy weryfikujące

początkowym a znacznikiem końcowym). Nadklasę UlComponentBodyTag rozszerzamy, jeśli nasz komponent przetwarza swoje ciało. Klasa UlComponentBodyTag jest rozszerzana tylko przez cztery znaczniki standardowe technologii JS F 1.1: f-view, f venpatirn, h:comnandL mk i h : outputL i nk. Ponieważ komponent datownika nie przetwarza swojego ciała, jego klasa powinna dziedziczyć po klasie UlComponentTag.

Application app = context getApplicat 1 ont). ValueBmding binding = app createVa 1ueB 1 nd 1 ng(expr). component.setValueBinding(name, binding).

} else

component.getAttributes() .put(name, new Integer(expr)).

Znacznik implementujący klasę UlComponentTag może zawierać ciało, pod warun­ kiem że znaczniki użyte w tym ciele „wiedzą” , jak same siebie przetwarzać. Na przykład do komponentu datownika możemy dodać znacznik potomny f:attribute.

■

H H Mapa zwracana przez metodę Ul Component.getAttri butes zasługuje na chwilę ■¡fel uwagi, ponieważ uzyskuje dostęp do właściwości i atrybutów komponentu. Jeśli na przykład wywołamy metodę get tej mapy dla atrybutu nazwanego "value", zostanie wywołana metoda getValue. Jeśli wywołamy metodę get dla atrybutu nazwanego "minimum” i jeśli nie będzie istniała metoda getMinimum, mapa atrybutów danego kom­ ponentu zostanie przeszukana pod kątem zawierania klucza "minimum".

W technologii JS F sprzed wersji 1.2 pliki TLD wykorzystywały deklarację DOCTYPE (zamiast deklaracji schematu). Przykład takiej konstrukcji przedstawiono poniżej:

Metodę pomocniczą wywołujemy w ciele metody setProperties:



public void setPnoperties(Ul Component component) { super setPropertíes(component). set Integer(component. "minimum", minimum), set 1nregen(component. "maximum", maximum).

0.03 l. 2



}

Co ważne, w przypadku atrybutów nie można stosować elementów potomnych deferred -va 1ue ani deferred-method. Zamiast tych elementów mamy do dyspozycji mechanizm polegający na przekazywaniu do klasy obsługującej znacznik łańcuchów wyrażeń. Klasa obsługująca znacznik musi następnie konwertować te łańcuchy na obiekty typu ValueBmding lub Method ^ B ind mg. Wspomniane typy są w technologii JS F 1.1 odpowiednikami klas ValueExpression i MethodExpression znanych z technologii JS F 1.2.

W naszej metodzie pomocniczej przyjmujemy, że dane wyrażenie reprezentuje wartość całkowitoliczbową. Dla pozostałych typów musielibyśmy opracować dodatkowe metody pomocnicze: setString, setBoolean itd. Atrybuty definiujące dowiązania do metod (w tym cztery najczęściej stosowane atrybuty wymienione w tabeli 9.1) wymagają od programisty dodatkowych nakładów. Obiekt klasy MethodBindmg tworzymy, wywołując metodę createMethodBinding kłasy App 1ication. Metoda crea leMethodB i ndi ng przyjmuje na wejściu dwa parametry: wyrażenie wiążące metodę oraz tablicę obiektów klasy Cl ass opisujących typy parametrów tej metody. Na przykład poniższy fragment kodu tworzy takie dowiązanie do metody nasłuchującej zmian wartości:

Oznacza to, że klasa obsługująca znacznik musi definiować następujące metody ustawiające dla łańcuchów: public class SpinnerTag extends UlComponentTag { private String minimum, private String máximum;

FacesContext context = FacesContext.getCurrentlnstanceO, Application app = context.getAppli cati onO ; Class[] paramTypes = new Class[] { ValueChangeListener class }, MethodBinding mb = app.createMethodBinding(attributeValue, paramTypes);

public void setMinimum(String newValue) { minimum = newValue; } public void setMaximum(String newValue) { máximum = newValue, }

} W ciele metody setPro p e rties sprawdzamy, czy dany łańcuch definiuje dowiązanie do wartości. Jeśli tak, konwertujemy go na obiekt klasy ValueBinding, czyli znanej z technolo­ gii JS F 1.2 poprzedniczki klasy ValueExpression. W przeciwnym razie konwertujemy dany łańcuch na odpowiedni typ i ustawiamy go w roli atrybutu komponentu. Przedstawiony schemat konwersji jest mało interesujący, ale bardzo się przydaje podczas definiowania metod pomocniczych podobnych do tej, którą zdefiniowano poniżej: public void setInteger(UIComponent component, String name, String expr) { i f (expr == nuli) return nuli; else i f (UlComponentTag.isValueReference(expr)) { FacesContext context = FacesContext.getCurrentInstance(),

351

Tabela 9.1. Atrybuty dowiązań do metod Nazwa atrybutu

Parametry metody

Metoda ustawiająca dowiązanie

ValueChangeListener

ValueChangeEvent

Edi tableValueHolder.setValueChangeLi stener

validator

FacesContext, UlComponent, Object

EditableValueHolder.setValidator

actionListener

ActionEvent

Acti onSource.setActi onLi stener

action

bez parametrów

Acti onSource.setActi on

Obiekt klasy MethodBi ndi ng musimy następnie zapisać w ramach naszego komponentu: ((EditableValueHolder) component).setValueChangeListener(mb);

352

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

JavaServer Faces Metody nasłuchujące akcji i mechanizmy weryfikujące pracują według dokładnie tego sa­ mego wzorca. Z drugiej strony, akcje są dużo bardziej złożone. Akcja może mieć albo postać dowiązania do metody, albo stałej łańcuchowej:

ja vax.faces.application .Application ■

Tworzy dowiązanie do wartości i składuje je w danej aplikacji. Łańcuch przekazany na wejściu tej metody musi mieć postać wyrażenia reprezentującego dowiązanie w formie # {...}.



lub
javax, faces.component.UlComponent

new C 1 a s s [ ] { } ) . e ls e { FacesContext context = F a c e s C o n te x t.g e tC u rre n tIn s ta n c e !). A p p lic a tio n app = c o n t e x t .g e t A p p lic a tio n ().

■

void setValueBinding(String name. ValueBinding va1ueBinding)

Składuje w danym komponencie dowiązanie do wartości (według nazwy).

MethodBindmg mb = new ActionM ethodBm clingtat L n b u t e V a lu e ). com ponent.getA ttn p u t e s !) . p u t( " a c t io n " .

ValueBinding createVa 1ueB i nd i ng ( S t r i ng valueBmchngExpression)

mb).

033 javax.faces.webapp.UIComponentTag

1 Poniżej przedstawiono definicję klasy ActionMethodBindmg (niezbędnej do prawidłowego funkcjonowania naszego kodu):

■ static boolean isValueReferenceCStrmg expression) Zwraca wartość true, jeśli łańcuch expression rozpoczyna się od sekwencji "tt{ " i kończy sekwencją "}

p u b lic c la s s ActionMethodBindm g extends MethodBindmg implements S e r ia liz a b le { p r i v a le S trm g resul t . p u b lic A ctio n M etn o d B m d m g (Strin g r e s u lt ) { t h i s . r e s u lt = r e s u lt . } p u b lic O bject m voke(FacesContext con tex t. O bject p aram sf]) { re tu rn r e s u lt . p u b lic S t r in g g e tE x p re s s io n S tm n g !) { re tu rn r e s u lt .

003 javax, faces.component.EditableValueHolder [

}

■

p u blic C lass getType(FacesContext co n tex t) { retu rn S t r in g . c la s s . }

W technologii JS F 1.2 obsługa wyrażeń wskazujących na metody jest dużo prostsza (szcze­ gółowe omówienie tego modelu można znaleźć w punkcie „Obsługa wyrażeń wskazujących na metody” w dałszej części tego rozdziału).

00| ■

Ustawia dowiązanie do metody nasłuchującej zmian wartości właściwej dla danego komponentu. Dowiązywana metoda musi zwracać void i przyjmować na wejściu obiekt klasy ValueChangeEvent. ■

Zwraca referencję do bieżącego egzemplarza klasy FacesContext. ■ Application getApplicati on C)

void se tV a lidaton(MethodBinding m)

Ustawia dowiązanie do metody weryfikującej dane właściwe dla tego komponentu. Dowiązywana metoda musi zwracać void i przyjmować na wejściu obiekt klasy ValueChangeEvent.

javax. faces. context,FacesContext s ta tic FacesContext getCurrentlnstanceO

void setValueChangeListenen(MethodBindmg m)

BSD javax. faces.component.ActionSource ■ void setActionListenen(MethodBinding m) Ustawia dowiązanie do metody nasłuchującej akcji właściwej dla danego komponentu. Dowiązywana metoda musi zwracać void i przyjmować na wejściu obiekt klasy Act i onEvent.

Zwraca obiekt klasy Appl i cation właściwy dla danej aplikacji internetowej.

■

void setAction(MethodBindmg m)

Ustawia dowiązanie do akcji właściwej dla danego komponentu. Dowiązywana metoda może zwracać obiekt dowolnego typu i nie przyjmuje na wejściu żadnych parametrów.

353

354

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

JavaServer Faces

javax.faces.Input com.corejsf.Spinner com.corejsf.SpinnerRenderer

Doskonalenie komponentu datownika W tym podrozdziale wrócimy do komponentu datownika omówionego we wcześniejszych podrozdziałach. Datownik w dotychczasowej formie miał dwie istotne wady. Po pierwsze, nasz komponent sam odpowiadał za swoją wizualizację, co uniemożliwiało między innymi dołączanie odrębnych mechanizmów wizualizacji w trakcie przenoszenia aplikacji na tele­ fony komórkowe. Po drugie, komponent datownika wymagał komunikacji z serwerem za każdym razem, gdy użytkownik klikał przycisk inkrementacji lub dekrementacji. Takie podejście byłoby trudne do zaakceptowania w przypadku rzeczywistej kontrolki, od której wymaga się znacznie wyższej wydajności. W tym podrozdziale spróbujemy rozwiązać opisane problemy. Przy okazji spróbujemy rozszerzyć funkcjonalność komponentu datownika o możliwość dołączania metod nasłuchujących zmian wartości.

Stosowanie zewnętrznych mechanizmów wizualizacji W przykładzie analizowanym do tej pory klasa UI Spinner sama odpowiadała za wizualizację naszego komponentu. Okazuje się jednak, że większość klas interfejsu użytkownika deleguje zadanie wizualizacji do odrębnych, wyspecjalizowanych klas. Stosowanie zewnętrznych mechanizmów wizualizacji jest o tyle korzystne, że ułatwia wymianę tych mechanizmów, dostosowywanie komponentu do współpracy z różnymi zestawami narzędzi interfejsu użytkownika, a także stosowanie rozmaitych efektów HTML-a.

Element component-fami ly ma na celu wyeliminowanie problemu, z którym od niepamięt­ nych czasów zmagają się twórcy stron HTML-a. Nazwy standardowych znaczników tego języka w założeniu mają określać typ komponentu i mechanizmu wizualizacji. Na przykład znacznik h :selectOneMeriu wskazuje na komponent UISelectOne wykorzystujący mechanizm wizualizacji typu javax. faces .Menu. Ten sam mechanizm wizualizacji może być stosowany także dla znacznika h: sel ectManyMenu. Okazuje się jednak, że opisywany model nie we wszystkich przypadkach zdaje egzamin. Mechanizm wizualizacji dla znacznika h:inputText zapisuje pole tekstowe i nput języka HTM L. Ten sam mechanizm nie powinien być stosowany dla znacznika h: outputText, ponieważ nie chcemy, aby dane wynikowe były prezentowane na stronie w formie pola tekstowego. Zamiast identyfikować mechanizmy odpowiedzialne za wizualizację poszczególnych kom­ ponentów, należy określać tylko typy tych mechanizmów i rodziny komponentów. W ta­ beli 9.2 przedstawiono rodziny komponentów właściwe dla wszystkich standardowych klas komponentów. W naszym przypadku najlepszym rozwiązaniem jest użycie rodziny kompo­ nentów javax. faces. Input, ponieważ klasa UISpinner jest podklasąklasy Ullnput.

Tabela 9.2. Rodziny komponentów, do których naieżą kiasy komponentów standardowych Klasa komponentu

Rodzina komponentów

W podrozdziale „Użycie skryptu JavaScript do ograniczenia komunikacji z serwerem” po­ każemy, jak można wykorzystać alternatywny mechanizm wizualizacji stosujący kod języka JavaScript do śledzenia wartości datownika po stronie klienta.

UlCommand

javax.faces.Command

UI Data

javax.faces.Data

Ul Form

javax.faces.Form

Stosowanie zewnętrznego mechanizmu wizualizacji wymaga podjęcia następujących kroków:

UIGraphic

javax.faces.Graphic

1. Zdefiniowania łańcucha identyfikatora dla mechanizmu wizualizacji.

Ullnput

javax.faces.Input

2. Zadeklarowania tego mechanizmu w pliku konfiguracyjnym JSF .

UIMessage

javax.faces.Message

UIMessages

javax.faces.Messages

UlOutput

javax.faces.Output

UlPanel

javax.faces.Panel

UISelectBoolean

javax.faces.SelectBoolean

UISelectMany

javax.faces.Sel ectMany

UISelectOne

javax.faces.SelectOne

3. Takiego zmodyfikowania klasy znacznika, aby jej metoda getRendererType zwracała identyfikator mechanizmu wizualizacji. 4. Implementacji klasy wizualizacj i. Odpowiedni identyfikator (w naszym przypadku com.corejsf .Spinner) koniecznie należy zdefiniować w pliku konfiguracyjnym JSF : com.corejsf.Spinner com.corejsf. LlISpi nner

355

Metoda getRendererType klasy naszego znacznika musi zwracać identyfikator mechanizmu wizualizacji:

356

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

JavaServerFaces public class SpinnerTag extends UIConiponentTag { public String getComponentType() { return "com.corejsf.Spinner", } public String getRendererType!) { return "com.corejsf .Spiriner"; } }

I | i Identyfikatory komponentów i rnechanizmów wizualizacji należą do odrębnych ■ m i przestrzeni nazw, Oznacza to, ż<3 stosowanie tego samego łańcucha w roli identyfikatora komponentu i identyfikatoraj mechanizmu wizualizacji nie powinno prowadzić do żadnych problemów. « m

m

m

®

^

Innym korzystnym rozwiązaniem jest określenie typu mechanizmu wizualizacji w konstruk­ torze komponentu: public class UISpinner extends Ul Input { public UISpinnerO { setConverter (new I ntegerConverter ()); I I konwersja przesłanej wartości setRendererTypeC'COm.COrejsf .Spinner"); / / mechanizm odpowiedzialny za wizualizację

} } W takim przypadku typ mechanizmu wizualizacji zostanie prawidłowo ustawiony, nawet jeśli dany komponent będzie wykorzystywany na poziomie programu (bez konieczności stosowania znaczników).

Metoda getConvertedVal ue konwertuje wartość wysianą przez dany komponent z formy łańcu­ chowej do postaci obiektu. Implementacja domyślna klasy Renderer zwraca tę wartość. Metoda getRendersChi Idren określa, czy dany mechanizm wizualizacji odpowiada także za wizualizację komponentów potomnych. Jeśli wspomniana metoda zwróci wartość true, implementacja JS F wywoła metodę encodeChi Idren klasy odpowiedzialnej za wizualizację; jeśli metoda getRendersChi Idren zwróci wartość false (czyli wartość domyślną), imple­ mentacja JS F nie wywoła metody encodeChi Idren, a komponenty potomne będą kodowane w ramach odrębnego procesu. Metoda convertCl i ent Id konwertuje łańcuch identyfikatora (np. _i dl :monthSpinner), aby można go było wykorzystywać po stronie klienta — niektóre aplikacje klienckie mogą wprowadzać pewne ograniczenia wobec tych identyfikatorów (np. wykluczające możliwość stosowania znaków specjalnych). Okazuje się jednak, że domyślna implementacja zwraca łańcuch identyfikatora w niezmienionej formie. Jeśli dysponujemy komponentem, który sam odpowiada za swoją wizualizację, przeniesienie odpowiedniego kodu z poziomu komponentu do odrębnej klasy wizualizacji nie powinno nam sprawić kłopotu. Na listingach 9.10 i 9.11 przedstawiono odpowiednio kod komponentu datownika i jego mechanizmu wizualizacji.

LÍStíng 9.10. Kod klasy spinner2/src/java/com/corejsf/UISpinner.java 1. package com.corejsf: 2.

Ostatnim krokiem jest implementacja samego mechanizmu wizualizacji. Mechanizmy wizu­ alizacji rozszerzają klasę bazową ja vax. faces. render. Renderer. Wspomniana klasa definiuje siedem metod, z których cztery są nam już znane: ■ void encodeBegin(FacesContext context, UlComponent component) ■ void encodeChildren(FacesContext context, UlComponent component) ■ void encodeEnd(FacesContext context, UlComponent component) ■ void decode(FacesContext context, UlComponent component) Wymienione powyżej metody klasy odpowiedzialnej za wizualizację są niemal identyczne jak ich odpowiedniki stosowane w komponentach — najważniejsza różnica dotyczy dodat­ kowego argumentu reprezentującego referencję do wizualizowanego komponentu. Aby zaim­ plementować te metody z myślą o komponencie datownika, przenosimy istniejące metody tego komponentu do klasy odpowiedzialnej za wizualizację i wprowadzamy niezbędne zmiany związane z faktem przekazywania referencji do komponentu. Opisywane rozwiązanie nie powinno nam sprawić najmniejszego kłopotu. Pozostałe metody klasy bazowej odpowiedzialnej za wizualizację wymieniono poniżej: ■ Object getConvertedValue(FacesContext context, UlComponent component, Object submittedValue) ■ boolean getRendersChildrenO ■ String convertClientId(FacesContext context, String clien tId )

357

3. import javax.faces.component.Ul Input, 4 import javax.faces.convert.IntegerConverter: 5. public class UISpinner extends UIInput { public UISpinnerO { setConverterCnew IntegerConverter!)); // konwersja przesłanej wartości 9-

}

10. }

Listing 9.11. Kod klasy spinner2/src/java/com/corejsf/SpinnerRenderer.java package com.corejsf: import import import import import import import import import

java.io.IOException; java.util.Map; javax.faces.component.UIComponent; javax.faces.component.EditableValueHolder; javax.faces.component.UIInput; javax.faces.context.FacesContext; javax.faces.context.ResponseWriter; javax.faces.convert.ConverterException; javax.faces.render.Renderer;

public class SpinnerRenderer extends Renderer { private static final String MORE = ".more"; private static final String LESS = ".less"; public Object getConvertedValue(FacesContext context, UlComponent component, Object submittedValue) throws ConverterException {

358

JavaServer Faces 19. 20. 21 22

23. 24 25. 26. 27. 28. 29. 30 31 32. 33 34. 35. 36. 37 38. 39. 40. 41. 42. 43. 44. 45. 46 47. 48. 49. 50. 51. 52. 53 54. 55. 56. 57. 58. 59. 60. 61. 62 63. 64. 65. 66. 67. 68. 69. 70. 71 72. 73. 74. 75. 76.

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

return com.corejsf util.Renderers.getConvertedValue(context, component, submittedValue),

}

public void encodeBegin(FacesContext context, UlComponent spinner) throws IOException { ResponseWriter writer = context,getResponseWriter(); String clientld = spinner.getClientld(context); encodeInputField(spinner, writer, clientld); encodeDecrementButton(spinner. writer, clientld); encodeIncrementButton(spinner, writer, clientld); } publicvoiddecode(FacesContext context,UlComponent component) { EditableValueHolder spinner = (EditableValueHolder) component; Map requestMap = context.getExternalContext( ) ,getRequestParameterMap(); String clientld = component.getClientld(context); int increment; i f (requestMap.containsKey(clientld + MORE)) increment = 1; else i f (requestMap.containsKey(clientld + LESS)) increment = -1; else increment = 0; try { int submittedValue =Integer.parselnt((String) requestMap.get(clientld)); int newValue = getIncrementedValue(component, submittedValue, increment), spinner. setSubmittedValueC" + newValue); spinner.setValid(true); } catch(NumberFormatException ex) { / / Obsługę błędnych danych wejściowych pozostawiamy co prawda konwerterowi, // co nie oznacza, że nie musimy ustawić wysłanej wartości — w przeciwnym razie / / konwerter nie dysponowałby danymi wejściowymi do przetworzenia. spinner.setSubmittedValue((String) requestMap.get(clie n tld )); } } private voidencodeInputField(UIComponent spinner,ResponseWriter String clientld) throws IOException { writer.startElement("input", spinner); writer.writeAttribute("name", clientld, "clientld"); Object v = ( ( UIInput) spinner) .getValueO , i f (v != null) writer. writeAttributeC'value", v.toStringO , "value"); Integer size = (Integer) spinner getAttributes() ,get("size"); if(size != nul1) writer.writeAttribute("size", size, "size"); writer.endElement("input"); }

77 78. 79. 80. 81. 82. 83 84 85 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99

359

private void encodeDecrementButton(UlComponent spinner, ResponseWriter writer, String clientld) throws IOException { writer.startElement("input", spinner); writer.writeAttributeCtype", "submit", null); writer writeAttribute("name", clientld + LESS, null), writer.writeAttribute("value", "<", "value"), writer.endElement("input"); } private void encodeIncrementButton(UIComponent spinner, ResponseWriter writer, String clientld) throws IOException { writer. startElementC'input", spinner); writer.writeAttributeCtype", "submit", null), writer.writeAttributeC'name", clientld + MORE, null): writer.writeAttributeC'value", ">", "value"), writer.endElement("input"); } private int getIncrementedValue(UIComponent spinner, int submittedValue, int increment) { Integer minimum = (Integer) spinner.getAttributesO.getCminimum"); Integer maximum = (Integer) spinner.getAttributesO,get("maximum"), int newValue = submittedValue + increment,

100.

101. 102. 103. 104. 105. 106. 107.

i f ((minimum == null || newValue >= minimum.intValueO) && (maximum == null || newValue <= maximum.intValue())) return newValue; else return submittedValue; } }

Wywoływanie konwerterów z poziomu zewnętrznych mechanizmów wizualizacji Jeśli porównamy kod z listingów 9.10 i 9.11 z kodem z listingu 9.1, przekonamy się, że przeniesiono większą część klasy oryginalnego komponentu do nowej klasy mechanizmu wizualizacji.

writer,

Warto przy tej okazji zwrócić uwagę na pewien ciekawy aspekt. Na listingu 9.10 widać w y­ raźnie, że komponent datownika obsługuje konwersje za pośrednictwem prostych wywołań metody setConverter() w swoim konstruktorze. Ponieważ datownik jest typowym kompo­ nentem wejściowym, jego nadklasa (Ullnput) wykorzystuje wskazany konwerter w fazie weryfikacji. Skoro nasz komponent datownika deleguje zadanie wizualizacji do odrębnego mechanizmu, właśnie ten mechanizm powinien odpowiadać za konwersję wartości tego komponentu przez nadpisanie metody Renderer .getConvertedVal ue(). Oznacza to, że musimy powiełić kod konwertujący (z klasy Ullnput) w naszym niestandardowym mechanizmie wizualizującym. Umieścimy ten kod (którego stosowanie jest niezbędne w przypadku wszystkich mechani­ zmów wizualizacji wykorzystujących konwertery) w metodzie statycznej getConvertedVal ue klasy com.corejsf .u til .Renderers (patrz listing 9.12 w dalszej części tego podrozdziału).

360

JavaserverFaces

H H Metodę Renderers.getConvertedValue (patrz listing 9.12 w dalszej części tego ■ li podrozdziału) należy traktować jak zło konieczne, ponieważ klasa Ul Input nie udostępnia publicznie swojego kodu konwertującego. Odpowiedni kod, który zaimple­ mentowano w chronionej metodzie Ul Input. getConvertedValue, bardzo przypomina implementację referencyjną JS F 1.2. / / Poniższy fragm ent kodu zaczerpnięto z klasy javax.faces, component. Ullnput:

public void getConvertedValueCFacesContext context, Object newSubmittedValue) throws ConverterException { Object newValue = newSubmittedValue; i f ( renderer !~ n u ll) { newValue = renderer.getConvertedValue(context, this, newSubmittedValue): } else i f (newSubmittedValue instanceof String) { Converter converter * getConverterWithType(context): / / metoda pryw atna i f (converter != null) newValue * converter.getAsObject( context, this, (String) newSubmittedValue);

Rozdział 9. ■ Niestandardowe Komponenty, konwertery i mechanizmy weryfikujące

361


|

\~ Q spinner.tld

j

p

[

Q SpinnerTag. class

D faces-config.xml

| L D web.xml

L~D styles.css

private MethodExpression valueChangeListener = null:

T Q index.html L Q index, jsp

public void setValueChangeListener(MethodExpression newValue) valueChangeListener = newValue;

{

} } W ramach metody setProperties naszej klasy obsługującej znacznik dokonujemy konwersji przekazanego obiektu klasy MethodExpressi on do postaci odpowiedniego obiektu nasłuchują­ cego, po czym dodajemy ten obiekt do komponentu: public void setPropertiesdJIComponent component) { super.setProperti es(component); i f (valueChangeListener != null) ( ( EditableValueHolder) component).addValueChangeListener( new MethodExpressionValueChangeListener(valueChangeListener));

} Z tabeli 9.3 można łatwo odczytać, w jaki sposób należy obsługiwać pozostałe trzy atrybuty. I Wartość atrybutu action może mieć albo postać wyrażenia wskazującego na I metodę, albo postać stałej. W tym drugim przypadku tworzona metoda zawsze zwraca tę wartość stałą.

L D next.jsp_____________________________

(Klasa Renderers dodatkowo definiuje metodę getSelectedltems, która będzie nam potrzebna w dalszej części tego rozdziału — na razie możemy ją zignorować). Kod klasy Renderers przedstawiono na listingu 9.12. Przebudowaną klasę SpinnerTag przedstawiono na listingu 9.13; na listingu 9.14 przedstawiono zawartość pliku konfiguracyjnego faces-config.xml.

Listing 9.12. Kod klasy spinner2/src/java/com/corejsf/util/Renderers.java 1. package com.corejsf.util;

c9.

3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20

import import import import import

java.util.ArrayList; java.util.Arrays; java.util.Collection; java.u til.List; java.util.Map;

import import import import import import import import import import import

javax.el.ValueExpression; javax.faces.application.Application; javax faces.component.UlComponent; javax.faces.component.UIForm; javax.faces.component.UlSelectItem; javax.faces.component.UlSelectltems; javax.faces.component.ValueHol der; javax.faces.context.FacesContext; javax.faces.convert.Converter; javax.faces.convert.ConverterException, javax.faces.model.Selectltem,

364

JavaServer Faces 21 public class Renderers { 22. public static Object getConvertedValue(FacesContext context, 23. UlCornponent component, Object submittedValue) 24. throws ConverterException { 25 i f (submittedValue instanceof String) { 26 Converter converter = getConverter(context, component); 27. i f (converter != null) { 28 return converter getAsObject(context, component, 29. (String) submittedValue): 30. } 31 } 32. return submittedValue; 33 } 34. 35 public static ConvertergetConverter(FacesContext context, 36 UlCornponent component) { 37 i f (¡(component instanceof ValueHolder)) return null; 38 ValueHolder holder = (ValueHolder) component: 39. 40. Converter converter = holder,getConverter(), 41. i f (converter != null) 42. return converter, 43. 44. ValueExpression expr = component.getValueExpressionC'value"); 45. i f (expr == null) return null; 46. 47. Class targetType = expr,getType(context,getELContext()), 48. i f (targetType == null) return null; 49. / / W wersji 1.0 im plementacji referencyjnej (wskutek błędu) konwerter 50 . I I nie zostałby zastosowany, gdyby typem docełowym był String lub Object. 51. 52. Application app = context.getAppli cation O , 53 return app.createConverter(targetType); 54. } 55. 56. public static String getFormId(FacesContext context, UlCornponent component) { 57. UlCornponent parent = component, 58. while (¡(parent instanceof UIForm)) 59. parent = parent,getParent(); 60. return parent.getClientld(context), 61. } 62. 63. @SuppressWarnings("unchecked") 64. public static ListgetSelectItems(UlCornponent component) { 65. ArrayList lis t = new ArrayList(), 66 for (UlCornponent child : component.getChildrenO) { 67 i f (child instanceof UlSelectltem) { 68 Object value = ( (UlSelectltem)chi Id ) .getValue(); 69. i f (value ==null) { 70. UlSelectltem item = (UlSelectltem) child, 71. list.add(new SelectItem(item.getItemValue(), 72 itern.getItemLabel0 , 73 item.getltemDescriptionO, 74. item.isItemDisabledO)); 75. } else i f (value instanceofSelectltem) { 76 1ist.add((Selectltem) value); 77. }

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące 78. 79. 80 81. 82. 83. 84. 85.

} else i f (child instanceof UISelectItems) { Object value = ((UISelectItems) child).getValueO, i f (value instanceof Selectltem) list.add((SelectItem) value); else i f (value instanceof SelectItem[]) list.addAll(Arrays.asList((SelectItem[]) value)); else i f (value instanceof Collection) list.addAll( (Collection) value); //n ie u n ik n io n e

86.

//o s tr z e ż e n ie

87. 88. 89. 90.

else i f (value instanceof Map) { for (Map.Entry entry . ( ( Map) value),entrySet()) list.add(new Selectltem(entry,getkey(). "" + entry.getValueO));

91.

}

92. 93. 94. 95 96 }

} } return lis t; }

Listing 9.13. Kod klasy spinner2/src/java/com/corejsf/SpinnerTag.java 1 package com.corejsf; 2.

3. 4. 5. 6. 7. 8. 9.

import import import import import import

javax.el.MethodExpression; javax.el.ValueExpression; javax.faces.component.EditableValueHolder, javax.faces.component.UlCornponent; javax.faces.event.MethodExpressionValueChangeListener; javax.faces.webapp.UIComponentELTag;

public class SpinnerTag extends UIComponentELTag { private ValueExpression minimum = null, 12. private ValueExpression maximum = null; 13. private ValueExpression size = null; 14. private ValueExpression value = null, 15. private MethodExpression valueChangeListener = null; 16. 17 public String getRendererType() { return "com.corejsf.Spinner"; } 18 public String getComponentType() { return "com.corejsf.Spinner"; } 19. 20. public void setMinimum(ValueExpression newValue) { minimum = newValue; 21. public void setMaximum(ValueExpression newValue) { maximum = newValue; 22. public void setSize(ValueExpression newValue) { size = newValue; } 23. public void setValue(ValueExpression newValue) { value = newValue; } 24. public void setValueChangeListener(MethodExpression newValue) { 25. valueChangeListener = newValue; 26. } 27. 28. public void setProperties(UIComponent component) { 29. / / zaw sze wywołujemy metodę setProperties nadklasy 30. super.setProperties(component); 31. 32. component.setValueExpressionC'size", size); 33. component.setValueExpression("minimum", minimum); 34. component.setValueExpression("maximum", maximum); 35. component.setValueExpressionCvalue", value); 10.

11.

365

366

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

JavaServer Faces 36

( ( E d ita b le V a lu e H o icie r) com ponent).addValueChangeListener(

38 39 40 41 42 43 44 45 46

new MethodExpressionvalueChangeListener( valueCnangeListener)). f public void release!) | / / zawsze wywołujemy metodę release nadklasy super release!). mi ni mum max i mum

= nu 11. = nu 11.

47

Size = nu l 1.

48

value = nu11.

49

valueC bangeListener = n u ll.

50

9J

39 COm c o r e j s f S p in n e r < / r e n d e r e r - t y p e > 40 < r e n d e r e r - c l a s s > C O m c o r e j s f SpinnerRenderer 41 42 43 44 45 ^ r e s o u r c e - bu n d le > 46 com corejsf messages 47 rnsgs 48 < / reso u rc e- b u n d le > 49 50

if ( vd 1ueCnangeL i stener !■ = null)

37

IH

\

1

■ void addValueChangeListener(ValueChangeListener 1istener) (JS F 1.2) Dodaje do danego komponentu metodę nasłuchującą zmian wartości.

Listing 9.14. Plik konfiguracyjny spinner2/web/WEB-INF/faces-config.xml 1

■ void addVal i da tor (V alidator v a l ) (JS F 1.2)

2 3
v e r s ion ="1.2">

Dodaje do danego komponentu mechanizm weryfikujący.

UDjavax. faces. component.Act ionSource ■

8 9

10 11 12 13 L4 15 16 17

J8 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36. 37. 38.

javax. faces.component.EditableValueHolder

Dodaje do danego komponentu metodę nasłuchującą akcji.

< n a vig a n o n - ru ie >

/index jsp next /next. jsp

/next.jsp rom-outcowe>again /mdex.jsp cardExpiramonDate com.corejsf CreditCardExpiration session com corejsf Spinner component-class>com.corejsf UlSpmner javax.faces.Input

void addActionListener(ActionListener 1istener) (JS F 1.2)

¡01 ■

javax.faces.component.ActionSource2 (JSF 1.2) void addAction(MethodExpression m)

Dodaje do danego komponentu akcję. Metoda akcji zwraca wartość typu String i nie przyjmuje na wejściu żadnych parametrów.

M javax.faces.event.MethodExpressionValueChangeListener ■

(JSF 1.2)

MethodExpressi onVa1ueChangeListener(MethodExpression m)

Konstruuje mechanizm nasłuchujący zmian wartości na podstawie wyrażenia wskazującego na metodę. Metoda nasłuchująca zwraca typ void i przyjmuje na wejściu obiekt klasy Va 1ueChangeEvent..

¡¡U javax.faces.validator.MethodExpressionValidator (JSF 1.2) ■

MethodExpressi onVa11 da tor(MethodExpression m)

Konstruuje mechanizm weryfikujący na podstawie wyrażenia wskazującego na metodę. Nowa metoda zwraca typ void i przyjmuje na wejściu obiekty klas FacesContext, Ul Component i Object.

367

368

JavaServer Faces M javax. faces.event.MethodExpressi onActionListener (JS F 1.2) ■ MethodExpressionActionnstener(MethodExpression m)

Konstruuje mechanizm nasłuchujący akcji na podstawie wyrażenia wskazującego na metodę. Metoda nasłuchująca zwraca typ void i przyjmuje na wejściu obiekt klasy Act lonEvent.

UJ

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

369

Jeśli klucza targetClass nie uda się odnaleźć we wspomnianej strukturze mapy, metoda createConverter przeszuka tę strukturę pod kątem zawierania klucza właściwego dla interfejsów i nadklas klucza targetClass (właśnie w tej kolejności) aż do odnalezienia pasującej klasy. Po zakończeniu procesu poszukiwania pasującej klasy metoda createConverter tworzy i zwraca odpowiedni konwerter. Jeśli poszukiwanie konwertera dla przekazanego klucza (oraz jego interfejsów i nadklas) zakończy się niepowodzeniem, metoda createConverter zwróci wartość nul 1.

javax. faces.event.ValueChangeEvent

■ Object getO1dVa1ue() Zwraca starą wartość danego komponentu. ■ Object getNewValue()

Użycie skryptu JavaScript do ograniczenia komunikacji z serwerem

Zwraca nową wartość danego komponentu.

U J ja v a x .faces .component. Val ueHol der ■ Converter getConverter()

Zwraca konwerter przypisany do danego komponentu. Interfejs Val ueHol der jest implementowany zarówno przez komponenty wejściowe Ja k i przez komponenty wyjściowe.

UJ

javax.faces.component.UlCornponent

■ ValueExpression getVa 1ueExpression(5tring name) (JS F 1.2)

Komponent datownika komunikuje się z serwerem za każdym razem, gdy użytkownik klika któryś z jego przycisków. Komunikacja z serwerem ma na celu aktualizację składowanej tam wartości datownika. Wymiana komunikatów pomiędzy klientem a serwerem może znacznie obniżyć wydajność komponentu datownika, zatem niemal we wszystkich przypadkach lepszym rozwiązaniem jest składowanie wartości komponentu po stronie klienta i aktualizowanie jej odpowiednika po stronie serwera tylko po wysłaniu odpowiedniego formularza na serwer. Możemy ten cel osiągnąć, stosując następujący skrypt języka JavaScript:
van v = p a n s e ln t( chi s v a lu e ) + incrément. i f ( isNaN( v ) ) re tu rn .

Zwraca wyrażenie reprezentujące wartość odpowiadającą danej nazwie.

UJ

if ('min' in tnis && v < this.mm) return, lf ('ma*1 in th1S && v > this.max) return, ihis value = v:

javax.faces.context.FacesContext

■ ELContext getELContext() (JS F 1.2)

language= "JavaScM pt">

document formst ' _ l d r ] [ '_ id l:m o n tn S p in n e r'] spin -= fun ctio n (in crem ent) {

idocument fo rm s[ 1_ i d l ' ] [ ’_ i d 1 : month S p in n e r’ ] .min

Zwraca kontekst języka wyrażeń.

UJ ■

javax.el.ValueExpression (JSF 1.2) Class getType(ELContext context)

= 0.

Zwraca typ danego wyrażenia reprezentującego wartość.

UJ ■

javax. faces. appli cati on.Appli cati on Converter createConverter(Class targetClass)

Tworzy konwerter na podstawie jego klasy docelowej. Implementacje JS F utrzymują mapę prawidłowych typów konwerterów, które z reguły określamy w ramach plików konfiguracyjnych naszych aplikacji. Jeśli za pośrednictwem argumentu targetClass przekażemy klucz któregoś z elementów tej mapy, metoda createConverter utworzy i zwróci egzemplarz odpowiedniego konwertera (reprezentowanego przez wartość właściwą dla klucza targetCl ass).

Kiedy piszemy kod języka JavaScript, który ma uzyskiwać dostęp do pól jakiegoś formularza, musimy dysponować identyfikatorem tego formularza (w tym przypadku '_ id l ' ): document fo rm s['

d 1 ' ] [ ' _ i d l •month Sp in n e r' ]

Funkcję drugiego indeksu tablicy pełni identyfikator klienta danego komponentu. Uzyskiwanie identyfikatora formularza jest zadaniem dość typowym, stąd decyzja o umiesz­ czeniu w klasie com.corejsf u t 11.Renderers metody pomocniczej odpowiedzialnej za tę operację:

370

JavaServer Faces

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

public static String getFormId(FacesContext context, UlComponent component) { UlComponent parent = component, while (¡(parent instanceof UIForm)) parent = parent,getParent(): return parent.getClientld(context):

} W tym miejscu nie będziemy szczegółowo analizowali technik programowania w języku JavaScript; warto jednak zwrócić uwagę na ryzyko występowania konfliktów nazw (wsku­ tek umieszczania funkcji globalnych tego języka w kodzie nieznanej strony). Okazuje się, że język JavaScript zaprojektowano z należytą ostrożnością i kładąc szczególny nacisk na elastyczność modelu obiektowego. Zamiast pisać funkcję globalną spin, możemy ją zdefi­ niować jako metodę obiektu pola tekstowego. Język JavaScript umożliwia nam rozszerzanie możliwości obiektów „w locie” przez dodawanie nowych metod i pól. Właśnie tę technikę zastosujemy dla wartości minimalnych i maksymal­ nych komponentu datownika (reprezentowanych — w razie konieczności — odpowiednio przez pola min i max). Nową wersję kodu klasy odpowiedzialnej za wizualizację komponentu datownika przed­ stawiono na listingu 9.15.

Listing 9.15. Kod klasy spinner-js/src/java/com/corejsf/JSSpinnerRenderer.java 1. package com.corejsf; 2

3 4 5. 6. 7. 8 9. 10. 11. 12. 13 14 15. 16. 17. 18. 19.

import import import import import import import import import import

java.io.IOException, java.text.MessageFormat; java.util.Map; javax.faces.component.EditableValueHolder; javax.faces.component.UlComponent, javax.faces.component.UIInput; javax.faces.context.FacesContext; javax.faces.context.ResponseWriter, javax.faces.convert.ConverterException, javax.faces.render.Renderer,

public class JSSpinnerRenderer extends Renderer { public Object getConvertedValue(FacesContext context, UlComponent component, Object submittedValue) throws ConverterException { return com.corejsf util.Renderers.getConvertedValue(context, component, submittedValue); }

20

21. 22. 23 24. 25. 26. 27. 28. 29. 30. 31. 32

public void encodeBegin(FacesContext context, UlComponent component) throws IOException { ResponseWriter writer = context.getResponseWriterO; String clientld = component.getClientld(context); String formld = com.corejsf util Renderers.getFormld(context, component); UIInput Integer Integer Integer

spinner = (Ullnput)component; min = (Integer) component,getAttributes() . get( "minimum"), max = (Integer) component,getAttributes() ,get("maximum"); size = (Integer) component.getAttributesO .getC'size");

writer.startElementC'input", spinner);

33. 34 35 36 37. 38. 39. 40. 41. 42. 43. 44 45. 46 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68

69. 70. 71 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89.

writer.writeAttribute("type", "text", null); writer.writeAttribute("name", clientld , null); writer writeAttributeC'value", spinner getValueO toStringO, "value"); i f (size != nul 1) writer.writeAttribute("size", size , null); writer.endElement("input"); writer.write(MessageFormat format( ""); writer.startElementC'input", spinner); writer.writeAttributeC'type", "button", null); writer.writeAttributeC'value", null), writer.writeAttributeC'onclick", MessageFormat.format( "document.forms[' ' {0 } " ] [ " {1}' '] .sp in(-l);", new Object[] { formld, clientld }), null); writer endElementC'input"); writer.startElementC'input", spinner); writer writeAttribute("type", "button", null); writer.writeAttributeC'value", null); writer.writeAttributeC'onclick", MessageFormat.format( "document.forms[ ' ' {0} " ] [ " {1} " ] .s p in (l);", new Object[] { formld, clientld }), null); wri ter. endElementC'input"); } public void decode(FacesContext context, UlComponent component) { EditableValueHolder spinner = (EditableValueHolder) component; Map requestMap = context.getFxternalContext( ) .getRequestParameterMap(); String clientld = component.getClientld(context); spinner.setSubmittedValue((String) requestMap.get(clientld));

371

372

JavaServer Faces 90. 91 92.

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

spinner.setVal icKtrue):

373

h:coirimandLink. W tym podrozdziale opracujemy komponent wielokrotnego użytku, który twórcy stron będą mogli bez trudu stosować w swoich projektach.

} }

Komponent panelu podzielonego na zakładki ma kilka szczególnie interesujących cech: Warto pamiętać, że wprowadzone zmiany nie mają najmniejszego wpływu na komponent UISpi nner. Aktualizacji wymaga wyłącznie klasa odpowiedzialna za wizualizację, co ponownie dowodzi skuteczności kroku polegającego na wyodrębnieniu mechanizmu wizualizacji.

Stosowanie komponentów i facet potomnych Komponent datownika, który omówiono w pierwszej części tego rozdziału, jest na tyle pro­ sty, że nie może skutecznie ilustrować szeregu ważnych i przydatnych technik implementacji komponentów niestandardowych. Szczegółowa analiza tych metod wymaga posłużenia się przykładem nieporównanie bardziej skomplikowanego komponentu — będzie to komponent panelu podzielonego na zakładki (patrz rysunek 9.9).

Rysunek 9.9. Komponent panelu podzielonego na zakładki

■ Możemy stosować klasy CSS zarówno dla całego panelu podzielonego na zakładki, jak i dla poszczególnych zakładek (zaznaczonych lub nie). ■ Zakładki definiujemy za pomocą znaczników f : sel ect Item (lub f : sel ect Items), a więc zgodnie ze schematem znanym ze standardowych znaczników menu i list JS F (gdzie w ten sposób definiowano dostępne opcje). ■ Zawartość panelu podzielonego na zakładki zdefiniujemy za pośrednictwem facety (prezentowanej przez mechanizm odpowiedzialny za wizualizację). Możemy na przykład określić zawartość dla zakładki Washington (patrz rysunek 9.9) jako W ashington. Mechanizm wizualizacji odnajduje następnie facetę właściwą dla zakładki nazwanej W a s h in g to n . Opisywany model korzystania z facet przypomina sposób, w jaki stosowaliśmy facety h e a d e r i f o o t e r w ramach znacznika h: da ta T a b le . ■ Do panelu podzielonego na zakładki możemy dołączyć metodę nasłuchującą akcji. Taka metoda będzie powiadamiana za każdym razem, gdy użytkownik zaznaczy którąś z zakładek.

http://loc»lho^8080/

■ Tekst zakładek można łatwo lokalizować, stosując klucze z pakietu komunikatów (zamiast stałych łańcuchowych przypisywanych bezpośrednio zakładkom).

iB.oosevelti iLincoln; iWashmgor Thomas Jefferson, trzeci prezydent Stanów Zjednoczonych, urodził się w roku 1743 w stanie Wirginia Jefferson był ' -■ '- ' - ' ' ' -J ktor/u. zastąp ,r —-----------------------urząd prezydi | $H; H g został w 1801 |

r

ŚJeffersonj

nno7,IOi41h(Is;:ir,So.';4buede*ne.!nde..f«e,

iŁmcota] jWashingtonj

¿skończono

Theodore Roosevelt był 26 prezydentem Stanów Zjednoczonych. Został prezydentem w roku 190] po; zamachu na prezydenta McKinley a TJrząd prezydenta objął w wieku 42 lał i przeszedł do histora jako j

■ Nasz panel podzielony na zakładki wykorzystuje pola ukryte do przesyłania pomiędzy klientem a serwerem informacji o zaznaczonej zakładce i jej zawartości. Tak duża złożoność panelu podzielonego na zakładki sprawia, że możemy wykorzystywać ten komponent na wiele różnych sposobów. Przykład prostego zastosowania tego komponentu przedstawiono poniżej: < co rejsf labbecIPane >

Prezydent Lmcoln przeszedł do łustomjako Wielki Łmancypator, ponieważ w ogromnym stopmu przyczynił się do anęsiema niewolnictwa na terem? Stanów Zjednoczonych. Urodzony w 1809 roJ wychował dwn«^odridon«K na zakiadki -MozKla F«efóx'' " 1860 ZąnaŁl L 1• -- - ■ | U )A Jd y c ja

CQim'rnJ

f i A '-

JJ/idok

-

#

Hi*om

kj

|||g

f j f [.

I

hWm.

,j\ '

httP »omno f 8030 rapaeapanH/.nci^xr<,ce<


s e le c l 1rena itemLabel = "Jeffenso n"

item vaiu e= "jefferso n "/>


s e le c t (tem i temLabel =” Roosevel i "

ite m V a iu e= "ro o seve lt’7>


s e le c t Item itemLabel ="Lm c o ln"

item value= "1m coln"/>


s e le c t item uewLabei ="washm gton" item vaipe="washmgton'7>

<1■ facet

"t

nam e="jefferson">



±&mz

5SS53



historii Stanów Zjednoczonych

sud-iwez

Skoro dysponujemy już ogólną wiedzą o komponencie panelu podzielonego na zakładki, możemy przystąpić do szczegółowej analizy implementacji zaawansowanych elementów tej konstrukcji. Poniżej wymieniono dalsze punkty tego podrozdziału: ■ „Przetwarzanie znaczników potomnych typu Selectltenf

Aby uzyskać efekt widoczny na rysunku 9.9, wystarczy użyć stylów C SS, stosując nastę­ puj ącą konstrukcj ę:

Zamiast wielu znaczników f :sel ecti tem można też użyć pojedynczego znacznika f :sel ect Items:

W takim przypadku znaczniki będą definiowane na poziomie komponentu JavaBean. W poprzednim przykładzie bezpośrednio zdefiniowano tekst wyświetlany w poszczegól­ nych zakładkach (czyli etykiety Jefferson , Roosevelt itd.). Tym razem zastosowano zdecy­ dowanie bardziej elastyczny model, zgodnie z którym mechanizm odpowiedzialny za wizu­ alizację jeszcze przed zakodowaniem zakładki podejmuje próbę odnalezienia odpowiedniej etykiety w pakiecie komunikatów i w razie jej odnalezienia wykorzystuje wartość właściwą dla danego klucza. Jeśli odpowiedniej etykiety nie uda się odnaleźć w pakiecie komunika­ tów, mechanizm wizualizacji koduje etykiety w niezmienionej formie. Pakiet komunikatów wskazujemy za pośrednictwem atrybutu resourceBundl e:

■ „Przetwarzanie facet” ; ■ „Kodowanie stylów C SS” ; ■ „Stosowanie pól ukrytych” ; ■ „Zapisywanie i przywracanie stanu” ; ■ „Generowanie zdarzeń akcji” .

Przetwarzanie znaczników potomnych typu Selectltem Panel podzielony na zakładki oferuje możliwość definiowania zakładek za pośrednictwem znaczników f: selectltem lub f : sel ect Items. Wspomniane znaczniki tworzą komponenty typu UlSelectltem, po czym dodają je do komponentu panelu podzielonego na zakładki jako jego komponenty potomne. Ponieważ mechanizm odpowiedzialny za wizualizację naszego komponentu musi wizualizować także te komponenty potomne, powinien nadpisywać metody rendersChildrenO i encodeChildren(): public boolean rendersChildren() { return true,

}

public void encodeChildren(FacesContext context, UlComponent component) throws java.io.IOException { / / ta metoda zostanie wywołana, nawet jeśli komponent panelu podzielonego 11 na zakładki nie ma komponentów potomnych i f (component.getChildCountO == 0) { return:

}

Warto zwrócić uwagę na etykiety elementów (zakładek), które mają postać kluczy wska­ zujących na odpowiednie pary w pakiecie komunikatów: jeffersonTabText=Jefferson rooseveltTabText=Roosevelt 1i ncolnTabText=Li ncol n washi ngtonTabText=Washington

List items = com.corejsf.util.Renderers.getSelectItems(context, component), Iterator it = items iteratorO; while (it.hasNextO) encodeTab(context, writer, (Selectltem) it.nextO, component);

376

JavaServer Faces Ogólnie komponent przetwarzający swoje komponenty potomne musi obejmować następujący fragment kodu: Iterator children = component.getChi 1dren() iteratorO. while (children.hasNextO) { UlComponent child = (UlComponent) children.nextO. processChild(context, writer, child, component).

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

377

Metoda encodeEnd sprawdza, czy treść aktualnie zaznaczonej zakładki odpowiada nazwie facety danego komponentu. Jeśli tak, przystępuje do kodowania tej facety przez wywołanie jej metod encodeBegin, encodeChi 1dren i encodeEnd. Za każdym razem, gdy mechanizm w i­ zualizacji przetwarza swoje obiekty potomne, automatycznie musi przejmować odpowie­ dzialność za realizację opisanych zadań.

EBJ javax.faces.component.UlComponent

} Z drugiej strony, nasza sytuacja jest bardziej skomplikowana. W ielu Czytelników zapewne pamięta z rozdziału 4., że wartością znacznika f : sel ect Items może być pojedynczy ele­ ment, kolekcja elementów, tablica elementów lub mapa obiektów Javy. Za każdym razem, gdy nasza klasa przetwarza obiekty potomne typów Selectltem lub Selectltems, musimy uwzględniać wszystkie możliwe kombinacje wymienionych możliwości. Metoda com.corejsf.util .Renderers.getSelectltems uwzględnia wszystkie te typy danych i na ich podstawie tworzy listę obiektów klasy Selectltem. Kod tej metody pomocniczej można znaleźć na listingu 9.12 we wcześniejszej części tego rozdziału. Metoda encodeChi 1dren klasy TabbedPaneRenderer wywołuje metodę getSelectltems i ko­ duje kolejno wszystkie komponenty potomne do postaci zakładek. Szczegóły tego mecha­ nizmu zostaną omówione w punkcie „Stosowanie pól ukrytych” w dalszej części tego pod­ rozdziału.

Przetwarzanie facet Panel podzielony na zakładki wykorzystuje nazwy facet identyfikacji treści właściwej dla poszczególnych zakładek. Metoda encodeEnd odpowiada za wizualizację wybranej facety: public void encodeEnd(FacesContext context, UlComponent component) throws java io.IOException { ResponseWriter writer = context.getResponseWriter(); UITabbedPane tabbedPane = (UITabbedPane) component, String content = tabbedPane.getContent(), i f (content != nul1) { UlComponent facet = component.getFacet(content); i f (facet != nul1) { i f (facet.isRenderedO) { facet,encodeBegin(context), i f (facet.getRendersChildrenO) facet.encodeChiIdren(context); facet.encodeEnd(context):

■ UlComponent getFacet(String facetName) Zwraca referencję do danej facety (jeśli taka faceta istnieje). Jeśli dana faceta nie istnieje, metoda getFacet zwraca wartość riul 1. ■ boolean getRendersChildrenO Zwraca wartość typu bool ean. Jeśli dany komponent odpowiada za wizualizację swoich potomków, zwraca true; w przeciwnym razie metoda getRendersChi 1dren zwraca fal se. Jeśli metoda getRendersChi 1dren zwróci wartość fal se, metoda encodeChi 1dren danego komponentu w ogóle nie zostanie wywołana. Metoda getRendersChi 1dren domyślnie zwraca właśnie wartość tai se. ■ boolean isRenderedO Zwraca wartość właściwości rendered. Komponent jest wizualizowany tylko wtedy, gdy wspomniana właściwość ma wartość true.

Kodowanie stylów CSS Obsługa stylów C SS jest procesem dwuetapowym: 1. Należy dodać odpowiedni atrybut do deskryptora biblioteki znaczników (T LD ).

2. Należy zakodować atrybut danego komponentu w metodzie encode klasy odpowiedzialnej za wizualizację. W pierwszej kolejności dodajemy atrybuty styleClass, tabCl ass i sel ectedTabCl ass do pliku deskryptora TLD : styleClass Styl CSS stosowany dla tego komponentu

} Klasa UITabbedPane definiuje pole content reprezentujące nazwę facety lub adres U R L aktualnie wyświetlanej zakładki.

W kolejnym kroku powinniśmy napisać atrybuty dla klas CSS: public class TabbedPaneRenderer extends Renderer {

378

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

JavaServer Faces public void encodeBegin(FacesContext context, UlComponent component) throws J a v a .io.IOException { ResponseWriter writer = context,getResponseWriter(), writer.startElementC'table", component); String styleClass = (String) component.getAttributesO.get("styleClass"), i f (styleClass != nul1) writer wniteAttributeC’class", styleClass, "styleClass"): wri ter .wri te( "\n"): // w ten sposób poprawiamy czytelność generowanego kodu HTML-a

}

public void encodeChildren(FacesContext context, UlComponent component) throws Java.i o .IOException { encodeTab(context, responseWriter, selectltem, component),

} private void encodeTab(FacesContext context, ResponseWriter writer, Selectltem item. UlComponent component) throws java.io.IOException { String tabText = getLocalizedTabText(component, item.getLabel()), String tabClass = n u ll, i f (content.equa1s(selectedContent)) tabClass = (String) component.getAttributesO .getC'selectedTabClass"), else tabClass = (String) component.getAttributesO.getC'tabClass"); i f (tabClass != nul1) writer.writeAttributeOclass", tabClass, "tabClass"):

379

informacjami o wybranej zakładce. Odpowiednie dane są składowane w polu ukrytym znajdującym się za wszystkimi zakładkami:

Oprócz danych formularza na serwer jest odsyłana także nazwa i wartość tego pola ukrytego, dzięki czemu metoda decode może aktywować właściwą zakładkę. Metoda encodeTab klasy odpowiedzialnej za wizualizację generuje znaczniki hiperłącza. Metoda encodeEnd wywołuje metodę encodeHiddenFields, która z kolei koduje nasze pole ukryte. Szczegółowe elementy opisywanego mechanizmu można znaleźć na listingu 9.17 w dalszej części tego rozdziału. Kiedy klasa odpowiedzialna za wizualizację komponentu panelu podzielonego na zakładki dekoduje otrzymane żądanie, wykorzystuje parametr żądania właściwy dla naszego pola ukrytego do określenia zawartości tego komponentu: public void decode(FacesContext context, UlComponent component) { Map requestParams = context.getExternalContext 0 .getRequestParameterMapO; String clientld = component.getClientld(context), String content = (String) ( requestParams.get(clientld)); i f (content != null && !content.equals("")) { UITabbedPane tabbedPane = (UITabbedPane) component, tabbedPane.setContent(content):

}

} ’

Zapisywanie i przywracanie stanu

} Atrybut styleClass kodujemy dla tabeli zewnętrznej panelu podzielonego na zakładki, na­ tomiast atrybuty tabClass i selectedTabClass kodujemy dla poszczególnych znaczników.

[¡¡I javax.faces.model .Selectltem ■ Object getValueO

Kiedy nasza aplikacja zapisuje swój stan na serwerze, obiekty widoku są składowane w pamięci operacyjnej. Z drugiej strony, kiedy stan aplikacji jest zapisywany po stronie klienta, obiekty widoku są kodowane i składowane w polu ukrytym (w formie bardzo długiego łańcucha, którego przykład przedstawiono poniżej):

Zwraca wartość wybranego elementu.

Stosowanie pól ukrytych


Każda zakładka naszego panelu jest kodowana w formie hiperłącza — przykład takiej kon­ strukcji przedstawiono poniżej:
foms[ formld][cl ient Id] formI d ] . submi t ( ) . " / >

one l i c k = " d o c u m e n t form s[

Pomiędzy kolejnymi żądaniami implementacja JS F zapisuje i przywraca wszystkie obiekty bieżącego widoku. Do utrwalanych i odczytywanych należą komponenty, konwertery, mecha­ nizmy weryfikacji oraz obiekty nasłuchujące zdarzeń. Mechanizm zapisywania stanu własnego, niestandardowego komponentu będziemy musieli zaimplementować samodzielnie.

v a l u e^content.

Kiedy użytkownik klika określone hiperłącze, następuje przesłanie formularza na serwer (wartość atrybutu href wskazuje na bieżącą stronę). Serwer musi oczywiście dysponować

id= "javax faces V iew Sta te "

va 1ue=" rO0ABXl\|yACBjb20uc3VuLmZhY2VzL nVOaWwuVHJ 1ZVNOcnVjdHVyZRRmGOQc 1WAgAgAET AA J 4ANXBwcHBwcHBwcHBwCHBwcHBxAH4ANXEAfgAlcHBwcHQABnNlVmlpdHVxAH4ALAAAAAA-" />

Zapisywanie stanu po stronie klienta jest niezbędne, jeśli nasza aplikacja ma być wykorzy­ stywana przez użytkowników, którzy wyłączyli obsługę znaczników kontekstu klienta. Opisywany mechanizm poprawia też skalowalność aplikacji internetowej. Zapisywanie stanu aplikacji po stronie klienta oczywiście ma też swoje wady: największą z nich jest konieczność przesyłania obszernych informacji o stanie w ramach wszystkich żądań i odpowiedzi.

380

JavaServer Faces Klasa UITabbedPane definiuje pole egzemplarza reprezentujące nazwę facety właściwej dla aktualnie prezentowanej zakładki. Jeśli nasze komponenty obejmują pole egzemplarzy i jeśli istnieje możliwość wykorzystywania tych komponentów w ramach aplikacji internetowych, których stan jest zapisywany po stronie klienta, musimy zaimplementować metody saveState i restoreState interfejsu StateHolder. Wymienione metody mają następującą postać: public Object saveState(FacesContext context) { Object values[] = new 0bject[n], va1ues[0] = supen saveState(context); values[1] = pole egzemplarza #1, values[2] = pole egzemplarza #2 : return values:

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące ■ Dodać do kodu strony index.jsp przycisk zdefiniowany przez konstrukcję . ■ Uruchomić aplikację i kliknąć jedną z zakładek. ■ Kliknąć przycisk Przetestuj zapisywanie stanu. Bieżąca strona zostanie co prawda ponownie wyświetlona, jednak na tej stronie nie będzie już zaznaczona żadna z zakładek!

Opisany problem wynika z faktu, że stan strony jest zapisywany po stronie klienta i kodo­ wany w formie wartości pola ukrytego. W momencie ponownego wyświetlania strony jest konstruowany nowy obiekt klasy UITabbedPane, po czym następuje wywołanie jego metody restoreState. Jeśli klasa UITabbedPane nie nadpisuje metody restoreState, wartość pola content nie jest przywracana.

} public void restoreState(FacesContext context, Object state) { Object values[] = (Object[ ]) state, super.restoreState(context, values[0]): pole egzemplarza #1 = (.Typ) val ues [1]: pole egzemplarza #2 = (Typ) values[2]:

} W przedstawionym rozwiązaniu zakładamy, że wartości pól egzemplarzy mogą być serializowane. Gdyby było inaczej, musielibyśmy samodzielnie operować na reprezentacji stanu komponentu. (Więcej informacji na temat mechanizmu serializacji w Javie można znaleźć w rozdziale 12. książki Core Java™ 2, vol. 1 — Advanced Features (7th ed.) 1autorstwa Cay a Horstmanna i Gary’ego Cornelia). Implementację mechanizmu zapisywania i odtwarzania stanu klasy UITabbedPane można znaleźć na listingu 9.16 w dalszej części tego rozdziału.

Jeśli wszystkie informacje opisujące stan w formie atrybutów, nie będziemy musieli implei restoreState, ponieważ atrybuty k o m p o n ™ implementację JSF. Na przykład kompone wykorzystywać atrybut "content" zamiast pola content.

a

ly składować I saveState ani ycznie przez kładki może

W takim przypadku w ogóle nie potrzebujemy klasy UITabbedPane — wystarczy użyć nadklasy UlCornmand i zadeklarować klasę komponentu za pośrednictwem następującej konstrukcji: com.corejsf.TabbedPane javax.faces.compónent .UICornrnand i | | t l | :|T TT j ;U J 7 % I S J f

Listing 9,16. Kod klasy tabbedpane/src/java/com/corejsf/UITabbedPane.java 1. package com.corejsf; 2.

P S I Wielu Czytelników zapewne nie rozumie, dlaczego nie zdecydowaliśmy się na użycie K i l standardowego algorytmu serializacji Javy. Mechanizm serializacji obiektów Javy jest co prawda dość elastyczny i uniwersalny, ale nie gwarantuje najbardziej efektywnego formatu kodowania stanu komponentów. Architektura JSF umożliwia twórcom kontenerów JS F konstruowanie bardziej efektywnych mechanizmów. Aby przekonać się, dlaczego zapisywanie stanu jest konieczne, warto przeprowadzić nastę­ pujący eksperyment: ■ Objąć metody saveState i restoreState komentarzami. ■ Aktywować mechanizm zapisywania stanu po stronie klienta przez dodanie następujących wierszy do pliku konfiguracyjnego web.xml: javax.faces.STATE_SAVING_METHOD client

1 Polskie wydanie: Java 2. Podstawy, Helion, 2003 — przyp. tłum.

381

3. import javax.faces.component.UlCornmand: 4. import javax.faces.context.FacesContext: 5. 6. public class UITabbedPane extends UlCornmand { 7. private String content: 8.

9. 10.

public String getContentO { return content: } public void setContent(String newValue) { content = newValue; }

11.

12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.

/ / A by sprawdzić, jaki będzie skutek niemożności prawidłowego zapisania I I stanu przez komponent, wystarczy objąć komentarzem te dwie metody. public Object saveState(FacesContext context) { Object val ues[] = new 0bject[3]: values f 0] = super.saveState(context); valuesfl] = content: return values; } public void restoreState(FacesContext context, Object state) { Object values[] = (Objectf]) state: super.restoreState(context, valuesf0]);

382

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

JavaServer Faces 24

content = (S t r in g ) vd 1ues[1 ] .

25

}

26 }

_

_

QQQjavax. faces. component. StateHolcier ■ Object saveState(FacesContext context)

Zwraca obiekt typu Seria 1izable, który zapisuje stan danego obiektu. ■

void rescoreState(FacesContext context. Object state)

Przywraca stan tego obiektu na podstawie danego obiektu stanu, który ma postać kopii obiektu uzyskanego wcześniej za pomocą wywołania metody saveState. ■

void setTransient(boolean newValue)

■ boolean isTransientO Ustawia i zwraca wartość właściwości pomijania. Po ustawieniu tej właściwości stan danego komponentu nie jest zapisywany.

Generowanie zdarzeń akcji Jeśli nasz komponent ma obsługiwać zdarzenia akcji lub same akcje, musimy podjąć nastę­ pujące kroki: ■ Komponent powinien rozszerzać klasę bazową UICommmand. ■ Musimy kolejkować obiekty klasy Acti onEvent w ramach metody decode naszego mechanizmu wizualizacji. Komponent panelu podzielonego na zakładki generuje zdarzenie akcji w chwili kliknięcia przez użytkownika którejś z zakładek tego komponentu. Odpowiednia akcja jest umieszczana w kolejce przez metodę decode klasy TabbedPaneRenderer: public void decode(FacesContext context, UlComponent component) { UITabbedPane tabbedPane = (UITabbedPane) component; component.queueEvent(new ActionEvent(tabbedPane));

} Na tym możemy zakończyć naszą analizę klasy TabbedPaneRenderer. Kompletny kod tej klasy przedstawiono na listingu 9.17. Klasa TabbedPaneTag jest równie nieciekawa jak w poprzednich wersjach naszej aplikacji, stąd zrezygnowano z jej ponownego prezentowania.

Listing 9.17. Kod klasy tabbedpane/src/java/com/corejsf/TabbedPaneRenderer.java________________ 1. package com.corejsf; 2.

3. import j ava.i o.IOException; 4. import java.util.Map; 5. import java.u ti1.1ogging.Level;

6 7 8 9 10 11 12 13 J4 15 16 17 18 19

383

import java util logging.Logger. import javax faces component UlComponent

import javax faces context.ExternaIContext. import javax faces context.FacesContext. import javax faces context Responsewrite r. import javax faces event ActionEvent. import javax faces.model Selectltem. import javax faces. render Renderer. import javax servlet.SenvletContext. import javax.servlet ServletException import javax servlet ServletRequest import javax servlet ServletResponse. / / Klasa odpowiedzialna za wizualizację komponentu UITabbedPane

20

21. 22 23. 24 25. 26. 27. 28. 29. 30. 31. 32. 33. 34 35. 36. 37. 38 39 40 . 41 42. 43. 44. 45. 46. 47. 48. 49 50. 51. 52. 53. 54. 55. 56. 57 58. 59. 60 . 61. 62.

public class TabbedPaneRenderer extends Renderer { private static Logger logger = Logger.getLogger("com.corejsf.util"); / / Metoda getRenders ChiIdrenQ domyślnie zwraca wartośćfalse, zatem metoda encodeChildrenQ nie zostanie // wywołana, dopóki nie nadpiszemv metody getRenders Children () wersją zwracającą wartość tnie. public boolean getRendersChildren() { return true; } // // II II II

Metoda decode uzyskuje wartość parametru żądania, którego nazwa odpowiada identyfikatorowi klienta komponentu panelu podzielonego na zakładki. Odpowiedni parametr żądaniajest kodowany przez metodę encodeHiddenField (wywoływaną przez metodę encodeEnd) wformie pola ukrytego. Wartość tego parametni jest ustawiana przez skryptjęzyka JavaScript wygenerowany przez metodę encodeTab i reprezentuje nazwę facety lub strony JSP.

/ / Metoda decode wykorzystuje wartość tego parametru żądania do ustawienia I I atrybutu treści komponentu panelu podzielonego na zakładki. I I I wreszcie metoda decodeQ umieszcza zdarzenie akcji w kolejce, z której zostanie I I przekazane metodom nasłuchującym wfazie wywołania aplikacji cyklu życia JSF. I / Metody nasłuchujące akcji można definiować za pośrednictwem atrybutu I I actionListener znacznika lub znaczników I I w ciele znacznika . public void decode(FacesContext context, UlComponent component) { Map requestParams = context.getExternalContext O .getRequestParameterMap(); String clientld = component.getClientld(context); String content = (String) (requestParams.get(clientld)); i f (content != null && ! content.equals(" " )) { UITabbedPane tabbedPane = (UITabbedPane) component; tabbedPane.setContent(content); } component.queueEvent(new ActionEvent(component)), } / / Metoda encodeBegin zapisuje początkowy element języka HTML I I wraz z klasą CSS wskazywaną za pośrednictwem atrybutu styleClass / 1 znacznika (jeśli taki atrybut w ogóle zdefiniowano).

384

JavaServer Faces 63. 64. 65 66 67 68. 69 70. 71. 72. 73. 74. 75.

76. 77

.

78. 79. 80. 81. 82. 83. 84. 85.

public void encodeBegin(FacesContext context. UlComponent component) throws Java.io.IOException { ResponseWriter writer = context.getResponseWriter(); writer.startElementC"table", component): String styleClass = (String) component.getAttributesO,get("styleClass"), i f (styleClass != null) writer writeAttributeC'class". styleClass. null); wri te r .wri te (" \n"); / / taki krok poprawia czytelność generowanego kodu HTML-a }

I I Metoda encodeChildren() jest wywoływana przez implementację JSFpo metodzie encodeBegin(). I I Elementy potomne względem komponentu mają postać komponentów UISelectItem / / ustawionych za pośrednictwem jednego lub wielu znaczników> bądź pojedynczego znacznika I I w ciele znacznika . public void encodeChildren(FacesContext context, UlComponent component) throws java.io.IOException {

I I Metoda encodeChildren jest wywoływana, nawetjeśli komponent tabbedpane I I nie obejmuje komponentów potomnych. i f (component.getChiIdCountO == 0) { return:

86.

87. 88. 89 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107 . 108. 109. 110.

111. 112. 113. 114. 115.

116. 117. 118.

}

ResponseWriter writer = context.getResponseWriter(); writer.startElementC'thead", component); writer.startElementC'tr", component); writer.startElementCth", component); writer.startElementC'table". component); writer.startElementC'tbody", component); writer.startElementC'tr", component); for (SelectItem item : com.corejsf.util.Renderers.getSelectltems(component)) encodeTab(context, writer, item, component); writer.endElementCtr"); writer.endElementC'tbody"); writer.endElement("table"); writer.endElementC'th"); writer.endElementCtr"); writer.endElementC'thead"); wri te r.wri te (" \n"); II taki krok poprawia czytelność generowanego kodu HTML-a }

I I Metoda encodeEndOjest wywoływana przez implementację JSFpo metodzie encodeChildrenQ. I I Metoda encodeEnd() zapisuje ciało tabeli i koduje zawartość komponentu tabbedpane / / w ramach pojedynczego wiersza tej tabeli. I I Treść panelu podzielonego na zakładki określamy albo wformie adresu URL wskazującego na stronę JSP, albo w formie nazwyfacety. Metoda encodeEnd() I I spraw’dza, czy wskazano facetę; jeśli tak, koduje ją; jeśli nie, dołącza stronę JSP. //

public void encodeEnd(FacesContext context. UlComponent component)

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące 119. 120. 121 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175.

385

throws java.io.IOException { ResponseWriter writer = context,getResponseWriter(); UITabbedPane tabbedPane = (UITabbedPane) component: String content = tabbedPane.getContent(), writer startElement("tbody", component); writer.startElementC'tr", component), writer.startElementC'td", component); i f (content != null) { UlComponent facet = component.getFacet(content); i f (facet != null) { i f (facet.isRenderedO) { facet.encodeBegin(context), i f (facet.getRendersChildrenO) facet.encodeChildren(context); facet.encodeEnd(context); } } else includePage(context, component), } writer.endElementC'td"); writer.endElement("tr"); writer.endElementC'tbody"); //

Zamyka elementy kolumny, wiersza i tabeli.

writer.endElement("ta b le "); encodeHiddenField(context, writer, component); } //

Metoda encodeHiddenFieldjest wywoływana na końcu metody encodeEndQ. Znaczenie ukrytego ijego wartości wyjaśniono przy okazji omawiania metody decode.

/ / pola

private void encodeHiddenField(FacesContext context, ResponseWriter writer, UlComponent component) throws java io.IOException { //

Zapisuje pole ukryte, którego nazwa odpowiada identyfikatorowi klienta.

w riter.startElement("input", component); writer.writeAttributeC'type", "hidden", null); wri te r .wri teAttri bute("name", component.getCli entId(context), nul1); writer.endElement("input"); }

I I Metoda encodeTab (wywoływana z poziomu metody encodeChildren) koduje element kotwicyjęzyka / / HTML z atrybutem onclick, który wymusza ustawianie wartości pola ukrytego zakodowanego przez I I metodę encodeHiddenField i wysłanie na serwer całegoformularza. Więcej informacji na temat / / samego pola ukrytego można znaleźć w komentarzu poświęconym metodzie decode. Metoda encodeTab / / dodatkowo zapisuje atrybut class dla poszczególnych zakładek; wartość tego atrybutu wskazuje albo I I na atrybut tabClass (wprzypadku niezaznaczonych zakładek), albo na atrybut selectedTabClass // (wprzypadku zakładki zaznaczonej). private void encodeTab(FacesContext context, ResponseWriter writer, Selectltem item, UlComponent component) throws java.io .IOException { String tabText = getLocalizedTabText(component,item.getLabel()); String content = (String) item.getValue();

386

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

JavaServer Faces 176. 177 178 179. 180 181. 182 183 184. 185. 186 187. 188 189 190 191 192 193 194 195. 196 197. 198. 199

writer startElementC'td", component), writer startElement("a", component), writer.writeAttribute("href", "#", "href"); String clientld = component.getClientld(context); String formld = com.corejsf util Renderers,getFormId(context, component); writer.writeAttribute("oncl ic k ", //

Zapisuje wartość pola ukrytego, którego nazwa odpowiada identyfikatorowi klienta. "document forms[’" + formld + + content + " 1: " +

+ clientld + " ’] value=’ "

/ / Wysyłaformularz, do którego należy komponent panelu. "document.forms[ + formld + " 1] .submit(); ", nuli); UITabbedPane tabbedPane = (UITabbedPane) component, String selectedContent = tabbedPane.getContent(), String tabClass = nuli; i f (content.equals(selectedContent)) tabClass = (String) component.getAttributes() ,get("selectedTabClass"), else tabClass = (String) component.getAttributes() ,get("tabClass");

387

232. / / Metoda includePage wykorzystuje mechanizm rozdziału żądań serwletu do 233. / 1 dołączania strony właściwej dla wybranej zakładki. 234. 235 private void includePage(FacesContext fc, UlComponent component) { 236. External Context ec = fc .getExternal Context( ); 237 SenvletContext sc = (ServletContext) ec.getContextO: 238. UITabbedPane tabbedPane = (UITabbedPane) component; 239. String content = tabbedPane,getContent(); 240. 241. ServletRequest request = (ServletRequest) ec.getRequest(), 242. ServletResponse response = (ServletResponse) ec.getResponse(); 243 try { 244. sc.getRequestDispatcher(content).include(request, response); 245. } catch (ServletException ex) { 246 logger.log(Level.WARNING, "Nie można załadować strony. " + content, ex); 247. } catch (IOException ex) { 248. logger.log(Level.WARNING, "Nie można załadować strony " + content, ex), 249. } 250. } 251 }

200

201 202 203. 204. 205. 206. •207 208 209.

i f (tabClass != nul1) writer.writeAttribute("class", tabClass, null); writer.write(tabText); writer.endElementCa"); writer endElementCtd"); wri te r .wr i te (" \n"), I I taki krok poprawia czytelność generowanego kodu HTML-a }

0201482330310023235300312353233253024823 . .

na zakładki

Na rysunku 9.9 (we wcześniejszej części tego rozdziału) przedstawiono przykładową stronę aplikacji tabbedpane. Strukturę katalogów tej aplikacji przedstawiono na rysunku 9.11. Na listingu 9.18 przedstawiono kod strony index.jsp. Na listingach od 9.19 do 9.22 przedsta­ wiono odpowiednio deskryptor biblioteki znaczników, klasę znacznika, plik konfiguracyjny oraz arkusz stylów tej aplikacji.

210. 211. 212

213. 214. 215.

216. 217. 218. 219. 220.

Tekst właściwy dla zakładek naszego komponentu panelu możemy zdefiniować albo z wykorzystaniem kluczy pakietu komunikatów, albo bezpośrednio wformie tekstu wyświetlanego w zakładce. Na podstawie I / tego tekstu metoda getLocalizedTabText próbuje odnaleźć odpowiednią wartość w pakiecie komunikatów / / wskazanym za pośrednictwem atrybutu resourceBundle znacznika . Jeśli próba I I odnalezienia tej wartości zakończy się niepowodzeniem, metoda getLocalizedTabText zwraca łańcuch, I I który przekazano najej wejściu. //

Rysunek 9.11.

//

Struktura katalogów aplikacji ilustrującej działanie komponentu panelu podzielonego na zakładki

private String getLocalizedTabText(UIComponent tabbedPane, String key) { String bundle = (String) tabbedPane.getAttributes() .get("resourceBundle"), String localizedText = null;

f j

. Q MANIFEST.MF w e b - in f 11| 3 classes f ■(¡3 com f £ 3 corejsf ~mSi Util 1L 1

i f (bundle != nul1) { localizedText = com.corejsf.util.Messages.getString(bundle, key, null); } i f (localizedText == null) localizedText = key; / / Jeśli parametr key nie reprezentuje istniejącego klucza wpakiecie komunikatów, / / zwracamy łańcuch wejściowy w niezmienionej formie. return localizedText; }

j

i-- Q

:

Q

Messages.class Renderers. class

;..Q TabbedPaneRenderer. class ..D TabbedPane!ag.class Q ¡~

221.

222. 223. 224. 225. 226. 227 . 228. 229. 230 231.

¡ 3 tabbedpane.w ar f E 3 META-tNF

UITabbedPane.class

Q messages, properties

Q tabbedpane.tld Q faces-conflg.xm l

!. Q web.xm l f- | 3 images ¡~

Q jefferson.jpg

r D lincoln.jpg - D rooseveit.jpg L Q Washington,jpg Q stytes.css !"- E j index.html Q index.jsp

388

JavaServer Faces

Listing 9.18. Kodstrony tabbedpane/web/index.jsp 1. 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. <%$ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. taglib uri="http://corejsf.com/tabbedpane" prefix="corejsf" %> 5. 6. 7. 8. 9. 10. 11. 12. 15. 16. 17. 18. 20. 21. 22. 23. 24. 25. 27. 28. 29. 30. 31. 32. 34. 35. 36. 37. 38. 39. 41. 42. 43. 44. 48. 50. 52. 53. 54. 55. 56. 57.

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące Listing 9.19.

Deskryptor

389

tabbedpane/web/Wtld

1. 2. 7. A library containing a tabbed pane 8. l.l 9. tabbedpane 10. http://corejsf,com/tabbedpane 11. 12. Znacznik dla komponentu panelu podzielonego na zakładki 13. tabbedPane 14. com.corejsf.TabbedPaneTag 15. JSP 16. 17. Identyfikator tego komponentu 18. id 19. true 20. 21. 22. 23. Wyrażenie reprezentujące referencję do tego komponentu 24. 25. binding 26. 27. javax.faces.component.UIComponent 28. 29. 30. 31. 32. Flaga określająca, czy ten komponent powinien, czy nie powinien być 33. wizualizowany. Wartością domyślną tej flagi jest true. 34. 35. rendered 36. 37. boolean 38. 39. 40. 41. Styl CSS stosowany dla tego komponentu 42. style 43. 44. java.1ang.String 45. 46. 47. 48. Klasa CSS stosowana dla tego komponentu 49. styleClass 50. 51. java.1ang.Stri ng 52. 53 54. 55. Klasa CSS stosowana dla niezaznaczonych zakładek

390

JavaServerFaces 56 57. 58 59 60 61. 62 63. 64. 65 66 67. 68. 69. 70. 71 72 73. 74. 75 76. 77. 78. 79. 80. 81 82. 83. 84. 85. 86. 87. 88. 89.

tabClass java.lang.String Klasa CSS stosowana dla zaznaczonej zakładki sel ectedTabClass java.lang.String Pakiet komunikatów wykorzystywany do lokalizacji etykiet kontrolek resourceBundle java.1ang.Stri ng Wyrażenie reprezentujące metodę wywoływaną w odpowiedzi na zaznaczenie zakładki actionListener void actionListener(javax.faces.event.ActionEvent)

Listing 9.20. Kod klasy tabbedpane/src/java/com/corejsf/TabbedPaneTag.java package com.corejsf, import import import import import 8 import //

javax.el.MethodExpression; javax.el ValueExpression, javax.faces.component.ActionSource; javax.faces.component.UlComponent; javax.faces.event.MethodExpressionActioriListener; javax.faces.webapp.UIComponentELTag;

Ten znacznik obsługuje następujące atrybuty:

// I I binding (obsługiwany przez klasę UIComponentELTag) U id (obsługiwany przez klasę UIComponentELTag) / / rendered (obsługiwany przez klasę UIComponentELTag) / / style / / styleClass / / tabClass / / selectedTabClass

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące 19 20 . 21. 22. 23. 24 25. 26 27. 28. 29. 30 31. 32 33. 34. 35. 36. 37. 38. 39. 40 41 42. 43. 44. 45. 46 47. 48. 49. 50 51. 52. 53. 54. 55 56. 57. 58. 59. 60 61. 62 63. 64. 65. 66. 67. 68. 69 70. 71. 72. 73.

// resourceBundle / / actionListener public class TabbedPaneTag extends UIComponentELTag { private ValueExpression style, private ValueExpression styleClass; private ValueExpression tabClass, private ValueExpression selectedTabClass, private ValueExpression resourceBundle; private MethodExpression actionListener, public String getRendererType() { return "com.corejsf TabbedPane"; } public String getComponentType() { return "com.corejsf TabbedPane"; } public void setTabClass(ValueExpression newValue) { tabClass = newValue: } public void setSelectedTabClassCValueExpression newValue) { selectedTabClass = newValue, } public void setStyle(ValueExpression newValue) { style = newValue, } public void setStyleClass(ValueExpression newValue) { styleClass = newValue; } public void setResourceBundle(ValueExpression newValue) { resourceBundle = newValue; } public void setActioriListener(MethodExpression newValue) { actionListener = newValue, } protected void setProperties(UIComponent component) {

11 Wpierwszej kolejności należy wywołać odpowiednią metodę nadklasy: super.setProperties(component); component.setValueExpression("style", style); component.setValueExpressionCstyleClass", styleClass), component.setValueExpression!"tabClass", tabClass), component.setValueExpression!"selectedTabClass", selectedTabClass); component.setValueExpressionC'resourceBundle", resourceBundle); i f (actionListener != null) ((ActionSource) component),addActionListener( new MethodExpressionActionListener(actionListener)), } public void releaseO {

11 Wpierwszej kolejności należy wywołać odpowiednią metodę nadklasy: super.release(); style = riul 1, styleClass = n u li; tabClass = n u li, selectedTabClass = nuli; resourceBundle = nul 1; actionListener = nul 1; } }

391

392

JavaServer Faces

Listing 9.21. Plik konfiguracyjny tabbedpane/web/WEB-INF/faces-config.xml 1 2. 7. 8. /index.jsp 9 10 /wel conie.jsp 11 12 13. 14 15. Panel zakladek 16. com.corejsf.TabbedPane 17. com.corejsf.UITabbedPane 18 19. 20. 21. 22. component-fami 1y>javax.faces.Comnand 23. coni.corejsf.TabbedPane 24. com.corejsf TabbedPaneRenderer 25. 26. 27. 28. 29 30. com.corejsf.messages 31. nisgs 32. 33. 34.

Listing 9.22. Arkusz stylów tabbedpane/web/styles.css 1. 2. 3. 4. 5. 6. 78. 9. 10. 11.

body { background: #eee: } .tabbedPane { vertical-align: top, border: thin solid Blue: } .tab { padding: 3px; border- thin solid CornflowerBlue; color: Blue:

12. }

13. .selectedTab { 14. padding: 3px; 15. border thin solid CornflowerBlue; 16. color: Blue: 17. background: PowderBlue, 18. }

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

393

implementacja niestandardowych konwerterów i mechanizmów weryfikacji Niestandardowe konwertery i mechanizmy weryfikacji, które omówiono w rozdziale 6. tej książki, były obciążone poważną wadą: ich funkcjonowanie nie było uzależnione od para­ metrów. Nie mogliśmy na przykład określać znaku separatora dla konwertera numerów kart kredytowych, co uniemożliwiało projektantom stron decydowanie, czy w tej roli powinny być stosowane myślniki, czy spacje. Innymi słowy, konwertery niestandardowe powinny oferować identyczne możliwości jak standardowe znaczniki f :convertNumber i f :convertDateTime. W szczególności chcielibyśmy umożliwić projektantom stron stosowanie naszych znaczników w ramach następujących konstrukcji:

W tym celu musimy zaimplementować znacznik konwertera niestandardowego. Podobnie jak znaczniki komponentów niestandardowych, tak i znaczniki konwerterów niestandardowych wymagają sporego zaangażowania ze strony programistów, ale też zapewniają możliwość wielokrotnego stosowania znaczników i wygodę oczekiwaną przez autorów stron.

Znaczniki konwerterów niestandardowych Podobnie jak to się dzieje w przypadku znaczników komponentów niestandardowych, specy­ fikację znaczników konwerterów niestandardowych należy zdefiniować w pliku deskryptora TLD . Sam plik deskryptora powinniśmy umieścić w katalogu WEB-INF. Deskryptor TLD opisujący znacznik niestandardowy convertCreditcard przedstawiono na listingu 9.13.

Listing 9.23. Plik deskryptora custom-converter/web/WEB-INF/converter, tld_________________________ 1 2. 7. l.l 8 l.l 9. converter 10. http://corejsf.com/converter 11.

12. 13. 14. 15 16. 17. 18 19

convertCreditcard com.corejsf.CreditCardConverterTag empty separator java.1ang.String

394

JavaServer Faces 20. 21. 22 23.

W pisy zawarte w przedstawionym powyżej pliku deskryptora nie wymagają dodatkowych wyjaśnień. Zadaniem tego pliku jest zdefiniowanie nazwy klasy odpowiedzialnej za obsługę znacznika (w tym przypadku com.corejsf .CreditCardConverterTag) oraz atrybutów obsługi­ wanych w ramach tego znacznika (w tym przypadku tylko atrybutu separator). Warto zwrócić szczególną uwagę na znacznik uri identyfikujący bibliotekę znaczników. Element potomny deferred-val ue użyty wewnątrz definicji atrybutu separator określa, że dany atrybut jest definiowany przez wyrażenie reprezentujące wartość, które po przetworzeniu powinno mieć postać łańcucha. Atrybutowi separator można przypisywać zarówno stałe łańcuchowe, jak i łańcuchy obejmujące wyrażenia # { ...}. Do identyfikatora zdefiniowanego w deskryptorze TLD odwołujemy się w dyrektywie tagl i b strony JSF : taglib uri="http://corejsf com/converter” prefix="corejsf" %>

Klasa obsługująca znacznik, którą musimy sami zaimplementować, odpowiada za realizację trzech zadań: 1.

Wskazanie klasy konwertera.

2. Odczyt atrybutów znacznika. 3. Konfigurację obiektu konwertera z wykorzystaniem odczytanych atrybutów. W przypadku konwertera klasa odpowiedzialna za obsługę znacznika powinna dziedziczyć po klasie ConverterELTag. Jak się niedługo Czytelnicy przekonają, klasy obsługujące znaczniki niestandardowych mechanizmów weryfikacji muszą rozszerzać klasę bazową Val i datorELTag. | W starszych wersjach technologii JSF musieliśmy tworzyć podklasy klas Conver ►terTag i ValidatorTag. Począwszy od wersji JSF 1.2, stosowanie obu tych klas bazowych nie jest zalecane. Nasza klasa obsługująca znacznik musi definiować po jednej metodzie ustawiającej dla każ­ dego atrybutu znacznika. Przykład takiej metody przedstawiono poniżej: public class ConveaOeditCardTag extends ConverterELTag { private ValueExpression separator, public void setSeparaior(VaiueExpression newValue) j separator = newVaiue. }

Rozdział 9. ■ Niestandardowe Komponent», konwertery i mechanizmy weryfikujące ELContext el Context = FacesContext.getCurrentlnstance!) .getELContext(); converter setSeparator((String) separator.getValue(elContext)); return converter;

} Nasza metoda ustawia właściwość separator klasy konwertera CreditCardConverter. I wreszcie dla każdej klasy obsługującej znacznik musimy zdefiniować metodę release, która odpowiada za przywrócenie oryginalnych (domyślnych) wartości we wszystkich polach egzemplarza: public void release!) { separator = n u ll;

} Kompletny kod klasy znacznika przedstawiono na listingu 9.24.

Listing 9.24. Kod klasy custom-converter/src/java/com/corejsf/CreditCardConverterTag.java_________ 1. package com.corejsf, 2.

3. 4. 5. 6 7. 8. 9. 10. 11.

import import import import import import

ja vax.el.ELContext: javax.el.ValueExpression, javax.faces.context.FacesContext, javax.faces.convert.Converter; javax.faces.webapp.ConverterELTag; javax.servlet.jsp.JspException;

public class CreditCardConverterTag extends ConverterELTag { private ValueExpression separator;

12.

13. 14. 15. 16 17 18 19 20 21

public void setSeparator(ValueExpression newValue) { separator = newValue; }

22

}

23 24 25 26 27

public voidrelease!) separator = nul 1. f

public ConvertercreateConverter!) throws JspException { CreditCardConverter converter = new CreditCardConve rte r(). ELContext elContext =FacesContextget Current Instance!) .get El Context!). converter setSeparator((String)separatorgetValue!elContext)), return converter.

{

}

flU javax.faces.webapp.ConverterELTag (JSF 1.2) Aby skonfigurować egzemplarz konwertera z odpowiednimi atrybutami znacznika, należy nadpisać metodę createC o n verter. W ciele tej metody powinniśmy skonstruować obiekt konwertera i przypisać jego właściwościom atrybuty znacznika: public Converter createConverter() throws JspException { CreditCardConverter converter = new CreditCardConverter()

395

■ protected void createConverter!) Należy tę metodę nadpisać, jeśli chcemy utworzyć własny konwerter i uzależnić jego działanie od wartości atrybutów znacznika.

396

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

JavaServer Faces ■

p u b lic void re sLo re Sta te(Fa cesC o n te x t con tex t. Object s t a t e ) O b je c t[ ] values = ( O b je ct[ ] ) s ta te . d a te S ty le = (S t r in g ) v a 1ues[0 ].

void releasee)

Zeruje stan danego znacznika, aby można go byio ponownie użyć.

397

{

lo c a le = (L o c a le ) v a lu e s [1]. p a tte rn = ( S t r in g ) va 1ues[2 ]

BBH javax.el.ValueExpression (JSF 1.2)

tim e S ty le = (S t r in g ) v a 1u e s [3 ]. timeZone = (TimeZone) valuesT4 ]. type = (S t r in g ) v a lu e s [5 ].

■ Object getValue(ELContext context)

Zwraca bieżącą wartość danego wyrażenia reprezentującego wartość.

BHB javax.faces.context.FacesContext (JSF 1.0) ■

Co więcej, interfejs StateHolder dodatkowo wymaga od programisty dodania właściwości transient. Jeśli ustawimy tę właściwość, dany obiekt nie zostanie zapisany. Właściwość transient jest odpowiednikiem słowa kluczowego transient stosowanego w mechanizmie serializacji Javy:

ELContext getELContext () (JS F 1.2)

Zwraca kontekst przetwarzania wyrażeń w danym języku wyrażeń.

p u b lic c la s s DateTmieConverter implements C onverter. StateH o ld e r {

Zapisywanie i przywracanie stanu

p r iv a te boolean tra n s ie n tF la g . // "transient" jest słowem zastrzeżonym p u b lic boolean i s Tra n s ie n t ( ) { retu rn tra n s ie n tF la g . }

Implementując konwertery i mechanizmy weryfikujące, musimy wybrać jedno z dwóch roz­ wiązań w zakresie zapisywania stanu. Prostszym wyjściem jest zdefiniowanie klasy konwertu­ jącej lub weryfikującej jako struktury serializowanej — wystarczy zaimplementować interfejs S e ria liz a b le i stosować się do typowych reguł serializacji w Javie. W przypadku konwertera numerów kart kredytowych mamy do czynienia z pojedynczym polem obiektu, który jest typu String, czyli typu podlegającego serializacji. W tej sytuacji musimy tylko zaimplementować interfejs Serial izable: pu blic c la s s C redu C ard C o nverter

implements C onverter. S e r ia l iz a b le {

}

Drugie rozwiązanie polega na opracowaniu konstruktora domyślnego i implementacji inter­ fejsu StateHolder. Takie podejście wymaga co prawda większego zaangażowania ze strony programisty, ale leż gwarantuje większą efektywność kodowania stanu obiektu. Z drugiej strony, w przypadku niewielkich obiektów (np. konwertera numerów kart kredytowych) lepszym wyjściem jest użycie standardowego mechanizmu serializacji. Kompletność naszych rozważań wymaga opisania interesującej nas techniki na przykładzie standardowego konwertera DateTimeConverter. W metodzie saveState interfejsu StateHolder konstruujemy obiekt serializowany, którego zadaniem jest opisywanie pola egzemplarza. Naturalnym wyborem jest tablica obiektów składująca w poszczególnych elementach reprezentowane pola egzemplarza. W metodzie restoreState odtwarzamy pola egzemplarza na podstawie obiektów tej tablicy. public class DateTimeConverter implements Converter, StateHolder { public Object saveState(FacesContext context) { Objectf] values = new 0bject[6]: valuesEO] = dateStyle; valuesEl] = locale: va1ues[2] = pattern, va1ues[3] = timeStyle, va J ues[4] = timeZone: va1ues[5] = type: return values:

p u b lic void s e tT ra n s ie n t( boolean newValue) { tra n s ie n tF la g = newValue.

}

Konwertery, mechanizmy weryfikacji i obiekty nasłuchujące zdarzeń, które nie imple­ mentują ani interfejsu Serializable, ani interfejsu StateHolder, są pomijane w procesie zapisywania widoku.

0

Oto prosty eksperyment, który jasno dowodzi, że konwertery powinny zapisywać " J swój stan. W pierwszej kolejności konfigurujemy aplikację custom-converter (w pliku ■ t i!' <ęontext~param>

lllillls . client

Z kodu kiasy CreditCardConverter należy teraz usunąć (lub objąć komentarzem) kon­ strukcję odwołującą się do interfejsu Serializable. W kolejnym kroku umieszczamy nowy przycisk na stronie result jsp:

Warto teraz wpisać numer karty kredytowej w formularzu na stronie irtdex.jsp, kliknąć przycisk Przetwórz: i sprawdzić, czy numer karty sformatowano z myślnikami: 4111-11111111-1111. Jeśli klikniemy przycisk Testuj zapisywanie stanu , okaże się, że myślniki zniknęły.

Przykładowa aplikacja zbudowana na bazie konwertera niestandardowego Na tym możemy zakończyć analizę przykładu konwertera niestandardowego. Na rysunku 9.12 przedstawiono strukturę katalogów tej aplikacji. Większość plików pozostała niezmieniona w porównaniu z poprzednim przykładem. Najważniejsza zmiana dotyczy kodu strony result.jsp, w którym odwołujemy się do naszego konwertera niestandardowego.

398

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

JavaServer Faces ¡¡3 custom-converter.war

Rysunek 9.12. Struktura katalogów programu ilustrującego działanie konwertera niestandardowego

f j \ \ | |

L Q MANIFEST. MF WEB-INF f - [3 classes j ¥ ( 3 com | f C3 corejsf I | Q CreditCard.class

|

|

: Q

CreditCardConverter.class

I |

|

i Q

CreditCardConverterTag. class

|

t-

Q FaymentBean. class

\ \ ' Q messages, properties | j~ Q corrverter.tld \ >r Q faces-config.xml j Q web. xml | D styles.css

r D index.html | D index.jsp D result.jsp_____________________________

Kod strony result.jsp przedstawiono na listingu 9.25. Kod zmodyfikowanego konwertera i pliku konfiguracyjnego przedstawiono odpowiednio na listingach 9.26 i 9.27.

Listing 9.25. Kod strony custom-converter/web/result.jsp 1. 2. <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. <%@ taglib uri="http://corejsf.com/converter" prefix="corejsf" %> 5. 6. 7. <1ink href=Mstyles.css" rel=’’stylesheet” type="text/css”/> 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27 28. 29. 30. 31. 32. 33.

< /htm l>

Listing 9.26. Kod klasy custom-converter/src/java/com/corejsf/CreditCardConverter.Java

meta-inf

1. package com.corejsf; 2.

3 4. 5. 6. 7. 8. 9 10 11

import java io.Serializable, import import import import

javax.faces.component.UlComponent, javax.faces.context.FacesContext; javax.faces.convert.Converter, javax.faces.convert.ConverterException;

public class CreditCardConverter implements Converter, Serializable { private String separator,

12.

13. 14. 15 16. 17 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31 32. 33. 34. 35 36 37 . 38. 39.

40 . 41. 42. 43. 44 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55.

// Właściwość separator: public void setSeparator(String newValue) { separator = newValue; } public Object getAsObject! FacesContext context, UlComponent component, String newValue) throws ConverterException { StringBuiIder builder = new StringBuilder(newValue); int i = 0; while (i < builder.length!)) { i f (Character.isDigit(buiIder charAt(i))) i ++; else buiIder.deleteCharAt(i), } return new CreditCard(builder.toStringO); } public String getAsString! FacesContext context, UlComponent component, Object value) throws ConverterException { / / Długość

13: xxxx xxx xxx xxx

/ / Długość 14: xxxxx xxxx xxxxx / / Długość 15: xxxx xxxxxx xxxxx

/ / Długość 16: xxxx xxxx xxxx xxxx / / Długość 22: xxxxxx xxxxxxxx xxxxxxxx i f ( ! (value instanceof CreditCard)) throw new ConverterException!); String v = ( (CreditCard) value).toString!); String sep = separator; i f (sep == null) sep = " "; in t[] boundaries = null; int length = v.length!); i f (length == 13) boundaries = new in t[] { 4, 7, 10 }, else i f (length == 14) boundaries = new in t[] { 5, 9 }; else i f (length == 15) boundaries = new in t[] { 4 , 10 }; else i f (length == 16)

399

400

JavaServerFaces 56. 57. 58. 59. 60. 61. 62. 63. 64 65. 66. 67. 68 . 69. 70. 71. 72 }

boundaries = new in t[] { 4 , 8, 12 }, else i f (length == 22) boundaries = new in t[] { 6 , 14 }, else return v, StringBuilder result = new StringBuilderO. int start = 0; for (int i = 0; i < boundaries length; i++) { int end = boundaries[ i ], result.append(v.substnng(start,end)); result.append(sep); start = end;

} result,append(v.substring(start)), return result.toString(); }

Listing 9.27. Plik konfiguracyjny custom-converter/web/WEB-INF/faces-config.xml 1. 2. 7. 8. /index.jsp 9 10. process 11. /result.jsp 12. 13. 14. 15. 16. /result.jsp 17. 18. back 19. /index.jsp 20. 21. 22. 23. 24. com.corejsf.Credi tCard 25. com.corejsf CreditCardConverter 26. 27. 28. 29 com.corejsf.CreditCard 30. com.corejsf.CreditCardConverter 31. 32. 33. 34. payment 35. com.corejsf.PaymentBean 36. session 37.

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

401

38. 39. 40. 41. com.corejsf.messages 42. msgs 43. 44 45.

Znaczniki niestandardowych mechanizmów weryfikacji W poprzednich punktach omówiono sposób implementacji konwertera niestandardowego zapewniającego autorom stron JS F wygodę porównywalną z wygodą stosowania standar­ dowych znaczników JS F . W tym punkcie skoncentrujemy się na technice konstruowania niestandardowych mechanizmów weryfikacji. Kroki składające się na proces konstruowania niestandardowego mechanizmu weryfikacji są niemal identyczne jak w przypadku niestandardowych konwerterów: 1.

Opracowanie pliku TFD i odwołanie się do tego deskryptora w kodzie stron JSF.

2. Implementacja klasy odpowiedzialnej za obsługę znacznika. Klasa znacznika musi rozszerzać klasę bazową Val i datorELTag, uzyskiwać atrybuty zadeklarowane w pliku deskryptora TFD i przekazywać je do obiektu weryfikującego.

3. Implementacja klasy mechanizmu weryfikującego. Klasa weryfikująca musi implementować interfejs Val i dator. Metoda val i date powinna pracować w standardowy sposób i generować wyjątek Val idatorException w razie wykrycia błędu. Aby stworzyć możliwość zapisywania i odtwarzania stanu obiektów weryfikujących, należy dodatkowo zaimplementować interfejs Serial izable lub StateHolder. Wróćmy teraz do przykładu mechanizmu weryfikującego numery kart kredytowych (patrz listing 9.27). Każdy numer karty kredytowej chcemy poddawać trzem testom: 1.

Sprawdzającemu, czy użytkownik podał jakąś wartość.

2. Sprawdzającemu, czy podany numer jest zgodny ze wzorem Fuhna. 3. Sprawdzającemu, czy podany numer rozpoczyna się od prawidłowego przedrostka. Przedrostek numeru karty kredytowej określa jej rodzaj — na przykład przedrostki z prze­ działu od 51 do 55 zarezerwowano dla kart MasterCard, natomiast przedrostek 4 jest stosowany dla kart Visa. Moglibyśmy oczywiście opracować własny kod realizujący to konkretne zadanie, jednak zdecydowaliśmy się na implementację bardziej uniwersalnego (i bardziej przydatnego) mechanizmu weryfikującego dowolne wyrażenia regularne. Opisywany mechanizm weryfikacji można zastosować w następujący sposób:

402

JavaServer Faces

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące % Aplikacja test u j ą mechanizm weryfikacji - Mozilla Firoto

Rysunek 9.13. Szczegółowa weryfikacja numeru karty kredytowej

Plik-

Edycja

<#• - #

Widok

- :®

Historia

'#

Zakładki

l i t i

Narzędzia

._ ................

P om oc

http://localhost:8980/custom-v:j *

v

jj^ j

l Prosim y w pisać dane o płatności: K w ota

:100,01)

Karta kredytowa

17111 1111 1111 1111

Data ważności (rmesiąc/rok)

2/200?

:

_

;

i

♦le-dnalubwiri<-rVbti'XOfVtJurfyjescnu/. ..prawna ♦ ITip,widny

k it iiy t e *

Dnww-j

fPgptwárz] Zakończono

Wyrażenie regularne [3-6] .* pasuje do każdego łańcucha rozpoczynającego się od cyfr z przedziału od 3 do 6. Moglibyśmy oczywiście opracować bardziej wyszukane wyrażenie regularne opisujące nieporównanie bardziej precyzyjne testy. Kod klasy weryfikującej przedstawiono na listingu 9.28. Analizując ten kod, należy mieć na uwadze, że naszym celem nie jest prezentacja modelu wyrażeń regularnych. Przeciwnie, interesuje nas działanie mechanizmów weryfikacji w sytuacji, gdy dane przekazywane przez komponenty okazują się nieprawidłowe — opisywany mechanizm generuje wówczas stosowny komunikat, po czym opakowuje go i rzuca w postaci wyjątku.

Listing 9.28. Kod klasy custom-validator/src/java/com/corejsf/RegexVaiidator.java__________________ 1. package com.corejsf; 2.

3. 4 5 6. 7. 8 9. 10. 11.

import java io.Serializable; import java.text.MessageFormat; import java.u ti1.Locale; import java.util.regex.Pattern; import javax.faces.application.FacesMessage; import javax.faces.component.UlComponent; import javax.faces.context.FacesContext; import javax.faces.validator.Validator; import javax.faces.validator.ValidatorException;

31. 32. 33. 34 35. 36 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49 50. 51. 52 53.

i f (errorDetail != nuli) message.setDetai1( new MessageFormat(errorDetai 1, locale) format(params)), throw new ValidatorException(message), } } / / Właściwość expression: public void setExpression(String newValue) { expression = newValue, pattern = Pattern.compile(expression); } / / Właściwość errorSummary: public void setErrorSummary(String newValue) { errorSummary = newValue; } / / Właściwość errorDetail: public void setErrorDetail(String newValue) { errorDetail = newValue, } }

Mechanizm weryfikujący domyślnie wyświetla komunikat o błędzie sygnalizujący brak zgod­ ności z określonym wyrażeniem regularnym. Jeśli użytkownikami naszej aplikacji mają być osoby, które nie dysponują szczegółową wiedzą o wyrażeniach regularnych, powinniśmy rozważyć zmianę tego komunikatu. Wykorzystamy do tego celu atrybuty errorSumrnmary i errorDetail. Wykorzystujemy znacznik niestandardowy, aby umożliwić dostarczanie parametrów mecha­ nizmowi weryfikującemu. Proces implementacji znacznika niestandardowego dla takiego mechanizmu przypomina proces tworzenia znacznika konwertera niestandardowego (opisany we wcześniejszej części tego rozdziału). Warto jednak pamiętać, że znacznik niestandardowego mechanizmu weryfikacji musi rozszerzać klasę bazową Val i datorTag. Implementację klasy RegexVal i datorTag przedstawiono na listingu 9.29.

12.

13 public class RegexValidator implements Validator, Serializable { 14 private String expression; 15. private Pattern pattern; 16. private String errorSummary; 17 private String errorDetail, 18. 19. public void validate(FacesContext context, UlComponent component, 20. Object value) { 21. i f (value == null) return; 22. i f (pattern == null) return; 23. if ( '.pattern.matcher(value.toString()) ,matches()) { 24. Object[] params = new Object[] { expression, value }, 25. Locale locale = context.getViewRoot() ,getLocale(); 26 FacesMessage message = com.corejsf.util.Messages.getMessage( 27 "com.corejsf.messages", "badRegex", params); 28. i f (errorSummary != null) 29. message.setSummary( 30. new MessageFormat(errorSummary, locale).format(params));

403

LiSling 9.29. Kod klasy custom-validator/src/java/com/corejsf/RegexValidatorTag.java 1. package com.corejsf; 2.

3. 4. 5. 6. 7. 8. 9. 10. 11. 12 13. 14. 15. 16.

import import import import import import

javax.el.ELContext; javax.el.ValueExpression; javax.faces.context.FacesContext; javax.faces.validator.Validator; javax.faces.webapp.ValidatorELTag; javax.servlet.jsp.JspException;

public class RegexValidatorTag extends ValidatorELTag { private ValueExpression expression; private ValueExpression errorSummary; private ValueExpression errorDetail; public void setExpression(ValueExpression newValue) expression = newValue;

404

Rozdział 9. ■ Niestandardowe komponenty, konwertory i mechanizmy weryfikujące

JavaServer Faces 17. 18 19. 20.

}

21.

}

22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45.

public void setErrorSurnniary(ValueExpression newValue) { errorSummary = newValue:

public void setErrorDetail(ValueExpression newValue) { errorDetail = newValue:

Struktura katalogów naszej aplikacji przykładowej

Listing 9.30. Plik konfiguracyjny custom-validator/web/WEB-INF/faces-config.xml_____________________ 1.

validator.setExpression((String) expression.getValue(elContext)); i f (errorSummary != null) validator.setErrorSummary( (String) errorSummary.getValue(elContext)); i f (errorDetail != null) validator.setErrorDetai1((String) errorDetai1.getValue(elContext)): return validator: } public void releaseO { expression = n u ll: errorSummary = nul1; errorDetail = n u ll; } }

Na rysunku 9.14 przedstawiono strukturę katalogów tej aplikacji.

Rysunek 9.14.

Na listingu 9.30 przedstawiono zawartość pliku faces-config.xml. Warto zwrócić uwagę na odwzorowanie identyfikatora mechanizmu weryfikacji w klasę tego mechanizmu. Klasę znacznika mechanizmu weryfikacji zdefiniowano w pliku TLD (patrz listing 9.31). Na listingu 9.32 przedstawiono kod strony JS F z naszym mechanizmem weryfikacji pola numeru karty kredytowej.

} public Validator createValidatorO throws JspException { RegexValidator validator = new RegexValidator(), ELContext elContext = FacesContext.getCurrentlnstanceO.getELContext():

¡¡2 custom-valldator.war f £3 META-INF 1 Q MANIFEST. MF

f •£S WEB-INF if E3 classes i

j

t " £3 com ^ e£I coreisf

|

if- £3 util | ..Q Messages.class

|

| Q

j

j

j

[

Q

CreditCardValidator. class

|

\

Q

PaymentBean.class

I

j“' D RegexVatidator.class

j - Q CreditCard. class

i

|

|

'■ Q

j

CreditCardConverter. class

Q CredttCardConverterTag. class

Q RegexValidatorTag. class messages, properties

Q converter.ttd

| Q validator.tld \

Q faces-conflg.xml Q web.xml

Q st'^es.css ■Q index.html Q index, jsp Q result.jsp

405

2. 3. 4. 5. 6. 7 8 9 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36 37. 38. 39. 40. 41. 42. 43. 44 45. 46. 47. 48. 49.

/index.jsp process /result.jsp /resul t . jsp back /index.jsp com.corejsf.CreditCard com.corejsf.CreditCardConverter com.corejsf.CreditCard com.corejsf.CreditCardConverter com.corejsf.Credi tCard com.corejsf.CreditCardValidator com.corejsf Regex com.corejsf.RegexValidator payment com.corejsf PaymentBean session

406

Rozdział 9. ■ Niestandardowe komponenty, konwertery i mechanizmy weryfikujące

JavaServer Faces

11. 12 13 14. 15. 16 17. 18 19. 20. 21. 22 24. 25 26. 27. 28. 29. 30. 31 35 36. 37. 38.

50. 51. 52. com.corejsf,messages 53. msgs 54 55. 56.

Listing 9.31. Deskryptor custom-validator/web/WEB-INF/validator.tld 1. 2. 7. l.l 8 validator 9. http://corejsf.com/validator 10. 11. validateRegex 12. com.corejsf.RegexValidatorTag 13. empty 14. 15. expression 16. 17. j ava.1ang.String 18. 19. 20. 21. errorSummary 22. 23. java.1ang.Stri ng 24. 25 26 27 enrorDeiail 28 29 java lang.Strmg 30 31 32 33

Listing 9.32. Kod strony custom-validator/web/index.jsp 1 chtml> <70o tagl ib un ="http7/java.sun.com/jsf/core" prefix="f" %> 2 3 taglib ur~i ="hUp://java.sun.com/jsf/iuml" prefix-"h" °^> 4 <%$ taglib un ="hitp-//corejsf com/vahdator" pref i x-"corejsf" °^> 5 6 7 <11nk href-"styles css" rei ="sLylesheet type=,,text/css'7> < tu lexh-outputText value=’7{msgs.11 11e)"/> 8 9. 10

407

Wiem y już, jak implementować znaczniki niestandardowe dla naszych komponentów, kon­ werterów i mechanizmów weryfikacji. Omówiliśmy wszystkie kluczowe aspekty i problemy, przed którymi staje programista konstruujący własne znaczniki. Kod przedstawiony w tym rozdziale powinien stanowić dobry punkt wyjścia dla Czytelników zainteresowanych własnymi eksperymentami.

UJ

ja vax.faces.webapp.Va1i datorlag

■ void set Va 1idator icKStnng i d) Ustawia identyfikator danego obiektu weryfikującego. Ustawiony identyfikator jest później wykorzystywany do poszukiwania klasy odpowiedzialnej za weryfikację. ■ protected void createValidator() Powinniśmy tę metodę nadpisać, jeśli chcemy uzależnić działanie naszego mechanizmu weryfikacji od wartości właściwości przekazywanych za pośrednictwem atrybutów znacznika.

408

JavaServer Faces

10 Usługi zewnętrzne W tym rozdziale omówimy techniki uzyskiwania dostępu do usług zewnętrznych z pozio­ mu aplikacji JavaServer Faces. Przeanalizujemy sposoby nawiązywania połączeń z bazami danych, usługami katalogowymi i usługami sieciowymi. Skoncentrujemy się przede wszystkim na metodach izolowania logiki aplikacji od konfiguracji zasobów.

Dostęp do bazy danych za pośrednictwem interfejsu JDBC W poniższych punktach dokonamy krótkiego przeglądu interfejsu A P I technologii JD B C (od ang. Java Database Connectivity). Przyjmujemy, że Czytelnik dysponuje podstawową wiedzą o poleceniach języka SQ L (od ang. Structured Query Language). Szczegółowe wprowadzenie w świat interfejsu JD B C i języka SQ L można znaleźć w rozdziale 4. książki Core Java™ 2, vol. 21 autorstwa Caya Horstmanna i Gary’ego Cornelia. Dla ułatwienia nie­ zbędne podstawy omówiono także poniżej.

Wykonywanie wyrażeń języka SQL Aby wykonywać wyrażenia języka SQ L na bazie danych, musimy dysponować obiektem połączenia. Tego rodzaju obiekty można uzyskiwać na wiele różnych sposobów. Najbardziej eleganckim jest użycie źródła danych (ang. data source ): DataSource source = . . Connection conn = source.getConnection();

1 Polskie wydanie: Java 2. Techniki zaawansowane. Wydanie //, Helion, 2005 — przyp. tłum.

410

RozdziaMO. ■ Usługi zewnętrzne

JavaServer Faces W punkcie „Uzyskiwanie dostępu do zasobów zarządzanych przez kontener” omówimy techniki uzyskiwania źródeł danych w ramach kontenerów GlassFish i Tomcat. Na razie przyjmujemy, że źródło danych zostało prawidłowo skonfigurowane i że możemy od razu przystąpić do nawiązywania połączenia z odpowiednią bazą danych. Po utworzeniu obiektu klasy Connection należy skonstruować obiekt klasy Statement, który będzie nam potrzebny do przekazywania wyrażeń języka SQ L do bazy danych. Dla wyrażeń SQL-a aktualizujących bazę danych należy stosować metodę executeUpdate, natomiast zapytania zwracające zbiory wynikowe wymagają stosowania metody executeQuery. Statement stat = conn.createStatementO, s ta t.executeUpdate(" INSERT INTO Users VALUES ( 'troosevelt', ’jabberwock1)"). ResultSet result = stat.executeQuery!"SELECT * FROM Users");

Klasa ResultSet oferuje dość nietypowy protokół przetwarzania iteracyjnego. W pierwszej kolejności wywołujemy metodę next, aby przenieść kursor do pierwszego wiersza. (Metoda next zwraca wartość fal se, jeśli kolejne wiersze są niedostępne). Musimy następnie wywołać metodę getString, aby uzyskać łańcuch reprezentujący wartość interesującego nas pola. Przykład takiego rozwiązania przedstawiono poniżej; while (resu lt.next!)) { username = result.getStringC'username1') ; password = result.getString!"password");

} Po wykonaniu wszystkich operacji na bazie danych koniecznie należy zamknąć połączenie, z którego korzystaliśmy. Aby mieć pewność, że dane połączenie zostanie zamknięte nieza­ leżnie od okoliczności (a więc także w razie wystąpienia wyjątków), powinniśmy umieścić kod operujący na bazie danych w bloku try-fi nal ly: Connection conn = source.getConnection!); try {

} finally { conn.close!);

} Interfejs JD B C A P I jest oczywiście dużo bardziej rozbudowany, jednak początkowo powyższy materiał podstawowy powinien nam w zupełności wystarczyć. R S | W tym rozdziale skoncentrujemy się na technikach wykonywania wyrażeń języka ■ H SQL z poziomu aplikacji internetowej. Prezentowane podejście zdaje egzamin w przypadku lekkich aplikacji cechujących się stosunkowo niewielkimi wymaganiami w zakresie ilości składowanych danych. Bardziej skomplikowane aplikacje mogą wy­ magać zastosowania jakiejś technologii odwzorowywania obiektowo-relacyjnego, np. JPA (od ang. Java Persistence API) lub Hibernate.

411

Zarządzanie połączeniami Jednym z najtrudniejszych wyzwań, z którymi muszą się mierzyć twórcy aplikacji interne­ towych, jest zarządzanie połączeniami z bazami danych. Musimy właściwie zrównoważyć dwa sprzeczne dążenia. Po pierwsze, otwieranie połączeń z bazą danych jest kosztowne czasowo — nawiązanie połączenia, uwierzytelnienie i pozyskanie niezbędnych zasobów zwykle trwa co najmniej kilka sekund. W tej sytuacji nie możemy sobie pozwolić na otwie­ ranie nowego połączenia dla każdego żądania strony. Z drugiej strony, trudno byłoby utrzymywać ogromną liczbę otwartych połączeń z bazą danych. Połączenia zajmują cenne zasoby (zarówno po stronie programu klienckiego, jak i po stronie serwera bazy danych). Systemy zarządzania bazami danych zwykle ograniczają maksymalną liczbę jednocześnie obsługiwanych połączeń. Oznacza to, że nasza aplikacja nie może po prostu otwierać nowego połączenia za każdym razem, gdy jakiś użytkownik loguje się do systemu, i pozostawiać to połączenie otwarte do czasu wylogowania tego użytkownika. Może się przecież okazać, że nasz użytkownik odejdzie od komputera i nigdy się nie wyloguje. Jednym z najbardziej popularnych rozwiązań tego problemu jest utworzenie puli (ang. pool) połączeń z bazą danych. Pula połączeń zawiera wszystkie aktualnie otwarte połączenia z bazą danych. Aplikacje uzyskują niezbędne połączenia właśnie z tej puli. Niepotrzebne połączenia są niezwłocznie zwracane do puli, ale nie są zamykane. Oznacza to, że pula w znacznym stopniu minimalizuje opóźnienia czasowe związane z ustanawianiem połączeń z bazami danych. Implementacja puli połączeń z bazą danych nie jest łatwa i z pewnością nie powinna należeć do zadań programistów aplikacji. Począwszy od wersji 2.0, interfejs JD B C oferuje dość transparentną obsługę puli połączeń. Okazuje się, że obiekt klasy Corinection uzyskany z puli połączeń jest tak zmodyfikowany, aby jego metoda close powodowała zwrócenie obiektu do puli (zamiast zamknięcia połączenia). Samo konstruowanie i utrzymywanie puli, a także udostępnianie aplikacjom źródła danych, którego metoda getConnecti on zwraca obiekty połączeń z tej puli, należy do serwera aplikacji. Każdy serwer aplikacji cechuje się własnym mechanizmem konfigurowania puli połączeń z bazą danych. Szczegółowe rozwiązania w tym zakresie nie są częścią standardu Javy; tego rodzaju wskazówek próżno szukać nawet w specyfikacji interfejsu JD B C . W kolejnym podrozdziale omówimy sposób konfigurowania pul połączeń w ramach serwerów aplikacji GlassFish i Tomcat. Podstawowe reguły konfiguracji są identyczne w przypadku wszystkich serwerów aplikacji, jednak trudno nie zauważyć istotnych różnic w kwestiach szczegółowych. Kluczem do efektywnego utrzymywania puli jest niezwłoczne „zamykanie” wszystkich nie­ potrzebnych obiektów połączeń. W przeciwnym razie pula połączeń błyskawicznie wyczer­ pałaby się, co zmusiłoby nas do otwierania nowych fizycznych połączeń z bazą danych. Problemem prawidłowego zamykania połączeń zajmiemy się w kolejnym punkcie.

Eliminowanie wycieków połączeń Przeanalizujmy teraz prostą sekwencję wyrażeń: DataSource source = ... Connection corin = source.getConnection();

412

Rozdział 10. ■ Usługi zewnętrzne

JavaServer Faces Statement stat = conn.createStatement(); String command = "INSERT INTO Users VALUES ( ' troosevelt', ' jabberwock')"; stat.executeUpdate!command); conn.closeO;

Przedstawiony kod wygląda na zupełnie poprawny — otwieramy połączenie, wykonujemy proste polecenie, po czym niezwłocznie zamykamy niepotrzebne połączenie. Okazuje się jednak, że mamy tutaj do czynienia z fatalnym niedopatrzeniem. Jeśli któraś z wywoływanych metod doprowadzi do wygenerowania jakiegoś wyjątku, metoda close nigdy nie zostanie

//

413

zaleca się stosowanie odrębnych bloków try

try { Connection conn = source.getConnection!); try { Statement stat = conn.createStatementO; String command = "INSERT INTO Users VALUES ('troosevelt', 'jabberwock')"; stat.executeUpdate(command);

}

fin a lly { conn.closeO;

}

wywołana! } W takim przypadku poirytowany użytkownik może wielokrotnie ponawiać żądanie, każdo­ razowo powodując wyciek jednego obiektu połączenia. Aby uniknąć tego rodzaju sytuacji, zawsze należy umieszczać wywołanie metody close wewnątrz bloku fin a lly : DataSource source = ... Connection conn = source.getConnection(), try { Statement stat = conn.createStatementO; String command = "INSERT INTO Users VALUES ( 'troosevelt', 'jabberwock')"; stat.executeUpdate(command);

catch (SQLException) { //

zapisanie komunikatu o błędzie w dzienniku zdarzeń

} Wewnętrzny blok try gwarantuje, że dane połączenie zostanie zamknięte. Zewnętrzny blok try gwarantuje nam, że ewentualny wyjątek zostanie zarejestrowany w dzienniku zdarzeń. Możemy oczywiście opisać naszą metodę dodatkową konstrukcją throws SQLExcep ■ “ '♦tion i przenieść odpowiedzialność za obsługę ewentualnych wyjątków na metodę wywołującą. W wielu przypadkach właśnie takie rozwiązanie jest najlepsze.

}

fin a lly { conn.close!);

Stosowanie gotowych wyrażeń

} Ten prosty mechanizm całkowicie rozwiązuje problem wyciekających połączeń. Prezentowana reguła jest szczególnie efektywna, jeśli konstrukcji try - fin a lly nie łączymy z żadnym kodem obsługującym wyjątki, a zwłaszcza nie podejmujemy prób przechwytywania wyjątku SQLExcepti on w ramach tego samego bloku try: I I to rozwiązanie NIEjest zalecane Connection conn = n u ll; try { conn = source.getConnection(); Statement stat = conn.createStatementO; String command = "INSERT INTO Users VALUES ( 'troosevelt’ , 'jabberwock')"; stat.executeUpdate(command);

}

catch (SQLException) { //

Do najbardziej popularnych technik optymalizacji aplikacji wykorzystujących interfejs JD B C należy stosowanie klasy PreparedStatement. Wykorzystując gotowe (przygotowane wcześniej) wyrażenia, możemy znacznie przyspieszyć operacje na bazie danych w sytuacji, gdy nasz kod wielokrotnie wykonuje ten sam typ zapytania. Warto przy tej okazji przeanalizować przykład haseł użytkowników. Nasza aplikacja najprawdopodobniej będzie musiała wielokrotnie wykonywać zapytanie w postaci: SELECT password FROM Users WHERE username=...

Takie wyrażenie w pierwszym podejściu wymusza na systemie zarządzania bazą danych prekompilację danego zapytania (czyli przeprowadzenie analizy składniowej wyrażenia języka SQ L i wyznaczenie strategii przetwarzania zapytania). Wszystkie uzyskane w ten sposób informacje są składowane w obiekcie gotowego wyrażenia i wykorzystywane za każdym razem, gdy wykonujemy to zapytanie.

zapisanie komunikatu o błędzie w dzienniku zdarzeń

}

finally { conn.closeO; 11 BŁĄD

} W powyższym kodzie można wskazać dwie drobne usterki. Po pierwsze, jeśli wywołanie metody getConnecti on doprowadzi do wygenerowania jakiegoś wyjątku, zmienna conn nadal będzie miała wartość nuli, zatem nie będziemy mogli wywołać metody close. Co więcej, także samo wywołanie metody close może spowodować wygenerowanie wyjątku SQLExcepti on. Moglibyśmy oczywiście umieścić w klauzuli fi nal ly dodatkowy kod, jednak takie podejście wprowadziłoby sporo zamieszania. Warto w tej sytuacji użyć dwóch odrębnych bloków try:

Obiekt gotowego wyrażenia tworzymy za pomocą metody prepareStatement klasy Connecti on. Poszczególnym parametrom należy przypisać znak ?: PreparedStatement stat = conn.prepareStatement! "SELECT password FROM Users WHERE username=?");

Kiedy już będziemy gotowi do wykonania tak przygotowanego wyrażenia, powinniśmy w pierwszej kolejności ustawić wartości parametrów: stat.setStringd, name);

414

JavaServen Faces (Warto pamiętać, że pierwszy parametr jest reprezentowany przez indeks 1). Możemy teraz wykonać to wyrażenie, stosując standardowy mechanizm; ResultSet result = stat.executeQuery().

Na pierwszy rzut oka wydaje się, że gotowe wyrażenia nie mają zbyt dużego wpływu na efektywność pracy aplikacji internetowych. Musimy mieć na uwadze, że połączenie z naszą bazą danych jest zamykane bezpośrednio po realizacji żądania użytkownika. Każde gotowe wyrażenie jest ściśle związane z konkretnym połączeniem, zatem efekty pracy związane z jego przygotowywaniem tracimy z chwilą przerwania fizycznego połączenia z bazą danych. Jeśli jednak fizyczne połączenia z bazą danych są składowane w puli, nasze gotowe wyrażenia najprawdopodobniej będzie można wykorzystywać wielokrotnie (po ponownym uzyskiwaniu dostępnych połączeń). Wiele współczesnych implementacji puli połączeń oferuje mechanizmy składowania przygotowanych wcześniej wyrażeń w pamięci podręcznej.

Rozdział 10. ■ Usługi zewnętrzne

415

Konfigurowanie zasobów baz danych w ramach serwera GlassFish Serwer GlassFish oferuje wygodny interfejs administracyjny na bazie stron W W W , za po­ średnictwem którego możemy bez trudu skonfigurować źródło danych. Wystarczy wpisać w polu U R L przeglądarki internetowej adres http://localhost:4848 i zalogować się jako ad­ ministrator (domyślną nazwą użytkownika jest admin; domyślnym hasłem jest adminadmin). W pierwszej kolejności należy skonfigurować pulę połączeń z bazą danych. W tym celu musi­ my wybrać element Connection Pools z listy zadań po lewej stronie. Powinniśmy przypisać tworzonej puli nazwę, wybrać dla niej typ zasobów (javax.sql .DataSource) oraz określić właściwy typ systemu zarządzania bazą danych (patrz rysunek 10.1).

j f htrpv/fo'

Kiedy wywołujemy metodę prepareStatement, implementacja puli w pierwszej kolejności przeszukuje pamięć podręczną (bufor) wyrażeń, wykorzystując łańcuch zapytania w roli klucza. Jeśli uda się odnaleźć odpowiednie wyrażenie, zostanie ono wykorzystane ponownie. W prze­ ciwnym razie nowe wyrażenie zostanie utworzone i dodane do pamięci podręcznej.

■ M U . iM

s lii

S u n Ja v a ™ S y s te m

Obiektu klasy PreparedStatement nie można utrzymywać i wielokrotnie wykorzyL I Stywać poza zasięgiem pojedynczego żądania. Po zamknięciu połączenia skła­ dowanego w puli wszystkie związane z nim obiekty klasy PreparedStatement są do tej puli zwracane. Oznacza to, że obiektów klasy PreparedStatement w żadnym razie nie można wykorzystywać poza bieżącym żądaniem. Przeciwnie, powinniśmy wielokrotnie wywoływać metodę prepareStatement dla tego samego łańcucha zapytania, licząc na ponowne wykorzystania istniejącego obiektu wyrażenia.

Nawet jeśli nie interesuje nas problem wydajności, powinniśmy zwrócić uwagę na (K U mechanizm gotowych wyrażeń z innego ważnego powodu — ochrony przed atakami polegającymi na wstrzykiwaniu kodu SQL-a,

Konfigurowanie źródła danych W kolejnych punktach tego podrozdziału omówimy sposoby konfigurowania źródeł danych w ramach serwera aplikacji (na przykładzie serwerów GlassFish i Tomcal), a także techniki uzyskiwania dostępu do tych źródeł z poziomu aplikacji internetowej.

H

S p S ^ lll w

; D o m ain ; clomainl '

Common T a s k s ;

Żadna z tych operacji nie wymaga udziału programisty aplikacji. Rola programisty sprowadza się do żądania obiektów klasy PreparedStalement w nadziei, że przynajmniej w niektórych przypadkach implementacji puli uda się odnaleźć obiekty już istniejące.

:

U s e r: admin

A p p lic a t io n S e r v e r A d m in C o n s o le

■

Application Server > Resources >. jQ BC ..;> Connection Pools

-BJ Ja va

'

X if 'T

:

Application Sen/ei New

^ S

Applications Enterprise Applications

1 o f 2)

j

a

vVep Applications

, 1

S

EJB Modules

%\

a

Connectc Modules

S

Lifecycle Modules

f !

[~ c ^

1

O

App Client Modules

■\

" indicates r e a p e d noid G e n e r a l S e tt in g s T Nam e: R e s o u rc e Type-

|7avaTsq* Data Source

D a ta b a s e V en do r; [PostgreSQ L" 3

w J | W ee Sen/ices §§ Custom MBeans v ^

C o n n e c tio n P o o l (S t e p

identity the general settings tor the connection pool

a

j

Resources JD BC

P a n

i

|DBC Resources

ifeUr Cancel

1

p

f fln n * r t ia n P n n U ’ Igf

_CaiiFiowRoo'

w|

Rysunek 10.1. Konfiguracja puli połączeń w ramach serwera aplikacji GlassFish Na kolejnej stronie interfejsu administracyjnego możemy zdefiniować opcje tworzonego połączenia z bazą danych, w tym nazwę użytkownika i hasło (patrz rysunek 10.2). W kolejnym kroku należy skonfigurować nowe źródło danych. Nadajemy mu nazwę jdbc/mydb, po czym wybieramy skonfigurowaną przed chwilą pulę połączeń (patrz rysunek 10.3). I wreszcie musimy umieścić plik sterownika bazy danych (w przypadku bazy PostgreSQL będzie to plik o nazwie podobnej do postgresql-X.X-XXX.jdbc3.jar, np.: postgresql-8.2-507. ^ jdbc3.jar - który w trakcie tłumaczenia tej książki byl najnowszym dostępnym sterowni­ kiem) w podkatalogu domains/domainl/¡ib/exl naszej instalacji serwera GlassFish.

416

JavaServer Faces

Rozdziano. ■ usługi zewnętrzne

Rysunek 10.2. Określanie opcji połączenia z bazą danych

417

Konfigurowanie zasobów baz danych w ramach serwera Tomcat ■ H IS KBKSMI U s e r : adinin

S e r v e r : localhost

D o m ain : dom am i

Sun Java™ System A pplication Server Adm in Console

|

Non T r a n s a c t io n a l C o n n e c tio n s :

Application Server

? ffl Applications O

W pierwszej kolejności musimy odnaleźć plik conf/server.xml i zlokalizować w nim element opisujący kontener (maszynę wirtualną) naszej aplikacji internetowej:

T r a n sa c tio n Iso la tio n

Enterprise Applications

^ m O

T r a n s a c t io n Is o la tio n : F~

W eb Applications



EJB Modules



Is o la tio n L e v e l:

33 Connector Modules ffl Lifecycle Modules m

App Client Modules

P ro p e rtie s

1v H, Weo Services



| f Custom MBeans, v

W tym punkcie przeanalizujemy kolejne kroki procesu konfigurowania puli zasobów bazy danych w ramach kontenera Tomcat 5. Czytelnicy, którzy nie korzystają z serwera Tomcat, mogą ten punkt pominąć.

Additional Properties (7)

Resources |DBC ■w

V a lu e

jDBC R eso u 'ce s H

0

|dDC/_T.merP0ol

jpoa^jmbe'

iabc/_CailP'ow Roo

¡Password

icnx/_detauit

Wewnątrz tego elementu należy umieścić podelement De faul LContext określający zarówno szczegółowe ustawienia bazy danych (sterownik, adres U R L oraz nazwę i hasło użytkownika), jak i docelową specyfikację definiowanej puli.

[prepare Threshold

23 C o n n e c tio n P o o ls

9

_CailF'owPooi

0

_ I,m e r P 00 i

|Sefÿer\ame [Logiprirrieout

91 DeroyPooi 0

usei

PostqresPoo'

[databaseNarne"

|MS Resources 113 javaMa" Sess'ons

£ $

$ iSâ jND>

iffil Connęctors____________I Zakończono

Rysunek 10.3. Konfigurowanie źródła danych

n Seiver Platform Edition 5 0 Admin Consoie - Mo itfa Firefox

I Q r'ttp.//iocai1'io5t;4848/a>aan''in/aami>-'gui/TopFrame5et

Poniżej przedstawiono dość typowy przykład opisujący pulę połączeń z bazą danych PostgreSQL. Wartości, które wymagają od nas dostosowania do potrzeb konkretnej puli, wyróż­ niono pogrubieniem: f ac tory org. apache. commons.clbcp. Bas i cDataSourceFactory priverC1assName org.postgresql.Dri ver url jdbc:postgresql://127.0.0.1:5432/postgres username nazwa_użytkowni ka password hasło_do_bazy maxAct i ve 20 maxlci 1e 10

418

Rozdziano. ■ Usługi zewnętrzne

JavaServer Faces pooiPrepareaSiatemen[s true < /D efauItC ontext>

Kontekst konkretnej aplikacji internetowej możemy też uzupełnić o takie elementy jak Resource czy ResourceParams. Źródło danych będzie wówczas dostępne wyłącz­ nie dla danej aplikacji. Aby skonfigurować pulę, musimy określić wartości pewnej sekwencji parametrów (najbardziej popularne parametry wymieniono i krótko opisano w tabeli 10.1). Kompletną dokumentację wszystkich obsługiwanych parametrów można znaleźć na stronie internetowej http://jaka.rta.

419

Musimy mieć na uwadze, że aplikacja internetowa zawsze powinna zamykać połączenia z bazą danych bezpośrednio po wizualizacji odpowiedzi na żądanie użytkownika. Pula może nie tytko odzyskiwać niewykorzystywane połączenia, ale też rejestrować tego rodzaju zdarzenia w dzienniku. Rejestrowanie podobnych przypadków w dzienniku zdarzeń jest szczególnie przydatne podczas diagnozowania oprogramowania, ponieważ ułatwia programiście aplikacji eliminowanie wycieków połączeń. Plik sterownika bazy danych należy umieścić w katalogu common/Iib serwera Tomcat. Jeśli plik sterownika ma rozszerzenie .zip , musimy to rozszerzenie zmienić na .jar — na przykład dla bazy danych Oracle powinniśmy dysponować plikiem classesl2jar. Szczegółowe omówienie procedur konfiguracji połączeń z wieloma popularnymi systemami zarządzania bazami danych można znaleźć na stronie internetowej

□

http://jakarta.apache.org/tomcat/tomcatS. 5-doc/jndi-datasouree~examples-howto. htmi.

apache.org/commons/dbcp/configuration.html. Tabela 10.1. Najczęściej stosowane parametry puli połączeń łączących serwer Tomcat z bazą danych Nazwa parametru

Opis

dr i veT 1assName

Nazwa sterownika JDBC, np. org postgresgl Dnver.

url

Adres URL bazy danych, np. jdbc.postgresgl -mydb.

username

Nazwa użytkownika bazy danych.

password

Hasło użytkownika bazy danych.

maxActi ve

Maksymalna liczba istniejących jednocześnie aktywnych połączeń (lub zero, jeśli rezygnujemy z ograniczania tej liczby).

max Idle

Maksymalna liczba aktywnych połączeń, które mogą pozostawać niewykorzystane w puli bez podejmowania działań na rzecz zwalniania tych połączeń (lub zero, jeśli rezygnujemy z ograniczania tej liczby).

poolPreparedStatements

Wartość true, jeśli w puli mają być składowane przygotowane wcześniej wyrażenia (domyślnie ma wartość f al se).

removeAbandoned

Wartość true, jeśli z puli powinny być usuwane połączenia, które sprawiają wrażenie porzuconych (domyślnie ma wartość fal se).

removeAbandonedTi meout

Liczba sekund, po których upłynięciu niewykorzystywane połączenie jest traktowane jak połączenie porzucone (domyślnie ma wartość 300).

logAbandoned

Wartość true, jeśli tzw. ślad stosu ma być rejestrowany w dzienniku zdarzeń w razie wykrycia połączenia porzuconego (domyślnie ma wartość fal se).

Aby aktywować mechanizm składowania w puli gotowych (przygotowanych wcześniej) wyrażeń, koniecznie należy przypisać wartość true parametrowi pool PreparedStatements. Ostatnie trzy parametry z tabeli 10.1 są ściśle związane z pewnym bardzo przydatnym elemen­ tem puli serwera Tomcat. Okazuje się, że możemy wymusić na mechanizmie puli monito­ rowanie i eliminowanie połączeń sprawiających wrażenie porzuconych. Jeśli dane połącze­ nie nie jest wykorzystywane od jakiegoś czasu, możemy przyjąć, że aplikacja nie będzie już korzystała z tego połączenia.

Uzyskiwanie dostępu do zasobów zarządzanych przez kontener Specyfikacja technologii Java EE nakłada na nas obowiązek deklarowania zasobów w pliku web.xml naszej aplikacji internetowej. W przypadku źródła danych odpowiedni wpis w pliku web.xml powinien mieć następującą postać: jdbc/iTiydb javax sq1 DataSource Container

Warto zwrócić uwagę na nazwę zasobu: jdbc/mydb. Przytoczona nazwa będzie wykorzysty­ wana w procesie poszukiwania źródła danych. Istnieją dwa sposoby lokalizowania takiego źródła. Bardziej elegancki polega na tzw. wstrzykiwaniu zasobu (ang. resource injection) poprzez zadeklarowanie odpowiedniego pola w komponencie zarządzanym i oznaczenie go stosowną adnotacją: @Resource(name="jdbc/mydb") private DataSource source;

Kiedy serwer aplikacji ładuje nasz komponent zarządzany, pole source jest inicjalizowane automatycznie. Opisywane rozwiązanie jest obsługiwane tylko przez serwery aplikacji zgodne ze standardem Java E E 5. Jeśli pracujemy w technologii JS F 1.1 lub korzystamy z autonomicznego serwera Tomcat, musimy poświęcić temu rozwiązaniu nieco więcej czasu i samodzielnie posłużyć się mechanizmem przeszukiwania interfejsu JN D I (od ang. Java Naming and Directory Interface): try { InitialContext ctx = new InitialContextO, source = (DataSource) ctx.lookup("java:conp/env/jdbc/mydb");

} catch (NamingException ex) {

}

420

JavaServer Faces

Rozdziano. ■ Usługi zewnętrzne

Przedrostek java:comp/env jest standardową ścieżką interfejsu JND1 do przeszukiwanego katalogu środowiska komponentów kontenera technologii Java EE. Zgodnie z przyjętą kon­ wencją zasoby JD B C należy umieścić w podkatalogu jdbc. Dobór samych nazw poszcze­ gólnych zasobów należy do programisty.

Rysunek 10.4. Strona logowania

^ Ł & j ł S' Plik

Edycja

Widok

Historia

’" ' ' I ! ?

Zakładki

[

Narzędzia

Pomoc

A j

http^localhostiSOSO/db/indev.faces ; * [ ► ) ijO U j

[% ]

-

Prosim y w p isać nazw ę i hasło użytkow nika.

JW 0 Serwer GlassFish odróżnia nazwy referencji do zasobów od nazw interfejsu JNDI. I hM Oznacza to, że dla większości zasobów musimy określać odpowiednie odwzoro­ wania w pliku $un~web.xml (przykład takiego rozwiązania można znaleźć w punkcie „Konfigurowanie kontekstu zewnętrznego” w dalszej części tego rozdziału). Podobne odwzorowania nie są konieczne w przypadku zasobów JDBC. W przypadku tak prostej operacji przeszukiwania możliwość stosowania adnotacji @Resource trudno oczywiście uznać za istotne ułatwienie. Okazuje się jednak, że inicjalizacja pozo­ stałych zasobów jest procesem dużo bardziej skomplikowanym. Ciekawy przykład wstrzy­ kiwania zasobu można znaleźć w podrozdziale „Stosowanie usług sieciowych" w dalszej części tego rozdziału. Zajmiemy się tam problemem wstrzykiwania portu usługi sieciowej za pomocą prostej adnotacji. Gdyby nie technika wstrzykiwania zasobów, musielibyśmy korzystać z bardzo skomplikowanych klas pomocniczych.

421

Nazwa iTroosevei>

ZaJogui i

Rysunek 10.5. Strona powitalna

; p łk

|dycja

#

* #

łfttdok

Historia

- #

Zakładki L

Narzędzia

X X “ .A

"fe so yss'

Pomoc

http.'docalhost:8080/db/mdex.faces j *

O

] jf | ll

| ^ ^ G o o q lt

Witamv w swiecie JavaSerw u Fares tr^ose^elr1

Wyłogi |

Dla spójności będziemy stosowali mechanizm adnotacji do inicjalizacji wszystkich zasobów. W tabeli 10.2 wymieniono i krótko opisano wszystkie adnotacje, za pośrednictwem których możemy wstrzykiwać zasoby:

Tabela 10.2. Adnotacje umożliwiające wstrzykiwanie zasobów Adnotacja

Typ zasobu

^Resource (^Resources

Dowolny zasób JNDI.

PWebServiceRef OWebServiceRefs

Port usługi sieciowej.

@EJB @EJBs

Komponent sesyjny EJB.

OPersistenceContext OPersi stenceContexts

Menedżer trwałych encji.

OPersistenceUnit @PersistenceUnits

Fabryka menedżera trwałych encji.

Rysunek 10.6. Strona błędu uwierzytelniania

Aplikacja bazy danych MoziHa firefox Plik

Edycja "

ty

Widok ” 0

Historia ¿|J

Zakładki

Narzędzia

Pomoc

I - 'Ą |ttp://localhost;8080/db/index.faces

~ T jg ) 1

B łąd u w ierzyteln ian ia Przykro nam, me udało się odnaleźć podanej kombinacji nazwy i hasła użytkownika. Spróbuj ponownie!

(Twntynuufj

Kompletny przykład użycia bazy danych W tym punkcie przeanalizujemy przykład weryfikacji kombinacji nazwy i hasła użytkow­ nika. Podobnie jak w przypadku przykładowej aplikacji z rozdziału 1. w pierwszej kolejno­ ści skoncentrujemy się na oknie logowania (patrz rysunek 10.4). Jeśli podana kombinacja nazwy i hasła użytkownika jest prawidłowa, nasza aplikacja wyświetla stronę powitalną (patrz rysunek 10.5). W przeciwnym razie prosimy użytkownika o ponowne wpisanie danych (patrz rysunek 10.6). I wreszcie, jeśli wystąpi błąd bazy danych, nasza aplikacja wyświetli okno ze stosownym komunikatem (patrz rysunek 10.7).

Nasza przykładowa aplikacja składa się więc z czterech stron JS F (przedstawionych na listin­ gach od 10.1 do 10.4 w dalszej części tego punktu), pliku konfiguracyjnego faces-config.xml (przedstawionego na listingu 10.5) z regułami nawigacyjnymi wykorzystującymi właściwości loginAction i logoutAction klasy UserBean oraz samej klasy komponentu UserBean (przedsta­ wionej na listingu 10.6).

422

JavaServer Faces

Rozdziano. ■ Usługi zewnętrzne • ft Aplikaga bazy danych - Moz.Ha Firef

Rysunek 10.7.

Pltk

Strona błędu wewnętrznego

Edycja

Widok

fi ’ *' ' ©

Historia Zakładki

fi

Narzędzia

Pomoc

http://localhost:8080/db/index.face5

7S ) ‘B2±

JS

Przed uruchomieniem tej przykładowej aplikacji musimy uruchomić naszą bazę danych, utworzyć tabelę nazwaną Users i dodać do niej jeden lub wiele rekordów reprezentujących nazwy i hasła użytkowników:

Błąd wewnętrzny

CREATE TABLE Users (username CHAR(20), password CHAR(20)) INSERT INTO Users VALUES ( ’troosevelt1, ' jabberwock’ )

Wystąpił błąd wewnętrzny Prosimy zgłosić usterkę naszym konsultantom technicznym | Kontynuuj j

423

Możemy teraz przystąpić do wdrażania i testowania naszej aplikacji. Na rysunku 10.8 przedstawiono strukturę katalogów tej aplikacji, natomiast na rysunku 10.9 przedstawiono schemat nawigacji pomiędzy poszczególnymi stronami JSF. Wspomniane już pliki naszej przykładowej aplikacji przedstawiono na listingach od 10.1 do 10.6.

Rysunek 10.8. W naszym prostym przykładzie kod odpowiedzialny za komunikację z bazą danych umiesz­ czamy bezpośrednio w klasie UserBean. Moglibyśmy oczywiście podzielić obiekty tej aplikacji pomiędzy dwie warstwy: komponentów odpowiedzialnych za komunikację ze stronami JS F oraz obiektów odpowiedzialnych za uzyskiwanie dostępu do danych i reprezentujących encje składowane w bazie danych.

3 cfb.war f 3 M ETA -IN F

Struktura katalogów naszej przykładowej aplikacji

j

j f •3 classes | j f- 3 corn is f 3 corejsf is I Q UserBean. class | I i

Kod uzyskujący dostęp do bazy danych zdecydowaliśmy się umieścić w odrębnej metodzie: public void doLoginO throws SQLException

Metoda doLogin wykonuje na bazie danych zapytanie umożliwiające weryfikację otrzyma­ nej kombinacji nazwy i hasła użytkownika, po czym ustawia wartość true w polu 1oggedln, jeśli istnieje dopasowanie dla tej kombinacji. Przycisk na stronie index jsp odwołuje się do metody login komponentu UserBean. Metoda 1ogi n wywołuje metodę doLogi n i zwraca łańcuch wynikowy niezbędny do wskazania kolejnej strony przez mechanizm odpowiedzialny za nawigację. Metoda 1ogi n dodatkowo obsługuje wyjątki generowane przez metodę doLogin. Przyjmujemy, że metoda doLogin odpowiada wyłącznie za komunikację z bazą danych i jako taka nie jest związana z interfejsem użytkownika. W razie wystąpienia wyjątku metoda doLogi n nie powinna podejmować dalszych działań. Z drugiej strony, metoda login powinna każdo­ razowo rejestrować wyjątek i zwracać łańcuch wynikowy " intenna 1Error" mechanizmowi odpowiedzialnemu za nawigację: pub 1iC String login() { try I dOLog1n(). I caich

(SQ LExcep tio n

ex)

I ( lo g g e d ln )

return "1oginSuccess". else retu rn

i ' • Q messages.properties ;• O faces-config.xml ! Q web.xml Q index.html

!- D error.jsp f - D index.jsp I- Q sorry jsp

D welcome, jsp

Rysunek 10.9. Mapa nawigacji pomiędzy stronami aplikacji

I

'B B 'W konfiguracjach obejmujących bazy danych istnieje szereg czynników, które mogą ™ prowadzić do rozmaitych usterek. W razie wystąpienia błędu wewnętrznego apli­ kacji jego przyczyn należy szukać w pliku dziennika. Domyślnym plikiem dziennika serwera GJassFish jest plik domains/domainl/logs/server.log; domyślnym plikiem dziennika serwera Tomcat jest plik logs/catalina.out

{

logger logdevel SEVERE. " logmAct ion". ex), return " irterna1Error". if

Q MANIFEST.MF

f (3 WEB-INF

" lo g in E a ilu re ",

Listing 10.1. Kod strony db/web/index.jsp_____________ 1 2 3

cag11b uri =”nttp.//java Sun com/jsf/core" prefix="f" %> taglib u n = "h ttD . //Java Sun com/jsf/n tm i " p re fix - "h " %>

4



5



67.

< t it le > < h : o u t p u t T e x t

v a lu e = " # {m s g s .t it le }" / > < / t it le >

424

Rozdziano. ■ Usługi zewnętrzne

JavaServer Faces 8

9.

10. 11 12 13 . 14. 15 16. 17. 18 19. 20. 21 22.









Listing 10.2. Kod strony db/web/welcome.jsp 1. 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" °X> 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. 5. 6. 7. 8. 9. 10.

11. 12. ! 13.

14

15. 16.

17. 18. 19. 20.

Listing 10.3. Kod strony db/web/sorry.jsp______________________________________________ 1. 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" £> 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. 5. 6. 7. 8. 9. 10. 11.

12. ! 13.

14.

15.

16.

17 18 19 20

Listing 10.4. Kod strony db/web/error.jsp 1 2. <&@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3 taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4 5. 6 7 8. 9. 10 11

12

13. 14.

15 16. 17 18.

Listing 10.5. Plik konfiguracyjny db/web/WEB-ÍNF/faces-config.xml 1 2
DN. oc=core|sf dc=com Klasa obiektów : dcObject. organization

Katalogi LDAP

A tryb uty: dc=corejsf Przykładowa organizacja

Technologia LD A P wykorzystuje hierarchiczną bazę danych. Utrzymuje wszystkie dane w strukturze drzewiastej, nie w zbiorze tabel (jak to się dzieje w relacyjnych bazach danych). Każdy element tego drzewa obejmuje: ■ Zero, jeden lub wiele atrybutów. Atrybut ma postać pary klucz-waitość. Przykładem takiego atrybutu jest para cn-Jan Wojciech Nowak. Klucz cn reprezentuje imię i nazwisko (listę najbardziej popularnych atrybutów technologii LD A P przedstawiono w tabeli 10.3).

Tabela 10.3. Najczęściej stosowane atrybuty technologii LDAP Nazwa atrybutu

Znaczenie

dc

Składowa reprezentująca dziedzinę

Cn

Imię i nazwisko

Sn

Nazwisko

dn

Nazwa unikatowa

0

Organizacja

Ou

Jednostka organizacyjna

ui d

Unikatowy identyfikator ■ Jedną lub wiele klas obiektów. Klasa obiektów definiuje zbiór wymaganych i opcjonalnych atrybutów danego elementu. Na przykład klasa obiektów person definiuje wymagany atrybut cn oraz atrybut opcjonalny telephoneNumber. Klasy obiektów nie są oczywiście tożsame z klasami Javy, ale o ferują możliwość dziedziczenia. Na przykład klasa i netOrgPerson jest podklasąklasy person i dodaje do niej pewne atrybuty.

DN. ou=people. dc-corejst dc=com

DN. ou=groups. de=corejsf, dc=com

Klasa obiektów : organizational Unit

Klasa obiektów : organizationalUnit

A trybuty: ou=peopie

A tryb uty: ou=groups

Z DN: uid=troosevelt. ou=peopie, dc=corejsf. dc=com Klasa obiektów : •netOrgPerson A trybuty: uid=trooseveit sn=Rooseveii cn-Theodore Roosevelt maiMroosevelt@c.. userPassword-jabber

Z

j DN uid=tjefferson. f ©unpeople. dc-corejsf. dc=com Klasa obiektów : inetOrgPerson Atrybuty: uid=tjefferson sn-Jefferson cn=Thomas Jefferson maiMjefferson@c. userPassword=mocktu

\

DN. cn=registereduser, ou^people, dc=corejsf. dc=com

--- -----------DN: cn=invitedguest, ou=peopie, dc-corejsf. dc=com

Klasa obiektów : groupOfUmqueNames

Klasa obiektów : groupOfUmqueNames

A trybuty: cn=registereduser uniqueMember=uid=t|...

A tryb uty: cn=invitedguest uniqueMember-uid=t) . umqueMember=uid=ti.

Sposoby organizowania drzewa katalogów i dobór informacji składowanych w ramach tej struktury są przedmiotem wielu sporów. W tej książce w ogóle nie będziemy się zajmowali tym problemem. Przyjmujemy, że schemat organizacyjny został nam narzucony i że katalog wypełniono odpowiednimi danymi użytkowników.

430

Rozdział 10. ■ Usługi zewnętrzne

JavaServer Faces

Konfigurowanie serwera LDAP Serwer LD A P (niezbędny do przetestowania programów prezentowanych w tym podrozdziale) można uruchomić na wiele sposobów. K ilka najbardziej popularnych rozwiązań opisano poniżej: ■ darmowy serwer OpenLDAP (patrz witryna internetowa http://openldap.org) dostępny dla systemów operacyjnych Linux i Windows (wersja dla systemu Mac OS X jest w fazie budowy); ■ serwer oferujący najwyższą wydajność, np. dostępny dla wielu różnych platform produkt Sun Java System Directory Server (patrz strona internetowa http://www.sun. com/software/products/directory_srvr/home_directory. html) ; ■ technologia Microsoft Active Directory. W tym punkcie skoncentrujemy się na procedurze konfiguracji serwera OpenLDAP. W przy­ padku innych serwerów usług katalogowych podstawowe kroki tej procedury są identyczne. Nasz przykładowy katalog wykorzystuje standardową klasę obiektów nazwaną i netOrg Pers on. (Zdecydowaliśmy się użyć tej klasy, ponieważ obejmuje przydatne atrybuty, takie jak uid czy mail). Oznacza to, że musimy się upewnić co do prawidłowego rozpoznawania tej klasy obiektów przez nasz serwer LD A P. Jeśli korzystamy z serwera OpenLDAP, musimy przed uruchomieniem tego serwera zmody­ fikować zawartość pliku konfiguracyjnego slapd.conf. Należy odnaleźć wiersz odwołujący się do pliku core.schema i dodać wiersze dołączające pliki cosine.schema oraz inetorgperson.schema. (W wersji dla systemu operacyjnego Linux plik slapd.conf domyślnie znajduje się w katalogu /etc/ldap, Ietc/openldap lub /usr/local/etc/openldap. Pliki schematów są składo­ wane w podkatalogu schema). R ||| Alternatywnym rozwiązaniem jest odpowiednie dostosowanie naszych danych przykładowych. Można na przykład zastąpić klasę obiektów inetOrgPerson częściej stosowaną klasą person oraz zrezygnować z atrybutów uid i mail na rzecz atrybutu sn (który będzie odpowiadał nazwie użytkownika). Warto jednak pamiętać, że taka zmiana będzie się wiązała z koniecznością przebudowy programów przykładowych.

fill

Mimo że ustawienia uwierzytelniania nie są niezbędne do testowania przykładów prezento­ wanych w tym podrozdziale, zaleca się ich zdefiniowanie. Poniżej przedstawiono ustawienia zapisane w pliku slapd.conf które umożliwiają użytkownikowi Manager odczytywanie i zapi­ sywanie haseł, a pozostałym użytkownikom umożliwiają odczytywanie wszystkich innych atrybutów. access to attr=userPassword by dn.base="cn=Manager.dc=corejsf,dc=com" write by self write by * none access to * by dn.base="cn=Manager,dc=corejsf,dc=com" write by self write by * read

Możemy wreszcie uruchomić serwer LD AP. Użytkownicy systemu Linux powinni uruchomić usługę slapd (odpowiedni plik wykonywalny zwykle znajduje się w katalogu /usr/sbin lub

/usr/local/libexec). W kolejnym kroku należy umieścić na tym serwerze przykładowe dane. Większość serwe­ rów LD A P oferuje możliwość importowania danych w formacie L D IF (od ang. Lightweight Directory Interchange Format). L D IF jest formatem (czytelnym także dla ludzi), w którym poszczególne wpisy, łącznie z nazwami unikatowymi, klasami obiektów i atrybutami, są reprezentowane na liście. Na listingu 10.7 (w dalszej części tego punktu) przedstawiono plik L D IF opisujący nasze przykładowe dane: . Idap/misc/sample Id if

Użytkownicy serwera OpenLDAP mogą użyć narzędzia Idapadd do dodania tych danych do katalogu: Idapadd -f sample Id if -x -D "cn=Manager,dc=corejsf,dc=com" -w secret

Zanim przystąpimy do dalszych rozważań, warto poświęcić chwilę na powtórną weryfikację katalogu zawierającego nasze dane. Zalecamy wykorzystanie jednej z istniejących przeglądarek LD A P, np. JXPlorer ( http://soureeforge.net/projeets/jxplorer/) lub LD A P Browser/Editor autorstwa Jarka Gawora ( http://www.mcs.anl.gov/~-gawor/ldap/). Oba wymienione narzędzia mają postać wygodnych programów Javy, za pośrednictwem których możemy przeglądać zawartość udostępnianą przez dowolne serwery LD AP. Po uruchomieniu aplikacji JXPIorer należy w pierwszej kolejności skonfigurować następujące opcje:

Serwer OpenLDAP wymaga dostosowania wpisu suffix w pliku slapd.conf do naszego przy­ kładowego zbioru danych. Wspomniany wpis określa przyrostek unikatowych nazw stoso­ wanych w ramach danego serwera. W tym przypadku wpis suffix powinien mieć następującą

■ Host : 1oca 1hos t

postać:

■ Base DN: dc=corejsf .dc-coni

suffix

"dc-ccmejsf.dc=com"

Musimy też skonfigurować użytkownika serwera LD A P, który będzie dysponował prawa­ mi administratora umożliwiającymi edycję danych katalogowych. W przypadku serwera OpenLDAP dodanie takiego użytkownika wymaga uzupełnienia pliku slapd.conf o nastę­ pujące wiersze: rootdn "cn=Manager,dc=corejsf,dc=com" rootpw secret

431

■ Port: 389

■ User DN: cn=Manager,dc=corejsf .dc=com ■ Password: secret Musimy się upewnić, że uruchomiono serwer LD AP, po czym nawiązać połączenie z tym serwerem. Jeśli wszystko będzie w porządku, przeglądarka JX Plo rer powinna wyświetlić drzewo katalogów podobne do tego z rysunku 10.11. Na listingu 10.7 przedstawiono zawartość wspominanego już pliku sample.ldif.

432

JavaServer Faces

Rysunek 10.11. Przeglądanie drzewa katalogów LDAP

Rozdziano. ■ Usługi zewnętrzne 31

1st

li Wm

JXplorer

Fite’Ecst View Bookmark Sftarchi iO If Options Toots Security Heip

\i £ &

^ m m \ > \ rnm\s\ __ w g H T M L W evC j Q

R esu lts

r a b fe Ed itoV

¡©World • com Ÿ m corejst 9 Â

g roup s

| u m qu eMe m b e^t lu m q u e M e m b e r

gr Qu p O fU m q u e Nam es u id = tto o s e v e lt,ou= p e o p le.dc= corejs1,,dc= com u id = tje ffe rs on ,ou = p e o p le,dc= corejsf,dt= co m

I b u sin essC ate gory

1

Definicja wpisu najwyższego poziomu

If

#

34

dn

35 36 37

o b je ctC la ss

38 39

u Definicja wpisu zawierającego grupy LDAP

Wpis grup jest wykorzystywany przez operacje poszukiwania ról

ou

ou=groups.dc=corejsf.dc-com orgam zat lo n a lu m t

groups

# Definicja

wpisu dla roli "registereduser"

dn cn=registereduser.ou-groups.dc=corejsf.dc=com objectClass groupOfUmqueNames cn registereduser

42 umqueMember 43

C h an g e C la ss

Listing 10.7. Plik danych Idap/setup/sample.ldif

32 33

40 41

3 re q iste red u se r 9 J k Pe ople % tje fte rs o n o» tro o s e v e lt

C on n ecte d To 'ld ap :/ / lo c alh o s t:3 8 9 '

433

u id = tje f ferson.ou=people, d c= corejsf .dolcom

44 45

łf Definicja wpisu dla roli "invitedguest" dn cn= invitedguest.ou= groups.dc=corejsf.dc=com

46 47

o b je ctC la ss groupOfUmqueNames cn in vited g u est

48 49

umqueMember umqueMemper

u id = tro o se ve L ,ou=people.dc= corejsf .dc-com uid= tjefferson,ou= people.dc= corejsf.dc= com

Pro p e rties

Uzyskiwanie dostępu do informacji składowanych w katalogach LDAP Skoro dysponujemy już wypełnioną bazą danych LD A P, możemy przystąpić do jej łączenia z programem Javy. Wykorzystamy do tego celu technologię JN D I, czyli interfejs unifikujący rozmaite protokoły katalogowe.

2 dn dc=corejsf.dc^com 3

o b je c tC la s s

dcObject

3

O b je c tC ld ss

o ng d m zd 1 1 on

5

dc

conejsf

W pierwszej kolejności musimy uzyskać kontekst katalogu LD A P, stosując następującą sekwencję wyrażeń:

6 o Ongdmzdcjd x

H asntabie env - new H a s m a b le O .

7

env put(Context SECURJ1V_PR[NC[PAL. userDNL env.put(Context.SECuRiiY_CREDENTlALS, password), DirContext in itia l = new In itial DirContext(env); DirContext context = (DirContext) in it ia l.1ookup("1 dap://I ocal host:389"),

8

łf

9. 10. 11. 12. 13. 14. 15. 16. 17 18. 19. 20. 21. 22. 23 . 24. 25 26. 27. 28. 29. 30.

#

Definicja wpisu zawierającego dane osobowe Właśnie na tym wpisie bazują operacje przeszukiwania

dn: ou=people,dc=corejsf,dc=com objectClass: organizationalUnit ou. people # Definicja wpisu reprezentującego prezydenta Roosevelta dn uid=troosevelt,ou=people,dc=corejsf,dc=com objectClass: inetOrgPerson uid. troosevelt sn: Roosevelt cn: Theodore Roosevelt mail: trooseveltCcorejsf.com userPassword: jabberwock # Definicja wpisu reprezentującego prezydenta Jeffersona dn: uid=tjefferson,ou=people,dc=corejsf,dc=com objectClass- inetOrgPerson uid- tjefferson sn: Jefferson cn: Thomas Jefferson mail: tjeffersonOcorejsf.com userPassword: mockturtle

W tym przypadku nawiązujemy połączenie z serwerem LD A P pracującym na komputerze lokalnym. 389 jest domyślnym numerem portu LD A P. Jeśli spróbujemy nawiązać połączenie z bazą danych LD A P, podając nieprawidłową kom­ binację nazwy i hasła użytkownika, zostanie wygenerowany wyjątek Authenti cati onExcepti on. Aby uzyskać listę atrybutów danego wpisu, należy wywołać metodę getAttributes i prze­ kazać na jej wejściu unikatową nazwę interesującego nas wpisu: Attributes answer = context.getAttri butes( " uid=troosevelt,ou=people,dc=corejsf,dc=com");

Wartość określonego atrybutu możemy uzyskać za pośrednictwem metody get — przykład takiego rozwiązania przedstawiono poniżej: Attribute commonNanieAttribute = answer .get( "cn"):

434

JavaServer Faces

Rozdziano. ■ Usługi zewnętrzne

| P o d r ę c z n ik u ż y t k o w n ik a

in te r f e js u

J N D I ( w y d a n y p rz e z fir m ę

S u n ) s u g e r u je

a lte r ­

n a t y w n y s p o s ó b n a w ią z y w a n ia p o łą c z e n ia z s e r w e r e m :

Hashtable env * new HashtableC): env.put(Context.I NI TIAL_C0NTEXT_FACTORY, "com.sun.jn d i.1dap.LdapCtxFactory” env.put(Context.PROVIDERJJR L . "1dap://1 ocaI host:389"); env.put(Context.SECURITY^PRINCIPAL. userON); env.put(Context.SECURITY_CREDENTIALS, password); DirContext context = new InitialDirContext(env);

435

W kolejnym kroku powinniśmy wywołać metodę createSubcontext. Na jej wejściu należy przekazać unikatową nazwę nowego wpisu oraz przygotowany wcześniej zbiór atrybutów: context

c r e a t e S u b c o n t e x t ( " u i d - a 1i n c o i n . o u - p e o p l e . d c ^ c o r e j s f

dc=com"

a ttrs).

H S | G d y d o d a je m y n o w e w p is y k a t a lo g o w e , m u s im y p a m ię t a ć , ż e ic h a t r y b u t y s ą w e ry -

L A

fik o w a n e p o d k ą te m

z g o d n o ś c i z e z d e f in io w a n y m

w c z e ś n ie j s c h e m a te m . Z je d n e j

s t r o n y , n ie n a le ż y u m ie s z c z a ć w n o w y c h w p is a c h n ie z n a n y c h a t r y b u t ó w ; z d r u g ie j s t r o n y , m u s im y m ie ć p e w n o ś ć , ż e z d e f in io w a n o w s z y s t k ie a t r y b u t y w y m a g a n e p r z e z d a n ą k la s ę

W y d a je s i ę j e d n a k , ż e s z t y w n e w i ą z a n ie n a s z e g o k o d u z f a b r y k ą k o n t e k s t u s tw a fir m y

Sun

n ie

d o w a n y m e c h a n iz m

z n a jd u je

u z a s a d n ie n ia . P o n ie w a ż t e c h n o lo g ia

k o n fig u r o w a n ia d o s ta w c ó w

L D A P a u to r­

J N D I o fe r u je

ro z b u ­

o b ie k t ó w . J e ś li n a p r z y k ła d p o m in ie m y a t r y b u t

createSubcontext

sn k l a s y person,

p ró b a w y k o n a n ia m e to d y

z a k o ń c z y s ię n ie p o w o d z e n ie m .

k o n t e k s t u , r e z y g n a c ja z je g o m o ż liw o ś c i

b y ła b y b łę d e m .

Aby usunąć istniejący wpis, należy wywołać metodę destroySubcontext: Aby uzyskać możliwość iteracyjnego przeszukiwania wszystkich atrybutów, należy użyć klasy NamingEnumeration. Jej projektanci doszli do wniosku, że standardowy protokół iteracji w Javie jest na tyle niedoskonały, że wymaga poprawy — zaproponowali nam następujący schemat przeszukiwania iteracyjnego: NamingEnumeration attrEnum = answer.getAl1(), while (attrEnum.hasMore()) { Attribute attr = (Attribute) attrEnum.next(); String id = attr getID(); }

context.destroySubcontext( "ui d=ali ncoln,ou=peopl e,dc=corejsf,dc=com"),

I wreszcie możemy stanąć przed koniecznością edycji atrybutów istniejącego wpisu. Można to zrobić za pośrednictwem metody modi fyAttri butes: context.modifyAttributes(distinguishedName. flag, attrs),

Za pośrednictwem argumentu f l ag należy przekazać jedną z następujących wartości: DirContext.ADD_ATTRIBUTE Di rContext.REMOVE_ATTRIBUTE Di rContext.REPLACE_ATTRIBUTE

Warto zwrócić uwagę na metodę hasMore stosowaną zamiast popularnej metody hasNext. Ponieważ pojedynczemu atrybutowi można przypisać wiele wartości, prezentacja wszystkich tych wartości wymaga użycia jeszcze jednego obiektu klasy Nami ngEnumerati on: NamingEnumeration valueEnum = attr.getAl1(). while (valueEnum.hasMoreO) { Object value = valueEnum.nextO. }

Jeśli jednak jesteśmy pewni, że interesujący nas atrybut reprezentuje pojedynczą wartość, możemy tę wartość od razu uzyskać, wywołując metodę get: String commonName = (String) commonNameAttribute.getO.

Skoro wiemy już, jak kierować do katalogu zapytania dotyczące danych użytkowników, możemy przystąpić do analizy operacji modyfikujących zawartość tego katalogu. Aby dodać nowy wpis, należy w pierwszej kolejności skonstruować obiekt klasy Basi cAttri butes reprezentujący zbiór atrybutów. (Klasa Basi cAttri butes implementuje interfejs Attri butes). Attributes attrs = new BasicAttributes(); attrs.putCobjectClass", "inetOrgPerson"), attrs.putCuid", "alincoln"); attrs.put( "sn", "Lincoln"), attrs.putCcn", "Abraham Lincoln"); attrs.put("mail", "[email protected]" ); String pw = "redqueen", attrs.putCuserPassword", pw.getBytesO),

Parametr attrs reprezentuje zbiór atrybutów, które mają zostać dodane, usunięte lub zastąpione w ramach edytowanego wpisu. Okazuje się, że konstruktor BasicAttributes(String, Object) automatycznie konstruuje zbiór atrybutów obejmujący pojedynczy atrybut. Odpowiedni przykład przedstawiono poniżej: context.modi fyAttri butes( "ui d=ali ncoln,ou=people,dc=corejsf,dc=com", DirContext.ADD_ATTRIBUTE, new BasicAttributes( "te lephonenumber", "+18005551212")); context.modi fyAttri butes( "ui d=al i ncol n,ou=people,dc=corejsf,dc=com", Di rContext.REMOVEJY1TRIBUTE, new BasicAttributes("mail", "[email protected]")), context.modi fyAttri butes( "ui d=ali ncoln,ou=people,dc=corejsf,dc=com", Di rContext.REPLACE_ATTRI BUTE, new BasicAttributesCuserPassword", newpw.getBytes()));

Kiedy już zakończymy operowanie na obiekcie kontekstu, powinniśmy ten kontekst zamknąć: context.cl ose();

Przedstawiony materiał powinien nam w zupełności wystarczyć do wykonywania na kata­ logach operacji niezbędnych do realizacji zadań właściwych dla systemów zbudowanych na bazie technologii LD A P. Bardziej szczegółowych informacji należy szukać w internetowym

436

JavaServer Faces

Rozdziano. ■ Usługi zewnętrzne

podręczniku poświęconym interfejsowi JN D I (pod adresem http://java.sun.com/products/

■ void modifyAttributes(String name, int flag. Attributes modes)

jndi/tutorial). Z drugiej strony, nie jesteśmy jeszcze gotowi do praktycznego wykorzystania tej wiedzy w ramach kompletnej aplikacji JavaServer Faces odwołującej się do usług LD A P. Trwałe kodowanie takich danych jak adres U R L katalogu czy hasło w naszym programie byłoby przejawem braku profesjonalizmu. Wymienione wartości należałoby raczej definiować w pliku konfiguracyjnym. W kolejnym podrozdziale omówimy rozmaite rozwiązania w zakresie zarządzania parame­ trami konfiguracyjnymi. Przeanalizujemy alternatywne sposoby konstruowania aplikacji umożliwiających swoim użytkownikom samodzielną rejestrację na witrynie internetowej (do składowania danych o tych użytkownikach wykorzystamy technologię LD A P).

Modyfikuje atrybuty wpisu oznaczonego daną nazwą. Za pośrednictwem argumentu fl ag należy przekazać jedną z następujących wartości: DirContext.ADD_ATTRIBUTE, DirContext.REMOVE_ATTRIBUTE lub

Di rContext.REPLACE_ATTRIBUTE.

GEDjavax.nam ing.directory.Attributes (Java SE 1 .3 ) ■ Attribute get(String id) Zwraca atrybut właściwy dla danego identyfikatora.

■ NamingEnumeration getAllO Zwraca obieki wyliczeniowy umożliwiający iteracyjne przeglądanie wszystkich atrybutów w ramach danego zbioru atrybutów.

OBJ javax.nam ing.directory.InitialDirContext (Java SE 1.3) ■

■

In i1 1 a 1DirContext( Hashtab 1e env)

Konstruuje kontekst katalogu, wykorzystując przekazane na wejściu ustawienia środowiskowe. Przekazywana tablica mieszająca może obejmować dowiązania dla Context.SECUR1TY_PRfhClPAL, Context.SECUR1TY_CREDENT 1ALS i innych kluczy (więcej informacji można znaleźć w dokumentacji API dla interfejsu javax. naming. Context).

03J

void put(Strin g id . Object value)

Dodaje atrybut do danego zbioru atrybutów.

javax.nami ng.di rectory .Basi cAttri butes (Java SE 1.3) ■

Bas icAt t rib u tes( St ring id. Object value)

Konstruuje zbiór atrybutów obejmujący pojedynczy atrybut z danym identyfikatorem i wartością.

java x .naming .C ontext (Java SE 1. 3 )

■ Object 1ookuptString name)

U] javax.nam ing.directory.Attribute (Java SE 1 . 3 )

Odnajduje obiekt oznaczony określoną nazwą. Wartość zwracana przez tę metodę zależy od charakteru danego kontekstu (często ma postać kontekstu poddrzewa lub obiektu liścia).

■ Context createSubcontext(String name) Tworzy podkontekst dla danej nazwy. Taki podkontekst automatycznie staje się potomkiem danego kontekstu. Łańcuch przekazywany na wejściu tej metody musi obejmować wszystkie składniki ścieżki poza ostatnim.

■

String get ID ()

Zwraca identyfikator danego atrybutu. ■ Object g e t ()

Zwraca pierwszą (jeśli wartości są uporządkowane) lub dowolną (jeśli wartości nie są uporządkowane) wartość danego atrybutu. ■

NamingEnumeration g e iA lH )

■ void destroySubcontext(String name) Zwraca obiekt wyliczeniowy umożliwiający iteracyjne przeglądanie wszystkich wartości danego atrybutu.

Niszczy podkontekst reprezentowany przez daną uazwę. Łańcuch przekazywany na wejściu tej metody musi obejmować wszystkie składniki ścieżki poza ostatnim.

Hfl javax.naming.NamingEnumeration (Java SE 1. 3)

■ void closeO Zamyka dany kontekst.

OBI javax.naming.di rectory .DirContext

■

(Java SE 1.3)

boolean hasMoreO

Zwraca wartość true, jeśli dany obiekt wyliczeniowy zawiera jeszcze jakieś elementy. ■ Object next O

■ Attributes getAttnidutesiString name) Zwraca atrybuty wpisu oznaczonego daną nazwą.

Zwraca kolejny element danego obiektu wyliczeniowego.

437

438

Rozdziano. ■ Usługi zewnętrzne

JavaServerFaces

Zarządzanie danymi konfiguracyjnymi Za każdym razem, gdy nasza aplikacja nawiązuje współpracę z usługami zewnętrznymi, musimy zdefiniować niezbędne parametry konfiguracyjne: adresy U R L, nazwy użytkowników, hasła itp. Tego rodzaju danych w żadnym razie nie należy trwale kodować w klasach aplikacji — takie podejście znacznie utrudniałoby aktualizację haseł, wymianę serwerów itd.

aplikacji i że może obsługiwać wiele sesji. I wreszcie wykorzystujemy ustawienia definiowane w ramach elementów managed-property do inicjalizacji tego komponentu JSF . Osiągnęliśmy więc cel polegający na umieszczeniu wszystkich parametrów inicjalizacji w pliku konfigu­ racyjnym (zamiast ich trwałego kodowania w klasie komponentu). Nasz komponent będzie oczywiście potrzebował metod ustawiających wartości tych właści­ wości: public class UserDirectoryBean { private String u r l, private String managerDN, private String managerPW;

Z przykładem właściwego podejścia do problemu zarządzania konfiguracją obejmującą bazę danych mieliśmy się okazję zapoznać w punkcie poświęconym odpowiednim usługom. Dane konfiguracyjne definiuje się w pliku server.xml Kontener serwletów wykorzystuje te infor­ macje do skonstruowania źródła danych i związania ich ze znaną nazwą. Klasy, które w y­ magają dostępu do tej bazy danych, wykorzystują interfejs JN D I w procesie lokalizacji źródła danych. Umieszczanie informacji konfiguracyjnych w pliku server.xml zdaje egzamin w przypadku takich zasobów globalnych jak bazy danych. Tego rodzaju zasoby mogą być wykorzystywane przez wszystkie aplikacje internetowe w ramach kontenera. Z drugiej strony, dane konfigu­ racyjne właściwe dla poszczególnych aplikacji należy umieszczać w plikach web.xml lub faces-config.xml. Na przykładzie połączenia z bazą danych LD A P przeanalizujemy wszystkie trzy możliwości.

439

public void setManagerDN(String newValue) { managerDN = newValue, } public void setManagerPassword(String newValue) { managerPW = newValue, } public void setURL(String newValue) { url = newValue, } public DirContext getRootContext() throws NamingException {

.

}

}

W czasie konstruowania obiektu tego komponentu następuje wywołanie tych metod usta­ wiających (na ich wejściu są przekazywane wartości zdefiniowane w pliku konfiguracyjnym

faces-config.xml). I wreszcie kod kliencki musi mieć dostęp do obiektu naszego komponentu JSF. Przypuśćmy na przykład, że klasa UserBean musi nawiązać połączenie z katalogiem:

Konfigurowanie komponentu Za każdym razem, gdy definiujemy komponent JS F w pliku konfiguracyjnym faces-config.xml, określamy parametry inicjalizacji za pośrednictwem elementów managed-property. Poniżej przedstawiono przykład konfiguracji komponentu nawiązującego połączenie z katalogiem LD A P: userdir com.corejsf.UserDirectoryBean application URL ldap://I ocal host:389 managerDN cn=Manager,dc=corejsf,dc=com managerPassword secret

Mamy tutaj do czynienia z doskonale nam znanymi elementami managed-bean-name i managedbean-class. Musimy jednak pamiętać, że definiowany komponent JS F otrzymuje zasięg aplikacji. Oznacza to, że obiekt tego komponentu pozostaje żywy przez cały czas pracy

UserDi rectoryBean userdir = ... / / Ja k ? DirContext context = userdir .connect(dn, pw),

Do zlokalizowania komponentu JS F wykorzystujemy wartość właściw ą dla jego nazwy — przykład takiego rozwiązania przedstawiono poniżej: FacesContext context = FacesContext,getCurrentInstance(); Application app = context.getApplication(), ValueBinding binding = app.createValueBinding("#{userdir}"); UserDirectoryBean dir = (UserDirectoryBean) binding.getValue(context),

Podsumowując, proces konfiguracji komponentu JS F obejmuje następujące kroki: 1.

Umieszczenie parametrów konfiguracyjnych w ramach elementów managed-property pliku konfiguracyjnego faces-config.xml.

2. Zdefiniowanie metod ustawiających wartości tych właściwości w klasie komponentu. 3. Odnalezienie obiektu komponentu z wykorzystaniem dowiązania jego wartości. Przedstawiona technika konfiguracji komponentów jest nie tylko prosta, ale też wyjątkowo wygodna. Okazuje się jednak, że opisany model nie zdaje egzaminu w przypadku obiektów, które mają być dostępne z poziomu wielu aplikacji internetowych. Co więcej, część progra­ mistów może argumentować, że plik konfiguracyjny faces-config.xml ma w założeniu opi­ sywać logikę aplikacji internetowej, nie jej interfejs do zasobów zewnętrznych — właściwym miejscem dla opisu takiego interfejsu jest plik web.xml. Czytelnicy, którzy podzielają tę argumentację, koniecznie powinni się zapoznać z treścią kolejnych punktów.

440

Rozdział 10. ■ Usługi zewnętrzne

JavaServer Faces

441

Proces uzyskiwania dostępu do zasobów za pośrednictwem kontekstu zewnętrznego składa się z następujących kroków:

Konfigurowanie kontekstu zewnętrznego W tym punkcie przyjmiemy, że nasza aplikacja JS F jest uruchamiana w formie serwletu. Niezbędne parametry możemy zdefiniować w pliku konfiguracyjnym web.xml za pośred­ nictwem zbioru elementów context-pa ram w ramach elementu web-app: URL lda p://local host:389 managerDN cn=Manager.dc-corejsf dc=com managerPassword secret

1. Umieszczenia parametrów konfiguracyjnych wewnątrz elementów context -pa rani w ramach pliku w eb.xm l

2. Użycia obiektu klasy External Context do odnalezienia wartości parametrów. 3. Przekształcenia tych parametrów w obiekty na potrzeby naszej aplikacji. Jak widać, prezentowana procedura konfiguracyjna ma miejsce na niższym poziomie niż konfi­ guracja komponentu JSF. Plik web.xml zawiera nieustrukturalizowaną listę parametrów. Kon­ struowanie obiektów wykorzystujących te parametry należy do programistów aplikacji. flB] javax. faces.context.FacesContext

■ ExternalContext getExterna1Context() Zwraca kontekst zewnętrzny, czyli opakowanie (w formie kontekstu serwletu lub portletu) wokół środowiska wykonawczego danej aplikacji JSF .



Aby odczytać interesujące nas parametry, musimy uzyskać obiekt kontekstu zewnętrznego. Obiekt kontekstu opisuje środowisko wykonawcze, w którym uruchomiono naszą aplikację JS F . Jeśli korzystamy z kontenera serwletów, możemy być pewni, że kontekst zewnętrzny ma postać opakowania wokół obiektu klasy ServletContext. Klasa S e rv íetConiext oferuje wiele metod pomocniczych, za których pośrednictwem możemy uzyskiwać dostęp do wła­ ściwości kontekstu serwletu. Na przykład metoda get 1mtParameter zwraca wartość para­ metru, którego nazwę przekazano na jej wejściu.

■ P R 9 E le m e n t u

L JI

context-param n i e

n io n y c h z n a c z n ik ó w

n a le ż y m y lić z e le m e n t e m

s łu ż y d o d e f in io w a n ia

i hit-param.

p a ra m e tró w , k tó re

r z a n e p rz e z s e r w le t w p o c z ą tk o w e j fa z ie je g o p ra c y . N a z w a

D r u g i z w y m ię -

m ogą

b y ć p rz e tw a ­

get I ni tParameter

d la m e to d y

javax.faces.context.ExternalContext

■ String get lm iParameter(Stnng name) Zwraca parametr inicjałizacji właściwy dla danej nazwy.

Konfigurowanie zasobu zarządzanego przez kontener W tym punkcie omówimy technikę konfigurowania zasobów dostępnych dla całego kontenera. Poniższy materiał opracowano z myślą o serwerach GlassFish i Tomcat. Inne kontenery oferują podobne mechanizmy, ale różnią się szczegółowymi rozwiązaniami.

o d c z y tu ją c e j p a r a m e tr k o n t e k s t u j e s t d o ś ć n ie s z c z ę ś liw a .

Poniżej przedstawiono przykładowy kod uzyskujący kontekst LD A P za pośrednictwem parametrów konfiguracyjnych web.xml: public DirContext getRootContext() throws NamingExceplion { LxternalContext external = FacesContext.getCurrent1nsiance() getFxternaiContexti ) String managerDN - external get InuParameteU"managerDN") String managerPw = external get[mtParameiert"managerPassword"). S trin g url

= extern al get 1n iiP a r a m e t e r t" u Rl " ) .

HashtaDle env = new Hash tab 1e ( ) .

env.put(Context SFCURIfY_PR[PC I PAL. managerDN). env put(Context.SE CUR 1Ty_CREDENTIA l S. managerPW). DirContext initial = new In 1 11alDirContext(env). Object obj = in itial lookup(url). if ( ! ( obj mslanceof DirContext)) throw new NamingExceptnonCBrak kontekstu“ ); return (DirContext) obj;

We wcześniejszej części tego rozdziału omówiono między innymi technikę konfigurowania źródła danych JD B C , które lokalizowano z wykorzystaniem metody wstrzykiwania zasobów lub przeszukiwania JN D I. Przedstawiona metoda zdawała egzamin w przypadku zasobów o zasięgu systemowym. Okazuje się, że serwery GlassFish i Tomcat umożliwiają nam stoso­ wanie tego samego mechanizmu także dla własnych zasobów. Użytkownicy serwera GlassFish mają do dyspozycji interfejs administracyjny umożliwiają­ cy dodawanie własnych, niestandardowych zasobów JN D I (patrz rysunek 10.12). W naszej przykładowej aplikacji ten niestandardowy zasób ma postać katalogu LDAP. W formularzu na stronie administracyjnej należy podać nazwę ( ldap/mydi r) oraz typ (javax. nami ng .di rectory ^ D i rContext) dodawanego zasobu. Jak się okazuje, nie istnieje standardowa fabryka kontek­ stów katalogów LD A P, stąd konieczność samodzielnej implementacji takiej fabryki typu con.corejsf Di rContextFactory. I wreszcie musimy określić następujące parametry połączenia (w formie dodatkowych właściwości): URL Hdap.//local host. 389

java.nami ng.securi ty.pri nci pal=cn=Manager,dc=corejsf.dc=com java.naming.security.credentlals=secret

442

Rozdziano. ■ Usługi zewnętrzne

JavaServer Faces ÿ

Rysunek 10.12. Przykład konfigurowania zasobu JNDI (w formie katalogu LDAP) w ramach serwera GlassFish

Sun JavafTM) System Application Serve« Platform Edition 9.0 Admin Console

Plik

Edycja

Widok

Historia

Zakładki

Narzędzia

p u b lic

Mejilla Eirefo.<

Ob ject

g e tO b je c tIrsian ce (0 b je c t

Name n. Context numeCtx

Pomoc

critlSElO.

443

o b j.

hasht ab 1e environment)

throws NamingFxception ]

3 B 'l

Píhsm ■«»twifiiijy U s e r: admin

S e r v e r : localhost

D o m a in : domain!

i>

Sun Java™ System Application Server Admin Console ®

Common Tasks

Application Server > Resources > JNDt > Custom Resources > Idap/mydir

IJ Application

Edit C u sto m R e so u rc e

v ca Applications

Edil an existing |ND< Cusron- resource

Eriierpr'be Applications

¡3

y 3

dicates required t'eid

Web Applications JN D I N am e :

fH ElB Modules 3

Copnectd' Modules

3

L.tecycie Mociu'es

3

Add Client Moauies

gg] Custom MBeans

R e s o u r c e type-

[¡sn/ax naming directory D*

jcorn"c"or-eis< DirContextEactory farror\ Class to- rpsOu'C-’ .moicr^p.-irt, )dva» naffllna SD1 ODlC't' r T 0r,

D e s crip tio n .

Resources U ^

|

p Enaoied

S ta tu s :

|DBc

'dap/mydi'

Fa c to ry c la s s -

v J | tWeo S e rvc e s

fc,

javä

IMS Resources

Metoda getObject 1nstance (przynajmniej w tak uniwersalnej postaci) może być wykorzysty­ wana do generowania dowolnych obiektów na podstawie dowolnych danych konfiguracyjnych. Same techniki wykorzystywania parametrów cechują się dużą zmiennością, co jednak nie powinno nam przeszkodzić w poznaniu tych parametrów, które dostarcza serwer aplikacji w procesie żądania zasobów. Parametry konfiguracyjne są umieszczane w obiekcie klasy Reference, czyli strukturze pod pewnymi względami przypominającej tablicę mieszającą. Nasza klasa fabryki umieszcza te parametry w tradycyjnej tablicy mieszającej, po czym uzyskuje kontekst danego katalogu (kompletny kod źródłowy tej klasy przedstawiono na listingu 10.9).

Additional Properties (3)

G3 lavaMai' Sessions

■v|ga iNDi •■r 3

P j S I I n t e r f e j s ObjectFactory j e s t i m p l e m e n t o w a n y t a k ż e p r z e z k l a s ę com. sun.jndi. 1dap. ■ n i ^LdapCtxFactory ( w y k o r z y s t y w a n ą w p o d r ę c z n i k u i n t e r f e j s u J N D I f i r m y S u n ) .

Custom Resources Q b W a p /m y d ir

3

External Resources

ir

Connectors

6- ®

Configuration

[C r T

paa^57^oc^TnosTT8^~™~~”

|java^ñam^

[seaeT

|cn=M anager ar=t.ore|sf dc=co«-n

O k a z u je s ię n ie s t e t y , ż e n ie m o ż e m y t e j k la s y u ż y ć w LDAP w V

Zakończono

jndi .1dap.LdapCtxFactory

ła ń c u c h a d r e s u

H

J

p re z e n to w a n y c h

p r z y k ła d a c h

w y k o r z y s tu je m y s t a n d a r d o w e

J N D I ( w t y m s t a n d a r d o w e d a n e u w ie r z y t e ln ia ją c e ) . S t a łe i n t e r f e js u

n a z w y ś r o d o w is k a

Context,

z k tó ry c h

s k ła d o w a n e

w

p r z y jm u je n a w e jś c iu

U R L , ta b lic ę ła ń c u c h ó w

m u ją c y w a r t o ś ć E S I W

r o li fa b r y k i p o łą c z e ń z u s łu g a m i

getObjectlnstance k l a s y com.sun. p a r a m e t r k l a s y Object'r e p r e z e n t u j ą c y U R L ł u b o b i e k t k l a s y Reference o b e j ­

r a m a c h n a s z e g o s e r w e r a a p lik a c ji. M e to d a

z k lu c z e m

fo r m ie

"URL” .

p a ra m e tru

a d re s ó w

P o z o s t a łe

ty p u

u s ta w ie n ia

Hashtable.

ś r o d o w is k o w e

m uszą

s t a r c z a n y p rz e z s e r w e r a p lik a c ji.

p o p r z e d n io k o r z y s t a liś m y , s ą w is t o c ie s k r ó t a m i d la n a z w ś r o d o w is k o w y c h . N a p r z y k ła d

Context.SECURITY_PRINCIPAL ^principal".

s ta ła

r e p r e z e n t u je

ła ń c u c h

"java.naming.security,

Musimy też opracować plik konfiguracyjny WEB-INF/sun-web.xml (patrz listing 10.8). Wspo­ mniany plik odpowiada za odwzorowywanie nazw zasobów serwera aplikacji w nazwy interfej­ su JN D I. W tym konkretnym przypadku posłużymy się jedną nazwą.

Listing 10.8. Plik konfiguracyjny ldap3/web/WEB-INF/sun-web.xml (tylko serwer GlassFish)___________________ 1 4. 5. 6. ldap/mydir 7 ldap/mydir 8. 9.

Musimy teraz zaimplementować własną klasę fabryki. Wszystkie tego rodzaju klasy muszą implementować interfejs ObjectFactory i metodę getObjectlnstance: public class DirContextFactory implements ObjectFactory {

Listing 10.9. Kod klasy ldap3/setup/java/com/corejsf/DirContextFactory.java 1 2 3 4 5 6 7 8 9

być

W s p o m n ia n y p a r a m e t r n ie j e s t d o ­

package com.corejsf, import Java.util Enumeration, import java.util.Hashtable,

i mport javax.nami ng.Context; import javax.naming.Name: i mport javax.nami ng.Nami ngExcepti on, import javax.naming.RefAddr; 10 import javax.naming.Reference: 11 i mport javax.nami ng.di rectory.Di rContext; 12 import javax.nami ng.di rectory.Ini ti a1Di rContext, 13 import javax.naming.spi .ObjectFactory: 14 15 public class DirContextFactory implements ObjectFactory { 16 public Object get0bjectlnstance(0bject obj, 17 Name n, Context nameCtx, Hashtable environment) 18 throws NamingException { 19 20 Hashtable env = new Hashtable(): 21 String url = nul1: 22 Reference ref = (Reference) obj: 23 Enumeration addrs = ref getAllO;

444

Rozdziano. ■ Usługi zewnętrzne

JavaServer Faces 24 25

w h ile (ad d rs.h asM o reElem ents()) { RefAddr addr = (RefAddr) addrs nextE lenient( )

26 27

S trin g name = addr g e tT y p e (). S trin g value = (S t r in g ) addr getC o n tent( ) .

28

if

29

(name equa1s ("U R L " ) )

e ls e env put(name

url

}

31

D irC o n te n

32 33

if (u rl == n u ll) re tu rn i n i t i a l . e ls e retu rn i n i t i a l lo o k u p (u rl).

34 35

in itia l

Tworzenie aplikacji LDAP W tym punkcie spróbujemy opracować i zademonstrować kompletną aplikację składującą dane o użytkownikach w katalogu LD AP.

= valu e.

v a lu e ).

30

= new In 1 11 a 1D irC o n te x t( e n v).

I 1

I P lik

ldap3/$etup/java/com/corejsf/DirContextFactoryjava

n a le ż y

s k o m p ilo w a ć

u m ie ś c ić w p lik u J A R :

Nasza aplikacja symuluje witrynę internetową agencji informacyjnej, która oferuje darmo­ wy dostęp do komunikatów tym użytkownikom, którzy podadzą swoje dane osobowe. Pre­ zentowana aplikacja ma jedynie charakter demonstracyjny, stąd zrezygnowano z dostarczania użytkownikom rzeczywistych komunikatów — nasza aplikacja składa się ze strony logowania (patrz rysunek 10.13) i odrębnej strony rejestracji użytkowników (patrz rysunek 10.14). Jeszcze inna strona (docelowo prezentująca użytkownikowi komunikaty) jest wyświetlana po podaniu prawidłowych danych uwierzytelniających (patrz rysunek 10.15).

Rysunek 10.13.

cd corej5f-exa/7?p7es/chl0/ldap3/setup/java javac com/corejsf/DirContextFactory.java jar cvf dirctxfactory.jar com/corejsf/ *.cl ass G o to w y p lik J A R m u s im y n a s tę p n ie p r z e n ie ś ć d o k a ta lo g u

445

Logowanie do usługi agencji informacyjnej głassfish/domains/domainl/

W/b/ext

l

Puk

Edycja

Widok

Hirtons

ą J?

^ r *

Zakładki

¡jj i

»

P.omo£ -

'

t

0 t

p

-

'

j P rosim y w p isać nazwę i hasło użytkow nika. Identyfikator ¡foose^eh Hasło

! Załoguj.1

Opisywana procedura przebiega bardzo podobnie na serwerze aplikacji Tomcat. W pierwszej kolejności powinniśmy zdefiniować element Resource (wraz z jego elementami Resource ^-►Pararos) w pliku server.xml:

Nie jestes zarejestrowanym użytkownikiem'7 Zarejestruj się juz terazij Zarejestruj i

^ResourceParams name=” 1dap/mydirM> factory com.corejsf.DirContextFactory URL ldap://I ocal host:389 java.nami ng.securi t y .pri nci pal cn=Manager,dc=corejsf,dc=com java.nami ng.securi t y .credenti als secret

Gotowy plik JA R (obejmujący skompilowaną wersję klasy Di rContextFactory) należy umie­ ścić w katalogu common/lib serwera Tomcat. Musimy pamiętać o konieczności ponownego uruchomienia tego serwera. Nie będziemy natomiast potrzebowali pliku sun-web.xml.

Rysunek 10.14. Rejestrowanie użytkownika internetowej agencji informacyjnej

Aplikacja LDAP - Mo?i

¡Ti* mmmy

' j ' . ntcp://łocalhost:8080/)dap/index.face|

R ejestracja now ego użytkow nika Prosimy podać dane osobowe i kliknąć przycisk Zarejestruj. Imię

'¡Herbert

Inicjał drugiego imienia

j

IW

Nazwisko

[Hoover

Adres poczty elektronicznej jhhpover@white'house.oij Identyfikator

!hhoover

Hasło

j ~~~j

Zakończono .„.W

. V:

__ ___

_

i ~~

;

Strona aktualizacji danych bardzo przypomina stronę rejestracyjną, stąd zrezygnowali­ śmy z prezentowania odpowiedniego zrzutu. Na rysunku 10.16 przedstawiono strukturę katalogów tej aplikacji; na rysunku 10.17 przedstawiono schemat przechodzenia pomiędzy jej stronami.

446

Rozdział 10. ■ Usługi zewnętrzne

JavaServer Faces

Rysunek 10.15. Główne okno usługi agencji informacyjnej

Aplikacja LDAP - MozłRa Firefox Pu*

Edycja

Widok

Historia

«0

■'///

t

ZaeteiM

Narzędzia

lh y Pomoc

■ 1-nrp://1oca.i>.--r:ñ080/tdap/index:.face ¡ »

¡W g ftf

i® 1

Opisaną aplikację opracowano w trzech wersjach — z danymi konfiguracyjnymi zdefiniowa­ nymi odpowiednio w pliku faces-config.xml, w pliku web.xml oraz na serwerze aplikacji. Wszystkie trzy wersje składają się z identycznych stron internetowych, których kod przed­ stawiono na listingach od 10.10 do 10.13. (Kod tych stron przedstawiono oczywiście tylko raz). Najważniejszą różnicą dzielącą te wersje jest sposób implementacji metody getRootContext klasy UserBean (patrz listing 10.14).

Uwierzytelnianie zakończone pomyślnie 1 'Vitai'»svdf-'wniku Herl'"n ®

fioov-i 1

1 Abv zdt.pralizowcii swoie lane osobowe lub zuuenir hasłt . kJbknu przvcisP «ktualizui1 r%tuas!i2y, 1 ! Vvytoyuj j

Listing 10.10. Kod strony ldap/web/index.jsp 1

I Zakończono

? Iü3 META-INF ! Q MANIFEST.MF f ¿3 WEB-INF

Struktura katalogów naszej przykładowej aplikacji

|

?

| | l |

( ¡3 classes

f E3 com $ [¡3 corejsf

! i

j- Q Nam e.class

|

j

T- Q UserBean. class

\

\

| " Q UserDirectoryBean. class

| |

; i

; L-

L Q m essages.properties Q face s-co n fig .x m l Q w eb . xm l

| - D index.htm l

\

Q

in d e x .jsp

j Q intern alE rror.jsp j-- Q loginError.jsp I

D signup.jsp

!' D sig.nupError.jsp j - D u p d a te .js p I



2

<°r@ t ag 11b un ="mtp

//java sun com/jsf/core" prefix="f" %>

3

<%e

/ / j a v a Sun

Lag 1 1D u r 1=" n r t p

co m /jsf/h im r

p r e f i x = ” h ’ %>

4. <-f-vtew> 5 6 7. 8. 9 10. 11. 12 13. 14. 15. 16 17. 18 19.
20. 21 22 23. 24. 25

¡ 3 Id a p .w a r

RysuneK 10.16.

Q w elc om e.jsp__________________________

Rysunek 10.17. Diagram przechodzenia pomiędzy stronami aplikacji agencji informacyjnej

Listing 10.11. Kod strony Idap/web/signup.jsp 1 2 3 4



10 11 12

< tu ie > < h .output Text vaiue="^{msgs 1 1 l l e }"/>

13 14



15 16 17

m inputText value= "#{u ser name midd1e }"/>

18

%> %>



6 7 9

I

<°4@ t a g h b u n = "http-//java sun com/js f / c o r e " p re fix = "f" <°4@ Lag 11 D u n ="n ttp - //java sun com /jsf/htm l" p re fix - "h "

5

8

j: :"j ,|

447

448

Rozdział 10. ■ Usługi zewnętrzne

JavaServer Faces 19. 20.



21.

Listing 10.13. Kod strony Idap/web/loginError.jsp 1. 2. taglib uri="http;//java.sun.com/jsf/core" prefix="f" %> 3. taglib uri="http7/java.sun.com/jsf/html" prefix="h" %> 4. 5. 6. 7. 8. 9.

Cl

1. 2. taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. 5. 6. 7. 8. 9. 10. 11.

12. 13. ! 14.

15.

16. 20. 21. 22. 23.

A

Listing 10.12. Kod strony Idap/web/welcome.jsp

V

22 23 24 25. 26. 27. 28 29 30. 31. 33 34. 35. 36.

10 11

12. 13 < /p> 14.

15. 16. 17. 18. 19. 20. 21.

Listing 10.14. Kod klasy Idap/src/java/com/corejsf/UserBean.java package com.corejsf; import java.util.logging.Level; import java.util.logging.Logger; import javax.el ELContext; import javax.el.ExpressioriFactory; import javax.el.ValueExpression; import javax.faces.application.Application; 10 import javax.faces.context.FacesContext; 11 import javax.naming.NameNotFoundException; 12 import javax.nami ng.Nami ngExcepti on; 13 import javax.nami ng.di rectory.Attri butes; 14 import javax.naming.directory.BasicAttributes; 15 i mport javax.nami ng.di rectory.Di rContext; 16 17 public class UserBean { 18 private Name name; 19 private String id; 20 private String email; 21 private String password; 22 private Logger logger = Logger.getLogger("com.corejava"); 23 24 public UserBeanO { name = new NameO; } 25 26 public DirContext getRootContext() throws NamingException { 27 FacesContext context = FacesContext.getCurrentInstance(); 28 ELContext el Context = context,getELContext(); 29 Application app = context.getApplication(); 30 ExpressionFactory factory = app.getExpressionFactory(); 31 ValueExpression ex = factory.createValueExpression(elContext, 32 "#{userdir}", UserDirectoryBean.class); 33 UserDirectoryBean dir = 34 (UserDirectoryBean) ex.getValue(elContext); 35 return dir,getRootContext(); 36 37 38 public Name getNameO { return name; } 39 public void setName(Name newValue) { name = newValue; 40 41 public String getEmaiK) { return email; } 42 public void setEmail(String newValue) { email = newValue;

449

450

Rozdział 10. ■ Usługi zewnętrzne

JavaServerFaces 43. 44 45. 46. 47 48 49 50 51 52 53 54 55 56 57 58 59 60. 61 62 63 64. 65 66 67. 68 69. 70. 71. 72. 73. 74 75 76 77. 78. 79 80 81. 82. 83. 84. 85.

101

id = newValue; }

public String getPassword() { return password, } public void setPassword(String newValue) { password = newValue; } public String loginO { try { DirContext context =getRootContext(); try { String dn = "uid=" + id + " ,ou=people,dc=corejsf,dc=com"; Attributes userAttributes = context.getAttributes(dn); String cn = (String) userAttributes.get("cn") ,get(); name.parse(cn); email = (String) userAttributes.get("mai1 "),get(); byte[] pw = (byte[]) userAttributes.getC'userPassword"),get(); i f (password.equals(new String(pw))) return "login_success"; else return "login_fai1ure", } finally { context.closeO; } } catch(NamingException ex) { logger.log(Level.SEVERE, "loginAction", ex); return "login_error"; } } public String signupO { try { DirContext context = getRootContext(); try { String dn = "uid=" + id + " ,ou=people,dc=corejsf,dc=com"; try { context.lookup(dn); return "signup_fai1ure"; } catch (NameNotFoundException ex) {}

86

87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99.

logger.log(Level.SEVERE, "loginAction", ex); return "signup_error";

100.

public String getldO { return id; } public void setId(String newValue) {

Attributes attrs = new BasicAttributesO; attrs.put("objectClass", "inetOrgPerson"); attrs.putC'uid", id); attrs.putC'sn", name.getLast()); attrs.putC'cn", name.toString()); attrs.put( "mai1", email); attrs.put( "userPassword", password,getBytes()); context,createSubcontext(dn, attrs); } finally { context.close(); } } catch (NamingException ex) {

451

102.

}

103. 104. 105. 106. 107. 108 109.

return "signup_success"; }

110.

111. 112

113. 114. 115. 116. 117. 118. 119. 120. 121. 122.

123 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. }

public String updateO { try { DirContext context = getRootContext(), try { String dn = "uid=" + id + " ,ou=people,dc=corejsf,dc=com"; Attributes attrs = new BasicAttributesO, attrs.putC'sn", name.getLast()); attrs. put ("cn", name.toStringO); a ttrs.put( "mai1", email); attrs.put("userPassword", password.getBytes()); context.modi fyAttributes(dn, DirContext.REPLACE_ATTRIBUTE, a ttrs ); } finally { context .closeO; } } catch (NamingException ex) { logger.log(Level.SEVERE, "updateAction", ex), return "internal_error"; } return "update_success"; } public String logout0 { password = return "logout_success"; }

Pierwsza aplikacja składa się między innymi z klasy UserDi rectoryBean (patrz listing 10.15) skonfigurowanej w pliku faces-config.xml (patrz listing 10.16). Druga aplikacja przeszukuje parametry inicjalizacji serwletu w trybie ad hoc. Trzecia wersja wykorzystuje technikę wstrzykiwania zasobów (z użyciem klasy przedstawionej na listingu 10.9 — patrz poprzedni punkt tego podrozdziału). I wreszcie, dla kompletności naszych rozważań, na listingu 10.17 przedstawiono kod źródłowy klasy Name wykorzystywanej przez klasę komponentu UserBean.

Listing 10.15. Kod klasy ldap/src/java/com/corejsf/UserDirectoryBean.java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

package com.corejsf; import import import import import

java.util.Hashtable; javax.naming.Context; javax.naming.NamingException; javax.naming.directory.DirContext; javax.naming.directory.InitialDirContext;

public class UserDirectoryBean { private String u r l;

452

Rozdziano. ■ usługi zewnętrzne

JavaServer Faces 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22 23. 24. 25. 26. 27. 28. 29. 30.

private String managerDN; private String managerPW, public void setManagerDN(StringnewValue) {managerDN = newValue, } public void setManagerPassword(StringnewValue) { managerPW = newValue: } public void setURL(String newValue) { url = newValue: } public DirContext getRootContext() throws NamingException { Hashtable env = new Hashtable(): env.put(Context.SECURITY_PRINCIPAL. managerDN), env.put(Context.SECURITY_CREDENTIALS, managerPW), DirContext in itia l = new InitialDirContext(env), Object obj = in it ia l.1ookupCurl); i f ( ! (obj instanceof DirContext)) throw new NamingExceptionC'Brak kontekstu"); return (DirContext) obj: } }

Listing 10.16. Plik konfiguracyjny Idap/web/WEB-INF/faces-config.xml 1. 2. 7. 8. /index.jsp 9. 10. logi n_success 11. /welcome.jsp 12. 13. 14. logi n_error 15. /loginError.jsp 16. 17. 18. login_failure 19. /loginError.jsp 20. 21. 22. 23. /signup.jsp 24. 25. signup_success 26. /welcome.jsp 27. 28. 29. signup_failure 30. /signupError.jsp 31. 32. 33. signup_error 34. /signupError.jsp

35. 36. 37. 38 39. 40. 41. 42. 43. 44. 45. 46. 47 48 49 50. 51. 52. 53. 54 55. 56. 57. 58 59. 60. 61. 62. 63 64. 65. 66. 67 68 69. 70. 71. 72 73. 74. 75. 76 77 78 79 80. 81 82. 83. 84 85. 86. 87. 88. 89. 90 91

si gnup_cancel /i ndex.jsp /welcome.j sp update /update.jsp logout_success /index.jsp /update.jsp update_success /welcome.jsp update_cancel /welcome.jsp logi n /index.jsp si gnup /si griup.jsp internal_error /internalError.jsp user com.corejsf,UserBean session userdir com.corejsf.UserDirectoryBean application URL ldap://I ocal host:389

453

454

JavaServer Faces 92 93. 94 95 96 97. 98 99. 100

managerDN cn=Manager,dc=corejsf,dc=com managerPassword secret

Rozdziano. ■ usługi zewnętrzne 38. 39. 40. 41. 42 43. 44. 45. 46. }

455

builder.append(’ ' ) , i f (middle lengthO > 0) { builder.append(middle.charAt(O)); builder.appendO. "); } buiIder.append(last): return builder.toString(), }

1 01

102 103 104. com.corejsf.messages 105. msgs 106. 107 108.

Listing 10.17. Kod klasy Idap/src/java/com/corejsf/Name.java 1 package com.corejsf; 2 3 public class Name { 4 private String first; 5 private String middle; 6 private String last; 7 8 public NameO { firs t = middle = last = ""; } 9 10 public String getFirstO { return first, } 11 public void setFirst(String newValue) { firs t = newValue; } 12 public String getMiddleO { return middle: } 13 public void setMiddle(String newValue) { middle = newValue, 14 public String getLastO { return last; } 15 public void setLast(String newValue) { last = newValue; } 16 17 public void parse(String full Name) { 18 int firstSpace = full Name indexOf(' '), 19 int lastSpace = fulIName.Iastlndex0f(' '); 20 i f (firstSpace == -1) { 21. firs t = 22 middle = 23. last = fulIName, 24. 25. else 26 firs t = full Name, substrings, firstSpace); 27. i f (firstSpace < lastSpace) 28 middle = full Name.substring(firstSpace + 1, lastSpace), 29. else 30 middle = 31. last = ful IName.substring(lastSpace + 1, ful 1Name. lengthO); 32 33. 34 35 public String toStringO { 36 StringBuilder builder = new StringBuilderO; 37. builder.append(fi r s t );

Uwierzytelnianie i autoryzacja zarządzana przez kontener W poprzednich podrozdziałach koncentrowaliśmy się na technikach tworzenia aplikacji internetowych wykorzystujących katalog LD A P do lokalizowania danych o użytkownikach. Za właściwe wykorzystywanie tych informacji odpowiadała sama aplikacja, od której zależała decyzja o przyznaniu bądź uniemożliwieniu dostępu do określonych zasobów. W tym pod­ rozdziale omówimy alternatywne podejście polegające na uwierzytelnianiu zarządzanym przez kontener (ang. container-managed authentication). Prezentowany mechanizm przenosi odpowiedzialność za uwierzytelnianie użytkowników na serwer aplikacji. Zachowywanie spójności w procesach gwarantujących bezpieczeństwo danych (we wszystkich komponentach aplikacji internetowej) jest dużo prostsze, jeśli to kontener zarządza uwie­ rzytelnianiem i autoryzacją. Programista aplikacji może się wówczas koncentrować na wła­ ściwym przepływie pracy w ramach tworzonej aplikacji (bez konieczności zajmowania się obsługą przywilejów i ról poszczególnych użytkowników). Większość materiału poświęconego szczegółowym zabiegom konfiguracyjnym opracowa­ no co prawda z myślą o serwerach GlassFish i Tomcat, jednak pozostałe serwery aplikacji oferują podobne rozwiązania. Aby chronić określony zbiór stron internetowych, należy zdefiniować odpowiednie usta­ wienia kontroli dostępu w pliku web.xml. Na przykład poniższa konstrukcja tak ogranicza dostęp do wszystkich stron w folderze protected , aby mogły być przeglądane wyłącznie przez uwierzytelnionych użytkowników z przypisanymi rolami regi stereduser lub i nvi tedguest: /protected/* registereduser i nvitedguest

Rola jest przypisywana użytkownikowi w chw ili uwierzytelniania. Role są składowane w katalogu użytkowników (wraz z ich nazwami i hasłami).

456

JavaServer Faces

Rozdziano. ■ Uskigi zewnętrzne

J e ś li s e r w e r J a v a S e r v e r F a c e s s k o n f ig u r u je m y w t a k i s p o s ó b , a b y d la s t r o n J S F b y ł s to s o w a n y p rz e d ro s te k a d re s ó w

URL do

/faces,

b ę d z ie m y m u s ie li d o d a ć o d p o w ie d n i w z o r z e c

k o n s tr u k c ji z a b e z p ie c z a ją c y c h

k ła d u b y łb y t o w z o r z e c /

(w

p rz y p a d k u

p r z e d s t a w io n e g o

p rz y ­

faces/protected/*).

E S I A b y b e z p ie c z n ie p r z e s y ła ć d a n e u w ie r z y t e ln ia ją c e p o m ię d z y k lie n t e m B a l p o w in n iś m y w y k o r z y s ta ć te c h n o lo g ię S S L (o d a n g .

457

a s e rw e re m ,

Secure Sockets Layei).

S zczegó­

ło w e o m a w ia n ie t e c h n ik k o n fig u r a c ji s e r w e r a S S L w y k r a c z a p o z a z a k r e s te m a ty c z n y t e j k s ią ż k i. D o d a tk o w y c h

in fo r m a c ji n a te n

t e m a t n a le ż y s z u k a ć n a s t r o n a c h

in te r n e to ­

http://java.sun.com/developer/technicaiArticles/WebSeivices/appsen/8-l.h tml ( G l a s s F i s h ) i http://jakarta.apache.org/tomcat/tomcat-5.5-doc/sskhowto.htmi ( T o m c a t ) .

w ych

Musimy następnie określić sposób, w jaki użytkownicy mają uwierzytelniać swój dostęp do naszej aplikacji. Najbardziej elastycznym podejściem jest uwierzytelnianie za pośrednictwem stosownych formularzy — w tym celu wystarczy dodać do pliku web.xml następujący wpis: F0RM / logm ntml

< logm ■conf> BASlCTen łańcuch z o sta n ie wyświetlony w oknie di alogowym

hem 1 < / f o r m - e r r o r -page>

< f or m - e r r o r ■pd g e> /n od Uth

Podstawowy mechanizm uwierzytelniania można zbudować także, umieszczając w pliku

web.xml następującą konstrukcję konfiguracyjną:



Przedstawiona konfiguracja mechanizmu logowania za pośrednictwem formularza wskazuje na stronę internetową, na której użytkownik będzie mógł wpisać nazwę i hasło. W kwestii projektu i wyglądu strony logowania mamy oczywiście pełną swobodę, jednak kod tej strony musi definiować mechanizm wysyłający do strony j_securi ty_check żądanie obejmujące parametry nazwane j_usernarne oraz j_password. W tym celu wystarczy skonstruować nastę­ pujący formularz:

W takim przypadku przeglądarka wyświetla okno dialogowe hasła (patrz rysunek 10.19). Okazuje się jednak, że profesjonalnie projektowane witryny internetowe zdecydowanie częściej wykorzystują uwierzytelnianie za pośrednictwem formularzy W W W .

Rysunek 10.19. Podstawowy mechanizm uwierzytelniania

Nazwa użytkownika Hasło

Łączenie z: openidao Mazwa użytkownika: O Hasło:

trooseve '1

.. .. .. .. .. ..

f j Zapamiętaj moje hasło



Funkcję strony z komunikatem o błędzie może pełnić dowolny dokument. Kiedy użytkownik żąda dostępu do chronionego zasobu, aplikacja powinna wyświetlić stronę logowania (patrz rysunek 10.18). Jeśli użytkownik wpisze prawidłową nazwę i hasło, aplikacja wyświetli żądaną stronę. W przeciwnym razie oczom użytkownika ukaże się strona z komu­ nikatem o błędzie.

Rysunek 10.18. Próba uzyskania dostępu do chronionego zasobu

■

Formularz logowania Plik

Edycja

Widok

Historia

Zakładki

1

Narzędzia

Pomoc

3 8080/accejscontrol/[ j r

■rf||| L Ę p jj V'ffpM , http://loc lhost:

Aby uzyskać dostęp do informacji chronionych, musisz się zalogować

1Nazwa użytkownika: ¡troosevelt

S i u i i ! _____ ¡ B ś '

Plik web.xml opisuje tylko zasoby będące przedmiotem konstrukcji ograniczających dostęp i obejmuje role, które mają takim dostępem dysponować. Plik konfiguracyjny web.xml w żaden sposób nie określa sposobu składowania nazw, haseł i ról użytkowników. Tego rodzaju infor­ macje konfigurujemy, opisując domenę (ang. realm) danej aplikacji internetowej. Mianem domeny określamy dowolny mechanizm lokalizujący nazwy, hasła i role użytkowników. Serwery aplikacji z reguły oferują obsługę wielu standardowych domen uzyskujących dostęp do informacji o użytkownikach składowanych w następujących źródłach:

\

■ katalogu LD A P, I fTajpgui ,j

■ relacyjnej bazie danych, ■ pliku (np. w pliku conf/tomcat~users.xml serwera Tomcat).

1Zakończono

Użytkownicy serwera aplikacji GlassFish mają do dyspozycji interfejs administracyjny, za pośrednictwem którego mogą skonfigurować domenę. W menu Configuration/Security/Realms należy wybrać opcję utworzenia nowej domeny nazwanej openldap. Wykorzystujemy domyśl­ ną nazwę klasy, po czym definiujemy następujące parametry połączenia (jako tzw. właści­ wości dodatkowe):

458

Rozdziano. ■ Usługi zewnętrzne

JavaServerFaces c lire c to ry lddp / /1 OC d l hos L 389 b a sed n ou=people.dc= corejsf.dc-con

459

rozwiązanie jest zalecanym sposobem definiowania domen właściwych dla poszczególnych aplikacji pracujących na serwerze Tomcat.

jdds-context ldapRealm sedrch p in d d n cn=Manager. d c = c o re js i, dc=com sedrch-bm dpdssw ord secret se d rch - f 1 1te r uid =%s group-bdse-dn ou=groups.dc^corejsf.dc=com group■tdrget en group-sedrch■f 1 1te r

D o m e n ę m o ż n a s k o n f ig u r o w a ć ta k ż e z a p o ś r e d n ic t w e m w

c h c ie li w y k o r z y s ty w a ć a p lik a c ję

uniqueMember=$d

Musimy też opracować plik konfiguracyjny WEB-INF/sun-web.xml (patrz listing 10.18). Prezentowany plik odpowiada za odwzorowywanie nazw ról w nazwy grup. W naszym przypadku nazwy obu struktur będą identyczne.

Listing 10.18. Plik konfiguracyjny accesscontrol/web/WEB-INF/sun-web.xml (tylko serwer GlassFish) 1 2 3

7 8 9 0

registereduser registereduser

1

< / S O C u r i t y -r o le - m a p p i n g >

2 3 invuedguest 4 mv i tedguest 5 6 7

e le m e n tó w

Engine

lu b

Host

T a k s k o n f ig u r o w a n a d o m e n a j e s t je d n a k w y k o r z y s ty w a n a n ie

t y lk o p rz e z n a s z ą a p lik a c ję in t e r n e t o w ą , a le t a k ż e p rz e z a p lik a c ję m e n e d ż e r a . G d y b y ś m y m e n e d ż e ra d o

w y c h , m u s ie lib y ś m y z a g w a r a n to w a ć w łą c z e n ie r o li

6

server.xml.

p lik u

manager d o

in s ta la c ji n a s z y c h

a p lik a c ji in te r n e to ­

n ie z b ę d n e j n a z w y i h a s ła

u ż y tk o w n ik a

dom eny.

Ponieważ za uwierzytelnianie i autoryzację odpowiada serwer aplikacji, sami nie musimy niczego programować. Mimo to chcemy zachować możliwość programowego uzyskiwania dostępu do informacji o użytkownikach. Niewielką ilość interesujących nas informacji (w tym nazwę załogowanego użytkownika) oferuje klasa Ht LpServ let Request. Obiekt żądania można uzyskać za pośrednictwem kontekstu zewnętrznego: Lxtenna1Context external = FacesContext getCument I nstancei) get Externa 1Context (). HtipServ1elRequest request - (HttpServletRequest) external getRequest(). String user = request,getRemoteUser()

Możemy też sprawdzić, czy bieżący użytkownik ma przypisaną określoną rolę. Przykład takiego rozwiązania przedstawiono poniżej: String role = "admin". boolean lsAdmm = request isuser1nRo1e( ro le).

N ie is t n ie je o b e c n ie ż a d n a s p e c y fik a c ja o p is u ją c a p r o c e s y w y lo g o w y w a n ia a n i p r z e ­ łą c z a n ia

u ż y tk o w n ik ó w

k o r z y s ta ją c y c h

B r a k t a k ie j s p e c y f ik a c ji o k a z u je

z m e c h a n iz m ó w

z a b e z p ie c z e ń

k o n te n e ra .

s ię d o ś ć p r o b le m a t y c z n y s z c z e g ó ln ie w t r a k c ie t e s t o ­

w a n ia a p lik a c ji in t e r n e t o w y c h . S e r w e r y G la s s F is h i T o m c a t w y k o r z y s t u ją z n a c z n ik i k o n ­

Konfiguracja domeny w serwerze Tomcat wymaga zdefiniowania elementu Rea 1m. Na listingu 10.19 przedstawiono dość typowy przykład konfiguracji domeny JND1 dla serwera LD AP.

Listing 10.19. Plik konfiguracyjny accesscontrol/src/conf/context.xml (tylko serwer Tomcat) 1 2 12

t e k s t u k lie n t a ( tz w . c ia s t e c z k a ) d o r e p r e z e n t o w a n ia b ie ż ą c e g o u ż y t k o w n ik a . O z n a c z a t o , że za ka żdym

z d e c y d o w a liś m y s ię w y k o r z y s ta ć d o t e s t o w a n ia n a s z e j a p lik a c ji p r z e g lą d a r k ę u r u c h a m ia

s ię

n ie p o r ó w n a n ie

s z y b c ie j o d g r a f ic z n y c h

p r z e g lą d a r e k

L yn x, k tó ra

in te r n e to w y c h

(p a trz ry s u n e k 1 0 .2 0 ) .

W dalszej części tego podrozdziału zostanie przedstawiony szkielet aplikacji ilustrującej funk­ cjonowanie mechanizmów zabezpieczających oferowanych przez kontener. Kiedy próbujemy uzyskać dostęp do zasobu chronionego protected/welcome.jsp (patrz listing 10.20), następuje wyświetlenie okna dialogowego umożliwiającego uwierzytelnienie (patrz listing 10.21). Użytkownik może kontynuować pracę, pod warunkiem że poda nazwę i hasło użytkownika, któremu przypisano rolę regi stereduser lub mvi tedguest.

Listing 10.20. Kod strony accesscontrol/web/protected/welcome.jsp 1

Przedstawiona konfiguracja nie tylko obejmuje informacje o adresie U R L i danych uwierzytel­ niających, ale też opisuje sposób lokalizowania użytkowników i ról. Element Realm należy umieścić w ramach elementu Context w pliku konfiguracyjnym context.xml. Przedstawione

r a z e m , g d y c h c e m y p r z e łą c z y ć u ż y t k o w n ik a , m u s im y z a m k n ą ć i u r u c h o m ić

p o n o w n ie p r z e g lą d a r k ę ( łu b p rz y n a jm n ie j u s u n ą ć is t n ie ją c e d a n e o s o b o w e ) . O s t a t e c z n ie

2 3 4. 5.



<1$ Ldg11D uri ="hitp //java.Sun com/jsf/core" pre f 1 X- " f" %> Lag 11b un="hitp://javd.sun.com/jsf/ntml" prefix="h" %>



460

Rozdziano. ■ Usługi zewnętrzne

JavaServer Faces

Rysunek 10.20. Przykład użycia przeglądarki Lynx w procesie testowania aplikacji internetowej

Password

10 1L 12 13 14 15 16 17 18 19 20

21



461



-td>Hasio

22 <'/tabie> 23 24 25 26 6 7

4 5. 6 7 8

Aby uzyskać dostęp do chronionych informacji, musisz się zalogować.

9

Nazwa użytkownika

1. 2. 7.

462

Rozdziano. ■ Usługi zewnętrzne

JavaServer Faces

Rysunek 10.22. Struktura katalogów aplikacji ilustrującej działanie mechanizmów kontroli dostępu

¡3 f ! f j \ | I j |

accesscontrol.war C3 META-INF !- Q MANIFEST. MF Q WEB-INF t £3 classes I com i ^ Cu3 corejsf j ¡ - Q UserBean. class | [ Q messages, properties j Q faces-config.xrril

i| Q j f j

sun-web.xml

! Q web.xml protected ; Q welcome.jsp

Listing 10.23. Kod strony accesscontrol/web/noauth.html 1 2 3 4. 5. 6. 7.

Przykro nam -- próba uwierzytelnienia zakończyła się niepowodzeniem. Spróbuj ponownie.

8 9

; Q index.html j- Q login.html : Q noauth.html

8 9. 10. 11. 12 . 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26 27. 28. 29. 30 31. 32. 33. 34. 35. 36 37. 38. 39. 40. 41. 42. 43. 44 45 46. 47. 48.

Faces Servlet javax.faces.webapp.FacesServlet l Faces Servlet *.faces i ndex.html Protected Pages /protected/* regi stereduser invitedguest FORM openldap /logi n.html /noauth.html registereduser i nvi tedguest

Listing 10.24. Kod klasy accesscontrol/src/java/com/corejsf/UserBean.java 1 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40.

package com.corejsf; import import import import

java.util.logging.Logger; javax.faces.context.External Context; javax.faces.context.FacesContext; javax.servlet.http.HttpServletRequest;

public class UserBean { private String name; private String role; private Logger logger = Logger,getLogger("com.corejsf"). public String getNameO { i f (name == null) getUserData(); return name == null ? "" : name; } public String getRoleO { returnrole == null ? "" :role, } public void setRole(String newValue) { role =newValue; } public boolean isInRoleO { External Context context =FacesContext.getCurrentInstance() .getExternalContext(); Object requestObject = context,getRequest(); i f (¡(requestObject instanceof HttpServletRequest)) { logger.severe("obiekt żądania jest typu; " +requestObject.getClassO); return false; } HttpServletRequest request = (HttpServletRequest) requestObject; return request.isUserInRole(role); } private void getUserDataO { External Context context =FacesContext.getCurrentlnstanceO.getExternalContext 0 ; Object requestObject = context.getRequest(); i f (¡(requestObject instanceof HttpServletRequest)) { logger.severe("obiekt żądania jest typu- " +requestObject.getClassO); return; }

463

464

JavaServer Faces

Rozdział 10. ■ Usługi zewnętrzne

41

H tip S ervietR e q u e st request

42

name = r e q u e s t

43

= ( H tip S e rv le tR e q u e s t) requestObject

g e t R e m o t e U s e r t ).

[

44

}

465

Twórcy witryny Amazon.com zdecydowali się udostępnić te usługi podmiotom zewnętrznym zainteresowanym sprzedażą towarów swoim klientom za pośrednictwem tego sprawdzonego systemu. Przed uruchomieniem naszego programu będziemy musieli się zarejestrować na witrynie Amazon.com, gdzie uzyskamy darmowy klucz dostępu uprawniający nas do nawią­ zywania połączeń z oferowanymi usługami.

Listing 10.25. Plik właściwości accesscontrol/src/java/com/corejsf'/messages.properties 1

t u l e = U w i e r z y t e l m a m e z a k o ń c z o n e pom ys ł m e

2

youHaveAccess=Masz teraz dostęp do info rm acji chronionych!

3 4

yOurl)senName=Nazwa użytkownika memberO+Czlonek r o li

DBH javax.servle t.HttpServletRequest ■ String getRenioteUser() (Servlet2.2) Zwraca nazwę aktualnie załogowanego użytkownika (lub wartość nuli, jeśli żaden użytkownik nie jest załogowany).

■ boolean i sUserlnRole(String role) (Servlet2.2) Sprawdza, czy bieżący użytkownik ma przypisaną daną rolę.

Stosowanie usług sieciowych

Największą zaletą usług sieciowych jest ich neutralność językowa. My będziemy uzyskiwali dostęp do using Amazon Web Services z poziomu języka programowania Java, co wcale nie oznacza, że inni programiści nie mogą korzystać z tych usług z poziomu aplikacji tworzonych w językach C++ bądź PHP. Deskryptor w formacie W SD L opisuje usługi w sposób całkowicie niezależny od tego czy innego języka programowania. Na przykład definicja w formacie W SD L usługi Amazon E-Commerce Service (dostępna w intemecie pod adresem http://webserviees. ^a m a zo n . com/A WSECommerceService/AWSECommerceService.wsdl) opisuje operację

ItemSearch:

Poniżej przedstawiono definicje typów ItemSearch i ItemSearchResponse: Kiedy aplikacja internetowa musi uzyskać informacje z jakiegoś źródła zewnętrznego, z reguły wykorzystuje jakiś mechanizm zdalnego wywoływania procedur. W ostatnich latach naj­ większą popularność w tym obszarze zyskała technologia tzw. usług sieciowych (ang. web

services). Na poziomie technicznym każda usługa sieciowa obejmuje dwa komponenty: ■ serwer, do którego można uzyskiwać dostęp za pośrednictwem protokołu transportowego, np. SO AP (od ang. Simple Object Access Protocol); ■ opis usługi zapisany w formacie W S D L (od ang. Web Service Description

Language). Okazuje się, że z usług sieciowych mogą z powodzeniem korzystać także ci programiści, którzy nie dysponują żadną wiedzą o protokole SO A P i którzy wiedzą naprawdę niewiele o języku W SD L. Aby lepiej zrozumieć ideę usług sieciowych, warto przeanalizować konkretny przykład takich usług: Amazon Web Services (patrz strona internetowa http://www.amazon.com/gp/aws/ ^landing.html). Usługi Amazon Web Services umożliwiają programiście nawiązywanie komunikacji z systemem witryny Amazon.com w rozmaitych celach. Możemy na przykład uzyskać listę wszystkich książek napisanych przez danego autora, odnaleźć publikacje, których tytuły pasują do danego wzorca, lub wypełnić koszyk i złożyć zamówienie.



466

JavaServer Faces

Rozdziano. ■ Usługi zewnętrzne

Istnienie wiele technologii oferujących warstwę programowania w Javie ponad popularnym protokołem SOAP. Jeśli zdecydujemy się użyć technologii JA X -W S, operacja ItemSearch przyjmie postać wywołania metody: void itemSearcd(String marketP1aceDomain. String awsAccesshey 1d String subscript i on]d. String associateTag. String xmlEscapmg String validate. [temSearchRequest shared L i st request Holder opHolder. Holder> responseHolder)

Obiekt port tłumaczy dany obiekt Javy na komunikat protokołu SO AP, przekazuje gotowy komunikat na serwer firmy Amazon, tłumaczy komunikat zwrotny na obiekt klasy 1temSearch ^Response i umieszcza ten obiekt we wskazanym obiekcie opakowania (w tym przypadku responseHolder).

E § | O p u b lik o w a n a p rz e z f ir m ę A m a z o n d o k u m e n t a c ja p a r a m e t r ó w i z w r a c a n y c h w a r t o ś c i

■Hal j e s t

w y ją tk o w o

ry m e n to w a ć P lik W S D L n ie o p i s u j e d z ia ła ń p o d e jm o w a n y c h p r z e z d a n ą u s łu g ę —

o k r e ś la w y łą c z ­

467

p o b ie ż n a i n ie k o m p le t n a . O k a z u je s ię je d n a k , ż e m o ż e m y e k s p e ­

z f o r m u la r z a m i n a

s tr o n ie

http://awszone.com/scratchpads/index.aws,

a b y z a p o z n a ć s ię z ż ą d a n ia m i i o d p o w ie d z ia m i p r o t o k o łu

S O A P . N a t e j p o d s t a w ie

m o­

ż e m y s ię d o m y ś la ć , k t ó r e w a r t o ś c i p a r a m e tr ó w b ę d z ie m y m u s ie li p r z e k a z y w a ć n a s e r w e r

n ie t y p y p a r a m e t r ó w i z w r a c a n y c h w a r t o ś c i.

■' ______________

Typ parametru 1temSearchRequest zdefiniowano w następujący sposób:
Kolejnym krokiem powinno być wywołanie metody getAWSECommerceServicePort: AWSECommerceServicePortType port = service.getAWSECommerceServicePortt);

Aby wygenerować plik JA R z wymaganymi klasami „artefaktów klienta” , należy wykonać następujące polecenia: g la s s f i s/?/bin/wsimport -p com.corejsf.amazon

Powyższy opis jest tłumaczony na następującą klasę Javy: public class ItemSearchRequest { public ItemSearchRequest() { ... } public String getActorO { .. } public void setActor(String newValue) { publ1C String getArtist( ) { } public void setArtist(String newValue) p u b lic

S trin g

getA uth or()

{

http://webservi ces.amazon.com/AWSECommerceServi ce/AWSECommerceServi ce.wsdl jar cvf aws.jar com/corejsf/amazon/* class

Gotowy plik JA R należy umieścić w katalogu WEB-INF/lib naszej aplikacji JSF. .. }

Przed kompilacją klasy AuthorSearchBean należy dołączyć do ścieżki do klas pliki glassfish/ {

}

{

I

^lib/appserv-ws.jar, glassfish/Hb/appserv-ws.jar oraz aws.jar.

}

public void seiAuthor(String newValue)

H H

C z y t e ln ic y k o r z y s t a ją c y z s e r w e r a T o m c a t ( z a m ia s t z s e r w e r a G ła s s F is h ) m u s z ą

■ n i l p o b r a ć p a k ie t J a v a W e b S e r v ic e s D e v e lo p e r P a c k (J W S D P ) z e s t r o n y in t e r n e t o w e j

public List getResponseGroupi)

{

}

http://java.sun.com/webservices/jwsdp

i n a s t ę p n ie g o z a in s t a lo w a ć . S z c z e g ó ło w y c h

in f o r m a c ji n a t e m a t p a k ie t u J W S D P n a le ż y s z u k a ć w je g o d o k u m e n t a c ji.

public void setSearch[ndex(Strmg newValue) {

}

Nasza przykładowa aplikacja jest bardzo prosta. Użytkownik wpisuje w polu tekstowym nazwisko autora i klika przycisk Przeszukaj (patrz rysunek 10.23). Wywołanie usługi przeszukującej wymaga od nas skonstruowania obiektu klasy ItemSearch ^Request i wywołania metody ItemSearch obiektu port: [temSearchRequest request = new I temSearchRequestO . request getResponseGroupt) ,add("1temAttributes"). request setSearchindexCBooks"). ho

1der
resp onseH older

= new H o l d e r < n s t < l t e m s » ( ) .

req u est,setA u tho r(n am e );

port.itemSearchC". accessKey,

request, null, null, responseHolder);

Pierwszą stronę odpowiedzi prezentujemy w ramach tabeli danych (patrz rysunek 10.24). Przedstawiona tabela dowodzi, że próba odwołania do interesującej nas usługi sieciowej zakończyła się pomyślnie. Rozszerzenie funkcjonalności tej aplikacji pozostawiamy Czytel­ nikom zainteresowanym samodzielnymi eksperymentami.

468

JavaServer Faces

Rozdziano. ■ usługi zewnętrzne Aplikacją JSF

Rysunek 10.23.

ffik

Przeszukiwanie książek według podanego nazwiska autora

przystający^ Widok

Historia

vei firmy Amazoj

__

Zakładki

Narzędzia

a Fïrefox

¡ 3 a m a z o n .w a r f U 3 M ETA -IN F j : D M A N IFES T. M F f S 3 W EB -IN F ; f C 3 c la s se s j i f E 3 com : ; f C 3 c o re js f j ; Q A u th o r S e a r c h B e a n . c la s s

Rysunek 10.25.

Pomoc

Struktura katalogów aplikacji ilustrującej działanie usług sieciowych

http://localhost:8080/amazon/index.1 ! ▼

P rzeszukiw anie książek oferow an ych przez A m azon .com w ed łu g nazw iska au tora :LfLz®!?.uh®Li

Autor!Lewis Carroll

;

[ j m e s s a g e s , p ro p e rtie s

j ? C3lib Q

a w s .ja r fa c e s -c o n fig .x m l

'

Q

w e b .x m l

Q

in d e x, htm l

j

j

j

;

i i

ą,

A p ifa q *1ST

Puk

Édycja

7 7 I L I Z L ..... Widok

Historia

Zakładk.

Narzędzia

-y: &

Pomoc

3 8

http://localho5t:808Q/amazon/¡nc)ex.faces

j i 1

G low n y * autor

,_en i." a ■ i'Ti

|

T

.

W y d a w ra

I la k e 's Adventure? in Wonderland a K-p-up Adaption !

Items, C a rr 11 ¡Thr Ann-rated Alice Alice's adventures in Wonderland & Through the L-oking Glass t e r n s ■"arioil ¡adice's Adventures in Wonderland & Through the Looking Glass iLrw i? Carroll ¡The Ann--rated Alire The Definitive Edition

Little Simon F andotn House Value Publishing

D ata

A H ';- [fl

1003.08-28

Signet Class« s

2nno- U - » l

"W W

lo o o /ii

Morton & Gompanv

¡Lewis Gan -11 iAlice in Wonderland

Grarr«=rry

¿r'04-nO-O7

¡Lems C anvil ¡Lem? r ‘anvll Itie Complete, Fully Illustrated W orks, Deluxe Edition iLiterarv Classics i

Gramere V

100*-. .8- 3u

¡Lewis Carroll ¡S v m lo k Logic and the Game of Logic

P'ovei Public anons

1058-OL-0]

k

Alic e’s adventures in Wonderland & Through the Looking Glass and Whai a it e Found

11 12 13 14

•wydania

¡Lewis Carroll ¡¡Lewis Carroll's Garnes and Puzzles

Dover Publications

1992-03-27

package com.corejsf; import java.u til.L is t; import javax.xml.ws.Holder; import javax.xml.ws.WebServiceRef;

c o r e js f amazon 1temSearcnRequest. c o r e js f amazon Items

p u b lic c la s s AuthorSearchBean {

p r iv a te S t r in g accessKey.

22

1. 2. 3. 4. 5. 6.

import com import com

private L 1SL response.

21

Listing 10.26. Kod komponentu amazon/src/java/com/corejsf/AuthorSearchBean.java________________________

import com .corejsf amazon AwSECommerceService. import com c o r e js f amazon AwSECommerceServicePortType. import com c o r e js f amazon item

20

104-Â 10-fi]

Kod klasy komponentu wywołującego usługę sieciową przedstawiono na listingu 10.26. W wyniku wywołania usługi sieciowej otrzymujemy obiekt klasy ItemSearchResponse. Zachowujemy ten obiekt na później, aby strona result.jsp mogła go użyć podczas wyświetla­ nia tabeli z danymi.

b u ild p ro p e rtie s

AwSECommerceService/AwSECommerceService wsdl") br i vate AwSECommerceService service.

2003-04

Na rysunku 10.25 przedstawiono strukturę katalogów tej aplikacji. Warto zwrócić szczególną uwagę na plik JA R w katalogu WEB-INF/lib.

re s u lt js p

Q

Pw eb Se rvice R ef(w sd lLo ca tio n = "n ttp //webservices.amazon com/

Gros sei & Dunlap

Rysunek 10.24. Wyniki przeszukiwania

Q

16 1/ 18 19

Penguin Books

'

e rro r.js p in d e x js p

15

¡Lewis Cartoll jA k e in Wonderland and Hirough the L-dong Glass (illustrated jurnoi Librarvj

Lotni] j

Q Q

7 8 9 10

W yniki przeszukiw ania

1D

23 24 25. 26 27 28. 29. 30. 31. 32. 33 34. 35. 36. 37 38 39. 40. 41. 42 43 44. 45.

p r iv a te S t r in g name.

public String getNameO { return name, } public void setName(String newValue) { name = newValue; } public void setAccessKey(String newValue) { accessKey = newValue; } public String searchO { try { AwSECommerceServicePortType port = service.getAWSECommerceServicePortO, ItemSearchRequest request = new ItemSearchRequest(); request.getResponseGroupO .addC'ItemAttributes"); request.setSearchIndex("Books"), request.setAuthor(name); Holder> responseHolder = new Holder
469

470

JavaServer Faces 46 47. 48 49 50 }

} } public List getResponseC) { return response: }

Warto jeszcze zwrócić uwagę na sposób, w jaki ustawiamy klucz dostępu w pliku konfigu­ racyjnym faces-config.xmI (patrz listing 10.27). W e wspomnianym pliku musimy oczywiście ustawić klucz, który otrzymaliśmy w procesie rejestracji.

Listing 10.27. Plik konfiguracyjny amazon/web/WEB-INF/faces-config.xml 1 2. 7 8. /index.jsp 9. 10. success 11 /result.jsp 12. 13. 14 fai1ure 15. /error jsp 16. 17. 18. 19. /result.jsp 20. 21 back 22. /index.jsp 23. 24 25. 26 /error jsp 27 28. conti riue 29 /index.jsp 30. 31 32. 33. 34. authorSearch 35. com.corejsf AuthorSearchBean 36 session 37 38. accessKey 39. XXXXXXXXXXXXXXXXXXXX 40 41 42. 43. 44.

Rozdział 10. ■ Usługi zewnętrzne 45. 46 47. 48 49.

471

com.corejsf,messages msgs

Na listingach od 10.28 do 10.30 przedstawiono kod stron JS F naszej przykładowej aplikacji. Strona result.jsp obejmuje tabelę z danymi reprezentowanymi przez obiekt response (zwró­ cony przez usługę przeszukiwania).

Listing 10.28. Kod strony amazon/web/index.jsp 1. 2. <^G taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. <%G taglib uri="http://java.sun.com/jsf/htrnl" prefix="h" %> 4. 5 6. 7. 7 8. 9 10. 11. 13 14 15. 16 17. 18 19 20. 21. 22

472

Rozdziano. ■ Usługi zewnętrzne

JavaServer Faces 23 24 25 26 27. 28 29 30 31 32 33 34. 35 36 37 38 39. 40 41 42.



Listing 10.30. Kod strony amazon/web/error.jsp 1. 2 3. 4 5. 6 7 8 9. 10. 11 12. 13 14 15 16 17 18.

<£@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%G taglib uri="http://java.sun.com/jsf/html" prefix="h" %>

I wreszcie na listingu 10.31 przedstawiono pakiet komunikatów.

Listing 10.31. Plik komunikatów amazon/src/java/com/corejsf/messages.properties 1. 2. 3. 4 5. 6. 7. 8. 9 10

title=Aplikacja JSF korzystająca z usługi sieciowej firmy Amazon authorSearch=Przeszukiwanie książek oferowanych przez Amazon.com według nazwiska autora author=Autor format=Format search=Przeszukaj searchResult=Wyniki przeszukiwania internalError=Błąd wewnętrzny internalError_detail=lAlystąpił błąd wewnętrzny. \ Prosimy zgłosić usterkę naszym konsultantom technicznym. continue=Kontynuuj

11 12. 13 14. 15.

473

authorl=Główny autor title=Tytuł publisher=Wydawca pubdate=Data wydania back=Cofnij

Wiem y już, jak nasze aplikacje internetowe mogą nawiązywać połączenia z takimi usługa­ mi zewnętrznymi jak bazy danych, katalogi i usługi sieciowe. Poniżej przedstawiono kilka najważniejszych wniosków płynących z naszych doświadczeń, które warto mieć na uwadze podczas samodzielnych eksperymentów: ■ Pliki JA R należy umieszczać albo w katalogu WEB-INF/lib aplikacji internetowej, albo w katalogu bibliotek serwera aplikacji. Drugie rozwiązanie jest uzasadnione wyłącznie w przypadku bibliotek wykorzystywanych przez wiele aplikacji, np. w przypadku sterowników JD BC . ■ Serwery aplikacji z reguły ofemją swoim użytkownikom gotowe usługi umożliwiające składowanie połączeń z bazą danych w puli, mechanizmy domen uwierzytelniania itp. Przykładem wygodnego i przenośnego mechanizmu lokalizowania klas niezbędnych do uzyskiwania dostępu do tych usług jest wstrzykiwanie zależności. ■ Parametry konfiguracyjne można definiować w plikach konfiguracyjnych facesconfig.xml lub web.xml. Pierwszy z tych plików powinien definiować parametry właściwe tylko dla danej aplikacji internetowej; drugi jest właściwym miejscem dla definicji parametrów określanych w czasie wdrażania.

474

JavaserverFaces

11 AJAX Programiści aplikacji internetowych od niepamiętnych czasów są zmuszani do przetwarzania danych formularzy w warunkach braku mechanizmów niezbędnych do zapewniania poziomu interaktywności znanego z tradycyjnych aplikacji autonomicznych. Dopiero kiedy firma Google pokazała całemu światu usługę Google Maps, okazało się, że aplikacje internetowe mogą oferować na tyle bogate interfejsy użytkownika, aby skutecznie konkurować z aplika­ cjami autonomicznymi. Usługa Google Maps dodatkowo wywołała falę innowacji, której efekty już w niedalekiej przyszłości będą decydowały o sposobie pracy całego środowiska programistów aplikacji internetowych. W tym rozdziale dokonamy analizy części spośród tych innowacji na przy­ kładzie aplikacji JS F zbudowanej na bazie technologii A JA X (od ang. Asynchronous Java­ Script a n d XM L ) i oferującej bogaty interfejs użytkownika. Przy okazji zostaną omówione następujące zagadnienia: ■ podstawy techniki A JA X ; ■ metody implementacji techniki A JA X za pomocą serwletów w ramach aplikacji JSF; ■ stosowanie mechanizmów nasłuchiwania faz JS F na potrzeby bardziej złożonych scenariuszy korzystania z techniki A JA X ; ■ uzupełnianie danych formularzy i weryfikacja w czasie rzeczywistym; ■ uzyskiwanie dostępu do stanu interfejsu użytkownika z poziomu wywołania techniki A JA X ; ■ zapisywanie stanu klienta w aplikacjach zbudowanych na bazie techniki A JA X ; ■ biblioteka Direct Web Remoting; ■ opakowywanie mechanizmów A JA X w ramach komponentów JS F ; ■ stosowanie frameworku Ajax4jsf.

476

Rozdziani. ■ AJAX

JavaServer Faces

Poniżej przeanalizujemy sposób działania tego mechanizmu. W pierwszej kolejności defi­ niujemy początkowo pusty element di v. Wewnętrzny kod H TM L tego elementu aktualizujemy dopiero po wygenerowaniu żądania. Element di v wraz z przyciskiem wprawiającym cały ten mechanizm w ruch przedstawiono poniżej:

Podstawy techniki AJAX A JA X jest w istocie prostym, trzyetapowym procesem: 1.

477



Wywołanie adresu U R L z poziomu kodu języka JavaScript wykonywanego po stronie klienta.

2. Obsługa tego wywołania po stronie serwera i sporządzenie odpowiedzi.

3. Integracja tej odpowiedzi z modelem DO M (od ang. Document Object Model). Opisana procedura jest niemal identyczna jak w przypadku obsługi przez aplikację JS F zdarzenia kliknięcia przez użytkownika łącza, także powodującego powstanie żądania. Apli­ kacja JS F obsługuje to żądanie po stronie serwera, by ostatecznie zapisać odpowiedź zastę­ pującą odpowiedź na poprzednie żądanie. To samo (oprócz ostatniego kroku) dotyczy żądań A JA X . Najważniejsza różnica polega na tym, że żądania A JA X nie wymagają odświeżania całych stron, a jedynie aktualizacji ich części. Ta z pozoru nieduża zmiana umożliwia nam wykonywanie takich operacji związanych z interakcją z użytkownikiem, o jakich nawet się nie śniło twórcom tradycyjnych aplikacji internetowych.

Warto zwrócić uwagę na typ tego przycisku, czyli button — oznacza to, że mamy do czynienia ze zwykłym przyciskiem, a nie przyciskiem zatwierdzania formularza. Kiedy użytkownik naciska przycisk, aplikacja JS F nie wysyła na serwer formularza otaczającego ten przycisk, tylko wywołuje funkcję showDaleAndT i niejęzyka JavaScript, której kod przedstawiono poniżej:
showDateAndTimel) { sendRequest("d ateA n d T im e.ajax ". // adres URL processAjaxCal 1 ). / / funkcja zwrotna

fun ctio n

\

Aby zilustrować kolejne kroki w ramach procesu przetwarzania żądania A JA X , warto rzucić okiem na aplikację przedstawioną na rysunku 11.1.

Rysunek 11.1. Prosty przykład użycia techniki AJAX łącznie z obiektem XHR i serwletem

sendRequest(url. h an d ler) { i nitXHR().

fun ctio n

xhr onreadysia techange = h and ler. ^

Podstawy techniki MAK - Moziita Firefcx

■£tlk

Edycja

Widok

Historia

Zakładki

xhr operą Narzędzia

Pomoc

-

- htqj^/ioc3ir»osfc8080/basic- { T 1 ^

ÍP r z y k ła d u ż y c ia t e c h n ik i A J A X

'i*'

łą c z n ie z s e r w le t e m

0

xhr send Cnu 11).

Jffjl

¡

fun ctio n

| Wyświetl aat§ i godzmf... i

Plik

//

wysyła żądanie bez parametrów

\

initXHRO {

i f ( wl hdOw. XMLHt ipReques t ) { // xhr = new XM LHttpRequestO . 1

Podstawy techniki AJAX - Moziíta Rrefox Edycja

lA * * l | l " j.~_. . «

Widok

Historia

Zakładki

Narzędzia

Pomo£

"

{c d Ü !

."y?

I

I

.'O-

1 ■■ http://localhost:8080/basic- L

--------

— -------------

/ / ustawia funkcję zwrotną

"GET". ur 1. t n u e ). / / otwiera asynchroniczne żądanie GET

J j ¡ ¡ ¡ ( E t ] Google fi^ j --------- --- ............................ .

Zakończono

PWyświetl datę 1godzinę... i

przeglądarka innego producenta niż Microsojt

} e 1Se 1f (wi ndow. Act I veX O b je ct) { / / przeglądarka firmy

Microsoft

xhr - new A c t iveX O b jec t( " M ic r o s o f t .XMLHTTP").

} 1 function processAjaxCal1() { i f (xhr. readyState == 4) { / /jeśli przetwarzanie danego żądania zostało zakończone... i f ( xhr. status == 200) { //.../' nie wykryto żadnych błędów

Uzyskujemy element div i konfigurujemy / / go z wykorzystaniem tekstu odpowiedzi. //

M o n D e c 0 4 1 8 :5 9 :5 2 M S T 2 0 0 6

var dateDiv = wmdow.document .getElementByldC'dateDlV") dateDiv.innerHTML = xhr.responseText; } Zakończono

Aplikacja przedstawiona na rysunku 11.1 wykorzystuje żądanie A JA X do uzyskania od serwera bieżącej daty i godziny. Aplikacja integruje następnie uzyskane odpowiedzi w ramach modelu DOM na stronie internetowej (już po stronie klienta). Taki krok powoduje aktualizację daty bez konieczności odświeżania całej strony.

Funkcja showDateAndTime wywołuje metodę sendRequest(), która z kolei lokalizuje niezbędny obiekt klasy XMLHttpRequest (znany też jako obiekt X H R ) za pośrednictwem funkcji i ni tXHR.

478

JavaServer Faces

Rozdziału. ■ AJAX

Kiedy już będziemy dysponowali obiektem X H R , będziemy gotowi do dalszych kroków. W pierwszej kolejności ustawiamy metodę processAjaxCall O w roli funkcji zwrotnej obiektu X H R , po czym otwieramy i wysyłamy żądanie. W trakcie przetwarzania wywołania A JA X obiekt X H R będzie wielokrotnie wywoływał naszą funkcję zwrotną, przekazując za jej po­ średnictwem komunikaty o postępie procesu realizacji żądania. Praktyka pokazuje, że programiści aplikacji internetowych są zainteresowani przede wszystkim reagowaniem na żądania A JA X już po ich pomyślnym przetworzeniu (jak w przedstawionym przykładzie). W ciele naszej funkcji zwrotnej sprawdzamy, czy otrzymano kod właściwy dla pomyślnie przetworzonego żądania, czyli readystate == 4 i status == 200. Kody stanów są zgodne z kodami znanymi z protokołu HTTP, zatem wartość 200 reprezentuje prawidłowe przetworzenie żądania. Po pomyślnym zakończeniu przetwarzania wywołania A JA X ustawiamy tekst odpowiedzi w wewnętrznym kodzie języka H T M L naszego elementu div. Wspomniana odpowiedź jest generowana przez serwlet: public class AjaxServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServietException, IOException { response.setContentType("text/plai n"); response.setHeader("Cache-Control", "no-cache"); response.setStatus(HttpServletResponse.SC_0K); response.getWriterO .write(new java.util .DateO .toStringO) ;

Przedstawiony serwlet jest związany z adresem U R L dateAndTime.ajax skonfigurowanym w deskryptorze wdrożenia (wiążącym wszystkie adresy U R L kończące się rozszerzeniem .ajax właśnie z serwletem AjaxServl et). m ... m m s a i z u Z d a r z a s ię , ż e m r lie j d o ś w ia d c z e n i p r o g r a m iś c i s ą p r z e k o n a n i, z e t e c h n ik a A J A X ■ M l o g r a n i c z a o b c i ą ż e i r i le s e r w e r a t y l k o d l a t e g o , ż e o f e r u j e b a r d z i e j r o z b u d o w a ć f e js u ż y t k o w n ik a ( p o s t io n i e k lie n t a ) . W p r a k t y c e a p lik a c je b u d o w a n e n a b a z ie i n o lo g ii z r e g u ły g e n e r u ją w ię k s z e o b c ią ż e n ie s e r w e r a , p o n ie w a ż k a ż d e ż ą d a n i w ią ż e s ię z k o n ie c z n o ś c ią o d w o ła n ia d o o p r o g r a m o w a n ia d z ia ła ją c e g o p o s t r o fi i e s e r P U

w e r a . Z d r u g i e j s t r o n y , p o n i e w a ż t e g o r o d z a j u ż ą d a n i a m a j ą c h a r a k t e r a s y n c h r o ► n ic z n y , A J A X s p r a w i a w r a ż e n i e t e c h n o l o g i i p r z e n o s z ą c e j o b c i ą ż e n i e n a s t r o n ę i n t e r f e j s >u u ż y t k o w n ik a i o d c ią ż a ją c e j s e r w e r .

/

. p,.í........

Biblioteki języka JavaScript W poprzednim podrozdziale zaimplementowano blisko 30 wierszy kodu języka JavaScript ilustrującego najprostszy z przypadków użycia techniki A JA X . Przedstawione rozwiązanie jest dość uproszczone i nie uwzględnia dość oczywistych ograniczeń występujących po stronie przeglądarki internetowej.

479

Aby ograniczyć ilość kodu języka JavaScript niezbędnego do obsługi żądań A JA X i aby zagwarantować prawidłowość przetwarzania tych żądań przez rozmaite przeglądarki interneto­ we, powinniśmy użyć którejś z bibliotek języka JavaScript oferujących gotowe implementuje szczegółowych rozwiązań i udostępniających swoim użytkownikom wygodne obiekty.

Biblioteka Prototype W dalszej części tego rozdziału będziemy się posługiwali biblioteką Prototype języka Java­ Script, której mechanizmy znacznie upraszczają proces operowania na wywołaniach A JA X . Prototype jest popularną biblioteką oferującą między innymi wbudowaną obsługę techniki A JA X . Poniżej jako przykład przedstawiono odpowiednik fragmentu kodu języka JavaScript z poprzedniego podrozdziału opracowany z wykorzystaniem biblioteki Prototype: function showDateAndTime() { new Ajax. Updater ( "d a te D IV ", // aktualizowany element div "d a teA n d T im e.ajax ",

//

{ method • "g e t" } ) ,

//

adres URL metoda protokołu HTTP

ł }

W przedstawionym fragmencie kodu języka JavaScript wykorzystano obiekt Ajax.Updater biblioteki Prototype do wykonania wywołania A JA X i (już po jego wykonaniu) aktualizacji wewnętrznego kodu H T M L elementu dateDIV. Warto podkreślić znaczne ograniczenie ilości kodu w porównaniu z listingiem z poprzedniego podrozdziału — konstrukcję złożoną z 30 wierszy udało się zastąpić kodem zaledwie dwuwierszowym. Oznacza to, że użycie biblioteki Prototype nie tylko umożliwiło nam blisko 94-procentową redukcję kodu, ale też zagwarantowało możliwość wykonywania tego kodu na wszystkich przeglądarkach inter­ netowych. Mamy więc do czynienia z wprost doskonałym zwrotem inwestycji. Więcej informacji na temat biblioteki Prototype można znaleźć na jej stronie domowej pod adresem http://www.pro to typejs. org/.

Biblioteka Fade Anything Technique Jedną z pożądanych praktyk w świecie współczesnych aplikacji internetowych jest tworzenie wizualnych wskazówek dla tych obszarów strony internetowej, którą aktualizujemy z w y­ korzystaniem techniki A JA X . Do najbardziej popularnych wizualnych wskazówek należy powolne przechodzenie pomiędzy dwiema barwami tła, zwykle od koloru żółtego do domyśl­ nego koloru tła. Biblioteka Fade Anything Technique obejmuje zaledwie 91 wierszy kodu języka JavaScript, które umożliwiają nam płynną zmianę barw elementów na stronie. Korzystając z tej biblioteki, możemy określać szybkość zmiany kolorów, barwę początkową i docelową oraz czas trwania tego procesu. Biblioteki Fade Anything Technique będziemy używać w pozostałych przykła­ dach prezentowanych w tym rozdziale (wszędzie tam, gdzie wykorzystamy technikę A JA X do aktualizowania elementów na stronie).

480

Rozdziału. ■ AJAK

JavaServer Faces

Uzupełnianie danych formularzy Jednym z prototypowych zastosowań techniki A JA X jest uzupełnianie formularzy, czyli rozwiązanie polegające na automatycznym dostosowywaniu wartości w polach formularza do informacji wpisywanych przez użytkownika w pozostałych polach tego samego formu­ larza. Możemy na przykład użyć techniki A JA X do właściwego reagowania na wartość wpisaną w polu kodu pocztowego (patrz rysunek 11.2).

481

Kjedy użytkownik przenosi kursor poza pole tekstowe kodu pocztowego, wysyłamy na serwer żądanie AJAX obejmujące bieżącą wartość tego pola (w formie parametru żądania). Pole tekstowe kodu pocztowego wiążemy z metodą odpowiedzialną za obsługę tego zdarzenia w następujący sposób:

Funkcja zipChanged wykorzystuje bibliotekę Prototype do wysłania żądania AJAX:

Rysunek 11.2. Uzupełnianie formularza. Pierwszy zrzut: użytkownik wpisał nieznany kod pocztowy; ostatni zrzut: użytkownik wpisał znany kod pocztowy

^ Ü2upeíraa«sedanychformutey ■4Ęp: t:W

techniki AJÄX-

'® ' 0 ffl j >^Ac»lho¡C»OWform-.rnjSI^^^


|

fu n ctio n if(z ip

len g th

!= 5 )

1

{

cleanCityAndStateFieids(). i else 1 new Ajax Request( "zipChanged.ajax" // adres URL { met Rod "get". / / metoda protokołu HTTP parameters "Zip=" + zip. // parametry żądania onComplete processZipCodeSelection. // wywołanie zwrotne

Kod pocztowy ¡61 -298 Miasto

zip C nang ed (zip )

i

Województwo íáüáiiMiJ

}>. 1

2 I1 1 IX IIS S 3 K o d pocztowy ;61 -298 ¡ Miasto

Po zakończeniu przetwarzania żądania biblioteka Prototype wywołuje funkcję zwrotną (wskazaną powyżej za pośrednictwem konstrukcji onComplete). Kod tej funkcji przedstawiono poniżej:

:B R a k Da n y C h

Województwo ¡B R ak Da N^CM

!, yyygJndane, i $

UzupeMmia danych torm ám y z w yk o ay^ m fn tefomfei AIÁX - fóozgła Rrefa* i s j j ^ L - S .

processZipCodeSelection(req) { van cityAndState = req.responseText.spli t ( ' . ' ) . setCityAndStateFields(cityAndState[0]. cityAndState [1]). Fat fade_elemente"form:city " ). Fat fade_element("form;state").

fu n ctio n

Zakcmq |

|

' ■«py/ ' OLí i hc^f m O/fot-r. ¡ K ^ - j ' j i C - V

" *-

f e i'

¿.... K o d pocztowy ¡61-297 ! Miasto W ojewództwo í

| 3

/jfflfc/f

htip.//' <| *

~ W :

JS tS D K S S y ^ T — -yyr—

} function clearCityAndStateFie1ds() { %(" form;city") value = SC'form-.state") value = "". } function setCityAndStateFleidstcity. state) { $(" form c i ty ") val ue = cuy. $ ("form;state") value = state. }

K o d pocztowy ¡61-29? ! Miasto

'Poznan

Województwo ¡Wiel^opoisUe

Ponownie wykorzystujemy w naszym przykładzie bibliotekę Prototype, która pozwala znacznie uprościć niezbędne skrypty języka JavaScript. Największym ułatwieniem jest dostępność obiektu Ajax.Request wykonującego żądanie AJAX oraz flmkcji $ 0 , czyli wyjątkowo w y­ godnego skrótu do funkcji window, document .get Element By Id ().

482

Rozdziani ■ AJAX

üavaServer Faces powyższym fragmencie kodu dodatkowo wykorzystaliśmy obiekt F a t biblioteki Fade Anything Technique języka JavaScript do zmiany koloru tła pól miasta i województwa po aktualizacji ich wartości. W

Adres U RL, który wykorzystaliśmy w wywołaniu A JA X (w tym przypadku zipChanged.ajax), jest obsługiwany po stronie serwera przez serwlet: puD11c c la s s A jd x S e rv ie t extends H ttp S e rv le i

{

483

Aplikacja przedstawiona na rysunku I 1.3 sprawdza poprawność danych wejściowych w czasie rzeczywistym. Kiedy użytkownik wpisuje ostatni, szósty znak kodu pocztowego, wykonu­ jemy żądanie A JA X celem poddania wszystkich sześciu znaków weryfikacji. Weryfikacja w czasie rzeczywistym z wykorzystaniem techmfe AJAX - Moztila

Rysunek 11.3.

Plik

Weryfikacja danych w czasie rzeczywistym

Edycja

Widok

Historia

Zakładki

Naizędzia

Pomoc

http //localhojtiBOSO/realtirr ! r

v Jte|

]¡p

f U

pu blic void d o G et(H ttp ServietR eq u est request. H ttp ServletResp o nse response) throws S e rv le tE x c e p tio n [OException j

! ftirpf H rn fiCh ft- \

response se tC o n te n tT yp e i"te x t/p lain "). response setHeader("Cacne-Control".

"no-cache"),

response setSta tu s( H ttp Serv1etResponse.SC_0k j .

K o 1 p o i zry wy 61 -29ñ

response g e t w r it e r () w rite(getR esp o n seFo rZ ip (req uest.getParam eter("zip") ) ) .

Miasto

B R û k D^ m \ C h

'Województwo BR.ak

1 p riv a te S trin g g etR e sp o n seFo rZ ip (Strin g z ip )

S iS M fJ

{

retu rn "61-297" e q u a ls (Z ip ) ? "Po z nan .W ielk o p olsk ie ’

"BRAK DANYCH.BRAK

Zakończono

DANYCH"

Jeśli nasz serwlet odnajdzie w bazie danych wpisany kod pocztowy, zapisze w odpowiedzi prosty łańcuch w następującym formacie: Mi as to .Województwo. Jeśli odpowiedniego kodu nie uda się odnaleźć w bazie danych, zostanie zwrócony łańcuch BRAK DANYCH. BRAK DANYCH. Po zakończeniu przetwarzania żądania następuje analiza składniowa łańcucha odpowiedzi i takie ustawienie wewnętrznego kodu HTM L pól tekstowych, aby zawierały właściwe warto­ ści. W rzeczywistej aplikacji zapewne posłużylibyśmy się bardziej rozbudowaną bazą danych o kodach pocztowych.

Po stronie serwera uzyskujemy referencję do komponentu reprezentującego pole kodu pocz­ towego, po czym iteracyjnie wywołujemy poszczególne mechanizmy weryfikujące właściwe dla tego komponentu. Jeśli którykolwiek z tych mechanizmów wygeneruje wyjątek, prze­ chwycimy ten wyjątek, umieścimy stosowny komunikat o błędzie w odpowiedzi i przerwie­ my proces przetwarzania żądania. W kolejnym kroku (już po stronie klienta) wyświetlamy odpowiedź z komunikatem o błędzie w ramach elementu div. Na rysunku 11.3 przedstawiono właśnie sytuację, w której użytkownik wpisał błędny kod pocztowy. Odpowiedni kod strony JS P przedstawiono poniżej:

g H

P r z e d s t a w io n y p o w y ż e j p r z y k ła d a u t o m a t y c z n e g o u z u p e łn ia n ia d a n y c h w fo r m u la r z u

U r a l w y m a g a o d p r o g r a m is t y b a r d z o n ie w ie lk ie j w ie d z y o t e c h n o lo g ii J a v a S e r v e r F a c e s —

w y s t a r c z y w ie d z ie ć , j a k

z k o m p o n e n te m

z w ią z a ć f u n k c ję o b s łu g u ją c ą z d a r z e n ia ję z y k a

J S F (z a p o ś r e d n ic t w e m

n ik i b ib lio t e k i z n a c z n ik ó w ję z y k a k lie n tó w

na

p o d s t a w ie

a try b u tó w

F IT M L ) i j a k

is tn ie ją c y c h

J a v a S c r ip t

D H T M L -a o b s łu g iw a n y c h p rz e z z n a c z ­

im p le m e n t a c ja

id e n ty fik a to r ó w

J S F tw o r z y id e n ty fik a to r y

k o m p o n e n t ó w . N a s z p r z y k ła d ja s n o

d o w o d z i, ż e p r o s t e m e c h a n iz m y b u d o w a n e n a b a z ie t e c h n ik i A J A X m o ż n a im p le m e n t o w a ć w

ra m a c h

a p lik a c ji J S F n a w e t w

s y t u a c ji, g d y n ie

d y s p o n u je m y s z c z e g ó ło w ą

w ie d z ą

o s a m e j te c h n o lo g ii J S F .

Weryfikacja w czasie rzeczywistym Z podrozdziału „Uzupełnianie danych formularzy” wiemy, że implementacja w ramach apli­ kacji JS F prostych rozwiązań na bazie techniki A JA X wymaga prostego serwletu i zaledwie kilku wierszy języka JavaScript. W tym podrozdziale zaimplementujemy mechanizm we­ ryfikacji danych pracujący w czasie rzeczywistym, by na jego przykładzie zilustrować bar­ dziej złożone interakcje pomiędzy techniką A JA X a aplikacjami JSF.

< f•view>

484

Rozdziani, n AJAX

JavaServer Faces Zdarzenie onkeyup naszego pola kodu pocztowego związano z funkcją nazwaną zipChanged, którą omówimy za chwilę. Do komponenm kodu pocztowego dodano też niestandardowy mechanizm weryfikujący. Działanie tego mechanizmu ogranicza się do rozpoznawania kodu 61-297; wszystkie inne kody pocztowe są uznawane za nieprawidłowe. Kod naszej strony zawiera też (początkowo pusty) element di v nazwany errors. ' 3. Zakończono od powiedź

Przykład weryfikacji danych wejściowych w czasie rzeczywistym okazał się nieporównanie bardziej skomplikowany od aplikacji omówionej w podrozdziale „Uzupełnianie danych for­ muł arzy” , ponieważ wymaga uzyskiwania dostępu do stanu widoku (drzewa komponentów) naszej strony JSP.

2. writer write{"..O

' 1. iSP wywołuje obiekt nasłuchujący

Powinniśmy też mieć na uwadze konieczność uzyskania referencji do komponentu kodu pocztowego i iteracyjnego przeszukania jego mechanizmów weryfikujących. W tym celu musimy uzyskać dostęp do stanu widoku, co je st możliwe tylko w przypadku żądań POST protokołu HTTP. Właśnie ze względu na to ograniczenie zdecydowaliśmy się stosować żądania PO ST:
ty p e = "ie x t/ jd v d s c rip t"

Przywrócenie p J Stosowanie widoku f i wartości /adama

l a n g u a g e = " J a v a s c n p t 1.1 ">

W yw ołanie


z ipChdngecK Z i p ) 1e n g t h

!= 5)

WerynMqa

{

Aktu¡.Uizacja .Vi I wa•rto ,noś% coi I modelu odeiu I pw

{

m d e E rro rs D i v ( ). retu rn.

Rysunek 11.4. Cykl życia JSF obejmujący wywołanie mechanizmu nasłuchującego fazy techniki AJAX new Ajdx.Request(window.document.forms[0].action. { method "post". Pdrdm eters "ajax=true&zip=" + zip. onComplet e processRealti meVali dati on if

public class AjaxPhaseLi stener implements PhaseLiscener | public Phase 1d getPhaseld( ) { return Phase Id. RESTORE_VIEW. / / interesuje nas włącznie faza przywracania widoku \

public void beforePhase(PhaseEvent pnaseEvent { //

Warto zwrócić uwagę na adres U R L wykorzystany w prezentowanym żądaniu: window ^document. forms [0]. acti on. Wspomniany adres reprezentuje akcję wykonywaną dla jedynego formularza na tej stronie — w ten sposób symulujemy na potrzeby implementacji JS F zda­ rzenie wysłania formularza przez użytkownika. Zdecydowaliśmy się na taki krok, ponieważ chcemy uzyskać dostęp do stanu widoku właściwego dla bieżącej strony, co jest możliwe tylko w przypadku wysłania formularza (ale dopiero po fazie przywracania widoku). Przedstawiony kod pokazuje, jak należy wywoływać określony adres U R L z poziomu klienta, ale w żaden sposób nie wyjaśnia kwestii obsługi tego adresu po stronie serwera. W tym kon­ kretnym przypadku nie możemy użyć serwletu, ponieważ musimy uzyskać dostęp do stanu widoku. Serwlety nie dysponują żadnymi danymi o cyklu życia JS F , stąd nie mogą mieć dostępu do stanu widoku. W tej sytuacji musimy użyć mechanizmu nasłuchującego fazy i obsługiwać żądanie po fazie przywracania widoku (a więc po tym, jak implementacja JS F przywróci drzewo komponentów). Na rysunku 11.4 przedstawiono cykl życia JS F obejmu­ jący obsługę żądania przez mechanizm nasłuchujący. Po zakończeniu fazy przywracania widoku implementacja JS F wywołuje fazowy mechanizm nasłuchujący, który sprawdza (na podstawie parametru żądania), czy mamy do czynienia z żądaniem A JA X ; jeśli tak, mechanizm nasłuchujący weryfikuje poprawność danych wej­ ściowych komponentu, generuje odpowiedź i skraca cykl życia. Wybrane fragmenty kodu klasy nasłuchującej przedstawiono poniżej:

stan widoku nie został jeszcze przywrócony

\

public void afterPhase(PhaseEvent phaseEvent) { FacesContext fc = FacesContext.getCurrentlnstanceO: Map requestParams = fc.getExternalContext0 ,getRequestParameterMap(): String ajaxParam = (String)requestParams.get( "ajax"): ifC true" .equals(ajaxParam)) { //

uzyskujemy referencję do komponentu kodu pocztowego

if(zip != nuli) {

uzyskujemy odpowiedź serwletu i mechanizmy weryfikujące / / komponentu kodu pocztowego //

for (int i = 0: i < validators.1ength: i++) { //

wywołujemy kolejno poszczególne mechanizmy weryfikujące i przechwytujemy ewentualne wyjątki

fC. responseCompl ete(): / / ta odpowiedź nie wymaga dalszych operacji

485

486

JavaServer Faces

Rozdziani. ■ AJAX

W powyższym fragmencie kodu pominięto znaczną część szczegółów implementacyjnych tej metody. Skoncentrowaliśmy się na rozwiązaniu polegającym na podejmowaniu działań przez mechanizm nasłuchujący już po fazie przywracania widoku i po jego automatycznym przetworzeniu przez implementację JS F . Jeśli bieżące żądanie jest żądaniem A JA X (jeśli parametr żądania nazwany ajax ma wartość true), mechanizm nasłuchujący lokalizuje kom­ ponent kodu pocztowego i jego mechanizmy weryfikujące, iteracyjnie przeszukuje te mecha­ nizmy, po czym generuje odpowiedź. I wreszcie nasza metoda wywołuje metodę response ^Complete obiektu klasy FacesContext, aby pominąć pozostałe fazy cyklu życia JSF . Łatwo zauważyć, że mechanizm nasłuchujący skraca cykl życia JS F (pomijając pozostałe fazy) tylko wtedy, gdy zakwalifikuje dane żądanie jako żądanie A JA X . Takie rozwiązanie jest konieczne, ponieważ musimy odróżniać żądania A JA X od pozostałych żądań — skracanie cyklu życia JS F w przypadku pozostałych żądań uniemożliwiłoby prawidłowe funkcjono­ wanie naszej aplikacji. Na koniec (ponownie po stronie klienta) musimy jeszcze przetworzyć otrzymaną odpowiedź: function processRealtimeVali dation(xhr) { var rt = xhr.responseText, if(xhr responseText == "okay") { hideErrorsDiv(), } else { showErrorsDiv(rt), } }

Jeśli tekstem odpowiedzi jest łańcuch okay, możemy być pewni, że wpisany kod pocztowy był prawidłowy, i tym samym możemy ukryć element di v nazwany errors. Jeśli tekst odpo­ wiedzi zawiera jakikolwiek inny łańcuch, wyświetlamy tekst odpowiedzi w ramach wspomnia­ nego elementu di v. B U javax.faces.context.FacesContext

■ void responseCompleteC ) Wymusza na implementacji JS F skrócenie cyklu życia. Po wywołaniu tej metody implementacja JS F nie wykonuje kolejnych faz tego cyklu życia.

487

Propagowanie stanu widoku po stronie klienta Jeśli nasza aplikacja składuje stan widoku po stronie klienta i jeśli jej prawidłowe funkcjo­ nowanie wymaga dostępu do tego stanu, musimy propagować stan widoku za pośrednictwem wywołań A JA X . Jeśli uważnie przeanalizujemy klasę nasłuchującą z poprzedniego przykładu, przekonamy się, że zastosowano tam właśnie mechanizm zapisywania stanu po stronie klienta. Warto zwrócić uwagę na wywołanie funkcji języka JavaScript nazwanej get JSFState: ") . I sty i eC 1ass-="dccord i on" paneiüâss-' accorchonPanel" neaderClass="accord ionPanelHeadec" contente lass="accordioriPanel Content ">

Znaczniki ri co: accordi on oraz ri co: accordi onPanel reprezentują niestandardowe mecha­ nizmy wizualizacji, które wiążemy z komponentami typu UlCommand. Wspomniane mecha­ nizmy generują kod języka JavaScript przystosowany do współpracy z frameworkiem Rico i tworzący komponent tego frameworku.

i

Atrybut sre (który w tym przypadku ma wartość ' r i co -sen p t. js f ') powoduje wywołanie serwera z odpowiednim adresem U R L ( rico-script.jsf ). Wspomniany adres U R L jest obsłu­ giwany przez następującą klasę nasłuchującą: public class AjaxPhaseListener implements PhaseListener { private static final String RICO_SCRIPT_REQUEST = "rico-script". private static final String PROTOTYPE_SCRIPT_FILE = "prototype.js", private static final String SCRIPTACULOUS_SCRIPT_FILE = "scriptaculous.j s " ; private static final String RICO_SCRIPT_FILE = "rico-1.1.2.js"; public Phaseld getPhaseldO { / / w ramach metody afterPhaseQ musimy return Phaseld .RESTORE_VIEW, / / mieć dostęp do stanu widoku } public void beforePhase(PhaseEvent phaseEvent) { // to nasnie interesuje }

public void afterPhase( PhaseEvent phaseEvent) { // po fazie przywracania widoku FacesContext fc = FacesContext,getCurrentInstance(); i f ( ( (HttpServletRequest)fc.getExternalContext() .getRequest( ) ) . getRequestURI() .contains(RICO_SCRIPT_REQUEST)) { try { readAndWriteFiles(fc, phaseEvent, new String[] { PROTOTYPE_SCRIPT_FIL E, SCRIPTACULOUS_SCRIPT_FILE,

496

Rozdzíalll. ■ AJAX

JavaServer Faces RICO_SCRIPT_FILE }); } catch(java.io.IOException ex) { ex.printStackTraceO, } phaseEvent.getFacesContextO .responseCompleteO; } } private void readAndWriteFiles(FacesContext fc. PhaseEvent pe, STring[] files) { //

W czasie wizualizacji komponentu mechanizm odpowiedzialny za ten proces uzyskuje wartości atrybutów znacznika z klasy komponentu, po czym generuje krótki fragment kodu języka JavaScript odpowiedzialny za przekazywanie do skryptu wartości danego komponentu (w tym przypadku przekazujemy nazwę elementu di v wypełnianego przez framework Rico funkcjo­ nalnością harmonijki). Wypełniany element di v początkowo wskazano za pośrednictwem atrybutu name znacznika ric o : accordion: public class AccordionRenderer extends Renderer { public void encodeEnd(FacesContext fc, UlComponent component) throws IOException { ResponseWriter writer = fc.getResponseWriterO:

Odczytuje pliki i zapisuje ich zawartość w odpowiedzi.

//

Jeśli adres U R I żądania zawiera łańcuch rico-script, klasa nasłuchująca fazy odczytuje trzy pliki (prototype.js , scriptaculous.js i rico-1.1.2.j s ), po czym dopisuje ich zawartość do odpowiedzi.

//

Map accordionAttributes = component.getAttributes(); String div = (String)accordionAttributes.get("name"); writer write(""); } public boolean getRendersChildren() { return false; } private void writeAccordionAttributes(ResponseWriter writer, Map attrs) { try {

/ / w tym miejscu należy dodać pozostałe właściwości komponentu harmonijki / / (patrz wiersz 179. w pliku rico-1.1.2.js)

Jeśli zaimplementujemy własne komponenty JS F wykorzystujące technikę A JA X , najpraw­ dopodobniej staniemy przed koniecznością przekazywania wartości atrybutów znaczników (zdefiniowanych w kodzie strony JS P ) do skryptów języka JavaScript zapisanych w odręb­ nych plikach (patrz punkt „Izolowanie kodu języka JavaScript od mechanizmów wizualizacji” ). Przeanalizujmy takie rozwiązanie na przykładzie komponentu harmonijki.

public void setName(Val ueExpression ñame) { / / wywoływana przez JSP this.name = ñame; } protected void setPropertiesdJIComponent component) { / / wywoływana przez JSP component.setValueExpression("name", name);

zapisujemy kodjęzyka JavaScript odpowiedzialny za tworzenie komponentu harmonijki Rico

/ / frameworku

Przekazywanie atrybutów znaczników JSP do kodu języka JavaScript

public class AccordionTag extends UIComponentELTag { private ValueExpression ñame = nuil;

wstawiamy znacznik zamykający ełement dh\ który zainicjowano w metodzie encodeBeginO

writer.write("

"),

Warto wspomnieć, że przedstawionej procedury odczytu plików języka JavaScript można by uniknąć dzięki wskazaniu ich w elemencie script wygenerowanym przez mechanizm wizualizacji komponentu harmonijki; z drugiej strony, takie podejście wiązałoby się z ko­ niecznością trwałego kodowania ścieżek do tych plików. Ponieważ do ładowania plików z kodem języka JavaScript wykorzystano klasę nasłuchującą fazy, możemy składować te pliki w tym samym katalogu, w którym przechowujemy plik wspomnianej klasy, i tym samym wyeliminować potrzebę ich wskazywania w kodzie stron JSP.

Po pierwsze, klasa znacznika komponentu harmonijki udostępnia metody ustawiające i zwra­ cające, które są wywoływane przez strony JS P dla wartości atrybutów ich znaczników. Po przekazaniu wartości tych atrybutów do właściwości implementacja JS F wywołuje metodę setProperties klasy znacznika, która z kolei przekazuje te wartości do odpowiedniego kom­ ponentu:

497

writer.writeC { "); writer ,write(" panel Hel ght: "+ attrs. getCpanelHeight")), writer.writeC } "); } catch (IOException e) { e.printStackTraceO; } i i

Ajax4jsf Skoro opanowaliśmy już techniki implementacji i osadzania komponentów wykorzystują­ cych technikę A JA X w ramach aplikacji JS F , możemy się skoncentrować na frameworku, który zwalnia nas z konieczności zajmowania się tymi szczegółowymi rozwiązaniami, czyli na frameworku Ajax4jsf. Ajax4jsf jest jednym z podprojektów większego projektu java.net — stronę domową fra­ meworku Ajax4jsf można znaleźć pod adresem http://labs.jboss.com/jbossajax4jsf/ (patrz rysunek 11.10). Framework Ajax4jsf oferuje 18 wygodnych znaczników JS P , które można z powodzeniem wykorzystywać do integrowania techniki A JA X z naszymi aplikacjami JSF .

498

JavaServer Faces

Rozdziału. ■ AJAX

Kompletną listę tych znaczników (wraz z niezbędnym omówieniem) opublikowano na wspo­ mnianej już stronie internetowej frameworku Ajax4jsf. W naszym krótkim przeglądzie tego frameworku skoncentrujemy się na dwóch spośród dostępnych znaczników: a4j- s u p p o rt, który umożliwia nam dołączanie funkcjonalności A JA X z komponentem (zwykle kompo­ nentem wejściowym), oraz a4j status, który wizualizuje komponenty JS F na początku i końcu każdego wywołania funkcji A JA X frameworku Ajax4jsf.

Rysunek 11.11. Przykład wpisania nieznanego (dla aplikacji) kodu pocztowego

i Uzupełnianie formularzy za p o m o c ą frameworku Ajax4jsf - MozSMa Firefox j £1* Idycjs Widok Historia Zakładki Narzędzia Pomoc v W/7 • ¿2 i_ http://!oca1hosti808O/ajax4jsf-fr |;» ]

:

Edycja

WtooE

! .

<>

........ i H j

Przykład użycia frameworku Ajax4jsf do uzupełniania ¡formularzy v

i j

Prosimy podać rniejsi e zamieszkania

Mozjiis i-iieioji I Ptrk

499

Historia

* /,s •Ę§ tef du

Zakładki

'

Narzędzia

Pomoc

I I

Lb" j|j4|t

K J pocztowy 61-298 Miasto

BRai DanzCm Uzupełnianie formularzy za pomocy frameworku Ajax4jif - Moziiia firefox .;

j

i wysU) d 5 Pi« ♦

I

Edycja ’

Widok

Historia

Zakładki

f2 I..

®

Narzędzia

Pomoc

http:/Vlocalhost:8080/ajav4jsf-f,i * .

. f

p-j ;jGM _

Zal orczono

? Przykład użycia frameworku Ajax4jsf do uzupełniania i | formularzy 1 Prosimy podać miejsce zamieszkania I | |i

K o cl p c ztow y il l f l l l l ■ Miasto

!

W niewodzrwo

i W ysiij dene j

|)

1 |J Zakończono

poza pole tego kodu (np. za pomocą klawisza Tab). Wykorzystujemy wówczas framework Ajax4jsf do odwołania do techniki A JA X celem określenia, czy kod 61-298 jest rozpozna­ wany, i aktualizacji pól tekstowych miasta i województwa.

Przykład prawidłowego kodu pocztowego

Rysunek 11.10. Strona domowa frameworku Ajax4jsf Aby zilustrować zarówno ogromny potencjał, jak i wady frameworku Ajax4jsf, przebudujemy mechanizmy uzupełniania formularzy i weryfikacji danych w czasie rzeczywistym z po­ przednich podrozdziałów i dokonamy ich ponownej analizy.

f Ifeupeteiatwe fo r m u la r z y z a p o m o c ą fr a m e w o rk u Ajax4jsf -Mazitla F u e lm

Plik. Edycja

Widok

Historia

Zakładki

Narzędzia

'__ K’i.PIS'SS

Q-

Pomoc

ł.ż_j._*fSi iStJ „ 9"

life)

_

Rysunek 11.12.

Przykład użycia frameworku Ajax4jsf do uzupełniania formularzy . Prosimy podać miejsce zamieszkania K od pocztowy 61-29? Miasto

'Po z"ar,

= ■ 'w o dztwo wieiFopoisMe W o y< I Wyątij.dąoe j

Implementowanie mechanizmu uzupełniania danych formularzy z wykorzystaniem frameworku Ajax4jsf Na rysunkach 11.11 i 11.12 przedstawiono przykład działania mechanizmu uzupełniania danych formularza zaimplementowanego z wykorzystaniem elementów frameworku Ajax4jsf. Pierwszy zrzut ekranu widoczny na rysunku 11.11 prezentuje efekt wpisania nieznanego kodu pocztowego (jedynym rozpoznawanym kodem pocztowym jest 61-297) i przeniesienia kursora

Drugi ze zrzutów ekranu przedstawionych na rysunku l l.l 1 pokazuje, jaki będzie efekt przywrócenia kursora do pola tekstowego kodu pocztowego (np. za pomocą kombinacji klawiszy ShifnTab) już po wpisaniu błędnego kodu. Nasza aplikacja usuwa wówczas zawar­ tość pół tekstowych miasta i województwa w oczekiwaniu na nowy kod pocztowy (także tym razem wykorzystujemy framework Ajax4jsf do wywołania A JA X ).

500

JavaSenver Faces

Rozdziału. H AJAX

501

Na rysunku 11.12 przedstawiono zawartość naszego formularza w sytuacji, gdy użytkownik wpisze jedyny kod pocztowy rozpoznawany przez naszą aplikację. W takim przypadku następuje automatyczne wypełnienie pól tekstowych miasta i województwa wartościami właściwym i dla tego kodu. Również tym razem wykorzystano framework Ajax4jsf do wywołania A JA X .

Aktywacja pola tekstowego kodu pocztowego powoduje wygenerowanie przez framework Ajax4jsf wywołania A JA X kierowanego do serwera, który z kolei wywołuje cykl życia JSF. Framework Ajax4jsf wpływa na ten cykl życia i uzupełnia swoje wywołanie o metodę nasłu­ chującą akcji. W roli tej metody wykorzystujemy funkcję setCi tyAndStateForZi p naszego komponentu wspomagającego.

Poniżej przedstawiono kod strony JS P pokazanej na rysunkach 11.11 i 11.12:

Po przeniesieniu kursora poza pole kodu pocztowego framework Ajax4jsf kieruje na serwer kolejne wywołanie A JA X , które także wpływa na cykl życia JS F (także tym razem framework Ajax4jsf dodaje do wspomnianego wywołania metodę nasłuchującą akcji). W roli metody nasłuchującej wykorzystujemy funkcję cl earCi tyAndState komponentu wspomagającego. Implementację tego komponentu przedstawiono poniżej:

<£@ taglib uri="https://ajax4jsf.dev.java.net/ajax" prefix="a4j" %>

package com.corejsf.

import javax.faces.event.ActionEvent,

W kodzie tej strony wykorzystano dwa znaczniki a4j : support do zaimplementowania w y­ wołań techniki A JA X . Oba te komponenty można znaleźć w ramach wejściowego kompo­ nentu kodu pocztowego; jeden z tych znaczników jest wyzwalany przez zdarzenie onbl ur; drugi przez zdarzenie onfocus.

public class BackingBean { private String zip; private String city, private String state. public String getStateO { return state; } public void setState(String state) { this.state = state; } public String getCityO { return city; } public void setCity(String city) { this.city =city; } public String getZipO { return zip. } public void setZip(String zip) { this.zip = zip; } public void clearCityAndState(ActionEvent setCity(""), setStateC""); }

e){

public void setCityAndStateForZip(ActionEvent e) { i f (zip.equals("61-297")) { setCity("Poznan"), setStateC'Wielkopolskie"); } else { setCity("BRAK DANYCH"), setStateCBRAK DANYCH");

Warto zwrócić uwagę na atrybuty reRender znaczników a4j:support. Kiedy wywołania A JA X inicjowane przez framework Ajax4jsf zwracają sterowanie, wykorzystywany framework wizualizuje tylko pola tekstowe miasta i województwa (wymuszając wydobycie odpowiednich wartości od naszego komponentu wspomagającego). Właśnie ten aspekt decyduje o przydat­ ności frameworku Ajax4jsf— istnieje możliwość ponownego wizualizowania części drzewa

komponentów JSF zamiast całego drzewa. Ponieważ framework Ajax4jsf wizualizuje pola tekstowe miasta i województwa, nasz kom­ ponent wspomagający musi tylko zadbać o prawidłową aktualizację odpowiednich właści­ wości (z którymi związano wspomniane pola tekstowe).

502

RozdzialU. ■ AJAX

JavaServer Faces Rysunek 11.14.

Implementacja mechanizmu weryfikacji w czasie rzeczywistym z wykorzystaniem frameworku Ajax4jsf

Skutek wpisania błędnej liczby znaków w polu kodu pocztowego

' % Weryfikacja w czasie toeczyw istym z wykorzystaniem frameworku Ajax4jsf - Mózttte Hf- ' Plik 4 »

Edycja *

-Z

Widok

Historia

- ii?

■

Zakładki

Narzędzia

503

!

Pom oc

¡2 '

iislf'«^

£0

Przykład użycia frameworku Ajax4jsf do weryfikacji w czasie rzeczywistym

Nasz ostatni przykład dowodzik jak łatwe i neutralne może być stosowanie frameworku Ajax4jsf przez programistów aplikacji JSF . Wspomniany przykład byl jednak na tyle pro­ sty, że część Czytelników może wątpić w sens jego prezentacji dopiero teraz i poświęcania czasu na analizę niskopoziomowych szczegółów implementacyjnych techniki A JA X . Dla­ czego od razu nie zajęliśmy się frameworkiem Ajax4jsf, który — jak się wydaje — zwalnia programistę z obowiązku opanowywania wspomnianych szczegółów?

Prosimy podać miejsce zamieszkania Y.

1j

■zt--w v M -8'1

MlaSt- -

!§? Weryfikacja * czasie rzeczywistym z wykorzystaniem frameworku Ajax4jsf - M palla H

.J i...

£.... ^

j w y s iij a l Plik

Problem w tym, że o ile w przypadku tak prostych aplikacji korzystanie z frameworku rze­ czywiście nie wymaga od programisty niemal żadnej wiedzy o technice A JA X , o tyle zna­ jomość tych niskopoziomowych szczegółów okazuje się absolutnie niezbędna w sytuacji, gdy chcemy efektywnie stosować framework Ajax4jsf w ramach bardziej złożonych aplikacji. Przykład weryfikacji w czasie rzeczywistym, który omówiono we wcześniejszej części tego rozdziału i który na poziomie koncepcyjnym idzie o krok dalej względem przykładu uzu­ pełniania danych formularza, jest już na tyle złożony, że jego przebudowa z myślą o użyciu frameworku Ajax4jsf wymaga od nas wykorzystania nabytej dotychczas wiedzy. Realizacja tego zadania nie byłaby możliwa bez dobrej znajomości cyklu życia JS F i łącznego funk­ cjonowania techniki A JA X i technologii JSF. W tym punkcie skoncentrujemy się na analizie implementacji przykładu weryfikacji w czasie rzeczywistym z wykorzystaniem frameworku Ajax4jsf, by na tej podstawie opanować bardziej uniwersalne umiejętności. Na rysunkach 11.13, 11.14 i 11.15 przedstawiono działającą wersję przykładu weryfikacji danych w czasie rzeczywistym, którą opracowano z wykorzystaniem frameworku Ajax4jsf.

Rysunek 11.13. Efekt pozostawienia pustego pola kodu pocztowego

^

Weryfikacja w czasie rceczywistym z wykorzystaniem frameworku Aja*4jsf - Moziłła fir.J c3. iJr* i . Plik

4 i

Edycja

Widok

-

B istom Ż S

!P r z y k ła d u ż y c ia

Zakładki

Narzędzia

L ...., w t

.'

..Pomoc l ’- N

>

1 'i£ H

fr a m e w o r k u A ja x 4 js f d o

^

.......................... i N

w e r y fik a c ji w

| c z a s ie r z e c z y w is ty m

«ś§§ r J f p ' - ^

Historia

Zakładki

Narzędzia

P om oc

;

J___http://lor-ą 11

{^ J ł

* ! p*. 1

Za» o i \ ; i

| Przykład użycia frameworku Ajax4jsf do weryfikacji w i czasie rzeczywistym

| j

Prosimy podać miejsc e zamieszkania b i-:-3 K

1

■ ■

i{.< LZt--wv

M ia sto W - ie w o J z iw - ' i

dane j

Zakończono

Rysunek 11.15. Przykłady wpisania kodów pocztowych złożonych z prawidłowej liczby znaków

CĘj. Weryfikacja w czasie rzeczywistym j wykorzystaniem framejworicu 4jax4jsf Plik

Edycja


Widok

Historia

Zakładki

®

http

Narzędzia lo al

Moeilla Fh ! totoJ3?___ J A . ’

Pomoc

r -

rąOfiO. ja 4| t n

(Ć p t

8 V-

i

O _jł

Przykład użycia frameworku Ajax4jsf do weryfikacji w | czasie rzeczywistym !

;

K

raw-uCrm ’■'Lu/-o—

1[-■ tztowv b> -Z^S

Miast-

Mj

m

mai Ja m cm iia »udu M-dSt

■,rW . -łznVC' D' 3.1 Ci.Jl 1VCl •J 1d 10 a •1!-•I -Z98 | wysiijdane j

tzto w ;

M iast-■‘i jfVo

Widok

Prosimy podać miejsce zamieszkania

1

Prosimy podać miejsce zamieszkania K oJp

Edycja

H? Weryfikacja w czasie rzeczywistym i. wykorzystaniem frameworku Ajax4jj

1ZJVVO 0

Weryfikacja w czasie rzeczywistym z wykorzystańiem frameworku Ą ja x 4 0 - Moz8te F k A i r 3 .! M .i .M _ J

i w y sti) de / Plik

Edycja

Widok

Historia

Zakładki

Narzędzia

Zakończono

\

Plik

Edycja

Widok

Historia

P r z y k ła d

i

u ż y c ia

>nrp--- -żiiiv'r-8ufli.l aja 4jto-r<| ■» | | P j

fr a m e w o r k u A ja x 4 js f d o

c z a s ie r z e c z y w is ty m

Prosimy podać miejsce zamieszkania

Narzędzia

'

. .

M ia sto

u

^

^

■-......-..X ' ■

_____

w e r y fik a c ji w

|

| Przykład użycia frameworku Ąjax4jsf do weryfikacji w | czasie rzeczywistym

|

Prosimy podać miejsce zamieszkania Miasto

poznan dziwo '■o. ie 11-oDo ic i-1e

W oleW odztW '"1 '■

| •iwysiij dane J

i yyysłi) d e n s |

i Zakończono Zakooczooc

J"

.O

Kod pocm>wv |6i -2iP j ztow w

Jk.

Mozitta

Pomoc

\ j

P om oc.

' ®

Zakładki

i i

j j

504

JavaServer Faces

Rozdziału. ■ AJAK

Na rysunku 11.13 pokazano, jaki będzie skutek pozostawienia pustego pola kodu pocztowego i przeniesienia kursora poza to pole (np. za pomocą klawisza Tab). Warto przy tej okazji zwrócić uwagę na wskaźnik zajętości prezentowany w trakcie wykonywania wywołania A JA X i ukrywany po zakończeniu realizacji tego wywołania. Ponieważ pole kodu pocztowego należy do pól wymaganych, w analizowanym przypadku wywołanie A JA X spowoduje wygenerowanie stosownego komunikatu o błędzie (wyświetlanego za pomocą znacznika h:outputText i reprezentowanego przez właściwość errorMessage naszego komponentu wspomagającego). Jak się niedługo przekonamy, wartość właściwości errorMessage ustawiamy w chwili wykrycia błędu przez mechanizm weryfikujący.




immediate znacznika a4j:supportjest niezbędny; gdybyśmy go nie zdefiniowali i gdyby próba weryfikacji zakończyła się niepowodzeniem, w cyklu życia JSF zostałyby pominięte wywołania metod nasłuchujących akcji (nastąpiłoby natychmiastowe przejście do fazy wizualizacji odpowiedzi. —>

Do naszego pola kodu pocztowego dołączyliśmy też niestandardowy mechanizm weryfi­ kujący dane, który sprawdza, czy kod wpisany przez użytkownika jest identyczny jak jedyny kod pocztowy rozpoznawany przez tę aplikację, czyli 61-297. Na rysunku 11.15 widać skutki naruszenia tego ograniczenia, czyli kolejny komunikat o błędzie, który sygnalizuje użytkow­ nikowi niemożność rozpoznania wpisanego kodu (ale nie sugeruje żadnych wskazówek, np. jedynego poprawnego kodu pocztowego). Jeśli kiedykolwiek staniemy przed koniecznością zaimplementowania podobnego pola kodu pocztowego w prawdziwej aplikacji, najprawdo­ podobniej poświęcimy tej kwestii więcej uwagi.



I wreszcie, jeśli użytkownik wpisze prawidłowy kod pocztowy, w nagrodę pola tekstowe miasta i województwa zostaną wypełnione wartościami właściwymi dla kodu 61-297 (jak w przypadku aplikacji ilustrującej działanie mechanizmu uzupełniania danych formularza).



Skoro wiemy już, jak działa nasza przykładowa aplikacja, możemy przystąpić do analizy jej implementacji. Kod jedynej strony JS P przedstawiono poniżej:



taglib uri="https://ajax4jsf dev.java.net/ajax" prefix="a4j" %>

505

< /lrfo rm >



Pierwszym aspektem, na który należy zwrócić uwagę, jest sposób użycia znacznika a4j : status do wyświetlenia wskaźnika zajętości. Możemy dla tego znacznika zdefiniować facety start i stop, by w odpowiedzi na dowolne wywołanie A JA X zainicjowane przez framework Ajax4jsf został wyświetlony komponent facety start. Po zakończeniu realizacji tego wywołania frame­ work Ajax4jsf wyświetla komponent facety stop.

506

Rozdziani. ■ AJAX

JavaServer Faces W prezentowanym przykładzie zrezygnowano z definiowania facety stop, co oznacza, że framework Ajax4jsf usunie ze strony komponent facety start bezpośrednio po realizacji wywołania. Drugim elementem, na który warto zwrócić uwagę, jest definicja pola kodu pocztowego jako elementu wymaganego oraz fakt dodania do tego komponentu wejściowego mechanizmów weryfikacji długości i poprawności kodu pocztowego. Trzecim ważnym aspektem jest sposób zdefiniowania znacznika a4j : support (z wartością true przypisaną atrybutowi immediate) w ramach komponentu kodu pocztowego. Gdybyśmy zrezygnowali z tego rozwiązania, nasza przykładowa aplikacja przestałaby działać. Aby przekonać się, skąd ten wniosek (przyjmijmy, że powyższy fragment kodu nie zawiera od­ powiedniego komentarza), wystarczy przeanalizować implementację naszego komponentu wspomagaj ącego: package com.corejsf; import import import import import

javax faces .event .ActioriEvent, javax faces.context.FacesContext, javax.faces.component.UIInput, javax.faces.application.FacesMessage; java.util Iterator.

public class BackingBean { private String zip; private String city, private String state; private String errorMessage = null; public public public public public public //

String getStateO { return state, } void setState(String state) { this.state = state, } String getCityO { return city, } void setCity(String city) { this.city = city: } String getZipO { return zip, } void setZip(String zip) { this.zip = zip, }

Metoda ustawiająca, zwracająca i usuwająca komunikat o błędzie.

public String getErrorMessage() { return errorMessage, } public void setFrrorMessage(String errorMessage) { this.errorMessage = errorMessage: } public void clearErrorMessage(ActionEvent e) { errorMessage = n u ll, } / / A JA

X

/ * Właściwości citylnput i statelnput są ustawiane za pośrednictwem * atrybutów binding tego komponentu po stronie widoku:

* * *



* */ private Ullnput citylnput = nuli, //citylnput public Ullnput getCitylnputO { return citylnput, } public void setCityInput(UIInput citylnput) { th is .citylnput = citylnput. }

private Ullnput statelnput = nuli. //statelnput public Ullnput getStatelnputO { return statelnput, } public void setStateInput(UIInput statelnput) { th is .statelnput = statelnput, } / * Metoda validateZip jest wywoływana przez framework Ajax4jsf w * na przeniesienie kursora poza pole tekstowe kodu pocztowego:

odpowiedzi

* * * * *



*/ public void validateZip(ActionEvent e) { / / Ponieważ nasza aplikacja działa zbyt szybko, aby użytkownik mógł / / dostrzec wskaźnik zajętości (po stronie widoku), spowalniamy cały proces:

try { Thread.sieep(250); } catch (InterruptedException el) { el.printStackTraceO; } Ullnput input = (UI Input )e.getComponent() / / komponentframeworku Ajax4jsf . getPa rent ( ) , / / komponent wejściowy i f (input != nul 1) { String zip = (String)input.getSubmittedValue(); i f (zip ! = nul 1) { //

ustawia właściwości miasta i województwa zgodnie wartością pola tekstowego kodu pocztowego:

/ / z przesłaną

setCityAndState(zip); //

weryfikuje zawartość pola kodu pocztowego:

FacesContext fc = FacesContext,getCurrentInstance(); i n p u t . v a li d a t e ( f c ) ;

//

iteracyjnie przeszukuje mechanizmy weryfikacji

i f ( ¡input.isValidO) setErrorMessage(fc, input);

*

* * *



Wymusza na implementacji JSF odświeżenie pól wejściowych miasta i województwa. Jeśli przesłana wartość danego komponentu wejściowego jest różna / / od mdl, implementacja JSF nie odświeży tego pola.

//

//

ci tyłnput.setSubmi ttedValue(nul 1);

507

508

JavaServer Faces

Rozdziału. ■ AJAX statelnput.setSubmittedValue(null); }

} private void setErrorMessage(FacesContext fc, UIInput input) { / / przypisuje

właściwości errorMessage pierwszy komunikat dla pola kodu:

Iterator it = fc.getMessages(input.getCiientld(fc)). i f (it.hasNextO) { FacesMessage facesMessage = (FacesMessage)it,next(); errorMessage = facesMessage.getSummary(); } private void setCityAndState(String zip) { String cityAndState = ZipcodeDatabase.getCityAndState(zip), i f (CityAndState != nuli) { // rozpoznano kod pocztowy String[] cityStateArray = cityAndState.splitC,"), setCity(cityStateAmay[0]); setState(cityStateArray[l]); } else { I I nieznany kod złożony z 6 znaków: i f (zip.lengthO == 5) { setCity ("brak danych dla kodu " + zip), setStateCbrak danych dla kodu " + zip); i else { I I nieznany kod złożony z niewłaściwej liczby znaków: setCity(nul 1); setState(nul 1); }

Musimy pamiętać, że znacznik a4j: support dodaje do cyklu życia JS F metodę nasłuchującą akcji. To dość oczywiste, jeśli weźmiemy pod uwagę, że odpowiedni atrybut tego znacznika nazwano actionListener. Okazuje się jednak, że skutki stosowania tego rodzaju metody wcale nie muszą być od razu widoczne. Implementacja JS F weryfikuje wartość naszego komponentu kodu pocztowego mniej więcej w połowie cyklu życia JSF, a konkretnie w fazie weryfikacji. Jeśli proces weryfikacji zakończy się niepowodzeniem, implementacja JS F natychmiast przystępuje do fazy wizualizacji odpo­ wiedzi, czyli ponownego wyświetlenia naszej strony (co jest standardowym zachowaniem aplikacji JS F w razie niepowodzenia weryfikacji). Musimy pamiętać, że sama implementacja JS F nie dysponuje żadnymi informacjami sugerującymi, że ma do czynienia z wywołaniem A JA X , zatem realizuje cykl życia aplikacji zupełnie tak, jakby użytkownik wysłał na serwer formularz obejmujący komponent kodu pocztowego. Jeśli proces weryfikacji w tej fazie zakończy się niepowodzeniem i jeśli wskutek odrzucenia danych wejściowych implementacja JS F przejdzie do fazy wizualizacji odpowiedzi, ewentualne metody nasłuchujące akcji (zwykle wywoływane bezpośrednio przed fazą wizualizacji odpowiedzi) właściwe dla tego wywołania zostaną pominięte. W tej sytuacji definiujemy metodę nasłuchującą akcji z ustawionym atrybutem immediate, aby implementacja JS F wywo­ łała ją już na początku cyklu życia (bezpośrednio po fazie stosowania wartości żądania) i przy­ stąpiła do fazy wizualizacji odpowiedzi. Oznacza to, że gdybyśmy zdefiniowali naszą metodę

nasłuchującą akcji bez atrybutu immediate=true w komponencie a4j: status, nasza metoda nasłuchująca nigdy nie byłaby wywoływana.

509

Skoro opanowaliśmy już podstawy interesujących nas mechanizmów, warto przystąpić do analizy bardziej złożonych, wręcz najeżonych pułapkami aspektów. Warto zwrócić uwagę na wywołanie metody val i date przez naszą metodę nasłuchiwania akcji dla komponentu kodu pocztowego. Jeśli nasz komponent wejściowy zostanie oznaczony jako nieprawidłowy, możemy być pewni, że proces weryfikacji zakończy się niepowodzeniem — w takim przypadku należy przypisać stosowny (wyświetlany następnie za pośrednictwem widoku) komunikat właściwości errorMessage komponentu wspomagającego. Podsumujmy nasze dotychczasowe spostrzeżenia: wykorzystujemy znacznik a4j: support do uzupełnienia cyklu życia JS F o metodę nasłuchującą akcji (wywoływaną po przeniesieniu kursora poza pole kodu pocztowego, kiedy framework Ajax4jsf zainicjuje wywołanie A JA X ). Naszą metodę nasłuchującą akcji, która weryfikuje dane wpisane w polu wejściowym, musimy zdefiniować z atrybutem irnmediate=true, aby implementacja JS F nie pomijała metody nasłu­ chującej w razie niepowodzenia weryfikacji. Warto przeanalizować kolejny element składowy analizowanej układanki: jeśli realizowany przez implementację JS F proces weryfikacji zakończy się pomyślnie dla wszystkich kompo­ nentów wejściowych, wspomniana implementacja przypisze wartość nuli wszystkim spraw­ dzonym komponentom (w miejsce wartości wpisanych przez użytkowników). Jeśli jednak weryfikacja jednego lub wielu komponentów wejściowych zakończy się niepowodzeniem, implementacja JS F pozostawi wpisane wartości w niezmienionej formie. W trakcie ponownego wizualizowania naszej strony (albo w wyniku niepowodzenia wery­ fikacji, albo wskutek braku reguł nawigacji właściwych dla akceptacji formularza) imple­ mentacja JS F sprawdza, czy komponenty wejściowe reprezentują wartości nuli; jeśli tak, następuje ponowny odczyt wartości komponentów. Jeśli jednak wysłane wartości są różne od nul 1 (co jasno wskazuje na niepowodzenie weryfikacji), implementacja JS F nie wypełnia ponownie odpowiednich pól przez odczyt właściwych wartości, tylko ponownie wyświetla wartości wysłane za pośrednictwem ostatniego żądania. W ten sposób implementacja JS F zachowuje błędne wartości w komponentach wejściowych, które spowodowały błędy weryfi­ kacji, co jest w pełni zgodne z naszymi oczekiwaniami. Ponieważ wywołujemy mechanizm weryfikujący ręcznie, wartości wpisane za pośrednictwem naszych komponentów wejściowych nigdy nie są zastępowane wartościami nuli w razie pomyślnej weryfikacji (w przeciwieństwie do sytuacji, gdy weryfikacja jest wywoływana przez implementację JS F ). Oznacza to, że sami musimy podjąć odpowiednie działania, aby po pomyślnej weryfikacji pola tekstowe miasta i województwa zawierały odpowiednio łań­ cuchy Poznań i Wi el kopol ski e. Do tego celu wykorzystamy dowiązania do komponentów, które umożliwią nam wywołanie metody setSubmittedVal ue(nul 1) dla wspomnianych komponentów. Analizowany przykład powinien ostatecznie przekonać Czytelników, że stosowanie frame­ worku Ajax4jsf nie zawsze jest takie proste, jak w przypadku przedstawionej wcześniej aplikacji uzupełniającej dane formularza. Korzystanie z tego frameworku wymaga sporej wiedzy praktycznej o cyklu życia JSF. Programiści zainteresowani stosowaniem tej techniki koniecznie powinni się więc zaopatrzyć w dobrą książkę o JS F — masz szczęście, właśnie trzymasz taką książkę w dłoniach. Musimy też rozumieć, jak framework Ajax4jsf implementuje technikę A JA X . Na przykład znacznik a4j . support tego frameworku nie wymusza końca cyklu życia JS F za pośrednictwem metody responseComplete wywoływanej dla kontek­ stu (w przeciwieństwie do naszych rozwiązań stosowanych wcześniej w tym rozdziale).

510

JavaServer Faces Przeciwnie, różnice względem tradycyjnego cyklu życia ograniczają się do istnienia dodat­ kowej metody nasłuchującej akcji. Warto dobrze ten model zrozumieć i przemyśleć przed pod­ jęciem decyzji o stosowaniu analizowanego frameworku. Aby nasze rozważania były kompletne, poniżej przedstawiono listingi naszego mechanizmu weryfikacji kodów pocztowych i bazy danych kodów pocztowych wykorzystywanej przez komponent wspomagający. Oto kod weryfikujący: package com.corejsf; import com.corejsf.util.Messages: import import import import

javax faces.context.FacesContext; javax.faces.component.UlComponent: javax.faces.validator ValidatorException; javax.faces.validator.Validator,

public class ZipcodeValidator implements Validator { public void validate(FacesContext fc, UlComponent c, Object zip) throws ValidatorException { String cityAndState = ZipcodeDatabase .getCityAndState((String)zip); i f (cityAndState == null) { throw new ValidatorException( Messages.getMessage("com.corejsf.messages", "badZip")),

12 Frameworki open-source Kiedy firma Sun po raz pierwszy wpadła na pomysł opracowania technologii JS F , jej pra­ cownicy liczyli na wsparcie szerokiej społeczności programistów rozwiązań typu open-source (oferowanych z otwartym dostępem do kodu źródłowego). Prace nad tym projektem trwały co prawda dłużej, niż początkowo zakładano, jednak warto pamiętać, że podobny przebieg miały początkowe fazy realizacji takich projektów jak Apache Shale, JBoss Seam czy Facelets. Wymienione projekty open-source (a także projekty realizowane na bazie technologii JavaServer Faces, np. AjaxFaces) nie tylko ułatwiają pracę programistów JS F , ale też kształtują przyszłość tej technologii. W tym rozdziale skoncentrujemy się na trzech najważniejszych innowacjach: ■ przepływie stron internetowych;

Poniżej przedstawiono kod naszej bazy danych: package com.corejsf, public class ZipcodeDatabase { public static String getCityAndState(String zip) { i f ("61-297",equals(zip)) return "Poznań,Wielkopolskie"; else return riul 1;

■ alternatywnych technologiach widoków; ■ integracji z technologią Enterprise JavaBeans (E JB ). Przepływ (obieg) stron internetowych (ang. web flo w ) jest bardziej rozbudowaną wersją domyślnego mechanizmu nawigacji w ramach aplikacji JSF. Stosując mechanizm przepływu stron, możemy dużo łatwiej definiować złożone interakcje z użytkownikami. Począwszy od wersji JS F 1.2 oraz JS P 2.1, różnice wynikające z niezgodności obu technologii zaczęły stopniowo zanikać, zatem programiści zainteresowani łączeniem tych standardów nie powinni obecnie napotykać poważniejszych problemów. Z drugiej strony, mimo tak po­ zytywnych zjawisk wciąż znaczna część społeczności programistów aplikacji JS F oczekuje całkowitego zastąpienia technologii JS P lekkim mechanizmem szablonów. Okazuje się, że technologię JS F zbudowano między innymi z myślą o takim scenariuszu. Czytelnicy, którzy do tej pory nie korzystali z technologii E JB 3.0, mogą być zaskoczeni dojrzałością tego standardu (uważanego niegdyś za jeden z najbardziej nieprzystępnych, a obecnie uważanego za jedną z najważniejszych technologii w świecie aplikacji). Modele komponentów E JB i JS F są niestety niezgodne, co stwarza przestrzeń dla frameworków implementujących zunifikowany model komponentów.

512

Rozdział 12. ■ Framework! open-source

JavaServer Faces W kolejnych podrozdziałach tego rozdziału przeanalizujemy trzy ważne innowacje przez pryzmat trzech implementujących je frameworków typu open-source: Shale, Facelets i Seam.

Przepływ stron WWW— pakiet Shale Twórcy frameworku Struts opracowali też pakiet Shale, czyli zbiór usług pracujących w warstwie ponad warstwą JS F . Pakiet Shale oferuje szereg elementów funkcjonalności, które znacznie ułatwiają codzienną pracę nad aplikacjami JSF : ■ mechanizm przepływu stron W W W ; ■ mechanizm zdalnych wywołań A JA X ; ■ model szablonów i dekorowanych widoków; ■ mechanizm weryfikacji danych po stronie klienta i serwera z wykorzystaniem funkcji Apache Commons Validator; ■ framework testujący z obsługą testów jednostkowych i testów integracyjnych; ■ mechanizm integrujący framework Spring, interfejs JN D I i framework Tiles; ■ kontrolery widoków (konkretną implementację koncepcji komponentu wspomagającego JS F ).

513

tran sitio n outcome="next" target="Yet Another State"/> tra n sitio n outcome="cancel" target="Exit"/>

W powyższym fragmencie kodu (wyodrębnionego z pliku konfiguracyjnego w formacie X M F ) zdefiniowano dialog nazwany Example Dialog z trzema stanami: Starting State, The Next State oraz Exit. Widoczne przejścia określają na potrzeby frameworku Shale sposób nawi­ gowania pomiędzy poszczególnymi stanami — poniżej przedstawiono odpowiednik takiego przejścia w kodzie strony JSP :

Jeśli przedstawiony powyżej dialog znajduje się w stanie The Next State i jeśli użytkownik kliknie przycisk, framework Shale wykorzysta wartość atrybutu outcome (w tym przypadku next) do wyboru kolejnego stanu (w tym przypadku Yet Another State). Drugie z przejść zdefiniowanych dla stanu The Next State określa, że kliknięcie przycisku właściwego dla akcji cancel powinno kończyć dany dialog.

Zaimplementowany w ramach pakietu Shale mechanizm przepływu stron internetowych umożliwia nam tworzenie szeregu interakcji pomiędzy użytkownikiem a naszą aplikacją. Wspomniany zbiór interakcji często jest określany mianem konwersacji z użytkownikiem, dialogu lub kreatora (ang. wizard). W e frameworku Shale obowiązuje określenie dialog, zatem właśnie nim będziemy się posługiwali w tym podrozdziale.

Ten zmyślony naprędce przykład dobrze ilustruje podstawy dialogów frameworku Shale. Na rysunku 12.1 przedstawiono dużo bardziej realistyczny przykład kreatora płatności. Za pośrednictwem tego kreatora możemy dokonać płatności przez internet, a cała procedura składa się z czterech kroków: wpisania informacji o płatniku, wyboru metody płatności, wyboru har­ monogramu płatności oraz podsumowania. Wszystkie te kroki przedstawiono na rysunku 12.1 (począwszy od górnego zrzutu ekranu).

Dialog frameworku Shale składa się z jednego lub wielu stanów. Poszczególne stany obejmują przejścia definiujące sposoby przekazywania sterowania pomiędzy poszczególnymi stanami. Każdy dialog obejmuje też stan specjalny, nazywany stanem końcowym (ang. end state), który przerywa dany dialog i zwalnia jego stan. Przykład definicji dialogu frameworku Shale przedstawiono poniżej:

Warto zwrócić uwagę na pewien specyficzny aspekt tego kreatora. Jeśli z listy rozwijanej metody płatności wybierzemy opcję Przelew bankowy, po czym klikniemy przycisk Dalej, nie zostaniemy skierowani bezpośrednio na stronę Harmonogram płatności (jak w scenariuszu przedstawionym na rysunku 12.1). Zamiast tej strony naszym oczom ukazuje się poddialog odpowiedzialny za zebranie niezbędnych informacji o przelewie bankowym.

tran sitio n outcome="next" target-'The Next State"/> tran sition outcome="cancel" target="Exit"/>

Zmodyfikowaną sekwencję zdarzeń przedstawiono na rysunku 12.2. Warto zwrócić szcze­ gólną uwagę na pierwszy i ostatni zrzut ekranu — oba prezentują dialog zewnętrzny. Drugi, trzeci i czwarty zrzut ekranu ilustrują poddialog odpowiedzialny za zebranie danych o prze­ lewie bankowym. Skoro wiemy już, jak wygląda nasza gotowa aplikacja złożona z dwóch dialogów, jednego zagnieżdżonego w ramach drugiego, możemy przystąpić do analizy kroków składających się na proces jej implementacji.

514

JavaServer Faces

RozdziaM2. ■ Framework! open-source ’H i Dramose rachunku - Mozitta firefox

í¡¡£. Płamost racftufHHi kfozifta firefox Pfłk

Edycja

Widok:

Histona

Zakładki

Narzędzia

Plik

Pom oc

|~ ; ht^Socalhost:808Cl/5hale/start,jjf

Edycja

Widok

Historia

Zakładki

Narzędzia

Pomoc

http;//iocalhor.t:808DMale/billpay/payment/>«rir«Tranafer/wizard.j$f I ^ i ► y ('jSjor!'ic irp:-

I B

Kwota i sposób płatności

Dane i adres płatnika

Pitk

Edycja

Widok

Historia

(u' h.osciubZ^i l r

Miasto

[c.ii....'ce____

•«¡¡jt Płatność rachunku - Mozite Fírefex Ptik

W-.¡^wodzuv'' [Siąs^ip K od pocztowy j44-100

4 *

1

Edycja t

Widok

Historia

' W

i r

f2

I

lpo$oł. płatności Pn-r-ip»- u * " o- . i * i

I ł

Zakładki

Narzędzia

:4 * ł ;i#

' Í P

Ł ,i: t S

1 (Informacje o banku

sób płatności Harmonogram płatności Podsumowanie

]

http://localhost:8880/shala/billp3y/payrrienVwireTran5fer/wizard.jsf j * T

B

s

ö

L

S

Informacje o koncie

Dane kontaktowe

Podsumowanie

Nazwa i adres banku Plik

fedyicia •

; K w o ta płatności |2n00 j Sposob płatności Pizei,-.. i

Widok

0

Historia

1J Natzędzia

tfer Plotko sí £itk

Widok

Płatność cotygodniowa

^¡¡®- r 1

Widok

Historia

* f||j

Zakładki

f i l \ \■

Narzędzia

foT©T^S

http://localho;t:8i)80/shale/billpay/payrnenp'wiieTtansfei/wizard.jsf

jMorawcje o koncie

Dane kontaktowe

Podsumowanie

Zakładki i

Naizędzia

Pomoc

l^p. 10Lo11*'O l-8ub0

Informacje o koncie

P'"p
jDone kontaktowe

l łl ñ

__

Podsumowanie

O

Pomoc

l'ittp://localho;t:8Q80/diale/billpay/paymentywireTran;fer/wizard.j?t

Historia ’Ą i0

Informacje o banku

lilii

Płatność rachunku •Mozife Firefcat, Edycja

~

Pomoc

cacłt««ku - MózKia fi

Edycja * d ß ir »

Płik

5 1 :p

Narzędzia

Informacje o koncie

M f p? j j [ Q f i Ooodie

Informacje o płatności Sposób pfetności {Harmonogram płatności Podsumowanie

* Płatność irdnorazowa

Zakładki

__

Pomoc

http://localho;t:8080/;hale/billpay/paymentA«iteTran:>fer/wizard.|sf

Harmonogram p ł a t t r f

‘Ł ?/

| Moitnaeje o banku

•éáé,

_

Zakładki

C T # ii."

e

Historia

..

■ Clala^ Łl^anin £ Płatność rachunku - Moziłte firefcw

Widok

Ii

^

% i Płatność rachunku -M ońiU Eirefex ■$

Kwota i sposób płatności

i l

M z i ::

I ; »

Dane kontaktowe

II I ;

&

Pomoc

¡ Oaiej j ! Comí, ^ ! Amit

Pomoc

. httpi/docalho.WSOSO/shale/billpay/payment/wiręTransfer/wizard pf ;

informacje o

I

' _PfS J

! {

Narzędzia

p o isi-d

K ra t

Edycja

Zakładki

.r- u i-“

tJlica

P|ik

P_; s i

jf, Ptetoo& rachunku -feffia Flrsfcx

K w o ta płatności j2r"'iu

4>

”J K )

Informacje o płatność [sposób płatności Harmonogram płatności Podsumowanie

Informacje o płatności Sposób płatności Harmonogram płatności Podsumowanie

N azw a

515

Płatność comiesięczna

i Informacje o płatności Sposób płatności ści Harmonogi am płatności jPodsumowanic

|

Odbiorca

\

Telefon odbiorcy

I j j Dsł_ej i i Cotnij i

Anuluj

A dres p o c z ty elektronicznej jjao@ now ak .org

T

Podsumowanie płatności

Dane i adres p łatnika

ij ;

Nazw a

® ’v iawrn»

|

U lica

ui K -scmszio !•'

|

Miasto

>jiwnc

i

W otpw ó dztw ' 'F4SKC

\

K raj

|

K o d pocztow y ¡u ’

11

i

-

¡¡¡Ę, Płatność i-achunku Voziü-r r

I

Plik

Edycja

Widok

1''■^

Historia

"N * ■ ■'

Zakładki

: .te

Henon 1

Informacje o płatności Sposób płatności jHarmooogram płamosci Podsianowaoie

Hannonogram płatności

isfca

® Płatność jednorazowa

Kwota i sposób płatności

Płatność cotygodniowa Płamosr comiesięczna

| K w o ta płatrmsci w - •<*>“' | Sposoł płatności p-ceHw b^nk-.n^;

I;

! Harmonogram plam iści Płatno-' I ip o s o b płatności

II

'l Ę®'1?1 ' ’>51mJ ] i_4nuLui_!

Harmonogrampłatności 1- dn„i-.iz-

Przelew bariKowy

Nazwa i adres banku :

Nazwa..b.aaku i m s u z ú s i s u Zatcczcii'o

Rysunek 12.1. Kreator płatności

Rysunek 12.2. Poddialog przelewu bankowego (tym razem pominięto panel podsumowania)

j

L

l l T

l

516

JavaServer Faces

Rozdział 12. ■ Frameworki open-source

Konfiguracja dialogu

517

Nawigacja w ramach dialogu

Dialogi domyślnie definiujemy w pliku X M L nazwanym /WEB-INF/dialog-config.xml. Po­ nieważ w analizowanym przykładzie wykorzystamy dwa dialogi, zdecydowaliśmy się użyć dwóch plików konfiguracyjnych zadeklarowanych w deskryptorze wdrożenia: org.apache.shale.di alog.CONFIGURATION /WEB-INF/di alogs/payment.xml, /WEB-INF/di alogs/wi re-transfer,xml

Gdybyśmy użyli pojedynczego pliku nazwanego /WEB-INF/dialog-config.xml, nie musieli­ byśmy go deklarować w naszym deskryptorze wdrożenia.

Inicjowanie dialogu

Dialogi Shale domyślnie są definiowane w pliku konfiguracyjnym w formacie X M L. Poniżej przedstawiono definicję dialogu Payment, do którego odwołujemy się w przedstawionym przed chwilą fragmencie kodu: ^transition outcome="success" target="Payee Information"/>

Kolejnym krokiem analizowanego procesu jest zainicjowanie dialogu (wejście w dialog). W naszym przypadku za inicjowanie dialogu będzie odpowiadało specjalne łącze (patrz rysunek 12.3).

Rysunek 12.3.



?J|§ Przykład u|ye
Łącze inicjujące dialog płatności

U

://l o caIho st: 8080/s h aIe/b ¡11p ay/p aym ent/wiza rd .jsf

!» W w W .

Google

Zapłać rachunek.

Bezpośrednio po zainicjowaniu dialogu framework Shale ładuje stan wskazany za pośred­ nictwem atrybutu start elementu dialog. W analizowanym przypadku funkcję stanu począt­ kowego pełni stan akcji (ang. action state) nazwany Setup. Stany akcji wykonują określone metody, po czym natychmiast wymuszają przejście w inny stan (którego wybór zależy od łańcucha zwróconego przez metodę, czyli od tzw. wyniku akcji). Bezpośrednio po zainicjowaniu naszego stanu Setup przez framework Shale następuje wywoła­ nie metody setupPaymentDi al og dla komponentu zarządzanego nazwanego dial ogLauncher. Wspomniana metoda składuje pewien obiekt w zasięgu dialogu (więcej informacji o tej metodzie można znaleźć w punkcie „Zasięg dialogu” ) i zwraca łańcuch wynikowy.

Kod tego łącza przedstawiono poniżej:

Łatwo się domyślić, że framework Shale przypisuje specjalne znaczenie każdej akcji roz­ poczynającej się od łańcucha dialog:. Łańcuch użyty za dwukropkiem reprezentuje nazwę dialogu inicjowanego przez framework Shale w reakcji na kliknięcie danego łącza.

Zwrócenie łańcucha success wymusza na frameworku Shale załadowanie stanu Payee Information, czyli stanu widoku (ang. view state). Dialog w stanie widoku ładuje widok wskazany za pośrednictwem atrybutu view Id i czeka na kliknięcie przez użytkownika przy­ cisku lub łącza, co generuje wynik wykorzystywany przez framework Shale do przejścia do kolejnego stanu. Warto teraz podsumować przedstawiony model: kiedy klikamy łącze dostępne na pierwszej stronie naszej aplikacji, framework Shale ładuje stan akcji nazwany Setup, który z kolei wywołuje metodę dial ogLauncher. setupPaymentDi alog. Metoda setupPaymentDi alog zwraca łańcuch success, co powoduje załadowanie przez framework Shale strony /biłlpay/paymentZ ^wizard.jsp i oczekiwanie na kolejny łańcuch wynikowy.

518

RozdziaH2. ■ Frameworki open-source

JavaSenver Faces W ostatnim kroku nasz dialog przechodzi w stan końcowy end:

519

Framework Shale wywołuje metodę dialogLauncher.setupWireTransferDialog bezpośrednio po zainicjowaniu dialogu Wi re Transfer. Mamy więc do czynienia z dwiema metodami, setupPaymentDi al og i setupWi reTransferDialog, wywoływanym i przez framework Shale bezpośrednio przed wejściem odpowiednio w dialog Payment i Wi re Transfer. Kod obu tych metod przedstawiono poniżej: public class DialogLauncher extends AbstractFacesBean private Bi 11payData bi11payData = null.

end jest specjalnym widokiem stanu przerywającym bieżący dialog i ładującym widok wska­ zany za pośrednictwem atrybutu vi ewld.

//

{

Metoda wywoływana bezpośrednio po zainicjowaniu dialogu płatności:

public String setupPaymentDialog() { billpayData = new Bi 11payData(). bi11payData,setTransfer(new WireTransferData()).

Zasięg dialogu

setValue("#{dialog.data}M, bi11payData): return "success",

Wszystkie strony JS P składające się na nasz kreator obejmują pola wejściowe związane z obiektem, który składujemy w formie obiektu data bieżącego dialogu — przykład takiego pola przedstawiono poniżej:

i //


Metoda wywoływana bezpośrednio po zainicjowaniu dialogu przelewu bankowego:

public String setupWireTransferDialog() { setValue("#{dialog.data}", billpayData.getTransfer()), return "success",

styleClass="iriputM/>

Na początku każdego dialogu framework Shale umieszcza obiekt nazwany dialog w zasięgu sesji; kiedy kończymy (przerywamy) dialog, Shale usuwa obiekt dialog z sesji i tym samym tworzy odrębny zasięg dialogu. W ramach obiektu di al og możemy składować dowolny inny obiekt — wystarczy nasz obiekt przypisać właściwości data obiektu dialog. W powyższym fragmencie kodu uzyskujemy dostęp do obiektu data celem związania pola tekstowego z właściwością name tego obiektu. Nasz obiekt data ma postać prostej kolekcji właściwości reprezentujących pola kolejnych stron naszego kreatora, co jest dość popularnym rozwiązaniem. W tej sytuacji trudno nie zadać sobie następującego pytania: jak to się dzieje, że nasz obiekt data jest wiązany z właściwością data dialogu? Podobnie jak dialog Payment omówiony w punkcie „Nawigacja w ramach dialogu” , także dialog Wire Transfer obejmuje stan akcji nazwany Setup i wykonywany przez framework Shale bezpośrednio po zainicjowaniu dialogu. Metoda tego stanu składuje obiekt data w tak samo nazwanej właściwości dialogu. Deklarację

Metoda setupPaymentDi alog tworzy dwa obiekty, które łącznie obejmują wszystkie właściwo­ ści wszystkich stron (paneli) dialogów Payment i Wire Transfer. Ponieważ Wire Transfer jest poddialogiem dialogu Payment, obiekt data właściwy dla przelewu bankowego składu­ jemy w ramach obiektu data właściwego dla dialogu płatności. Gdy nasz dialog jest aktywny, odpowiedni obiekt dialog (i powiązany z nim obiekt data) jest dostępny za pośrednictwem takich wyrażeń JS F jak #{di al og.data .jakaśidłaściwość}. W momencie przerywania dialogu framework Shale usuwa obiekt dialog z zasięgu dialogu i tym samym wyklucza możliwość dalszego operowania na tym obiekcie za pośrednictwem wyrażeń JSF. Warto pamiętać, że obiekt data dialogu można bez trudu przekształcić w mapę, co w praktyce prowadzi do powstania zupełnie nowego zasięgu.

n

tej metody przedstawiono poniżej:

i l

Ł a t w o z a u w a ż y ć , ż e z d e f in io w a n a w

pow yższym

AbstractFacesBean

fra m e w o rk u

ro z s z e rz a

^FacesBean

k la s ę

k o d z ie

k la s a

Di a 1ogLauncher Abstract

S h a le . K la s a b a z o w a

o fe r u je s z e r e g p rz y d a tn y c h m e to d , k tó r e m o g ą n a m

b a r d z o u ła t w ić p ra c ę

n a d a p lik a c ja m i t e c h n o lo g ii J S F ( c z ę ś ć s p o ś r ó d ty c h m e to d o p is a n o p o n iż e j) . N a p rz y ­

i a iog name="wi re Transfer Dialog" sfart="Setup">

k ła d

k la s a

Di al ogLauncher

w y k o r z y s tu je m e to d ę

AbstractFacesBean. setValue,

p r z y p is u je o k r e ś lo n e j w ła ś c iw o ś c i k o m p o n e n tu ła ń c u c h

k tó ra

p rz e k a z a n y n a je j w e jś c iu

(c o

c ie k a w e , z a m ia s t s t a łe j ła ń c u c h o w e j m o ż n a p r z e k a z a ć w y r a ż e n ie r e p r e z e n t u ją c e w a r t o ś ć ) .

transition outcome="next" target="Account Information"/> transition outcome="cancel" target="Exit"/> transition outcome="previous" target="Bank Information"/> transition outcome="next" target="Account Contact"/> transition outcome="cancel" target="Exit"/>

524

JavaServer Faces transition outcome="previous" target="Account Information"/> transition outcome="next" target="Surnmary'7> transition outconie="cancel" target="Exit"/> transition outcome="previous" target="Account Contact"/> transition outcome="finish" target="Finish"/> transition outcome="cancel" target="Exit"/> transition outcome="success" target="Exit'7>
xhtml

1 0 Trans u i ona 1//EN”

"H ttp //www.w3.org/TR/xhtml 1/DTD/xhtml 1•tra n si Li ona 1 dtd">



526

RozdziaM2. ■ Frameworki open-sounce

JavaServer Faces nref =" s t y le s css" rel =" s ty 1es n e e t" type= "iext/css"/> 1 1 10 >An p l a i n ■v d m 1 Id

xhtml

f i 1e< / 1 i c 1e >

< table cel 1padding=" 2px ">

<1 r >

Rysunek 12.5.

^

Efekt zastąpienia znacznika XHTML komponentami JSF (w czasie wykonywania oprogramowania)

fccłytja

Widok _ Fłistoria

Zakładki

Narzędzia

Pomoc i » {¡ajjy

Hash Plik

Edycja

iSip

Widok ’ ^

Historia

',!■ f j |

Zakładki !

Narzędzia

http://locor-

Pomoc

:8u80/raceie,.login-i oupedup.isf | - ffe j'

<1abel f " n a m e ” class-"label"> Nazwa

Witaj, Wojtek

style="background #ffa"/>
<1abel for="password" class="label"> Hasło

Trudno sobie wyobrazić bardziej uproszczony model aplikacji internetowej. W kolejnym punkcie spróbujemy powiązać te elementy H T M L z komponentami JSF.

Zastępowanie znaczników komponentami JSF— atrybut jsfc Naszym celem jest użycie komponentów JS F do przekształcenia naszych niefunkcjonalnych znaczników w kod doskonałego interfejsu W W W (patrz rysunek 12.5).

S

*

■http://localhost SOSO/facelets/logm-soupedup jsf

”



iEl!

Efekt zastąpienia znacznika XHTMl-a komponentami JSF - Mozitła firek« Plik

Efekt transformacji naszego pliku X H T M L: <1ink href="styles.css" rel="stylesheet" type="text/css"/> #{msgs.windowTi t l e}

<1abel for="name" class="label" jsfc="h:outputLabel "> #{msgs.namePrompt}

#{msgs.passwordPrompt} 527 528 JavaServer Faces Rozdział 12. ■ Frameworki open-source

Warto zwrócić uwagę na trzy aspekty przedstawionego przykładu: ■ Powinniśmy sobie przypomnieć zawartość pasków adresów U R L z rysunków 12.4 i 12.5. Adres U R L widoczny na rysunku 12.4 kończy się przyrostkiem .xhtml, natomiast adres widoczny na drugim ze wspomnianych rysunków kończy się przyrostkiem .js f Oznacza to, że na pierwszym zrzucie ekranu przedstawiono to, co widzi projektant grafiki, natomiast na rysunku 12.5 przedstawiono to, co ukazuje się oczom programistów i (docelowo) użytkownika końcowego. ■ Aby umożliwić stosowanie znaczników technologii Facelets „podszywających się” pod bibliotekę znaczników podstawowych JS F , wykorzystujemy przestrzeń nazw języka X M L . Naturalną konsekwencją takiej decyzji jest wykorzystywanie znacznika f : 1oadBundl e z tej przestrzeni nazw do ładowania pakietu komunikatów. I wreszcie bezpośrednio w kodzie strony posługujemy się wyrażeniami reprezentującymi wartości, np. #{msgs. naniePrompt} — znacznik h: outputText nie jest wymagany — które umożliwiają nam uzyskiwanie dostępu do kluczy pakietu zasobów. ■ Nasz formularz, etykiety, pola tekstowe i przycisk rozbudowaliśmy o dodatkowy atrybut jsfc. Kiedy technologia Facelets operuje na tak skonstruowanej stronie X H T M L, zastępuje odpowiednie znaczniki komponentami określonych typów. Część Czytelników zapewne zastanawia się, co widzi projektant warstwy graficznej, kiedy pracuje nad plikiem w formacie XF1TML. Odpowiedzią na te wątpliwości jest zrzut ekranu przedstawiony na rysunku 12.6.

Ponieważ przeglądarka internetowa „nie wie", jak interpretować wyrażenia reprezentujące wartości właściwe dla technologii JSF , traktuje je jak zwykłe łańcuchy tekstowe. Takie roz­ wiązanie jest szczególnie cenne z perspektywy tłumaczy, którzy mogą bez trudu identyfikować prezentowane komunikaty na podstawie stron XH T M L.

, ,

-TT

.....................................

--■ '

| | | |

C o p r z e g lą d a r k a ( lu b in n e n a r z ę d z ia u m o ż liw ia ją c e p r z e g lą d a n ie s t r o n X H T M L ) r o b i

flfi«i

z n a s z y m i a tr y b u ta m i

jsfc?

N ic ! O z n a c z a t o , ź e p r o je k t a n c i i g r a f ic y m o g ą s w o b o d n ie

d o s k o n a lić w y g lą d i s p o s ó b o b s łu g i k o le jn y c h p lik ó w k o m p o n e n t a m i, k t ó r e

/żwytó^

:

U ^x

X H T M L , p o d c z a s g d y m y , p ro g ra i g d ą w y k o r z y s t y w a n e .w

c z a s ie

" ■'wmwfT'z.W 'j p o d

p e w n y m i w z g lę d a m i ^

e c h n o lo g ia , t a k i C la y o fe r u je p r e c y z y jn e r o z g r a n ic z e n ie p r o je k t u g r a f ic z n i z w ią z a n e g o z w id o k a m i H T M L . C la y m a t ę fu n k c jo n o w a ć n a w e t z b łę d n ie s k o n s tr u o

;;:rftć§fią

iw a n ia w t e n c z y in n y s p o s ó b c h n o lo g ią F a c e le t s , ż e m o ż e

v U h itechnoiogięt .Facelets A vt.. "r____________

T---Y' ■...o:.::

Stosowanie znaczników technologii JSF Najkrócej mówiąc, technologia Facelets (podobnie jak framework Tapestry) precyzyjnie izoluje projekt graficzny od procesu wytwarzania właściwego oprogramowania. Jeśli jednak pełnimy jednocześnie funkcje projektanta warstwy graficznej i programisty, istnieje szereg powodów, dla których możemy preferować bardziej tradycyjne podejście znane z technologii JSP . Przykładowo: kod języka X H T M L jest bardziej obszerny od kodu JS P i jako taki na dłuższą metę jest trudniejszy w konserwacji. Okazuje się, że technologia Facelets zdaje eg­ zamin, nawet jeśli tęsknimy za tradycyjnym podejściem polegającym na stosowaniu znacz­ ników JSP. Jedynym istotnym odstępstwem od oryginalnego podejścia jest niewidoczna, ale faktyczna rezygnacja z technologii JSP . Technologia Facelets rozpoznaje znaczniki, które chociaż wyglądają identycznie jak ich odpo­ wiedniki znane z technologii JSP , są przetwarzane właśnie przez technologię Facelets. Kod X H T M L jest poddawany analizie składniowej, której wynikiem jest drzewo komponentów.

530

JavaServer Faces

Rozdział 12. ■ Frameworki open-source

Na rysunku 12.7 przedstawiono nową wersję formularza logowania z rysunku 12.5 (tym zaimplementowaną z wykorzystaniem znaczników JS F technologii Facelets).

Rysunek 12.7.

|||i Przykład użycia znaczników JSf - Mcz a f "etos

Widok technologii Facelets zbudowany z wykorzystaniem znaczników JSF

i Plik

Edycja

Widok

|^

Historia

Zakładki

i

Nazwa

p-opei-

Hash

1

j

Narzędzia



Pomoc

http://loc8lho$t:8080/facelets/login-with-faces-tagj.jif

1* •

531



____ Ml



Warto zwrócić uwagę na fakt, że w powyższym kodzie celowo zrezygnowano z podejścia opartego na stosowaniu atrybutu j s f c , które — jak już wiemy — umożliwia niezależną, równoległą pracę programistów i projektantów szaty graficznej.

i Zaloguj !

Ostateczna decyzja o ewentualnym izolowaniu projektu graficznego od właściwego pro­ gramowania aplikacji należy oczywiście do nas. Niezależnie od tej decyzji musimy mieć na uwadze, że technologia Facelets oferuje wiele udoskonaleń względem domyślnych mecha­ nizmów wyświetlania technologii JavaServer Faces. i

Zal n o c z o

Kompozycje stron złożonych z szablonów Nasza strona w formacie X H T M L ma teraz następującą postać: <1DOCTYPE himl PUBLIC "-//W3C//DTD XHTML ] 0 Trans U i ona 1//EN" "TH l p / /wWW w3 o r g / T R / x l u m l 1/DED/xiuml 1- t r a n s u i o n a l

dTU">



Rysunek 12.8.

lo adB undle -^{msgs

re l= "style sn e e L "

Dasename=” c o m . c o n e j s f

-tllk Facelets - Moate FśęffełśU

Efekt użycia technologii Facelets do skomponowania strony internetowej

<1 1 nk h r e i - " s t y l e s . c s s "

Technologia Facelets umożliwia nam konstruowanie stron internetowych złożonych z odręb­ nych fragmentów kodu języka XFITM L (czyli podobnie jak w przypadku frameworku Tiles). Przykład takiej strony internetowej przedstawiono na rysunku 12.8.

Plik

Edycja

Widok

Historia

Zakładki ,■Narzędzia

Pomoc

h ttp :;/lo i:a !h o ;t;3 0 8 0 /fa ce le t5 .'io g iti-w itn -c c^ [ ^ |

type= "tex t/css"/>

m essages"

var-'m sg s"/>

f a c e s T a g s w m d o w T u 1e [ < / 1 u le>





Prosimy się zalogować w serwisie faceleis.com Nazwa j Hash

f

Zaioęuij


xmlns:ui="http://java.sun.com/jsf/facelets" xmlns-f="h t t p : / / ja v a .su n .co m /jsf/ co re" xmlns:h="h t t p : / / Ja v a .Su n .co m /jsf/h tm l" xmlns*c="h t t p : / / ja va .s u n .c o m / js t1/co re">

ciała



Ciało powyższego znacznika ui compos 11ion jest identyczne jak ciało pliku XH T M L, którego zawartość przedstawiono na pierwszym listingu z punktu „W idoki X H T M L".

m

P o c o w o g ó le t r a c im y c z a s n a s t o s o w a n ie k o m p o z y c ji t e c h n o lo g ii F a c e le ts , s k o r o

■ K k i r ó w n ie d o b r z e m o g lib y ś m y u m ie ś c ić d e f in ic ję r o z m ie s z c z e n ia i w ła ś c iw ą t r e ś ć s t r o n y w je d n y m

p lik u ?

O d p o w ie d ź j e s t p r o s t a —

w s p ó łd z ie lą c y m i to

sam o

z d e f in io w a n ie t e g o

r o z m ie s z c z e n ia

w id o k a c h

( p o d o b n y m e c h a n iz m

jsp:include

t e c h n o lo g ii J S P

p a m ię ta ć , ż e w

pow yższym

menu i content

m oże

g d y b y ś m y d y s p o n o w a li w ie lo m a

r o z m ie s z c z e n ie , le p s z y m i je g o

r o z w ią z a n ie m

w ie lo k r o t n e

w y k o r z y s t y w a n ie

s t o s u je m y , d o łą c z a ją c t r e ś ć

i e le m e n tu

ui :incłude

za

w id o k a m i

b y ło b y je d n o r a z o w e w e w s z y s tk ic h

pom ocą

e le m e n tu

t e c h n o lo g ii F a c e le t s ) . M u s im y

p r z y k ła d z ie k a ż d a k o m p o z y c ja d e f in iu ją c a o b s z a r y

k o rz y s ta ć z te g o

sam ego

headery

r o z m ie s z c z e n ia . P r z e d s t a w io n y m o d e l

m a o g r o m n y p o t e n c ja ł.

< t 1 1 ie> Facelets< /t u le >

Znaczniki niestandardowe technologii Facelets Technologia Facelets oferuje nieporównanie więcej rozwiązań, niż zdołaliśmy omówić w tym podrozdziale — Czytelników zainteresowanych poszerzeniem swojej wiedzy na ten temat odsyłamy do oficjalnej dokumentacji. Najpierw jednak przyjrzyjmy się jeszcze jednemu aspektowi tej technologii: znacznikom niestandardowym.

Okazuje się, że tworzenie i wykorzystywanie własnych znaczników X H T M L w widokach budowanych na bazie technologii Facelets jest wyjątkowo proste. Na rysunku 12.9 przed­ stawiono aplikację omówioną w punkcie „Kompozycje stron złożonych z szablonów" i uzupeł­ nioną o znacznik niestandardowy prezentujący nagłówki protokołu HTTP właściwe dla bieżą­ cego żądania (ale tylko wtedy, gdy żądanie obejmuje parametr debug z wartością true).

534

JavaServer Faces

Rozdział 12. ■ Frameworki open-source HH Facelets - M-ozilla Fkefox

Rysunek 12.9.

Plifc

Znacznik diagnostyczny wywoływany za pośrednictwem atrybutu żądania

fedycja

Widok

iz z z s s a

H*rtoria

ZaktatfU

Naizędza

¿o,

.toga»

Pomoc

»ttp://localho$t!8030/facelet?/loqin-with-ci{.y|^^^^^i |jocigle

^

|&||

¡ f ace>i B Prosimy się zalogować w serwisie _faeeleis.com W it™ W k

Nazwa

j

Hash

f

535

To wszystko. Skonstruowanie znacznika niestandardowego technologii Facelets wymaga zaledwie dwóch kroków.

Integracja z technologią EJB— Seam Jednym z czynników, który czyni programowanie aplikacji internetowych w Javie trudniejszym, niż można by oczekiwać, jest niespójność frameworków interfejsu użytkownika i frameworków odpowiedzialnych za utrwalanie danych. Oba aspekty Javy dla przedsiębiorstw istnieją i doj­ rzewają niezależnie od siebie, a więc bez z góry określonych, wspólnych celów.

i Zaloguj j

Poniżej przedstawiono bardzo okrojoną wersję kodu strony z rysunku 12.9:



Swobodne stosowanie tego znacznika wymaga tylko dołączenia deklaracji naszej przestrzeni nazw. Sam znacznik zdefiniowano w pliku w formacie X M L: http://corejsf/facelets/debug headers tags/corejsf/debug/headers.xhtml

W przedstawionym kodzie X M L określiliśmy nazwę znacznika, nagłówki oraz plik repre­ zentowany przez ten znacznik: tags/corejsf/debug/headers.xhtm l. Zawartość tego pliku przedstawiono poniżej:

Implementacja aplikacji internetowych z wykorzystaniem Javy tradycyjnie wiązała się z ko­ niecznością opanowania dwóch frameworków — jednego dla interfejsu użytkownika (U l) i drugiego dla mechanizmów wewnętrznych (właściwej logiki aplikacji). Przykładami takich par frameworków są JS F i Hibemate, Tapestry i EJB3 oraz Webwork i LBAT1S. Oznacza to, że przed opracowaniem aplikacji internetowej musimy opanować techniki łącznego stosowania obu frameworków. Współpraca programistów tworzących takie frameworki mogłaby nam znacznie uprościć proces wytwarzania aplikacji internetowych — unifikacja frameworków interfejsu użytkownika i utrwalania danych jest marzeniem wielu współczesnych programistów. Rozwiązaniem jest fraraework Seam Firmy JBoss. Seam jest przykładem zupełnie nowego podejścia do problemu wytwarzania aplikacji internetowych, w którym udało się połączyć technologie JS F i EJB3 (lub Flibemate) w ramach jednego rozbudowanego frameworku za­ pewniającego nieporównanie wyższą produktywność niż tradycyjne frameworki aplikacji internetowych Javy. Framework Seam może współpracować zarówno z technologią Hibernate, jak i z technologią EJB3, a cała aplikacja może działać albo na serwerze JBoss, albo na serwerze Tomcat 5.5. W kolejnych punktach tego podrozdziału przeanalizujemy działanie tej ciekawej technologii.

Książka adresowa Aby wyjaśnić podstawy funkcjonowania frameworku Seam, w niniejszym punkcie prze­ analizujemy implementację opracowanej w tej technologii aplikacji książki adresowej, która utrzymuje listę kontaktów w bazie danych. Książka adresowa jest typowym przykładem aplikacji utwórz, odczytaj, zaktualizuj, usuń. Możliwy sposób dodawania kontaktów do bazy danych przedstawiono na rysunku 12.10. Na rysunkach 12.11 i 12.12 przedstawiono odpo­ wiednio sposób usuwania i edycji kontaktów. Nasza aplikacja książki adresowej składa się z trzech stron JS P : strony książki adresowej obejmującej listę wszystkich kontaktów, strony dodawania nowego kontaktu oraz strony edycji kontaktu już istniejącego. Samo przeglądanie wymienionych stron JS P nie pozwala stwierdzić, czy mamy do czynienia z aplikacją Seam. Poniżej przedstawiono wybrany fragment kodu strony addressBook.jsp (widocznej na rysunku 12.10):

536

Rozdział 12. ■ Frameworki open-source

JavaServer Faces

Rysunek 12.10.

Rysunek 12.11.

Ksiarka adresowa • Mo zilla Firefc*

Proces dodawania dwóch kontaktów do pustej książki adresowej

Plik

Edycja

Widok

Historia

Zakładki

Narzędzia

Przykład usuwania kontaktu z książki adresowej

Pomoc

' ‘-O ' k ł y J; ói *.. hrtP:/'localhoT:i! 7. ►*!EH

■ .X '

Dodaj kontakt do książki adresowej

Użytkownicy

Plik

Edycja v "i ż

-ii Dł-KjaM/3

Miast ■

61 Z n

Woic-w odzrw o

■ ■-'Pikopoi-i-<
K rai

Pozn an

Mozrtts Nrełox

Widok

Historia

' ^

Zakładki [

Imię i Nazwisko

^

\

Użytkownicy - Moziiła Firefox

£m

Edycja

Widok

Historia

Zakładki

’

Narzędzia

Narzędzia

Ulica

ij f i !T ł ■:

Jćtai

Książka adresowa Imie i Nazwisko

Miasto Województwo

Kraj

uł, Długa 14/3

61-231 Wielkopolskie Poznań

| Usun i J an Budnik

os Ptasrow 2 3^

44. 100 Śląskie

Gliwice

|. U ^ j Ducyna Podgórna

ał W ierzbowa 14.

00-139 Mazowieckie

W arszawa

?L

Pomoc

T7':/T'T'Dt:Si:i

I l i

i Usuń j Kaztaraerg N o w a k

j Usoti j M arie; ¿ukaplitzny ul M okra l N

t2 !

Dodaj kontakt

C-2:#:

Pomoc

http /.‘localhost-eOSO/seam /a il * T f i» j jjG

Książka adresowa

truu; i nazwisk.- ' azim ier? No-«f3>

rTfod

i Usun i Filip Piechna ;

1

62-050 Wielkopolskie Zaniemyśl

os Kosynierów 8/42 12-332 Małopolskie

K rak ó w

Li Wlę. -1ks-titakK-W Ulica

¿aronczono

Miasto Województwo Kraj

Plik

Edycja

Widok

Historia

♦ rIjl ' ® lj!

[ Usuń | Kaątmćfz N o w a k ul. Długa 14/3 61-231 Wielkopolskie Poznań

Ijt

Zakładki

i

Natzędzia

Pomoc

http://!ocaIhost: S08O/seao /ac] * [ j t ]

;> U-oq:»a

jjjj

Książka adresowa L • • .iai w ię

#

JLL.

Książka adresowa - Mozills Firefos Plik

Edycja

Widok -

#

Historia 7 1 . fjt

Imię i Nazwisko

Zakładki

Narzędzia

Pomoc

Ulica

Miasto Województwo

http://locaIhost:8uy0,’seam/addu ontactsea ! » f |^ | §G)^P

T

L tI

Dodaj koniaki do książki adresowej

. ul Długa 14/3

61-231 Wielkopolskie Poznań

L Usurt 1 Jan Rudnik

os Piastów ¿3/9

44. [00 Śląskie

j Usun~~j

ul. M okra 7A G -■ Q

62-050 Wielkopolskie Zaniemyśl

i Psun j

Filip Piechna

os Kosynierów 8'42 12-332 Małopolskie

tanu; i nazwisk- i tan Bud miUka

o.=- Piasto-i U3■B

Miasto

^-’00

W .-1rw-i dzrw-.

S iąs n e

P ■„ tar w ięc e- k - n t a k r w

ECrai

El®

,* Użytkownicy - Moz-ra Firefom Plik

Edycja

W idok

Historia

Zakładki

Narzędzia

■Jjtt p; / / 1o c a Ih o st:8 08Oj »

0»o*>gle

jj-ty

Książka adresowa Imię i Nazwisko

Ulica

Miasto Województwo Kraj

jjs ta te j

ul Długa 14/3

T Usuń j Jan Budnik

os Piastów 23/9 44-100 Śląskie

6-|rS |:f; Wielkopolskie Poznań

Gliwice 1

Dodaj wiece- kontaktów*

Z akończono

^mmmmmm

<%@ page contentType="text/html,charset=UTF-8" language="java" %> <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> taglib uri="http://java.sun.coni/jsf/core" prefix="f" Użytkowni cy

Zakończono


P om oc

uii'""ce

! Cwci&jkomaw

Kraj

C, 1 lJSU11 i

i.

537

mmm1

Gliwice

K rak ów

538

RozdziaM2. ■ Fnameworki open-source

JavaServer Faces

Rysunek 12.12. Edycja kontaktu składowanego w książce adresowej

fĘfy UTyttownscv Puk

Edycja

Jak można było oczekiwać, tabelę kontaktów zaimplementowano z wykorzystaniem znacz­ nika h: data Table. Atrybut value tego znacznika wskazuje na komponent zarządzany, który nazwaliśmy contacts, natomiast w jego ciele uzyskujemy dostęp do innego komponentu zarządzanego, który nazwaliśmy addressBook. Komponent addressBook wykorzystujemy do wiązania widocznych na stronie przycisków i ich łączenia z metodami akcji JSF .

MazNa Fire-fax WtdoK

Historia

' C ?

'

Zawadki '

£ 2

Narzędzia

Pomoc

htfp:.'.,|ocalh o s t 80 «0 /seam /af: » , frP t C H

..

i Książka adresowa Imię i Nazwisko

Edycja

Kraj

tú. Długa 14/3

61-231 Wieikop olskie Poznań

os Piasiow 23/9

44 109 śląskie

¡ ut.wr> ¡ J ctnpBudruŁ

Plik

Miasto Województwo

UUca

i u s u p i Kaaaáefz N ow ak

Widok

M * M *m

Historia

Zakładki

8 S C

Narzędzia

Pozostałe dwie strony JS P naszej aplikacji, czyli addC onlactjsp oraz ediiC ontacljsp , są równie proste — mają postać najzwyklejszych widoków technologii JavaServer Faces po­ zbawionych jakichkolwiek elementów sugerujących stosowanie technologii innej niż JSF .

Gliwice

Pomoc

http://1ocalhost:8080/jeam/adc! »

Najbardziej interesującymi składnikami tej aplikacji są komponenty zarządzane. Na podstawie samych stron JS P nie bylibyśmy w stanie ocenić, że wspomniane komponenty contacts i addressBook są w istocie komponentami EJB . Pierwszy z nich jest komponentem encyjnym, drugi jest stanowym komponentem sesyjnym. W dalszej części tego podrozdziału przeko­ namy się, jak w praktyce wygląda współpraca poszczególnych elementów naszej aplikacji.

| | i/

Edycja kontaktu Lnnę i iiazwisk

'a 1- Bu Pai

rjh. d

'> P'smo....

M iast.

J J - ' nn

~ Q5jjg' Plik

Edycja ■. Widok;■ Histeria-:

Zakład«* |

Inni; m azw isP

c: I I

http://loca!host //localhostiSOBO/seam/addr

Plik

Edycja . Widok

Histor.a

Zak

p f lt il

EPj-irui-

Nlif d

ui FćtiiSta m

Miast

1Z-b ”

U.iai-wi.' łztwo EIrai

Konfiguracja

Narzędzia .i Pomoc

Edycja kontaktu

|f| Użytkownicy-MozifeFitefos:.ZZ

M ai ok-oIs11? k rak ci ■ ■

Książka adresowa

Konfiguracja naszej aplikacji składa się z dwóch plików X M L: po jednym dla technologii JS F i technologii utrwalania danych. Nasz plik konfiguracyjny właściwy dla technologii JS F nie zawiera deklaracji żadnych komponentów zarządzanych (co jest typowe w przypadku aplikacji Seam) — wszystkie tego rodzaju konstrukcje przeniesiono na poziom adnotacji. W praktyce wspomniany plik konfiguracyjny składa się niemal wyłącznie z reguł nawigacji opisujących przejścia pomiędzy poszczególnymi stronami internetowymi. Plik konfiguracyjny JS F nie zawiera więc żadnych nowych elementów i jako taki nie wymaga szczegółowej analizy. Nieco bardziej interesujący jest plik konfiguracyjny opisujący utrwalanie danych:

Łmię i N azwisko ul Długa 14/3

61-231 Wielkopolskie Poznań

|_uswo i I/ut Budiul

dl Falista 18

12-K77 Małopolskie

ELrakow

^ p n o v id en>ong

I

ał Wierzbowa 14

00-139 Mazowieckie

Warszawa

java /DefaullDS
j u sop i M a u p i Zcikapliczn? 'il Mokra ?A/1 I

'■

■

name=" userDatabase">

[ U c u ń j Kaatraerz N o w ak

I Lucyna Podgórna

539

Ó2-0ÓU Wielkopolskie Zaniemyśl

os: Kosynierów 8/42 12-332 Małopolskie 3 K rak ów

< p ersisten ce

u n it

h ib e rn a te

ejD

H ipernatePersiSten ce< /pn oviden>

value="org h ip e rn a te d ia le c t hSOl Di a 1ec t "/> f

^property name="uibernate hpm2ddl auto" value="cneate-dnop"/>

-iai wie i *i I-muda, -w

Zak O'»J . »0

- %- Pozostałe kolumny tabeli pominięto, aby oszczędzić cenną przestrzeń.



Kontakty naszej książki adresowej składujemy w bazie danych, stąd konieczność użycia komponentu encyjnego: ©Entity @Name("contact") ©Scope(ScopeType.EVENT) ©Table(name="contacts") public class Contact implements Serializable { private static final long serialVersionUID = 48L; private String name, streetAddress, city; private String state, country, public Contact(String name) { this.name = name; } public ContactO {} ©Id @NotNul 1 ©Length(min=5, max=25) public String getNameO { return name; }

541

Wspomniane adnotacje poprzedzające klasę Contact powodują, że kiedy Seam po raz pierwszy napotyka nazwę contact w wyrażeniu reprezentującym wartość, automatycznie tworzy i umieszcza w zasięgu żądania (w terminologii Seam stosuje się określenie zasięg zdarzenia) obiekt klasy com. corej s f .Contact. Określiliśmy też nazwę tabeli bazy danych (w tym przy­ padku contacts) właściwej dla naszego komponentu encyjnego. Adnotacja ©Id wskazuje właściwość name jako klucz główny tabeli contacts. Adnotacje ©NotNul 1 i ©Length określają, że właściwość name odpowiednio nie może mieć wartości nuli i że musi reprezentować łańcuch złożony z co najmniej pięciu i maksymalnie 25 znaków.

R H I W w

J

p o w y ż s z y m f r a g m e n c ie k o d u w y k o r z y s t a liś m y łą c z n ie s ie d e m

r z a ją c y c h z w y k ły , tr a d y c y jn y o b ie k t J a v y ( a n g .

c h a n iz m

u t r w a la n ia

i p r z e k s z ta łc a ją c y c h g o w

a d n o ta c ji ro z s z e -

Plain Old Java Object —

P O JO ) o m e ­

k o m p o n e n t z a r z ą d z a n y J S F . P o s łu ż y liś m y

się trzema rodzajami adnotacji: ■ technologii EJB3.

public void setName(String name) { this.name = name; }

■ technologii JSF. ■ frameworku weryfikacji technologii Hibernate.

Pominięto standardowe dla technologii JavaBeans metody ustawiające i zwracające / / wartości pozostałych zmiennych.

//

©Entity, ©Table i ©Id s ą z w i ą z a n e z t e c h n o l o g i ą E J B 3 , n a t o m i a s t a d n o t a ­ ©Name i ©Scope s ą z w i ą z a n e z t e c h n o l o g i ą J S F . I w r e s z c i e a d n o t a c j e ©NotNul 1 o r a z ©Length m a j ą w p ł y w n a f u n k c j o n o w a n i e f r a m e w o r k u w e r y f i k a c j i t e c h n o l o g i i H i b e r n a t e , A d n o ta c je c je

public String toStringO { return "ContactC + name + ")", }

k t ó r y m o ż e b y ć w y k o r z y s ty w a n y z a r ó w n o p rz e z s a m ą t e c h n o lo g ię H ib e r n a te , ja k i p rz e z te c h n o lo g ię E J B 3 .

}

Adnotacje umieszczone przed deklaracją klasy Contact określają, że reprezentuje ona kom­ ponent encyjny. Dostęp do tego komponentu (nazwanego contact) uzyskujemy w kodzie strony addContact.jsp :

P |J

W

p r z e c iw ie ń s t w ie d o ty p o w y c h a p lik a c ji J S F a p lik a c je S e a m

■ ¡¡i d a n y c h

d o k o n u ją w e r y fik a c ji

n a p o z io m ie m o d e lu , n ie n a p o z io m ie w id o k u .

_________________________________________________________________________

Stanowe komponenty sesyjne Skoro dysponujemy już stosunkowo prostym komponentem encyjnym, który możemy trwale składować w naszej bazie danych, warto się przyjrzeć klasie odpowiedzialnej za właściwe działania, czyli stanowemu komponentowi sesyjnemu obejmującemu metody akcji JS F wywo­ ływane z poziomu stron JSP . W pierwszej kolejności zadeklarujemy interfejs lokalny: package com.corejsf; import javax.ejb.Local; ©Local public interface AddressBook {

542

JavaServerFaces public public public public public

String adclToBookO, String delete(), String begiriEditO. String e d itO , void findContacts(),

} Możemy teraz przystąpić do implementacji stanowego komponentu sesyjnego: / / UWAGA: Poniższy listingjest niekompletny. Wybranefragmenty tej klasy celowo / / pominięto z myślą o dalszych rozważaniach.

OStateful @Scope(ScopeType.SESSION) @Name("addressBook") public class AddressBookAction implements Serializable. AddressBook { @In(required=false) private Contact contact: DPersi stenceContext(type=Persi stenceContextType.EXTENDED) private EntityManager em.

@1fInvalid(outcome=Outcome.REDISPLAY) public String addToBookO { List existing = em.createQueryC'select name from Contact where name=:nanie") .setParameterCname", contact ,getName()) getResultList(), i f (existing.size()==0) {

Jeśli dany kontakt jeszcze nie istnieje, zapisujemy go / / w bazie danych:

//

e m .p ersist(co n ta ct);

return "success".

}

else f facesContext addMessage(nu ll. new TdcesMessage("kontakt istnieje juz w bazie danych!")) return nuli

DRemove DDestroy p u b lic void d e s t r o y ! ) {1

} Adnotacja @Name określa nazwę komponentu zarządzanego. Do komponentu addressBook odwołujemy się z poziomu strony addressBook.jsp , której kod przedstawiono w punkcie „Książka adresowa". Za pośrednictwem adnotacji @Scope opisujemy zasięg komponentu addressBook.

Do wstrzyknięcia (ang. inject) egzemplarza komponentu contact wykorzystano adnotację 01 n — oznacza to, że framework Seam przechwyci każde wywołanie metody klasy Address ^BookAct ion, i jeśli okaże się, że zmienna nazwana contact jest w zasięgu, Seam wstrzyk­ nie ją do właściwości contact klasy AddressBookAction przed wywołaniami danej metody.

RozdziaM2. ■ Frameworki open-source

543

W przypadku właściwości contact wstrzykiwanie nie jest konieczne; gdyby było inaczej, framework Seam generowałby wyjątek dla każdego wywołania metody w warunkach braku zmiennej contact w zasięgu. W metodzie addToBook użyliśmy menedżera encji E JB do trwałego zapisania kontaktu w bazie danych. Wspomniana metoda jest wywoływana z poziomu strony addContact.jsp :

Przedstawiony mechanizm działa w następujący sposób: kiedy ładujemy stronę addContactjsp , framework Seam napotyka wyrażenie #{contact.name). Ponieważ komponent contact obejmuje zasięgiem żądanie (w terminologii Seam — zdarzenie), Seam tworzy egzemplarz klasy com.corejsf .Contact i składuje go w zasięgu żądania pod nazwą contact. Framework Seam wywołuje następnie metodę contact ,getName(), której zadaniem jest wypełnienie pola tekstowego name w czasie ładowania strony. Od tej pory komponent contact jest dostępny na poziomie całej ładowanej strony. W odpowiedzi na wysłanie formularza przez użytkownika (zakładając, że wszystkie wpisane wartości pomyślnie przechodzą proces weryfikacji danych) framework Seam wywołuje odpowiednie metody ustawiające wartości właściwości obiektu contact, po czym wywołuje metodę addressBook addToBook(). Kiedy framework Seam przechwytuje wywołanie metody addressBook .addToBook!), w pierw­ szej kolejności wstrzykuje wartość zmiennej contact o zasięgu żądania do tak samo nazwanej właściwości obiektu addressBook. Oznacza to, że metoda addToBookt) ma dostęp do kom­ ponentu encyjnego contact i że od tej pory może wykorzystywać usługi menedżera encji E JB do aktualizowania bazy danych (zgodnie ze zmianami dokonywanymi przez użytkownika). | H ! Nasza aplikacja książki adresowej składa się z dwóch kom ponentów EJB: kom■ fcil ponentu encyjnego reprezentującego pojedynczy kontakt oraz stanowego kom­ ponentu sesyjnego. Kom ponenty encyjne kontaktów są składow ane w bazie danych, natom iast stanowy kom ponent sesyjny zawiera metody akcji JSF i utrzymuje listę kon­ taktó w reprezentowanych w bazie danych. Nasz stanowy kom ponent sesyjny równie dobrze m ożna by zaim plem entow ać w form ie kom ponentu JavaBean, jedn ak wówczas nie moglibyśmy korzystać z dobrodziejstw dostępu do bazy danych z poziomu akcji JSF — stąd decyzja o użyciu kom ponentu sesyjnego (co je s t dość typowym rozwiąza­ niem w przypadku aplikacji budowanych na bazie fram eworku S eam ).

544

JavaserverFaces

RozdziaM2. ■ Framework! open-source @End public String editO { em.persist (selected C o n tact), contacts = em.createQueryC'from Contact") .getResultListO , return "edited":

Integracja z modelem danych technologii JSF Framework Seam oferuje wbudowaną obsługę tabel technologii JSF. Warto raz jeszcze rzucić okiem na bardzo okrojony kod strony addressBook.jsp poświęcony tabeli kontaktów:

}



//

public class AddressBookAction implements Serializable, AddressBook { @DataModel

@Out(required=false) private List contacts: @ Factory("contacts")

public void findContacts() { contacts = em.createQueryC'from Contact") .getResultListO ;

} } Kiedy framework Seam napotyka konstrukcję . . w kodzie strony addressBook.jsp, próbuje odnaleźć w zasięgu zmienną nazwaną contacts. Jeśli okaże się, że taka zmienna nie istnieje, Seam utworzy ją za pośred­ nictwem wywołania metody fabryki nazwanej AddressBookAction.findContactsO. Metoda findContacts() wykonuje na bazie danych zapytanie gwarantujące, że zmienna contacts będzie reprezentować kompletną listę kontaktów. Bezpośrednio potem Seam eksportuje tę zmienną do zasięgu strony (wymusiliśmy to działanie za pomocą adnotacji @0ut). Opisany przykład dowodzi, że metody fabryk frameworku Seam umożliwiają nam wiązanie komponentów JS F z trwałymi obiektami — w tym konkretnym przypadku wiążemy listę kontaktów składowanych w bazie danych z tabelą JSF. Framework Seam dodatkowo oferuje obsługę operacji wyboru podzbioru wierszy tabeli. W tym celu w kodzie klasy AddressBookActi on użyliśmy adnotacji @DataModel Sel ecti on: public class AddressBookAction implements Serializable, AddressBook { ODataModel @0ut(requi red=false) private List contacts: @DataModelSelectio n

@Out(required=false, scope=ScopeType.CONVERSATION) private Contact selectedContact;

Metoda delete jest wywoływana z poziomu strony addressBookjsp.

public String deleteO { //

Usuwa zaznaczone kontakty z bazy danych:

contacts. reniove(selectedćontact), em.remove( selectedContact), return "deleted":



Wróćmy teraz do naszego stanowego komponentu sesyjnego AddressBookAction (omówionego w punkcie „Stanowe komponenty sesyjne” ). W przytoczonym punkcie celowo pominęliśmy pewne szczegóły, którymi zajmiemy się dopiero w tym i kolejnych punktach. W pierwszej kolejności skoncentrujemy się na adnotacjach @DataModel i @DataModelSelection oraz ich właściwościach. Sposób użycia adnotacji @DataModel przedstawiono poniżej:

545

} } Kiedy użytkownik klika przycisk lub łącze dostępne w tabeli reprezentowanej przez zmienną contacts, framework Seam wstrzykuje wybrany kontakt do zmiennej selectedContact klasy AddressBookAction jeszcze przed wywołaniem metody akcji właściwej dla klikniętej kon­ trolki. Na przykład w odpowiedzi na kliknięcie przycisku Usuń na stronie aplikacji książki adresowej framework Seam wywoła metodę AddressBookActi on. delete. Zanim jednak nastąpi to wywołanie, ten sam framework wstrzyknie wybrany kontakt do zmiennej selectedContact klasy AddressBookAction. Co ciekawe, istnienie metod ustawiających i zwracających wartość tej zmiennej nie jest konieczne — w zupełności wystarczy zadeklarowanie tej zmiennej wraz z odpowiednią adnotacją (całą resztą zajmie się framework Seam). Nasza aplikacja nie tylko wstrzykuje wartość zmiennej selectedContact, ale też dodatkowo eksportuje (czyli wykonuje operację odwrotną niż wstrzykiwanie, ang. outject) swój zasięg konwersacji, aby umożliwić dostęp do tego zasięgu z poziomu strony editContactjsp. Pro­ blematyką zasięgu konwersacji zajmiemy się w kolejnym punkcie.

Zasięg konwersacji W aplikacjach internetowych istnieje pojęcie zasięgu żądania, który obejmuje pojedyncze żądanie protokołu HTTP, oraz niemal nieograniczonego zasięgu sesji. Kiedy implementujemy cały ciąg interakcji, np. w formie kreatora, często stawiamy sobie za cel stworzenie zasięgu pośredniego, a więc szerszego niż zasięg żądania, ale węższego niż zasięg sesji. W technologii Seam taki zasięg określa się mianem zasięgu konwersacji. Usuwanie kontaktu z książki adresowej jest typowym procesem jednoetapowym. W odpowie­ dzi na zdarzenie kliknięcia przez użytkownika przycisku Usuń framework Seam wywołuje metodę AddressBookActi on. delete (co opisano w poprzednim punkcie). Za wstrzyknięcie wybranego kontaktu przed wykonaniem tego wywołania odpowiada framework Seam (patrz punkt „Integracja z modelem danych technologii JS F ” ). Metoda delete usuwa wskazany kontakt z bazy danych i aktualizuje listę kontaktów utrzymywaną przez bezstanowy kom­ ponent sesyjny. Z zupełnie inną sytuacją mamy do czynienia w przypadku edycji kontaktu, która z natury rzeczy jest procesem dwuetapowym. W pierwszej kolejności użytkownik klika łącze repre­ zentujące interesujący go kontakt:

546

JavaServer Faces

1

3

Jak to zrobić?

Framework Seam wywołuje wówczas metodę AddressBookActi on. begi nEdi t (także tym razem wspomniane wywołanie jest poprzedzone wstrzyknięciem wybranego kontaktu do zmiennej selectedContact). Sposób implementacji metody begi nEdi t przedstawiono poniżej: public class AddressBookAction implements Serializable, AddressBook { BDataModelSelection @In(requi red=false) @0ut(required=false, scope=ScopeType.CONVERSATION) private Contact selectedContact, OBegin public String beginEditO {

return "ed it",

W poprzednich rozdziałach systematycznie omawialiśmy technologię JSF , organizując nasze rozważania według podstawowych koncepcji i mechanizmów. Warto jednak mieć na uwadze, że każda technologia ma pewne cechy, które trudno poddać systematycznej analizie — JavaServer Faces nie jest w tym względzie wyjątkiem. Prędzej czy później Czytelnik zada sobie pytanie „Jak to zrobić?” i nie znajdzie odpowiedzi albo dlatego, że JS F nie oferuje obsługi określonej funkcji, albo dlatego, że stosowne rozwiązanie nie jest intuicyjne. Ten rozdział ma pomóc Czytelnikowi w podobnych sytuacjach. W dość przypadkowej kolejności spró­ bujemy odpowiedzieć na pytania pojawiające się na internetowych listach dyskusyjnych.

} @End public String editO {

em.persist(selectedContact), contacts = em.createQueryC'from Contact") .getResultListO ; return "edited",

} 1 Metoda begmEdi t jest przykładem metody akcji JS F zwracającej łańcuch wynikowy, który jest następnie wykorzystywany przez implementację JS F w procesie wyboru kolejnego widoku. Nie ma w tym mechanizmie niczego szczególnego. Z naszego punktu widzenia dużo ciekawsza jest adnotacja @Begm określająca, że konwersja jest inicjowana przez metodę beginEdit(). Po zwró­ ceniu sterowania przez tę metodę framework Seam eksportuje zmienną selectedContact do za­ sięgu konwersji, gdzie uzyskujemy do niej dostęp z poziomu kodu strony edirContact.jsp. Adnotacja @End użyta dla metody edi t sygnalizuje koniec konwersacji. Oznacza to, że po zwróceniu sterowania przez tę metodę framework Seam usuwa zmienną s e lectedContact z zasięgu konwersacji. BSJJ Moglibyśmy oczywiście zrezygnować z konwersacji na rzecz składowania wybranego K U kontaktu w zasięgu sesji. Moglibyśmy wówczas usuwać ten kontakt z zasięgu sesji ręcznie w metodzie e d it i —* tym samym — skonstruować nam iastkę zasięgu konwersji. Wielu program istów decyduje się właśnie na takie rozwiązanie, jedn ak tworzenie tego rodzaju konstrukcji je s t dość nużące i zwiększa ryzyko popełnienia błędów. Dużo wygod­ niejszym rozwiązaniem jes t pozostawienie tego zadania frameworkowi i skoncentrowanie się na rozwiązaniach wyższego poziomu.

Projektowanie interfejsu użytkownika aplikacji internetowej W tym podrozdziale omówimy techniki stosowania takich konstrukcji jak wyskakujące okna, aplety czy okna dialogowe wysyłania plików. Mamy nadzieję, że przyszłe wersje technologii JS F będą oferowały wbudowane, gotowe do użycia komponenty realizujące wymienione zadania. W kolejnych punktach tego podrozdziału pokażemy, jak można własnoręcznie implementować i konfigurować niezbędne komponenty.

Gdzie należy szukać dodatkowych komponentów? Standard JS F definiuje minimalny zbiór komponentów. Jedynym komponentem standardowym wykraczającym poza podstawowe konstrukcje języka H TM L jest tabela danych. Ten nie­ wesoły wniosek bywa źródłem rozczarowania wśród programistów, którzy wzięli sobie do serca twierdzenie, jakoby JS F miał być „Swingiem aplikacji internetowych” .

548

JavaServer Faces W ielu programistów zastanawia się, dlaczego twórcy technologii JS F nie zdecydowali się na dołączenie zbioru profesjonalnie zaprojektowanych komponentów, jak drzewa czy kon­ trolki wyboru daty i godziny. Okazuje się jednak, że budowa takich komponentów wymaga sporych umiejętności i że są to umiejętności zupełnie inne od tych niezbędnych do opraco­ wywania specyfikacji nowej technologii. Aby przekonać się, jak trudne jest samodzielne implementowanie spójnej biblioteki kom­ ponentów, wystarczy się przyjrzeć komponentom biblioteki open-source nazwanej Apache MyFaces (patrz strona internetowa http://myfaces.apache.org/tomahawk/index.html). Po­ szczególne komponenty (w oderwaniu od pozostałych) są w pełni funkcjonalne, a niektóre oferują nawet atrakcyjny wygląd (patrz rysunek 13.1). Wadą tej biblioteki jest stosunkowo niewielka liczba cech wspólnych w wymiarze projektów graficznych i interfejsów progra­ mowych poszczególnych komponentów.

Rysunek 13.1. Komponenty biblioteki MyFaces Na bogaty zbiór standardowych komponentów JS F będziemy musieli poczekać przynajmniej do wersji JS F 2.0. Do tego czasu musimy się zadowolić istniejącymi bibliotekami kompo­ nentów — poniżej wymieniono i krótko opisano kilka najciekawszych przykładów takich bibliotek:

Rozdział 13. ■ Jak to zrobić? 1.

Komponenty biblioteki Apache MyFaces być może nie są idealne, ale mają dwie wielkie zalety: są dostępne za darmo i możemy z nich korzystać już teraz. Najciekawsze komponenty tej biblioteki przedstawiono w tabeli 13.1.

Tabela 13.1. Komponenty biblioteki MyFaces Znacznik

Opis

tree

Komponent drzewa.

treeColumn

Tabela, w której jedna z kolumn ma postać drzewa.

tree 2

Alternatywny komponent drzewa.

jscookMenu

Menu języka JavaScript.

pane 1Nav1ga tion

Pionowe menu hierarchiczne.

panelNavigation2

Udoskonalona wersja komponentu panelNavigat ion.

calendar

Komponent wejściowy kalendarza.

mputDate

Komponent daty i godziny.

schedule

Harmonogram z możliwością przeglądania zadań według dni, tygodni i miesięcy.

inputHtml

Komponent wejściowy dla tekstu w formacie HTML zbudowany z wykorzystaniem języka HTML.

f i lelipload

Komponent wysyłania pliku na serwer.

rssTicker

Komponent uzyskujący dane z kanału RSS.

LabPedPane

Panel podzielony na zakładki (podobny do tego z rozdziału 9.).

panelStack

Wyświetla jeden z wielu dostępnych paneli.

popup

Pomoc podręczna wyświetlana w chwili, gdy kursor znajduje się nad wskazanym komponentem.

dataTable

Rozszerzenie standardowej kontrolki dataTable uzupełnione o obsługę nagłówków sortujących i mechanizm zapisujący stan modelu.

dataScroller

Komponent umożliwiający przewijanie zawartości tabel.

newspaperTable

Dzieli zawartość długiej tabeli pomiędzy dodatkowe kolumny.

dataList

Wyświetla dane w formie listy numerowanej, listy punktowanej lub listy elementów oddzielonych przecinkami.

saveState

Zapisuje dowolny stan właściwy dla danego klienta.

aliasBean

Definiuje alias dla komponentu należącego do podwidoku.

buffer

Wizualizuje część strony w buforze z myślą o przyszłym wykorzystaniu.

stylesheet

Ładuje arkusz stylów ze wskazanej lokalizacji (względnej wobec katalogu głównego danej aplikacji internetowej).

jsValueChange ^►Listener

Mechanizm nasłuchujący zmian wartości po stronie klienta.

549

550

Rozdział 13. ■ Jak to zrobić?

JavaServer Faces 2. Zbiór komponentów AD F Faces firmy Oracle (patrz strona internetowa

http://www.oracle.com/technology/products/jclev/htdocs/partners/addins/exchange ^/jsf/doe/tagdoc/eore/imageIndex.html) cechuje się profesjonalnie zaprojektowanym wyglądem. Obejmuje zaawansowane komponenty drzew, paneli podzielonych na zakładki, tabel itp., a także udoskonalonych, bardziej eleganckich odpowiedników podstawowych przycisków i pól tekstowych FiTM L. Wspomniane komponenty zostały włączone do organizacji Apache w roku 2006, zatem powinny być publicznie dostępne (za darmo) po pewnym czasie spędzonym w „inkubatorze” Apache'a.

: imMmrn

Rysunek 13.2. Wysyłanie na serwer pliku graficznego

Plik

Edycja

Widok

Historią

S/ir® Wyślij

Zakładki

L it !

Narzędzia

swoje zdjęcie

Przeglądaj., j

Wyślij

S

i

B

i

l

l

S

iĘ B m .

Myszufritt p

i

%

O rg an iz u j ^

i

%

Dok'u’T>8nn/

| IT

O O K u w en ły

S! \ /.¡doki

▼

H

fi i !

4. Java Studio Creator ( http://developers.snn.com/prodtech/javatooIs/jscreator)

1 V

R o z m ia r

1, Pu bh czny

O s tatn io u ZVw an» rr^

H ! A ro u n d tt>e H o u se

2 kb

Skrót

2007 0 4 -1 | 4

f|§ ? D A E M O N fo o ls

ł KB

Sk roi

2007-03-0! | |

Ife ld a n V s e w

1 iii

f| § M a t m o lu d k j

1

fii'

; 1$

f

5. W ramach projektu Java BluePrints opracowano zestaw komponentów A JA X (patrz strona internetowa https://blueprints.dev.java.net/ajaxeomponents.htmI). W skład tego projektu wchodzą między innymi takie komponenty jak mechanizmy automatycznego uzupełniania danych, interfejsy usługi Google Map, pomoc podręczna czy mechanizm wysyłania plików ze wskaźnikiem postępu.

i

Oo^azy

W ysokog.

#Skype

M u zy k3

W in a m p

1 KB

Sk roi

2008-03-0!

||

3 KB

Sk roi

2007-03- Ij

j,'

3 KB

Sk ro i

2008-01

1 KB

Skrót

2008-03 -0

|

p A L L P la y e r

1 KB

Skrót

2007-02-3

I

PubK/n*

f | K « refox

2 KB

Skrót

2007 -02-1

f f lG a d u - G a d u

i KB

S k ro i

2007 12-0

2 KB

Skrót

2007-12-1

i _ r». f P o iderv

___ _____S..S.J23.HJ3...

4 Nazw a pltku

1

y

Rysunek 13.3. £lik

Edycja . Widok

M

Historia

v

tt

Zakładki

Narzędzia

.....

|

i [W szystkie pitki

1

......... 0 Apy{Mj:

Wysłany obraz

yĄ

W ysz u krw am a

f U j o u r n e y to th e Center o... |

*■

tt® K o m p u te t

Pu«OJ5

| 5,

D ara m nd

Jy p

A n d rz ejek

O Sl^n«,e /rpjpn-r^p

Ąp,

jest narzędziem stworzonym z myślą o wizualnym projektowaniu komponentów JSF . Java Studio Creator dodatkowo obejmuje zbiór gotowych, profesjonalnie zaprojektowanych komponentów. Na konferencji Java One w 2006 roku firma Sun ogłosiła plany udostępnienia kodu źródłowego tych komponentów.

li

M o w y fo ld e r

M az w a

z obsługą techniki A JA X .

L->JavaServerFaces/#software-comp.

jg

►

6

Bardziej rozbudowane listy dodatkowych komponentów można znaleźć na stronach interne­ towych http://jsfeentral.com/produets/components oraz http://www.jamesholmes.com/

cm

Pomoc

h*tp^/localho5t:SOSO/login/»nd®(Jaoej

pu lpit

3. ICEfaces (http://ieefaces.org) jest biblioteką open-source obejmującą komponenty

551

I J

/

„ ....,1

Pomoc

http dncalhn.t j Oulrgin inde>tace

|■ »i

i ijQr] C-i

,'-i

Jak zaimplementować obsługę wysyłania plików na serwer? Użytkownicy naszej aplikacji mogą potrzebować możliwości wysyłania na serwer rozmaitych plików, w tym fotografii lub dokumentów (patrz rysunki 13.2 i 13.3). Okazuje się, że technologia JS F nie oferuje standardowego komponentu wysyłania plików. Z drugiej strony, samodzielna implementacja takiego komponentu nie jest niczym trudnym. Najtrudniejszą część tego zadania zrealizowali już programiści organizacji Apache w ramach biblioteki Commons (patrz strona internetowa http://jakarta.apache.org/commons/fileupload). W tym punkcie omówimy możliwy sposób włączenia tej biblioteki do komponentu JSF. E S I Projekt MyFaees obejmuje komponent wysyłania plików, którego atrybuty różnią się ■ M il od atrybutów naszego kom ponentu (patrz strona internetow a http://myfaces. p ap ach ę. org/tomahawk/fileUpload.html). Proces wysyłania plików różni się od tradycyjnych żądań wysyłanych za pośrednictwem formularzy. Dane formularza (z wysyłanym plikiem włącznie) przekazywane pomiędzy klientem a serwerem są kodowane zgodnie ze schematem "mul npart/forni-data" (zamiast z wykorzystaniem schematu "application x-www-form-ur 1 encoded").

Oto tw ój obraz:

JS F niestety w ogóle nie obsługuje wspomnianego schematu kodowania. Można ten problem obejść, instalując serwlet filtrujący, który będzie przechwytywał przesyłane pliki i przekształ­ cał je w atrybuty żądania, jednocześnie konwertując pozostałe dane formularza na parametry żądania. (Do dekodowania żądań zakodowanych według schematu "mul Hpart/form data" wykorzystamy metodę pomocniczą biblioteki Commons). Aplikacja JS F przetwarza następnie parametry żądania, pozostając w błogiej nieświadomości co do ich oryginalnego sposobu kodowania. Metoda decode komponentu wysyłania plików albo umieszcza te dane w pliku dyskowym, albo składuje je w ramach wyrażenia reprezentu­ jącego wartość. Kod serwlelu filtrującego przedstawiono na listingu 13.1.

552

JavaServer Faces

Rozdział 13. ■ Jak to zrobić?

| Ogólnych inform acji na te m a t serw letó w filtrujących należy szukać na stronie I internetowej http://java.sun.com/products/servlet/FHters.html.

Listing 13,1, Kod klasy fileupload/src/java/com/corejsf/UploadFilter.java_________ 1

package com c o r e j s f

2 3 4

import java import java

io F i l e 10 lOtxception.

5 6

import java u t i l import j a v a . u t i l

C o l l e c t io n s . Enumeration.

53 55 56 58 59 60 61 62 63

return

f DiSkFi leitemFactory factory = new DiSkFileitemFactOry( ) if (sizeThreshold >= 0) factory.setSizeThreshold(sizeThreshold), i f (repositoryPath 1= null) factory.setRepository(new File(repositoryPath)); ServletFileUpload upload = new ServletFileUpload(factory),

66 67

68 69 70 71. 72. 73 74. 75. 76. 77. 78. 79 80 81 82 83 84 85. 86. 87

javax.servlet.FilterChain, javax.servlet.FilterConfig; javax.servlet.ServletException, javax.servlet.ServletRequest: javax.servlet.ServletResponse; javax.servlet.http.HttpServletRequest; javax.servlet.http.HttpServletRequestWrapper; org.apache.commons.fileupload.Fileltem; org.apache.commons.f i 1eupload.F i1eUploadException; org.apache.commons.f i 1eupload.disk.DiskFi1eltemFactory; org.apache.commons.f i 1eupload.servlet.ServletFi1eUpload;

public class UploadFi 1ter implements F ilte r { private int sizeThreshold = -1; private String repositoryPath; public void in it ( F i1terConfig config) throws ServletException { repositoryPath = config.getInitParameter( "com.corejsf UploadFiIter.repositoryPath"); try { String paramValue = config.getInitParameter( "com.corejsf .UploadFi1te r .si zeThreshold"); i f (paramValue != null) sizeThreshold = Integer.parselnt(paramValue); } catch (NumberFormatException ex) { ServletException servletEx = new ServletException!); servletEx.initCause(ex); throw servletEx; }

} public void destroy!) }

boolean isMultlpartContent = ServletFi leUpload isMu1tlpartContent(httpRequest) if ( ! isMultlpartContent) { cham doF 1 1ten request response)

64

11. 12. 13. 14 15. 16. 17. 18. 19. 20. 21. 22 . 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 42. 43. 44. 45. 46. 47 48. 49. 50. 51. 52.

HttpServletRequest nttpRequest = (HttpServletRequest) request

57

10 import javax.servlet.Filter,

41.

}

65

7 import java .lit 11 HashMap 8 import j a v a . u t i l L i s t 9. import j a v a . u t i 1 Map,

import import import import import import import import import import import

return

54

{

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { i f (¡(request instanceof FlttpServletRequest)) { chain.doFilter(request, response),

try

chain.doFilter(new HttpServletRequestWrapper(httpRequest) { public Map getParameterMap!) { return map. }

88

//

89 90 91. 92. 93 94 95. 96 97. 98. 99 100.

poniżej zaimplementowano mechanizmy wewnętrzne, które docelowo powinny się znaleźć w klasie opakowującej:

public StringE] getParameterValues(String name) { Map map = getParameterMapO; return (StringE]) map.get(name), } public StringgetParameter(String name) { StringE] params = getParameterVal ues(name); i f (params == null) return null, return params[0], } public EnumerationgetParameterl\lames() { Map map = getParameterMap(); return Collections.enumeration(map.keySetO),

101 .

}

102 . 103. 104. 105. 106. 107. 108. 109. }

{ List items = (Li st) upl oad.parseRequest(httpRequest), final Map map = new HashMap(), for (Fileltem item items) { String str = item.getStringO , i f (item isFormField()) map.put(item.getFieldName(), new StringE] { str }); else httpRequest.setAttribute(item.getFieldName(). item); }

}, response). } catch (FileUploadException ex) { ServletException servletEx = new ServletException!), servletEx.initCause(ex), throw servletEx, } }

553

554

Rozdział 13. ■ Jak to zrobić?

JavaServer Faces Serwlet filtrujący musimy zainstalować w pliku konfiguracyjnym w eb-infxm l , stosując następującą składnię: Upload Fi 1ter com.corejsf.Upl oadFi 1ter com.corejsf UploadFi1te r.sizeThreshold 1024 Upload Fi 1ter /upload/*

Nasz filtr wykorzystuje parametr inicjalizacji sizeThreshold do skonfigurowania obiektu komponentu wysyłania plików. Pliki, których rozmiar przekracza 1024 bajty, nie są składowane w pamięci operacyjnej, tylko w katalogu tymczasowym na dysku twardym. Przedstawiony filtr obsługuje też dodatkowy parametr inicjalizacji com. corejsf. Upl oadFi 1t e r . repositoryPath, który reprezentuje katalog docelowy dla otrzymywanych plików (gdzie są składowane przed ostatecznym utrwaleniem). Na podstawie tego parametru serwlet filtrujący ustawia odpo­ wiednie właściwości obiektu klasy Di skFi 1eUpl oad biblioteki Commons. Prezentowany mechanizm odwzorowywania filtrów wymusza stosowanie adresów U R L rozpoczynających się od przedrostka /upload/ W ten sposób eliminujemy ryzyko niepo­ trzebnego filtrowania pozostałych żądań. Strukturę katalogów naszej przykładowej aplikacji przedstawiono na rysunku 13.4.

Rysunek 13.4. Struktura katalogów aplikacji ilustrującej działanie komponentu wysyłania plików

¿3 fileupload.war

f

gS meta-IMF

j L D MANIFEST. MF \ (¡^WEB-INF | |

f-

|

|

F

j

|

| Q

|

C3 classes com corejsf j~ Q UploadFilter$l.class D UploadFilter. class UptoadRenderer.class

| Q UploadTag, class

j j

| fj

|

| |

L~

D UserBean. class

lib j Q commons-fileupload-l.l.jar L- Q commons-lo-1.2.jar

I

h D upload.tld

j

i-~ Q faces-conflg.xml

|

Q web.xml

f-

|Z3 upload | L Q uploadlmage.jsp r D index, html

j D index.jsp 1 Q submitted.jsp

555

Przejdźmy teraz do analizy samego komponentu wysyłania plików. Nasz komponent obsługuje dwa atrybuty: value i target. Atrybut value reprezentuje wyrażenie, w którym składujemy zawartość wysyłanych plików. Takie rozwiązanie zdaje egzamin w przypadku niewielkich plików — na potrzeby dłuższych plików będziemy korzystali z atrybutu target opisującego ich lokalizację (zamiast zawartości). Implementacja klasy FileUploadRenderer jest stosunkowo prosta (patrz listing 13.2). Metoda encodeBegin odpowiada za wizualizację odpowiedniego elementu H TM L. Metoda decode uzyskuje pliki umieszczone uprzednio przez serwlet filtrujący w atrybutach żądania, po czym rozdziela je zgodnie z ustawieniami zawartymi w atrybutach znacznika. Atrybut target określa lokalizację pliku względem katalogu głównego danej aplikacji internetowej (po stronie serwera).

Listing 13.2. Kod klasy fileupload/src/java/com/corejsf/UploadRendererjava 1 package com.corejsf; 2.

3. 4. 5 6. 7. 8. 9 10. 11 12. 13. 14 15 16. 17 18. 19. 20 21. 22. 23. 24. 25. 26. 27 28. 29. 30. 31 32. 33. 34. 35. 36 37. 38 39 40. 41 42.

import java.io .File, import java io .IOException; import java.io.InputStream; import java.io.UnsupportedEncodingException; import javax.el.ValueExpression; import javax.faces.FacesException, import javax.faces.component.EditableValueHolder; import javax.faces.component.UlComponent, import javax.faces.context.External Context; import javax.faces.context.FacesContext, import javax.faces.context.ResponseWriter; import javax.faces.render Renderer; import javax.servlet.ServletContext; import javax.servlet.http.HttpServletRequest; import org.apache.commons.fileupload.Fileltem, public class UploadRenderer extends Renderer { public void encodeBegin!FacesContext context, UlComponent component) throws IOException { i f ( ¡component.isRendered!)) return, ResponseWriter writer = context.getResponseWriter!); String clientld = component.getClientld(context); writer startElement!"input", component), writer writeAttribute!"type", "file ", "type"); writer writeAttribute!"name", clientld, "clientld"); writer.endElement!"input"), writer.flush!), } public void decode(FacesContext context, UlComponent component) { External Context external = context.getExternalContext!), HttpServletRequest request = (HttpServletRequest) external getRequest(), String clientld = component.getClientld(context); Fileltem item = (Fileltem) request,getAttribute(clientld), Object newValue, ValueExpression valueExpr = component.getValueExpressionCvalue"); i f (valueExpr != null) {

556

Rozdział 13. ■ Jak to zrobić?

JavaServerFaces 43. 44. 45. 46 47 48. 49. 50. 51. 52 53. 54. 55 . 56 57. 58. 59. 60. 61 62 63. 64 65 66. 67. 68 69. 70. 71. 72. 73 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85

Class valueType = valueExpr.getType(context.getELContextO); i f (valueType == byte[].class) { newValue = item.getO; } else i f (valueType == IriputStream.class) { try { newValue = item.getInputStream(); } catch (IOException ex) { throw new FacesException(ex), } } else { String encoding = request.getCharacterEncoding(); i f (encoding != null) try { newValue =item.getString(encoding), } catch (UnsupportedEncodingException ex) { newValue = item.getString!);

} else newValue = item.getString!); } ((EditableValueHolder) component).setSubmittedValue(newValue); ((EditableValueHolder) component).setValid(true), }

20 2 1. 22 . 23. 24. 25. 26. 27. 28. }

private ValueExpression value; private ValueExpression target; public String getRendererType!) { return "com.corejsf.Upload"; } public String getComponentType() { return "com.corejsf.Upload", } public void setValue(ValueExpression newValue) { value = newValue, } public void setTarget(ValueExpression newValue) { target = newValue; public void setProperties(UIComponent component) { super.setProperties(component), component.setValueExpression!"target", target); component.setValueExpression("value", value),

public void releaseO super. releaseO; value = n u ll; target = nul 1 ;

Object target = component.getAttributesO.get("target'"); i f (target != null) { File file ; i f (target instanceof File) f ile = (File) target; else { ServletContext servletContext = (ServletContext) external .getContext!); String realPath = servletContext.getRealPath(target.toStringO), f ile = new File!real Path); } try { item .w rite(file), } catch (Exception ex) { throw new FacesException(ex);

86.

}

87.

}

}

88 89.

4. i 5. i 6. 7. P 8. 9. 10 . 11. 12 . 13. 14. 15. 16. 17 18. 19

557

}

W odpowiedniej klasie obsługującej znacznik (której kod przedstawiono na listingu 13.3) trudno doszukać się czegokolwiek interesującego.

Listing 13.3. Kod klasy fileupload/src/java/com/corejsf/UploadTagJava_______________________________ 1 . package com.corejsf, 2.

3 import javax.el.ValueExpression;

I wreszcie, pracując ze znacznikiem komponentu wysyłania plików, musimy pamiętać o ustawieniu właściwego schematu kodowania (a konkretnie "mul ti part/form-data" — patrz listing 13.4).

Listing 13.4. Kod strony fileupload/web/upload/uploadlmage.jsp 1 2

3 4 5 6

7 8 9 10 11

12 13 14 15 16 17 18

<£@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> taglib uri="http://java.sun.com/jsf/html" prefix="h" %> taglib uri="http://corejsf.com/upload" prefix="corejsf" %> Wyślij swoje zdjęcie;

558

Rozdział 13. ■ Jak to zrobić?

JavaServer Faces

Wartości reprezentujące obszary zdefiniowano w pliku konfiguracyjnym faces-config.xmk

Jak wyświetlać mapę obrazów? Implementacja mapy obrazów (ang. image map) wymaga zdefiniowania atrybutu usemap w ramach elementu h: output Image:

Właściwą mapę możemy następnie wskazać za pośrednictwem następującej konstrukcji H TM L w kodzie strony JSF :

Prezentowane podejście nie gwarantuje jednak właściwej integracji z mechanizmami nawigacji JSF. Byłoby lepiej, gdyby obszary map przypominały swoim działaniem przyciski lub łącza. W rozdziale 12. podręcznika poświęconego technologii Java E E 5 (patrz strona internetowa http://java.sun.eom/javaee/5/docs/tutorial/doc) przedstawiono przykłady użycia znaczników map i area, które umożliwiają skuteczne obejście tego ograniczenia. Aby zweryfikować funkcjonowanie mapy obrazów w praktyce, warto uruchomić za pośred­ nictwem przytoczonego podręcznika aplikację internetową bookstore6 (patrz rysunek 13.5). Sposób użycia tych znaczników w przykładowej aplikacji przedstawiono poniżej:

NA com.sun.bookstore6.model ImageArea application coords 53.109.1.110,2,167,19,168,52.149,67.164,67,165,68.167.70.168.72,170,74,172,75,174.77, 175,79,177,81,179.80.179,77.179,81,179,81,178,80,178,82,211.28.238,15.233,15,242,31. 252,36,247,36,246,32,239.89.209,92,216,93.216,100,216,103,218.113,217,116,224.124,221, 128.230,163,234,185,189,178,177.162.188,143,173,79,173,73,163,79,157.64,142,54.139,53, 109

Alternatywnym rozwiązaniem byłoby użycie techniki, którą omówiliśmy w rozdziale 7. tej książki. Wystarczy umieścić obraz w ramach przycisku polecenia i przetwarzać współrzędne poziome i pionowe po stronie serwera:

Musimy jeszcze dołączyć metodę nasłuchującą akcji, która uzyska identyfikator przycisku, dołączy do niego przyrostki . x oraz .y, po czym odnajdzie wartości współrzędnych w ramach mapy żądania. Możemy te wartości przetwarzać w dowolny sposób. Opisywana technika wymaga jednak od serwera aplikacji wiedzy o geometrii obrazu.

Jak dołączać aplet do naszej strony? Znacznik apletu należy włączyć do kodu strony internetowej w zwykły sposób (przykład takiego rozwiązania przedstawiono na listingu 13.5). Strona, której kod przedstawiono na wspomnianym listingu, wyświetla aplet wykresu (patrz rysunek 13.6) zaczerpnięty z roz­ działu 10. książki Core Java™ 2, vol. 1 1autorstwa Caya Horstmanna i Gary’ego Cornelia.



Listing 13.5. Kod strony applet/web/index.jsp Rysunek 13.5.

1 . 2. <%® taglib uri="http://java.sun.com/jsf/core" prefix="f" £>

Przykładowy komponent mapy obrazów

3. 4. 5. 6. 7. 8. 9.

10. 11. 12. 13.

taglib uri="http://java.sun.com/jsf/html" prefix="h" %>



Angielski Niemiecki Francuski Hiszpański

I Zakończono

7W!W 7r~^rr~!~T:

559

1 Polskie wydanie: Java 2. Podstawy, Helion, 2003 — przyp. tłum.

560

Rozdział 13. ■ Jak to zrobić?

JavaServer Faces

Rysunek 13.6. Aplet wykresu

Pi7.yktad iavsw

Plik fcdycja Widok Historia Zakładki Narzędzia Pomoc

|jg f fjl *# (¡P llf <

561

■ W pewnych okolicznościach warto rozważyć rezygnację ze znacznika applet na rzecz znacznika jsp:plugin. Znacznik jsp:plugin generuje element modułu rozszerzenia Javy (ang. Java Plug-in). Przykład takiej konstrukcji przedstawiono poniżej:

O to nasz obraz.

Średnice planet



ZtemtB

*o«iSs? Satoo'

Więcej informacji na temat modułu rozszerzenia Javy można znaleźć na stronie internetowej

http://java.sun.com/products/plagin. Zakończono

Jak generować dane binarne w ramach stron JSF? W pewnych sytuacjach programista staje przed koniecznością opracowania rozwiązania zdolnego do dynamicznego generowania takich danych binarnych jak obraz czy plik PDF. Realizacja tego zadania w technologii JS F jest o tyle trudna, że domyślny mechanizm obsługi widoku wysyła do obiektu odpowiedzialnego za zapis odpowiedzi dane tekstowe (zamiast strumienia binarnego). Teoretycznie wymiana tego mechanizmu jest możliwa, jednak dużo prościej byłoby użyć serwletu pomocniczego generującego odpowiednie dane binarne. Nie oznacza to oczywiście, że chcemy rezygnować z wygody oferowanej przez technologię JS F (szczególnie przez wyrażenia reprezentujące wartość) w zakresie operowania na danych wynikowych. Chcielibyśmy dysponować znacznikiem JS F gromadzącym niezbędne dane i przekazującym je serwletowi. W tym punkcie będziemy się posługiwać przykładem w postaci znacznika JS F tworzącego obraz wykresu (patrz rysunek 13.7). Wspomniany obraz obejmuje dynamicznie generowane dane sformatowane zgodnie ze standardem JP EG .

E Ti

E ''O

T3
14 15. 17. 18. 19 20. 2 1. 22 . 23. 24 25. 26 28. 29. 30 31. ^paran name="value 5 va1ue= "88000"/> 32 33 34 name-"value 8 value="30600"/> 35 name="value 9 value="1430"/> 36 37 38 39 40 41 42 43

Dołączając aplet do strony naszej aplikacji internetowej, musimy mieć na uwadze dwa ważne aspekty: ■ Jeśli pracujemy w technologii JS F 1.1 i użyjemy znacznika applet w ramach komponentu JS F odpowiedzialnego za wizualizację swoich komponentów potomnych (np. w ramach siatki), będziemy się musieli posłużyć następującą konstrukcją: ..

^ H | Przedstawiony wykres będziemy wykorzystywali w roli przykładu techniki operowania ■ M il na danych binarnych. Czytelnicy zainteresowani prezentowaniem bardziej wyrafi­ nowanych wykresów za pośrednictwem swoich aplikacji internetowych powinni skorzystać z kom ponentu ChartCreator (patrz strona internetowa http://jsf-comp.sourceforge.net/ ^ components/chartcreator). 4 Na listingu 13.6 (w dalszej części tego punktu) przedstawiono kod strony JS P obejmujący między innymi następujący znacznik: session = external,getSessionMap(), session.put(id, data),

Nasz serwlet uzyskuje obiekt transferu ze struktury mapy sesji, po czym wywołuje metodę w rite tego obiektu. Wspomniana metoda odpowiada za wizualizację obrazu do postaci strumienia odpowiedzi.

1 . 2 taglib uri="http://java.sun.com/jsf/core" prefix="f" 3 4. 5

6 7. 8. 9.

10 11. 12 13. 14. 15 16 17. 18

%>

taglib uri="http://java.sun.com/jsf/html" prefix="h" %> taglib uri="http://corejsf com/chart" prefix="corejsf" %>

0to nasz obraz:

Listing 13.7. Kod klasy binaryl/src/java/com/corejsf/ChartRenderer.java 1 package com.corejsf, 2.

3. 4 5. 6. 7. 8. 9

import import import import import import import

Java io.IOException; java.util Map: javax.faces.component.UlComponent; javax.faces.context.External Context, javax.faces.context.FacesContext, javax.faces.context.ResponseWriter; javax.faces.render.Renderer;

10.

11. public class ChartRenderer extends Renderer { 12. private static final int DEFAULT_WIDTH = 200: 13 private static final int DEFAULT_FIEIGHT = 200; 14. 15. public void encodeBegin(FacesContext context, UlComponent component) 16 throws IOException {

564

Rozdział 13. ■ Jak to zrobić?

JavaServer Faces 17. 18 19. 20 21. 22. 23. 24 25. 26 27. 28. 29. 30. 31. 32 33. 34. 35. 36 37 38. 39. 40. 41. 42. 43 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. }

i f ( ! component.isRenderedO) return; Map attributes = component.getAttributes(); Integer width = (Integer) attributes.get("width"); i f (width = null) width = DEFAULT_WIDTH; Integer height = (Integer) attributes,get("height"); i f (height == null) height = DEFAULT_HEIGHT; String t it le = (String) attrib u tes.g et("title"); i f (t it le == null) t it le = String[] names = (Strin g []) attributes.get( "names"); doublet] values = (doublet]) attributes.getCvalues"); i f (names == null || values == null) return; ChartData data = new ChartDataO; data.setWidth(width); data.setHeight(height); d ata.se tT itle (title ); data.setNames(names); data.setValues(values); String id = component.getClientld(context); External Context external = FacesContext.getCurrentInstance() .getExternalContext(); Map session = external,getSessionMap(); session.put(id. data); ResponseWriter writer = context,getResponseWriter(); writer.startElement( "img", component): writer.writeAttributeC'width", width, null); writer.writeAttributeC'height", height, null); String path = external.getRequestContextPath(); writer.writeAttributeC'src", path + "/BinaryServlet?id=" + id, null); writer.endElement( " img"); context.responseComplete(); }

20

21. 22. 23 24 25 26 27 28. 29. 30. 31. 32. 33. 34. 35. 36.

response.setContentType(data,getContentType()); OutputStreani out = response.getOutputStream(); data.write(out), out.closeO, } protected void doGet(HttpServletRequest throws ServletException, IOException { processRequest(request, response), }

request,HttpServletResponse response)

protected void doPost(HttpServletRequest throws ServletException, IOException { processRequest(request, response), } }

request, HttpServletResponse response)

Listing 13.9. Interfejs binaryl/src/java/com/corejsf/BinaryData.java 1 . package com.corejsf; 2.

3 import java.io.IOException; 4. import java io.OutputStream; 5 6 public interface BinaryData { 7. String getContentType(); 8 void write(OutputStream out) throws IOException, 9-

}

Listing 13.10. Kod klasy binaryl/src/java/com/corejsf/ChartData.java 1 . package com.corejsf;

1 . package com.corejsf; 2.

import java.io.IOException; import java.io.OutputStream; import import import import import

HttpSession session = request,getSession(), String id = request.getParameter("id"); BinaryData data = (BinaryData) session.getAttribute(id);

2.

Listing 13.8. Kod serwletu binaryl/src/java/com/corejsf/BinaryServlet.java

3. 4. 5. 6. 7 8. 9. 10

17 18. 19.

javax.servlet.ServletException; javax.servlet.http.HttpServlet; javax.servlet.http.HttpServletRequest; javax.servlet.http.HttpServletResponse; javax.servlet.http.HttpSession;

11.

12. public class BinaryServlet extends HttpServlet { 13. protected void processRequest(HttpServletRequest request, 14. HttpServletResponse response) 15. throws ServletException, IOException { 16.

3 import java.awt.Col or; 4. import java.awt.Font ; 5. import java.awt.Graphics2D, 6 import java.awt.font.FontRenderContext; 7. import java.awt.font.LineMetrics; 8 . import java.awt,geom.Rectangle2D, 9 import java.awt.image.Bufferedlmage; 10 import java.io.IOException; 11. import java.io.OutputStream, 12. import java.util.Iterator, 13 import javax imageio.ImagelO; 14. import javax imageio.ImageWriter ; 15. 16 public class ChartData implements BinaryData { 17 18. private int width, height; 19. private String tit le ; 20. private String[] names, 2 1. private doublet] values;

565

566

JavaServerFaces

Rozdział 13. ■ Jak to zrobić?

22 . 23 24 25 26 27 28 29

79 80 81 82 83 84 85

private static final int DEFAULT_WIDTH = 200; private static final int DEFAULT_HEIGHT = 200, public ChartDataO { width = DEFAULT_WIDTH, height = DEFAULT HEIGHT; }

86

30

31 32 33 34 35 36 37 38 39. 40 41 42 43. 44 45. 46. 47 48. 49.

87

public void setWidth(int width) { this.width = width, }

88 89 90 91. 92. 93. 94. 95 96. 97 98 99 100. 101 102. 103 104. 105 106. 107 108 109. 110

public void setHeight(int height) { this.height = height: } public void setTitle(String t it le ) { th is .title = t it le ; } public void setNames(String[] names) { this.names = names: } public void setValues(double[] values) { this.values - values; }

50.

51. 52 53. 54. 55 56. 57 58. 59. 60 61. 62. 63 64. 65.

public String getContentType() { return "image/jpeg"; } public void write(OutputStream out)throws IOException { Bufferedlmage image = new Bufferedlmage(width, height, Bufferedlmage.TYPE_INT_RGB); Graphics2D g2 = (Graphics2D) image.getGraphics(); drawChart(g2, width, height, t it le , names, values); Iterator iter =ImagelO.getlmageWritersByFormatNameCjpeg"); ImageWriter writer = iter.nextO, writer setOutput(ImageIO.createImageOutputStream(out)); writer.write(image), }

66

67

68 69

private static void drawChart(Graphics2D g2, int width, int height, String t it le , StringE] names, doubled values) {

czyści tło:

70.

//

71. 72. 73 74. 75. 76 77

g2.setPaint(Color.WHITE); g2. f i l l (new Rectangle2D.Doubled, 0, width, height)). g2.setPaint(Color.BLACK),

78

//

i f (names == null || values == null || names.length return;

wyznacza wartość minimalną i maksymalną:

i f (values == null) return. double minValue = 0, double maxValue = 0. for (double v values) { i f (minValue > v) minValue = v; i f (maxValue < v) maxValue - v. } i f (maxValue == minValue) return.

!= values length)

111. 112

113 114. 115 116 117 118 119 120

121 122. 123. 124 125. 126. 127. 128 129. 130 . 131 132 133 134 135.

Font titleFont = new Font("SansSerif", Font.BOLD, 20), Font label Font = new Font("SansSerif", Font.PLAIN, 10). / / wyznacza rozmiar tytułu: FontRenderContext context = g2.getFontRenderContext(), Rectangle2D titleBounds = titleFont.getStringBounds(title, context), double titleWidth = titleBounds.getWidthO . double top = titleBounds,getHeight();

I I rysuje tytuł: double y = -titleBounds.getYO , double x = (width - titleWidth) / 2; g2.setFont(titleFont), g2.drawString(title, (float)x, (float)y), //

wyznacza rozmiar etykiet poszczególnych słupków:

LineMetrics labelMetrics = labelFont.getLineMetricsC", context); double bottom = labelMetrics,getHeight(): y = height - labelMetrics,getDescent(); g2.setFont(labelFont),

I I wyznacza współczynnik skalowania i szerokość słupków: double scale = (height - top - bottom) / (maxValue - minValue); int barWidth = width / values.length; // jysuje słupki: for (int i = 0; i < values length; i++) { //wyznacza współrzędne wierzchołków prostokąta reprezentującego słi4pek: double xl = i * barWidth + 1, double yl = top, double barHeight = values[i] * scale; i f (values[i] >= 0) y l += (maxValue - values[i]) * scale, else { yl += maxValue * scale, barHeight = -barHeight, }

I I wypełnia słupek i rysuje jego krawędzie: Rectangle2D rect = new Rectangle2D.Double(xl, yl, barWidth - 2, barHeight); g2.setPaint(Color.RED); g2.fi11(re c t); g2.setPaint(Color BLACK),

567

568

Rozdział 13. ■ Jak to zrobić?

üavaServer Faces 136 137 138 139. 140 141 142. 143 144 145. 146. 147 }

g2 .draw(rect), / / wyświetla wyśrodkowaną etykietę pod słupkiem: Rectangle2D label Bounds = labelFont.getStringBounds(names[i], context). double label Width = 1abelBounds.getWidth(). x = i * barWidth + (barWidth - labelWidth) / 2, g2.drawString(names[i], (float)x, (float)y). } }

Istnieje też możliwość generowania danych binarnych bezpośrednio z poziomu stron JS F (bez konieczności stosowania dodatkowego serwletu). Tego rodzaju rozwiązania wymagają jednak wyboru właściwego czasu odczytywania strumienia wejściowego (zanim implementa­ cja JS F przystąpi do zapisywania odpowiedzi). Nie możemy do tej operacji wykorzystać mechanizmu wizualizacji komponentów, ponieważ komponenty JS F wchodzą w skład danych wyjściowych strony, ale tych danych nie zastępują. W tej sytuacji warto zainstalować fazowy obiekt nasłuchujący, który będzie aktywowany po zakończeniu fazy przywracania widoku. Nasz obiekt zapisuje dane binarne, po czym wywołuje metodę responseComplete celem pominięcia pozostałych faz cyklu życia JS F : public class BinaryPhaseListener implements PhaseListener { public Phaseld getPhaseldO { return Phaseld.RESTORE_VIEW.

} public void afterPhase(PhaseEvent event) { i f (! event,getFacesContext() ,getViewRoot() ,getViewId() ,startsWith("/binary")) return, HttpServletResponse servietResponse = (HttpServletResponse) external.getResponseO. servietResponse.setContentType(data.getContentType()), OutputStream out - servietResponse.getOutputStream(); Zapis danych do strumienia out context.responseComplete();

Akcja filtrowania jest podejmowana wyłącznie w przypadku widoków, których identyfikatory rozpoczynają się od przedrostka /binary. Podobnie jak w poprzednim rozwiązaniu (zbudo­ wanym na bazie serwletu) klucz obiektu transferu danych jest przesyłany w formie parametru żądania GET. Uruchomienie tego filtru wymaga przypisania adresowi obrazu prawidłowego adresu U R L implementacji JS F (np. nazwaaplikacji/hinary.faces?id=key lub nazwaaplikacji/faces/ ^binary?id=key). Dokładny typ zależy od sposobu odwzorowywania serwletu JSF. Mecha­ nizm odpowiedzialny za wizualizację uzyskuje właściwy format za pośrednictwem metody getActionllRL obiektu obsługującego widok: ViewHandler handler = context.getApplication() ,getViewHandler(), String url = handler.getActionURL(context, "/binary),

569

Kod fazowej klasy nasłuchującej przedstawiono na listingu 13.11. Instalacja tej klasy wymaga zdefiniowania następującego elementu w pliku konfiguracyjnym faces-config.xml :

<1 i fecycle> com.corejsf.BinaryPhaseListener

Listing 13.11. Kod klasy binary2/src/java/com/corejsf/BinaryPhaseListener.java 1 . package com.corejsf; 2 3 import java.io .IOException, 4 import java i o.OutputStream. 5. import java.util.Map; 6 import javax.faces.FacesException; 7. import javax.faces.context.External Context, 8 import javax faces.context.FacesContext. 9. import javax faces.event.PhaseEvent, 10 . import javax.faces.event.Phaseld, 11 import javax.faces.event.PhaseListener, 12. import javax.servlet.http.HttpServletResponse; 13. 14. public class BinaryPhaseListener implements PhaseListener { 15. public static final String BINARY_PREFIX ="/binary"; 16. 17. public static final String DATA_ID_PARAM ="id", 18 19 public Phaseld getPhaseldO { 20. return Phaseld.RESTORE_VIEW, 21

}

22

23 24. 25. 26 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40 41. 42. 43. 44. 45. 46. 47 48.

public void beforePhase(PhaseEvent event) { } public void afterPhase(PhaseEventevent) { i f ( ! event,getFacesContext() ,getViewRoot() .getViewIdO.startsWith( BINARY_PREFIX)) return; FacesContext context = event,getFacesContext(); External Context external = context.getExternalContext(); String id = (String) external.getRequestParameterMapO,get(DATA_ID_PARAM), HttpServletResponse servletResponse (HttpServletResponse) external.getResponseO; try { Map session = external .getSessioriMap() ; BinaryData data = (BinaryData) session.get(id), i f (data != null) { servletResponse.setContentType(data.getContentType()); OutputStream out =servletResponse.getOutputStream(); data.write(out); } } catch (IOException ex) { throw new FacesException(ex); } context.responseComplete();

570

JavaServerFaces

Rozdział 13. ■ Jak to zrobić?

Jak prezentować ogromne zbiory danych podzielone na mniejsze strony? Z rozdziału 5. wiemy, że tabele można rozbudowywać o dodatkowe paski przewijania. Jeśli jednak prezentowana tabela jest zbyt duża, wolelibyśmy jej nie odsyłać do aplikacji klienckiej (zwykle jest to przeglądarka) w całości. Pobieranie takiej tabeli wymaga wiele czasu, a w wielu przypadkach okazuje się, że użytkownicy są zainteresowani zaledwie kilkoma pierwszymi wierszami. Standardową konstrukcją interfejsu użytkownika wykorzystywaną do nawigowania w ramach wielkich zbiorów danych jest podział na strony, czyli prezentowanie zbioru łączy wskazują­ cych na poszczególne strony tabeli (wraz z łączami do poprzedniej i kolejnej strony oraz — jeśli liczba tych stron jest naprawdę duża — łączami przeskakującymi o kilka stron w obu kierunkach). Na rysunku 13.8 przedstawiono konstrukcję umożliwiającą przeglądanie bardzo dużego zbioru danych — predefiniowanych stref czasowych uzyskanych za pośrednictwem wywołania metody java ú til TimeZone.gelAva i labie! Ds().

Tabela podzielona na wiele stron

fcdyeja

0t * 0

Widok

Historia

'|p

Zakładki

I

Narzędzia

Pomoc

0

/ j »jjjjj

httpiiVlocalho;t:8fl80/paget ir

[N i

Anjervkd/Aigeiitvna^shuaid pjnerck.i/f-aliia Amervka/Tel-ni Amen/t a/P ucn ¿ . au r ? Amervkdy^atamaii a ' 'averme .-juervkd/'>i -i'l'd «¿nervl'd/G tkał rtmervl' a/Juiuv

av

Listing 13.12. Kod klasy pager/src/java/com/corejsf/PagerRenderer.java_______________________________ 1 . package com.corejsf, 2 3 import java i o.IOException. 4. import java.util.Map, 5 import javax.faces.component.UlComponent. 6 . import javax.faces.component.UI Data, 7 import, javax faces component UIForm 8

import javax faces

context FacesContext.

9

import javax faces

c o n t e x t .R e s p o n se w rite r.

10 11

13 M 15 16 17 18 19 20

import javax f a c e s . render Renderer public c la s s PagerRenderer extends Renderer

{

public void encodeBeginfFacesContext context. UlComponent component) tnrows lOException j S t r in g id = component getC1lentIdicontext). UlComponent parent = component. while (¡(parent instanceof ulForm)) parent = parent.getParent() String formId = parent getC1ientld(context). Responsewriter writer = context getResponseWrit e r ().

21

Arnen/kd/F -rtalcza

:_

Przypuśćmy, że użytkownik klika łącze >, aby przejść na następną stronę. Nasz komponent lokalizuje tabelę danych i aktualizuje właściwość f ir s t (zwiększając ją o wartość właści­ wości rows). Odpowiedni kod można znaleźć w metodzie decode klasy PagerRenderer (patrz listing 13.12).

12

Test łątzy przewijania - Mozslla fweftw

Plik

_

%

Rysunek 13.8.

'j j

000 .

Okazuje się niestety, że technologia JS F nie oferuje wbudowanego komponentu dzielenia długich zbiorów danych na mniejsze strony. Z drugiej strony, napisanie odpowiedniego kom­ ponentu jest dość proste — w tym punkcie omówimy kod umożliwiający stosowanie lub modyfikowanie tego komponentu w ramach naszych własnych aplikacji. Mechanizm podziału na strony z natury rzeczy jest stosowany łącznie z tabelą danych. Musimy określić identyfikator tej tabeli danych, liczbę stron wyświetlanych przez mechanizm podziału oraz style zaznaczonych i niezaznaczonych łączy. Przykład takiej konstrukcji przedstawiono poniżej:

571

22 23 24 25 26 27 28. 29. 30. 31. 32. 33. 34 35. 36. 37. 38. 39 40. 41 42 43. 44. 45. 46. 47. 48 49. 50.

String sty 1eC1ass = (String) component getAttributes() get( "styleC1ass"). String selectedStyled ass = (String) component getAttri butes() get( "selectedStyleClass"). String dataTab 1eJd = (String) component getAttributes() get( "dataTableld"). Integer a = (Integer) component getAttributes() get( "snowpages") int showpages = a == null ? 0 a intValueO. / / lokalizujemy komponent właściwy dla danego identyfikatora: UIData data = (UIData) component findComponent(dataTableld). int firs t = data.getFirst(); int itemcount = data.getRowCount(), int pagesize = data,getRows(); i f (pagesize <= 0) pagesize = itemcount, int pages = itemcount / pagesize, i f (itemcount % pagesize != 0) pages++; int currentPage = firs t / pagesize; i f (fir s t >= itemcount - pagesize) currentPage = pages - 1, int startPage = 0, int endPage = pages, i f (showpages > 0) { startPage = (currentPage / showpages) * showpages; endPage = Math,min(startPage + showpages, pages): } i f (currentPage > 0)

572

Rozdział 13. ■ Jak to zrobić?

JavaServer Faces 51 52. 53. 54 55 56 57 58 59. 60. 61. 62 63 64. 65 66. 67 .

writeLink(writer, component, formld, id, i f (startPage > 0) writeLink(writer, component, formld, id, " « " ,

86 87. 88. 89. 90. 91. 92 93. 94 95. 96 97. 98. 99. 100 101.

styleClass).

for (int i = startPage; i < endPage; i++) { writeLink(writer, component, formld, id, "" + (i + 1), i == currentPage ? selectedStyleClass ; styleClass); } i f (endPage < pages) writeLink(writer, component, formld, id,

styleClass),

i f (firs t < itemcount - pagesize) writeLink(writer, component, formld. id. ">", styleClass);

I I pole ukryte, w którym przechowujemy wynik:

68 69. 70 71. 72. 73. 74. 75 . 76. 77. 78. 79. 80. 81 82. 83. 84. 85

styleClass);

writeHiddenField(writer, component, id); } private void writeLink(ResponseWriter writer, UlComponent component, String formld, String id, String value, StringstyleClass) throws IOException { writer .writeTextC ", null); writer.startElement("a", component); writer,writeAttribute("href", "#", null); writer.writeAttributeC'onclick", onclickCode(formId, id, value), null), i f (styleClass != n u ll) writer.writeAttributeC'class", styleClass, "styleClass"); writer writeText(value, null), writer.endElementC'a"), } private String onclickCode(String formld, String id, String value) { StringBuilder builder = new StringBui1der(); bui1 der.append("document.forms["); builder.append( ); builder.append(formld); builder.appendC'"), builder.append(" ] [ '" ) , builder.append(id); builder.appendC ' ] .value-'"); builder,append(value); builder appendC '; " ) ; builder.appendC document.forms["); builder.appendC""); builder.append(formld), builder.append( ); builder.appendC] .submitO"), builder.appendC ; return false;"); return buiIder.toString();

102.

}

103. 104. 105. 106. 107 108 109.

private void writeHiddenField(ResponseWriter writer, UlComponent component, String id) throws IOException { writer.startElement("input", component); writer.writeAttributeC'type", "hidden", null), writer.writeAttributeC'name", id, null); writer.endElementCinput");

no.

573

}

111. 112 113. 114 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143.

public void decode(FacesContext context, UlComponent component) { String id = component.getClientld(context); Map parameters = context.getExternalContext 0 .getRequestParameterMap(); String response = (String) parameters.get(id); i f (response — null || response.equalsC")) return, String dataTableld = (String) component.getAttributesO.getC'dataTableld"), Integer a = (Integer) component.getAttributesO,get("showpages"), int showpages - a — null ? 0 : a.intValue(); UIData data = (UIData) component.findComponent(dataTableld); int firs t = data.getFirst(); int itemcount - data,getRowCount(); int pagesize = data.getRows(); i f (pagesize <= 0) pagesize = itemcount; i f (response.equals("<")) firs t -= pagesize; else i f (response.equals(">")) firs t += pagesize; else i f ( response.equals( " « " ) ) firs t -= pagesize * showpages; else i f (response.equals( " » " ) ) firs t +- pagesize * showpages; else { int page = Integer.parselnt(response); firs t = (page - 1) * pagesize; } i f (fir s t + pagesize > itemcount) firs t - itemcount - pagesize; i f (firs t < 0) firs t = 0; d ata.se tF irst(first); } }

Z naszego punktu widzenia bardziej interesująca jest metoda encode, która generuje zbiór niezbędnych łączy. Podobnie jak w przypadku łączy poleceń generowane łącza aktywują kod języka JavaScript ustawiający wartość pola ukrytego i wysyłający formularz. Na listingu 13.13 przedstawiono kod strony index.jsp generujący tabelę i mechanizm dzielący jej zawartość pomiędzy strony. Przykładowy komponent wspomagający przedstawiono na listingu 13.14. ijania danych wchodzący w skład ł.myfaces.apache.org/tomahawk/

^d a ta S em 1 M .h m ,

rrx v'.:v..■. r /cc ; -

Î

, ,

v.-,-, y

Listing 13.13. Kod strony pager/web/index.jsp __________________________________ 1 . 2. <%@ taglib uri="http://java.sun.com/jsf/core" prefix-"f" 3 4. 5. 6.

%>

taglib uri="http;//java.sun.com/jsf/html" prefix="h" %> <%@ taglib uri="http;//corejsf.com/pager" prefix="corejsf" %>

574

Rozdział 13. ■ Jak to zrobić?

üavaServer Faces 7



8. 9

10 11. 12 13 14 15. 16 17. 18 19 20 21 22 23 24



25 26 27



575

Funkcja doPopup obejmuje wyrażenia języka JavaScript odpowiedzialne za wyświetlanie dodat­ kowego okna. Zdefiniowano tę funkcję w ramach znacznika script na poziomie nagłówka strony. Z prawdziwym wyzwaniem mamy do czynienia dopiero wtedy, gdy chcemy przekazywać dane pomiędzy oknem głównym a oknem wyskakującym. Przeanalizujmy teraz konkretny przykład. Na rysunku 13.9 przedstawiono stronę internetową wraz z wyskakującym oknem, które obejmuje listę stanów U SA lub prowincji Kanady (w za­ leżności od zaznaczonego przycisku opcji). Sama lista jest generowana przez komponent wspomagający, który pracuje po stronie serwera.

Rysunek 13.9.

'-‘-L i 1 1

tH Prosta aplikacja JavaServer Faces - MoztUa Fírefox

Przykład wyskakującego okna, za pośrednictwem którego użytkownik może wybrać stan lub prowincję

Pltfc

♦

fccłycja - j #

Widok ;

ę

Cl.-ii

Histona

: n ;-'rt

5

Zakładki i

tVatïçdaa

23

j

: :0

Pomoc

... http://localhost:80í| * ¡ f l f

¡T|gj

El .ma i.i

a

Xtan/pi ■■wur la

i D atei j H

Be:// -

j

.-Jat'Oin.i

Listing 13.14. Kod komponentu pager/src/java/com/corejsf/BackingBeanjava

rtltts k j ■"JIZ t,a

1 package com.corejsf 2

f Zam oczono

3 public class BackingBean {

.'.r m n n c u i

1 l ak T3 1 .-tu líu cc,-.,

'

Ú ¡:;

1 D a k o ta P ó łn o c n a

4

p r í v a t e S i r i ng[ ] dala = jav a u t i l

5

p u blic S i r i ng[

TimeZone get-AvailabielDsC)

] getDatd () { re lu rn

data.

i

}

6 {

7

public boolean getDummyO

8 9

public void seiDummyCboolean b) { }

return

f a ls e .

1 [ p LivVcü>

[

1

Jak generować wyskakujące okna? Podstawowy mechanizm wyświetlania wyskakujących okien jest bardzo prosty. Wystarczy użyć następującego wywołania języka JavaScript: popup = window.open(url, name, features); popup.focusO :

Parametr features ma postać łańcucha — przykład definicji tego parametru przedstawiono poniżej : "hei ght=300.wi dth=200,toolba r=no.menuba r=no"

Wyskakujące okno powinno zostać wyświetlone w chwili, gdy użytkownik kliknie przycisk lub łącze. Odpowiednią funkcję należy przypisać atrybutowi onclick przycisku lub łącza. Nasza funkcja powinna zwracać wartość fal se, aby przeglądarka nie wysyłała formularza ani nie przenosiła użytkownika na stronę wskazywaną przez dane łącze. Poniżej przedstawiono przykład takiego rozwiązania:

0 - r v .y

! 1 C aw dü 1 LD k 1 I Lndtdim 1 Zakcm-zcmo

1 lí (I I I m

iJ

Skąd komponent wspomagający „wie” , który stan bądź prowincję wskazano w wyskakującym oknie? Musimy pamiętać, że w momencie, w którym użytkownik spowodował wyświetlanie dodatkowego okna, formularz nie został jeszcze odesłany na serwer. W dalszej części tego punktu skoncentrujemy się na dwóch rozwiązaniach — oba są na swój sposób interesujące i ilustrują techniki przydatne w pracach nad podobnymi problemami. W pierwszym rozwiązaniu przekażemy parametr wyboru w ramach adresu U R L wyskaku­ jącego okna: window.open("popup faces?country=" + country[i] value. "poPuP "’ features),

Strona popup.faces uzyskuje wartość parametru żądania country jako pa rani. country:

W prezentowanym przykładzie właściwość states komponentu wspomagającego bb repre­ zentuje mapę (odwzorowanie), w której funkcję indeksu pełni nazwa kraju.

576

Rozdział 13. ■ Jak to zrobić?

JavaServer Faces Drugie rozwiązanie (zaproponowane przez Marión Bass i Sergeya Smimova) wymaga nieco większego zaangażowania programisty, ale też oferuje wyższy potencjał. W tym rozwiązaniu wyskakujące okno jest tworzone od razu (w formie okna pustego) i wypełniane dopiero na podstawie odpowiedzi na polecenie JSF. Wspomniane polecenie JS F jest generowane przez formularz obejmujący pole ukryte i nie­ widoczne łącze:

Warto zwrócić szczególną uwagę na następujące aspekty: ■ Nazwa celu tego formularza j est identyczna j ak nazwa wyskakuj ącego okna. Oznacza to, że przeglądarka wyświetli wyniki tej akcji wewnątrz wyskakującego okna. ■ Pole ukryte country jest wypełniane przed wysłaniem formularza. Polu country przypisujemy wyrażenie bb.country. Takie rozwiązanie umożliwia komponentowi wspomagającemu zwrócenie właściwego zbioru stanów lub prowincji. ■ Atrybut act i on łącza polecenia jest wykorzystywany przez mechanizm odpowiedzialny za obsługę nawigacji do identyfikacji strony JS F generującej zawartość wyskakującego okna. Funkcja doPopup inicjalizuje pole ukryte, po czym wykonuje akcję właściwą dla łącza: document.getElementById("hidden:country").value = country[i] .value; document.getElementById("hidden;go").onclick(nuli );

Wartość reprezentująca wybrany stan bądź prowincję jest umieszczana we wspomnianym polu ukrytym. Po wysłaniu ukrytego formularza na serwer wartość tego pola jest składowana w ramach komponentu wspomagającego. Okazuje się, że w prezentowanym rozwiązaniu strona JS F wyświetlana w wyskakującym oknie jest jeszcze prostsza. Tabela stanów lub prowincji jest wypełniana za pomocą nastę­ pującego wywołania właściwości:

Właściwość statesForCountry uwzględnia wartość właściwości country ustawionej w trakcie dekodowania ukrytego formularza. Takie podejście gwarantuje większą elastyczność niż pierw­ sze z prezentowanych rozwiązań, ponieważ umożliwia ustawianie dowolnych właściwości komponentu jeszcze przed wyznaczeniem zawartości wyskakującego okna. Niezależnie od stosowanego podejścia musimy się liczyć z koniecznością odsyłania danych z wyskakującego okna do oryginalnej strony. Okazuje się jednak, że można ten cel osiągnąć, stosując proste wyrażenie języka JavaScript. W łaściwość opener wyskakującego okna reprezentuje okno główne (które doprowadziło do wyświetlania okna dodatkowego). Kiedy użytkownik klika łącze w wyskakującym oknie, ustawiamy wartość odpowiedniego pola tekstowego oryginalnej strony: opener.document.forms[formld][formld + " :state"].value = value;

577

Skąd wyskakujące okno „zna” identyfikator oryginalnego formularza? Także w tym przy­ padku korzystamy z elastyczności oferowanej przez język JavaScript, który umożliwia nam między innymi dodawanie „w locie” pól egzemplarzy do dowolnych obiektów. Pole opener ^Formld ustawiamy w ramach wyskakującego okna w chwili jego konstruowania: popup = window.open(. ); popup.openerFormld = source form id,

Kiedy jesteśmy gotowi do modyfikowania zmiennych formularza, uzyskujemy to pole z w y­ skakującego okna za pośrednictwem następującego wyrażenia: var formld - window.openerFormld.

To wszystkie zabiegi, których znajomość jest niezbędna do efektywnej pracy z wyskakującymi oknami. Poniżej przedstawiono przykład ilustrujący oba zaprezentowane podejścia. Kod stron índex.jsp i popup.jsp (implementujących pierwsze podejście, czyli konfigurowanie wyska­ kującej strony z wykorzystaniem parametru żądania) przedstawiono odpowiednio na listingach 13.15 i 13.16.

Listing 13.15. Kod strony popup/web/index.jsp 1 . 2.
%>

taglib uri="http://java.sun.com/jsf/html" prefix="h" £>

Państwo:

Listing 13.16. Kod strony popup/web/popup jsp 1. 2. <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> 3. <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 4. 5 6 7. 14 15. 16. 17. 18. 19. 20.
2 1.

onclick="doSave(’#{state}');">

22 23. 24. 25 26. 27. 28 29

Kod stron index2.jsp i popup2.jsp (implementujących drugie podejście polegające na w y­ pełnianiu wyskakującej strony wynikiem akcji JS F ) przedstawiono odpowiednio na listin­ gach 13.17 i 13.18. Na listingu 13.19 przedstawiono kod komponentu wspomagającego; na listingu 13.20 przedstawiono zawartość pliku konfiguracyjnego. Warto zwrócić szczególną uwagę na sposób, w jaki akcja showStates prowadzi do otwarcia strony popup2.jsp .

Listing 13.17. Kod strony popup/web/index2.jsp 1 . 2 . <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" 3 4 5. 6. 7. 8. 9

10 11. 12 . 13. 14. 15. 16. 17. 18 19 20.

%> <%$ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>

Panstwo:
Stan/prowincja:		57. 58. 59. 60. 61. 62. Listing 13.18. Kod strony popup/web/popup2jsp 1. 2. <^@ taglib uri="http;//Java.sun.com/jsf/core" prefix="f" %> 3. 4. 5. 6. 7 8. 9 10. 11 <£@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 12 13 14. 15. 16. 17. 18. 19. 20. 21 22. 23. 24 25. 26. 27. 28 29. Listing 13.19. Kod komponentu popup/src/java/com/corejsf/BackingBean.java 1 package com.corejsf; 2. 3 import ja v a .u til HashMap; 4. import ja v a .util.Map; 5. 6. public class BackingBean { 7. private String country = "USA", 8 private String state = 9 private static Map states; 10 . 11. / / Właściwość country: 12. 13 public String getCountryO { return country; } public void setCountry(String newValue) { country - newValue, } 14. 15. 16. 17. 18 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. / / Właściwość state: public String getStateO { return state, } public void setState(String newValue) { state -newValue; public Map getStatesO {return } states; } public String[] getStatesForCountryO { return (String[]) states.get(country). } static { states = new HashMap(). states.put( "USA", new String[] { "Alabama", "Alaska", "Arizona", "Arkansas", "Connecticut", "Dakota Południowa". "Dakota Północna", "Delaware", "Floryda", "Georgia", "Hawaje", "Idaho", "Illin o is ", "Indiana", "Iowa", "Kalifornia", "Kansas", "Karolina Południowa". "Karolina Północna", "Kentucky", "Kolorado", "Louizjana", "Maine", "Maryland", "Massachusetts", "Michigan", "Minnesota", "Missisipi", "Missouri", "Montana", "Nebraska", "Nevada", "New Hampshire", "New Jersey", "Nowy Jork", "Nowy Meksyk","Ohio", "Oklahoma", "Oregon", "Pensylwania", "Rhode Island", "Tennessee", "Teksas". "Utah", "Vermont", "Waszyngton", "Wirginia", "Wirginia Zachodnia", "Wisconsin", "Wyoming" }); states.put("Canada", new String[] { "Alberta", "Kolumbia Brytyjska", "Manitoba", "Nowy Brunszwik", "Nowa Fundiandia i Labrador", " Terytoria Północno-Zachodnie", "Nowa Szkocja", "Nunavut", "Ontario", "Wyspa Księcia Edwarda", "Quebec", "Saskatchewan", "Yukon" }); } } Listing 13.20. Plik konfiguracyjny popup/web/WEB-INF/faces-config.xml 1. 2. 3. 8. 9. 10. next 11. /welcome.jsp 12. 13. 14. showStates 15. /popup2.jsp 16. 17. 18. techniquel 19. /i ndex.j sp 20 21. 581 582 JavaServer Faces 22 . technique2 23. /index2 .jsp 24. 25 26 27 28. bb 29 com.corejsf BackingBean 30 session 31 32 Jak selektywnie prezentować i ukrywać komponenty? Prezentowanie lub ukrywanie wybranych fragmentów stron internetowych w pewnych oko­ licznościach jest praktyką dość powszechną. Przykładowo: jeśli użytkownik nie jest załogowa­ ny, możemy zdecydować o wyświetlaniu pól wejściowych dla nazwy i hasła użytkownika. Z drugiej strony, jeśli użytkownik jest już załogowany, należałoby wyświetlać raczej jego nazwę wraz z przyciskiem umożliwiającym wylogowanie. Projektowanie dwóch odrębnych stron różniących się tylko tymi elementami byłoby oczywistą stratą czasu. Lepszym rozwiązaniem będzie umieszczenie na stronie wszystkich komponentów i ich selektywne wyświetlanie. Opisywany problem można rozwiązać za pomocą konstrukcji c : i f biblioteki JST L. Z drugiej strony, łączenie znaczników JS F ze znacznikami JS T L ogranicza czytelność kodu. Okazuje się, że ten sam efekt można stosunkowo łatwo osiągnąć za pomocą samych znaczników JSF . Do włączania i wyłączania pojedynczych komponentów (lub kontenerów, np. paneli grupują­ cych) służy właściwość rendered: .. Aby umożliwić łatwe przełączanie się pomiędzy dwoma zbiorami komponentów, powinniśmy dodatkowo wykorzystać atrybuty rendered: . Rozdział 13. ■ Jak to zrobić? 583 .. , . . Metoda getStatus komponentu JavaBean powinna zwrócić łańcuch "new", "1 oggedln" lub "loggedOut". Jak dostosowywać wygląd stron o błędach? Większość programistów prawdopodobnie chciałaby oszczędzić użytkownikom swoich aplikacji widoku śladu stosu w razie wystąpienia jakiegoś błędu. Sposób prezentowania komunikatów o błędach można modyfikować na dwa sposoby. Stronę o błędzie dla określonej strony JS F możemy wskazać za pośrednictwem następującej dyrektywy JS P : <%$ page errorPage="error jsp'’ %> W razie wystąpienia błędu w czasie wykonywania kodu Javy skompilowanej strony zostanie wyświetlona strona error.jsp. Opisywany mechanizm nie jest jednak zbyt przydatny z perspek­ tywy programistów JS F , ponieważ wskazana strona JS P (opisująca błąd) nie będzie wyko­ rzystywana do informowania użytkownika o błędach kompilacji stron lub przetwarzania wyrażeń (w obu przypadkach zostanie użyta standardowa strona o błędach). Lepszym rozwiązaniem jest użycie znacznika error-page w pliku konfiguracyjnym web.xml. W ramach tego znacznika możemy zdefiniować albo klasę wyjątku Javy, albo kod błędu protokołu HTTP. Przykład takiej konstrukcji przedstawiono poniżej: java.lang.Exception <1 ocati on>/excepti on.jsp 500 <1 ocati on>/error.jsp 404 <1 ocati on>/notfound.jsp Jeśli musimy operować na więcej niż dwóch możliwych konfiguracjach strony, powinniśmy się posłużyć odpowiednim komponentem, np. panel Stack biblioteki komponentów Apache MyFaces (patrz strona internetowa http://myfacesMpache.org/tomahawk/panelStack.html). Komponent panel Stack pod wieloma względami przypomina panel podzielony na zakładki, który przedstawiono w rozdziale 9., z tą różnicą, że nie udostępnia zakładek. Zamiast klikać zakładki, możemy wybrać jeden z komponentów potomnych z poziomu kodu aplikacji. Jeśli w czasie wykonywania aplikacji wystąpi wyjątek typu, dla którego zdefiniowano stronę o błędzie, odpowiednia strona zostanie wyświetlona. W przeciwnym razie zostanie wyge­ nerowana strona o błędzie nr 500 protokołu HTTP. Komponent panel Stack wymusza przypisanie każdemu z komponentów potomnych unikato­ wego identyfikatora. Za pośrednictwem atrybutu sel ectedPanel wskazujemy identyfikator komponentu potomnego, który ma zostać wyświetlony: Jeśli w czasie wykonywania aplikacji wystąpi błąd protokołu H TTP, dla którego zdefinio­ wano stronę o błędzie, właśnie ta strona zostanie wyświetlona. W przeciwnym razie oczom użytkownika ukaże się standardowa strona o błędzie. 584 Rozdział 13. ■ Jak to zrobić? JavaServer Faces P t | Jeśli błąd wystąpi w czasie, gdy nasza aplikacja będzie próbowała wyświetlić i L J i niestandardow ą stronę o błędzie, zam iast tej strony zostanie wyświetlona strona domyślna. Jeśli nie udaje nam się zmusić serwera do wyświetlenia naszej niestandar­ dowej strony o błędzie, koniecznie powinniśmy przejrzeć płiki dzienników w poszukiwaniu kom unikatów dotyczących naszej strony. Rysunek 13.10. Przykład zmienionej strony o błędzie PM Edycja Widok Historia Zakładki ■ *¡¿11■ ]. Narzędzia Pomoc http://localhost:8080/error/mdex.faces Prz vk ro nam . ale podczas p ra ry progi amu vvysr^pil bla d w ew n^trzny i Goeriia jp | | Pro s im v o V ontaki z dzialem p o m o r v technic znei p o d num erem 0 8u 1 C O S T A iv l | N a p ro s b ? naszego k on s’iltanta p io sim v sk opiow ac 1 wkleu. pomzszv rap o n do w ia d o m c s c i pocztv elektiom cznej Jeśli użyjemy dyrektywy JS P errorPage, obiekt wyjątku będzie dostępny w strukturze mapy żądania (reprezentowany przez klucz " j av a x . servlet. jsp. jspFxcept ion"). Z drugiej strony, jeśli posłużymy się znacznikiem error page, w mapie żądania zostanie umieszczonych wiele obiektów w ten czy inny sposób związanych z danym błędem (patrz tabela 13.2). Możemy te wartości wykorzystać do wyświetlania informacji opisujących dany błąd. .1w a x . s e r v Let . S e r v Let E x c e p t L o n : j a v a x . f c a c e s . e l . E v a l u a t L o n E x c e p t Lon: g e t t m g p r o p e r* . y p a s s w o r d tr o m L .ean o t t y p e co m . c o r e j s ± . U s e r B e a n : j a v a . l a n g . N u i I P o m t e r Exc-ept io n Klucz Wartość Typ javax.servlet.error.status_code Kod błędu protokołu HTTP. Integer javax.servlet.error message Opis błędu. String javax.servlet.error.excepti on_type Klasa danego wyjątku. Class javax.servlet.error.excepti on Obiekt wyjątku. Throwable javax.servlet.error.request_uri Ścieżka do zasobu aplikacji, który napotkał dany błąd. String javax.servlet.error.servl et_name Nazwa serwletu, który napotkał dany błąd. String Poniżej przedstawiono przykładową aplikację, którą zaimplementowano właśnie z wyko­ rzystaniem tej techniki. W e właściwości password komponentu UserBean celowo generujemy wyjątek Nul 1PointerException, aby nasza aplikacja wyświetliła raport o błędzie (patrz rysu­ nek 13.10). Na listingu 13.21 przedstawiono zawartość pliku konfiguracyjnego web.xml okre­ ślającego stronę informacji o błędzie errorDisplay.jsp. Jej kod przedstawiono na listingu 13.22. P U W kodzie strony errorDisplay.jsp wykorzystano znacznik f: subview. Takie rozwiązanie k i l skutecznie elim inuje anom alię w ystępującą w im plem entacji referencji do JSF —- użycie znacznika f wiew w kodzie strony o błędzie powoduje błąd asercji w kodzie fram eworku. 1 . 2 . xmlns:xsi="http://www.w3.org/2001/XMLSchema-i nstance" xsi:schemaLocati on="http://Java.sun.com/xml/ns/javaee http://Java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"> Faces Servlet javax.faces.webapp.FacesServlet l |. I o r g . a p a c h e . j a s p e r . r u n t Line . P a g e C o n t e x r Imp I . h a n d l e P a g e E x c - e p t i o n >P a g e C o w e v t Lmp I . ja \ ! o r g . a p a c h e , j s p . i n d e x _ j s p . _ j s p S e r v i c e i m d e x _ j 3 p . j a v a : "78 . ! o r g . a p a c h e , j a s p e i . r u n t Lme . Ht r p J s p B a s e . s e r v i c e . H tf p J s p B a s e . j a v a : Lx .. • j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t . s e r v i c e ; H t t p S e r v L e t . j a v a :8 5 6? o r g . a p a c h e . j a s p e r . s e r v l e t . J s p S e r v l e t U r a p p e r . s e r v i c e (J s p S e r v l e t . W r a p p e r . j a v a : 3 11) o r g . a p a c h e . j a s p e r . s e r v l e t . J s p S e r v l e t . 3 e r v i c e J s p F i l e (J s p S e r v l e t . j a v a : 3 u l ) o r g . ap a c L ie . j a s p e r . s e r v l e t . J s p S e r v l e t . s e r v i c e ( J s p S e r v l e t . j a v a : 2 48 ) j a v a x . s e r v l e t . h t t p . H t t p S e r v l e t . s e r v i c e ( H t t p S e r v l e t . j a v a : 8 56) 13. 14 15. 16 17. 18. 19. 20 . Faces Servlet *.faces /i ndex.html 21. 22 . 23. 500 24 <1ocati on>/errorDi splay.faces 25. 26. Listing 13.22. error/web/errorDisplay.jsp 1 . 2. <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" 3. 4 Listing 13.21. Plik konfiguracyjny error/web/WEB-INF/web.xml_______ E rro r o r g . a p a c h e . j a s p e r . r u n t lm e . P a g e O o n t e x t Lrnp 1 . d o H a n d l e P a g e E x e e p t i o n >,F 'a g e C o n r ex t Lmp 1 . j; } Tabela 13.2. Atrybuty wyjątków serwletów *- %> taglib uri="http://java.sun.com/jsf/html" prefix="h" %> 5. 6. 7 8. 9. 10 . 11. 12 . 13. 15. 16. 17. 18. 585 586 Rozdział 13. ■ Jak to zrobić? JavaServer Faces Na listingu 13.23 przedstawiono kod klasy ErrorBean. Metoda getStackTrace tej klasy kon­ struuje łańcuch kompletnego śladu stosu obejmującego wszystkie zagnieżdżone wyjątki. Listing 13.23. Kod klasy enviysrc/]ava/com/corejsf/ErrorBean.java___________________________________ 1 . package com.corejsf, 2 3. import java i o.PrintWriter, 4 import java io.StringWriter, 5. 6. 7 8. 9 10 11. 12 13. 14. 15 16 17 18. 19. 20. import java.sql SQLException; import java.util.Map, import javax.faces.context.FacesContext, import javax.servi et.ServietException. public class ErrorBean { public String getStackTrace() { FacesContext context = FacesContext,getCurrentInstance(): Map request = context.getExternalContextO .getRequestMapO : Throwable ex = (Throwable) request.getC'javax.servlet.error exception"), StringWriter sw = new StringWriter(), PrintWriter pw = new PrintWriter(sw), fillStackTrace(ex, pw), return sw.toString(): } 21. 22 private static void fillStackTracedhrowable t, PrintWriter w) { 23 i f (t == null) return: 24. t.printStackTrace(w), 25 i f (t instanceofServletException) { 26. Throwable cause = ((ServletException) t),getRootCause(): 27 i f (cause != nul 1) { 28. w.printlnC'Przyczyna nadrzędna:"): 29. fiUStackTrace(cause, w). 30. } 31. } else i f (t instanceofSQLException) { 32 Throwable cause = ((SQLException)t),getNextException(): 33. i f (cause != null) { 34. w.printlnCNastępny wyjątek:"): 35. f i l !StackTrace(cause, w): 36. } 37. } else { 38 Throwable cause = t.getCauseO; 39 i f (cause != null) { 40. w.printlnC'Przyczyna-"), 41 fil!StackTrace(cause, w); 42. } 43 } 44. } 45 } 587 Weryfikacja danych Technologia JavaServer Faces oferuje rozbudowaną obsługę mechanizmów weryfikacji po stronie serwera danych pochodzących od poszczególnych komponentów. Jeśli jednak chcemy weryfikować dane po stronie klienta lub sprawdzać relacje obejmujące wiele komponentów, powinniśmy samodzielnie opracować niezbędne rozwiązania. W trzech kolejnych punktach tego podrozdziału omówimy techniki rozwiązywania tego problemu. Jak utworzyć własny, niestandardowy znacznik weryfikacji po stronie klienta? Przypuśćmy, że opracowaliśmy funkcję języka JavaScript, która ma weryfikować dane wej­ ściowe, i że przetestowaliśmy ją na wielu przeglądarkach internetowych. Przyjmijmy, że chce­ my tę funkcję wykorzystać w aplikacjach JSF . Będziemy potrzebowali dwóch znaczników: 1. Znacznika mechanizmu weryfikującego dołączanego do każdego komponentu wymagającego weryfikacji. 2. Znacznika komponentu generującego kod języka JavaScript odpowiedzialny za weryfikację wszystkich komponentów danego formularza. Znacznik komponentu należy dodać na koniec tego formularza. Warto pamiętać, że w tej roli nie można wykorzystać znacznika mechanizmu weryfikacji, ponieważ tylko komponenty mogą prezentować dane wynikowe. W tym punkcie posłużymy się przykładem ilustrującym możliwy sposób wykorzystania kodu weryfikującego numery kart kredytowych, opracowanego w ramach projektu Apache Commons Validator. Można ten kod pobrać ze strony internetowej http://jakarta.apache.org/ ^commons/validator. Opracujemy dwa znaczniki: creditCardVal idator, który będzie można dodać do dowolnego komponentu wejściowego JS F , oraz val idatorScri pt, który będzie generował niezbędny kod języka JavaScript. Znacznik creditCardVal idator obsługuje dwa atrybuty. Atrybut message definiuje szablon dla komunikatów o błędach: { 0} nie jest prawidłowym numerem karty kredytowej. Atrybut arg reprezentuje wartość, która powinna zostać wstawiona w miejsce symbolu {0} (zwykle ma postać nazwy odpowiedniego pola). Przykład użycia obu tych atrybutów przed­ stawiono poniżej: Kod mechanizmu weryfikującego przedstawiono na listingu 13.24. Klasa tego mechanizmu odpowiada za realizację dwóch zadań: weryfikację danych i formatowanie komunikatów o błędach. 588 Rozdział 13. ■ Jak to zrobić? JavaServer Faces Listing 13.24. Kod klasy clientside-validator/src^java/com/corąjy/C 1 package com.corejsf: 2 3 4. 5. 6. 7. 8. 9 10 import import import import import import import import java.io.Serializable: java.text.MessageFormat, java.util Locale: javax.faces.application.FacesMessage. javax.faces.component.UlComponent: javax.faces.context.FacesContext; javax.faces.validator.Validator: javax.faces.validator.ValidatorException, 11 12. 13 14. 15. 16. 17 18. 19. 20. 21 22 . 23. 24. 25 26. 27. 28. 29. 30. 31 32 33. 34. 35. 36. 37. 38 39. 40. 41 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. public class CreditCardValidator implements Validator, Serializable { private String message: private String arg; / / Właściwość message: public void setMessage(String newValue) { message = newValue; } I I Właściwość arg: public void setArg(String newValue) { arg = newValue, } public String getArgO { return arg: } public voidvalidate(FacesContextcontext, UlComponentcomponent, Object value) { if(value == null) return: String cardNumber; i f (value instanceof CreditCard) cardNumber = value.toString(); else cardNumber = getDigitsOnly(value.toStringO); if(!luhnCheck(cardNumber)) { FacesMessage message = new FacesMessage(FacesMessage.SEVERITY_ERROR, getErrorMessage(value, context), null): throw new ValidatorException(message); } } public String getErrorMessage(Objectvalue, FacesContext context) { Object[] params = new Object[] { value }; i f (message == null) return com.corejsf.util.Messages.getString( "com.corejsf messages", "badLuhnCheck", params); else { Locale locale = context.getViewRoot() ,getLocale(), MessageFormat formatter = new MessageFormat(message, locale), return formatter.format(params); } } private static boolean 1uhnCheck(String cardNumber) { int sum = 0, for(int i = cardNumber.length() - 1; i >= 0; i -= 2) { sum += Integer.parseInt(cardNumber.substring(i, i + 1 )): if ( i > 0) { 56 57. 58. 59 60. 61 62. 63 64. 65. 66 67. 68. 69. 70. 71. 72 73. 74 75. 76. } 589 int d = 2 * Integer.parseInt(cardNumber substrings - 1, i )), if(d > 9) d -= 9, sum += d; } } return sum % 10 == 0, } private static String getDigitsOnly(String s) { StringBuiIder digitsOnly = new StringBuiIder (); char c, for (int i = 0. i < s.lengthO: i++) { c = s.charAt ( i ); i f (Character.isDigit(c)) { digitsOnly.append(c): } } return digitsOnly.toString 0 ; } Klasa CreditCardVal idator odpowiada za tradycyjną weryfikację danych po stronie serwera (niezależnie od kodu języka JavaScript wykonywanego po stronie klienta). Bazowanie wyłącznie na mechanizmach weryfikacji po stronie klienta byłoby ryzykowne. Użytkownicy mogą przecież wyłączać w swoich przeglądarkach obsługę skryptów języka JavaScript. Co więcej, niesprawdzone żądania protokołu H TTP mogą być przesyłane do naszej aplikacji internetowej także przez zautomatyzowane skrypty lub hakerów. Metoda getErrorMessage formatuje komunikat o błędzie, który zostanie włączony do skryptu języka JavaScript wykonywanego po stronie klienta. Komunikat jest konstruowany na pod­ stawie atrybutów message i arg. Komponent val idatorScri pt, którego kod przedstawiono na listingu 13.25, jest nieporów­ nanie bardziej interesujący. Metoda encodeBegin tego komponentu wywołuje rekurencyjną metodę findCreditCardValidators, która przeszukuje drzewo komponentów, lokalizuje wszystkie komponenty, przegląda ich mechanizmy weryfikacji, sprawdza, które z nich weryfi­ kują numery kart kredytowych, i umieszcza je w strukturze mapy. Metoda writeVal idation ^Functions zapisuje kod języka JavaScript odpowiedzialny za wywołanie funkcji spraw­ dzania wartości we wszystkich polach objętych działaniem mechanizmów weryfikujących kartę kredytową. Listing 13.25. Kod klasy dientside-validator/src/java/com/corejsf/UIValidatorScnpt.java 1 . package com.corejsf; 2 3. 4 5 6. 7 import import import import import 8 import 9. import 10 . import java.io.IOException; java.util.Map; java.util.LinkedHashMap, javax.faces.component.EditableValueHolder; javax.faces.component.UlComponent; javax.faces.component.UIComponentBase; javax.faces.context.FacesContext, javax.faces.context.ResponseWriter, 590 Rozdział 13. ■ Jak to zrobić? JavaServer Faces 11 import javax.faces.validator Validator; 68 12 13 public class UlValidatorScript extends UIComponentBase { 14 private Map validators 15 = new LinkedHashMap(); 16 17 public String getRendererType() { return null; } 18. public String getFamilyO { return null; } 19 20 private void findCreditCardValidatorsCUIComponent c. FacesContext context) { 21 i f (c instanceof EditableValueHolder) { 22. EditableValueHolder h = ( EditableValueHolder) c. 23. for (Validator v h.getValidators()) { 24. i f (v instanceof CreditCardValidator) { 25 String id = c.getClientld(context), 26 va1 idators put( id v). 69 70 71. 72 73. 74 75. 76 77. 78 79 80. 81. 82 83 21 84 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 \ 66 67 writer write(v.getErrorMessage(v.getArg(), context)); wri ter.wri te ("' , 1 1); \n"); / / Trzeci element niejest wykorzystywany pizez ten mechanizm. } w riter,w rite("}\n"). } public void encodeBegin(FacesContext context) throws lOException { ResponseWriter writer = context,getResponseWriter(): validators,clear(), findCreditCardValidators(context.getViewRoot(). context), writeScriptStart(writer); writeValidatioriFunctions(writer, context), writeScriptEnd(writer), ( 1 } \ Znacznik val idatorScript należy umieścić na końcu formularza: c g e t C h i 1dren ()) for (UlComponent c h i l d findCreditCardValidators(chiId. context). } private void writeScrlpiStart(Responsewriter writer) throws lOException { writer startElementi"script". this). wri ter wri teAttnpute( "type" " text /javascr lpt" null) wri ter wri teAttnbutef" language". "Javascript1.1". null). w r i t e r w r i t e ( "\n lOException { wr1ter wr1 te("\n■■>\n"). 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 591 w r i t e r e n d [ l e m e n t i " s c r i p t " ). 1 private void writeval idationFunctionsiResponseWruerwriter. FacesContext context) writer wr1 ter writer writer throws lOException { writeCvar DCancel - false.\n"). wr it e (" function " ). wr i tefgetAt t r i putes () get (" funct ionName") toStnngo). w rite(" ( form) \ return DCancel ||va1idateCred11 Card( form). |\n"). writer w rlte(" function "). String formfd = getParento get C11ent I d Ccon text). writer write(form Id). writer write("_creditCardi ) j \n"). / / d/a kazdego pola zweryjikowanego przez ten mechanizm dodaj obiekt konfiguracji int k = 0. for (String id validators keySetU) { CreditCardVa1idator v = (CreditCardvalidator) validators get( id). writer w rite("Lhis[" + k + "] = ') k-. writer write("new writer w rite(id ). writer w rite(" 1. < c o r e j s f •v a l i d a t o r S c r i p t P § 9 Gdybyśmy um ieścili znacznik validatorScript przed znacznikam i kom ponentów L a f l w ym agających w eryfikacji, m ogłoby się okazać, że kod przeszukujący drzew o kom ponentów nie m oże odnaleźć m echanizm ów weryfikujących! To m ało intuicyjne, wręcz dziwaczne zachowanie wynika wprost ze sposobu funkcjonowania odpowiedniego mechanizmu JSP, na bazie którego opracowano im plem entację referencyjną technologii JSF, Kiedy im plem entacja zbudowana na bazie technologii JSP po raz pierwszy wizu­ alizuje stronę JSF, drzewo kom ponentów jeszcze nie istnieje. Oznacza to, że proces wizualizacji przebiega równolegle z procesem konstruowania drzewa kom ponentów. Na rysunku 13.11 przedstawiono opis błędu wygenerowany w odpowiedzi na próbę wpisania przez użytkownika błędnego numeru karty kredytowej. Kod tej przykładowej strony JS F przedstawiono na listingu 13.26. Rysunek 13.11. Weryfikacja numeru karty kredytowej po stronie klienta tH Aplikacja testująca mecha??fem weryfikacji - Moálaíkefüx Puk Edycja Widok HMona : Zakładki U ,. Nareęctoa __?? __J lg * i ® • - Pomoc no:p.y/locaihost:8080..'Clieritside-vaiiV ^ o^ 3 ^ Prosimy wpisać dane o płatności: Kwota ¡0 00 j Numei karty kredytowei !?11 l i 11 n 1111111 j Data ważności irmesiątfiokj U'/2009 ¡ PneiyvQf?, j [Aplikacja Sm aSm pl] 1 Array('"). ). functionName="validatePaymentForm"/> Zakończono i jg ^ ^ Nieznanv typ kart/ kredytowei ■ t e 592 Rozdział 13. ■ Jak to zrobić? JavaServer Faces Listing 13.26. Kod strony clientsidew 1 2 . <»a taglib uri="http://java.sun.coiii/jsf/core" prefix=,'f'’ 3 . <£@ taglib uri="http://java.sun.com/jsf/html" prefix=''h" %> 4 <°4@ taglib uri="http://corejsf.com/creditcard" prefix="corejsf" 5. 6. 7. 8 9. 10 11. 12 . 13. 14 . 15 16. 17 18. 19 20. 21. 22 . 23. 24. 25. 27. 28. 29. 30. 31. 32. 33. 34. 35 . 36. 37 . 38. 39. 40. 41. Szczegółowe rozwiązania w metodzie writeValidationFunctions są ściśle związane ze spo­ sobem, w jaki zakodowano odpowiednie konstrukcje języka JavaScript w ramach projektu Commons Validator. Po pierwsze, metoda writeValidationFunctions generuje funkcję weryfikującą wywoływaną za pośrednictwem konstrukcji onsubmit formularza na naszej stronie: var bCancel = false: function nazwaFunkcji(form) { return bCancel || validateCreditCard(form); } 593 Jeśli nasz formularz obejmuje przycisk Anuluj lub Cofnij, atrybut onclick odpowiedniego elementu powinien przypisywać zmiennej bCancel wartość true, aby pominąć weryfikację. Funkcja val idateCreditCard jest punktem wejścia do kodu mechanizmu Commons Validator. Funkcja val idateCreditCard wymaga do prawidłowego działania funkcji nazwanej na zw a ^ F o r m u ł arza_creditCard, która konstruuje obiekt konfiguracji. Metoda writeVal idation ^Functions generuje kod dla funkcji credi tCard. Wspomniane rozwiązania szczegółowe są niestety dość zawiłe. Funkcja n a z w a F o r m u la r z a _ ^creditCard zwraca obiekt obejmujący po jednym polu egzemplarza dla każdego weryfi­ kowanego elementu formularza. Każde z tych pól reprezentuje trój elementową tablicę, w której składuje identyfikator elementu formularza, komunikat o błędzie wyświetlany w razie nie­ powodzenia weryfikacji oraz wartość właściwą dla danego mechanizmu weryfikującego. Ponieważ nasz mechanizm nie wykorzystuje tej wartości, będziemy wykorzystywali w tej roli łańcuch pusty. Nazwy pól egzemplarzy nie mają żadnego znaczenia. W ciele metody writeVal idation ^Functions korzystamy z elastyczności języka JavaScript i odwołujemy się do pól indek­ sowanych wartościami 0, 1, 2 itd. Poniżej przedstawiono odpowiedni przykład: function paymentForm_creditCard() { th i s [0] = new Array("paynientForm:primary", "Nieprawidłowy numer pierwszej karty kredytowej", ""), th is[1] = new Array("paymentForm:backup", "Nieprawidłowy numer dodatkowej karty kredytowej", ""); } Jeśli zdecydujemy się opracować własne funkcje języka JavaScript, będziemy mogli zapro­ jektować bardziej rozsądny mechanizm składowania parametrów. Jak weryfikować dane po stronie klienta za pomocą mechanizmu Shale Validator? W poprzednim punkcie omówiono technikę tworzenia własnego znacznika mechanizmu weryfikacji wykorzystującego skrypt opracowany w ramach projektu Commons Validator. Czytelnicy, którym takie podejście odpowiada, nie muszą zawracać sobie głowy innymi rozwiązaniami w tym zakresie. W ramach projektu Apache Shale (patrz strona internetowa http://struts.apache.org/struts-shale) opracowano z myślą o weryfikacji danych specjalną bibliotekę znaczników niestandardowych. (Wspomniana biblioteka początkowo została opracowana na potrzeby pierwszej edycji tej książki, by później wejść w skład projektu Shale). Użycie mechanizmu Shale Validator wymaga wykonania następujących kroków: 1. Należy umieścić pliki biblioteki shale-corejar i commons-validator.jar w katalogu WEB-INF/lib naszej aplikacji internetowej (wraz z bibliotekami niezbędnymi do ich prawidłowego działania). W czasie, gdy pisano tę książkę, lista niezbędnych plików dodatkowych JA R obejmowała następujące pozycje: commons.logging.jar, 594 RozdziaM3. ■ Jak to zrobić? JavaServer Faces commons .digester.jar, commons-beanutils.jar,commons-collections.jar ijakarta oro.jar. Aby dysponować odpowiednimi wersjami tych plików, należy pobrać plik shale-dependencies-data.zipwłaściwy dla stosowanej dystrybucji projektu Shale. 2. Należy zadeklarować bibliotekę znaczników: <» taglib uri“ "http://struts.apache.org/shale/core" prefix="s" %> W tym konkretnym przypadku zastosowano przedrostek s. Jak zawsze w tego rodzaju sytuacjach można użyć dowolnego innego przedrostka. Tabela 13.3. Mechanizmy weryfikacji po stronie klienta frameworku Struts Hazwa mechanizmu weryfikującego Parametry Przeznaczenie required brak Sprawdza, czy dane pole obejmuje znaki inne niż spacje. maxlength maxlength Sprawdza, czy długość danego pola nie jest większa od wartości parametru maxi ength. minlength minlength Sprawdza, czy długość danego pola nie jest mniejsza od wartości parametru mi nl ength. byte brak Sprawdza, czy dane pole zawiera liczbę całkowitą z przedziału o d -128 do 127. short brak Sprawdza, czy dane pole zawiera liczbę całkowitą z przedziału od -32 768 do 32 767. integer brak Sprawdza, czy dane pole zawiera liczbę całkowitą z przedziału od -2 147 483 648 do 2 147 483 647. float brak Sprawdza, czy dane pole zawiera liczbę zmiennopozycyjną. intRange min, max Sprawdza, czy dane pole zawiera liczbę całkowitą z przedziabi od mi n do max. Należy zdefiniować oba parametry. floatRange min, max Sprawdza, czy dane pole zawiera wartość zmiennopozycyjną z przedziału od mi n do max. Należy zdefiniować oba parametry. date datePatternStric t Sprawdza, czy dane pole zawiera datę sformatowaną zgodnie ze wzorcem datePatternStrict. email brak Sprawdza, czy dane pole zawiera składniowo poprawny adres poczty elektronicznej. creditCard brak Sprawdza, czy dane pole zawiera numer karty kredytowej, który przechodzi test Luhna. mask mask Sprawdza, czy wartość danego pola można dopasować do wyrażenia regularnego reprezentowanego przez mask. 3. Należy przypisać metodę weryfikującą atrybutowi onsubmi t znacznika formularza: Bezpośrednio przed znacznikiem powinniśmy umieścić znacznik s:validatorScript: Wartość atrybutu functionName musi odpowiadać nazwie funkcji wywołanej za pośrednictwem atrybutu onsubmi t. 4. Należy dodać mechanizmy weryfikujące do naszych komponentów. Przykład odpowiedniej konstrukcji przedstawiono poniżej: Atrybut type reprezentuje typ mechanizmu weryfikacji. Atrybutowi type należy przypisać jeden z typów wymienionych w tabeli 13.3. Atrybutowi arg powinniśmy przypisać argument komunikatu o błędzie. Z reguły będzie to nazwa odpowiedniego pola. 595 Parametry min, max, minlength, maxlength, mask oraz datePatternStrict należy definiować w zależności od stosowanej metody weryfikacji. 5. Czytelnicy zainteresowani dostosowaniem działania mechanizmów weryfikacji do potrzeb swoich aplikacji lub dodawaniem nowych reguł weryfikacji powinni się zapoznać z materiałem dostępnym na stronie internetowej http://wiki.apache.org/struts/Shale/Validation. ■ ¡S i W razie niepow odzenia w eryfikacji m echanizm C om m ons V alid a to r w yśw ietla ( ¡ ¡ l i wyskakujące okno ze stosownym kom unikatem . Lepszym rozwiązaniem byłoby oczywiście um ieszczenie kom unikatu o błędzie obok pola, które spowodowało błąd. Można ten cel osiągnąć, stosując pakiet weryfikacji po stronie klienckiej autorstwa Cagataya Civicíego (patrz strona internetowa http://jsf-comp.sourceforge.net/components/ V » ciientvalidators/index.html). ■■■ ■ :■ ■■ ■ -■ ■ ■ :-—¿-Li. ■- —. I . —.-¿-i ' ' "" - * > * Jak weryfikować relacje pomiędzy komponentami? W technologii JS F mechanizmy weryfikacji w założeniu mają sprawdzać zawartość poje­ dynczych komponentów. Praktyka pokazuje jednak, że często niezbędne jest testowanie relacji łączących wiele komponentów. Na przykład współczesne aplikacje internetowe często żądają od swoich użytkowników ponownego wpisywania haseł. W tej sytuacji naturalnym rozwią­ zaniem byłoby wyświetlanie komunikatu o błędzie weryfikacji w razie wykrycia niezgodności obu haseł. Można ten problem rozwiązać na dwa sposoby — bardziej wymagające rozwiązanie polega na zaprojektowaniu własnego, niestandardowego komponentu, który będzie prezentował dwa pola wejściowe: jedno dla hasła i drugie dla potwierdzenia hasła. Takie podejście jest dość eleganckie, ale wymaga sporo pracy. 596 JavaServer Faces Drugie rozwiązanie polega na weryfikacji danych tylko przez drugi ze spokrewnionych kompo­ nentów. Kiedy wartości lokalne komponentów poprzedzających komponent odpowiedzialny za weryfikację będą ustawione, nasz kod weryfikujący będzie mógł je odczytać. Tylko dla ostatniego komponentu będziemy musieli wykorzystać wartość przekazaną przez metodę weryfikującą. Najprostszym rozwiązaniem jest umieszczenie metody weryfikującej w komponencie wspo­ magającym, który oprócz tej metody będzie obejmował komponenty naszego formularza: Rozdział 13. ■ Jak to zrobić? W pierwszej kolejności skoncentrujemy się na bibliotekach JSF . Najlepszym rozwiązaniem jest stworzenie projektu obejmującego te biblioteki i jego wielokrotne wykorzystywanie w kolejnych projektach JSF. Poniżej opisano procedurę konfigurowania tego projektu bazo­ wego (nazwiemy go j s f 1ibs). 1. Z menu File należy kolejno wybrać opcje New i Java Project , po czym wpisać w oknie dialogowym nazwę js f 1i bs. 2. W oknie Java Settings kreatora projektu należy kliknąć kolejno zakładkę Libraries i przycisk Add External JARs... (patrz rysunek 13.12). Jeśli korzystamy z serwera GlassFish, możemy się ograniczyć do dodania pliku ja va eeja r składowanego w katalogu glassfish/lib. Jeśli stosujemy inną implementację JS F , powinniśmy dodać wszystkie wymagane pliki JA R . public class BackingBean { private UIInput passwordField: private UIInput confirmField, public void validateConfirmField(FacesContext context, UlComponent component, Object value) { i f ( ¡passwordField.getLocalValue() .equals(value)) throw new ValidatorException(... ) : 597 Rysunek 13.12. Dodawanie bibliotek do projektu jsflibs } Mechanizm weryfikacji należy następnie dołączyć do pola potwierdzenia hasła: Bardziej konkretny przykład zastosowania tej techniki można znaleźć w rozdziale 6. Programowanie W poniższych punktach omówimy wybrane problemy, z którymi muszą się mierzyć progra­ miści aplikacji JSF . Pokażemy, jak korzystać ze środowiska Eclipse, jak eliminować utrud­ nienia związane z typowymi zadaniami implementacyjnymi, jak inicjalizować aplikacje i jak pakować komponenty w ramach plików JA R wielokrotnego użytku. Jak tworzyć aplikacje JSF w środowisku Eclipse? W środowisku Eclipse można z powodzeniem edytować kod stron JS F , a także kompilować kod komponentów JavaBeans, konwerterów, klas weryfikujących i komponentów interfejsu użytkownika. Zakładamy, że Czytelnik potrafi wykonywać podstawowe operacje w tym środowisku, zatem skoncentrujemy się tylko na szczegółach konfiguracyjnych właściwych 3. Należy teraz kliknąć zakładkę Order and Export i zaznaczyć dodane przed chwilą dla programowania aplikacji JSF . 4. Całą procedurę kończymy, klikając przycisk Finish. Przed przystąpieniem do właściwych działań musimy zainstalować biblioteki technologii JS F i narzędzia Ant. Instalowanie tych bibliotek osobno dla każdego projektu byłoby oczywiście niepraktyczne. biblioteki (patrz rysunek 13.13). Za każdym razem, gdy będziemy chcieli utworzyć nowy projekt JSF, powinniśmy w pierwszej kolejności otwierać standardowy kreator New Java Project. Po dojściu do ekranu Java Settings należy jednak kliknąć zakładkę Projects i dołączyć projekt js flib s (patrz rysunek 13.14). Od tej pory wszystkie niezbędne biblioteki będą automatycznie włączane do naszego nowego projektu. 598 Rozdział 13. ■ Jak to zrobić? JavaServer Faces Rysunek 13.13. Eksportowanie bibliotek do projektu jsflibs | New Java Project Jeśli zależy nam na możliwości łatwego korzystania z narzędzia Ant, powinniśmy umieścić plik build.xml w katalogu projektu. Takie podejście odbiega od praktyki stosowanej w naszych aplikacjach przykładowych, gdzie korzystano z pojedynczego pliku build.xml dla wszystkich aplikacji. Czytelnicy, którym odpowiada takie podejście, mogą umieścić następujący plik build.xml w katalogach wszystkich projektów środowiska Eclipse: m ii J a v a Settings Define the Java build settings. \ 'P m jYttVf E T b i w e f i 'V Ordei and Export Build class path order and exported entries: (Exported entries are contributed to dependent projects) [Bj e5isflibs/src [fj S U R E System Library [jre 1.6.0_03] igj 0 javaee.jar - .Q;\gfesfish\ltfe 599 I Można też skopiować pliki build.xml i buildproperties do katalogów wszystkich projektów. Aby uruchomić Anta, należy prawym przyciskiem myszy kliknąć plik build.xml i z menu kontekstowego wybrać opcję Run As/Ant Build. Komunikaty tego narzędzia zostaną wyświe­ tlone w oknie konsoli. Zalecamy instalację modułu rozszerzenia XMLBuddy i uczynienie z niego domyślnego edytora kodu stron JSF. W spom niany m oduł można pobrać z witryny internetowej http://xmlbuddy.com. Ponieważ XMLBuddy ta k napraw dę je s t edytorem plików XML, Q stosow anie prawidłowej składni języka XML (patrz rozdział : Rysunek 13.14. Włączenie projektu jsflibs do nowo tworzonego projektu New Java Projecl J a v a Settings I S SourceI ^ p"-'1 i Required projects on ! < ■ I Litvaries [ S/ Order andExport! L. Opisana konfiguracja czyni z narzędzia Eclipse całkiem sprawne środowisko wytwarzania aplikacji JSF . Wielu programistów oczekiwałoby oczywiście czegoś więcej, np. automa­ tycznego uzupełniania kodu stron JS F , podkreślania błędnych konstrukcji w kodzie stron JS F i X M L, wizualnej edycji reguł nawigacji pomiędzy stronami, diagnozowania oprogra­ mowania itp. Wszystkie te mechanizmy będą obsługiwane przez rozszerzenia platformy W T P (od ang. Web Tools Platform) opracowane specjalnie z myślą o technologii JSF. Samą platformę W TP zbudowano na bazie wielu innych rozszerzeń środowiska Eclipse. W czasie, kiedy pisano tę książkę, procedura instalacji i zakres funkcjonalności wciąż były przedmiotem zmian. W szczególności projekt JS F Tools wciąż znajdował się we wstępnej fazie realizacji (pracowano dopiero nad wersją 0.5). Czytelników zainteresowanych samodzielnymi eksperymentami z przyszłymi elementami funkcjonalności zachęcamy do instalacji odrębnej kopii środowiska Eclipse i wykorzystania mechanizmu Software Update do pobrania odpowiednich rozszerzeń. Należy zaznaczyć rozszerzenie JS F Tools i umożliwić programowi instalacyjnemu odnalezienie wszystkich niezbędnych rozszerzeń. Jak zmieniać lokalizację plików konfiguracyjnych? W przypadku niektórych aplikacji internetowych stosowanie własnych, niestandardowych plików konfiguracyjnych okazuje się lepszym rozwiązaniem niż korzystanie z plików facesconfig.xml lub web.xml. Problem w tym, że nie zawsze wiadomo, gdzie umieścić odpowiedni plik, ponieważ programiści często nie wiedzą, gdzie dany kontener W W W składuje pliki ich aplikacji. W praktyce kontener W W W w ogóle nie musi tych plików składować we własnych katalogach — może je odczytywać z pliku W A R . 600 JavaServer Faces Rozdział 13. ■ Jak to zrobić? Można ten problem rozwiązać, stosując metodę getResourceAsStream klasy External Context. Przypuśćmy na przykład, że chcemy odczytać plik app.properties składowany w katalogu WEB-INF naszej aplikacji. Odpowiedni kod przedstawiono poniżej: FacesContext context = FacesContext.getCurrentInstance(); External Context external = context.getExternalContext(), InputStream in = external.getResourceAsStream("/WEB-INF/app.properties"): Jak komponenty JSF mogą uzyskiwać dostęp do zasobów dostępnych w pliku JAR? String resourcePath = req.getPathInfo(): i f (resourcePath == nuli) return; InputStream in = getClass( ) .getResourceAsStream(resourcePath), i f (in == nul 1 ) return. OutputStream out = resp.getOutputStreamO; int ch; while ((ch = in.readO) != -1 ) out.write(ch) ; Kod tego serwletu należy umieścić w tym samym pliku JA R , w którym znajdują się mechanizm odpowiedzialny za wizualizację naszego komponentu i interesujące nas zasoby (w tym przypadku obrazy). W izualizacji podlegają adresy U R L w formacie resource/ścieżkaDoZasobu. Przypuśćmy, że opracowaliśmy bibliotekę komponentów i przekazujemy ją naszym klientom w formie pliku my component.jar. Załóżmy, że niektóre z mechanizmów odpowiedzialnych za wizualizację tych komponentów muszą generować łącza do obrazów lub kodu języka Java­ Script składowanego w ramach tego pliku JA R . Możemy oczywiście zasugerować klientom wyodrębnianie i przenoszenie tego pliku we wskazane miejsce, jednak takie podejście znacznie podnosiłoby ryzyko występowania błędów i obniżało atrakcyjność naszego produktu — dużo lepszym rozwiązaniem byłoby umieszczanie naszego pliku JA R w katalogu WEB-INF/lib. Rozwiązanie tego problemu przeanalizujemy na przykładzie komponentu datownika z gra­ ficznymi przyciskami zwiększania i zmniejszania wartości w polach tekstowych (patrz ry­ sunek 13.15). Mechanizm odpowiedzialny za wizualizację powinien wygenerować następujący kod języka H TM L: 23 24 25 26 27, 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 public static final String RESOURCE_LOCATION_PARAM = "p"; public static final String CONTENT_TYPE_PARAM = "ct", public static final String DEFAULT_CONTENT_TYPE = "application/octet-stream" private Map extensionToContentType = null; public ResourcePhaseListenerO { extensionToContentType = new HashMap(); extensionToContentType.put(" j s " , "text/javascript"); extensionToContentType.put(" .g if" , "image/gif"); extensionToContentType.put(" jpg", "image/jpeg"), extensionToContentType.put(".jpeg", "image/jpeg"); extensionToContentType.put( " .png", "image/png"); public Phaseld getPhaseldO { return Phaseld.RESTORE VIEW; 52 53 54 55 56 57 58 59 60 61. 62 63 64 65. String contentType = (String) external,getRequestParameterMap() ,get( CONTENT_TYPE_PARAM), i f (contentType == null) { int extensionlndex = resourcePath lastlndex0f(" "), i f (extensionlndex != -1 ) contentType = extensi oriToContentType.get ( resourcePath substring(extensionlndex)); i f (contentType == null) contentType = DEFAULTJflNTENTTYPE: 66 67. 68 69. 70 71. 72 73. 74 75 76. 77 78 79 80. 81. 82 83 84. 85. 86 87. } InputStream in = getClass() .getResourceAsStream(resourcePath); HttpServletResponse servletResponse = (HttpServletResponse) external,getResponse(), try { OutputStream out = servletResponse.getOutputStream(), servletResponse.setContentType(contentType), int ch, while ((ch = in.readO) != -1) out.write(ch), } catch (IOException ex) { throw new FacesException(ex), } context.responseComplete(); } } /** * Zwraca adres URL umożliwiający uzyskanie zasobu za pośrednictwem tej klasy 88. * 89. 90 . 91. * @param context kontekst stron JSF * @param String resourcePath ścieżka do danego zasobu * @param String contentType typ treści określany w ramach danego adresu URL lub 92 . 93. 94. 95. 96 97 98. 99 public void beforePhase(PhaseEvent phaseEvent) 100. public void afterPhase(PhaseEvent event) { i f (event.getFacesContextO .getViewRootO .getViewIdO ,startsWith( RESOURCE_PREFIX)) { FacesContext context = event.getFacesContext(), External Context external = context,getExternalContext(); 101. 102. 103 104. 105 106 107. 108 } String resourcePath = (String) external,getRequestParameterMap() .get( RESOURCE_LOCATION_PARAM), i f (resourcePath == null) return, * wartość mdl, jeśli typ treści nie ma być dołączany * @return adres URL w następującym formacie: * /appname/resourcefaces?r=resourcePath,ct=contentType lub * /appname/faces/resource?r=resourcePath,ct=contentType */ public static String getURL(FacesContext context, String resourcePath, String contentType) { ViewHandler handler = context.getApplicationO.getViewHandlerO; String url = handler.getActionURL(context, RESOURCE_PREFIX); StringBuilder r = new StringBui1der(url), r.appendC?" + RESOURCE_LOCATION_PARAM + "=").append(resourcePath); i f (contentType != null) r.appendC," + CONTENT_TYPE_PARAM + "=").append(contentType); return r.toStringO ; } 603 604 Rozdział 13. ■ Jak to zrobić? JavaServer Faces Jak spakować zbiór znaczników w ramach pliku JAR? Jeśli zaprojektowaliśmy komponenty, mechanizmy weryfikujące lub konwertery z myślą o wielokrotnym wykorzystywaniu w ramach różnych projektów, najprawdopodobniej będzie­ my je chcieli spakować do postaci plików JA R , które będzie można umieszczać w katalogach WEB-INF/lib dowolnych aplikacji internetowych. Jeśli zdecydujemy się przygotować autonomiczny plik JA R w taki sposób, aby użytkownicy nie musieli tracić czasu na edycję deskryptora biblioteki znaczników (T L D ) lub plików konfiguracyjnych, powinniśmy wykonać następujące kroki: 1. Plik T LD należy umieścić w katalogu META-INF . Plik deskryptora biblioteki znaczników powinien zawierać element uri, do którego użytkownicy naszej biblioteki będą się odwoływali w swoich stronach JSF . 2. W katalogu META-INF należy też umieścić plik nazwany faces-config.xml i obejmujący wymagane elementy component, val idator i converter. 3. Wszelkie pakiety zasobów i pliki konfiguracyjne należy umieścić w miejscu, w którym znajdują się nasze klasy. Można te zasoby ładować za pomocą metody ResourceBundle.getBundle lub Class.getResourceAsStream. 4. Należy unikać konfliktów nazw przez stosowanie odpowiednich przedrostków poprzedzających nazwy globalne, w tym wykorzystywane przez naszą implementację nazwy komponentów, klucze komunikatów czy nazwy mechanizmów rejestrujących zdarzenia. Na rysunku 13.16 przedstawiono strukturę katalogów biblioteki komponentu datownika omówionej w poprzednim punkcie tego podrozdziału. Rysunek 13.16. Struktura katalogów biblioteki komponentu datownika £3 spinnerLib.jar f [3 | I | meta -inf j~ Q MANIFEST. MF D spinner.tlci 605 Interfejs A P I technologii JS F nie obejmuje żadnej metody pomocniczej ułatwiającej określanie identyfikatorów formularzy. W tej sytuacji należy się posłużyć następującym kodem: UlComponent parent = component. while ( ! (parent instanceof UIForm)) parent = parent,getParent(); String formld = parent.getClientld(context): (Umieściliśmy ten kod w metodzie getFormld klasy com. corejsf. ut i 1. Renderers). Polecenia języka JavaScript można teraz wizualizować, stosując następującą konstrukcję: String command = "document formsL" + formld + .submit()": Jak sprawić, by funkcja języka JavaScript była definiowana tylko raz dla danej strony? Niektóre komponenty wymagają implementacji rozbudowanych konstrukcji języka JavaScript wykonywanych po stronie klienta. Jeśli pojedyncza strona zawiera wiele egzemplarzy takiego komponentu, chcielibyśmy uniknąć sytuacji, w której odpowiednie funkcje języka JavaScript były wielokrotnie powielane. Aby zablokować generowanie wielu kopii tego samego kodu, klasa odpowiedzialna za wizuali­ zację powinna uzyskać mapę żądania (za pośrednictwem metody facesContext .getExternal ^Contexto .getRequestMapO) i przypisać wartość stałej Boolean.TRUE do klucza właściwego dla danego typu komponentu. W odpowiedzi na kolejne wywołanie mechanizm wizualizujący uzyska ten klucz celem sprawdzenia, czy podobne wywołanie miało już miejsce w ramach danego żądania. Jak realizować zadania związane z inicjalizacią i przywracaniem oryginalnego stanu środowiska? L " Q faces-config. xml t corn ¥ (¡3 corejsf ¥ images I j j~ Q triangle.d own .png Q triangle.up.png r D ResourcePhaseListener. class | Q SpinnerTag. class f Q UtSplnner. class Q messages, properties Jak uzyskać identyfikator formularza niezbędny do wygenerowania struktury document.forms[id] w języku JavaScript? Niektóre komponenty muszą generować kod języka JavaScript, aby uzyskiwać dostęp do bieżącego formularza (albo celem jego wysłania, albo celem uzyskania dostępu do wartości pól wchodzących w skład tego formularza). Technologia JS F 1.2 wykorzystuje adnotacje @PostConstruct i @PreDestroy będące częścią standardu Java S E 6/EE 5 Common Annotations zdefiniowanego w dokumencie JS R 250. Jeśli komponent zarządzany jest ładowany w ramach kontenera zgodnego ze standardem Java E E 5, automatycznie zostaną wywołane metody tego komponentu oznaczone adnotacjami @PostConstruct. W chwili wygaśnięcia zasięgu żądania, sesji bądź aplikacji następuje wywołanie metod ozna­ czonych adnotacją @PreDestroy i zdefiniowanych we wszystkich komponentach zarządza­ nych mieszczących się w tym zasięgu. Kod odpowiedzialny za inicjalizację i przywracanie oryginalnego stanu środowiska należy umieścić w metodach oznaczonych odpowiednio adnotacjami @PostConstruct i @PreDestroy. W przyszłości wspomniane adnotacje być może będą obsługiwane także przez takie auto­ nomiczne kontenery jak Tomcat. 606 JavaServer Faces Czytelnicy, którzy pracują w technologii JS F 1.1 lub nie chcą uzależniać funkcjonowania swoich aplikacji od obsługi adnotacji, muszą dołączyć do kodu klasy nasłuchujące odpowie­ dzialne za inicjalizację i przywracanie oryginalnego stanu środowiska: ■ Aby zarządzać obiektami o zasięgu aplikacyjnym, należy dołączyć klasę nasłuchującą ServietContextListener oraz zaimplementować metody contextlnitial ized i contextDestroyed tej klasy. Klasę nasłuchującą powinniśmy dodać do pliku konfiguracyjnego web.xml w następującej formie: <1 istener> mypackage.MyListener ■ Aby zarządzać obiektami o zasięgu sesyjnym, należy dołączyć klasę nasłuchującą HttpSessi onLi stener oraz zaimplementować metody sessi onCreated i sessi onDestroyed tej klasy. Klasę nasłuchującą powinniśmy dodać do pliku konfiguracyjnego web.xml, stosując przytoczoną powyżej konstrukcję. ■ Aby zarządzać obiektami obejmującymi zasięgiem żądanie, należy dołączyć klasę nasłuchującą PhaseLi stener. (Fazowe klasy nasłuchujące omówiono w rozdziale 7.). Obiekty można inicjalizować w metodzie beforePhase, pod warunkiem że bieżący identyfikator fazy ma wartość APPLY_REQUEST_VALUES. Przywracanie oryginalnego stanu może się odbywać w metodzie afterPhase (na końcu fazy reprezentowanej przez identyfikator RENDER_RESPONSE). Jak składować komponent zarządzany poza zasięgiem żądania, ale w czasie krótszym od okresu istnienia zasięgu sesji? Większość aplikacji internetowych musi oczywiście składować dane pomiędzy pojedynczymi żądaniami stron, jednak zasięg sesyjny często okazuje się zbyt długi. Do największych wad tego zasięgu należą: ■ nadmierne wykorzystanie pamięci; ■ ryzyko składowania przestarzałych, nieaktualnych danych; Rozdział 13. ■ Jak to zrobić? 607 oraz przywracać komponenty lub właściwości komponentów (w czasie odtwarzania widoku). Łącząc ten mechanizm z techniką zapisywania stanu po stronie klienta, możemy stworzyć proste rozwiązanie ad hoc. Wystarczy w kodzie wybranych stron naszej aplikacji umieścić następujące komponenty: Stan jest zachowywany pomiędzy żądaniami kolejnych stron z wykorzystaniem pasujących do siebie komponentów i jest porzucany w chwili przejścia na stronę pozbawioną odpowiednich komponentów. 2. W ramach projektu JS F Extensions (patrz witryna internetowa https//jsf-extensions. ^ dev.java.net) zaimplementowano mechanizm imitujący zasięg „błyskowy” (mg. flash scope) znany z frameworku Ruby on Rails. Wspomniany zasięg ma postać mapy, której wpisy cechują się bardzo ograniczonym czasem życia. Element umieszczony w tej strukturze jest dostępny z poziomu następnej strony, ale usuwany w chwili przejścia na kolejną stronę. Projekt JS F Extensions definiuje zmienną najwyższego poziomu nazwaną f 1ash, za pośrednictwem której możemy uzyskiwać dostęp do zasięgu błyskowego. 3. Za pomocą menedżera dialogów opracowanego w ramach projektu Apache Shale (http//struts, apache, org/struts-shale/features-dialog-manager. html) możemy definiować sekwencje stron składających się na dialogi. Menedżer dialogów umożliwia nam traktowanie takich sekwencji jak jednostek wielokrotnego użytku. Jedną z zalet tego mechanizmu jest struktura zasięgu dialogu składująca dane w czasie trwania dialogu i usuwająca odpowiednie wpisy w chwili jego zakończenia. 4. Framework Seam (http://www.jboss.com/products/seam) umożliwia nam grupowanie wzajemnie powiązanych stron w ramach tzw. konwersji. Stosując odpowiednie adnotacje, możemy wskazywać komponenty obejmujące swoim zasięgiem czas trwania konwersji. Istnieje nawet możliwość operowania na wielu konwersjach właściwych dla tej samej strony otwartej w odrębnych oknach przeglądarki. Opisywany mechanizm najprawdopodobniej zostanie zaimplementowany także w przyszłych wersjach technologii JS F (zgodnie z dokumentem JS R 299 — patrz strona internetowa http://jcp.org/en/jsr/detail?id=299). Więcej informacji na temat frameworku Seam można znaleźć w rozdziale 12. ■ problemy z obsługą wielu okien odwołujących się do różnych stanów. Szczególnie irytujący jest ostatni z wymienionych problemów. Użytkownik może przeglądać pewne informacje w jednym oknie, po czym otworzyć inne okno, zażądać tych samych infor­ macji w nieco inny sposób, by następnie porównać dane uzyskane w obu oknach. Idealnym rozwiązaniem byłoby składowanie przez naszą aplikację konwersacji obejmującej kompletną sekwencję wzajemnie powiązanych ekranów (stron). Istnieje kilka podejść zaproponowanych z myślą o rozwiązaniu tego problemu: 1- Biblioteka komponentów Apache MyFaces obejmuje niewizualny komponent saveState (patrz strona internetowa http://myfaces.apache.org/tomahawk/ ^ uiSaveState.html). Za pomocą tego komponentu możemy dodawać komponenty lub właściwości komponentów do stanu widoku (w czasie jego zapisywania) Jak rozszerzyć język wyrażeń technologii JSF? Zdarza się, że programista staje przed koniecznością rozbudowy istniejącego języka wyrażeń. Na przykład mechanizmy integrujące interfejs JN D I z frame workiem Shale umożliwiają nam wykorzystywanie takich wyrażeń jak #{ jndi [ ' jdbc/CustomerDB' ]} do lokalizowania zasobów JN D I. W ięcej informacji na ten temat można znaleźć na stronie internetowej http //struts, apache, org/struts-shale/features-jndi-integration. html. Oczekiwany efekt udało się uzyskać, dodając mechanizm przetwarzający wyrażenie w postaci base.property (lub jego odpowiednik w formie base[property]), gdzie base jest łańcuchem "jn d i", natomiast property jest nazwą JN D I. 608 JavaServer Faces Rozdzianą. ■ Jak to zrobić? W technologii JS F 1.2 implementacja mechanizmu przetwarzającego wyrażenia wymaga rozszerzenia klasy bazowej ELResolver. Poniżej przedstawiono sygnaturę kluczowej metody tej klasy: public Object getValue(ELContext context. Object base. Object property) Jeśli nasz mechanizm przetwarzający „w ie” , jak interpretować wyrażenie base. property, możemy się posłużyć następującym wywołaniem: context.setPropertyResolved(true); W wyniku tego wywołania otrzymamy wartość naszego wyrażenia. Istnieje wiele innych metod stworzonych z myślą o obsłudze narzędzi analizy typów i konstru­ owania aplikacji (szczegółowych informacji na ich temat należy szukać w dokumentacji A PI). Przeanalizujmy teraz konkretny przykład — mechanizm umożliwiający lokalizowanie kom­ ponentów według identyfikatorów. Przyjrzyjmy się następującemu wyrażeniu: vi ew. 1ogi nForm.password.value Chcemy w widoku najwyższego poziomu odnaleźć komponent oznaczony identyfikatorem login Form i odnaleźć komponent oznaczony identyfikatorem password w ramach formularza, by ostatecznie wywołać metodę getVal ue tego komponentu. Nasz mechanizm będzie obsłu­ giwał wyrażenia w formie komponent. nazwa: public class ComponentIdResolver extends ELResolver { public Object getValue(ELContext context, Object base, Object property) { if (base instanceof UlComponent && property instanceof String) { UlComponent r = ((UlComponent) base).findComponent((String) property); i f (r != null) { context.setPropertyResolved(true); return r; powinniśmy otrzymać wywołanie: System.getProperty( "java.versi on"), Aby uatrakcyjnić budowane rozwiązanie, nasz mechanizm powinien prawidłowo interpretować także następujące wyrażenie: sysprop.java.version Tworzony mechanizm powinien obsługiwać także specjalny przypadek, w którym w miejsce obiektu base stosujemy wartość nul 1, a obiektowi property przypisujemy łańcuch "sysprop". Nasza implementacja powinna sobie radzić także z takimi częściowo kompletnymi podwyrażeniami jak sysprop. java. Listę wyrażeń gromadzimy w klasie zagnieżdżonej SystemPropertyResolver.PartialResolution. Nasz mechanizm rozróżnia dwa przypadki: 1. Jeśli obiekt base ma wartość nul 1 i jeśli property reprezentuje łańcuch "sysprop”, należy zwrócić pusty obiekt klasy Partial Resolution. 2. Jeśli base reprezentuje obiekt klasy Partial Resolution i jeśli property reprezentuje łańcuch, należy dodać daną właściwość na koniec listy. Zaraz potem podejmujemy próbę odnalezienia właściwości systemowej, której klucz odpowiada konkatenacji elementów tej listy oddzielonych kropkami. Jeśli taka właściwość istnieje, zwracamy ją; w przeciwnym razie zwracamy rozszerzoną listę. Poniżej przedstawiono fragment kodu, który dobrze ilustruje oba opisane przypadki: public class SystemPropertyResolver extends ELResolver { public Object getValue(ELContext context. Object base, Object property) { i f (base == null && "sysprop".equals(property)) { context.setPropertyResolved(true); return new PartialResolutionO; } i f (base instanceof PartialResolution && property instanceof String) { ((PartialResolution) base),add((String) property); Object r = System.getProperty(base.toStringO), context.setPropertyResolved(true), i f (r == null) return base, else return r; return null; } } Warto zwrócić uwagę na fakt, że nasz mechanizm przetwarzający jest wywoływany dla pierwszych dwóch podwyrażeń (vi ew. 1ogi nForm i view, logi nForm. password). Ostatnie wyrażenie jest przetwarzane przez mechanizm lokalizujący komponenty zarządzane, który wchodzi w skład implementacji JSF . W przypadku wyrażenia początkowego vi ew mamy do czynienia ze specjalnym przypadkiem. Mechanizmy przetwarzające są wywoływane z wartością nuli przypisaną obiektowi base i łańcuchem wyrażenia początkowego przypisanym obiektowi property. Wyrażenie w tej formie jest przetwarzane przez odpowiedni mechanizm wbudowany implementacji JSF , który zwraca właściwy dla danej strony obiekt klasy UIV i ewRoot. } return nul 1 ; } public static class PartialResolution extends ArrayList { public String toStringO { StringBuilder r = new Stri ngBui1der(); for (String s : this) { i f (r.lengthO > 0) r appendC.'); r append(s); } W kolejnym przykładzie spróbujemy skonstruować mechanizm przetwarzający właściwości systemowe. Na przykład dla wyrażenia w postaci: syspropC'java.version’ ] 609 return r.toStringO ; 610 RozdziaM3. ■ Jak to zrobić? JavaServer Faces Aby dodać do aplikacji JS F niestandardowy mechanizm przetwarzający wyrażenia, należy umieścić w pliku faces-config.xml (lub innym pliku konfiguracyjnym) następujący element: 4. 611 Mechanizm interpretujący nazwy pakietów komunikatów. 5. Mechanizm przetwarzający zasoby konfiguracyjne aplikacji (np. zawartość pliku faces-config.xml). com corejsf ComponentIdResolver 6. Mechanizm interpretujący przejęte (spadkowe) zmienne. Kompletną implementację obu przykładowych mechanizmów przetwarzających można znaleźć w kodzie źródłowym dołączonym do tej książki. K S J W technologii JSF 1 .1 modyfikowanie języka wyrażeń je s t bardziej skom plikowane, ■¡fej Implementacja JSF 1 .1 obejmuje konkretne podklasy klas abstrakcyjnych V ariable ^ R e s o lv e r i P ropertyR esolver, K lasa V a r iableR esolver odpow iada za przetw arza­ nie podwyrażenia początkowego, natom iast klasa PropertyResolver musi prawidłowo interpretować operator kropki lub nawiasów kwadratowych. Gdybyśmy chcieli dodać do języka wyrażeń jakieś własne zm ienne, musielibyśmy opra­ cować własny mechanizm przetwarzający te zmienne i wskazać go w pliku konfiguracyjnym — przykład takiego rozwiązania przedstawiono poniżej: com.corejsf.CustomVariableResolver «/vari able-resolver> 7. Mechanizm interpretujący przejęte właściwości. 8. Mechanizmy dodane za pośrednictwem metody Appl i ca 11on. addEL Resol ver. Diagnostyka i rejestrowanie zdarzeń Wykrywanie i rozwiązywanie problemów w aplikacjach JS F bywa dość kłopotliwe. Aby nasze aplikacje działały prawidłowo, musimy zadbać o mnóstwo szczegółów. Zdarza się, że komunikaty o błędach są trudne do zlokalizowania bądź wręcz niedostępne. Nawet naj­ drobniejsze literówki mogą uniemożliwiać uruchomienie aplikacji lub powodować, że jej użytkownik utknie w martwym punkcie. W tym podrozdziale przedstawimy szereg wskazówek, które mogą ułatwić programistom eliminowanie podobnych sytuacji. Jak rozszyfrować ślad stosu? W klasie przetwarzającej wyrażenia należy zdefiniować konstruktor przyjmujący na wejściu pojedynczy parametr typu Vari ableResol ver. Implementacja JSF przekaże za pośrednic­ tw em tego parametru swój domyślny obiekt odpowiedzialny za przetwarzanie zmiennych. Takie rozwiązanie bardzo ułatwia zastosow anie wzorca projektowego D ecorator (deko­ ratora). Poniżej przedstawiono przykład klasy rozpoznającej zm ienną nazwaną sysprop: public class CustomVariableResolver extends VariableResolver { private VariableResolver original: Kiedy naszym oczom ukazuje się strona podobna do tej przedstawionej na rysunku 13.17, możemy mówić o szczęściu. Rysunek 13.17. Typowa strona z komunikatem o błędzie Pwk Edycja widok Htrtoria SijlßS Zakładki Narejdz« ■itTp locdino''’ Pomoc 'cgir..iriaę »ac»- ' ! i : L r - ^ J S iM t iS p Ę 'Ś H ' HTTP Status 5ÖÖ - public CustomVariableResolver(VariableResolver original) { : this.original * original; . } public Object resolveVariableCFacesContext context, String name) { i f (name.equa1s( " sysprop")) return System.getProperties(); return original.resolveVariableCcontext. name); } } Podobnie wygląda Im plem entacja klasy PropertyResolver. Implementacja JS F stosuje mechanizmy przetwarzające w następującej kolejności: 1. Mechanizm interpretujący obiekty niejawne JSP . 2. Mechanizm interpretujący obiekty niejawne facesContext i view technologii JSF . 3. Mechanizm interpretujący nazwy komponentów zarządzanych. org ipache jasp ei iaspe rExce ption •index js p d b , 21} Ho tag lmptitTaxi.' de fin e d in tag L ib r a r y im ported w itl, p re rtr, "h* org apache ja s p e r com piler D e fa u ltE rro rH a n d le r js p E r ro r (D e fa w ltE r r o r H a n d le r Ja v a 03) orq apache laap er com pile/ Erro rD isp acch er d is p a tc h (E rro rD is p a c ch e r ia v a 402} o r 9 apache jasper compiler E r t or D lspatcher ja p E .io r fErro rD iap acclie r ja v a 236; orq apache ja sp er com piler P a rs e r parseCu stoaTaq (Parser gave 134$) orq apacbe jasper compiler Parser par®e£lem ents‘Pars er ja va 1593) org apache jasp er com piler Parser p a raeBod y(Parser ja v a 182*7) org apache ja sp e r com piler p arser par aeOptionalBodvCPa.raer gave 1.100) .■rg apache jasper com piler Parser p a rs “ CutstomTaq(Parser java t405) orq apache ja sp er com piler P a rs e r p a rse Ele m e n ts(P arse r ja v a 1S98) orq apacb© ja sp e r com piler P a rs e r par s eBody (pa r s e» gave 1827) Dig apache jasper com pilei P a rs e , par -seOptionalRody(Parse, ja va LlOO.i org apache ja s p e r com piler P a rs e r parseC «stoK® ag (Parser ja v a 1405) orq apache jasp er com piler P a rs e r parse Ele m ^ n ts(P arse r java IS98) orq apache ja sp ei com piler Pa rs e , p a rs e (P a rs e r ja v a P I ) org apache ja s p e r com piler P a r s e r C o n t r o ile r d d P a rs e (P a rs e rC o n tro lle r ja « a 250) orq apache ja sp e r com piler P a r s e c C o n tro lle r p a rs e (P a r s e r C o n tr o ile i ja v a 139) org apache jasper com piler Compiler g en e rateJava(C om piler ja v a 237) org apache gasper com piler Compiler com pile(Com piler ja v a 456) orq apache jaspei com piler Compiler co m p ile t Compiler ja v a 439) org apache ja s p e r JspCom pxlatianConte^t c o m p ile ( ispC om pilationContext ja v a 553) org apache ja sp er s e r v l e t Js p S a r v le W rap p e r s e r v ic e (J s p S e r v la W rap p e r gave 291) erg apache jasper 3e rv L e t 3spServLet s e r v i c e J s p F ile (J s p S e r v ie t java 301) org apache jasper s e r v le t js p S s r v l e t s e r v ic e (J s p S e r v le t ja va 248) javax s e r v l e t afcep H tc p S e rv le t s e r v ic e (H t t p S e r v le t ja va 85b) i fa c e s context Exte rnalC on textim p I d is p a tc h (Ex te m a lC o n te x tlm p i ja va 322) *n ViewHandlerlm p i c ende r V i^ V i« w H a n d le c Impl ja v a 142) com -Min fa ces L if e c v c le RenderBespcmsePh&se ; _____ execute _______________ _____ (RenderResponsePtiase t*v a 8"’) com son tace s li f e c y c l e L iie c y t le im p l p h a s e (L ife c y c le Im p i * ja v a l,,.,, 612 JavaServer Faces Rozdział 13. ■ Jak to zrobić? Wystarczy się zapoznać z pierwszym wierszem (lub pierwszym wierszem, który w naszej ocenie ma jakikolwiek sens) i odnieść jego treść do naszego pliku JSF . W tym konkretnym przypadku mamy do czynienia z nieprawidłowym znacznikiem (inputTaxt zamiast inputText) w kolumnie 21. wiersza 16. lub przynajmniej gdzieś niedaleko. W tej sytuacji musimy dokonać przeglądu plików dziennika. W analizowanym przypadku okazuje się, że plik dziennika zawiera bardziej szczegółowy raport: Caused by javax.faces.el.EvaluationException Error getting property 'password' from bean of type com.corejsf.UserBean java.1ang.Nul1Poi nterExcepti on at at at at at Caused by at Komunikat o błędzie może też sugerować występowanie jakiegoś problemu w naszym kodzie. Poniżej przedstawiono przykład takiego komunikatu: java lang.ClassCastException com.corej s f .UploadRenderer.decode(UploadRenderer.java :73) javax.faces.component.UIComponentBase.decode!UIComponentBase.java:658) javax.faces.component.UIIn p u t.decode( UIInput.j ava:464) javax.faces.component.UIComponentBase.processDecodes!UIComponentBase.jav a :878) javax.faces.component.UIInput.processDecodes(UIInput.java:380) javax faces component UlForm processDecodes!U I Form java at j ava.1ang.ref1ect.Method.invoke(Method.java:324) at comsun faces el PropertyResolverlmpl getvaiue(PropertyResolverlmpl java 79) 59 more javax faces component UIComponentBase processDecodes(UIComponentBase java 873) javax faces.component.UlViewRoot pnocessDecodesfUlViewRoot java 305) com sun faces hfecyde L i fecyc lelmpl phased i feeyc lelmpl java-200) com sun faces l i fecycle Lifecyclelmpl.execute!LifecycleImp1 java.90) javax faces webapp Ea c e s S e rvie t s e r v i c e f F a c e s S e r v i e t ja va com .cor ejsf u p l o a d F i l t e r doF 1 1t e r ( up 1oadF 1 1ter j a v a :6 8 ) 197) Wreszcie dysponujemy informacjami, które mogą nam się przydać — problem został spo­ wodowany przez wiersz 12. pliku User Bean.java. Zdarza się, że ślad stosu nie daje nam żadnych istotnych wskazówek na temat źródła błędu. Przykład skrajnie nieprzydatnego raportu przedstawiono poniżej: javax servlet ServletLxcept >on Cannot fina FacesContext org apacne jasper runtime PageContextImpl aonandIePageExcept ion(PageContextImpljava867) org apacne jasper runt ime PageContextImpl handlePageException(PageContextImpl java800) org apache jsp mae*jsp jspServicet moexjsp java 78) org apache jasper runtime HttpJspBase service(HttpJspBase java 133) javax servlet http HttpServiet servicetmtpServlet java 856) org apacne jasper servlet JspServ'etwrapper serviceiJspServletwrapper java 311) org apache jasper servlet JspServ’et serviceJspfiletJspServlet java 301) org apache jasper servlet JspServiet servicecJspServlet java 248) javax servlet http HttpServiet servicetnttpServlet java 856) W takim przypadku identyfikacja problemu jest dość prosta — wystarczy rzucić okiem na wiersz 73. pliku UploadRenderer.java i poszukać przyczyn błędnego rzutowania. Jeśli z wygenerowanego śladu stosu wynika, że identyfikacja oryginalnego źródła błędów w kodzie je s t niem ożliwa, należy skom pilować aplikację w trybie diagno­ stycznym. Jeśli korzystamy z narzędzia Ant, powinniśmy dodać atrybut debug="true" do zadania javae. Q Okazuje się jednak, że życie programisty nie zawsze jest usłane różami. Przyjrzyjmy się poniższemu raportowi: javax.servlet.ServletException javax.faces.el.EvaluationException Error getting property 'password' from bean of type com.corejsf.UserBean java.lang.NullPointerException org.apache.jasper runtime.PageContextImp1,doHandlePageException(PageContextImpl.java:864) org.apache.jasper runtime.PageContextImp1.handlePageException(PageContextImpl.java:800) org.apache.j sp.i ndex_j sp._j spServi ce(i ndex_j sp.java:78) org.apache.jasper runtime.HttpJspBase.service(HttpJspBase.java:133) javax.servlet.http.HttpServlet.servi ce(HttpServlet.java:856) org.apache.jasper.servlet.JspServletWrapper service(JspServletWrapper.java:311) org.apache.jasper servlet.JspServlet.servi ceJspFi1e(JspServl et.j ava:301) org.apache.jasper.servlet.JspServlet.servi ce(JspServlet.java:248) javax.servlet.http.HttpServlet.servi ce(HttpServlet.java:856) com.sun.faces.context.External ContextImpl.di spatch(Externa1ContextImpl.java:322) com.sun.faces.appl i cati on.Vi ewHandlerlmpl.renderVi ew(Vi ewHandlerlmpl.java:142) com.sun.faces.1i fecycle.RenderResponsePhase.execute!RenderResponsePhase.java:87) com.sun.faces.1i fecycle.Li fecyclelmpl.phase!Li fecyclelmpl.java:200) com.sun.faces.1i fecycle.Li fecyclelmpl.render(Li fecyclelmpl.java:117) javax.faces.webapp.FacesServlet.servi ce(FacesServlet.java:198) Tym razem podsystem odpowiedzialny za przetwarzanie konstrukcji języka wyrażeń opa­ kował wyjątek wygenerowany w kodzie komponentu w ramach obiektu klasy Evaluation ^Exception. Dowiadujemy się więc, gdzie wygenerowano sam wyjątek EvaluationException, co jednak nie jest zbyt dużym ułatwieniem — musimy jeszcze zlokalizować źródło wyjątku Nul 1Poi nterExcepti on, który doprowadził do opisywanej sytuacji. com.sun.faces.el.PropertyResolverlmpl,getValue(PropertyResolverImpl.java:89) com.sun.faces.el impl.ArraySuffix.evaluate(ArraySuffix.java:162) com.sun.faces.el impl.ComplexValue.evaluate(ComplexValue.java:146) com.sun.faces.el impl.ExpressionEvaluatorlrripl ,evaluate(ExpressionEvaluatorImpl.java:238) com.sun.faces.el.ValueBindinglmpl.getValue(ValueBindinglmpl.java:155) 55 more java.lang.NullPointerException com.corejsf.UserBean.getPassword(UserBean.java:12) at sun.reflect.NativeMethodAccessorImpl invokeO!Native Method) at sun.reflect.NativeMethodAccessorImpl invoke!NativeMethodAccessorImpl,java:39) at sun.reflect.DelegatingMethodAccessorImpl invoke(DelegatingMethodAccessorImpl,java:25) 139) com.sun faces i i fecycle.ApplyRequest ValuesPhase execute(ApplyRequestvaiuesPhase java.79) 613 Z czego wynika tak opisany błąd? Z niekorzystnego układu gwiazd i planet? Otóż nie — fak­ tycznym źródłem problemu był błędnie wpisany adres U R L ( http://localhost:8080/login/ index.jsp zamiast http://localhost:8080/login/index.faces). Jak unikać „śladów stosu z pieklą rodem' ? Większość programistów oczekuje od kompilatorów identyfikacji i sygnalizowania popełnia­ nych błędów składniowych. Okazuje się jednak, że kiedy pracujemy nad aplikacjami Java­ Server Faces, kompilator weryfikuje tylko nasz kod źródłowy Javy. Ewentualna niezgodność stron JSF , komponentów zarządzanych i plików konfiguracyjnych jest wykrywana wyłącznie w czasie wykonywania. Czasochłonne analizy nieczytelnych śladów stosu mogą więc mieć fatalny wpływ na produktywność programistów. Poniżej przedstawiono szereg wskazówek ułatwiających wykrywanie błędów, zanim będziemy się musieli zmierzyć z problemem „śladów stosu z piekła rodem” : 1. Warto korzystać z edytora języka X M L weryfikującego poprawność składniową kodu tworzonych stron JS F i plików konfiguracyjnych. Edytor powinien alarmować użytkownika o błędnych elementach i nazwach atrybutów, a także nieprawidłowo zagnieżdżanych konstrukcjach. W tej roli dobrze się sprawdzają domyślne edytory 614 Rozdział 13. ■ Jak to zrobić? JavaServer Faces kodu JS P i X M L oferowane w ramach środowiska NetBeans. Użytkownicy środowiska Eclipse mogą skorzystać z edytora XM LBuddy. Jeśli korzystamy z autonomicznego edytora tekstu, warto poszukać odpowiedniego modułu rozszerzenia, np. n X M L dla edytora Emacs. 2. Należy pracować w środowiskach wytwarzania JS F , które potrafią interpretować komponenty zarządzane i konstrukcje języka wyrażeń. Jeśli nasze środowisko ID E oferuje funkcję automatycznego uzupełniania kodu, możemy przyjąć, że to nie literówki będą największym problemem. Jeśli nasze środowisko wytwarzania oprogramowania dodatkowo weryfikuje spójność stron JS F , komponentów zarządzanych i pliku konfiguracyjnego faces-config.xml, wiele błędów będziemy mogli wykryć jeszcze przed wdrożeniem. 3. Należy korzystać z mechanizmów weryfikujących. Większość serwerów aplikacji oferuje możliwość weryfikacji plików W A R przed wdrożeniem. Tego rodzaju mechanizmy potrafią odnajdywać wiele różnych błędów, w tym brakujące klasy i błędy składniowe w kodzie stron JSF . Użytkownicy serwera GlassFish mogą skorzystać z następującego polecenia: glass f i s h / / n/veri fi er appname.war Użytkownicy środowiska NetBeans powinni kliknąć projekt prawym przyciskiem myszy i wybrać z menu kontekstowego opcję Verify Project. 4. Jeśli korzystamy z implementacji Sun JS F , możemy wymusić weryfikację składni pliku konfiguracyjnego faces-config.xml i definiowanych w nim obiektów zarządzanych. W tym celu należy umieścić w pliku web.xml następujące wiersze: com.sun faces.val idateXml true com.sun.faces.veri fyObjects true 5. Należy używać debugera. Większość zintegrowanych środowisk programowania (ID E ) oferuje możliwość zdalnego diagnozowania serwera aplikacji. Możemy definiować punkty wstrzymania (ang. breakpoints) w kodzie komponentów zarządzanych, mechanizmów odpowiedzialnych za wizualizację, a także — w niektórych środowiskach ID E — w kodzie stron JSF . Sama konfiguracja odpowiednich mechanizmów może być czasochłonna, jeśli nasze środowisko nie oferuje predefiniowanej obsługi serwera aplikacji, jednak efekt końcowy jest wart wysiłku. Jak wdrażać aplikacje „na gorąco”? Wdrażanie aplikacji wymaga czasu. Serwer aplikacji musi wyłączyć starą wersję aplikacji, po czym rozpakować, zweryfikować i zainicjalizować nową wersję. Wymienione zadania mogą zabierać programistom mnóstwo czasu. 615 W trybie wdrażania „na gorąco” (ang. hot deployment) wystarczy skopiować zmienione pliki do katalogu wdrożenia. Serwer aplikacji automatycznie wykrywa zmiany w znacznikach czasowych plików i dokonuje przyrostowej aktualizacji aplikacji z uwzględnieniem nowych plików. Takie podejście jest dużo bardziej efektywne i podnosi produktywność programistów. Technika wdrażania „na gorąco” jest stosowana przez wiele zintegrowanych środowisk pro­ gramowania, np. NetBeans. Jeśli jednak sami kompilujemy nasze aplikacje, musimy opa­ nować sztukę włączania opcji takiego wdrażania na wykorzystywanym serwerze aplikacji. Poniżej opisano odpowiednie reguły obowiązujące na serwerze GlassFish: 1. Nie należy tworzyć pliku W A R . Zamiast z niego powinniśmy korzystać z techniki wdrażania katalogów (ang. directory deployment). Układ naszego katalogu ze skompilowanymi plikami musi dokładnie odpowiadać strukturze pliku W A R . 2. Musimy wykonać następujące polecenie: g 7assf 7s/7/bin/asadmi n deploydi r ścieżkaDoKataloguKompi la c ji W ten sposób wskazujemy katalog dla naszej aplikacji internetowej i wymuszamy wdrożenie początkowe. (Nazwa ostatniego składnika ścieżki do katalogu ze skompilowanymi plikami musi odpowiadać nazwie naszej aplikacji). 3. Serwer GlassFish domyślnie stosuje technikę dynamicznego ponownego ładowania (ang. dynamie reloading). Po zmianie plików w naszym katalogu kompilacji wystarczy odczekać dwie sekundy i odświeżyć stronę w przeglądarce. Takie rozwiązanie zdaje egzamin, kiedy modyfikujemy strony JSF . Z drugiej strony, pozostałe zmiany (w tym zmiany w klasach i plikach konfiguracyjnych) wymagają ponownego wdrażania, które można wymusić, modyfikując znacznik czasowy pliku ścieżkaDoKataloguKompilacji/.reload (w systemie U N IX można to zrobić za pomocą polecenia touch). Jak umieścić w komentarzu wybrany fragment kodu strony JSF? W niektórych przypadkach określenie, który fragment strony JS F powoduje wyświetlanie śladu stosu, może wymagać umieszczania w komentarzach kolejnych fragmentów kodu strony zgodnie ze strategią „dziel i zwyciężaj” — w ten sposób możemy izolować komponenty prowadzące do błędów. Ku zaskoczeniu wielu programistów standardowe komentarze języka X M L (w formie kon­ strukcji ) nie zapobiegają przetwarzaniu zawartych w nich komponentów. Co ciekawe, takie komponenty są przetwarzane i wizualizowane wraz z symbolami , które — tym samym — nie są widoczne w wynikowym dokumencie HTM L. Takie rozwiązanie z pewnością nie ułatwia diagnozowania aplikacji, ponieważ w żaden sposób nie wpływa na generowane wyjątki. Opisane zachowania sprawiają co prawda wrażenie dziwacznych i nieprzemyślanych, jednak musimy mieć na uwadze, że większość stron JS F nie ma postaci prawdziwych doku­ mentów X M L . Mogą obejmować na przykład konstrukcje właściwe dla składni stron JSP , 616 JavaServer Faces Rozdział 13. ■ Jak to zrobić? np. dyrektywy tag 1ib %>. Mechanizmy odpowiedzialne za przetwarzanie kodu JS P pozostawiają separatory komentarzy X M L w niezmienionej formie. Można ten problem rozwiązać na dwa sposoby. Pierwszym z nich jest stosowanie komentarzy JSP , czyli konstrukcji <%-A>. Ewentualne komponenty umieszczone pomiędzy tymi separatorami nie będą przetwarzane. Rysunek 13.18. Interfejs administracyjny serwera GlassFish ¡B M T y jr JavaTM) Syrern Application Server Platform Édition 90 Admin Consoie Mozitla Firefox £’* i 5*!*]* Wrdot! Historia ZaWadH tettęctoa 617 Pomoc Û :ï i l j http://localhostj4848^sadmin/adminguj/TopFiameset RSS3SI WB3BEBÊ er® K ta iia i W M U u m b u m wsm Sun Java™ System Application Server Admin Console W elcom e to the Sun J a v a rv Sy ste m Application Server Alternatywnym rozwiązaniem jest konsekwentne stosowanie reguł języka X M L podczas prac nad tworzeniem stron JS F (patrz rozdział 2.). Jeśli umieścimy kod naszych stron JS F w ramach znacznika jsp: root, komentarze XML-a będą interpretowane zgodnie z naszymi oczekiwaniami: < ? xít) 1 v e r s io n - " l 0"?> < Teraz możemy z powodzeniem umieszczać znaczniki -• -r-B ■wnno'.E' w komentarzach XML. —> Gdzie należy szukać plików dziennika? Szczegółowe rozwiązanie problemu lokalizacji plików dziennika zależy od wykorzystywanego kontenera W W W . Serwer GlassFish rejestruje wszystkie komunikaty w pliku glassfish/ ^domains/domain I /logs/server .log. Zawartość tego pliku można przeglądać zarówno za pomocą edytora tekstu, jak i za pośrednictwem interfejsu administracyjnego serwera. Warto się zalogować na stronie http://localhost:4848/asadmin. Domyślną nazwą użytkownika jest admin , natomiast domyślnym hasłem administratora jest adminadmin. Po zalogowaniu w oknie przeglądarki powinniśmy zobaczyć stronę podobną do tej, którą przedstawiono na rysunku 13.18. Pierwszym zadaniem na stronie Common Tasks jest Search Log Files. Należy kliknąć to łącze, aby nasza przeglądarka wyświetliła zawartość plików dziennika (patrz rysunek 13.19). Serwer Tomcat 5 składuje dzienniki w katalogu tomcat/logs. Do standardowych plików dzienników serwera Tomcat należą: ►Join the Ft- iert wJasshaL C< ► Need help' Learn how to ger ► Trv Meti-iraliS ' i i Zarówno serw er Tom cat, ja k i I h U rzystują mechanizm rejestrował Commons (patrz strona internetowa i biblioteka rejestrowania zdarzeń je s t v gólności bibliotek java. uti 1,1 ogging (.http://logglng.apache.org/log4j/do biblioteka je s t lepsza I czy stosował (patrz strona internetowa http://w m bibliotekę ja v a .u til. logging, która częścią standardu Javy. from Sim EE 5 based D E erencyjna technologii JSF wykowany w ramach projektu Apache tache.org/logging/). W spomniana o wielu innych bibliotek, w szczeetu JDK 1 .4 ) oraz Apache Log4J nons je s t dobrym rozwiązaniem nkAgain.htmf). Sami preferujemy iskonała — zdaje egzam in i je s t ■ catalina.out ■ localhost_log.data.log Składnik data w nazwie drugiego z wymienionych plików reprezentuje znacznik czasowy, np. 2003-06-30. Plik catalina.out zawiera wszystkie dane wyjściowe wysłane do System.out i System.err. W konfiguracji domyślnej są to wszystkie komunikaty cechujące się poziomem ÍNF0 lub wyższym. Pliki localhostJog.data.log obejmują komunikaty wygenerowane przez kontekst serwletów. Jak sprawdzić, które parametry przekazano za pośrednictwem naszej strony? Z reguły chcemy wiedzieć, jakie parametry aplikacja kliencka odesłała na serwer wraz z zaakceptowanym przez użytkownika formularzem. W tym punkcie skoncentrujemy się na szybkiej, ale mało eleganckiej metodzie rejestrowania parametrów żądań. 618 Rozdział 13. ■ Jak to zrobić? JavaServer Faces .M L . ' Z M -i a S ife (ft' W dzienniku zdarzeń będą wówczas gromadzone między innymi następujące wpisy: S e a r c h R e s u it s Instance: * Apr 2. 2004 12:50:45 PM org.apache.jsp.welcomej s p INFO name=_id0,value=_id0 Apr 2, 2004 12:50:45 PM org.apache.jsp.welcomejsp INFO- name=_idO._idl.value=me Apr 2, 2004 12:50:45 PM org.apache.jsp.welcomejsp INFO• name=_idO:j d2.value=secret Apr 2, 2004 12:50:45 PM org. apache.jsp .wel comej s p INFO- name=_id0._id3,value=Login I server I o ts É S s s s i M S í i s í I ¿ I Log Level 1 1°37 INFO I 1036 INFO 1 1035 INFO j Message Application server startup complete (details) ■Self Management Rules service is enabled ¡details) Loading web module [__JWSappelients svs war] in virtual server [server] at [I__JWSappclients] (details j L ogger i Timestamp javas enterprise svstern coie ' 2007-1 -10 08 39 58 604 _ThreadlD=l0,._ThreadNarne=main, tavax entei rn core selfmanagement lavax enter svstern container web tavax enterprise svstern core Name-Value Pairs 2007-1 •19 08 39 53 57 8 _ThreadlD=i0, _ThreadName=rnain, ’ 2007-1 -19 0:3 39 58 417 1 1034 1 1033 INFO Starting Sun-Java-SvstemiApplication-Server HTTP/1 1 on 4848 (details.) ia»ax entei svstern container web 1 1032 INFO Starting S un-J a-a-Svste rn,'«pp11cati ori-S er/et HTTP/I 1 on 8181 (details) lavax enter svstern container web 2007-1 -1 9 08 39 57 886 _ThreadlD=10,_ThreadName=mam,8181, ■d'.-i -"te' ;'-,Íd'. 2‘-'"- i ' _JWSappclients IMP'' 1 1f0't "E- E p E I >02» # ,E L P E 3 'Fw-■■ .'¿H.Uli -ti -,:VU f. h TTP ’1 1 ...i onor nnie^t Ud'tur '-Ilrij .JyO to ■ r-d. sen,l-,-"r.L,rr,tiu..j,ji2i'i.'iEP ¡I'll I- r--. itm ..tai.iHl -Gt ...r, „15 r,. -itai.iid'D ,d., i -ntr-. li.c-tpn. •. .ntaingl ...i-i 2007-1 -19 08 39 58 01 1 _TlneadlD=10,_Thre a dN ame=in a in,4848, ■ -e-uE 19 O0 .M ’ „iiriz i- _ r.i.CJ „jl 1.11,-=. I. a,.. _ C'u.jIjG r,..dddlt,e 1" 1. 6 o^'i'ieteu .rrit'arizing j. - a o a s ^ o ip . r , — .rul,iern~ntatinn >, .02 t.iOj F' S '..' . ""'le:1 •j-ta.is •a-d i-ntr' n- omanie, id' •.j'.tiii IQ?? IMF,. " itianzmg Sun'- idva-e-e'F r e. .m,.iprr.-r.Tatr'». ■' / 0.. r.njS Tf g, iq. .,nte”T aujn.ne'j.ji; oota,. id.-a ei'tc. l,f Ot.tdi..Gi ,31 111itin N '0’ 1 i ' " 1Q?S IFlr ■ . nr..(Jieiea .nitiauzinu r- - ■ , ja„„sp.,.a. r ■' ¿..j. t'O : f ( s !<■„ ..omeift ■■aodsr.'. ■oetai''-. •a..d eme. i. ..'■lR 1 1 . n;-, g S7 n-s _ ---- .ai[,= Ti . ri •i e -to11ai f■ c=ii,an ..id-," '■ '025 ■ M ■ irut.ailZ|..i.l ■ Ia".3&-'ve. F I-"'- .'-‘.r.ia'-.tmtdti ... i 2_u.. nfl -f- S'tn- ii.%.;i u., js- .mi ,u,-tan- , . iU;: .n-^dPi-i _ m.d=ig|[i= i n _ riirPddNd ."f=''"d' ...-ia-as- n ' 02a ■Njr ■"* I....P _ rm-njiD: Ul. to r llvjf Í 1 '023 If if ' 02' iKlP 1020 IMF.... umDieti-U .r'ltidHZH-g Sd" - ia ->ob>-O- F O r : ■'■'■l.iemeniflti.ir' i ^ .02 "0 i r .- .r..[ii-i'r.-"tatiui' iiMiianzi'iii b y 'aur,Se>..^. r , e .r..[iier..cniaii..r 1 -_u. n"3-f ■S.'u-■'oniexr details mulcted .n.tidiizi'iu 2uri • >'a>.aSc'">=' r a- “ ■ ■ ■ u )^ ■ t=r.tRtiri i ;■. 0/ r.o r<~q i,_,t onte'a ■dsa.i'r.i1',-u-t^i's. .a a eme' 1. -jntai,.^. , t c nthl ng ' i ., .a- - r-.-tei n. nt-.iiut ,*1 . -'"'it11 .a-a „ntr. »in 1ici -onîi g ■ d.d- -l'iTc' n. «’ir*i^5= .-...a. rmei Ul ritai»«R' |öl i u"TIg ¿rirw , jm r r -s, JC) -.1. ’ . 20i,- ' ,d..a -nt&r t . rtntdinfcr ,0r ■«-*nîig rr,.r ^i)(\|^rnO—llri .|iti .trijmiip. . rritdSjILll 10 . ft— cio''lat' -1ai-•-ic.i.ji. i ■nc' '• 5b bi " _ TtiiMadlLir r u Nw _ n-irpajiLi-. i o . n,readNaniw=".di'. u -b 68" 19 08 -'9^5 .mo '..itiailZi'.Li S'J'-' - ja..aSar.,r , F P1 /_u. rnj -F'.S-'C" i ontexi aa.i.Jmin .Jetmis. n. iiitdlMPr ,-1 01ltdj 2' 0" 1 1,, ne ¡gajem ; . rt-readiD: ' 0 _ r,.rr ddNa,'1“ =r., din.rasad'''" Lr,aui"a « OS ¡'3 5/ 925 . rnteadiD= ' 0 . rnreadNan-ersn-an..Puinj se 1 1017 i'.|! KJ Luading “ cu .-nnaijir [ouizneani .i> ..>iua' aj n.e. |sef. er| at l.tOulZi.tPdri| .detail-.. -«ste*> umai«rł «»ei 20117 1 i9 ,9 52 31- iClfSj,-t'-'1 tlda1. ..luizne.a . rri'padiD-10 _ rrIre = 1 1016 it>|F ij ,1.1.7 , i 9 On i-<52 894 . rn.eddiD-'O,. rrneadN-ri,a=maii. ,a-asi ", 2r|07 I i - 08 J® 5. ob J . n.rcaoiLir n'j _ rnieadNar'ie='"di|i,iu''rinc.. •u*itai"ef Monitor HTTP środowiska NetBeans i i NetBeans !DF 5.5.1 'javascript ;. z m m é i& k m im m ) j | F'« Liii' View ISovigatf Source Reractoi Bntłrt Run CVS Tools Wmanv» Help ^ ^ ^ ü j ć b Protects ^ ^ p 82 Files - j 'r"Je hrrf" -nde "to * | -Ó 2: @ ^remer. ©a i.. ® layout.xhtml I ę, ’ 1 1 i Naingatoi <8 it j j 3: ¿ r * ë P ..x.jsp [ i ä .nctex.łitml ?«] Ś.teyoijt.xrtmi lg) a-i'iian.ridq gi> ® ■# . - ! -A 'V ¡ ^ lii.:...' ¡ 3 ^ — ..eacj xl F c iń 61 ?! • i 9ił | 10; im ¡ | j I p PLzyFiiaa usy-iu ledii- - 1 T'Ti e i t i ’ Lt r.* 1 1014 IMP,.. Loading ...er .‘'i.'U.ji.- iddminguii .r iuua' M'-s. |__a.adunnni ni l.iaadjrnini ■a a -fntei r^tair-ip. aeu iMPr, Ludai"g n.ei n.w„]uie [ad'-manpi uui.eL.’j details' ■a.is dutei -.■,vI0rr. -.jntaiPc« -«cU "tud' sen.e. |__d-admini it 200" 1 i 9 n- jo w., . r,..eadiD= i u _ rrireadNfn.eeirriaii' Jfjrnil'y 2-u" 1 10 O' '!- 5. ' 7" _ rnto agiDr ' 0 _ riKeadNatrie=r,.ai.i ddmii.ai ] Search Results Output I * 0 if ^ |j Meta data i P io s z k T.ipi?ac nas^ępuT^* « ® p Enumeration e = request getParameterNamest ) \ j |i HTTP Monitor ¡ Cooioesjession [ i^ncext f Cnem and Serve» f headers] <¥ 5« ;W... - j¡ j: ^tsf-Lo... Request 5a- ed FF'eoa'd. rnete^asnoquer, scrina ' Z Z ' l;Z'..: java u t i l ' .jj l- HTML Forms F i P0rm GET Chari..etas ^ Na początku pliku JS F otrzymującego żądanie należy umieścić następujący fragment kodu: <% ! |ï f f j Text Inpu' |{ Rysunek 13.19. Ekran przeglądania dziennika serwera GlassFish i | | » L in k ---------------------------- J P~i Mult-line Inpu1 p ^ Al'PeCd'dS || •- ^1 .unen- a d s Zäk O^CZClO [§4 Image - £Vciom >'0"tainpł "f0D , I L iJ ,a„a rat“ ' 'ooie 1 L.-.eij|l"i ...ct, rn Idu|t Iriufn'-e'dUiZI -r' 'Uijd' e'-d' isoweg ar i.'riijrr'tje.gu'zi aetan. ■ VÈ i Cj unordered ust ¿T ll.jl ÉT Palette S> » C HTMl................. V O 4 j j i#- Í P ,_j| ,,... [j* O'dered ust I.iid^-is- k,pt| uetans 1 1 1015 I 1013 Po uruchomieniu aplikacji wybierz z menu Window opcję HTTP Monitor. 1 IMF . ■ •ci. a- eme. 4. . r>'„e .di['= i" _ n. i' e ad' -iar" e~r" in a = •adif'' i. iM! ■ •a.-a f'ttd' 3. Zaznacz pole wyboru Use HTTP monitor. Rysunek 13.20. 1 1018 1 1019 kontekstowego opcję Properties. rh.oa,j|fi-1 n ri.rpajl'.H.iiP=ii,ai!..,ri,j'i.' — ■MF ■ ri..u a.jiL'f 1'i Kliknij zakładkę Runtime i rozwiń węzeł Servers. 2. Kliknij prawym przyciskiem myszy pozycję GlassFish i wybierz z menu 1028 ntdinw .et . „nt,g jspService Programiści, którzy pracują w środowisku NetBeans, mają do dyspozycji znacznie lepszy mechanizm „szpiegowania” komunikatów protokołu HTTP (patrz rysunek 13.20). Użytkownicy środowiska NetBeans 5.5 mogą ten cel osiągnąć, wykonując następujące kroki: ..jetdii , ,..,pi_,T.el.ia1,0,. jspService rmcdiji i d11.p—r. iai- . p-"i,ji- E *• ■ it'in -' 1-- _jspService _r,.ro .,J1[ 1: 1u _ ri.l-„jMd...e=in-„ a"-'-_ r, ••t'-' _jspService _ThreadlD=10,_T hread Na in e=rna rn__ JVVS ; 2007-1 -1 9 08 39 58 136 _ThreadlD=10,_ThreadNarne=inain, INFO I 1030 # 619 .. ‘ ____ wtulę (e hasMoret lem e nist)) 1 S t r in g n = ( S t r i n g ) e n ex tE 1ement( ). S t m n g [ ] v = request getPa rame terVal u e s ( n ) . for ( i n t i =0 jav a u t i l v != nuli && i < v length, logging Logger global i- ^ ) i n f o ( “ name=" - n + " >value=" + v [ i ] ) . Monitor protokołu HTTP wyświetla kompletne zestawienie komunikatów przekazywanych pomiędzy przeglądarką a serwerem W W W i — co dla nas szczególnie ważne — dekoduje żądania. Taka możliwość jest szczególnie cenna w sytuacji, gdy konstruujemy własne komponenty niestandardowe. Rozdział 13. ■ Jak to zrobić? JavaServer Faces Jak włączyć tryb rejestrowania zdarzeń związanych z pracą kontenera JSF? ^ Sun Java(TM) System Application Server Platform Edition 9,0 Admm Console - Mozilla Firefox Plik Edycja ♦ * ♦ Widok • f ? Historia Q Zakładki Narzędzia . j§ User: admin Server: iocalhost Domain: domainl Implementacja referencyjna technologii JS F obejmuje niezliczone operacje rejestrowania zdarzeń, których dane wynikowe mogą być bardzo pomocne w procesie lokalizowania problemów w naszych aplikacjach. Sun Java™ System Application Server Admin Console ifO Common Tasks ü Jeśli korzystamy z serwera Glass Fish, możemy w wygodny sposób zarządzać rejestrowaniem zdarzeń za pośrednictwem interfejsu administracyjnego. W tym celu musimy się zalogować na stronie http://loca/host:4848/asadmin. Domyślną nazwą użytkownika jest admin, natomiast domyślnym hasłem administratora jest adminadmin. Logging F F S Ż F 5 Servei W S i M-l- ' g j f - r . , - -t p- lHÜ 3 a ,i, , T... M- .51j11- S Life- ■■'C- f"l.„JulP Ü3 App Client Modules Należy następnie kliknąć kolejno węzeł Application Server, zakładkę Logging i podzakładkę Log Levels. W dolnej części wyświetlonej strony znajduje się tabela zatytułowana Additional Module Log Level Properties. Właśnie tam należy dodać nowy wpis nazwany javax. enterpri se. ^ re s o u rc e .webcontainer. j s f i z poziomem FINEST (patrz rysunek 13.21). JÜ W e Li Se r-i ces §§j Custom MBeans ^ Module Log Levels -I't'l' .ÎI- !' E 1B r u i1. ji— ir.,j M'lei * TiNtSI -n.,,s,n i I IrJEP1 Mnij-r il—■ ° 111, , .Ti * r 11JE Minimal veiu L i » * » l O N FIG Messages related to se rve r c onil g urati o n INFO Messages related to setvet configuration ot server status, excluding errors WARNING Warnings, including exceptions S E V E R E Events that interfere with normal program execution Resources Configuration Admin: Configuration: Connector: CORBA: Przedstawione ustawienia spowodują wyświetlenie ogromnej ilości informacji. Zakres tych danych można ograniczyć, wybierając interesujące nas elementy potomne. Mechanizm reje­ strowania zdarzeń wyróżnia następujące przyrostki: .context .lifecycle .renderkit tag!ib Jeśli na przykład interesuje nas monitorowanie faz cyklu życia, powinniśmy przypisać poziom FINEST nazwie javax. enterprise, resource, webcontai ner . j s f . 1i fecycl e. Jeśli korzystamy z serwera Tomcat, powinniśmy skonfigurować dane wyjściowe rejestrowania zdarzeń z wykorzystaniem standardowego mechanizmu biblioteki ja v a . uti 1 . 1 oggi ng: ¡ÍÑFO in f o n fo Deployment: EJ8 Container: JarvaMail: JAXR; .application .config fe 13 [ ,feJ 0 |T 3 E * ™ ““ [¡3 p fd F c T ” ~ 3 ¡I . .y [T F “”™ . .tíSi ¡7 ~ ~ ~"T3 fÎNFO y ¡INFO Classtoader: Przeszukując dzienniki zdarzeń, koniecznie należy ustawić poziom rejestrowania wyższy niż domyślny poziom INFO. Odpowiedni przykład przedstawiono na rysunku 13.22. n fo n fo n fc JAXRPC: MS: n fo JTA: jT rT T T " JTS: |7 r _ " ~ MDB Container: ¡ I n fo Naming: ¡ I n fo - Persistence: pNFO . s .. -Djava. u t il.logging.config.fi] e=tomcatI conf/ logging.properties W systemach U N IX i Linux należy użyć następującej składni: CATALINA_OPTS="-Djava.uti1.1 oggi ng.config.fi 1e=tomcat/conf/1ogging.properti es" “ ...... ,W Root: ..B ........ y Security: ¡INFO Seif Management: [INF0 ......y Server: Utii: |1 n f o ~ Verifier: ¡I n f o ™ " Web Container: fïïF o - . y ’ 7TB Additional Module Log Level Properties (1) Delete Properties W systemie Windows powinniśmy zastosować taką składnię: set CATALINA_OPTS=-Djava.uti1.1oggi ng.confi g.fi 1e=tomcat\conf\1 ogging.properti es @ T 3 SftftJ: 1- W pierwszej kolejności należy zmodyfikować skrypt catalina.sh lub catalina.bat dostępny w katalogu tomcat/bin. Na początku tego skryptu powinniśmy dodać wiersz przypisujący zmiennej CATALINA_0PTS następującą definicję parametru: k\ ;'U Name i--! ; {vaKeTterpnse resource? j X , || fl | Value FIN EST (Jak zawsze w takich sytuacjach element tomcat reprezentuje ścieżkę do katalogu, w którym zainstalowano serwer Tomcat, czyli np. /usr/local/jakarta-tomcat-5.5.19 lub c: \jakarta-tomcat-5.5.19). 2. Plik logging.properties należy skopiować z podkatalogu jre/lib pakietu Java SD K do katalogu tomcat/conf. Rysunek 13.21. Aktywowanie trybu rejestrowania zdarzeń w ramach kontenera JSF (na przykładzie serwera GlassFish) H ü Pomoc ] 2 H L Í http!//łocalho5t:4848/a$adrnin/admingui/TopFrameset - 620 621 622 JavaServer Faces Rozdział 13. ■ Jak to zrobić? 623 ■ W pierwszej kolejności należy raz jeszcze sprawdzić reguły nawigacji, aby mieć absolutną pewność, że zdefiniowano je prawidłowo dla danej strony. ■ Najczęstszym powodem niemożności przejścia do kolejnej strony aplikacji internetowej jest występowanie jakiegoś błędu weryfikacji lub konwersji. Łatwo to sprawdzić, umieszczając w kodzie tej strony znacznik . ■ Jeśli powyższe kroki nie pozwoliły nam zlokalizować źródła błędu, należy skorzystać z narzędzia śledzenia faz. Prostą implementację takiego mechanizmu przedstawiono co prawda w rozdziale 7., jednak w praktycznych zastosowaniach warto rozważyć użycie bardziej dojrzałego narzędzia FacesTrace (patrz strona internetowa http://facestrace.sourceforge.net). Wspomniane narzędzie prezentuje fazy w estetycznej formie graficznej (patrz rysunek 13.23). Aplikacja testująca da^ąpie rt Rysunek 13.23. Narzędzie FacesTrace w akcji Plik Edycja I Widok I I MM M M M M i weryfikując Historia ^ ''Xih ""*"'■""■’ ■ ■ “ Prosimy wpisać inform acje o płatwności: u. [ 'd ta wrazii s n - m i r Rysunek 13.22. Zmiana poziomu rejestrowania zdarzeń w przeglądarce dzienników serwera GlassFish i Zakład*: ■ Narzędzia 514ciX 'th1 t' LiS: ■ tu i'-isO- dVTM-titJ: ■= u t \-Ju- nuD lucnii [ P tz ę iy -p r? i Racist. Trace »O C E S S 3. W kolejnym kroku powinniśmy zmodyfikować plik nMf tomcat/conf/logging.properties. Należy odnaleźć wiersz: java u t i l logging ConsoleHandien level V'tJW RFOUESi lFECi-ClE 86nw £'Q °i> 1«*«- = INFO vauaattQns* ż*i.sei - uociat/» 118 Moae1 i zastąpić poziom I NFO poziomem F 1NEST. Na końcu tego pliku należy dodatkowo umieścić następujący wiersz: AOOSiCdtiG'’' 0 Tisec i;s vaujf javax e n t e r p r i s e resource webconiamer j s f =f lNFS t com ęułi facai. dDDf.icatfon ApDiscaiso^Associaceii1le328ae i-oi^.snri.f a c e s conł..iDlansr (W technologii JS F 1.1 należy dodać wiersz com.sun faces level =F 1NEST). 'W-eDaDROassi.oaaeFde'egate pw rnoQ'»mnei, /WEe-^rcfasseif n«x> se-rvi®* etassioati«* ,S!OX lV»E nfjque«! z o m sun ractiv.AppiicacionimD' AopiiCttOOP SCOPP 4. Należy ponownie uruchomić serwer Tomcat i uruchomić aplikację JSF. Zapisy ofq.dpacbe' c ate m a w e l c o m e , ¿LES org a p ac n e Ł ataB na.resources dziennika znajdują się w pliku tomcat/logs/catalina.out. com ^ faces, z n S " i , RfiQuES't. SERVICED iun,face;> O n e ’' im efmaaiizador c o m .suiirtacai. -«tml base C j-Svax faces, s i charter Wyłączenie rejestrowania zdarzeń w ramach kontenera JS F wymaga przywrócenia wartości 1NFO zmiennej corn.sun faces level (w pliku tomcat/eonf/Iogging.properties). Jeśli serwer Tom cat odnajdzie bibliotekę Apache Log4J w ścieżce do klas, wykoL J rzysta w łaśnie tę bibliotekę rejestrow ania zdarzeń, chyba że do zm iennej środo­ wiskowej CATALINAJ3PTS dodam y następującą definicję: -Dorg.apache.commons.1oggi ng.Log=org.apache.commons.1oggi ng.impl.Jdkl4Logger co«11.jyji fqces, 'ogicaiV'ewMap Aaremt CtesseCaneo - fa TSU? com suo facet, aspi-icdGo^ Appnc.ationimoir^*ie0Dp90 ?L]ava wn g Sm nq ^ l< łf 4 3 c s orcj aoacite naromq resourcea RroxyOjrCo-nrext® 139fM9 tfue Cpm tates» O^p^mesnięaifZaaor' com■suoi’aces renaeficrt 8eca«f Korzystanie z narzędzia FacesTrace jest bardzo prosie. Wystarczy umieścić jego plik JA R oraz plik JA R biblioteki Commons Logging w katalogu WEB-INF/lib naszej aplikacji inter­ netowej. Bibliotekę odpowiedniego znacznika należy zaimplementować, stosując konstrukcję: <%$ Lag1 1 D u n ="ru t p ./ /s o u rc e f o rg e n e t / p r o je c t s / f a c e s t r a c e " pref ix--" ft"%> W kolejnym kroku powinniśmy umieścić znacznik w postaci: Jak diagnozować stronę, na której zatrzymała się nasza aplikacja? na końcu kodu naszej strony JSF. W pewnych sytuacjach użytkownik ma wrażenie, że „utknął" na pewnej stronie JS F naszej aplikacji. Kiedy użytkownik klika przycisk akceptacji formularza, następuje ponowne w y­ świetlenie tej samej strony. Poniżej opisano procedurę diagnozowania takiej strony: 624 JavaS erver Faces Gdzie należy szukać kodu źródłowego biblioteki? Kod źródłowy biblioteki można pobrać ze strony internetowej http://javaserverfaces.dev. ^ j ava.net. Kod źródłowy biblioteki może się okazać bardzo pomocny w procesie rozwią­ zywania problemów i podczas rozstrzygania niejasnych kwestii w specyfikacji. Kod biblioteki podzielono pomiędzy trzy katalogi: ■ katalog jsf-api obejmujący udokumentowane klasy A PI, których pakiety rozpoczynają się od przedrostka javax. faces; ■ katalogyx/vv obejmujący klasy implementacji referencyjnej, których pakiety rozpoczynają się od przedrostka com. sun .faces; Skorowidz ■ katalogjsf-tools obejmujący narzędzia odpowiedzialne za automatyczne generowanie klas obsługujących znaczniki i wizualizujących komponenty. Uzyskanie kompletnego zbioru plików źródłowych wymaga użycia skryptu narzędzia Ant w katalogu jsf-tools : 1. Należy skopiować plik build.properties, template do pliku build.properties, po czym zmienić w pliku docelowym następujące zapisy: js f build.home=śc7'eż/c<3 do katalogu javaserverfaces_sources contai ner.name=glassfi sh con tainer.home=ścieżka do katalogu in s ta la c ji serwera GlassFish 2. Można teraz uruchomić polecenie ant mai n. 3. Brakujące pliki z kodem źródłowym zostaną umieszczone w katalogu jsf-ri/build/generate. I wreszcie możemy stanąć przed koniecznością uzyskania dostępu do takich szczegółów konfiguracyjnych wykorzystywanej implementacji JS F jak nazwy stron JS F lub klas kom­ ponentów standardowych, mechanizmów wizualizacji, konwerterów czy mechanizmów weryfikujących. Tego rodzaju informacji należy szukać w plikach jsf-ri/src/com/sun/faces/ v->jsf-ri-config.xml oraz jsf-ri/build/classes/com/sun/faces/standard-xml-renderkit.xml. 25, 49 #{form.beverage}, 144 $(), 481 ${...}, 49 @DataModel, 544 @DataModelSelection, 544 @EJB, 420 @EJBs, 420 @End, 546 @Entity, 541 @Id, 541 @Length, 541 @Name, 541 ©NotNull, 541 @PersistenceContext, 420 @PersistenceContexts, 420 @PersistenceUnit, 420 @PersistenceUnits, 420 @PostConstruct, 63, 605 @PreDestroy, 63, 605 @Resource, 420 @Resources, 420 @Scope, 541 @Table, 541 @WebServiceRef, 420, 467 @WebServiceRefs, 420 616 <%@ include %>, 301 <%@ page errorPage-'error.jsp" %>, 583 <%@ taglib ... %>, 616 , 301 A a4j:status, 498 a4j:support, 498, 500, 506 AbstractFacesBean, 519 setValueQ, 519 accept, 105, 107 acceptcharset, 105, 107 Accept-Language, 53 accesskey, 105 AccordionRenderer, 495 action, 25, 27, 44, 75, 77, 80, 122, 257, 362 action state, 517 ActionEvent, 75 actionListener, 75, 96, 122, 256, 257, 263, 264, 362 ActionLogger, 265 ActionSource, 329, 352, 353, 367 ActionSource2, 328, 329, 367 Active Directory, 430 ActiveXObject("Microsoft.XMLHTTP"), 477 addAction(), 367 addActionListener(), 367 addDataModelListener(), 201 addValidator(), 367 addValueChangeListenerQ, 367 ADF Faces, 550 adnotacje cykl życia, 63 wstrzykiwanie zasobów, 420 adres URL, 30, 62 afterPhase(), 274, 485, 606 AJAX, 274, 475 Ajax4jsf, 497 Direct Web Remoting, 488 Fade Anything Technique, 479 harmonijki, 491 komponenty, 490 kontrolki przeciągnij i upuść, 491 mechanizm nasłuchujący, 485 proces, 476 propagowanie stanu widoku po stronie klienta, 487 Prototype, 479 Rico, 491 serwlety, 476 626 Skorowidz JavaServerFaces AJAX uzupełnianie danych formularzy, 480, 498 weryfikacja danych w czasie rzeczywistym, 482, 502 XHR, 476 XMLHttpRequest, 477, 478 żądania, 476, 486 Ajax.Request, 481 Ajax.Updater(), 479 Ajax4jsf, 497 cykl życia, 501 implementacja mechanizmu uzupełniania danych formularzy, 498 implementacja mechanizmu weryfikacji w czasie rzeczywistym, 502 AjaxPhaseListener, 485 AjaxServlet, 478 akcje, 256 aktualizacja wartości modelu, 43 algorytm nawigacji, 92 aliasBean, 549 alt, 105 alternatywne metody wizualizacji, 39 Amazon Web Services, 464 anchor, 107 Ant, 34, 599 Apache Log4J, 622 Apache MyFaces, 548 Apache Shale, 607 Apache Tiles, 291, 305 instalacja pakietu, 305 kafelki, 305 kafelki zagnieżdżone, 313 kontroler kafelków, 313 parametryzacja kafelków, 308 rozszerzanie kafelków, 309 stosowanie pakietu, 306 aplety, 559 aplikacje internetowe, 15, 23 JavaServer Faces, 21 LDAP, 445 applet, 560 Application, 328, 330, 353, 368 addELResolver(), 611 applicationScope, 73 apply request values, 43 APPLY REQUEST VALUES, 276, 606 architektura model-widok-kontroler, 38 ArrayDataModel, 187, 193 ArrayList, 54, 55 ASP.NET, 15 ataki XSS, 118 atrybuty, 329 actionListener, 263 binding, 100, 102 border, 135 converter, 100, 103, 210 HTML 4.0, 104 id, 100, 101 immediate, 267 przekazywane, 104, 105 rendered, 101, 103 required, 100, 220 requiredMessage, 221 style, 103 styleClass, 101 tabindex, 283 usemap, 558 validator, 100, 103 validatorMessage, 221 value, 49, 100, 102, 144 valueChangeListener, 100, 263 zdarzenia języka DHTML, 104 attribute, 96, 97, 98, 242, 271, 342 Attribute, 437 Attributes, 437 auth-constraint, 455 autocomplete, 112 automatyzacja procesu kompilacji, 34 autoryzacja zarządzana przez kontener, 455 B backing beans, 47, 60 BaseDialogPage, 520, 521 BasicAttributes, 435, 437 baza danych, 183 JDBC, 409 konfiguracja zasobów w ramach serwera GlassFish, 415 konfiguracja zasobów w ramach serwera Tomcat, 417 SQL, 409 użycie, 420 bean, 20, 45 beforePhase(), 274, 606 beverage, 144 bezpośrednie komponenty poleceń, 268 bezpośrednie komponenty wejściowe, 266 bezstanowy protokół, 61 bgcolor, 160, 170 biblioteki, 292, 312 Commons, 551 Direct Web Remoting, 488 JSTL, 582 MyFaces, 548 znaczników, 25, 95 biblioteki języka JavaScript, 478 Fade Anything Technique, 479 Prototype, 479 BigDecimal, 209, 210 Biglnteger, 209, 210 Binary Data, 563 Binary Servlet, 562 binding, 60, 98, 100, 101, 102, 107, 119, 139, 210, 221 błędy, 39, 154 konwersja, 211 krytyczne, 154 Boolean, 210 BOOLEAN detail, 215 border, 105, 135, 160, 170 breakpoints, 614 buffer, 549 build.xml, 35, 599 byte, 595 c c:if, 582 c:import, 301 calendar, 549 caption, 172 captionClass, 160, 170 captionStyle, 160, 170 CATALINA_OPTS, 620, 622 cellpadding, 160, 170 cellspacing, 160, 170 ChangeLocaleBean, 271 chapterKeys, 294 charset, 105, 122 ciasteczka, 61 Clay, 529 close(), 412, 436 cn, 428 cols, 111, 112 column, 99, 166 columnClasses, 160, 170, 181 columns, 159, 160 com.corejsf, 20, 21 com.corejsf.Contact, 541, 543 com.corej sf. CreditCardConverterTag, 394 com.corejsf.DirContextFactory, 441 com.corejsf.messages, 50 com.corejsf.SpinnerTag, 340 com.corejsf.TableData, 168 com.corejsf.UploadFilter.repositoryPath, 554 com.corejsf.UserBean, 46, 115 com.corejsf.util, 232 com.corejsf.util.Messages, 232, 238 com.corejsf.util.Renderers, 359, 369 commandButton, 99, 103, 120, 121, 122, 123 627 commandlink, 97 commandLink, 99, 120, 122, 123, 124, 127,269, 283 Commons, 551 Commons Validator, 594 ComponentELTag, 343 ComponentldResolver, 608 Connection, 410, 413 Connection Pools, 415 Contact, 541, 543 container-managed authentication, 455 contentClass, 308 Context, 436, 458 Context.SECURITY_PRINCIPAL, 442 contextDestroyed(), 606 contextlnitialized(), 606 context-param, 30, 440 convert, 228 convertClientId(), 356, 357 convertDateTime, 96, 208, 210 converter, 96, 100, 101, 103, 119, 210, 227 Converter, 210, 229 converter-class, 227 ConverterELTag, 394, 395 ConverterException, 225, 229 converter-id, 227 converterMessage, 101,214 convertNumber, 96, 208 cookie, 73 cookies, 61 coords, 105 core, 25 corej sf:chart, 561 corejsf:creditCardValidator, 587 corej sf: spinner, 325, 326 CREATE TABLE, 423 createAccordion(), 492 createConverter(), 368, 369, 394, 395 createMethodBinding(), 353 createStatement(), 410 createSubcontext(), 435, 436 createValidator(), 407 createValueBinding(), 353 creditCard, 595 CreditCard, 225, 227, 228 CreditCardConverterTag, 394 creditCardValidator, 587 CreditCardValidator, 589 Cross-Site Scripting, 118 CSS, 103 CURRENCY_detail, 215 currencyCode, 209 currencySymbol, 209 CustomerBean.all(), 183 628 JavaServer Faces cykl życia aplikacji JSF, 42, 250 aktualizacja wartości modelu, 43 fazy, 42 przywracanie widoku, 43 stosowanie wartości żądania, 43 weryfikacja danych, 43 wizualizacja odpowiedzi, 43 wywołanie aplikacji, 44 D dane binarne, 561 osobowe, 445 użytkownik, 20 dane konfiguracyjne, 438 konfiguracja komponentu, 438 konfiguracja kontekstu zewnętrznego, 440 konfiguracja zasobu zarządzanego przez kontener, 441 data source, 409 dataList, 549 DataModel, 187, 201 getWrappedData(), 187 dataScroller, 549 DataSource, 409, 415 dataTable, 99, 102, 165, 296, 549 date, 595 Date, 207 DATE_detail, 215 dateStyle, 209 DateTime, 210 DateTimeConverter, 396 datownik, 325, 346 daty, 207 dc, 428 debuger, 31,614 decode(), 336, 356, 555, 571 DefaultContext, 417 default-locale, 53 deferred-method, 341, 350 deferred-value, 341, 350, 394 definiowanie komponent JSF, 329 para nazwa-wartość, 97 reguła nawigacji, 27 właściwość, 48 deklaracja DOCTYPE, 26 deklaracja pakietu komunikatów, 50 dekodowanie, 40, 334 żądania, 41 deleteNames(), 189 description, 89 destroySubcontextQ, 435, 436 Skorowidz DHTML, 104 diagnostyka, 611 debuger, 614 FacesTrace, 623 parametry przekazane za pośrednictwem strony, 617 pliki dziennika, 616 punkty wstrzymania, 614 ślad stosu, 611 ślad stosu z piekła rodem, 613 tryb rejestrowania zdarzeń związanych z pracą kontenera JSF, 620 diagram składni definicji, 66 dialog, 512 inicjowanie, 516 konfiguracja, 516 nawigacja, 517 poddialogi, 522 zależność od kontekstu, 520 dialog-config.xml, 516 DialogFauncher, 519 dialogFauncher.setupPaymentDialogO, 517 dir, 105, 107, 119, 170 DirContext, 436, 441 DirContextFactory, 441 Direct Web Remoting, 488 directory deployment, 615 disabled, 105 disabledClass, 132, 135 DiskFileUpload, 554 display-name, 89 div, 201 długość łańcucha, 219 dn, 428 DOCTYPE, 26 document.getElementByldO, 477, 481, 576 doFogin(), 422 dołączanie aplety, 559 konwertery, 210 rozmieszczenie, 305 dołączanie treści, 300, 302 aplikacje JSP, 300 kontekst aplikacji JSF, 301 DOM, 476 domena, 457 dostęp do bazy danych, 409 dostęp do informacji składowanych w katalogach FDAP, 433 dostęp do komunikatów o błędach zapisanych w pakiecie komunikatów, 230 dostęp do łańcucha komunikatów, 50 dostęp do zasobów zarządzanych przez kontener, 419 dostosowywanie komponenty, 46 wygląd stron o błędach, 583 DOUBFE, 215 DOUBFE_detail, 215 DoubleRangeValidator, 220, 222 DoubleRangeValidator.MAXIMUM, 222 DoubleRangeValidator.MINIMUM, 222 DoubleRangeValidator.NOT_IN_RANGE, 222 DoubleRangeValidator.TYPE, 222 drag-and-drop, 491 driverClassName, 418 drzewo katalogów, 429 DTD, 30 duże zbiory danych, 570 DWR, 488 Dynamie HTMF, 104 dynamie reloading, 615 dynamiczne ponowne ładowanie, 615 629 endElement(), 332, 334 ENUM,215 Enum.valueOf(), 68 ENUM_detail, 215 ENUM_NO_CFASS, 215 ENUM_NO_CLASS_detail, 215 error.jsp, 583 errorClass, 155 error-code, 583 errorMessage, 504 error-page, 583 errorPage, 584 errorStyle, 155 escape, 118, 119, 139 EvaluationException, 612 exception-type, 583 executeQuery(), 410 executeUpdateQ, 410 Extensions, 601, 607 ExtemalContext, 336, 441 E Eclipse, 31, 596 build.xml, 599 dodawanie bibliotek do projektu, 597 eksportowanie bibliotek, 598 New Java Project, 597 projekt, 597 tworzenie aplikacji JSF, 596 włączanie projektu, 598 EditableValueHolder, 328, 329, 336, 353, 367, 486 edycja komórki tabeli, 177 model tabel, 188 EJB, 535 EJB3, 535, 541 ekran logowania, 19, 20 ekran powitalny, 20 elementy, 138 formularze, 108 składowe aplikacji, 20 eliminowanie wycieków połączeń, 411 EFResolver, 608 email, 595 empty, 74 enabledClass, 132, 135 encode(), 573 encodeBegin(), 330, 331, 356, 555 encodeChildrenO, 330, 333, 356, 375, 376 encodeEnd(), 330, 356, 376, 377, 379 encodeTab(), 379 encoding, 40 enctype, 107 end state, 512 F factionListener, 264, 375 fattribute, 97, 242, 271 atrybuty, 98 fconvertDateTime, 208, 210 atrybuty, 209 fconverter, 227 fconvertNumber, 208 atrybuty, 209 f:facet, 97, 171 atrybuty, 98 floadBundle, 50 f:param, 97, 270 atrybuty, 98 fselectltem, 134, 136, 138, 139, 374 atrybuty, 139 fselectltems, 138, 140, 374 f: setPropertyActionListener, 272 fsubview, 301, 584 EvalidateDoubleRange, 220 EvalidateLength, 219, 220 EvalidateLongRange, 220 f:validator, 220, 240, 241 EvalueChangeListener, 264, 360 f:verbatim, 560 f:view, 25,301,584 fabryka, 544 Facelets, 524, 525 Clay, 529 jsfc, 526 kompozycje stron złożonych z szablonów, 531 stosowanie znaczników technologii JSF, 529 630 JavaServer Faces Facelets szablony, 532 treść, 532 układ, 532 zastępowanie znaczników komponentami JSF, 526 znaczniki niestandardowe, 533 faces-config, 28, 273 faces-config.xml, 20, 27, 28, 34, 46, 53, 64, 117, 240, 438, 599 facesContext, 73 FacesContext, 234, 328, 330, 333, 336, 352, 396, 441,486 renderResponse(), 251 responseComplete(), 251 FacesEvent, 252 FacesMessage, 225, 229, 232 FacesTrace, 623 facet, 96, 97, 98, 376 Fade Anything Technique, 479 fatalClass, 155 fatalStyle, 155 fazy, 274 fazy cyklu życia aplikacji, 42 fileUpload, 549 FileUploadRenderer, 555 filtr modelu danych, 192 filtr serwletów, 601 filtrowanie, 192 finally, 412 fmdComponent(), 102 fmdCreditCardValidators(), 589 first, 169, 170 flash scope, 607 float, 595 floatRange, 595 footerClass, 160, 170, 171, 172 for, 155 form, 99, 107 atrybuty, 107 Form.getStatePrompt(), 102 formaty numerów kart kredytowych, 227 form-eiTor-page, 456 form-login-config, 456 form-login-page, 456 formularz logowania, 42 formularze, 41, 106 AJAX, 480 anchor, 107 atrybuty, 106 elementy, 108 identyfikator, 107 kontrolki, 109 metoda GET, 107 metoda POST, 107 Skorowidz pola tekstowe, 111 przesyłanie, 107 skrypty JavaScript, 108 weryfikacja poprawności danych, 206 zapisywanie stanu klienta, 107 frame, 160, 170 frameworki JSF, 11 open-source, 511 from-action, 91, 93 from-outcome, 27, 78 from-view-id, 78, 90 ft:trace, 623 funkcje JavaScript, 605 G generowanie dane binarne, 561 zdarzenia akcji, 382 znaczniki, 330 get, 24, 48 GET, 107 get(), 437 getActionURL(), 568 getAllO, 434, 437 getApplication(), 352 getAsObject(), 225, 229 getAsString(), 225, 229 getAttributes(), 243, 333, 351, 433, 436 getAvailableIDs(), 570 getAWSECommerceServicePortQ, 467 getBean(), 519 getChapterKeys(), 296 getCityAndStateForZip(), 490 getClientldO, 332, 333 getComponent(), 252 getComponentType(), 344 getConnected(), 48 getConnection(), 409, 411 getContextClassLoader(), 230 getConvertedValue(), 356, 359, 360 getConverter(), 368 getConverterWithType(), 360 getCurrentInstance(), 352 getELContext(), 396 getElementById(), 477, 576 getErrorMessage(), 589 getExtemalContext(), 336, 441 getFacesMessage(), 230 getFacet(), 377 getID(), 437 getIncrementedValue(), 335 getlnitParameterQ, 440, 441 getISOCountries(), 203 getJSFState(), 487 getLanguageCode(), 271 getLocale(), 53, 234 getName(), 25 getNewValue(), 252, 368 getObjectlnstance(), 442, 443 get01dValue(), 252, 368 getPassword(), 24, 47 getPhaseId(), 252, 274 getRemoteUser(), 464 getRendererType(), 344, 355 getRendersChildren(), 333, 356, 357, 377 getRequestMap(), 605 getRequestParameterMap(), 271, 336 getResponseWriter(), 333 getRootContext(), 447 getRowCount(), 201 getRowData(), 201 getRowlndex(), 201 getScoreComponent(), 60 getStatePrompt(), 102 getString(), 230, 410 getType(), 368 getValidators(), 486 getValue(), 378, 396, 520 getValueExpression(), 368 getViewRoot(), 234 getWrappedData(), 187, 188, 201 GlassFish, 17, 22 konfiguracja zasobów baz danych, 415 globalOnly, 155 Google Maps, 475, 550 graphiclmage, 99, 118, 119 gridClass, 308 groupingUsed, 209 grupowanie wzajemnie powiązanych stron, 607 grupy elementów, 141 H h: column, 166 atrybuty, 170 h:commandButton, 25, 120, 121, 123 atrybuty, 122 h:commandLink, 97, 120, 123, 127, 269 atrybuty, 122 h:dataTable, 102, 165, 296 atrybuty, 169, 170 bgcolor, 170 border, 170 captionStyle, 170 cellpadding, 170 cellspacing, 170 columnClasses, 170 dir, 170 first, 169, 170 footerClass, 170 frame, 170 h:column, 166 headerClass, 170 rowClasses, 170 rows, 170 rules, 170 summary, 170 UIData, 166 value, 166 var, 170 h:form, 25 atrybuty, 107 h:graphiclmage, 118 atrybuty, 119 h:input, 323 h:inputHidden, 114, 246 atrybuty, 112 h:inputSecret, 25, 111, 113 atrybuty, 112 hiinputText, 25, 102, 111, 179 atrybuty, 112 h.'inputTextarea, 111, 114 atrybuty, 112 hmiessage, 154, 211, 213 atrybuty, 155 h:messages, 154, 219 atrybuty, 155 h:outputFormat, 52, 97, 118 atrybuty, 119 h:outputLink, 120, 124, 125 atrybuty, 124 h:outputText, 25, 118, 120, 179 atrybuty, 119 h:panelGrid, 159 atrybuty, 160 h:panelGroup, 161 atrybuty, 161 h:selectBooleanCheckbox, 131, 133, 146, 178 atrybuty, 132 hiselectMany Checkbox, 131, 133, 134 atrybuty, 132 h:selectManyListbox, 131, 135, 136, 141, 145 atrybuty, 132 h:selectManyMenu, 131, 135, 137, 146 atrybuty, 132 hiselectOneListbox, 131, 135 atrybuty, 132 h:selectOneMenu, 106, 131, 135, 137 atrybuty, 132 h:selectOneRadio, 131, 132, 134, 144 631 632 Skorowidz JavaServer Faces harmonijki, 491 Rico, 491 Harmonogram płatności, 513 HashMap, 141 hasMore(), 437 header, 73 headerClass, 160, 170, 171, 172, 308 header-menu-content, 309 headerValues, 73 Hibernate, 535 hierarchiczna baza danych, 428 hiperłącza, 378 hot deployment, 615 hreflang, 105 HTML, 23 HTML 4.01 Transitional, 27 HtmlBasicInputRenderer, 360 HTTP, 61,545 HttpServletRequest, 459, 464 HttpSession, 62 HttpSessionListener, 606 hybrydowy komponent harmonijki JSF-Rico, 493 I IBATIS, 535 ICEfaces, 550 icon, 89 id, 98, 100, 101, 107, 119, 139 IDE, 16 identyfikator formularza niezbędny do wygenerowania struktury document, forms [id], 604 identyfikatory, 101 image, 122, 294 image map, 558 immediate, 111, 112, 122, 267, 269 immediate component, 267 implementacja klasy niestandardowych konwerterów, 225 klasy niestandardowych mechanizmów weryfikacji, 237 mapa obrazów, 558 mechanizm uzupełniania danych formularzy, 498 mechanizm weryfikacji w czasie rzeczywistym, 502 niestandardowe konwertery, 393 niestandardowe mechanizmy weryfikacji, 393 obsługa wysyłania plików na serwer, 550 pula połączeń z bazą danych, 411 znaczniki komponentów niestandardowych, 339 include, 301 index.html, 20, 30 index.jsp, 19, 20, 30, 39 INFO, 616 infoClass, 155 informacje, 154 infoStyle, 155 inicjalizacja dialog, 516 lista, 65 mapa, 65 oryginalny stan środowiska, 605 InitialDirContext, 433, 436 init-param, 440 initParam, 73 initXHR(), 477 innerHTML, 488 input, 25 inputDate, 549 inputHidden, 99, 112, 246 inputHtml, 549 inputSecret, 99, 111, 112, 113 inputText, 99, 102, 111, 112, 179 inputTextarea, 99, 111, 112 instalacja oprogramowania, 16 integer, 595 INTEGER, 215 INTEGER detail, 215 integerOnly, 209 Integrated Development Environments, 16 interfejs użytkownika, 46, 547 internacjonalizacja, 50 intRange, 595 invalidate(), 62 invitedguest, 455, 459 invoke application, 44 INVOKE APPLICATION, 277 isConnected(), 48 isNextButtonEnabled(), 520 isRendered(), 377 isRowAvailable(), 201 isTransient(), 382 isUserInRole(), 459, 464 isValueReference(), 353 itemDescription, 139 itemDisabled, 139 itemLabel, 139 ItemSearch, 466 itemSearch(), 466 ItemSearchRequest, 466 ItemSearchResponse, 468 itemValue, 139 izolowanie kodu języka JavaScript od mechanizmów wizualizacji, 495 J jar, 22 JAR, 23, 600 Java, 561 Java bean, 23 Java BluePrints, 21, 550 Java Database Connectivity, 409 Java EE, 15,419 Java EE 5, 17 Java Naming and Directory Interface, 24, 419 Java Plug-in, 561 Java SDK, 13 Java SE Development Kit, 16 Java Studio Creator, 550 java.sql.ResultSet, 187 java.text.MessageFormat, 231 java.text.SimpleDateFormat, 208 java.util.Locale.getlSOCountriesQ, 203 java.util.logging, 617, 620 java.util.logging.ConsoleHandler.level, 622 java.util.Properties, 50 java.util.TimeZone.getAvailablelDs(), 570 JavaBean, 47 javac, 23 JavaScript, 108 JavaServer Faces, 11, 15 JavaServer Pages, 11, 15 JavaServer Pages Standard Template Library, 49 javax.el.ValueExpression, 368, 396 javax.enterprise.resource.webcontainer.jsf, 622 javax.enterprise.resource.webcontainer.jsf.lifecycle, 620 javax.faces.application.Application, 353, 368 javax.faces.application.FacesMessage, 229 javax.faces.component.ActionSource, 353, 367 javax.faces.component.ActionSource2, 367 javax.faces.component.EditableValueHolder, 336, 353,367 j avax.faces .component. StateHolder, 3 82 javax.faces.component.UIComponent, 243, 332, 336, 346, 353, 368, 377 javax.faces.component.LIIInput.Conversion, 216 javax.faces.component.UIViewRoot, 234 javax.faces.component.ValueHolder, 339, 368 javax.faces.CONFIG_FILES, 64 javax.faces.context.ExtemalContext, 336, 441 javax.faces.context.FacesContext, 234, 333, 336, 352,396, 441,486 j avax. faces.context. Response Writer, 333 javax.faces.convert.ConverterException, 229 javax.faces.DoubleRange, 240 javax.faces.event.EditableValueHolder, 486 j avax. faces.event. FacesE vent, 252 javax.faces.event.MethodExpressionActionListener, 368 javax. faces, event. MethodExpression Value ^ChangeListener, 367 javax.faces.event.ValueChangeEvent, 252, 368 javax.faces.Input, 355 javax.faces.Length, 240 633 javax.faces.LongRange, 240 javax.faces.model, 187 javax.faces.model.DataModel, 187 javax.faces.model.Selectltem, 139, 378 javax.faces.model.SelectltemGroup, 143 j avax. faces .render. Renderer, 356 javax.faces.validator.MethodExpressionValidator, 367 javax.faces.validator.Validator, 221, 237 javax.faces.ViewState, 487 javax.faces.webapp.ConverterELTag, 395 javax.faces.webapp.UIComponentELTag, 346 javax.faces.webapp.UIComponentTag, 353 javax.faces.webapp.ValidatorTag, 407 javax.naming.Context, 436 javax.naming.directory.Attribute, 437 javax.naming.directory.Attributes, 437 javax.naming.directory.BasicAttributes, 437 javax.naming.directory.DirContext, 436 javax.naming.directory.InitialDirContext, 436 javax.naming.NamingEnumeration, 437 javax.servlet.error.exception, 584 javax.servlet.error.exceptionjype, 584 j avax.servlet, error, message, 5 84 javax.servlet.error.request uri, 584 javax.servlet.error.servlet_name, 584 javax.servlet.error.status_code, 584 javax.servlet.HttpServletRequest, 464 javax.servlet.jsp.jstl.Result, 187 javax.sql.DataSource, 415 JAX-WS, 466 JDBC, 409 Connection, 410 eliminowanie wycieków połączeń, 411 gotowe wyrażenia, 413 obiekt połączenia, 409 PreparedStatement, 413,414 pula połączeń, 411 ResultSet, 410 stosowanie gotowych wyrażeń, 413 wycieki połączeń, 411 wykonywanie wyrażeń języka SQL, 409 zarządzanie połączeniami, 411 źródło danych, 409 jdbc/mydb, 419 JDK, 16 jednowierszowe pola tekstowe, 111 język JavaScript, 108 SQL, 409 XHTML, 525 XML, 26 JND1, 24,419, 441,607 JPEG, 561 jscookMenu, 549 634 Skorowidz JavaServer Faces jsessionid, 62 JSF, 11, 15,535,541 JSF 1.0, 11 JSF 1.1,349 JSF 1.2, 16, 17,28 JSF Expert Group, 11 JSF HTML, 98, 99 jsfc, 526 jsflibs, 597 JSP, 11, 15,49 JSP 2.1, 511 jsp: forward, 31 jsp:include, 301 jsp:plugin, 561 JSTL, 49, 291,582 jsValueChangeListener, 549 K kafelki, 305 zagnieżdżone, 313 karty kredytowe, 227 katalog LDAP, 428 katalogi, 21 META-INF, 21 web, 21 key-class, 66 klasy ActionSource, 353 Application, 353 ComponentELTag, 343 Connection, 410 Converter, 229 ConverterELTag, 395 ConverterException, 229 DataModel, 187, 201 EditableValueHolder, 336, 353, 367 ELResolver, 608 ExtemalContext, 336 FacesContext, 234, 333, 336, 352, 396 FacesEvent, 252 FacesMessage, 229, 232 FileUploadRenderer, 555 implementacja komponentów niestandardowych, 325 InitialDirContext, 436 MessageFormat, 231 NamingEnumeration, 434 PreparedStatement, 413, 414 Property Resolver, 610 ResponseWriter, 333 ResultSet, 410 Selectltem, 141 SelectltemGroup, 142, 143 ServletContext, 440 SimpleDateFormat, 208 SortFilterModel, 194 TableData, 168 UlCommand, 329 UlComponent, 243, 327, 332, 336, 346, 353 UIComponentBodyTag, 349 UIComponentELTag, 346 UIComponentTag, 349, 353 UIData, 192 UIInput, 60, 329 UlOutput, 60, 329 UITabbedPane, 380 UIViewRoot, 234 UserBean, 21, 24, 47 ValidatorELTag, 343 ValueChangeEvent, 252 ValueExpression, 396 VariableResolver, 610 klasy CSS, 135 klasy obiektów, 428 klucze mapy, 141 kod HTML, 23 kod źródłowy aplikacji, 21 kod źródłowy biblioteki, 624 kodowanie, 40, 330 hard-core’owe, 15 style CSS, 377 kolejka komunikatów, 154 komentarze, 615 XML, 615 komórki tabeli danych, 177 kompilacja aplikacji, 22 Ant, 34 automatyzacja procesu, 34 build.xml, 35 komponenty, 16, 23, 45, 547 ADF Faces, 550 AJAX, 550 aliasBean, 549 bezpośrednie, 265 biblioteka MyFaces, 548 buffer, 549 calendar, 549 ChangeLocaleBean, 271 dataList, 549 dataScroller, 549 dataTable, 549 dostęp do wartości, 47 dostęp do zasobów dostępnych w pliku JAR, 600 encyjne, 540 facet, 329 fileUpload, 549 ICEfaces, 550 identyfikatory, 101 inputDate, 549 inputHtml, 549 interfejs użytkownika, 16 Java, 23 Java BluePrints, 550 JavaBean, 47 jscookMenu, 549 J S F ,174 jsValueChangeListener, 549 klasa, 28 konfiguracja, 64, 438 newspaperTable, 549 panelNavigation, 549 panelNavigation2, 549 panelStack, 549, 582 popup, 549 potomne, 329 prezentowanie, 582 RegisterForm, 147 rssTicker, 549 saveState, 549, 606 schedule, 549 stron, 60 stylesheet, 549 tabbedPane, 549 tree, 549 tree2, 549 treeColumn, 549 UIData, 166 ukrywanie, 582 user, 27 UserBean, 47 ustawianie wartości właściwości, 65 validatorScript, 589 value, 49 wejściowe, 60 wiązanie definicji, 66 właściwości, 23, 47 wspomagające, 47, 60 wyjściowe, 60 zarządzające danymi użytkownika, 20 zasięg, 28, 61 zasięg aplikacji, 62 zasięg sesyjny, 61 zasięg żądania, 62 komponenty AJAX, 490 hybrydowe komponenty, 491 hybrydowy komponent harmonijki JSF-Rico, 493 izolowanie kodu języka JavaScript od mechanizmów wizualizacji, 495 przekazywanie atrybutów znaczników JSP do kodu języka JavaScript, 496 635 komponenty niestandardowe, 39, 323 ActionSource, 329 ActionSource2, 329 Application, 330 atrybuty, 329 decode(), 336 definiowanie, 329 dekodowanie, 334 EditableValueHolder, 329, 336 encodeBeginQ, 330 encodeChildren(), 330 encodeEnd(), 330 ExtemalContext, 336 FacesContext, 330, 333, 336 generowanie znaczników, 330 getExtemalContext(), 336 getRequestParameterMap(), 336 implementacja znaczników, 339 interfejsy, 329 klasy implementujące, 325 kodowanie, 330 komponenty facet, 329 komponenty JavaBeans, 327 komponenty potomne, 329 kontener nazewnictwa, 333 obiekty nasłuchujące, 329 przetwarzanie danych wejściowych, 327 przetwarzanie wartości żądania, 334 ResponseWriter, 333 setConverter(), 339 setSubmittedValue(), 336 stosowanie konwerterów, 337 UlCommand, 329 UlComponent, 327, 332, 336 Ullnput, 329 UlOutput, 329 ValueHolder, 329, 339 wizualizacja, 327 wyrażenia reprezentujące wartość, 329 zestaw narzędzi, 328 znaczniki, 327, 330 komponenty wspierające, 60 binding, 60 wiązanie komponentu interfejsu użytkownika, 60 komponenty zarządzane, 45 @PostConstmct, 63 @PreDestroy, 63 adnotacje cyklu życia, 63 dostosowywanie, 46 konfiguracja, 46, 64 konwersja łańcuchów, 68 składnia wyrażeń reprezentujących wartości, 69 ustawianie wartości właściwości, 65 wiązanie definicji komponentów, 66 zasięg, 61 636 JavaServer Faces komunikacja z serwerem, 369 komunikaty, 50, 154 błędy, 154 błędy krytyczne, 154 informacje, 154 ostrzeżenia, 154 wyświetlanie, 156 komunikaty o błędach, 211, 215, 611 błędy weryfikacji, 221, 222 dostęp do komunikatów zapisanych w pakiecie komunikatów, 230 modyfikacja treści, 214 niestandardowe komunikaty, 214 komunikaty obejmujące zmienne, 51 konfiguracja dialog, 516 komponent, 64, 438 kontekst zewnętrzny, 440 mechanizm logowania, 456 serwer LDAP, 430 serwlet, 29 ustawienia regionalne aplikacji, 52 zasoby baz danych w ramach serwera GlassFish, 415 zasoby baz danych w ramach serwera Tomcat, 417 zasoby zarządzane przez kontener, 441 źródło danych, 414 kontekst katalogu LDAP, 433 kontekst zewnętrzny, 440 kontener nazewnictwa, 333 kontenery serwletów, 61 kontroler kafelków, 313 kontrolki formularza, 109 kontrolki przeciągnij i upuść, 491 konwersacja z użytkownikiem, dialogu, 512 konwersja danych, 38, 205, 206 błędy, 211 converter, 210 daty, 207 f:convertDateTime, 208 f:convertNumber, 208 komunikaty, 211 komunikaty o błędach, 215 konwertery, 216 liczby, 207 niestandardowy konwerter, 211 przekazywanie konwerterom atrybutów, 242 raportowanie błędów, 229 treść komunikatów o błędach, 214 wyświetlanie komunikatów o błędach, 211 wyświetlanie wszystkich komunikatów o błędach, 213 konwersja łańcuchów, 68, 70 konwersja na obiekt, 210 Skorowidz konwertery, 102, 207, 337 atrybuty, 209 binding, 210 dołączanie, 210 stosowanie, 207 konwertery niestandardowe, 225, 234, 393 aplikacja, 397 ConverterELTag, 395 FacesContext, 396 przywracanie stanu, 396 ValueExpression, 396 zapisywanie stanu, 396 znaczniki, 393 kreator, 512 kreator płatności, 514 książka adresowa, 535 L label, 112 lang, 105, 107, 119 languageCode, 272 layout, 135, 155, 161 Layout, 132 LDAP, 428 Active Directory, 430 aplikacje, 445 atrybuty, 428 Attribute, 437 Attributes, 437 BasicAttributes, 437 baza danych, 428 Context, 436 DirContext, 436 dodawanie wpisów, 434 dostęp do informacji, 433 drzewo katalogów, 429 edycja atrybutów wpisu, 435 elementy drzewa, 428 InitialDirContext, 436 katalogi, 428 klasy obiektów, 428 konfiguracja serwera, 430 kontekst katalogu, 433 NamingEnumeration, 434, 437 OpenLDAP, 430 połączenie z serwerem, 433 przeglądanie drzewa katalogów, 432 serwer, 430 Sun Java System Directory Server, 430 Unikatowa nazwa, 429 usuwanie wpisów, 435 uwierzytelnianie, 431 użytkownicy, 430 ldapadd, 431 LdapCtxFactory, 443 Length Validator, 220, 222 LengthValidator.MAXIMUM, 222 LengthValidator.MINIMUM, 222 liczby, 207 life cycle, 42 lifecycle, 273 lineDirection, 135 LinkedHashMap, 141 List, 65 ListDataModel, 187 list-entries, 65, 66 listy, 65, 135, 146 wielokrotnego wyboru, 136 load(), 50 loadBundle, 96 locale, 53, 209 locale-config, 53 localhost, 62 logAbandoned, 418 logika biznesowa, 23 login(), 422 login.war, 22 loginAction, 421 login-config, 456 logout.jsp, 78 logoutAction, 421 logowanie, 456 lokalizacja, 373 lokalizacja pakietu komunikatów, 51 lokalizacja plików konfiguracyjnych, 599 LongRangeValidator, 220, 222 LongRangeValidator.MAXIMUM, 222 LongRangeValidator.MINIMUM, 222 LongRange Validator.NOT_IN_RANGE, 222 LongRangeValidator. TYPE, 222 lookup(), 436 l-value, 70 1-wartość, 70 l ładowanie klas, 50 łańcuchy, 206 łańcuchy komunikatów, 50 łącza, 120, 269 łącza poleceń, 126 M managed-bean, 46, 47, 64 managed-bean-class, 28, 46, 64, 438 managed-bean-name, 46, 64, 438 managed-bean-scope, 28, 46, 64 managed-property, 65, 438 Map, 65, 66 mapa atrybutów, 97 mapa facet, 97 mapa obrazów, 558 usemap, 558 map-entries, 66 mapowanie serwletów, 29 mapy, 65 mask, 595 maxActive, 418 maxFractionDigits, 209 maxldle, 418 maxIntegerDigits, 209 maxlength, 105, 595 mechanizmy logowanie, 456 nasłuchiwanie akcji, 265 podział na strony, 570 rendering, 40 Shale Validator, 593 śledzenie faz, 277 uwierzytelnianie, 457 weryfikacja danych, 102, 218, 223 menedżer encji EJB, 543 menu, 135, 146 menuClass, 308 menultems, 142 message, 99, 154, 211 MessageFormat, 52, 231 messages, 99, 154 Messages, 232 META-INF, 21 MethodBinding, 351 MethodExpression, 350, 362 MethodExpressionActionListener, 368 MethodExpressionValidator, 367 MethodExpressionValueChangeListener, 367 metoda GET, 107 metoda POST, 107 metody, 75 dostępowe, 24 get, 24 nasłuchujące akcji, 256 nasłuchujące zdarzeń, 263 set, 24 ustawiające, 48 zwracające, 48 Microsoft Active Directory, 430 minFractionDigits, 209 minlntegerDigits, 209 minlength, 595 model, 38 637 638 JavaServer Faces model DOM, 476 modele tabel, 187 edycja, 188 filtrowanie, 192 sortowanie, 192 model-widok-kontroler, 38 modifyAttributesQ, 435, 437 modyfikacja treści standardowych komunikatów o błędach, 214 monitor HTTP, 619 monolityczne strony JSF, 295 multipart/form-data, 550, 551 MVC, 38 MyFaces, 548, 582 H name, 98 NamingEnumeration, 434, 437 narzędzia projektowania wizualnego, 32 nasłuchiwanie akcji, 265 native2ascii, 51 navigation-case, 78, 89, 91 navigation-rule, 78, 87, 89, 92 nawiasy kwadratowe, 71 nawigacja, 27, 77, 257 algorytm, 92 from-action, 91 from-view-id, 90 navigation-case, 91 navigation-rule, 92 przekierowanie, 89 redirect, 89 reguły, 27 symbole wieloznaczne, 90 to-view-id, 89 zaawansowane techniki, 88 nawigacja dynamiczna, 79 action, 80 przycisk akceptacji formularza, 79 reguły, 87 rozgałęzienia, 80 wyrażenia odwołujące się do metody, 79 nawigacja statyczna, 77 action, 77 reguły, 78 nazwa komponentu, 27 NetBeans, 31,614 newspaperTable, 549 next(), 437 niestandardowe komponenty, 323 niestandardowe komunikaty o błędach, 214 niestandardowe konwertery, 224, 323 Skorowidz niestandardowe mechanizmy weryfikacji, 224,323,393 implementacja, 237 RegexValidatorTag, 403 ValidatorTag, 407 znaczniki, 401 niestandardowy znacznik weryfikacji po stronie klienta, 587 NOT IN RANGE, 221 NullPointerException, 612 null-value, 65 Number, 210 NUMBER_detail, 215 NumberConverter, 214 numery kart kredytowych, 227 o obieg stron internetowych, 511 obiekty, 45 biznesowe, 47 nasłuchujące, 106, 329 wyniki biblioteki JSTL, 187 XMLHttpRequest, 477, 478 ObjectFactory, 442, 443 obramowanie, 135 obrazy, 118 JPEG, 561 obsługa błędy, 39 błędy konwersji, 326 metody nasłuchujące zmian wartości, 360 narzędzia, 39 style CSS, 377 wyrażenia wskazujące na metody, 361 wysyłanie plików na serwer, 550 obsługa zdarzeń, 249, 281 actionListener, 263, 264 bezpośrednie komponenty poleceń, 268 bezpośrednie komponenty wejściowe, 266 FacesEvent, 252 komponenty bezpośrednie, 265 metody nasłuchujące akcji, 256 PhaseListener, 274 przekazywanie danych z interfejsu użytkownika na serwer, 269 ValueChangeEvent, 252 valueChangeListener, 263, 264 ValueChangeListener, 264 oddzielanie logiki interfejsu użytkownika od logiki biznesowej, 258 odwzorowywanie przedrostki, 29 serwlety, 29 ograniczanie komunikacji z serwerem, 369 onblur, 106 onchange, 106 onclick, 106, 107, 121,574 ondblclick, 106, 107 onfocus, 106, 107 onkeydown, 106, 107 onkeypress, 106, 107 onkeyup, 106, 107 onmousedown, 106, 107 onmousemove, 106, 107 onmouseout, 106, 107 onmouseover, 106, 107 onmouseup, 106, 107 onreset, 106, 107 onselect, 106 onsubmit, 106, 107 opener, 576 OpenLDAP, 430 operatory, 74 arytmetyczne, 74 empty, 74 logiczne, 74 relacyjne, 74 trój argumentowy operator selekcji, 74 optgroup, 143 org.apache.shale.faces.AbstractFacesBean, 519 org.apache.struts.tiles.Controller, 313 oryginalny stan środowiska, 605 ostrzeżenia, 154 ou, 428 outject, 545 outputFormat, 97, 99, 118, 119 outputLabel, 99 outputLink, 99, 120, 124, 125 outputText, 99, 118, 119, 120, 179 P page beans, 60 pageDirection, 135 PagerRenderer, 571 pakiet Apache Tiles, 305 pakiet Shale, 512 pakiety komunikatów, 50 deklaracja, 50 komunikaty obejmujące zmienne, 51 lokalizacja, 51 ustawienia regionalne, 52 pakowanie zbiom znaczników w ramach pliku JAR, 604 panele, 159 panelGrid, 159, 160 zakładki, 373, 387 panelGrid, 99, 159, 160 panelGroup, 99, 161 panelNavigation, 549 panelNavigation2, 549 panelStack, 549, 582 param, 96, 97, 98, 270 Param, 73 parametry puli połączeń, 418 parametryzacja kafelków, 308 param Values, 73 PartialResolution, 609 pasek przewijania, 201 password, 24, 418, 584 pattern, 209 PATTERN TYPE, 215 PERCENT_detail, 215 phase events, 273 Phaseld.ANY PHASE, 275, 276 Phaseld.APPLY REQUEST VALUES, 274 phaseListener, 96 PhaseListener, 274, 606 placehorders, 52 pliki build.xml, 35 deskryptor TLD, 340 dziennik, 616 faces-config.xml, 27, 28, 64, 438 index.html, 30 index .jsp, 30 JAR, 23, 600 jsf, 24 jsp, 24 konfiguracyjne, 20 properties, 50 server.xml, 438 WAR, 21 web.xml, 29 welcome .jsp, 26 poddialogi, 522 podstawowe znaczniki JSF, 96 podwidoki, 291, 302 podział na strony, 570 PO JO, 541 pola hasła, 111 pola tekstowe, 25, 111 stosowanie, 114 pola ukryte, 107, 114, 373, 378 pola wyboru, 133, 146 połączenia z bazą danych, 183 z serwerem LDAP, 433 pomijanie procesu weryfikacji danych, 221 pomoc podręczna, 550 poolPreparedStatements, 418 639 640 JavaServer Faces popup, 549 POST, 41, 107 PreparedStatement, 413, 414 prepareStatement(), 413, 414 prependld, 107 prezentacja, 23 duże zbiory danych, 570 prezentowanie komponentów, 582 PrintWriter.writeQ, 495 proces konfiguracji komponentu, 439 process validations, 43 process Aj axCall(), 477, 478 processRealtimeValidation(), 486 processZipCodeSelection(), 481 programowanie, 596 Eclipse, 596 sterowane zdarzeniami, 16 programowe tworzenie komponentów, 102 projektowanie interfejs użytkownika aplikacji internetowej, 547 wizualne, 32 propagowanie stanu widoku po stronie klienta, 487 PropertyEditor, 69 Property Resolver, 610 protokoły HTTP, 61 SOAP, 464 Prototype, 479 przeciągnij i upuść, 491 przeglądarka książek, 292, 294 przekazywanie atrybutów znaczników JSP do kodu języka JavaScript, 496 przekazywanie danych z interfejsu użytkownika na serwer, 269 przekazywanie konwerterom atrybutów, 242 przekierowanie, 89 przepisywanie adresów URL, 62 przepływ stron internetowych, 511,512 przetwarzanie facet, 376 iteracyjne, 410 wartości żądania, 334 wyrażenia wskazujące na metody, 362 znaczniki potomne typu Selectltem, 375 żądania AJAX, 476 przewijanie zawartości tabeli danych, 201 dodatkowe łącza, 202 pasek przewijania, 201 przycisk akceptacji formularza, 79 przyciski, 120 przyciski opcji, 133, 146 przyciski poleceń, 121 przyciski typu włączony-wyłączony, 121 Skorowidz przywracanie oryginalny stan środowiska, 605 stan, 379, 396 widok, 43 pula połączeń z bazą danych, 411 Tomcat, 418 punkty wstrzymania, 614 push button, 121 put(), 437 Q queue(), 252 Quiz liczbowy, 54 QuizBean, 54 R raportowanie błędów konwersji, 229 readonly, 105 Realm, 458 redirect, 89 redisplay, 111, 112, 113 RegexValidatorTag, 403 registereduser, 455, 459 RegisterForm, 147 reguły nawigacji, 25, 78, 87 definiowanie, 27 rejestrowanie mechanizm weryfikacji, 240 zdarzenia, 611 rei, 105 relacje pomiędzy komponentami, 595 relacje weryfikacji łączące wiele komponentów, 243 release(), 346, 396 remove Abandoned, 418 removeAbandonedTimeout, 418 removeDataModelListener(), 201 render response, 43 RENDER RESPONSE, 606 rendered, 101, 103, 104, 107, 119, 582 Renderers, 360 getConvertedValue(), 359, 360 getSelectItems(), 376 rendering, 40 renderResponse(), 251, 268 rendersChildren(), 375 request value, 206 requestScope, 73 required, 100, 101, 111, 112, 220, 595 requiredMessage, 101,221 resource injection, 419 resource-bundle, 51 responseComplete(), 251, 486, 568 ResponseWriter, 328, 330, 332, 333 restoreState(), 380, 381, 382, 396 Result, 187 ResultDataModel, 187 ResultSet, 187,410 ResultSetDataModel, 187, 201 rev, 105 Rico, 491 Rico.Accordion, 492 rico:accordion, 494, 497 ricoiaccordionPanel, 494 rodziny komponentów, 355 role-name, 455 rowClasses, 160, 170, 181, 182 rows, 105, 111, 112, 170 rozgałęzienia, 80 rozmieszczenia elementów na stronie, 291 rozszerzanie języka wyrażeń technologii JSF?, 607 rozszerzanie kafelków, 309 rssTicker, 549 Ruby on Rails, 607 rules, 160, 170 r-value, 70 r-wartość, 70 s s: validatorS cript, 594 saveState, 549, 606 saveState(), 380, 381,382, 396 ScalarDataModel, 187 schedule, 549 Seam, 535, 607 Contact, 541 fabryka, 544 grupowanie wzajemnie powiązanych stron, 607 integracja z modelem danych JSF, 544 komponenty encyjne, 540 konfiguracja aplikacji, 539 koniec konwersacji, 546 konwersje, 607 książka adresowa, 535 menedżer encji EJB, 543 stanowe komponenty sesyjne, 541 wstrzyknięcie, 542 zasięg konwersacji, 545 zasięg zdarzenia, 541 security-constraint, 455 select, 136 selectBooleanCheckbox, 99, 131, 132, 133, 178 selectedPanel, 582 selectedTabClass, 377 selectltem, 96, 134, 136, 138 641 Selectltem, 139, 140, 141, 142, 375, 378 SelectltemGroup, 142, 143 selectltems, 96, 138, 140 selectMany, 144 selectManyCheckbox, 99, 131, 132, 133, 134 selectManyListbox, 99, 131, 132, 135, 136, 141, 145 selectManyMenu, 99, 131, 132, 135, 137 selectOneListbox, 99, 131, 132, 135 selectOneMenu, 99, 106, 131, 132, 135, 137 selectOneRadio, 99, 131, 132, 134, 144 selekcja, 130 selektywne prezentowanie komponentów, 582 sendRequest(), 477 separatory, 25 Serializable, 396 serializacja, 396 server.log, 616 server.xml, 417, 438, 459 servlet, 601 ServletContext, 440 ServletContextListener, 606 servlet-mapping, 30 serwer GlassFish, 17, 22 LDAP, 428 OpenLDAP, 430 serwlety, 29 filtrujące, 551 konfiguracja, 29 mapowanie, 29 odwzorowywanie, 29 web.xml, 29 sesja, 61 sessionCreated(), 606 sessionDestroyed(), 606 sessionScope, 73 set, 24, 48 setAction(), 352, 353 setActionListener(), 353 setAsText(), 69 setBoolean(), 351 setConverter(), 337, 339, 359 setLocale(), 53 setName(), 25, 65 setPassword(), 47, 65 setPhase(), 275 setPhaseId(), 252 setProperties(), 344, 346, 350, 351, 362, 496 setPropertyActionListener, 96, 272 setPropertyResolved(), 608 setRendererType(), 344 setRowIndex(), 201 setScoreComponent(), 60 setSelectltemsQ, 144 642 JavaServer Faces setSeverity(), 229 setString(), 351 setSubmittedValueQ, 336 setTransient(), 382 setValid(), 336, 337 setValidator(), 353 setValidatorld(), 407 setValue(), 520 setValueBinding(), 351, 353 setValueChangeListener(), 353 setValueExpression(), 346 setWrappedData(), 188, 195,201 Shale, 512 BaseDialogPage, 520, 521 dialog, 512 dialog-config.xml, 516 inicjowanie dialogu, 516 konfiguracja dialogu, 516 kreator, 512 nawigacja w ramach dialogu, 517 poddialogi, 522 stan akcji, 517 stan końcowy, 512 stan widoku, 517 zależność od kontekstu dialogu, 520 zasięg dialogu, 518 Shale Validator, 593 shape, 105 ShoppingCartBean, 62 short, 595 showDateAndTime(), 477 showDetail, 155 showSummary, 155 Simple Object Access Protocol, 464 SimpleDateFormat, 208 size, 105, 136 składnia wyrażeń reprezentujących wartości, 69 składowanie komponentu zarządzanego poza zasięgiem żądania, 606 skrypty JavaScript, 108 ograniczanie komunikacji z serwerem, 369 slapd.conf, 430 sn, 428 SOAP, 464, 466 sortByFirst(), 194 sortByLast(), 194 SortFilterModel, 194 sortowanie, 192 spinnerLib, 601 SpinnerTag, 340 sprawdzanie długości łańcuchów, 219 SQL, 409 SQLException, 412 SSL, 457 Skorowidz stan, 379 stan akcji, 517 stan końcowy, 512 stan widoku, 484, 517 standardowe komunikaty o błędach weryfikacji, 222 standardowe mechanizmy weryfikacji, 218 stanowe komponenty sesyjne, 541 startElement(), 332, 333 StateHolder, 380, 382, 396 Statement, 410 stosowanie komponent panelu podzielonego na zakładki, 387 konwerter, 337 łącza poleceń, 126 pola tekstowe, 114 pola ukryte, 378 wartość żądania, 43 zewnętrzny mechanizm wizualizacji, 354 strona błędu uwierzytelniania, 421 strona index.jsp, 27 strona JSF, 24 strona powitalna, 30 struktura katalogów aplikacji, 21 Struts, 595 style, 103, 105, 107, 118, 119 style CSS, 103,377 styleClass, 101, 107, 118, 119, 155, 180, 283,377 stylesheet, 549 submitted value, 206 subview, 96, 301 summary, 160, 170 Sun Java Studio Creator, 33 Sun Java System Directory Server, 430 sun-web.xml, 442, 458 supported-locale, 53 symbole wieloznaczne, 90 symbole zastępcze, 52 System.err, 616 System.out, 616 SystemPropertyResolver.PartialResolution, 609 szukanie dodatkowych komponentów, 547 ś ścieżka interfejsu JNDI, 420 ślad stosu, 611,613 z piekła rodem, 613 śledzenie fazy, 277 sesja, 61, 62 środowiska wytwarzania, 31 Ant, 34 automatyzacja procesu kompilacji, 34 Eclipse, 31 narzędzia projektowania wizualnego, 32 NetBeans, 31 Sun Java Studio Creator, 33 T tabbedPane, 549 TabbedPaneRenderer, 376, 382 tabClass, 377 tabele bazy danych, 183 Result, 187 ResultSet, 187 zbiory wynikowe, 187 tabele danych, 165, 166 atrybuty, 170 CSS, 180 DataModel, 187 edycja komórek, 177 edycja modeli tabel, 188 filtrowanie, 192 h:dataTable, 165 kolumny, 181 komórki, 177 komponenty JSF, 174 modele, 187 nagłówki, 171 podpisy, 171 przewijanie, 201 SortFilterModel, 194 sortowanie, 192 stopki, 171 style, 180 style kolumn, 181 style wierszy, 182 TableData, 168 wiersze, 182 tabele HTML, 165 tabindex, 105, 283 Table, 166 TableData, 168 deleteNamesQ, 189 taglib, 95, 340 Tapestry, 529, 535 target, 105, 107 techniki przewijania, 201 techniki wytwarzania aplikacji internetowych, 15 technologie EJB, 535 Facelets, 525 JSF, 15, 16 tekst, 118 tekstowe pola wejściowe, 111 telefon komórkowy, 25 tile controllers, 313 643 tiles, 305 tiles: import Attribute, 308 tiles:insert, 306 TIME_detail, 215 timeStyle, 209 timeZone, 209 title, 105, 107, 1 19, 283 TLD, 340 Tomcat, 417 konfiguracja zasobów baz danych, 417 parametry puli połączeń, 418 tooltip, 155 toStringO, 55 to-view-id, 78, 89 tradycyjny obiekt Javy, 541 tree, 549 tree2, 549 treeColumn, 549 TreeMap, 141 trój argumentowy operator selekcji, 74 tryb rejestrowania zdarzeń związanych z pracą kontenera JSF, 620 try-fmally, 410, 412 tworzenie aplikacje JSF w środowisku Eclipse, 596 aplikacje LDAP, 445 niestandardowy znacznik weryfikacji po stronie klienta, 587 wyskakujące okna, 574 zdarzenia akcji, 382 type, 105, 122, 209 u ui:composition, 533 ui:defme, 533 ui:include, 533 UlCommand, 328, 329, 355 UlComponent, 243, 327, 328, 332, 336, 346, 353, 368 getAttributes(), 351 UIComponentBodyTag, 349 UIComponentELTag, 326, 328, 344, 346 UIComponentTag, 349, 353 uid, 428 UIData, 166, 192,355 UIForm, 355 UIGraphic, 355 Ullnput, 40, 42, 60, 222, 328, 329, 355, 360 getConvertedValue(), 360 REQUIRED, 222 UIMessage, 355 UIMessages, 355 644 Skorowidz JavaServer Faces UlOutput, 60, 329, 355 UlPanel, 355 UISelectBoolean, 355 UlSeleetltem, 375 UISelectMany, 355 UlSelectOne, 355 UlSpinner, 328,331,337,355 encodeBegin(), 332 UITabbedPane, 328, 376, 380, 381 UIViewRoot, 53, 234, 608 układy, 292 ukryte pola wejściowe, 246 ukrywanie komponentów, 582 umiędzynarodowienie, 39, 51, 56 unikatowa nazwa, 429 update model values, 43 UploadFilter.java, 552 uploadlmage.jsp, 557 UploadRenderer.java, 555 UploadTag.java, 556 url, 418 URL, 30, 62 usemap, 558 user, 27 user.name, 40 UserBean, 21, 24, 32, 46, 47, 421, 422 UserBeanjava, 20, 21 UserDirectoryBean, 451 username, 418 usługi frameworka JSF, 37 usługi sieciowe, 464 @WebServiceRef, 467 Amazon Web Services, 464 artefakty klienta, 467 deskryptor, 465 komponenty, 464 neutralność językowa, 465 opis usługi, 464 SOAP, 464, 466 WSDL, 464, 465 usługi zewnętrzne, 409 ustawianie wartości właściwości, 65 ustawienia regionalne, 51, 52 definiowanie, 53 utrzymywanie sesji, 61 uwierzytelnianie, 457 uwierzytelnianie zarządzane przez kontener, 455 domena, 457 SSL, 457 użytkownicy, 456 uzupełnianie danych formularzy, 480 Ajax4jsf, 498 v validate!), 239, 242 validateCreditCard!), 593 validateDoubleRange, 96, 220 validateLength, 96, 219, 220 validateLongRange, 96, 220 validator, 75, 96, 100, 101, 103, 220, 240, 362 Validator, 221,237,239, 242 validator-class, 240 ValidatorELTag, 343 ValidatorException, 238, 239, 401 validator-id, 240 validatorld, 240 validatorMessage, 101,221 validatorScript, 587, 589, 591 ValidatorTag, 403, 407 value, 25,49, 65,98, 100, 101, 102, 111, 119, 122, 124, 139, 166 wiązanie atrybutu, 144 ValueBinding, 350 ValueChangeEvent, 252, 368 valueChangeListener, 75, 96, 100, 101, 111, 112, 249, 251, 263, 264, 360, 361, 362 ValueChangeListener, 264 value-class, 65, 66 ValueExpression, 344, 350, 368, 396 ValueHolder, 329, 339, 368 valueOf(), 68 var, 170 VariableResolver, 73, 610 verbatim, 96, 560 Verify Project, 614 view, 73, 96, 301 view state, 517 ViewState, 487 w waluta, 52 WAR, 21,614 wamClass, 155 wamStyle, 155 warstwa prezentacji, 23 wartości, 49, 102 lokalne, 206 właściwości, 65 wymagane, 220 wyrażenia przetwarzane w czasie wykonywania, 341 wysłane, 206 żądanie, 206 wdrażanie aplikacje JavaServer Faces, 29 katalogi, 615 „na gorąco”, 614 web, 21 web flow, 511 Web Service Description Language, 464 web services, 464 web.xml, 20, 29, 30, 599 WEB-INF, 340 Weblets, 601 web-resource-collection, 455 Web work, 535 welcome.jsp, 20, 26 welcome-file, 31 weryfikacja danych, 39, 43, 205, 587 Commons Validator, 594 creditCardValidator, 587 długość łańcucha, 219 fvalidateDoubleRange, 220 EvalidateLength, 220 fvalidateLongRange, 220 fvalidator, 220 klasy niestandardowych mechanizmów, 237 komponenty JavaBeans, 242 komunikaty o błędach, 221 komunikaty o błędach weryfikacji, 222 mechanizm, 223 niestandardowe mechanizmy, 224 niestandardowy znacznik weryfikacji po stronie klienta, 587 obiekt konwertera, 242 po stronie klienta, 587 pomijanie procesu weryfikacji, 221 przedziały liczbowe, 219 rejestrowanie mechanizmów, 240 relacje weryfikacji łączące wiele komponentów, 243 requiredMessage, 221 Shale Validator, 593 standardowe mechanizmy, 218, 220 Struts, 595 ukryte pola wejściowe, 246 validate!), 242 Validator, 221,237 ValidatorException, 238 validatorMessage, 221 wartości wymagane, 220 wyświetlanie komunikatów o błędach, 221 weryfikacja danych w czasie rzeczywistym, 482 Ajax4jsf, 502 weryfikacja relacji pomiędzy komponentami, 595 wiązanie atrybut value, 144 definicja komponentów, 66 widok, 38, 524 JSF, 302 XHTML, 525 width, 105 wielowierszowe pola tekstowe, 111 window.document.getElementByld!), 481 window.open(), 574 window.openerFormld, 577 wizualizacja, 354 odpowiedzi, 43, 63 strony, 40 warunkowa, 103 właściwości, 23 komponenty, 47 wzorzec nazewniczy, 48 writeAttribute(), 332, 334 writeValidationFunctions(), 589, 592 WSDL, 464, 465 wskazywanie konwerterów, 227 wstrzykiwanie zależności, 467 wstrzykiwanie zasobów, 419 @WebServiceRef, 467 adnotacje, 420 wybór opcji, 130 wycieki połączeń, 411 wygląd stron o błędach, 583 wyjątki serwletów, 584 wykonywanie wyrażeń języka SQL, 409 wykresy, 561 wykrywanie błędów, 613 wyrażenia odwołujące się do metod, 75, 79 obsługa, 361 wyrażenia reprezentujące wartości, 49, 329 listy, 71 1-wartość, 70 mapy, 71 nawiasy kwadratowe, 71 obiekty predefiniowane, 73 odwołania do map i list, 71 operatory, 74 rozwiązywanie wyrazu początkowego, 72 r-wartość, 70 składnia, 69 wyrażenia odwołujące się do metod, 75 złożone wyrażenia, 74 wyskakujące okna, 574 wysyłanie plików na serwer, 550 DiskFileUpload, 554 FileUploadRenderer, 555 serwlet filtrujący, 551 645 646 Skorowidz JavaServer Faces wysyłanie plików na serwer UploadFilter.java, 552 uploadlmage.jsp, 557 UploadRenderer.java, 555 UploadTag.java, 556 wysyłanie plików ze wskaźnikiem postępu, 550 wysyłanie żądania AJAX, 481 wyświetlanie komunikaty, 156 komunikaty o błędach, 211 komunikaty o błędach weryfikacji, 221 mapa obrazów, 558 obraz, 118 tekst, 118 wytwarzanie błyskawiczne, 15 wywołanie aplikacji, 44 wywołanie konwerterów z poziomu zewnętrznych mechanizmów wizualizacji, 359 wzorzec nazewniczy właściwości, 48 wzór Luhna, 239 X XHR, 476, 478 XHTML, 525 XML, 26 XMLBuddy, 28, 599 XMLHttpRequest, 477 XSS, 118 z zaawansowane techniki nawigacji, 88 zależność od kontekstu dialogu, 520 zapisywanie stanu, 379, 396 zapytania SQL, 409 zarządzanie dane konfiguracyjne, 438 połączenia bazodanowe, 411 zasięg aplikacji, 73, 438 zasięg błyskowy, 607 zasięg dialogu, 518 zasięg komponentów, 61 adnotacje cyklu życia, 63 zasięg aplikacji, 62 zasięg sesji, 61 zasięg żądania, 62 zasięg konwersacji, 545 zasięg sesji, 73 zasięg zdarzenia, 541 zasięg żądania, 73 zbiory wynikowe, 187 zdarzenia, 104, 249 akcje, 249, 256 cykl życia, 250 DHTML, 104, 106 fazy, 249, 273 komponenty poleceń, 249 komponenty wejściowe, 249 metody nasłuchujące akcji, 256 po stronie serwera, 268 zmiana wartości, 249, 251 zewnętrzne mechanizmy wizualizacji, 354 obsługa metod nasłuchujących zmian wartości, 360 obsługa wyrażeń wskazujących na metody, 361 wywoływanie konwerterów, 359 zewnętrzne źródła danych, 47 zgodne zasięgi komponentów, 68 ziarno, 46 zintegrowane środowisko programowania, 16, 31 ZipCodeDirectory, 490 zmiana lokalizacja plików konfiguracyjnych, 599 wartości, 251 zmienne, 25 znaczniki, 19 applet, 560 atrybuty, 100 atrybuty wspólne, 100 c:import, 301 f:actionListener, 264 f: attribute, 242, 271 f:convertDateTime, 208 f:convertNumber, 208 fiparam, 270 f:selectltem, 138 fselectltems, 138, 140 fsetPropertyActionListener, 272 fisubview, 301 f:valueChangeListener, 264 f:view, 25, 301 h:column, 166 h:commandB utton, 120, 121 h:commandLink, 120 h:dataTable, 165 h:form, 25 h:graphiclmage, 118, 119 hunputHidden, 114 hunputSecret, 111, 113 h:inputText, 111, 179 h:inputTextarea, 114 h:message, 154, 211 h:messages, 154 h:outputFormat, 118 h:outputLink, 120, 124 h:outputText, 118, 179 h:panelGrid, 159, 160 h:panelGroup, 161 h:selectBooleanCheckbox, 131, 133, 178 h:selectManyCheckbox, 131, 133 h:selectManyListbox, 131, 135, 141 h:selectManyMenu, 131, 135, 137 h:selectOneListbox, 131, 135 h:selectOneMenu, 131, 135, 137 h:selectOneRadio, 131, 144 HTML, 25 JSF, 96 JSF HTML, 98, 99 jspiinclude, 301 JSTL, 582 komponenty niestandardowe, 339 konwertery niestandardowe, 393 managed-bean-class, 28 managed-bean-scope, 28 metody nasłuchujące zdarzeń, 263 niestandardowe mechanizmy weryfikacji, 401 podstawowe, 25 przedrostki, 25 selekcja, 130 tiles: importAttribute, 308 tilesunsert, 306 znaczniki niestandardowe, 339 ActionSource, 353 Application, 353 atrybuty dowiązań do metod, 351 ciało, 349 ComponentELTag, 343 definiowanie klas obsługujących znaczniki w technologii JSF 1.1, 349 Editable ValueHolder, 353 Facelets, 533 FacesContext, 352 implementacja, 339 JSF 1.1,349 klasa obsługująca znacznik, 343 MethodBinding, 351 plik deskryptora TLD, 340 taglib, 340 UlComponent, 346, 353 UIComponentBodyTag, 349 UIComponentELTag, 346 UIComponentTag, 349, 353 ValidatorELTag, 343 znaczniki standardowe JSF, 95 biblioteka znaczników, 95 taglib, 95 związki, 101 ź źródło danych, 409 dostęp do zasobów zarządzanych przez kontener, 419 GlassFish, 415 JNDI, 419 konfiguracja, 414 Tomcat, 417 2 żądania, 334 AJAX, 476, 486 GET, 107 POST, 41 647 Cay S Horstmann Gary Cornell Java Podstawy Wydanie IX Read more Marciniak A. - JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW Read more ABC Linux. Wydanie II Read more core-stability Read more Sheri S. Tepper - Artefakty. Tom 3. Trawa. Wydanie II Read more Laudyn D. - Elektrownie Wydanie 4 Read more Begg D. - Makroekonomia. Wydanie 4 Read more Android w akcji Wydanie II Read more Core Rules 1st Edition Read more Harmon A. - Making Faces Read more Java Podstawy wyd VIII C S Horstmann G Cornell Read more S po d fl agi ma g ii Read more Mendrala D. - SQL. Praktyczny kurs Wydanie III Read more Beazley D. - Python. Receptury. Wydanie III Read more 100 sposobow na sieci bezprzewodowe Wydanie II Read more Jonathan-Gennick-sql-leksykon-kieszonkowy-wydanie-II Read more Reese G. - MySQL. Leksykon kieszonkowy. Wydanie II Read more S GRAFIK@ II 2015 Read more S GRAFIK @ II 2015 Read more Skeet J. - C# od podszewki. Wydanie II Read more Agarwal M. - Metasploit. Receptury pentestera. Wydanie II Read more K Krysiak Sieci komputerowe Kompendium Wydanie II Read more Lam W. - Rysunek i malarstwo Wydanie II Read more Stutz M. - Linux. Najlepsze przepisy. Wydanie II Read more abc-sam-naprawiam-komputer-wydanie-II Read more Jonathan Gennick sql leksykon kieszonkowy wydanie II Read more Tzu S. - Sztuka wojny. Wydanie III Read more Oflag II D Gross-Born Read more Coruscant And The Core Worlds Read more S D Stuart Herobrine powstaje Read more Recommend Documents Cay S Horstmann Gary Cornell Java Podstawy Wydanie IX Marciniak A. - JavaServer Faces i Eclipse Galileo. Tworzenie aplikacji WWW ABC Linux. Wydanie II core-stability Sheri S. Tepper - Artefakty. Tom 3. Trawa. Wydanie II Laudyn D. - Elektrownie Wydanie 4 Begg D. - Makroekonomia. Wydanie 4 Android w akcji Wydanie II Core Rules 1st Edition Harmon A. - Making Faces × Sign In Email Password Remember me Forgot password? Sign In Login with Facebook Login with Google