7 Przedmowa XML, XML, XML... Ten skrót pojawia się na czapeczkach i koszulkach. W kaŜdym czasopiśmie technicznym, w radiu, w czasopismach kobiecych...

28 downloads 88 Views 4MB Size

7

Przedmowa XML, XML, XML... Ten skrót pojawia się na czapeczkach i koszulkach. W kaŜdym czasopiśmie technicznym, w radiu, w czasopismach kobiecych... no, moŜe sprawy nie zaszły jeszcze tak daleko, ale niewiele brakuje. XML, rozszerzalny język znaczników (ang. Extensible Markup Language), wydaje się pojawiać w kaŜdej branŜy technicznej, a szczególnie często słychać o nim w środowisku programistów języka Java®. Aplikacji nie uwaŜa się juŜ za produkt przemysłowy, jeśli nie uŜyto w niej w jakiś sposób języka XML. Wreszcie powstała moŜliwość nowych zastosowań dla starych, firmowych systemów, a przedsiębiorstwa oszczędzają miliony i miliardy dolarów na integracji systemów — wszystko dzięki tym trzem literkom. Programiści Javy będą zmuszeni do przyswajania sobie jeszcze jednej technologii, a zadanie wydaje się być tym trudniejsze, im bardziej się w nie zagłębić. Drogę do XML-a wytyczają kolejne skróty: XSL, XPath, RDF, XML Schema, DTD, PI, XSLT, XSP, JAX®, SAX, DOM i inne. I nie ma juŜ chyba dyrektora, który nie wymagałby od swojego personelu informatycznego znajomości XML-a! Kiedy na początku 1998 roku XML zyskał status specyfikacji formalnie określonej przez World Wide Web Consortium, niewiele osób zgodziłoby się uznać, Ŝe powstała właśnie najwspanialsza technologia od czasów Javy (a moŜe jeszcze wspanialsza!). Ale juŜ dwa lata później XML i grupa technologii słuŜących do manipulacji tym językiem zaczęły stanowić podstawowy sposób reprezentacji danych w Javie. XML ma szansę wnieść do formatu danych to, co Java wniosła do języków programowania — całkowitą przenośność. I właściwie to zamierzenie twórców Javy osiągnąć moŜna tylko dzięki językowi XML; przenośność Javy bardzo ucierpiała ze względu na uŜywane od lat, firmowe formaty danych — aplikacja mogła zostać uruchomiona na wielu platformach, ale nie w wielu firmach, na standardowym formacie danych. XML moŜe rozwiązać ten problem — powoduje, Ŝe te firmowe formaty danych zaczynają być zbędne i umoŜliwia wzajemne komunikowanie się systemów za pomocą standardowej reprezentacji danych. To ksiąŜka o języku XML, ale napisana głównie z myślą o programistach Javy. Zarówno XML, jak i Java są potęŜnymi narzędziami. W tej ksiąŜce jednak uwaga skupiona zostanie na tym, jak ze sobą współpracują — to właśnie dzięki tej współpracy XML staje się naprawdę potęŜną technologią. Przedstawione zostaną róŜne słowniki XML. Czytelnik nauczy się tworzyć, zawęŜać i przekształcać XML, pozna takŜe wszystkie interfejsy programistyczne (API) do obsługi języka XML z poziomu kodu Javy. W ksiąŜce zostaną takŜe podjęte najciekawsze zagadnienia dotyczące języka XML: dynamiczna zawartość, usługi powiadamiania, e-biznes i składnice danych. Za kaŜdym razem będzie stosowany ten sam, wąski punkt widzenia programisty, któremu zaleŜy na wykonaniu konkretnego zadania z uŜyciem opisywanych narzędzi. Zostaną przedstawione narzędzia, jakie

Organizacja ksiąŜki

8

udostępnia XML; a jeśli istnieje coś, co — choć popularne! — nie jest zbyt uŜyteczne, zostanie tylko pobieŜnie omówione. JeŜeli natomiast któraś wyjątkowo przydatna funkcja XML-a sprawia wraŜenie „ukrytego rodzynka” — zostanie on wydobyty i opisany pod kątem uŜyteczności. Java i XML ma słuŜyć pomocą Czytelnikowi. Nie jest pozycją referencyjną ani nie ma na celu reklamowania standardu XML. Połowa tej ksiąŜki to kod — praktyczny i działający. MoŜna go takŜe pobrać z Internetu, ale umieszczono go w ksiąŜce po to, aby Czytelnik mógł prześledzić proces tworzenia róŜnych aplikacji XML. Czytelnik powinien więc raczej zagłębiać się w te przykłady, a nie je pomijać. Jest tutaj przedstawiony takŜe nowy interfejs API do manipulacji XML-em z poziomu Javy — został on opisany w pełni, z przykładami. To ksiąŜka dla programisty Javy, dlatego zastosowano podejście praktyczne. To nie jest ani teoretyczny, ani pobieŜny przegląd „fajnej” technologii. Tam, gdzie to moŜliwe, unikamy słów-haseł; tam, gdzie nie — podajemy ich precyzyjne definicje. Cały kod oraz rozwiązania z tej ksiąŜki zostały ręcznie wpisane do edytora i przetestowane. Są tutaj po to, by pomóc Czytelnikowi w solidnym opanowaniu Javy i XML-a.

Organizacja ksiąŜki KsiąŜka została podzielona w szczególny sposób. W pierwszej połowie (rozdziały 1. do 7.) został przedstawiony standard XML oraz najwaŜniejsze interfejsy API Javy do jego obsługi. MoŜe nie są to rozdziały niezwykle interesujące, jednak powinny być czytane w proponowanej kolejności, a przynajmniej dokładnie przejrzane — nawet jeśli XML nie jest Czytelnikowi obcy. Rozdział 8. to jakby fragment przejściowy pomiędzy dwiema częściami ksiąŜki. Opisano w nim niezwykle ciekawy nowy interfejs API do obsługi XML-a z poziomu Javy — JDOM. Ten rozdział trzeba przeczytać koniecznie, poniewaŜ publikacja tego interfejsu zbiegnie się z wprowadzeniem niniejszej ksiąŜki do sprzedaŜy, a tutaj przedstawiono pełne materiały referencyjne odnośnie tego API (interfejs ten, który autor utworzył wraz z Jasonem Hunterem, ukierunkowany jest właśnie na rozwiązywanie problemów z wykorzystaniem Javy i XML-a!). W pozostałej części ksiąŜki (rozdziały 9. do 14.) omawiane są specyficzne tematy związane z XML-em, nieustannie poruszane na konferencjach i w samouczkach programistów. Analiza tych tematów pozwoli Czytelnikowi maksymalnie wykorzystać XML we własnych aplikacjach — i to od zaraz! KsiąŜkę zamykają dwa dodatki. PoniŜej przedstawiony jest skrótowy opis poszczególnych rozdziałów: Rozdział 1. Wprowadzenie Omówienie alfabetu XML-a i próba znalezienia odpowiedzi na pytanie, dlaczego standard ten jest tak istotny dla obecnych i przyszłych aplikacji stosowanych w przedsiębiorstwach. Rozdział 2. Tworzenie dokumentów XML Omówienie procesu budowania dokumentu XML od podstaw; zastosowanie najwaŜniejszych konstrukcji XML, takich jak elementy, atrybuty, encje. Rozdział 3. Przetwarzanie kodu XML Przedstawienie interfejsu API Javy słuŜącego do obsługi XML-a — Simple API for XML (SAX). Szczegółowo opisano proces przetwarzania oraz zdarzenia udostępniane przez interfejs SAX, przeznaczone do wykorzystania przez programistów. Rozdział 4. ZawęŜanie danych XML Przedstawienie dwu sposobów zawęŜenia dokumentu XML: zastosownie definicji typu dokumentu (DTD) oraz XML Schema.

Organizacja ksiąŜki

9

Rozdział 5. Sprawdzanie poprawności składni XML-a Uzupełnienie poprzedniego rozdziału. Omówiono, jak za pomocą poznanego interfejsu SAX umoŜliwić weryfikację składni dokumentu oraz reagować, gdy dokument wykracza poza narzucone zawęŜenia. Rozdział 6. Przekształcanie kodu XML Opis rozszerzalnego języka arkuszy stylów XSL oraz innych istotnych komponentów słuŜących do przekształcania dokumentów XML z jednego formatu na inny. Omówiono róŜne metody konwersji dokumentów XML na inne formaty tekstowe oraz sposób wykorzystania obiektów formatujących do konwersji na formaty binarne. Rozdział 7. Czerpanie z XML-a Kontynuacja tematu przekształcania dokumentów XML. Przedstawiono procesory transformacji XML oraz sposoby konwersji dokumentów XML na inne formaty. Opisano równieŜ model obiektowy dokumentu (DOM) i wyjaśniono, w jaki sposób moŜna za jego pomocą obsłuŜyć dane XML. Rozdział 8. JDOM Omówienie interfejsu Java API for XML Parsing (JAXP) i próba przeanalizowania, jak duŜe znaczenie w XML-u ma niezaleŜność od rozwiązań firmowych. Zaprezentowano teŜ interfejs JDOM, wskazano przyczyny jego powstania, szczegółowo opisano sposób korzystania z niego oraz porównano go z interfejsami SAX oraz DOM. Rozdział 9. Struktury publikacji WWW Analiza struktur publikacji WWW i wybór najodpowiedniejszej. Omówiono takŜe strukturę Apache Cocoon oraz wyjaśniono, w jaki sposób korzystać z niej przy budowaniu dynamicznej zawartości stron WWW. Rozdział 10. XML-RPC Przedstawienie zdalnych wywołań procedur (RPC), uwzględnienie ich znaczenia w systemach rozproszonych w porównaniu z RMI oraz wyjaśnienie, dlaczego technologie RPC w przypadku niektórych problemów tak wiele zyskują dzięki XML-owi. Omówienie biblioteki XML-RPC Javy oraz konstrukcji klientów XML-RPC. Rozdział 11. XML na potrzeby konfiguracji Omówienie sposobów tworzenia danych konfiguracyjnych w postaci XML i wyjaśnienie, dlaczego format ten jest tak istotny w aplikacjach wieloplatformowych, szczególnie w systemach rozproszonych. Rozdział 12. Tworzenie danych XML w języku Java Przedstawienie procesu generowania i modyfikowania formatu XML z poziomu Javy przy wykorzystaniu mechanizmów działających po stronie serwera, takich jak serwlety. Wskazano teŜ, na co trzeba zwrócić uwagę przy dokonywaniu mutacji XML. Rozdział 13. Operacje typu firma-firma Omówienie sposobu komunikacji pomiędzy firmami i wewnątrz firmy z wykorzystaniem przenośnego formatu danych XML. PosłuŜą do tego przykładowe aplikacje, napisane w róŜnych językach i porozumiewające się ze sobą za pomocą XML-a. Rozdział 14. XML Schema Omówienie przyczyn niezwykłego zainteresowania specyfikacją XML Schema oraz wyjaśnienie, dlaczego technologie Java i XML Schema nawzajem się uzupełniają.

Dla kogo jest ta ksiąŜka?

10

Dodatek A. Interfejs API — materiał referencyjny W tym dodatku wymieniono wszystkie klasy, interfejsy i metody dostępne w interfejsach programistycznych SAX, DOM, JAXP i JDOM. Dodatek B. Funkcje i właściwości SAX 2.0 W tym dodatku wymieniono wszystkie funkcje i właściwości implementacji interfejsu SAX 2.0.

Dla kogo jest ta ksiąŜka? Podstawą napisania ksiąŜki było przekonanie, Ŝe XML jest juŜ nieodłącznym elementem programowania w Javie. KsiąŜka została napisana w taki sposób, Ŝe najpierw Czytelnik dowiaduje się, jak w ogóle korzystać z XML-a i Javy. Nie ma tutaj rozwaŜań dotyczących tego, czy powinno się korzystać z XML-a. Programista Javy powinien korzystać z XML-a. Dlatego, jeśli Czytelnik programuje w Javie, chce programować w Javie, zarządza programującymi w Javie lub jest odpowiedzialny albo związany z projektem pisanym w Javie — ksiąŜka na pewno mu się przyda. Jeśli Czytelnik chce się rozwijać, pogłębiać wiedzę programistyczną, pisać bardziej przejrzysty kod, tworzyć udane projekty w terminie i bez przekraczania budŜetu, musi korzystać z danych w formatach firmowych, tworzyć rozproszone systemy lub po prostu ciekaw jest, skąd całe to zainteresowanie XML-em — ksiąŜka na pewno mu się przyda. Pisząc ksiąŜkę, starałem się czynić jak najmniej załoŜeń. Nie chcę rozpoczynać omawiania XML-a od takiego poziomu, Ŝe zniechęci to część Czytelników. Ale uwaŜam takŜe, Ŝe jeśli Czytelnik wydał juŜ pieniądze na tę ksiąŜkę, to zaleŜy mu na czymś więcej niŜ tylko na podstawach. Dlatego zakładam jedynie znajomość Javy i zagadnień programowania po stronie serwera (takich jak serwlety Javy czy komponenty Enterprise JavaBean®. Jeśli Czytelnik nie miał jeszcze nigdy do czynienia z Javą albo dopiero rozpoczyna przygodę z tym językiem, być moŜe warto najpierw przeczytać Learning Java Pata Niemeyera i Jonathana Knudsena (wyd. O'Reilly & Associates). Zakładam, Ŝe Czytelnik nie wie nic o XML-u, więc zaczynam od samych podstaw. Ale zakładam równieŜ, Ŝe Czytelnik będzie cięŜko pracował i szybko przyswajał wiedzę. Dlatego podstawy zostaną omówione błyskawicznie, by jak najszybciej przejść do bardziej zaawansowanych zagadnień. Materiał nie będzie wielokrotnie powtarzany poza tymi miejscami, gdzie jest to absolutnie koniecznie. MoŜe więc zajść potrzeba ponownego przeczytania wcześniejszych fragmentów. Jeśli Czytelnik chce uczyć się XML-a, trochę zna Javę i przygotowany jest na „wstukanie” przykładowego kodu do swojego ulubionego edytora tekstów, nie powinien mieć większych problemów z przyswojeniem materiału opisanego w ksiąŜce.

Oprogramowanie i wersje Informacje w tej ksiąŜce dotyczą XML-a w wersji 1.0 oraz róŜnych słowników XML w wersjach najbardziej aktualnych w czasie ukończenia ksiąŜki, tj. w kwietniu 2000 r. PoniewaŜ rozmaite specyfikacje XML nie uzyskały jeszcze ostatecznej postaci, pomiędzy drukowaną wersją ksiąŜki a opisywanymi specyfikacjami mogą wystąpić drobne róŜnice. Cały kod Javy prezentowany w tej ksiąŜce oparty jest na platformie Java 1.1, za wyjątkiem opisów dotyczących interfejsu JDOM 1.0. Ta odmienność jest odnotowana i uzasadniona w odpowiednim miejscu, w rozdziale 8. Wykorzystano parser Apache Xerces, procesor Apache Xalan oraz biblioteki Apache FOP w najnowszych stabilnych wersjach z kwietnia 2000 r. Zastosowano strukturę publikacji WWW Apache Cocoon w wersji 1.7.3, a biblioteki Javy XML-RPC w wersji 1.0 beta 3. Całe oprogramowanie moŜna pobrać za darmo z adresów http://java.sun.com, http://xml.apache.org oraz http://www.xml-rpc.com.

Konwencje typograficzne

11

Kod źródłowy przykładów, w tym klasy narzędziowe com.oreilly.xml, jest w całości zamieszczony w ksiąŜce. Zarówno kod źródłowy, jak i postać binarną wszystkich przykładów (w tym szeroką dokumentację Javadoc) moŜna pobrać z adresów http://www.oreilly.com/catalog/javaxml oraz http://www.newInstance.com. Wszystkie przykłady mogące funkcjonować jako serwlety lub nadające się do przekonwertowania na serwlety moŜna obejrzeć w działaniu online pod adresem http://www.newInstance.com. Pełną dystrybucję JDOM 1.0, wraz ze specyfikacją, implementacją referencyjną, kodem źródłowym, dokumentacją interfejsu oraz postacią binarną moŜna pobrać z adresu http://www.jdom.org. Ponadto stworzono drzewo CVS zawierające kod JDOM i pozwalające na uzupełnianie i komentowanie źródeł. Informacje o tym, jak korzystać z CVS-a JDOM, moŜna znaleźć takŜe pod adresem http://www.jdom.org.

Konwencje typograficzne W ksiąŜce zastosowane zostały następujące konwencje typograficzne: Druk pochyły wykorzystywany jest do oznaczania: • uniksowych ścieŜek dostępu, nazw plików i nazw programów, • adresów internetowych (nazw domen i identyfikatorów URL), • nowych, definiowanych terminów. Czcionka proporcjonalna oznacza: • tekst wpisywany w wierszu poleceń i opcje — czyli to, co ma być wpisane dokładnie tak, jak wydrukowano, • nazwy i słowa kluczowe w programach Javy, w tym nazwy metod, zmiennych i klas, • nazwy elementów i znaczników XML-a, nazwy atrybutów i innych konstrukcji XML-a wyglądających tak, jak wyglądałyby w dokumencie XML . Czcionka proporcjonalna pogrubiona słuŜy do oznaczania: • nowo wprowadzonych fragmentów kodu, • fragmentów większego kodu, które właśnie są opisywane w tekście.

Opinie i komentarze Opinie i komentarze dotyczące tej ksiąŜki moŜna przysyłać do wydawcy: O'Reilly & Associates, Inc. 101 Morris Street Sebastopol, CA 95472 (800) 998-9938 (Stany Zjednoczone lub Kanada) (707) 829-0515 (międzynarodowe lub lokalne) (707) 829-0104 (faks) MoŜna takŜe wysłać list elektroniczny. W celu zapisania się na listę adresową lub zamówienia katalogu, wystarczy wysłać e-mail pod adres [email protected].

Podziękowania

12

Podziękowania Kiedy tak spoglądam na plik arkuszy składających się na manuskrypt tej ksiąŜki, to widzę, Ŝe w tych kilku akapitach nie udałoby się podziękować wszystkim, którzy przyczynili się do jej powstania. A jednak jest to na pewno prostsze niŜ omówienie całej tematyki Javy i XML-a, więc za chwilę spróbuję... Gdybym kogoś pominął, bardzo proszę — wybaczcie! Historia tej ksiąŜki rozpoczęła się w Święto Dziękczynienia w roku 1999. Wtedy to mój redaktor, Mike Loukides, zaproponował mi napisanie tej ksiąŜki, mimo Ŝe w tym czasie zajęty byłem pisaniem innej ksiąŜki dla O'Reilly. Nieco wahałem się przed odłoŜeniem na jakieś sześć miesięcy tekstu, którego tworzenie bardzo mnie pochłonęło. Mike jednak przekonywał mnie tak wprawnie, jak potem redagował gotowy tekst do czytelniejszej postaci. Teraz ten czas wspominam jako najciekawszy okres w mojej karierze technicznej i wiem, jak wiele zawdzięczam właśnie Mike'owi: słuŜył mi wskazówkami przy pisaniu trudnych, pierwszych rozdziałów; wysłuchał narzekań, gdy trzykrotnie (tak, trzykrotnie!) zmieniałem rozdział o XML Schema z powodu aktualizacji specyfikacji; wreszcie, kiedy trzeba było trochę odpocząć, okazywał swoje wszechstronne zdolności muzyczne. Bez niego ta ksiąŜka nie osiągnęłaby tak wysokiego poziomu. KsiąŜce mogłem poświęcić tak wiele wysiłku i czasu tylko dzięki rodzinie i przyjaciołom: rodzicom, którzy dzień w dzień przez osiemnaście lat zabiegali o poprawność mojego języka; cioci, która pasjonowała się tym, co robię, nawet jeśli nie wiedziała, o co w tym chodzi; Jody Durret, Carlowi Henry'emu i Pam Merryman, którzy poświęcili bardzo duŜo czasu na zrobienie ze mnie autora ksiąŜek; Gary'emu i Shirley Greathouse'om, którzy zawsze przypominali, abym wytrwale parł naprzód i nie osiadał na laurach; oraz moim dziadkom, Deanowi i Gladys McLaughlinom, którzy cały czas mnie wspierali. Nad merytoryczną poprawnością i precyzją ksiąŜki czuwali liczni recenzenci techniczni: Marc Loy, Don Weiss, George Reese (którego komentarze spowodowały dodanie całego rozdziału!), Matthew Merlo i James Duncan Davidson. Szczególną pomoc okazał James — pieczołowicie punktował drobne błędy i był brutalnie szczery, dzięki czemu nigdy nie zapomniałem, Ŝe jestem przede wszystkim programistą, a dopiero potem autorem ksiąŜek. Bardzo duŜo zawdzięczam Jasonowi Hunterowi, autorowi Java Servlet Programming (O'Reilly & Associates). Choć pisanie tej ksiąŜki rozpoczęło się w listopadzie 1999 roku, to przeŜyła ona swoiste odrodzenie w marcu 2000, kiedy to Jason i ja całe popołudnie spędziliśmy na trawniku w Santa Clara, narzekając na istniejące interfejsy API Javy do obsługi XML-a. Te utyskiwania zaprocentowały w dwójnasób — przede wszystkim, stworzyliśmy opisywany w tej ksiąŜce interfejs JDOM (przy pomocy i zachętach ze strony Jamesa Davidsona z Sun Microsystems). UwaŜamy, Ŝe interfejs ten znacząco przyczyni się do zacieśnienia współpracy pomiędzy XML-em i Javą i spowoduje, Ŝe XML z punktu widzenia Javy będzie standardem przejrzystym i uŜytecznym, a nie zagmatwanym i nieprzydatnym. Po drugie, bardzo zaprzyjaźniliśmy się z Jasonem. Pomógł mi w niełatwym procesie tworzenia ksiąŜki. Niejednokrotnie siedzieliśmy do późnych godzin nocnych, zastanawiając się, co moŜna zrobić by JDOM i inne programy działały bardziej intuicyjnie. Na pewno ta ksiąŜka nie powstałaby, gdyby nie moja Ŝona, Leigh. Jakimś cudem wytrzymała i nie wyrzuciła mnie z domu przez te ostatnie 6 miesięcy, w ciągu których najczęściej byłem zmęczony, nieprzystępny i w ogóle zajęty. Te krótkie chwile, jakie udawało nam się zdobyć dla siebie po moim pisaniu i pełnoetatowej pracy konsultanta, sprawiały, Ŝe cała moja praca wydawała mi się więcej warta. Tęsknię juŜ za nią bardzo i nie mogę się doczekać, kiedy wrócę do zwyczajnego try-

Podziękowania

13

bu Ŝycia właśnie z nią, z naszymi trzema bassetami (Charlie, Molly i Daisy) i moimi labradorami (Sethem i Mosesem). Dziękuję teŜ mojemu dziadkowi, Robertowi Earlowi Burdenowi, który nie doczekał wydania tej ksiąŜki. Był takim człowiekiem, jakim ja zawsze chciałem być. Dziękuję mu za to, Ŝe nauczył mnie, iŜ nigdy nie powinienem poprzestawać tylko na tym, czego oczekują ode mnie inni.

Podziękowania

14

Co to jest XML?

15

1 Wprowadzenie XML. W ciągu ostatnich dwóch lat chyba kaŜdy programista w którymś momencie poczuł ciarki na plecach związane z tym skrótem. Ciarki na plecach, choć z róŜnych powodów: konieczność wyuczenia się kolejnego skrótu, ekscytacja nową technologią, zagubienie. I, co ciekawe, kaŜda z tych reakcji na XML jest uzasadniona. Tak, trzeba zapamiętać nowy skrót, a takŜe skróty jemu towarzyszące: XSL, XSLT, PI, DTD, XHTML i inne. Tak, XML oferuje nowe moŜliwości: to, co Java wniosła w przenośność kodu, XML ma wnieść w przenośność danych. W ostatnich miesiącach Sun promuje nawet to rozwiązanie następującym sloganem: „Java + XML = przenośny kod + przenośne dane”. I wreszcie — tak, XML powoduje pewne zagubienie. Spróbujemy przybliŜyć i rozgryźć XML — będziemy omawiać go tylko na tyle ogólnie i abstrakcyjnie, Ŝeby nie popaść w bezuŜyteczność, i tylko na tyle szczegółowo, Ŝeby nie tworzyć kolejnej suchej specyfikacji. To ksiąŜka dla programisty Javy, który chce poznać i nauczyć się korzystać z narzędzi operujących na tej technologii. Przed programistą współczesnej aplikacji WWW stoi wiele problemów, których dziesięć lat temu nie było nawet w prognozach. Pojawiła się konieczność uruchamiania szybkich i bezawaryjnych systemów rozproszonych na przestrzeni tysięcy kilometrów, konieczność pobierania danych z systemów heterogenicznych, baz danych, usług katalogowych i aplikacji bez utraty choćby jednej cyfry po przecinku. Aplikacje muszą porozumiewać się nie tylko z innymi komponentami danej firmy, ale takŜe z innymi systemami biznesowymi — często znajdującymi się w innych firmach i zbudowanymi w oparciu o inne technologie. Klienty to juŜ nie tylko klienty uproszczone (ang. thin client), ale całe przeglądarki WWW obsługujące HTML, telefony komórkowe z obsługą protokołu aplikacji bezprzewodowych (WAP) czy asystenty osobiste („organizery”) obsługujące zupełnie inne języki znaczników. Oreganizacja danych i ich przetwarzanie — oto podstawowe zadania współczesnych aplikacji. XML pozwala programiście sprostać wszystkim tym wyzwaniom. Programiści Javy mają zaś jeszcze do dyspozycji arsenał interfejsów umoŜliwiających korzystanie z XML-a i jego towarzyszy bez konieczności opuszczania zintegrowanego środowiska programistycznego Javy (Integrated Development Environment — IDE). Jeśli to wszystko wydaje się zbyt piękne, by było prawdziwe — warto czytać dalej. Poznamy zalety i wady interfejsów API Javy słuŜących do przeprowadzania operacji na XML-u, a takŜe korzyści płynące z zastosowania najnowszych specyfikacji XML-a. Cały czas będziemy przyjmować punkt widzenia programisty. Ta ksiąŜka nie mówi o tym, dlaczego powinno się korzystać z XML-a, ale jak to robić. Jeśli w specyfikacji znajdą się elementy niezbyt przydatne, to powiemy, dlaczego tak jest, i przejdziemy dalej; jeśli jakieś zagadnienie jest

Co to jest XML?

16

szczególnie godne uwagi, poświęcimy mu więcej czasu. Będziemy traktować XML jako narzędzie, a nie jako slogan reklamowy czy kolejną „zabawkę”. Pamiętając o tym, spróbujmy odpowiedzieć na pytanie, czym jest XML.

Co to jest XML? XML to Extensible Markup Language, czyli rozszerzalny język znaczników. Podobnie jak jego przodek, SGML, XML jest metajęzykiem słuŜącym do definiowania innych języków. Jest jednak o wiele prostszy i bardziej praktyczny niŜ SGML. XML to język znaczników, w którym nie sprecyzowano ani zestawu znaczników, ani gramatyki języka. Zestaw znaczników (ang. tag set) w języku znaczników określa, jakie znaczniki mają znaczenie dla parsera języka. Na przykład, w HTML-u moŜna uŜywać znaczników ze ściśle określonego zestawu. MoŜemy wstawić znacznik , ale nie moŜemy uŜyć (angielskie słowo table oznacza nie tylko tabelę, ale takŜe stół). Pierwszy ze znaczników ma dla aplikacji wykorzystującej dane HTML specyficzne znaczenie, a drugi nie — większość przeglądarek po prostu go zignoruje, ale niektóre mogą zachować się nieprzewidywalnie. Wszystko to dlatego, Ŝe kiedy definiowano standard HTML, określono w nim konkretny zestaw znaczników. W kaŜdej kolejnej wersji HTML-a dodawane są nowe znaczniki. Jeśli jednak znacznik nie jest zdefiniowany, to przetwarzanie dokumentu zawierającego taki znacznik moŜe spowodować błąd. Gramatyka języka definiuje poprawne uŜycie jego znaczników. I znów weźmy HTML jako przykład. Do znacznika

moŜna dodać szereg atrybutów, określających szerokość tabeli, kolor tła, wyrównanie itd. Nie moŜemy jednak wstawić np. atrybutu TYPE, bo nie pozwala na to właśnie gramatyka języka. XML nie definiuje ani znaczników, ani gramatyki. Ma więc nieograniczone moŜliwości rozbudowy, jest rozszerzalny — i stąd jego nazwa. Jeśli postanowimy korzystać ze znacznika

, a potem jeszcze w danych objętych tym znacznikiem zagnieździć kilka znaczników , to bez trudności moŜemy to zrobić. Jeśli chcielibyśmy zdefiniować atrybut określający typ krzesła, np. TYPE, teŜ mamy taką moŜliwość. MoŜemy nawet wstawiać znaczniki o nazwach takich jak imiona naszych dzieci! MoŜliwości te zostały przedstawione w przykładzie 1.1.

Przykład 1.1. Przykładowy plik XML

Drewnosklep S.A.

2 doskonała niebieski 3 średnia

Co to jest XML?

17

Jeśli Czytelnik nigdy nie widział pliku XML, a miał do czynienia tylko z HTML-em lub innymi językami znaczników, to przykład moŜe się wydawać dość osobliwy. To dlatego, Ŝe znaczniki i gramatyka opisująca dane zostały w całości zmyślone. śadna strona WWW ani specyfikacja nie definiuje znaczników , czy poduszka (ale mogłoby tak być — w podobny sposób specyfikacja XHTML definiuje znaczniki HTML wewnątrz XML-a). Tu właśnie drzemie siła XML-a — umoŜliwia on definiowanie zawartości danych na róŜne sposoby i wymaga jedynie zgodności z ogólną strukturą języka. W dalszej części ksiąŜki są przedstawione róŜnego rodzaju ograniczenia, ale na razie wystarczy pamiętać, Ŝe XML został stworzony po to, by zapewnić elastyczność formatowania danych. Ta elastyczność jest jedną z największych zalet XML-a, a jednocześnie jedną z jego największych wad. Dokumenty XML moŜna przetwarzać na tak wiele róŜnych sposobów i w tak wielu róŜnych celach, Ŝe powstała bardzo duŜa liczba związanych z XML-em standardów opisujących tłumaczenie formatów danych i same formaty. Te dodatkowe skróty i ich nieustanne pojawianie się „w okolicach” XML-a często powoduje błędne rozumienie idei tego standardu. Kiedy ktoś mówi „XML”, to jest niemal pewne, Ŝe nie ma na myśli samego języka XML, tylko jedno z towarzyszących mu narzędzi. Niejednokrotnie zajmować się będziemy właśnie tymi narzędziami; trzeba jednak pamiętać, Ŝe najczęściej „XML” nie oznacza samego języka, lecz „XML i towarzyszące mu wspaniałe metody manipulowania danymi”. Skoro to rozróŜnienie mamy juŜ za sobą, moŜemy przejść do rozszyfrowania najbardziej popularnych skrótów związanych z XML-em. Skróty te są niezwykle istotne dla całej ksiąŜki, a więc warto zostawić w tym miejscu zakładkę, aby móc w kaŜdej chwili zajrzeć na te strony. PoniŜsze opisy powinny przybliŜyć Czytelnikowi wzajemne związki między narzędziami związanymi z XML-em oraz wyjaśnić, czym jest XML. Nie będziemy tutaj omawiać mechanizmów publikacyjnych, aplikacji i narzędzi dla XML-a, bo są one przedstawione w dalszej części ksiąŜki. PoniŜej Czytelnik znajdzie informacje jedynie o specyfikacjach i zaleceniach. Większość z nich powstała z inicjatywy W3C (World Wide Web Consortium). Organizacja ta zajmuje się definiowaniem standardów XML i spełnia rolę podstawowej bazy informacji o tym standardzie — podobnie jak firma Sun jest podstawowym źródłem informacji o Javie i związanych z nią interfejsach API. Więcej informacji o W3C moŜna znaleźć pod adresem http://www.w3.org.

XML XML to oczywiście punkt wyjścia wszystkich tych trzy- i czteroliterowych skrótów. Definiuje sam język i określa strukturę metadanych. XML sam w sobie ma niewielką wartość — to tylko struktura. Ale rozmaite technologie bazujące na tej strukturze dają programistom i administratorom zawartości niespotykaną do tej pory elastyczność w zarządzaniu i przesyłaniu danych. XML ma juŜ status ukończonego zalecenia W3C, co oznacza, Ŝe nic się nie zmieni aŜ do opublikowania nowej wersji standardu. Pełna specyfikacja XML 1.0 znajduje się pod adresem http://www.w3.org/ TR/REC-xml/. Specyfikacja ta jest trudną lekturą nawet dla programistów dobrze znających XML, więc polecałbym raczej zapoznanie się z jej doskonałą wersją opatrzoną komentarzami, dostępną pod adresem http://www.xml.com. Temat ten będzie w dalszych rozdziałach omawiany szczegółowo, więc teraz wystarczy pamiętać o dwóch podstawowych koncepcjach koniecznych do zrozumienia istoty dokumentu XML. Pierwsza mówi, Ŝe dokument XML, aby był w jakikolwiek sposób przydatny i mógł zostać przetworzony, musi być poprawnie uformowany. Poprawnie uformowany dokument to taki, w którym kaŜdemu znacznikowi otwierającemu odpowiada znacznik zamykający, w którym znaczniki nie są zagnieŜdŜone niezgodnie z regułami oraz którego składnia jest zgodna ze specyfikacją. Ale zaraz — czyŜ nie powiedzieliśmy wcześniej, Ŝe XML nie posiada Ŝadnych reguł składniowych? Niezupełnie.

Co to jest XML?

18

Powiedzieliśmy, Ŝe nie ma reguł gramatycznych. Dany dokument moŜe definiować własne znaczniki i atrybuty, ale wciąŜ musi być zgodny z regułami ogólnymi. Reguły te wykorzystywane są następnie przez aplikacje i parsery znające XML w celu odczytania danych z dokumentu i wykonania na nich pewnych czynności — np. znalezienia ceny krzesła czy utworzenia z danych dokumentu PDF. Zagadnienie to jest dokładniej omówione w rozdziale 2., Pisanie w XML-u. Druga istotna koncepcja związana z dokumentami XML mówi, Ŝe mogą one — ale nie muszą — być poprawne. Poprawny dokument to taki, który spełnia wymagania odpowiadającej mu definicji typu dokumentu DTD (o niej za chwilę). Mówiąc krótko, DTD definiuje gramatykę i zestaw znaczników na potrzeby określonego formatowania XML. Jeśli w dokumencie określono konkretną definicję DTD i jeśli jest on zgodny z tą definicją, to dokument taki określa się jako poprawny. Dokumenty XML mogą zostać takŜe zawęŜone w ramach schematu — jest to nowy sposób narzucania formatu XML, który wyprze DTD. Dokument moŜe być więc takŜe zgodny ze schematem. W dalszej części ksiąŜki zajmiemy się dokładniej przedstawionymi wyŜej zagadnieniami. Najpierw jednak musimy poznać kilka skrótów i specyfikacji uŜywanych wewnątrz dokumentu XML.

PI PI to instrukcja przetwarzania (ang. processing instruction) w dokumencie XML. Instrukcja przetwarzania nakazuje aplikacji wykonanie określonego zadania. Instrukcje PI, choć zajmują niewiele miejsca w specyfikacji XML, są na tyle waŜne, Ŝe znalazły się wśród omawianych akronimów. PI wyróŜnia się spośród innych danych w dokumencie XML tym, Ŝe oznacza polecenie przekazywane parserowi XML lub innemu programowi korzystającemu z dokumentu. W naszym przykładowym dokumencie 1.1 pierwszy wiersz, wskazujący wersję standardu XML, stanowi instrukcję przetwarzania. Informuje parsery, z której wersji standardu będziemy korzystać. Instrukcje przetwarzania mają postać . Wszystkie instrukcje PI, w których jako cel określono XML, naleŜą do standardowego zestawu instrukcji określonego w ramach XML-a i powinny być rozpoznawane przez parsery. Nazywa się je często instrukcjami XML. Ale instrukcje PI mogą takŜe zawierać informacje, które mają zostać wykorzystane przez aplikacje przechwytujące czynności parsera; w takim przypadku jako cel instrukcji przetwarzania moŜna określić słowo kluczowe odpowiadające danej aplikacji (np. „cocoon”). Instrukcje przetwarzania nabierają duŜego znaczenia, gdy dane XML wykorzystywane są w aplikacjach znających ten standard. RozwaŜmy aplikację, która przetwarza nasz przykładowy plik XML, a następnie tworzy reklamę mebli opartą na produktach wymienionych w dokumencie. Instrukcja przetwarzania moŜe poinformować aplikację, Ŝe dany mebel jest na liście „zapotrzebowania” i Ŝe ma zostać przekazany do innej aplikacji, np. takiej, która wysyła zamówienia — zatem taki mebel ma nie pojawiać się w reklamie. Parser XML rozpozna instrukcje PI odwołujące się do celów zewnętrznych i przekaŜe je w niezmienionej postaci zewnętrznym aplikacjom.

DTD DTD to document type definition, czyli definicja typu dokumentu. DTD narzuca szereg ograniczeń na dokument (lub grupę dokumentów) XML. Definicja DTD sama w sobie nie jest specyfikacją, ale została zdefiniowana jako część specyfikacji XML. Deklaracja typu dokumentu wewnątrz dokumentu XML moŜe sama zawierać ograniczenia odnośnie znaczników, ale moŜe takŜe odwoływać się do zewnętrznego dokumentu opisującego takie ograniczenia. Definicją typu dokumentu jest suma tych dwóch powyŜszych zestawów ograniczeń. DTD definiuje sposób, w jaki ma być skonstruowany dokument XML. Ponownie spójrzmy na przykład 1.1. Choć stworzyliśmy grupę własnych znaczników, to dokument taki jest bezuŜyteczny dla innej aplikacji, a nawet dla innego uŜytkownika, który nie potrafi zinterpretować naszych znaczników. Powstają wątpliwości — czy

Co to jest XML?

19

znacznik mówi nam, ile krzeseł jest na stanie? Czy atrybut drewno moŜe zostać uŜyty w znaczniku ? Jeśli dokument ma zostać poprawnie przetworzony przez parser, na te wszystkie pytania trzeba znaleźć odpowiedzi. Dokument uwaŜa się za poprawny, jeśli jest zgodny z ograniczeniami narzucanymi przez DTD odnośnie formatowania danych XML. Jest to szczególnie istotne, gdy zamierzamy przenosić dane pomiędzy aplikacjami — wymaga to uzgodnienia formatu i składni, aby dwa róŜne systemy mogły się porozumieć. Jak juŜ wcześniej wspomniano, definicja DTD definiuje ograniczenia, mówiąc inaczej — zawęŜa konkretny dokument lub zestaw dokumentów XML. Programista lub autor zawartości tworzy takŜe definicję DTD w postaci dodatkowego dokumentu, do którego odwołuje się z plików XML; moŜe takŜe zawrzeć ją w samym pliku XML — w kaŜdym razie definicja nie ingeruje w Ŝaden sposób w dokument XML. Tak naprawdę to właśnie DTD przyczynia się do przenośności danych XML. MoŜe ona na przykład określać, Ŝe jedynymi poprawnymi wartościami atrybutu drewno są „klon”, „sosna”, „dąb” i „mahoń”. Dzięki temu parser potrafi określić, czy zawartość dokumentu jest do przyjęcia, i zapobiec ewentualnym błędom formatowania danych. Definicja DTD określa takŜe kolejność zagnieŜdŜania znaczników. MoŜe na przykład stanowić, Ŝe znacznik ma prawo być zagnieŜdŜany jedynie w znacznikach . Dzięki temu inna aplikacja, która otrzymuje nasz przykładowy plik XML, wie, jak przetworzyć i przeszukiwać otrzymane dane. Definicja DTD nie tylko przyczynia się do wysokiej elastyczności formatowania danych w XML-u, ale takŜe umoŜliwia przetwarzanie i sprawdzanie poprawności danych w dowolnym systemie potrafiącym odnaleźć tę definicję.

Przestrzeń nazw Przestrzeń nazw to jedno z niewielu pojęć związanych z XML-em, dla których nie wymyślono akronimu. Nie ma takiej potrzeby — w tym przypadku nazwa dobrze odpowiada funkcji tego elementu. Przestrzeń nazw (ang. namespace) to odwzorowanie pomiędzy przedrostkiem elementu a identyfikatorem URI. Odwzorowanie to umoŜliwia zapobieŜenie kolizjom przestrzeni nazw oraz określenie struktur danych, które pozwalają parserom zapobiec takim kolizjom. Przeanalizujmy przykład kolizji przestrzeni nazw. ZałóŜmy, Ŝe w dokumencie pomiędzy znacznikami i znajduje się znacznik . Ale w ramach definicji krzesła jest teŜ znacznik , który przecieŜ takŜe moŜe posiadać własny znacznik . ZauwaŜmy równieŜ, Ŝe dokument moŜe odwoływać się do innego dokumentu XML w celu pobrania informacji o prawach autorskich. W obu dokumentach powinny pojawić się znaczniki lub np. , ale jak rozpoznać, który znacznik odwołuje się do czego? Taka dwuznaczność to problem dla parsera XML. Czy znacznik ma być interpretowany w róŜny sposób zaleŜnie od tego, w którym elemencie jest zagnieŜdŜony? Czy moŜe autor zawartości pomyłkowo uŜył go w dwóch kontekstach? Bez informacji o przestrzeni nazw nie jest moŜliwe określenie, czy był to błąd w konstrukcji dokumentu XML, a jeśli było to działanie celowe — jak rozporządzić danymi kolidujących znaczników. Zalecenie opisujące przestrzenie nazw w XML-u definiuje mechanizm do kwalifikowania nazw. Mechanizm ten wykonuje swoje zadanie z uŜyciem identyfikatora URI, ale tego na razie nie musimy wiedzieć. Poprawne stosowanie znaczników w rodzaju opisywanego nie wymaga wpisywania niezbyt mądrych nazw w rodzaju czy . Zamiast tego przestrzeń nazw tworzona jest z wykorzystaniem przedrostka w postaci elementu XML — a więc na przykład: czy . Parser XML umie potem rozróŜnić te przestrzenie i wcale nie trzeba tworzyć nowych nazw. Przestrzenie nazw są najczęściej uŜywane w dokumentach XML, ale pojawiają się takŜe w schematach i arkuszach sty-

Co to jest XML?

20

lów i w innych specyfikacjach powiązanych z XML-em. Zalecenie odnośnie przestrzeni nazw moŜna znaleźć pod adresem http://www.w3.org/TR/REC-xml-names.

XSL i XSLT XSL to Extensible Stylesheet Language, czyli rozszerzalny język arkuszy stylów. SłuŜy do przekształcania i tłumaczenia danych XML z jednego formatu XML na inny. RozwaŜmy przykład, w którym ten sam dokument XML musi zostać wyświetlony w formatach HTML, PDF i Postscript. Bez zastosowania XSL-a dokument XML musiałby być ręcznie skopiowany, a następnie przekształcony na jeden ze wspomnianych formatów. Mechanizm XSL umoŜliwia zdefiniowanie arkuszy stylów wykonujących to zadanie. Zamiast zmieniać dane pod kątem róŜnych reprezentacji, rozdzielamy dane (zawartość) od reprezentacji — właśnie za pomocą języka XSL. Jeśli dokument XML musi zostać odwzorowany w postaci innej reprezentacji, jest uŜywany XSL. Wykonuje podobne zadanie jak program w Javie, który tłumaczy dane na format PDF lub HTML, ale zadanie to wykonuje z wykorzystaniem standardowego interfejsu. Tłumaczenie moŜe dokonywać się za pomocą obiektów formatujących (ang. formatting objects) zawartych wewnątrz dokumentu XSL. Obiekty te mają postać specyficznych, nazwanych znaczników, pod które moŜe zostać podstawiona zawartość składająca się na docelowy typ dokumentu. Typowym obiektem formatującym jest znacznik, który przez jakiś procesor wykorzystywany jest do przetworzenia dokumentu XML na PDF; w takim przypadku znacznik ten zostanie zastąpiony informacją specyficzną dla dokumentu PDF. Obiekty formatujące to specyficzne instrukcje XSL i choć zostaną pokrótce omówione, to jednak wykraczają poza tematykę niniejszej ksiąŜki. Skoncentrujemy się natomiast na XSLT, całkowicie tekstowym procesie transformacyjnym. W wyniku działania procesu XSLT — transformacji rozszerzalnego języka arkuszy stylów (ang. Extensible Stylesheet Language Transformation) — tekstowy arkusz stylów XSL oraz tekstowy dokument XML są „łączone”, tworząc dane XML sformatowane zgodnie z arkuszem stylów XSL. Zagadnienie to przybliŜa przykład 1.2.

Przykład 1.2. Inny przykładowy plik XML Strona testowa WYSIWYG, czyli What you see is what you get!

PowyŜszy dokument zadeklarowano jako dane XML w wersji 1.0. Następnie podano połoŜenie odpowiadającego mu arkusza stylu XSL, akuku.xsl. Podobnie deklaruje się definicję DTD — do DTD odwołujemy się w XML-u po to, aby określić strukturę danych, zaś do pliku XSL po to, aby określić, w jaki sposób dane mają być wyświetlane i prezentowane. W przykładzie 1.3 jest przedstawiony arkusz stylów XSL, do którego odwołujemy się w dokumencie.

Przykład 1.3. Arkusz stylów dla przykładu 1.2

Co to jest XML?

21

<xsl:value-of select="tytul" />

Ten arkusz stylu ma za zadanie przekształcić bazowy dokument XML na postać HTML-ową, nadającej się do obejrzenia w przeglądarce WWW. Wszystkie te zagadnienia zostaną omówione w dalszej części ksiąŜki, tutaj przyjrzymy się tylko znacznikom . KaŜde wystąpienie takiego znacznika powoduje, Ŝe odpowiedni element, na przykład akapit, jest zamieniany na zawartość arkusza XSL — w tym wypadku powoduje to wstawienie znacznika

i ustawienie pochyłości czcionki. Po transformacji dokumentu XML zgodnie z pokazanym arkuszem XSL otrzymujemy taki wynik, jak w przykładzie 1.4.

Przykład 1.4. Wynikowy dokument HTML powstały z przykładów 1.2 i 1.3 Strona testowa

WYSIWYG, czyli What you see is what you get!

Nie szkodzi, Ŝe na razie nie są zrozumiałe wszystkie przedstawione konstrukcje XSL i XSLT; wystarczy, Ŝe Czytelnik zda sobie sprawę z faktu, iŜ korzystanie z XSL-a umoŜliwia uzyskanie bardzo róŜnych formatów dokumentów na podstawie tych samych danych bazowych XML. Więcej informacji na temat XSL-a zawarto w rozdziale 6., Przekształcanie XML-a. Standard XSL w organizacji W3C ma obecnie status Working Draft (wersja robocza). Zalecenie odnośnie standardu XSL moŜna znaleźć pod adresem http://www.w3.org/Style/XSL.

XPath XPath (język XML Path Language) stanowi samodzielną specyfikację, ale jest intensywnie wykorzystywany w ramach XSLT. Specyfikacja XPath określa, w jaki sposób zlokalizować określony element dokumentu XML. W tym celu wykorzystuje się odwołania do specyficznych węzłów do-

Co to jest XML?

22

kumentu XML; węzeł (ang. node) oznacza dowolny komponent XML, taki jak element, atrybut czy dane tekstowe. Według specyfikacji XPath, dokument XML stanowi strukturę drzewiastą takich węzłów. Dostęp do dowolnego węzła moŜna osiągnąć poprzez określenie połoŜenia w danym drzewie. Szczegóły związane z XPath zostaną przedstawione dopiero przy dokładniejszym omawianiu XSL i XSLT, ale trzeba pamiętać, Ŝe z XPath będziemy korzystali wszędzie tam, gdzie musimy odwołać się do specyficznych danych wewnątrz dokumentu XML. Oto przykładowe wyraŜenie XPath: *[not(self::JavaXML:Tytul)]

PowyŜsze wyraŜenie oznacza wszystkie elementy potomne elementu bieŜącego, których nazwa jest inna niŜ JavaXML:Tytul. W przypadku poniŜszego fragmentu dokumentu: Java i XML &OReillyCopyright;

wykonanie wyraŜenia, gdy bieŜącym węzłem jest element JavaXML:Ksiazka, spowoduje zwrócenie elementów JavaXML:Spis oraz JavaXML:Copyright. Pełna specyfikacja XPath jest dostępna pod adresem http://www.w3.org/TR/xpath.

XML Schema Schemat XML Schema to zamiennik definicji DTD o znacznie większych moŜliwościach. SłuŜy do ograniczania (zawęŜania) dokumentów XML. Choć tylko pobieŜnie omówiliśmy definicje DTD, to juŜ moŜna dostrzec dość powaŜne ograniczenia tego standardu: brak znajomości hierarchii, trudności w obsłudze konfliktów przestrzeni nazw i niemoŜność określenia dozwolonych relacji pomiędzy dokumentami XML. Ograniczenia te są ze wszech miar usprawiedliwione — skąd zespoły pracujące nad specyfikacją miały wiedzieć, Ŝe XML będzie wykorzystywany na tak wiele róŜnych sposobów? Jednak wady definicji DTD zaczęły dokuczać autorom i programistom korzystającym z XML-a. Najistotniejszą cechą XML Schema jest fakt, Ŝe umoŜliwia on zbliŜenie definicji DTD do języka XML. To moŜe wydawać się niejasne, ale przypomnijmy sobie, Ŝe kaŜdy akronim, o którym ostatnio mówiliśmy, określany jest na podstawie standardu XML. Arkusze stylów, przestrzenie nazw i cała reszta korzystają z XML-a w celu zdefiniowania specyficznych zastosowań i właściwości tego języka. A definicje DTD są zupełnie inne — nie wyglądają jak XML, nie współdzielą hierarchicznej struktury XML-a i nawet nie reprezentują w ten sam sposób danych. Definicje DTD nie przystają więc zbytnio do świata XML, a poniewaŜ to właśnie one obecnie definiują, jak dokumenty XML mają wyglądać, łatwo się w tym wszystkim pogubić. Problem ten naprawia XML Schema — w standardzie tym definiowanie XML-a odbywa się za pomocą samego XML-a. Nie mówiliśmy jeszcze wiele o „definiowaniu danych opisujących dane”, ale takŜe to potrafi XML Schema. Specyfikacja XML Schema pozwala w większym stopniu korzystać z konstrukcji tylko jednego języka; nie trzeba uciekać się do innych konstrukcji definicji DTD. Członkowie W3C i twórcy XML-a słusznie uznali, Ŝe przebudowa DTD nie przyniosłaby oczekiwanego rezultatu. Dlatego postanowiono stworzyć schematy XML Schema, poprawiając w ten sposób nieodłączne wady DTD oraz dodając nowe funkcje, odpowiadające współczesnym zastosowaniom

Co to jest XML?

23

XML-a. Więcej informacji o tym istotnym projekcie W3C moŜna znaleźć pod adresami http://www. w3.org/TR/xmlschema-1 oraz http://www.w3.org/TR/xmlschema-2. Ciekawe wprowadzenie do XML Schema jest dostępne pod adresem http://www.w3.org/TR/xmlschema-0.

XQL... XQL to język zapytań, dzięki któremu w dokumentach XML moŜna w prosty sposób odwoływać się do baz danych. XQL, choć jeszcze nie został formalnie przyjęty przez W3C, jest na tyle powszechny i przydatny, Ŝe faktycznie stanowi juŜ popularną metodę uzyskiwania dostępu do baz danych z dokumentów XML. Struktura zapytania definiowana jest za pomocą pojęć XPath, a zestaw wynikowy — za pomocą standardowego XML-a i znaczników specyficznych dla XQL-a. Na przykład, poniŜsze wyraŜenie XQL przeszukuje tablicę ksiazki i zwraca wszystkie rekordy, w których tytuł zawiera słowo „Java”. Dla kaŜdego rekordu wyświetlany jest odpowiadający mu rekord w tablicy autorzy: //ksiazki[tytul contains "Java"] ( .//autorzy )

Zestaw wynikowy takiego zapytania moŜe wyglądać następująco:

Najprawdopodobniej w miarę dojrzewania specyfikacji nastąpią w niej jakieś zmiany; na pewno jednak warto trzymać rękę na pulsie i interesować się XQL-em. Obecna propozycja standardu XQL znajduje się pod adresem http://metalab.unc.edu/xql/xql-proposal.html. Spotkała się ona z zainteresowaniem grupy W3C w styczniu 2000 roku, a obecne wymagania odnośnie języka zapytań XML moŜna znaleźć pod adresem http://www.w3.org/TR/xmlquery-req.

... i cała reszta Mamy juŜ za sobą pobieŜne wprowadzenie do najwaŜniejszych z omawianych w ksiąŜce specyfikacji powiązanych z XML-em. Nie zostały omówione wszystkie liczące się akronimy, a jedynie te, które mają szczególne znaczenie przy omawianiu języka XML z punktu widzenia Javy. Pozostałe są wymienione poniŜej, wraz z adresami odpowiednich zaleceń lub projektów roboczych: • Struktura Resource Description Framework (RDF): http://www.w3.org/TR/PR-rdf-schema/ • Język odsyłaczy XML (ang. XML Link Language — XLL): — XLink: http://www.w3.org/TR/xlink/ — XPointer: http://www.w3.org/TR/xptr/ • XHTML: http://www.w3.org/TR/xhtml-basic/ Kiedy Czytelnik będzie czytał tę ksiąŜkę, prawdopodobnie powyŜsza lista będzie juŜ nieaktualna — wciąŜ pojawiają się nowe rozwiązania w ramach XML-a. Nie wszystkie zostały szczegółowo omówione w tej ksiąŜce, ale to wcale nie znaczy, Ŝe nie zasługują na uwagę. Nie są po prostu tak bardzo istotne przy omawianiu obsługi XML-a z poziomu Javy. Pełne zrozumienie XML-a na

Jak z tego korzystać?

24

pewno wymaga opanowania zarówno tych technologii, które dokładniej opisujemy, jak i tych jedynie wspomnianych. Ale i tak moŜe się zdarzyć, Ŝe w pewnym miejscu ksiąŜki Czytelnik napotka standardy, które nie zostały omówione — wówczas takie zagadnienie zostanie dokładnie przedstawione.

Jak z tego korzystać? Wszystkie wspaniałe zalety XML-a nie na wiele się zdadzą, jeśli nie będzie narzędzi umoŜliwiających zastosowanie ich w naszym ulubionym środowisku programistycznym. Na szczęście, XML jest związany z Javą. Java posiada najpełniejszy wybór interfejsów API do obsługi XML-a bezpośrednio z kodu. Co prawda języki takie jak C, C++ i Perl nadrabiają zaległości w tym zakresie, ale to właśnie Java ustanawia standardy dotyczące sposobu obsługi XML-a z poziomu aplikacji. Z punktu widzenia aplikacji, cykl działania dokumentu XML dzieli się na dwa etapy (rysunek 1.1): przetwarzanie dokumentu i analizowanie danych w nim zawartych.

Rysunek 1.1. Cykl dzialania dokumentu XML z punktu widzenia aplikacji Jako programiści Javy, mamy dostęp do bardzo prostych sposobów wykonywania powyŜszych, a takŜe wielu innych czynności.

SAX SAX to Simple API for XML, czyli prosty interfejs API do obsługi XML-a. Do przetwarzania danych XML — czyli procesu odczytywania dokumentu i rozbijania danych na odpowiednie elementy — udostępnia strukturę opartą na obsłudze zdarzeń. Na kaŜdym etapie definiowane są zdarzenia, które mogą wystąpić. Na przykład SAX definiuje interfejs org.xml.sax.ContentHandler, który z kolei definiuje metody, takie jak startDocument() i endElement(). Za pomocą takiego interfejsu moŜna uzyskać pełną kontrolę nad odpowiednimi etapami procesu przetwarzania dokumentu XML. Podobny interfejs stworzono do obsługi błędów i konstrukcji leksykalnych. Definiowany jest zestaw błędów i ostrzeŜeń, co umoŜliwia obsługę róŜnych sytuacji mogących wystąpić w czasie przetwarzania dokumentu XML — np. napotkanie dokumentu niepoprawnego lub źle sformatowanego. MoŜna dodawać nowe zachowania, co umoŜliwia obsługę zadań związanych z bardzo specyficznymi aplikacjami — a wszystko to w ramach standardowego interfejsu XML. Dokumentacja i inne informacje na temat interfejsu SAX znajdują się pod adresem http://www.megginson.com/SAX.

Jak z tego korzystać?

25

Przed przystąpieniem do omawiania kolejnych zagadnień naleŜy koniecznie wyjaśnić pewne nieporozumienie związane z interfejsem SAX. OtóŜ SAX często jestb uwaŜany za parser XML-a. Nawet tutaj piszemy, Ŝe SAX umoŜliwia przetwarzanie danych XML. Ale tak naprawdę SAX udostępnia tylko strukturę dla parserów i definiuje zdarzenia procesu przetwarzania podlegające monitorowaniu. śeby jakiekolwiek przetwarzanie mogło nastąpić, konieczne jest jeszcze zastosowanie zewnętrznego parsera. Powstało wiele świetnych parserów napisanych w Javie, takich jak Project X Suna, Xerces z Apache Software Foundation, XML Parser firmy Oracle i XML4J IBM-a. Wszystkie one podłączane są do interfejsu SAX i umoŜliwiają uzyskanie przetworzonych danych XML. Interfejs SAX udostępnia sposób na przetwarzanie dokumentu, ale sam nie jest parserem.

DOM DOM to interfejs API dla obiektowego modelu dokumentu (ang. Document Object Model). SAX umoŜliwia jedynie dostęp do danych w dokumencie XML, natomiast DOM pozwala na manipulowanie danymi. W ramach interfejsu DOM dokument XML reprezentowany jest jako struktura drzewiasta. PoniewaŜ taki sposób reprezentowania znany jest juŜ od dawna, nie ma trudności z przeszukiwaniem i przetwarzaniem tego rodzaju struktur z poziomu języków oprogramowania — a więc takŜe z poziomu Javy. W interfejsie DOM cały dokument XML wczytywany jest do pamięci, a wszystkie dane są składowane jako węzły, a więc bardzo szybko uzyskać moŜna dostęp do poszczególnych części dokumentów — wszystko jest w pamięci dopóty, dopóki istnieje drzewo DOM. Poszczególne węzły odpowiadają konkretnym danym pobranym z oryginalnego dokumentu. DOM ma jednak pewną powaŜną wadę. PoniewaŜ cały dokument wczytywany jest do pamięci, zasoby szybko ulegają wyczerpaniu, często powodując spowolnienie działania aplikacji, a nawet uniemoŜliwienie jej poprawnego działania. Im większy i bardziej złoŜony jest dokument, tym bardziej spada wydajność. NaleŜy o tym pamiętać — DOM to uŜyteczny i popularny, ale nie jedyny sposób manipulacji danymi XML. Interfejsowi temu poświęcimy nieco czasu; napiszemy takŜe kod słuŜący do manipulacji danymi wprost z interfejsu SAX. Charakterystyka aplikacji zadecyduje o tym, które rozwiązanie okaŜe się lepsze w danym projekcie programistycznym. Zalecenie W3C odnośnie interfejsu DOM znajduje się pod adresem http://www.w3.org/DOM.

JAXP JAXP to interfejs Javy do przetwarzania XML-a (ang. Java API for XML Parsing) firmy Sun. Interfejs ten, będący całkiem nowym narzędziem w arsenale programisty XML-a, ma na celu nadanie spójności interfejsów SAX i DOM. Nie jest rozwiązaniem konkurencyjnym w stosunku do nich, nie został teŜ stworzony jako ich następca — JAXP oferuje uproszczone metody mające na celu ułatwienie korzystania z interfejsów Javy do obsługi XML-a. Jest zgodny ze specyfikacjami SAX i DOM, a takŜe ze wspomnianym wcześniej zaleceniem dotyczącym przestrzeni nazw. JAXP nie definiuje zachowania interfejsów SAX ani DOM, ale zapewnia standardową warstwę dostępu dla wszystkich parserów XML-a z poziomu Javy. Oczekuje się, Ŝe JAXP będzie ewoluował w miarę modyfikacji interfejsów SAX i DOM. MoŜna takŜe załoŜyć, Ŝe ostatecznie zajmie on miejsce wśród innych specyfikacji firmy Sun, jako Ŝe zarówno mechanizm serwletów Tomcat, jak i specyfikacja EJB 1.1 wymagają plików konfiguracyjnych i wdroŜeniowych sformatowanych w XML-u. Choć specyfikacje J2EE® 1.3 oraz J2SE® 1.4 nie mówią jawnie o JAXP, to oczekuje się, Ŝe takŜe w tych narzędziach zostanie zintegrowana obsługa JAXP. Pełna specyfikacja JAXP znajduje się na stronie http://java.sun.com/xml. Te trzy interfejsy składają się na warsztat programistów Javy mających do czynienia z formatem XML. Nie jest to zatwierdzone formalnie, ale właśnie ta trójka oferuje mechanizm pobierania

Dlaczego warto korzystać z technologii XML?

26

i manipulowania danymi z poziomu zwykłego kodu w Javie. Interfejsy te będą nam potrzebne w całej ksiąŜce; dowiemy się wszystkiego o klasach, które kaŜdy z nich udostępnia.

Dlaczego warto korzystać z technologii XML? W powyŜszych podrozdziałach zostały omówione najwaŜniejsze skróty opisujące technologie związane z XML-em. Być moŜe Czytelnik zorientował się juŜ, Ŝe XML to coś więcej niŜ kolejny sposób tworzenia warstwy prezentacji. Ale nie jest jeszcze pewien, w którym miejscu tworzonych aplikacji standard ten moŜna zastosować. Nie udałoby nam się jeszcze przekonać pracodawcy, Ŝe powinniśmy poświęcić więcej czasu na poznawanie XML-a — po prostu nie umielibyśmy udowodnić mu, Ŝe XML moŜe przyczynić się do stworzenia lepszej aplikacji. Chcielibyśmy pewnie nawet wypróbować to lub tamto narzędzie do pracy na dokumentach XML, ale nie wiemy, od czego zacząć. Jeśli Czytelnik ma teraz takie właśnie odczucie — zainteresowanie nową technologią i trudność zdecydowania, co robić dalej — to warto czytać dalej! W tej części poznamy relacje między XML-em a rzeczywistymi aplikacjami i uzasadnimy potrzebę korzystania z tego standardu. Najpierw zostanie omówione zastosowanie języka XML we współczesnych aplikacjach. Następnie autor przedstawi wsparcie oferowane dla XML-a i powiązanych z nim technologii — wszystko to w świetle aplikacji w Javie. Java oferuje cały wachlarz parserów, narzędzi przekształcających, mechanizmów publikacyjnych i struktur opracowanych specjalnie pod kątem XML-a. W zakończeniu zostaną omówione kierunki rozwoju XML-a. Te wiadomości będą argumentami słuŜącymi do przekonania przełoŜonego (i jego przełoŜonych), jak bardzo XML liczy się teraz na rynku.

Java i XML — małŜeństwo idealne Wiemy juŜ, Ŝe XML to naprawdę przydatna technologia i Ŝe zdobywa ogromną popularność, jednak Czytelnik tej ksiąŜki moŜe sobie zadawać pytanie, dlaczego traktuje ona o Javie i XML-u, a nie tylko o tym ostatnim. OtóŜ Java idealnie pasuje do XML-a z jednego zasadniczego powodu: Java to przenośny kod, XML to przenośne dane. Oddzielnie obie te technologie są naprawdę bardzo dobre, ale mają ograniczenia. Java wymaga od programisty tworzenia formatów danych do przesyłania przez sieć i do prezentacji oraz korzystania z technologii typu Java Server Pages™ (JSP), które nie zapewniają faktycznej separacji warstw zawartości i prezentacji. XML to po prostu metadane i bez parserów czy procesorów XSL jest to „oprogramowanie - widmo”. Kiedy Java i XML zostaną połączone, wszystkie te ograniczenia programistyczne znikają. Kiedy napiszemy program w Javie, to mamy pewność, Ŝe skompilowany kod bajtowy będzie mógł zostać uruchomiony na dowolnym sprzęcie i w dowolnym systemie operacyjnym wyposaŜonym w wirtualną maszynę Javy (JVM). Jeśli do tego dodamy moŜliwość reprezentacji danych wejściowych i wyjściowych aplikacji z wykorzystaniem niezaleŜnej od systemu, standardowej warstwy danych, to otrzymujemy całkowitą przenośność informacji. Aplikacja jest przenośna i porozumiewa się z dowolną inną aplikacją za pomocą tych samych (szeroko przyjętych) standardów. Mało tego, wspomnieliśmy juŜ takŜe, Ŝe Java udostępnia szerszy wachlarz interfejsów, parserów, procesorów, struktur publikacji i narzędzi dla XML-a niŜ jakikolwiek inny język. Pamiętając o tym wszystkim, zobaczymy, jak te dwie technologie współpracują dziś i jak ta współpraca będzie przebiegała w latach następnych.

Dlaczego warto korzystać z technologii XML?

27

XML dzisiaj Wśród wielu programistów i pracowników firm branŜy technologicznej panuje przekonanie, Ŝe XML to rzeczywiście nowoczesna technologia, ale Ŝe nie jest jeszcze gotowa do zastosowania w aplikacjach krytycznych, od których zaleŜy funkcjonowanie całej firmy. To mylna opinia. XML i spokrewnione technologie, o których wspomnieliśmy, trwale zadomowiły się w aplikacjach — przyjęły się znacznie szybciej niŜ zaprezentowana kilka lat temu Java. Najprawdopodobniej to właśnie XML pobił rekord Javy w zdobywaniu rynku informatycznego. My, programiści, musimy sobie zdawać sprawę z faktu, Ŝe te dwie technologie uzupełniają się, a nie zwalczają. Dane i aplikacje nie mogą być juŜ bardziej przenośne niŜ te napisane w Javie i XML-u. Obydwie technologie są juŜ teraz bardzo często stosowane.

XML w prezentacji danych XML najczęściej stosowany jest do rozdzielania zawartości od sposobu jej prezentacji. Zawartością (ang. content) nazywamy dane, które mają zostać wyświetlone u klienta, zaś prezentacją (ang. presentation) samo formatowanie tych danych. Na przykład, nazwa i adres pracownika działu administracji to zawartość, a sformatowana strona w HTML-u, z grafiką i emblematem firmy, to prezentacja. Zasadnicza róŜnica polega na tym, Ŝe zawartość jest uniwersalna względem aplikacji i moŜe zostać poddana dowolnemu formatowaniu; prezentacja natomiast związana jest z konkretnym typem klienta (przeglądarką WWW, telefonem z obsługą Internetu, aplikacją Javy) oraz z funkcjami udostępnianymi przez klienta (HTML 4.0, język WML, Java™ Swing). Za zawartość odpowiedzialny jest wtedy XML, zaś za prezentację odpowiadającą poszczególnym klientom — XSL i XSLT. Jednym z największych wyzwań stojących przed współczesnymi aplikacjami, szczególnie aplikacjami WWW, jest róŜnorodność klientów z nich korzystających. Jeszcze dziesięć lat temu istniały niemal wyłącznie klienty pełne (ang. thick clients), z zainstalowanym oprogramowaniem pozwalającym na korzystanie z aplikacji. Trzy lata temu klienty aplikacji miały niemal zawsze postać przeglądarek internetowych „rozumiejących” HTML. Obecnie korzysta się z przeglądarek na najrozmaitszych platformach systemowych, popularne stały się telefony komórkowe z obsługą bezprzewodowego języka znaczników WML (ang. Wireless Markup Language) oraz asystenty kieszonkowe („organizery”) z obsługą podzbioru HTML-a. Taka róŜnorodność powoduje, Ŝe nieraz tworzy się niezliczone wersje tej samej aplikacji — po jednej wersji dla kaŜdego typu klienta — a i tak nie wszystkie klienty są poprawnie obsługiwane. Aplikacja nie musi koniecznie obsługiwać np. telefonu komórkowego, ale przecieŜ jeśli juŜ odbiorcy lub pracownicy firmy wyposaŜeni są w takie urządzenia, to czy nie warto z nich skorzystać? MoŜe i kieszonkowy asystent nie umoŜliwia wykonywania wszystkich operacji, jakie udostępnia zwyczajna przeglądarka WWW, ale czy osoby często przebywające w podróŜy nie docenią moŜliwości przynajmniej podstawowej obsługi swoich spraw w naszej firmie za ich pośrednictwem? Twórcy aplikacji i osoby zarządzające firmami mają dylemat — czy tak jak dawniej oferować wszystkie funkcje tylko wybranym klientom, czy, zgodnie z nowymi tendencjami, oferować jedynie ograniczone funkcje, ale wszystkim klientom? Odpowiedzią jest XML. Jak powiedzieliśmy wcześniej, XML nie jest technologią prezentacyjną. Jedynie moŜe być uŜyty do wygenerowania warstwy prezentacyjnej. Jeśli Czytelnik nie dostrzega róŜnicy, moŜe warto odwołać się do HTML-a jako technologii prezentacyjnej. HTML ma postać języka znaczników dobranych tak, Ŝe umoŜliwiają graficzne rozplanowanie elementów na stronie wyświetlanej przez przeglądarkę WWW. Ale przecieŜ zastosowanie HTML-a nie jest dobrym sposobem reprezentacji danych. Dokumentu w tym formacie ani łatwo się nie przeszukuje, ani nie przetwarza. Format został zdefiniowany dość swobodnie, a przynajmniej połowę pliku zajmują znaczniki prezentacji — właściwe dane to tylko niewielki procent dokumentu. XML jest zupełnie inny. Ten język znaczników ukierunkowany jest na dane, a nie na prezentację. Niemal całość dokumentu XML to

Dlaczego warto korzystać z technologii XML?

28

dane i opis ich struktury. Do danych nie odwołują się jedynie instrukcje dla parsera XML lub aplikacji przechwytujących. Przeszukiwanie dokumentu XML i jego przetwarzanie z wykorzystaniem interfejsów API i narzędzi jest proste, dzięki ściśle określonej strukturze narzuconej przez DTD lub schemat. XML jest całkowicie odłączony od warstwy prezentacji. MoŜe jednak zostać wykorzystany do tworzenia warstwy prezentacyjnej poprzez zastosowanie spokrewnionych technologii XSL i XSLT. W ramach XSL tworzona jest definicja i konstrukcje odpowiedzialne za prezentacje, a takŜe instrukcje informujące, jak te konstrukcje mają się do danych w dokumencie XML. XSLT umoŜliwia wyświetlenie oryginalnego dokumentu XML u klienta na róŜne sposoby, takŜe poprzez bardzo złoŜony format HTML. Przez cały ten czas bazowy dokument XML pozostaje odseparowany od warstwy prezentacji. W kaŜdej chwili moŜe w równie prosty sposób zostać dostosowany do zupełnie innego stylu prezentacji, np. interfejsu uŜytkownika Swing, bez konieczności wprowadzania jakichkolwiek zmian w oryginalnych danych. Być moŜe najpotęŜniejszą funkcją oferowaną przez XML i XSL na potrzeby prezentacji jest moŜliwość tworzenia wielu arkuszy stylów odpowiadających dokumentowi XML albo narzucania z zewnątrz takich arkuszy. Ta moŜliwość zwiększa elastyczność prezentacji: nie tylko moŜna korzystać z tego samego dokumentu XML na potrzeby wielu prezentacji, ale struktura publikacji dokonująca transformacji moŜe sama określić, od jakiego klienta nadeszło Ŝądanie dokumentu, i wybrać odpowiedni arkusz stylu. Nie istnieje standardowy sposób przeprowadzania tego procesu nie ma teŜ standardowych kodów odpowiadających róŜnym klientom, ale struktura publikacji XML pozwala na przeprowadzanie takich czynności w sposób dynamiczny. Proces tworzenia wielu arkuszy stylów XSL w ramach dokumentu XML nie jest zaleŜny od produktu Ŝadnej firmy, więc jedyne, co naleŜy zrobić w dokumencie XML w celu wykorzystania go w strukturze publikacji, to wprowadzenie jednej czy dwóch instrukcji przetwarzających. Instrukcje takie, jeśli nie są obsługiwane ze strony aplikacji, zostają zignorowane, a więc oznakowane w ten sposób dane pozostają całkowicie przenośne i w stu procentach zgodne ze standardem XML.

XML w komunikacji Ten sam dokument XML moŜe zostać nie tylko przekształcony, jak to zostało opisane wyŜej, moŜliwe jest równieŜ przesłanie danych, które zawiera, do innej aplikacji. WdroŜenie takiej komunikacji nie sprawia Ŝadnych trudności, poniewaŜ dane XML nie są związane z Ŝadnym typem klienta — nie są nawet wykorzystywane bezpośrednio przez klienta. W szybki sposób uzyskać moŜna równieŜ prostą reprezentację danych, łatwą do przesłania w sieci. To właśnie ten aspekt XML-a — łatwość przesyłania danych — jest chyba najbardziej niedoceniany. Aby zrozumieć, jak duŜo daje moŜliwość komunikacji za pośrednictwem standardu XML, trzeba najpierw rozszerzyć swój sposób postrzegania aplikacji-klienta. Kiedy omawialiśmy prezentację, w typowy sposób załoŜyliśmy, Ŝe klient to uŜytkownik uzyskujący dostęp do części aplikacji. Ale w dzisiejszych czasach jest to duŜe uproszczenie. Klient to tak naprawdę cokolwiek (tak, cokolwiek!), co uzyskuje dostęp do danych lub usług aplikacji. Klienty to np. komputery lub telefony komórkowe uŜytkowników; klienty to inne aplikacje, systemy składowania danych w rodzaju baz danych lub usług katalogowych; klientem moŜe być nawet aplikacja łącząca się sama z sobą. Tak szerokie pojęcie klienta pozwala zrozumieć, jak duŜe znaczenie moŜe mieć XML. Spróbujmy najpierw podzielić klienty na dwie grupy: klienty wymagające warstwy prezentacji i te, które warstwy takiej nie wymagają. Nie zawsze łatwo przeprowadzić taki podział. Na pewno formaty HTML i WML (Wireless Markup Language) to prezentacja, ale co zrobić, jeśli dane muszą zostać sformatowane jedynie nieznacznie na potrzeby innej aplikacji — np. poprzez odfiltrowanie danych zabezpieczonych lub zmianę nazw elementów? Tak naprawdę rzadko mamy do czynienia z klientem, który nie wymaga jakiegoś konkretnego formatowania danych.

Dlaczego warto korzystać z technologii XML?

29

PowyŜsza próba kategoryzacji powinna przekonać Czytelnika, Ŝe dane niemal zawsze podlegają transformacji, często wielokrotnej. RozwaŜmy dokument XML, który został przekonwertowany na format uŜyteczny dla innej aplikacji za pomocą arkusza XSL (rysunek 2.2). Plik wynikowy jest wciąŜ dokumentem XML. Taka aplikacja moŜe następnie wykorzystać dane do stworzenia nowego zestawu wynikowego i utworzenia nowego dokumentu XML. Nowe informacje mają zostać przekazane ponownie pierwszej aplikacji, a więc nowy dokument XML jest znów przekształcany na oryginalny format — choć teraz zawiera inne dane! To bardzo typowy scenariusz.

Rysunek 1.2. Transformacje XML/XSL pomiędzy aplikacjami To właśnie ten cykliczny proces przetwarzania dokumentu i nieustannego tworzenia nowej postaci wynikowej XML czyni z XML-a tak potęŜne narzędzie komunikacyjne. Ten sam zestaw zasad wykorzystywany jest na kaŜdym etapie procesu. Zawsze rozpoczyna się od dokumentu XML, przekształca zgodnie z jednym lub więcej arkuszami stylów XSL i uzyskuje się dokument XML, który wciąŜ jest uŜyteczny dla tych samych narzędzi, które stworzyły dokument oryginalny. ZauwaŜmy takŜe, Ŝe XML to dane reprezentowane w sposób czysto tekstowy. PoniewaŜ reprezentacja tekstowa nie wymaga duŜych zasobów i łatwo wykonać na niej serializację danych, zatem przesyłanie tego typu danych w sieci jest łatwiejsze. Niektóre formaty binarne moŜna przesyłać bardzo wydajnie, a jednak tekstowy XML niemal zawsze okazuje się szybszym sposobem komunikacji.

XML-RPC Specyfikacja, w której skupiono się właśnie na wykorzystaniu XML-a w komunikacji, to XML-RPC. Opisuje ona komunikację nie tyle pomiędzy aplikacjami, co pomiędzy poszczególnymi elementami aplikacji albo współdzielonymi usługami działającymi pomiędzy aplikacjami. RPC to skrót utworzony od słów Remote Procedure Calls (zdalne wywoływanie procedur). Jest jednym z najwaŜniejszych poprzedników technologii zdalnego wywoływania metod RMI (ang. Remote Method Invocation). Za pomocą RPC moŜliwe jest wywoływanie procedur poprzez sieć i — takŜe poprzez sieć — otrzymywanie odpowiedzi. NaleŜy zauwaŜyć, Ŝe to rozwiązanie jest zasadniczo róŜne od RMI, technologii, która pozwala klientowi uruchamiać metody na danym obiekcie za pośrednictwem „namiastek” metod (ang. stub) i szkieletów ładowanych poprzez sieć. Główna róŜnica polega na tym, Ŝe wywołania RPC powodują wygenerowanie odpowiedzi zdalnie; odpowiedź taka zwracana jest później poprzez sieć, a klient nigdy nie komunikuje się bezpośrednio z obiektem

Dlaczego warto korzystać z technologii XML?

30

zdalnym (Ŝąda wywołania metody za pomocą interfejsów RPC). Natomiast technologia RMI umoŜliwia klientowi bezpośrednią interakcję z obiektem zdalnym i nie ma Ŝadnego „pośredniczenia” w Ŝądaniach. Bardziej szczegółowy opis zasady działania technologii XML-RPC moŜna znaleźć pod adresem http://www.xml-rpc.com. Technologia XML-RPC stała się bardzo uŜytecznym sposobem odwoływania się do zdalnych usług. Z powodu trudności stworzenia standardowego modelu Ŝądanie-odpowiedź, technologia RPC niemal zupełnie przestała być uŜywana w programach w Javie — zastąpiono ją technologią RMI. Istnieją jednak sytuacje, w których wysyłanie i odbieranie danych tekstowych jest wydajniejsze niŜ ładowanie zdalnych „namiastek” i szkieletów. RPC obciąŜony jest historycznym problemem polegającym na tym, Ŝe zawsze starano się reprezentować złoŜone obiekty wyłącznie tekstowo (zarówno Ŝądania, jak i odpowiedzi). Problem ten rozwiązano w XML-u i RPC znów okazuje się dobrym sposobem komunikacji systemów zdalnych. Dzięki standardowi umoŜliwiającemu reprezentowanie dowolnego typu danych za pomocą dokumentów tekstowych mechanizm XML-RPC potrafi odwzorowywać parametry egzemplarza (ang. instance) obiektu na elementy XML i w prosty sposób dekodować ten „graf” obiektu na serwerze. Uzyskana odpowiedź moŜe znowu zostać przekształcona na „graf” XML-a i zwrócona klientowi (rysunek 1.3). Więcej informacji o mechanizmie XML-RPC moŜna znaleźć w rozdziale 10., XML-RPC.

Rysunek 1.3. Komunikacja i powiadamianie w standardzie XML-RPC

Firma-firma Ostatni ze sposobów zastosowania XML-a w celach komunikacyjnych tak naprawdę nie stanowi oddzielnej metody czy specyfikacji; poniewaŜ jednak pojęcie komunikacji i handlu typu firma-firma (ang. business-to-business) jest ostatnio bardzo popularne, naleŜy je objaśnić. Komunikacja firma-firma oznacza nie tyle porozumiewanie się dwóch róŜnych aplikacji, co komunikację pomiędzy przedsiębiorstwami, a nawet całymi branŜami. XML jest w takich przypadkach naprawdę pomocnym narzędziem — zapewnia komunikację pomiędzy systemami zamkniętymi, umoŜliwiając wdroŜenie usług, na które kiedyś mogły sobie pozwolić jedynie największe firmy. Przeanalizujmy to zagadnienie na przykładzie. ZałóŜmy, Ŝe niewielki, lokalny operator telekomunikacyjny sprzedaje swojemu klientowi linię do przesyłania danych, np. DSL lub T1. Pociąga to za sobą szereg procesów (rysunek 1.4). Trzeba złoŜyć zamówienie u dostawcy linii, naleŜy skonfigurować router.

Dlaczego warto korzystać z technologii XML?

31

O ustawieniach routera trzeba poinformować usługodawcę internetowego (ISP). Następnie przeprowadzana jest faktyczna instalacja, do wykonania której moŜe zostać wynajęta — np. na zasadzie outsourcingu — jeszcze inna firma. W tej względnie prostej operacji sprzedaŜy łącza sieciowego biorą udział aŜ trzy firmy! Jeśli do tego dodamy techników zatrudnionych przez producenta routera, firmę telekomunikacyjną świadczącą inne usługi klientowi czy NASK zajmujący się rejestracją domeny, to cały proces zaczyna urastać do sporego problemu. Na szczęście proces ten moŜna uprościć, właśnie za pomocą XML-a (rysunek 1.5). Wyobraźmy sobie, Ŝe pierwotne zamówienie na załoŜenie łącza zostaje wprowadzone do systemu, który konwertuje je na dokument XML. Dokument ten jest przetwarzany (za pomocą XSL-a) na format, który moŜna przesłać dostawcy linii. Dostawca linii dodaje do tego dokumentu własne informacje i przekształca go na nowy dokument XML, który zwracany jest naszemu lokalnemu operatorowi. Ten nowy dokument przekazywany jest firmie instalującej z dodatkowymi informacjami o tym, gdzie znajduje się firma klienta. Po instalacji firma instalująca dodaje do dokumentu notatkę informującą o powodzeniu lub niepowodzeniu instalacji i po przekształceniu (znów za pomocą XSL-a) dokument jest oddawany do głównej aplikacji u operatora. Elegancja tego rozwiązania polega na tym, Ŝe zamiast kilku systemów firmowych, z których kaŜdy ma swój sposób formatowania, na kaŜdym etapie wykorzystywany jest ten sam interfejs XML — bez względu na rodzaj aplikacji, systemu czy firmy.

Rysunek 1.4. Proces instalowania łącza sieciowego z wykorzystaniem systemów firmowych

Dlaczego warto korzystać z technologii XML?

32

XML w konfiguracji Jeszcze jedno istotne zastosowanie standardu XML w aplikacjach i technologiach związanych z Javą ma miejsce na poziomie serwera aplikacji. Specyfikacja Enterprise JavaBeans (EJB) 1.1 wymaga, aby deskryptory wdroŜeniowe dla programów JavaBean (definiujące sposób działania i inne parametry związane z EJB) oparte były na XML-u. Wcześniej w tym celu uŜywano serializowanych deskryptorów wdroŜeniowych. W środowisku programistów EJB tę zmianę przyjęto z zadowoleniem, poniewaŜ deskryptory wdroŜeniowe nie muszą być juŜ tworzone zgodnie z wymogami rozwiązań firmowych. PoniewaŜ deskryptory wdroŜeniowe mają być teraz zgodne z wcześniej zdefiniowaną definicją DTD, wszyscy producenci wykorzystują te same deskryptory. To zaś przyczynia się do zwiększenia przenośności kodu EJB.

Rysunek 1.5. Proces instalowania łącza sieciowego z wykorzystaniem danych w standardzie XML Standard XML wykorzystywany jest takŜe w konfiguracji interfejsu API serwletów (wersja 2.2). Plik XML opisuje konfigurację samego mechanizmu serwletów (określa parametry złącza, początkowy kontekst serwleta i inne aspekty specyficzne dla mechanizmu). Pliki konfiguracyjne XML wykorzystywane są takŜe do konfigurowania indywidualnych serwletów — umoŜliwiają przekazywanie argumentów początkowych, konfigurację wielu nazw serwleta oraz dopasowywanie adresów URL w specyficznych kontekstach serwletów. ChociaŜ zarówno specyfikacja EJB 1.1, jak i mechanizm serwletów Tomcat są nowymi elementami w krajobrazie języka Java, to zastosowanie XML-a jako podstawy konfiguracji świadczy o tym, Ŝe firma Sun przyjęła strategię wykorzystywania standardu XML w tego typu zastosowaniach. W miarę wzrostu popularności parserów XML, pliki konfiguracyjne w XML-u będą stosowane coraz częściej, i to nie tylko w serwerach opartych na Javie — równieŜ w np. serwerach HTTP czy bazach danych.

Dlaczego warto korzystać z technologii XML?

33

Obsługa XML-a W drugiej połowie 1999 roku standard XML przeŜył rozkwit. Pojawiły się — a w chwili obecnej zyskały juŜ stabilność i wysoką wydajność — parsery XML, procesory XSLT, struktury publikacji, edytory XML i zintegrowane środowiska programistyczne IDE, a takŜe całe bogactwo narzędzi pokrewnych. Choć tematem tej ksiąŜki jest interfejs API Javy do manipulacji danymi XML, to jednak parsery, procesory i inne elementy niewątpliwie stanowią część procesu przetwarzania XML-a, a więc poświęcone im będzie naleŜne miejsce. PoniewaŜ technologia XML zmienia się niezwykle szybko, nie będziemy tutaj mówili o konkretnych wersjach — w czasie pojawienia się tej ksiąŜki na rynku będą juŜ zapewne nowsze. Ponadto jest bardzo moŜliwe, Ŝe wtedy dostępne będą nowe narzędzia. Jeśli Czytelnik nie znajdzie w ksiąŜce informacji o obsłudze XML-a z poziomu określonego narzędzia, powinien uzyskać je od producenta oprogramowania.

Parsery Parser stanowi jedną z najwaŜniejszych warstw aplikacji obsługującej XML. Element ten odpowiedzialny jest za niezwykle istotne zadanie analizowania dokumentu. Sprawdza, czy jest poprawnie sformatowany, czy umieszczono w nim odwołanie do odpowiedniej definicji DTD lub schematu; moŜe takŜe sprawdzać poprawność składni. Po takim przetworzeniu zazwyczaj uzyskiwana jest struktura danych — w naszym przypadku przeniesiona na grunt Javy — którą łatwo potem manipulować poprzez inne narzędzia XML lub interfejs API Javy. Nie będziemy teraz szczegółowo opisywać takich struktur, poniewaŜ są one przedstawione w kolejnych rozdziałach. Tymczasem wystarczy pamiętać, Ŝe parser to jeden z najwaŜniejszych składników mechanizmu przetwarzania dokumentu XML. Wybór parsera XML nie jest zadaniem prostym. Nie obowiazują tutaj sztywne zasady, ale zazwyczaj brane są pod uwagę dwa kryteria. Pierwsze z nich to szybkość parsera. W miarę coraz częstszego wykorzystywania dokumentów XML i zwiększania ich złoŜoności szybkość parsera zaczyna mieć istotny wpływ na ogólną wydajność aplikacji. Drugie kryterium to zgodność ze specyfikacją XML. PoniewaŜ to właśnie wydajność jest często waŜniejsza niŜ niektóre rzadko wykorzystywane cechy XML-a, niektóre parsery nie są w stu procentach zgodne ze specyfikacją XML. UŜytkownik musi więc wypośrodkować pomiędzy tymi dwoma kryteriami, biorąc pod uwagę konkretne zastosowanie. Ponadto niektóre parsery potrafią sprawdzać poprawność składni XML na podstawie definicji DTD, a inne nie. Jeśli tego wymaga dana aplikacja, musimy skorzystać z parsera posiadającego taką umiejętność. PoniŜej przedstawiony jest spis najpopularniejszych parserów XML. Nie zamieszczono tutaj informacji, czy dany parser wyposaŜony jest w funkcję sprawdzania poprawności składni, poniewaŜ w niektórych przypadkach funkcja taka jest właśnie dodawana. Nie przedstawiono tutaj takŜe oceny tych parserów, ale informacje przedstawione na wymienionych stronach WWW powinny wystarczająco ułatwić wybór: • Apache Xerces, http://xml.apache.org • IBM XML4J, http://alphaworks.ibm.com/tech/xml4j • James Clark's XP, http://www.jclark.com/xml/xp • OpenXML, http://www.openxml.org • Oracle XML Parser, http://technet.oracle.com/tech/xml • Sun Microsystems Project X, http://java.sun.com/products/xml

Dlaczego warto korzystać z technologii XML?

34

• Tim Bray's Lark and Larval, http://www.textuality.com/Lark • Grupa W3C poinformowała, Ŝe zamierza opublikować parser sprawdzający poprawność na podstawie schematu. Parser będzie oprogramowaniem typu open source.

Na tej liście celowo nie umieszczono parsera Microsoftu. Wygląda na to, Ŝe firma ta nie zamierza teraz ani w przyszłości utrzymywać zgodności ze standardami W3C. Microsoft najwyraźniej opracowuje własną wersję XML-a. IleŜ to juŜ razy przerabialiśmy... W kaŜdym razie trzeba mieć się na baczności, gdy sytuacja zmusi nas do wykorzystania parsera Microsoftu, MSXML.

Procesory Po przetworzeniu dokumentu XML niemal zawsze następuje jego przekształcenie (transformacja). Przekształcenie to, jak juŜ wspomnieliśmy, wykonywane jest za pomocą XSLT. Podobnie jak w przetwarzaniu, równieŜ na tym etapie obróbki dokumentu XML moŜemy wybierać spośród wielu narzędzi. Znów dwoma podstawowymi kryteriami wyboru są szybkość przekształcania i zgodność ze specyfikacjami XSL i XSLT. W czasie pisnia tej ksiąŜki standard XSL zyskał status ukończonego zalecenia W3C, a więc obsługa konstrukcji i opcji XSL bardzo gwałtownie się rozwija. Najlepszym źródłem informacji o danym procesorze jest wymieniona strona WWW — tam znajdziemy informacje dotyczące zgodności narzędzia ze specyfikacjami, tam teŜ są zamieszczone testy porównawcze. • Apache Xalan, http://xml.apache.org • James Clarks's XT, http://www.jclark.com/xml/xt • Lotus XSL Processor, http://www.alphaworks.ibm.com/tech/LotusXSL • Oracle XSL Processor, http://technet.oracle.com/tech/xml • Keith Visco's XSL:P, http://www.clc-marketing.com/xslp • Michalel Kay's SAXON, http://users.iclway.co.uk/mhkay/saxon

Struktury publikacji Struktura publikacji (ang. publishing framework) to termin nieco mglisty, nie stanowiący formalnej definicji. Na potrzeby niniejszej ksiąŜki strukturą publikacji standardu XML nazwiemy zestaw narzędzi XML wykonujących przetwarzanie, przekształcanie (transformację) oraz dodatkowe czynności na dokumentach XML w aplikacji. Przetwarzanie i transformacja są zazwyczaj wykonywane za pomocą wspomnianych wyŜej narzędzi; struktura publikacji łączy zaś wszystkie te operacje w jedną całość z interfejsem API Javy i zapewnia standardowy interfejs całości. W bardziej zaawansowanych strukturach moŜliwe jest przetwarzanie zarówno statycznych dokumentów XML, jak i tych stworzonych w aplikacjach Javy. Niektóre udostępniają takŜe edytory i mechanizmy do tworzenia komponentów, dzięki czemu wygenerowany XML zgodny jest z wymaganiami narzuconymi przez daną strukturę. PoniewaŜ nie istnieje Ŝadna specyfikacja określająca zachowanie takich struktur, wymienione poniŜej rozwiązania są bardzo róŜne. KaŜde posiada cechy, które sprawiają, Ŝe warto się mu przyjrzeć bliŜej. Niektóre struktury są rozprowadzane na zasadzie oprogramowania open source (OSS),

Dlaczego warto korzystać z technologii XML?

35

są więc nie tylko ogólnie dostępne, ale takŜe otwarte w tym sensie, Ŝe moŜna sprawdzić, w jaki sposób dane funkcje zostały zaimplementowane. Kiedy później zajmiemy się budową poszczególnych komponentów aplikacji, wybierzemy taką strukturę, która najlepiej pasuje do danego zadania. Teraz jednak decyzję tę odkładamy, aby Czytelnik mógł sam zdecydować, co jest dla niego najlepsze. • Apache Cocoon, http://xml.apache.org • Enhydra Application Server, http://www.enhydra.org • Bluestone XML Server, http://www.bluestone.com/xml • SAXON, http://users.iclway.co.uk/mhkay/saxon

Edytory i środowiska IDE dla standardu XML Istnieje wiele potęŜnych parserów i procesorów XML. Tego samego nie moŜna jednak powiedzieć o edytorach. Niestety, XML jest w tym aspekcie w podobnej sytuacji, co kilka lat temu HTML. Niewielka grupa specjalizowanych programistów „pisze XML” zazwyczaj w vi, emacsie lub Notatniku. Pojawiły się ostatnio edytory przeznaczone specjalnie dla XML-a, są to jednak jeszcze projekty niedojrzałe i ich praktyczna przydatność jest niewielka. Istotne postępy robi na tym polu IBM — dotychczasowe wyniki pracy tej firmy moŜna zobaczyć na stronie http://alphaworks.ibm.com. Odsyłacze do najświeŜszego oprogramowania moŜna teŜ znaleźć w świetnym serwisie http:// www.xmlsoftware.com.

Przyszłość XML-a Aby dopełnić obraz XML-a, spróbujmy jeszcze przewidzieć, jak standard ten będzie wykorzystywany w przyszłości. XML często określa się mianem „technologii przyszłości”. W niejednej firmie nie zdecydowano się na korzystanie z tego standardu, twierdząc Ŝe to technologia jeszcze niedopracowana. Jednocześnie wszyscy przyznają, Ŝe jej znaczny wpływ na sposób tworzenia aplikacji jest juŜ przesądzony. Po tym, jak omówiliśmy sposoby zastosowania XML-a, trudno zgodzić się z tezą o jego niedojrzałości. Ale twierdzenie, Ŝe standard ten zrewolucjonizuje proces tworzenia aplikacji jest jak najbardziej prawdziwe. Nawet ci, którzy nie korzystają jeszcze intensywnie z XML-a, są świadomi, Ŝe wkrótce będą to musieli robić — a to „wkrótce” jest z kaŜdym dniem bliŜej. Mimo całego tego zamieszania otaczającego technologię XML oraz wielkich nadziei, jakie ona ze sobą niesie, prawie niemoŜliwe jest przewidzenie, jakie znaczenie będzie ona miała za rok, czy nawet za pół roku. To trochę tak, jakbyśmy jakieś cztery lata temu próbowali przewidzieć przyszłość tego śmiesznego języka obiektowego zwanego Javą, przydatnego, owszem, do budowania apletów... Są jednak pewne tendencje w XML-u, które pozwalają domyślić się, jakie zmiany nastąpią w najbliŜszym czasie. Przyjrzyjmy się tym najbardziej rzucającym się w oczy.

Repozytoria konfiguracji Jak juŜ wspomnieliśmy, XML jest coraz częściej wykorzystywany w konfiguracjach serwerów, poniewaŜ umoŜliwia niezwykle prostą reprezentację danych idealnie spełnia potrzeby plików konfiguracyjnych. Tradycyjnie pliki takie były dość zawiłe, trudne w uŜyciu i modyfikacji oraz specyficzne dla danego producenta. Spójrzmy na fragment pliku konfiguracyjnego serwera HTTP Apache (przykład 1.5).

Dlaczego warto korzystać z technologii XML?

36

Przykład 1.5. Plik konfiguracyjny serwera HTTP Apache ServerType standalone ServerRoot "e:/java/server/apache/http" PidFile logs/httpd.pid ScoreBoardFile logs/apache_status Timeout 300 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 15 MaxRequestsPerChild 0 ThreadsPerChild 50 Listen 80 Listen 85

Plik taki jest niezbyt skomplikowany, ale zasadniczo róŜni się od pliku konfiguracyjnego serwera Weblogic (przykład 1.6).

Przykład 1.6. Plik konfiguracyjny serwera Weblogic weblogic.security.ssl.enable=true weblogic.system.SSLListenPort=7002 weblogic.httpd.register.authenticated= weblogic.t3.srvr.ClientAuthenticationServlet weblogic.security.certificateCacheSize=3 weblogic.httpd.register.T3AdminCaputreRootCA=admin.T3AdminCaputreRootCA weblogic.security.clientRootCA=SecureServerCA.pem weblogic.security.certificate.server=democert.pem weblogic.security.key.server=demokey.pem weblogic.security.certificate.authority=ca.pem weblogic.httpd.register.Certificate=utils.certificate weblogic.allow.execute.weblogic.servlet.Certificate=system weblogic.httpd.enable=false

Te dwa pliki konfiguracyjne mają całkowicie inną składnię. Choć w róŜnych usługach wykorzystywane będą zazwyczaj róŜne definicje DTD i nazwy elementów, to jednak XML umoŜliwia sformalizowanie i ustandaryzowanie formatowania plików, przyczyniając się do powstania uniwersalnego języka konfiguracyjnego. To są naprawdę dobre wiadomości dla administratorów sieci, systemów i dla programistów. Czytelnik moŜe zauwaŜyć, Ŝe pliki konfiguracyjne juŜ omawialiśmy — dlaczego powracamy do tego tematu? Obecnie kaŜdy serwer posiada lokalny plik (lub pliki) konfiguracyjne. Choć w niektórych serwerach ostatnio umoŜliwia się takŜe odczytywanie konfiguracji poprzez usługi katalogowe, to jednak ta metoda przyswajana jest powoli i wymaga znajomości protokołu usług katalogowych, najczęściej LDAP (Lightweight Directory Access Protocol). Widać coraz silniejszą tendencję tworzenia repozytoriów XML zawierających konfiguracje (rysunek 1.6). Coraz chętniej korzysta się równieŜ z interfejsu Java Naming and Directory Interface™ dla standardu XML (usługa podobna do udostępniania plików). W takiej sytuacji XML moŜe funkcjonować albo oddzielnie od

Dlaczego warto korzystać z technologii XML?

37

usług katalogowych, albo jako abstrakcyjna warstwa „na” usługach katalogowych, pozwalająca aplikacjom posiadającym jedynie parser XML uzyskiwać ustawienia konfiguracyjne. To znacznie prostsze rozwiązanie niŜ udostępnianie serwerom bibliotek LDAP. Ponadto, w miarę wzrostu liczby serwerów poprawnie interpretujących język XML, moŜliwość przechowywania konfiguracji w jednym, centralnym miejscu pozwala zapewnić wzajemną współpracę poszczególnych elementów systemu. Serwery HTTP będą mogły rozpoznawać, jakie mechanizmy serwletów są dostępne, i samodzielnie konfigurować połączenia. Serwery JavaBean mogą odnajdywać usługi katalogowe w sieci i rejestrować tam swoje „fasolki”, a takŜe odkrywać bazy danych, które moŜna wykorzystać do przechowywania obiektów. To tylko niektóre moŜliwości wiąŜące się z wprowadzaniem serwerów sieciowych (korzystających ze wspólnego repozytorium XML) w miejsce serwerów samodzielnych.

Rysunek 1.6. Repozytorium konfiguracji oparte na XML-u

XSP XSP to Extensible Server Pages, czyli rozszerzalne strony serwera. To jeszcze jeden akronim związany z XML-em, którego wprowadzenie moŜe mieć ciekawe konsekwencje dla programowania w Javie. Na razie standard ten ma status projektu roboczego autorstwa Ricardo Rocha i Stefano Mazzocchiego, głównych programistów pracujących nad projektem Apache Cocoon. W czasie pisania tej ksiąŜki projekt nie był jeszcze przyjęty formalnie przez W3C ani inną organizację, ale kiedy ksiąŜka będzie w sprzedaŜy, sytuacja ta moŜe juŜ przedstawiać się inaczej. Mówiąc skrótowo, XSP to zewnętrzny interfejs struktury XML. UmoŜliwia tworzenie dynamicznych stron

Dlaczego warto korzystać z technologii XML?

38

XML przetwarzanych i przekształcanych w ramach struktury. Strony takie umoŜliwiają współpracę pomiędzy aplikacjami. W systemie składowane są jako pliki statyczne. Czytelnicy zaznajomieni z elementami Javy uruchamianymi po stronie serwera zapewne odnoszą wraŜenie, Ŝe jest to coś w rodzaju JSP, a przynajmniej „XML-owej” wersji JSP. To do pewnego stopnia prawda. XSP to interfejs do XML-a; stanowi alternatywny język skryptowy do tworzenia stron i całych serwisów WWW. W wielu aplikacjach biznesowych pisanych w Javie duŜy nacisk kładzie się na odseparowanie zawartości od aplikacji i logiki biznesowej. Podobną rolę spełnia XSP w aplikacjach opartych na XML-u. Choć taką separację warstw w ramach skompilowanego kodu umoŜliwia wiele dostępnych obecnie struktur XML-a, to jednak zmiany w formatowaniu samych danych zawartych w dokumencie XML wymagają zmian w kodzie Javy i rekompilacji. A do tego dochodzą jeszcze zmiany wynikające z prezentacji za pomocą odpowiedniego arkusza stylów XSL. W ramach interfejsu XSP moŜna takŜe zdefiniować proces opisujący transformacje XSLT zachodzące w dokumencie — transformacje zarówno programowe, jak i prezentacyjne. Przyjrzyjmy się przykładowemu dokumentowi XSP (opartemu na przykładzie z projektu roboczego XSP — przykład 1.7).

Przykład 1.7. Prosta strona XSP Prosta strona w XSP

Czołem. Otwarto mnie razy.

W takiej stronie mamy tylko ładnie sformatowany i w prosty sposób weryfikowany język XML. Nie ma w nim logiki programistycznej. Na tym właśnie polega róŜnica pomiędzy językami XSP a JSP — logika i kod programu zdefiniowane są w odpowiednim arkuszu logiki (ang. logicsheet), a nie w samej stronie XSP. Dzięki temu zachowujemy całkowitą niezaleŜność od języka takiej strony oraz abstrakcję konstrukcji specyficznych dla danego języka w ramach arkusza logiki. Transformację znacznika oraz reszty strony moŜe obsługiwać np. arkusz logiki zaprezentowany w przykładzie 1.8.

Przykład 1.8. Arkusz logiki XSP java.lang.* private static int licznik = 0; private synchronized int obecnaLiczba() {

Co dalej?

39 return ++licznik; }

obecnaLiczba()

Nie trzeba chyba szczegółowo wyjaśniać zasady działania powyŜszych przykładów. XSP oferuje pewne nowe konstrukcje, takie jak oraz , ale poza tym dokument wygląda jak standardowy arkusz stylów XSL. Znaczniki XSP są zrozumiałe — pozwalają na wprowadzenie wyniku działania kodu w Javie. Choć interfejs XSP jest obecnie dostępny jedynie jako część projektu Apache Cocoon, to jest to pomysł niezwykle starannie przemyślany. UmoŜliwi oddzielenie aplikacji „rozumiejących” XML od szczegółów prezentacji w sposób bardziej wydajny niŜ do tej pory. Upraszcza takŜe wprowadzanie samego XML-a, tak jak strony JSP zachęcały programistów do poznawania Javy i przechodzenia do bardziej złoŜonych interfejsów. XSP moŜe takŜe przyczynić się do większego upowszechnienia XML-a. Więcej informacji o XSP oraz pełny projekt roboczy tego standardu znaleźć moŜna pod adresem http://xml.apache.org/cocoon/xsp.html.

Co dalej? Po tym niezwykle szybkim omówieniu technologii XML oraz interfejsów API Javy umoŜliwiających jej obsługę gotowi jesteśmy do zagłębienia się w szczegóły. Następne dwa rozdziały poświęcimy omawianiu składni XML-a oraz sposobu korzystania z tego standardu w aplikacjach WWW. To umoŜliwi nam zrozumienie dokumentów XML, jakie będziemy potem tworzyć, formatować i przetwarzać z poziomu naszych aplikacji. W następnym rozdziale szczegółowo opiszemy sposób tworzenia dokumentu XML; powiemy takŜe, co to znaczy, Ŝe dokument XML jest „poprawnie sformatowany”. Zanim zaczniemy, jeszcze jedna istotna uwaga — szczególnie waŜna dla tych, którzy tylko przejrzeli niniejszy rozdział. Technologię XML od samego jej poczęcia otacza atmosfera niezrozumienia i niedoinformowania. Autor niniejszej ksiąŜki zakłada, Ŝe Czytelnik nie miał jeszcze kontaktu z XML-em, a zatem nie jest obciąŜony tego typu uprzedzeniami (szczególnie tym mówiącym, Ŝe XML słuŜy do prezentacji). Nie będziemy omawiali dokumentów XML pod kątem ich prezentacji ani przekształcania informacji — raczej pod kątem sposobu zapisu prostych danych. To charakterystyczne podejście moŜe na początku wydawać się dziwne, poniewaŜ większość osób słysząc „XML” wciąŜ jednak ma na myśli prezentację. Ale jako programiści Javy będziemy traktować dokumenty XML jako dane i nic więcej. Większa część tej ksiąŜki jest poświęcona czynnościom innym niŜ formatowanie dokumentów XML — ich przetwarzaniu i obróbce. Siła XML-a leŜy

Co dalej?

40

w moŜliwości przesyłania danych z systemu do sytemu, aplikacji do aplikacji, firmy do firmy. Pozbycie się błędnych załoŜeń odnośnie XML-a pomoŜe Czytelnikowi czerpać większą przyjemność z czytania tej ksiąŜki, a takŜe umoŜliwi poznanie sposobów zastosowania XML-a, o których być moŜe nawet nie myślał.

Co dalej?

41

Dokument XML

41

2 Tworzenie dokumentów XML Teraz, gdy juŜ wiemy, czym jest XML, do jakich celów moŜe słuŜyć oraz przez jakie interfejsy programowe Javy jest obsługiwany, pora przenieść tę wiedzę na grunt praktyczny. Niniejsza ksiąŜka nie jest w Ŝadnym razie pełnym podręcznikiem składni języka — nie moŜe nawet słuŜyć jako leksykon — nie moŜna jednak omawiać przetwarzania dokumentów XML nie posiadając umiejętności tworzenia. Ponadto stosowanie interfejsów Javy do obsługi XML-a wymaga dość dobrej znajomości składni i struktury tego języka, a takŜe sposobów tworzenia dokumentów, ich zawęŜania i przekształcania. Zanim więc zajmiemy się interfejsami Javy słuŜącymi do obsługi języka XML, zapoznamy się z tymi czynnościami. W niniejszym rozdziale przyjrzymy się składni dokumentów XML. Rozpoczniemy od najbardziej podstawowych konstrukcji i powiemy, co to jest „poprawnie skonstruowany” dokument XML. Opiszemy róŜne zasady tworzenia dokumentów XML oraz pułapki składni. Po lekturze rozdziału Czytelnik będzie potrafił stworzyć dokument nie tylko poprawny, ale takŜe nadający się do praktycznego zastosowania. Wszystko to będzie stanowiło wstęp do napisania pierwszego programu w Javie (w następnym rozdziale) i zrozumienia, na czym polega przetwarzanie kodu XML oraz jak Java odwołuje się do tego procesu. Ci, którzy mieli juŜ kiedyś do czynienia z ksiąŜkami opisującymi składnię języka programowania, zdają sobie sprawę, Ŝe takie opisy bywają dość nudne. My spróbujemy podejść do sprawy nieco inaczej. Zamiast rozpoczynać od jedno- czy dwuwierszowego pliku XML i dodawać do niego kolejne elementy (co kończy się stworzeniem długiego, ale bezuŜytecznego przykładu), rozpoczniemy od pełnego, dość złoŜonego dokumentu XML. Plik, którego uŜyjemy jako przykładu, to fragment rzeczywistego dokumentu XML reprezentującego spis treści tej ksiąŜki. Przyjrzymy mu się wiersz po wierszu i opiszemy poszczególne konstrukcje. Przy omawianiu składni w oparciu o proste przykłady rzadko pamięta się o tym, Ŝe rozwiązania proste stosowane są w rzeczywistych aplikacjach bardzo rzadko. Zamiast tego najczęściej trafiają się złoŜone pliki, niezrozumiałe dla osób „wychowanych” na prostych przykładach. Trzeba zatem przyzwyczaić się do plików XML zawierających wszelkie moŜliwe konstrukcje — i zaczniemy właśnie od takich praktycznych przykładów. MoŜna mieć nadzieję, Ŝe dzięki temu nasze wprowadzenie będzie bliŜsze rzeczywistości. Zanim zaczniemy, jeszcze jedna uwaga. Rozdział ten nie pretenduje do miana materiału referencyjnego. Innymi słowy, nie przedstawiamy poszczególnych pojęć wraz z ich definicjami, nie jest

Dokument XML

42

to teŜ skrótowe wprowadzenie do standardu XML. Będziemy posuwać się kolejnymi krokami naprzód — definicje podawane będą w kontekście przykładów oraz przedstawionych konstrukcji. Warto natomiast podczas lektury mieć pod ręką dobry leksykon XML-a, co pozwoli uniknąć powtarzania przedstawionych tu wiadomości w dalszej części ksiąŜki, omawiającej sprawy bardziej skomplikowane. Dobrym przykładem takiej pozycji jest ksiąŜka Roberta Ecksteina XML. Leksykon kieszonkowy (Helion, Gliwice 2000).

Dokument XML Zgodnie z obietnicą zaczniemy od praktycznego dokumentu XML, stanowiącego fragment spisu treści tej ksiąŜki. Spójrzmy na przykład 2.1.

Przykład 2.1. Plik XML Java i XML Wprowadzenie Co to jest? Jak z tego korzystać? Dlaczego z tego korzystać? Co dalej? Tworzenie dokumentów XML Dokument XML Nagłówek Zawartość Co dalej? Przetwarzanie kodu XML Przygotowujemy się Czytniki SAX Procedury obsługi zawartości Procedury obsługi błędów Lepszy sposób ładowania parsera "Pułapka!" Co dalej?

Nagłówek

43

Struktury publikacji WWW Wybór struktury Instalacja Korzystanie ze struktury publikacji XSP Cocoon 2.0 i dalej Co dalej? &HelionCopyright;

Nagłówek Pierwszy element dokumentu dotyczy samego języka XML. Dokument stworzony w tym języku moŜna podzielić na dwie podstawowe części: nagłówek, który przekazuje parserowi i aplikacjom XML informacje o tym, jak dany dokument ma być obsługiwany, oraz zawartość, czyli same dane XML. Pozwoli nam to odróŜnić treść dokumentu XML od instrukcji przekazywanych aplikacjom z jego wnętrza. Zaczniemy od pierwszych kilku linijek przykładu, do miejsca JavaXML: Ksiazka (bez niego). Te początkowe wiersze to właśnie nagłówek dokumentu. Termin „nagłówek” nie jest formalnym pojęciem zdefiniowanym w specyfikacji XML, ale jest szeroko stosowany. W tej ksiąŜce równieŜ będziemy z niego korzystać.

Instrukcje XML Pierwszym elementem kaŜdego dokumentu XML jest instrukcja XML. Instrukcje języka XML stanowią określony podzbiór instrukcji przetwarzania (PI), o których mówiliśmy w poprzednim rozdziale. Powiedziano tam, Ŝe instrukcje PI są zazwyczaj przekazywane przez parser do aplikacji wywołującej i dopiero tam obsługiwane. Ale instrukcje przetwarzające, w których jako element docelowy podano xml, są przeznaczone dla samego parsera. Określają one rodzaj uŜywanej wersji XML-a, arkusz stylów lub inne informacje potrzebne parserowi do poprawnego przetworzenia danych XML. Oto instrukcja XML:

Podobnie jak wszystkie inne instrukcje PI, ma ona postać i w tym przypadku określa, Ŝe uŜywana wersja standardu XML to 1.0, a dokument nie jest samodzielnym dokumentem XML. ZauwaŜmy, Ŝe instrukcja to niekoniecznie jedna para klucz=wartość; w tym przypadku określamy zarówno wersję dokumentu, jak i to, czy wymaga on jeszcze obecności jakiegoś innego dokumentu lub dokumentów. Kiedy parser „dowiaduje się”, Ŝe dany dokument nie jest samodzielny (ang. standalone), wie, Ŝe do określenia jego poprawności będzie konieczne wykorzystanie zewnętrznej definicji DTD. Gdyby atrybut standalone miał wartość yes, parser nie musiałby odwoływać się do zewnętrznej definicji DTD. W początkowej instrukcji moŜe teŜ znaleźć się deklaracja sposobu kodowania dokumentu. Tutaj, jak równieŜ w przedstawionym powyŜej przykładowym dokumencie XML, tłumacz dodał informację o kodowaniu (encoding="ISO-8859-2") — bez niej w czasie późniejszego przetwarzania dokumentu parser zgłaszałby błędy po napotkaniu znaków spoza standardowego zestawu ASCII (czyli np. polskich liter ą, ć, ś itp.).

Nagłówek

44

Kolejną grupę stanowią instrukcje XML odwołujące się do arkuszy stylów. W naszym przykładzie mamy dwie takie instrukcje:

Zazwyczaj instrukcja PI rozpoczynająca się od xml-[nazwa] odwołuje się do technologii związanej z XML-em i określonej w części [nazwa]. W tym przypadku chodzi o arkusz stylów, toteŜ instrukcja przekazywana jest do mechanizmu XSLT, a nie do parsera XML-a. W pierwszym wierszu odwołujemy się do domyślnego arkusza stylów, podając jego połoŜenie i typ. W wierszu drugim widzimy odwołanie do alternatywnego arkusza stylów. W tym przypadku podano takŜe atrybut media, który informuje procesor, dla jakiego rodzaju klientów jest przeznaczony dany arkusz. Mechanizmy publikacji omówimy w rozdziale 9., Systemy publikacji WWW.

Deklaracje typu dokumentu Po początkowych instrukcjach XML następuje deklaracja DOCTYPE. Deklaracja ta dysponuje własną, odrębną składnią, poniewaŜ jest wykorzystywana tylko do jednego celu — określenia definicji DTD wykorzystywanej w danym dokumencie XML. Spójrzmy jeszcze raz na deklarację DOCTYPE w naszym przykładzie:

W tym przykładzie definicją DTD dla dokumentu jest plik JavaXML.dtd, znajdujący się w lokalnym systemie plików. Parsery XML zazwyczaj dopuszczają stosowanie zwykłego lub lewego ukośnika (odpowiednio, dla systemów Unix i Windows), co pozwala uzyskać przenośność ścieŜek dostępu pomiędzy róŜnymi platformami. Pierwszym parametrem deklaracji DOCTYPE jest element główny dokumentu, o którym powiemy za chwilę — tymczasem wystarczy informacja, Ŝe określa on bieŜący dokument XML. Następnym argumentem jest albo słowo SYSTEM, albo PUBLIC. PoniewaŜ wpisaliśmy SYSTEM, parser XML będzie oczekiwał, Ŝe w następnym argumencie znajdzie się połoŜenie pliku DTD, określone za pomocą jednolitego identyfikatora zasobów (URI). Słowo SYSTEM nie oznacza jednak, Ŝe plik DTD musi się koniecznie znajdować w systemie lokalnym. MoŜna teŜ uŜyć następującego zapisu:

Specyfikacja XML pozwala umieścić w tym miejscu dowolny poprawny identyfikator URI, a więc adres URL jest do przyjęcia. UŜycie słowa PUBLIC oznacza, Ŝe definicja DTD, do której się odwołujemy, jest upubliczniona i mogą z niej korzystać wszyscy. W tym przypadku przed podaniem URI konieczne jest określenie nazwy publicznej. PoniŜszą deklarację moŜna znaleźć na początku niektórych plików HTML, takich jak strona główna konsorcjum W3C, dostępna pod adresem http://www.w3c.org/:

Po słowie kluczowym PUBLIC następuje nazwa określająca publiczną definicję DTD wykorzystywaną w danym dokumencie. Parser XML najpierw stara się zlokalizować definicję DTD za pomocą jej nazwy, a dopiero kiedy to się nie uda — za pomocą dodatkowo podanego identyfikatora URI. Składnia nazwy publicznej definicji DTD jest szczegółowo opisana w specyfikacji XML, ale to na razie nie będzie nas interesować. Definicjom DTD i ich formatowi przyjrzymy się w rozdziale 4., ZawęŜanie XML.

Zawartość dokumentu

45

Zawartość dokumentu Skoro nagłówek mamy juŜ za sobą, moŜemy przejść do zawartości dokumentu XML. Składają się na nią elementy, atrybuty i opisywane przez nie dane tekstowe.

Element główny Element główny (ang. root element) to najwyŜszy w hierarchii element dokumentu XML. Jego definicję stanowią zawsze pierwszy znacznik otwierający i ostatni znacznik zamykający w dokumencie. Element ten stanowi punkt wyjścia dla parsera lub aplikacji XML, umoŜliwiając im rozpoznanie początku i końca dokumentu. W naszym przykładzie elementem głównym jest :

Znacznik ten, w połączeniu z odpowiadającym mu znacznikiem zamykającym, otacza całą pozostałą zawartość dokumentu XML. Specyfikacja XML zezwala na obecność tylko jednego elementu głównego w dokumencie. Innymi słowy, element taki musi „obejmować” wszystkie inne elementy. Poza tym jednym wymogiem element główny nie róŜni się od innych elementów XML. Warto o tym pamiętać, poniewaŜ dokumenty XML mogą zawierać inne dokumenty XML lub odwoływać się do nich. W takich przypadkach element główny dokumentu, do którego się odwołujemy, staje się elementem wewnętrznym dokumentu, z którego nastąpiło odwołanie i musi zostać normalnie obsłuŜony przez parser XML. Dzięki temu, Ŝe elementy główne zdefiniowano jako standardowe elementy XML (nie posiadające specjalnych właściwości czy zachowań), dołączanie innych dokumentów XML przebiega bezproblemowo.

Identyfikacja elementów za pomocą przestrzeni nazw Nie będziemy tutaj zbytnio zagłębiać się w temat przestrzeni nazw, ale wypada zdawać sobie sprawę ze sposobu ich uŜycia w elemencie głównym. Jak moŜna było zauwaŜyć, wszystkie nazwy elementów XML mają przedrostek JavaXML. Być moŜe później zajdzie potrzeba dołączenia do przykładowego dokumentu fragmentów innych ksiąŜek wydawnictwa O’Reilly. PoniewaŜ kaŜda z nich moŜe takŜe posiadać znaczniki , lub , dokument musi zostać skonstruowany tak, aby wyeliminować moŜliwość kolizji przestrzeni nazw z innymi dokumentami. Specyfikacja przestrzeni nazw w języku XML rozwiązuje ten problem w bardzo prosty sposób. PoniewaŜ nasz dokument odpowiada konkretnej ksiąŜce, której nie będzie odpowiadał Ŝaden inny dokument XML, moŜna uŜyć przedrostka w rodzaju JavaXML, powodującego przypisanie elementu do danej przestrzeni nazw. Specyfikacja przestrzeni nazw wymaga przypisania danemu przedrostkowi niepowtarzalnego identyfikatora URI, tak aby moŜliwe było odróŜnienie elementów w danej przestrzeni nazw od elementów w innych przestrzeniach. Zaleca się uŜycie do tego celu adresu URL i tak właśnie robimy w naszym przykładzie (http://www.oreilly.com/ catalog/javaxml — strona WWW tej ksiąŜki):

Do zdefiniowanej w ten sposób przestrzeni nazw moŜna odwoływać się z dowolnego elementu w danym dokumencie XML. W naszym przypadku przestrzeń wykorzystujemy we wszystkich elementach, wszystkie bowiem do niej naleŜą. Poprawnym sposobem związania elementu z prze-

Zawartość dokumentu

46

strzenią nazw jest podanie jej identyfikatora jako przedrostka oddzielonego dwukropkiem od właściwej nazwy elementu: Wprowadzenie Co to jest? Jak z tego korzystać? Dlaczego z tego korzystać? Co dalej?

KaŜdy z tych elementów jest traktowany przez parser XML jako część przestrzeni nazw http:// www.oreilly.com/catalog/javaxml/, dzięki czemu nie wystąpią kolizje z innymi elementami o nazwach Rozdzial, Naglowek czy Temat, zawartymi w innych przestrzeniach nazw. W tym samym dokumencie moŜna umieszczać wiele deklaracji przestrzeni nazw — wszystkie za pomocą jednego elementu:

PowyŜsza deklaracja jest poprawna, jednak przy wykorzystywaniu wielu przestrzeni nazw w jednym dokumencie trzeba zachować duŜą ostroŜność. Często korzyści z takiego rozwiązania mogą zostać zniwelowane przez komplikację i konieczność umieszczania dodatkowego tekstu w dokumencie. Zazwyczaj pojedyncza przestrzeń nazw umoŜliwia stworzenie jednego, „czystego” dokumentu XML z jednoczesnym uniknięciem kolizji; jedynym istotnym wyjątkiem jest przypadek, gdy wykorzystywana jest inna specyfikacja XML (np. XML Schema) i gdy trzeba dla niej uŜyć osobnej przestrzeni nazw. Na koniec jeszcze jedno interesujące (i moŜe nieco skomplikowane) zagadnienie. Specyfikacja XML Schema, dokładniej omówiona w rozdziale 4., wymaga określenia schematu dokumentu XML w sposób bardzo przypominający zestaw deklaracji przestrzeni nazw (przykład 2.2).

Przykład 2.2. Dokument XML wykorzystujący specyfikację XML Schema Brett McLaughlin [email protected] Maciej Abacki [email protected]

Wystąpiło tutaj kilka zjawisk, które naleŜy dobrze zrozumieć. Po pierwsze, dla danego egzemplarza (ang. instance) schematu XML (XML Schema) definiowana jest — i kojarzona z określonym identyfikatorem URI — przestrzeń nazw. Przestrzeń ta, o skrótowej nazwie xsi, słuŜy do poda-

Zawartość dokumentu

47

wania w dokumencie XML informacji o danym schemacie — dokładnie tak, jak robimy to tutaj. Dlatego w pierwszym wierszu udostępniamy elementy naszego egzemplarza schematu XML do wykorzystania w całym dokumencie. W następnym wierszu definiujemy przestrzeń nazw samego dokumentu XML. PoniewaŜ nie są w nim wykorzystywane Ŝadne jawne przestrzenie nazw (inaczej niŜ w poprzednim przykładzie), deklarujemy domyślną przestrzeń nazw. Specyfikacja przestrzeni nazw XML mówi, Ŝe kaŜdy element dokumentu XML musi naleŜeć do jakiejś przestrzeni nazw; domyślna przestrzeń nazw to ta, z którą skojarzony jest element w przypadku, gdy nie podano Ŝadnej innej przestrzeni. Oznacza to, Ŝe wszystkie elementy bez przedrostka przestrzeni nazw (czyli w tym przykładzie wszystkie) kojarzone są z tą właśnie przestrzenią domyślną. Przy takim zdefiniowaniu przestrzeni nazw dokumentu oraz schematu XML moŜemy juŜ zrobić to, co chcieliśmy, czyli skojarzyć schemat z dokumentem. SłuŜy do tego atrybut schemaLocation, naleŜący do przestrzeni nazw XML Schema. Przed tym atrybutem stawiamy jego przestrzeń nazw (xsi), którą przed chwilą zdefiniowaliśmy. Argument atrybutu składa się właściwie z dwóch identyfikatorów URI: pierwszy określa przestrzeń nazw skojarzoną ze schematem, a drugi jest identyfikatorem schematu, do którego się odwołujemy. W naszym przykładzie pierwszy identyfikator to domyślna przestrzeń nazw, którą właśnie zadeklarowaliśmy, a drugi to plik mySchema.xsd w lokalnym systemie plików. Jak kaŜdy inny atrybut XML, para ta umieszczana jest wewnątrz cudzysłowów. I oto mamy w dokumencie odwołanie do schematu! Mówiąc powaŜniej, zagadnienie to nie jest takie proste i wciąŜ stanowi jeden z najtrudniejszych dla uŜytkowników aspektów uŜywania przestrzeni nazw i schematu XML. Do całego opisanego wyŜej mechanizmu wrócimy wkrótce, na razie zaś wystarczy zrozumieć, Ŝe przestrzenie nazw umoŜliwiają wykorzystanie elementów z róŜnych grup, przy czym elementy te cały czas pozostają nieodłącznym fragmentem grup, z których pochodzą.

Elementy danych Do tej pory unikaliśmy definiowania pojęcia „element”. Teraz nadeszła pora, aby wyjaśnić je dokładnie. Element opatrzony jest dowolną nazwą i musi zawierać się w nawiasach kątowych. W naszym przykładowym dokumencie obecne są elementy róŜnego rodzaju: Struktury publikacji WWW

Pierwsza zasada tworzenia elementów mówi, Ŝe nazwa elementu musi rozpoczynać się literą lub podkreśleniem, po którym moŜe wystąpić dowolna liczba liter, cyfr, podkreśleń, łączników lub kropek. Nazwy nie mogą zawierać spacji — poniŜszy przykład nie jest poprawnym elementem XML:

Zawartość dokumentu

48

W nazwach elementów XML rozróŜniana jest wielkość liter. Mówiąc ogólnie, zastosowanie tych samych zasad, których uŜywa się przy tworzeniu nazw zmiennych Javy, pozwala uzyskać poprawne nazwy elementów XML. Nie powinno się skracać nazw typu „Obiekt telekomunikacyjny” do postaci (bo staną się niezrozumiałe), z drugiej strony nie powinno się teŜ stosować elementów typu , bo niepotrzebnie zaśmiecają dokument. Warto pamiętać, Ŝe dokumenty XML będą najprawdopodobniej oglądane przez innych programistów, a więc dobrze jest uŜywać znaczących, „samodokumentujących się” nazw. KaŜdy otwarty element musi zostać zamknięty. I nie ma tutaj wyjątków, tak jak to jest w innych językach znaczników, np. w HTML-u. Znacznik końcowy składa się z ukośnika i nazwy elementu, np. . Pomiędzy znacznikiem otwierającym a zamykającym moŜe znajdować się dowolna ilość danych tekstowych lub innych elementów. Nie moŜna jednak zmieniać kolejności zagnieŜdŜania — pierwszy otwarty element musi zostać zamknięty jako ostatni. Jeśli któraś z tych zasad nie zostanie spełniona, dokument XML będzie niepoprawnie skonstruowany. Poprawnie skonstruowany (ang. well-formed) dokument to taki, w którym przestrzega się zasad składni języka XML, a wszystkie elementy i atrybuty znajdują się we właściwych miejscach. JednakŜe poprawnie skonstruowany dokument niekoniecznie musi być poprawny (ang. valid), tzn. nie musi być zgodny z ograniczeniami narzuconymi przez DTD lub schemat. Pomiędzy dokumentem poprawnie skonstruowanym a poprawnym jest duŜa róŜnica; w tym rozdziale zajmujemy się tylko poprawnością konstrukcji, natomiast reguły określające poprawność dokumentu przedstawimy w rozdziale 4. Oto przykład dokumentu niepoprawnie skonstruowanego:

Kolejność zagnieŜdŜania nie jest prawidłowa, poniewaŜ po znaczniku otwierającym nie znajduje się znacznik zamykający . Ale po poprawieniu tego błędu składniowego nie moŜemy jeszcze być pewni, Ŝe cały dokument jest poprawny. To istotna róŜnica, do której wrócimy w rozdziale 4. PowyŜszy przykład niepoprawnie sformatowanego dokumentu moŜe się wydawać banalny, ale z drugiej strony warto zauwaŜyć, Ŝe w HTML-u byłby to zapis poprawny — i często pojawia się w duŜych tabelach wewnątrz dokumentów zapisanych w tym języku. Innymi słowy, HTML i wiele innych języków znaczników nie wymaga tworzenia poprawnie sformatowanych dokumentów w takim sensie, w jakim jest to rozumiane w definicji XML. Ścisłe przestrzeganie zasad zagnieŜdŜania obowiązujących w XML-u umoŜliwia duŜo szybsze przetwarzanie i sprawniejszą obsługę zapisanych w nim dokumentów. Ostatnia zasada, jaką omówimy, dotyczy dość oryginalnych elementów pustych. Powiedzieliśmy juŜ, Ŝe znaczniki XML muszą występować parami; na kompletny element XML składają się znaczniki otwierający i zamykający. Są jednak przypadki, w których element występuje w dokumencie samodzielnie, informując np. o tym, Ŝe rozdział nie jest ukończony; są teŜ elementy posiadające atrybuty, ale nie zawierające danych tekstowych — np. obrazek w HTML-u. Elementy takie naleŜałoby zapisywać w następujący sposób:

Zawartość dokumentu

49

Zapis ten jest niezbyt rozsądny i powoduje zwiększenie bałaganu w dokumencie. Specyfikacja XML dopuszcza jego uproszczenie poprzez zawarcie znacznika otwierającego i zamykającego w jednym elemencie:

Rozwiązuje to problem elegancji zapisu, a jednocześnie nie narusza zasady, Ŝe kaŜdy element XML musi mieć odpowiednik zamykający — tutaj jeden element jest jednocześnie otwierającym i zamykającym.

Atrybuty elementów Oprócz tekstu zawartego pomiędzy znacznikami, element moŜe takŜe posiadać atrybuty. Atrybuty, wraz z odpowiadającymi im wartościami, zawarte są w deklaracji otwierającej elementu (która moŜe być takŜe deklaracją zamykającą!). Np. częścią znacznika JavaXML:Rozdzial był atrybut określający tematykę rozdziału:

W powyŜszym przykładzie tematyka to nazwa atrybutu, a jego wartościami są, odpowiednio, XML i Java. Nazwy atrybutów podlegają takim samym zasadom jak nazwy elementów XML, a ich wartości muszą znajdować się w cudzysłowach. Dopuszczalne są tu równieŜ apostrofy, ale standardowo uŜywa się cudzysłowów — odpowiada to zresztą konwencji przyjętej w Javie. Apostrofy i cudzysłowy moŜna takŜe wykorzystywać wewnątrz wartości atrybutu — jeśli znajduje się ona w cudzysłowach, to wewnątrz moŜna uŜyć apostrofów, i odwrotnie. Nie jest to jednak metoda zalecana, jako Ŝe parsery i procesory XML często automatycznie przekształcają wszystkie cudzysłowy otaczające wartości atrybutów na apostrofy (lub odwrotnie), co moŜe spowodować nieprzewidywalne skutki. WaŜne jest nie tylko to, jak naleŜy uŜywać atrybutów, ale takŜe gdzie ich uŜywać. XML umoŜliwia tak rozmaite formatowanie danych, Ŝe rzadko kiedy nie jest moŜliwe wyraŜenie atrybutu przez element, lub odwrotnie — elementu przez atrybut. Nie istnieje Ŝadna specyfikacja ani ogólnie przyjęty standard mówiący o tym, kiedy uŜywać atrybutu, a kiedy elementu, ale moŜna tutaj podać pewną radę praktyczną: elementów uŜywa się do opisywania danych przeznaczonych do prezentacji, a atrybutów — do opisywania danych systemowych. Dane, które mają zostać przedstawione klientowi albo aplikacji, najprawdopodobniej zostaną opisane za pomocą elementu. Mogą one być później traktowane jako dane aplikacji, które moŜna w prosty sposób przeszukiwać i wykorzystywać. Jako przykład moŜe tu posłuŜyć tytuł rozdziału ksiąŜki, cena mebla czy adres URL firmowej witryny WWW. Jeśli jednak dane słuŜą do grupowania lub za ich pomocą przekazujemy aplikacji informację o sposobie obsłuŜenia innej porcji danych, czy teŜ wreszcie nie są bezpośrednio widziane przez klienta lub aplikację XML-ową, najprawdopodobniej będą miały postać atrybutu. Przykładami „dobrych kandydatów” na atrybuty mogą być części ksiąŜki — sama część moŜe być elementem posiadającym własny tytuł, ale grupowanie znajdujących się w niej rozdziałów da się w prosty sposób opisać atrybutem czesc w elemencie JavaXML:Rozdzial. Atrybut taki umoŜliwia proste indeksowanie części, ale nie będzie prezentowany bezpośrednio uŜytkownikowi. Innym dobrym przykładem jest sytuacja, w której klient zapłacił zadatek za dany

Zawartość dokumentu

50

towar (np. krzesło czy stół), „rezerwując” go w ten sposób dla siebie. Poinformowana o tym aplikacja XML mogłaby wygenerować broszurę lub ulotkę, w której taki towar nie byłby juŜ zawarty. I znów — klient nie widziałby bezpośrednio tej informacji, ale dane zostałyby wykorzystane przy obsłudze i przetwarzaniu dokumentu XML. Jeśli po tym wszystkim nadal jeszcze nie wiadomo, czego uŜyć, zawsze moŜna postąpić asekuracyjnie i zastosować element. MoŜna teŜ wyobrazić sobie inne sposoby reprezentacji przedstawionych przykładów. Zamiast np. korzystać z atrybutu opisującego część, moŜna zagnieździć elementy JavaXML:Rozdzial w elemencie JavaXML:czesc; w drugim przykładzie uŜycie pustego znacznika pozwoliłoby na sprawniejsze oznakowanie „zarezerwowanych” mebli. W języku XML rzadko mamy do czynienia z jednym tylko sposobem reprezentowania danych. Najczęściej to aplikacja i sposób wykorzystania danych determinują sposób postępowania. Nie będziemy więc pisać o tworzeniu zapisów w XML-u (byłoby to trudne), ale o ich uŜywaniu — i właśnie przez praktyczne uŜywanie Czytelnik będzie mógł poznać sposoby obsługi i uŜycia róŜnych reprezentacji danych. Ta wiedza umoŜliwia Czytelnikowi samodzielne podejmowanie decyzji o sposobie formatowania dokumentów XML.

„Stałe” języka XML Nie wspomnieliśmy jeszcze o sekwencjach unikowych i odwoływaniu się do innych, stałych wartości. Dla przykładu, typową reprezentacją ścieŜki do katalogu instalacyjnego jest zapis lub . W obu przypadkach tekst taki zostałby zamieniony przez uŜytkownika na nazwę wybranego katalogu instalacyjnego. W rozdziale opisującym aplikacje WWW jest przedstawiony przykład, w którym konieczne jest podanie szczegółowych informacji o instalacji i sposobie korzystania z aplikacji Apache Cocoon. MoŜe zatem zajść potrzeba uŜycia takiej reprezentacji danych w elemencie: Instalacja Cocoon Plik Cocoon.properties znajduje się w katalogu /bin.

Kłopot polega na tym, iŜ parser XML spróbuje obsłuŜyć takie dane jako znacznik XML i zakomunikuje o błędzie, poniewaŜ nie znajdzie znacznika zamykającego. Jest to typowy problem związany z kaŜdą sytuacją, w której konieczne jest zastosowanie nawiasów kątowych. MoŜna go rozwiązać za pomocą encji (ang. entity reference). Encja to specjalny typ danych XML słuŜący do odwoływania się do innych rodzajów danych. Składa się ona z niepowtarzalnej nazwy poprzedzonej znakiem ampersand (&) i zakończonej średnikiem, tj. &[nazwa-encji];. Po napotkaniu encji parser XML podstawia pod nią odpowiednią wartość i nie przetwarza jej dalej. W języku XML zdefiniowano pięć encji, które pomogą rozwiązać powyŜszy problem: < to otwierający nawias kątowy (lub symbol „mniejsze niŜ”), > to zamykający nawias kątowy (lub symbol „większe niŜ”), & to sam znak ampersand, " to cudzysłów, a ' — apostrof. Za pomocą tego rodzaju encji moŜemy przedstawić odwołanie do katalogu instalacyjnego w następujący sposób: Instalacja Cocoon Plik Cocoon.properties znajduje się w katalogu /bin.

Co dalej?

51

Po przetworzeniu tego dokumentu pogrubiony zapis zostanie zinterpretowany jako i dokument zostanie zaakceptowany jako poprawnie sformatowany. NaleŜy takŜe pamiętać, Ŝe encje mogą być definiowane przez uŜytkownika, co pozwala tworzyć swoiste zapisy skrótowe. W przedstawionym na początku rozdziału dokumencie XML znajduje się odwołanie do zewnętrznego, współuŜytkowanego tekstu noty o prawach autorskich. PoniewaŜ ten sam dokument wykorzystywany jest w wielu ksiąŜkach wydawnictwa, nie chcemy zamieszczać go w całości w dokumencie XML. Jeśli jednak prawa autorskie ulegną zmianie, nasz dokument powinien te zmiany odzwierciedlić. Być moŜe Czytelnik zauwaŜył, Ŝe składnia wykorzystana w przykładowym dokumencie XML wygląda jak predefiniowana encja: &HelionCopyright;

Co prawda dopiero w części omawiającej definicje DTD wyjaśnimy, w jaki sposób XML ustala, do czego ma się odwołać po napotkaniu encji &HelionCopyright;, ale juŜ teraz naleŜy zauwaŜyć, Ŝe encje słuŜą do wielu innych zadań, nie tylko do reprezentowania nietypowych znaków w danych.

Dane nieprzetwarzane Ostatnia konstrukcja XML, jaką omówimy, to sekcja CDATA. Stosowana jest ona wtedy, gdy do aplikacji wywołującej trzeba przekazać duŜą ilość danych nieprzetworzonych przez parser XML. Z tego sposobu moŜna skorzystać wtedy, gdy dane zawierają wiele nietypowych znaków, których znaczenie naleŜałoby znosić za pomocą encji, albo teŜ gdy zaleŜy nam na utrzymaniu układu tekstu. W dokumencie XML sekcja CDATA wygląda następująco: Zainstaluj Cocoon do "/usr/lib/cocoon" Znajdź odpowiedni plik properties. Pobierz program Ant z adresu "http://jakarta.apache.org" -----> skorzystaj z CVS <----]]>

W tym przykładzie zawartość sekcji CDATA nie musi być kodowana za pomocą encji lub innych mechanizmów nakazujących parserowi specjalne postępowanie z nietypowymi znakami — przekaŜe on je w niezmienionej postaci do aplikacji. Poznaliśmy juŜ najwaŜniejsze składniki dokumentów XML. KaŜdy z nich został omówiony niejako „przy okazji”, ale juŜ teraz Czytelnik powinien potrafić rozpoznać znaczniki XML i ich przeznaczenie. W następnych rozdziałach ksiąŜki poznamy kolejne właściwości tych konstrukcji, wykonując ćwiczenia praktyczne — ta metoda nauki jest najlepsza.

Co dalej? Po tym wstępie do tworzenia dokumentów XML moŜemy rozpocząć pisanie pierwszego programu w Javie. W następnym rozdziale przyjrzymy się prostemu interfejsowi Simple API for XML (SAX). Zaczniemy od przetworzenia naszego dokumentu za pomocą prostego programu, a następnie poznamy sposoby obsługi instrukcji przetwarzania, elementów, atrybutów i innych konstrukcji języka XML w procesie przetwarzania dokumentu. Autor zaprezentuje kod napisany w Javie wykonujący poszczególne czynności, zaczynając od prostego programu drukującego dokument XML. W kolejnym rozdziale rozpocznie się intensywny proces nauki manipulowania składnikami dokumentu XML oraz ich stosowania w aplikacjach Javy.

Co dalej?

52

Przygotowujemy się

53

3 Przetwarzanie kodu XML Dwa rozdziały solidnego wprowadzenia za nami. MoŜemy rozpocząć kodowanie! Poznaliśmy juŜ wszystkie akronimy składające się na świat XML-a, zagłębiliśmy się w sam język XML i poznaliśmy jego strukturę. W tym rozdziale rozpoczniemy programowanie w Javie od przetworzenia dokumentu XML i uzyskania dostępu do przetworzonych danych z poziomu kodu w Javie. Najpierw będziemy musieli pobrać i przetworzyć dokument. W czasie przetwarzania dokumentu staje się on dostępny dla aplikacji wykorzystującej parser. To właśnie jest aplikacja „obsługująca XML” (w angielskim uŜywa się określenia XML-aware, czyli „wiedząca o XML-u”). To wszystko wydaje się zbyt proste, Ŝeby było prawdziwe — ale tak właśnie jest. W tym rozdziale poznamy szczegóły dotyczące przetwarzania dokumentu XML. Omówimy sposoby korzystania z parsera wewnątrz aplikacji i przekazywania parserowi danych. Potem omówimy wywołania wsteczne dostępne w czasie przetwarzania. Są to miejsca, w których moŜliwe jest wstawienie kodu specyficznego dla aplikacji i w których moŜe nastąpić obróbka danych. Oprócz omówienia sposobu pracy parserów, poznamy równieŜ interfejs Simple API for XML (SAX). To właśnie SAX udostępnia wywołania wsteczne. Interfejsy dostępne w pakiecie SAX staną się istotnym elementem naszego warsztatu. Klasy SAX są niewielkie i nieliczne, ale w całym naszym omówieniu XML-a będziemy się opierali właśnie na tych klasach. Dobre zrozumienie ich działania jest niezbędne do sprawnego korzystania z XML-a w programach Javy.

Przygotowujemy się Są pewne rzeczy, które naleŜy przygotować jeszcze przed rozpoczęciem programowania. Po pierwsze, trzeba zaopatrzyć się w parser XML. Napisanie parsera XML to ogromne zadanie; istnieje kilka doskonałych projektów zmierzających do zbudowania takiego parsera. Nie będziemy opisywali tutaj, jak pisze się parsery XML, ale w jaki sposób aplikacje korzystają z funkcji udostępnianych przez te parsery. Do manipulacji danymi XML wykorzystamy istniejące narzędzia. Po wybraniu parsera musimy zaopatrzyć się w klasy SAX. Nie jest trudno je znaleźć; klasy te są warunkiem przetwarzania XML-a z poziomu Javy. Oczywiście potrzebny jest równieŜ dokument XML do przetworzenia.

Przygotowujemy się

54

Zaopatrujemy się w parser Najpierw naleŜy zaopatrzyć się w odpowiedni parser (rodzaje parserów zostały pokrótce przedstawione w rozdziale 1.). Aby parser działał ze wszystkimi przykładami z ksiąŜki, naleŜy sprawdzić, czy jest zgodny ze specyfikacją XML. PoniewaŜ dostępnych jest wiele parserów, a w środowisku programistów XML następują gwałtowne zmiany, opisanie poziomu zgodności róŜnych parserów ze specyfikacją wykracza poza moŜliwości tej ksiąŜki. Powinniśmy zasięgnąć informacji na stronie producenta parsera i odwiedzić wymienione wcześniej witryny. Zgodnie z duchem społeczności wolnego oprogramowania (open source), we wszystkich przykładach tej ksiąŜki wykorzystany zostanie parser Apache Xerces. Jest on dostępny w postaci źródłowej i binarnej pod adresem http://xml.apache.org. Parser ten został napisany w C i w Javie i jest uŜywany przez liczną grupę programistów. Poza tym, jeśli korzystamy z parsera objętego zasadą wolnego oprogramowania, mamy moŜliwość wysłania autorom pytań lub powiadomień o błędach — to przyczynia się do podwyŜszania jakości produktu. Aby zapisać się na ogólną listę adresową dotyczącą parsera Xerces, wystarczy wysłać pusty e-mail pod adres [email protected]. Tam uzyskamy odpowiedzi na pytania dotyczące samego parsera oraz uzyskamy pomoc w przypadku wystąpienia problemów nie ujętych w tej ksiąŜce. Oczywiście, przykłady z ksiąŜki będą poprawnie obsłuŜone przez dowolny parser wykorzystujący opisywaną tutaj implementację SAX. Po dokonaniu wyboru i pobraniu parsera XML naleŜy upewnić się, Ŝe nasze środowisko programistyczne — czy to IDE (Integrated Development Environment), czy wiersz poleceń — ma dostęp do parsera poprzez ścieŜkę klas. To podstawowy wymóg działania wszystkich dalszych przykładów.

Zaopatrujemy się w klasy i interfejsy SAX Po zdobyciu parsera musimy zaopatrzyć się w klasy SAX. Klasy te są niemal zawsze dołączone do parserów i Xerces nie stanowi tutaj wyjątku. Jeśli tak właśnie jest w naszym przypadku, nie powinniśmy pobierać klas oddzielnie, poniewaŜ parser na pewno wyposaŜony jest w najświeŜszą obsługiwaną wersję klas. W czasie pisania tej ksiąŜki zkończono prace nad SAX 2.0. Właśnie z klas w tej wersji korzystamy w niniejszej ksiąŜce i powinna być w nie wyposaŜona najświeŜsza wersja Apache Xerces. Jeśli nie jesteśmy pewni, czy posiadamy klasy SAX, wystarczy spojrzeć na plik jar lub strukturę klas wykorzystywaną przez parser. Klasy SAX znajdują się w pakietach struktury org.xml.sax. NajświeŜsza wersja zawiera w katalogu głównym 17 klas oraz 9 klas org.xml.sax.helpers i 2 klasy org.xml.sax.ext. Jeśli brakuje którejś z tych klas, trzeba skontaktować się z producentem i sprawdzić, czy zostały one zawarte w dystrybucji. Niektóre mogą być pominięte, jeśli nie są w całości obsługiwane1. Tyle samo klas istnieje w interfejsie SAX 2.0; mniej klas pojawi się w tych katalogach, gdy obsługiwany jest tylko SAX 1.0. Warto takŜe pobrać albo zaznaczyć zakładką przeglądarki dokumenty SAX API Javadoc na stronach WWW. Dokumentacja ta bardzo przydaje się podczas korzystania z klas SAX, a struktura Javadoc zapewnia standardowy i prosty sposób znajdowania dodatkowych informacji o klasach.

1

Obsługa klas SAX w całości jest bardzo istotną cechą parsera. Oczywiście, moŜna korzystać z dowolnego parsera, ale jeśli nie obsługuje on w całości SAX 2.0, wiele przykładów z ksiąŜki nie będzie działało. Ponadto oznacza to, Ŝe parser nie uwzględnia nowości w technologii XML. Bez względu na powód, warto zapoznać się z parserem Xerces.

Czytniki SAX

55

Dokumentacja mieści się pod adresem http://www.megginson.com/SAX/SAX2/javadoc/index.html. Dokumentację Javadoc moŜna takŜe wygenerować ze źródeł SAX-a poprzez kod zawarty w parserze lub poprzez pobranie pełnych źródeł z adresu http://www.megginson.com/SAX/SAX2.

Przygotowujemy dokument XML Zawsze naleŜy mieć pod ręką dokument XML do przetworzenia. Dane uzyskiwane w przykładach wynikają z uŜycia dokumentu opisanego w rozdziale 2. Dokument ten naleŜy zachować jako plik contents.xml na dysku lokalnym. Zalecamy pracę właśnie na tym pliku. MoŜna wpisać go ręcznie albo pobrać ze strony WWW tej ksiąŜki, http://www.oreilly.com/catalog/javaxml. Warto jednak poświęcić chwilę czasu i wpisać go ręcznie, gdyŜ jest to praktyczna nauka składni XML-a. Oprócz pobrania lub stworzenia pliku XML, będziemy musieli poczynić w nim kilka niewielkich zmian. PoniewaŜ nie zostały jeszcze podane informacje o sposobie zawęŜania i przekształcania dokumentu, w tym rozdziale nasze programy będą wyłącznie przetwarzały („parsowały”) dokument. Aby zapobiec błędom, trzeba usunąć z dokumentu odwołania do zewnętrznej definicji DTD zawęŜającej XML oraz do arkuszy XSL powodujących jego przekształcenie. Wystarczy opatrzyć komentarzami te dwa wiersze dokumentu XML oraz instrukcję przetwarzania wysyłaną do modułu Cocoon i Ŝądającą przekształcenia:

Po opatrzeniu tych wierszy komentarzami naleŜy zanotować pełną ścieŜkę dostępu do dokumentu XML. Trzeba ją będzie przekazać programom w tym i w dalszych rozdziałach. Na koniec naleŜy opatrzyć komentarzami odwołanie do zewnętrznej encji OReillyCopyright, poniewaŜ powodowałaby ona ładowanie pliku z informacjami o prawach autorskich. Nie posiadając definicji DTD opisującej sposób przetworzenia tej encji, otrzymalibyśmy błędy. W następnym rozdziale zostanie przedstawione zastosowanie tej encji.

Czytniki SAX Po informacjach wstępnych czas przejść do programowania. Nasz pierwszy program pobierze plik jako argument wiersza poleceń i przetworzy go. Zbudujemy wywołania wsteczne do procesu przetwarzania, dzięki czemu zdarzenia zachodzące w czasie tego procesu będą wyświetlane i umoŜliwią lepszą obserwację całego mechanizmu.

Czytniki SAX

56

Najpierw naleŜy uzyskać egzemplarz (ang. instance) klasy zgodny z interfejsem SAX org.xml. sax.XMLReader. Interfejs ten definiuje sposób przetwarzania i pozwala na ustawienie funkcji i właściwości, które zostaną omówione w rozdziale 5., Sprawdzanie poprawności składni XML-a. Informacja dla osób znających juŜ SAX 1.0 — interfejs ten zastępuje dotychczasowy org.xml. sax.Parser.

Instalacja czytnika Interfejs udostępniany przez SAX powinien być zaimplementowany we wszystkich parserach XML zgodnych z SAX-em. Dzięki temu SAX wie, jakie metody dostępne są dla wywołań wstecznych i jakie moŜna uŜyć z poziomu aplikacji. Na przykład główna klasa parsera SAX w Xerces, org.apache.xerces.parsers.SAXParser, implementuje interfejs org.xml.sax.XMLReader. Jeśli mamy dostęp do źródeł parsera, to zobaczymy, Ŝe ten sam interfejs zaimplementowano w głównej klasie parsera SAX. KaŜdy parser musi posiadać jedną (a czasem więcej) klas, które implementują ten interfejs. I właśnie egzemplarz tej klasy musimy stworzyć w celu przetworzenia danych XML: XMLReader parser = new SAXParser(); // Tu robimy coś z parserem parser.parse(uri);

Osoby, które po raz pierwszy stykają się z interfejsem SAX, mogą być zaskoczone brakiem zmiennej egzemplarza o nazwie reader czy XMLReader (reader to po angielsku „czytnik”). Rzeczywiście, wydawałoby się, Ŝe tak powinny nazywać się te komponenty, ale w klasach SAX 1.0 zdefiniowano główny interfejs przetwarzający jako Parser i wiele zmiennych wywodzących się z tamtego kodu odziedziczyło właśnie nazwę parser. Tamta postać interfejsu została juŜ teraz zaniechana, poniewaŜ duŜa liczba poczynionych zmian wymagała nowych przestrzeni nazw, funkcji i właściwości, ale konwencje nazewnicze wciąŜ obowiązują, a parser dobrze oddaje przeznaczenie tego egzemplarza. Mając to na uwadze, przyjrzyjmy się niewielkiemu programowi uruchamiającemu i tworzącemu egzemplarz parsera SAX (przykład 3.1). Program ten nie przetwarza faktycznie dokumentu, ale tworzy szkielet, w ramach którego będziemy mogli wykonać pozostałe ćwiczenia rozdziału. Faktyczne przetwarzanie rozpoczniemy w następnym rozdziale.

Przykład 3.1. Przykład uŜycia parsera SAX import org.xml.sax.XMLReader; // Tutaj importujemy implementację czytnika XML (XML Reader) import org.apache.xerces.parsers.SAXParser; /** * SAXParserDemo pobiera plik XML i przetwarza je * za pomocą SAX, wyświetlając wywołania wsteczne. * * @author * Brett McLaughlin * @version 1.0 */

Czytniki SAX

57

public class SAXParserDemo { /** *

* Tutaj przetwarzamy plik za pomocą zarejestrowanych procedur obsługi SAX; * wyświetlamy zdarzenia zachodzące w cyklu przetwarzania. *

* * @param uri String URI pliku do przetworzenia. */ public void performDemo(String uri) { System.out.println("Przetwarzanie pliku XML: " + uri + "\n\n"); // Stwórz egzemplarz parsera XMLReader parser = new SAXParser(); } /** *

* Tu obsługujemy wiersz poleceń tego programu demonstracyjnego. *

*/ public static void main(String[] args) { if (args.length != 1) { System.out.println("UŜycie: java SAXParserDemo [XML URI]"); System.exit(0); } String uri = args[0]; SAXParserDemo parserDemo = new SAXParserDemo(); parserDemo.performDemo(uri); } }

Czytelnik powinien umieć załadować i skompilować powyŜszy program, o ile tylko przygotował się w opisany wcześniej sposób i klasy SAX znajdują się w ścieŜce dostępu do klas. Ten prosty program nie potrafi jeszcze zbyt wiele; jeśli uruchomimy go, podając wymyśloną nazwę pliku lub URI jako argument, powinien „pobrzęczeć” dyskiem i wyświetlić komunikat „Przetwarzanie pliku XML”. Wynika to stąd, Ŝe jedynie stworzyliśmy instancję parsera, a nie zaŜądaliśmy jeszcze przetworzenia dokumentu XML. Jeśli wynikły kłopoty z kompilacją powyŜszego pliku źródłowego, najprawdopodobniej problem tkwi w ścieŜce dostępu do klas środowiska programistycznego lub systemu. Najpierw naleŜy upewnić się, Ŝe zainstalowany został parser Apache Xerces (lub inny). W przypadku Xerces naleŜy po prostu pobrać odpowiedni plik jar. Po rozpakowaniu archiwum uzyskujemy plik xerces.jar — właśnie on zawiera skompilowane klasy dla tego programu. Po dodaniu tego archiwum do ścieŜki dostępu do klas nie powinno być problemów z kompilacją powyŜszego przykładu.

Przetwarzanie dokumentu Kiedy parser jest juŜ załadowany i gotowy do wykorzystania, moŜna przekazać mu do przetworzenia dokument. Tradycyjnie słuŜy do tego metoda parse(), wchodząca w skład klasy org.xml.sax.XMLReader. Metoda ta przyjmuje albo wejście org.xml.sax.InputSource, albo zwykły identyfikator URI. Na razie nie będziemy zajmowali się wejściem In-

Czytniki SAX

58

putSource i skorzystamy z URI. Identyfikator taki moŜe być adresem sieciowym, ale my uŜyjemy pełnej ścieŜki dostępu do dokumentu, który przygotowaliśmy wcześniej. Gdybyśmy jednak chcieli skorzystać z dokumentów umieszczonych w sieci, powinniśmy pamiętać o tym, Ŝe aplikacja musi umieć znaleźć dany adres URL (tzn. musi być zapewnione połączenie z siecią). Do programu dodajemy więc metodę parse() oraz dwie procedury obsługi błędów. PoniewaŜ dokument musi zostać załadowany, czy to lokalnie, czy przez sieć, moŜe wystąpić wyjątek java.io.IOException, który musimy przechwycić. Ponadto w czasie przetwarzania moŜe zostać zgłoszony wyjątek org.xmlsax.SAXException (problem przy przetwarzaniu), a więc musimy dodać jeszcze dwie istotne instrukcje, kilka linijek kodu i juŜ mamy gotową do uŜycia aplikację przetwarzającą XML: import java.io.IOException; import org.xml.sax.SAXException; import org.xml.sax.XMLReader; // Tutaj importujemy implementację czytnika XML (XML Reader) import org.apache.xerces.parsers.SAXParser; /** * SAXParserDemo pobiera plik XML i przetwarza je * za pomocą SAX, wyświetlając wywołania wsteczne. * * @author * Brett McLaughlin * @version 1.0 */ public class SAXParserDemo { /** *

* Tutaj przetwarzamy plik za pomocą zarejestrowanych procedur obsługi SAX; * wyświetlamy zdarzenia zachodzące w cyklu przetwarzania. *

* * @param uri String URI pliku do przetworzenia. */ public void performDemo(String uri) { System.out.println("Przetwarzanie pliku XML: " + uri + "\n\n"); try { // Stwórz egzemplarz parsera XMLReader parser = new SAXParser(); // Przetwórz dokument parser.parse(uri); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); } } public static void main(String[] args) {

Procedury obsługi zawartości

59

if (args.length != 1) { System.out.println("UŜycie: java SAXParserDemo [XML URI]"); System.exit(0); } String uri = args[0]; SAXParserDemo parserDemo = new SAXParserDemo(); parserDemo.performDemo(uri); } }

Tak zmodyfikowany przykład kompilujemy i wykonujemy. Pierwszym argumentem programu powinna być pełna ścieŜka dostępu do przetwarzanego pliku: D:\prod\JavaXML> java SAXParserDemo D:\prod\JavaXML\contents\contents.xml Przetwarzanie pliku XML: D:\prod\JavaXML\contents\contents.xml

Widząc taki nieciekawy wynik działania programu Czytelnik moŜe zacząć wątpić, czy w ogóle cokolwiek się stało. Jednak dokument XML jest rzeczywiście przetwarzany, a gdybyśmy podali błędny identyfikator URI pliku, parser zgłosi wyjątek i poinformuje, Ŝe nie mógł przetworzyć pliku. Nie stworzyliśmy jednak jeszcze Ŝadnych wywołań wstecznych, powodujących Ŝe SAX informuje w czasie przetwarzania, co się dzieje w danej chwili. Bez nich dokument jest przetwarzany w sposób niewidoczny dla uŜytkownika i bez interwencji aplikacji. Oczywiście, my mamy zamiar interweniować w ten proces, a więc musimy stworzyć metody wywołań wstecznych. To właśnie ta „interwencja” jest najwaŜniejszym aspektem korzystania z parsera SAX. Wywołania wsteczne parsera umoŜliwiają podjęcie działania w czasie trwania programu. Przetwarzanie przestaje być takie nieciekawe jak powyŜej — aplikacja zaczyna reagować na dane, elementy, atrybuty i strukturę przetwarzanego dokumentu, a w tym czasie współdziała jeszcze z innymi programami i klientami.

Korzystanie z InputSource Zamiast korzystania z pełnego identyfikatora URI, metodę parse() moŜna takŜe wywołać z argumentem w postaci org.xml.sax.InputSource. Właściwie o tej klasie niewiele moŜna powiedzieć — to raczej klasa osłonowa (ang. wrapper) i pomocnicza. Klasa InputSource po prostu kapsułkuje informacje o pojedynczym obiekcie. W naszym przykładzie nie na wiele się to przyda, ale w sytuacjach, gdzie identyfikator systemowy, identyfikator publiczny lub strumień mogą być dowiązane do jednego identyfikatora URI, kapsułkowanie za pomocą InputSource moŜe się okazać bardzo przydatne. Klasa posiada metody akcesora i mutatora do obsługi identyfikatorów systemowego i publicznego, kodowania znaków, strumienia bajtów (java.io.InputStream) oraz strumienia znaków (java.io.Reader). Jeśli w ten sposób przekaŜemy argument do parse(), to SAX gwarantuje równieŜ, Ŝe parser nigdy nie zmodyfikuje InputSource. Dzięki temu wiemy na pewno, Ŝe po wykorzystaniu parsera lub aplikacji obsługującej XML dane wejściowe pozostaną niezmienione. Wiele aplikacji opisywanych w dalszych częściach ksiąŜki będzie wykorzystywało właśnie klasy InputSource, a nie specyficznego URI.

Procedury obsługi zawartości Aby nasza aplikacja mogła zrobić cokolwiek poŜytecznego z przetwarzanymi właśnie danymi XML, w parserze SAX musimy zarejestrować procedury obsługi (ang. handlers). Procedura obsługi to po prostu grupa wywołań wstecznych zdefiniowanych w ramach interfejsu SAX i umoŜliwiających wywoływanie kodu aplikacji w przypadku zajścia konkretnych zdarzeń w czasie przetwarza-

Procedury obsługi zawartości

60

nia dokumentu. Trzeba zdać sobie sprawę z tego, Ŝe wywołania te będą następowały w czasie przetwarzania dokumentu, a nie po jego przetworzeniu. To między innymi dlatego SAX jest tak potęŜnym interfejsem — umoŜliwia obsługę dokumentu sekwencyjnie, bez konieczności wczytywania go całego do pamięci. Ograniczenie takie posiada model Document Object Model (DOM), który zostanie omówiony w dalszej kolejności. W interfejsie SAX 2.0 istnieją cztery podstawowe procedury obsługi: org.xml.sax.ContentHandler, org.xml.sax.ErrorHandler, org.xml.sax.DTDHandler oraz org. xml.sax.EntityResolver. W tym rozdziale omówimy procedurę ContentHandler, umoŜliwiającą obsługę standardowych zdarzeń związanych z danymi dokumentu XML. Rozpoczęte zostanie równieŜ omawianie procedury ErrorHandler, za pośrednictwem której parser zgłasza znalezione w dokumencie błędy. Procedura DTDHandler zostanie omówiona w rozdziale 5. Procedura EntityResolver omawiana jest w róŜnych miejscach ksiąŜki; teraz wystarczy zrozumieć, Ŝe działa ona dokładnie tak jak pozostałe i słuŜy do tłumaczenia encji zewnętrznych wstawionych do dokumentu XML. KaŜdy z tych interfejsów moŜe zostać zaimplementowany w klasach aplikacji wykonujących specyficzne zadania. Klasy implementacyjne rejestrowane są w parserze metodami setContentHandler(), setErrorHandler(), setDTDHandler() i setEntityResolver(). Następnie parser wykonuje wywołania wsteczne tych metod w razie uruchomienia konkretnego programu obsługi. W naszym przykładzie zaimplementujemy interfejs ContentHandler. W interfejsie tym zdefiniowano szereg istotnych metod cyklu przetwarzania, na które nasza aplikacja moŜe reagować. Przede wszystkim musimy dodać odpowiednie instrukcje import do pliku źródłowego (w tym klasę i interfejs org.xml.sax.Locator i org.xml.sax.Attributes — oraz nową klasę implementującą te metody wywołań wstecznych. Ta nowa klasa zostanie dodana na końcu pliku źródłowego SAXParserDemo.java: import java.io.IOException; import import import import import

org.xml.sax.Attributes; org.xml.sax.ContentHandler; org.xml.sax.Locator; org.xml.sax.SAXException; org.xml.sax.XMLReader;

// Tutaj importujemy implementację czytnika XML (XML Reader). import org.apache.xerces.parsers.SAXParser; /** * SAXParserDemo pobiera pliki XML i przetwarza je * za pomocą SAX, wyświetlając wywołania wsteczne. * * @author Brett McLaughlin * @version 1.0 */ public class SAXParserDemo { /** *

* Tutaj przetwarzamy plik za pomocą zarejestrowanych procedur obsługi SAX; * wyświetlamy zdarzenia zachodzące w cyklu przetwarzania. *

* * @param uri String URI pliku do przetworzenia. */

Procedury obsługi zawartości

61

public void performDemo(String uri) { System.out.println("Przetwarzanie pliku XML: " + uri + "\n\n"); // Stwórz egzemplarze procedur obsługi. ContentHandler contentHandler = new MyContentHandler(); try { // Stwórz egzemplarz parsera. XMLReader parser = new SAXParser(); // Zarejestruj procedurę obsługi zawartości. parser.setContentHandler(contentHandler); // Przetwórz dokument parser.parse(uri); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); } } /** *

* Tu obsługujemy wiersz poleceń tego programu demonstracyjnego. *

*/ public static void main(String[] args) { if (args.length != 1) { System.out.println("UŜycie: java SAXParserDemo [XML URI]"); System.exit(0); } String uri = args[0]; SAXParserDemo parserDemo = new SAXParserDemo(); parserDemo.performDemo(uri); } } /** * MyContentHandler implementuje interfejs * ContentHandler i definiuje sposób zachowania * wywołań wstecznych SAX powiązanych z zawartością * dokumentu XML. */ class MyContentHandler implements ContentHandler {

SAX

/** Zmienna locator będzie zawierała informacje o połoŜeniu */ private Locator locator; /** *

* Odwołania do Locator umoŜliwią uzyskanie * informacji o miejscu, w którym wystąpiło wywołanie wsteczne. *

*

Procedury obsługi zawartości * @param locator Locator -- obiekt dowiązany do * procesu wywołań wstecznych. */ public void setDocumentLocator(Locator locator) { } /** *

* Początek przetwarzanego dokumentu -- to dzieje się przed wszystkimi * odwołaniami wszystkich procedur obsługi SAX oprócz * {@link #setDocumentLocator}. *

* * @throws SAXException jeśli coś pójdzie nie tak */ public void startDocument() throws SAXException { } /** *

* Koniec przetwarzania dokumentu -- to dzieje się po wszystkich * wywołaniach wstecznych wszystkich procedur obsługi. SAX.. *

* * @throws SAXException jeśli coś pójdzie nie tak */ public void endDocument() throws SAXException { } /** *

* To oznaczać będzie, Ŝe napotkano instrukcję przetwarzania (nie na deklarację XML). *

* * @param target String obiekt docelowy instrukcji PI * @param data String zawiera wszystkie dane wysłane do PI. * Zazwyczaj ma to postać jednej lub więcej par * atrybut - wartość. * @throws SAXException jeśli coś pójdzie nie tak. */ public void processingInstruction(String target, String data) throws SAXException { } /** *

* To oznacza początek odwzorowywania przedrostka przestrzeni nazw XML. * Zazwyczaj powinno się pojawić wewnątrz elementu głównego dokumentu XML, * ale nie jest to reguła (moŜe pojawić się w dowolnym miejscu). * Odwzorowanie przedrostka danego elementu uruchamia wywołanie wsteczne * przed odwołaniem odnoszącym się do samego elementu * ({@link #startElement}). *

* * @param prefix String przedrostek dla odnalezionej * przestrzeni nazw. * @param uri String URI dla odnalezionej * przestrzeni nazw. * @throws SAXException jeśli coś pójdzie nie tak. */

62

Procedury obsługi zawartości public void startPrefixMapping(String prefix, String uri) { } /** *

* To oznacza koniec odwzorowania przedrostka, kiedy nie jest juŜ dostępna * przestrzeń nazw określona w odwołaniu * {@link #startPrefixMapping}. *

* * @param prefix String znalezionej przestrzeni nazw. * @throws SAXException jeśli coś pójdzie nie tak. */ public void endPrefixMapping(String prefix) { } /** *

* Komunikat o pojawieniu się faktycznego elementu. Podawane są atrybuty * elementu, za wyjątkiem atrybutów specyficznych dla słownika XML, * takich jak: * xmlns:[namespace prefix] i * xsi:schemaLocation. *

* * @param namespaceURI String URI przestrzeni nazw, z którą * skojarzony jest ten element lub pusty * String. * @param localName String nazwa elementu (bez * przedrostka przestrzeni nazw, jeśli taki istnieje) * @param rawName String Wersja XML 1.0 nazwy elementu: * [namespace prefix]:[localName]. * @param atts Attributes -- lista atrybutów tego elementu * @throws SAXException jeśli coś pójdzie nie tak. */ public void startElement(String namespaceURI, String localName, String rawName, Attributes atts) throws SAXException { } /** *

* Oznacza, Ŝe osiągnięto koniec elementu. * (). NaleŜy zauwaŜyć, Ŝe parser * nie rozróŜnia pomiędzy elementami pustymi i niepustymi, * a więc to będzie się odbywało identycznie w obu przypadkach. *

* * @param namespaceURI String URI przestrzeni nazw, z jaką skojarzony jest ten element * @param localName String nazwa elementu bez przedrostka * @param rawName String nazwa elementu w postaci XML. 1.0 * @throws SAXException jeśli coś pójdzie nie tak. */ public void endElement(String namespaceURI, String localName, String rawName) throws SAXException { } /** *

* Tutaj wyświetlamy dane tekstowe (zawarte wewnątrz elementu). *

63

Procedury obsługi zawartości

64

* * @param ch char[] tablica znaków zawartych w elemencie. * @param start int indeks w tablicy, w którym zaczynają się dane. * @param end int indeks w tablicy, w którym kończą się dane. * @throws SAXException jeśli coś pójdzie nie tak. */ public void characters(char[] ch, int start, int end) throws SAXException { } /** *

* Tutaj informujemy o znakach białych, ignorowanych w oryginalnym dokumencie. * Zazwyczaj procedura taka uruchamiana jest jedynie wtedy, gdy w procesie * przetwarzania odbywa się teŜ sprawdzanie poprawności. *

* Tutaj pokazujemy encję pominiętą przez parser. Zdarzenie powinno * pojawiać się jedynie w parserach nie sprawdzających poprawności; * jego zachowanie zaleŜy od konkretnej implementacji. *

* * @param name String nazwa pomijanej encji. * @throws SAXException gdy coś pójdzie nie tak. */ public void skippedEntity(String name) throws SAXException { } }

Dodaliśmy puste implementacje wszystkich metod zdefiniowanych w ramach interfejsu ContentHandler i nasz plik źródłowy kompiluje się. Oczywiście, takie puste implementacje nie umoŜliwiają obserwacji całego procesu, więc teraz przyjrzymy się po kolei wszystkim wymaganym metodom.

Lokalizator dokumentu Pierwsza metoda, jaką naleŜy zdefiniować, to ta ustawiająca org.xml.sax.Locator dla dowolnego zdarzenia. W przypadku wystąpienia wywołania wstecznego klasa implementująca procedurę obsługi niejednokrotnie musi uzyskać informację o miejscu w pliku XML przetwarzanym przez parser. Dzięki temu aplikacja będzie mogła podjąć decyzję odnośnie danego zdarzenia i miejsca, w którym ono wystąpiło. Klasa Locator udostępnia szereg przydatnych metod, takich jak getLineNumber() i getColumnNumber(), zwracających bieŜące miejsce w dokumencie

Procedury obsługi zawartości

65

XML. PoniewaŜ połoŜenie to odnosi się tylko do bieŜącego cyklu przetwarzania, klasy Locator powinno się uŜywać wyłącznie w zakresie implementacji ContentHandler. PoniewaŜ nam moŜe ona przydać się później, zachowujemy udostępniony egzemplarz klasy Locator do zmiennej składowej i drukujemy komunikat, informujący, Ŝe nastąpiło wywołanie wsteczne. Dzięki temu poznamy kolejność występowania zdarzeń SAX: /** Zmienna locator będzie zawierała informacje o połoŜeniu */ private Locator locator; /** *

* Odwołania do Locator umoŜliwią uzyskanie * informacji o miejscu, w którym wystąpiło wywołanie wsteczne. *

* * @param locator Locator -- obiekt dowiązany do * procesu wywołań wstecznych. */ public void setDocumentLocator(Locator locator) { System.out.println(" * setDocumentLocator() została wywołana"); // Zachowujemy do ewentualnego wykorzystania w przyszłości. this.locator = locator; }

Później, jeśli konieczne będzie uzyskanie informacji o miejscu zdarzenia, do metody tej moŜna dodać bardziej szczegółowe instrukcje. Jeśli jednak uŜytkownik chce pokazać, gdzie w dokumencie pojawiają się dane zdarzenia (np. numer wiersza, w którym wystąpił element), musi przypisać ten Locator zmiennej składowej do późniejszego wykorzystania w klasie.

Początek i koniec dokumentu KaŜdy proces ma początek i koniec. Oba te zdarzenia powinny wystąpić raz — pierwsze przed wszystkimi innymi zdarzeniami, a drugie po. Ten oczywisty fakt ma w aplikacjach krytyczne znaczenie — dokładnie informuje, kiedy przetwarzanie rozpoczyna się i kiedy kończy. SAX udostępnia metody wywołań wstecznych dla obu tych zdarzeń: startDocument() i endDocument(). Pierwsza metoda, startDocument(), wywoływana jest przed wszelkimi innymi wywołaniami wstecznymi, równieŜ przed tymi znajdującymi się w innych procedurach obsługi SAX, np. DTDHandler. Innymi słowy, startDocument() to nie tylko pierwsza metoda wywoływana wewnątrz ContentHandler, ale takŜe pierwsza metoda w całym procesie przetwarzania (nie licząc metody setDocumentLocator(),wspomnianej przed chwilą). Dzięki temu wiemy, kiedy przetwarzanie rozpoczyna się, a nasza aplikacja moŜe wykonać procedury, które muszą być uruchomione jeszcze przed tym przetwarzaniem. Druga metoda, endDocument(), jest zawsze wywoływana jako ostatnia, równieŜ bez względu na procedurę obsługi. Obejmuje to takŜe sytuacje, w których proces przetwarzania zostaje zatrzymany w wyniku napotkania błędów. Błędy zostaną omówione w dalszej części ksiąŜki; teraz Czytelnik powinien jednak wiedzieć, Ŝe są dwa ich rodzaje: błędy naprawialne i nienaprawialne. W przypadku wystąpienia błędu nienaprawialnego wywoływana jest metoda procedury ErrorHandler, po czym przetwarzanie kończy się wywołaniem metody endDocument(). W naszym przykładzie, kiedy obie te metody zostaną wywołane, wyświetlimy odpowiednie komunikaty na konsoli.

Procedury obsługi zawartości

66

/** *

* Początek przetwarzanego dokumentu -- to dzieje się przed wszystkimi * odwołaniami wszystkich procedur obsługi SAX oprócz * {@link #setDocumentLocator}. *

* * @throws SAXException jeśli coś pójdzie nie tak. */ public void startDocument() throws SAXException { System.out.println("Rozpoczyna się przetwarzanie..."); } /** *

* Koniec przetwarzania dokumentu -- to dzieje się po wszystkich * wywołaniach wstecznych wszystkich procedur obsługi SAX. *

* * @throws SAXException jeśli coś pójdzie nie tak. */ public void endDocument() throws SAXException { System.out.println("...Przetwarzanie skończone."); }

Oba te wywołania wsteczne mogą zgłosić wyjątek SAXException. Jest to jedyny typ wyjątków zgłaszany przez SAX. Za pośrednictwem wyjątków udostępniany jest kolejny standardowy interfejs do procesu przetwarzania. JednakŜe wyjątki te często pośredniczą w obsłudze innych wyjątków, wyraźnie wskazujących na to, z jakim problemem mamy do czynienia. Na przykład, jeśli plik XML jest przetwarzany za pośrednictwem sieci (poprzez adres URL), a połączenie nagle zostało przerwane, to zgłoszony zostaje IOException. Ale aplikacja korzystająca z klas SAX nie musi umieć przechwytywać tego wyjątku, poniewaŜ w ogóle nie musi wiedzieć, gdzie zlokalizowano zasób XML. Aplikacja moŜe obsługiwać tylko jeden wyjątek — SAXException. Ten pierwszy wyjątek jest przechwytywany przez parser SAX i ponownie zgłaszany, tym razem jako SAXException; pierwotny wyjątek jest „kapsułkowany” w nowym. Dzięki temu wystarczy, Ŝeby aplikacja przechwytywała jeden wyjątek, poprzez który dostarczane są takŜe szczegółowe informacje o naturze problemu, jaki wystąpił w procesie przetwarzania. Klasa SAXException udostępnia metodę getException(), zwracającą właściwy wyjątek.

Instrukcje przetwarzania Instrukcje przetwarzania (PI) w dokumencie XML są elementami dość wyjątkowymi. Nie są postrzegane jako elementy samego XML-a i zamiast natychmiastowej obsługi, przekazywane są aplikacji wywołującej. Z tego względu do ich obsługi SAX udostępnia specjalne wywołanie wsteczne. Metoda ta otrzymuje obiekt docelowy (ang. target) instrukcji oraz dane przekazane do PI. ZałóŜmy, Ŝe Ŝyczymy sobie wyświetlenia na ekranie informacji w momencie pojawienia się wywołania: /** *

* To oznaczać będzie, Ŝe napotkano instrukcję przetwarzania (nie * deklarację XML). *

* * @param target String obiekt docelowy instrukcji PI * @param data String zawiera wszystkie dane wysłane do PI.

Procedury obsługi zawartości

67

* Zazwyczaj ma to postać jednej lub więcej par * atrybut - wartość. * @throws SAXException jeśli coś pójdzie nie tak. */ public void processingInstruction(String target, String data) throws SAXException { System.out.println("PI: Obiekt docelowy:" + target + " i dane:" + data); }

W rzeczywistej aplikacji, korzystającej z danych XML, w tym miejscu program mógłby otrzymać instrukcje do ustawienia wartości zmiennych lub wykonania metod związanych z tą konkretną aplikacją. Na przykład struktura publikacji Apache Cocoon mogłaby ustawić znaczniki związane z przekształcaniem danych po ich przetworzeniu lub wyświetlić skrót XML jako określony typ zawartości. Metoda ta, podobnie jak inne wywołania wsteczne SAX, zgłasza SAXException w razie wystąpienia błędu. Podczas omawiania instrukcji przetwarzania wspomnieliśmy takŜe o deklaracji XML. Ta specjalna instrukcja przetwarzania udostępnia wersję, opcjonalne informacje o kodowaniu oraz o tym, czy dany dokument jest dokumentem samodzielnym:

Instrukcja ta przeznaczona jest specjalnie dla parsera XML. UmoŜliwia zgłoszenie błędu (np. o nieobsługiwanej wersji) na samym początku przetwarzania. PoniewaŜ instrukcja ta obsługiwana jest tylko przez parser, nie powoduje wywołania processingInstruction(). NaleŜy uwaŜać, aby nie stworzyć kodu oczekującego tej instrukcji lub informacji o wersji, poniewaŜ aplikacja nigdy nie otrzyma wywołania wstecznego do tej instrukcji przetwarzania. Właściwie to tylko parser powinien „interesować się” kodowaniem i wersją dokumentu XML, poniewaŜ elementy związane są z samym procesem przetwarzania. Kiedy juŜ dane dokumentu zostaną udostępnione poprzez interfejs API Javy, szczegóły te stają się dla aplikacji nieistotne.

Wywołania związane z przestrzenią nazw Sądząc po tym, ile czasu poświęciliśmy przestrzeniom nazw w XML-u (oraz po stopniu skomplikowania tej problematyki), moŜna przypuszczać, Ŝe jest to pojęcie dość istotne i Ŝe ma duŜy wpływ na przetwarzanie i obsługę danych XML. Oprócz schematu XML, przestrzenie nazw XML to z pewnością najwaŜniejsza cecha dodana do języka XML od czasu opublikowania oryginalnego zalecenia XML 1.0. W interfejsie SAX 2.0 obsługę przestrzeni nazw wprowadzono na poziomie elementów. Dzięki temu moŜliwe jest rozróŜnienie pomiędzy przestrzenią nazwy elementu (opisaną przedrostkiem i odpowiednim identyfikatorem URI) a lokalną nazwą elementu. W tym przypadku, pojęciem lokalna nazwa określamy nazwę elementu bez przedrostka. Na przykład lokalną nazwą dla JavaXML:Ksiazka jest po prostu Ksiazka. Przedrostek przestrzeni nazw to JavaXML, a identyfikator URI przestrzeni nazw (w naszym przykładzie) to http://www.oreilly.com/ catalog/javaxml. Istnieją dwa wywołania wsteczne do obsługi przestrzeni nazw (choć wywołania związane z elementami mogą takŜe z nich korzystać). Wywołania te następują wtedy, gdy parser natrafi na początek i koniec odwzorowania przedrostków (ang. prefix mapping). Sam termin nie jest jeszcze znany, ale to pojęcie nie wprowadza nic nowego. Odwzorowanie przedrostków to po prostu element, w którym za pomocą atrybutu xmlns deklarowana jest przestrzeń nazw. Jest to często element główny (w którym moŜe występować wiele róŜnych odwzorowań), ale nic nie stoi na prze-

Procedury obsługi zawartości

68

szkodzie, aby tę rolę spełniał dowolny inny element dokumentu XML, jawnie deklarujący przestrzeń nazw. Na przykład: Tu jakieś dane

W tym przypadku przestrzeń nazw deklarowana jest jawnie, na głębokości kilku poziomów zagnieŜdŜenia elementów. Wywołanie startPrefixMapping() otrzymuje przedrostek przestrzeni nazw oraz identyfikator URI skojarzony z tym przedrostkiem. Odwzorowanie uznawane jest za „zamknięte” lub „zakończone”, gdy zamknięty zostaje element deklarujący to odwzorowanie. Jedyny „haczyk” tego wywołania polega na tym, Ŝe zachowuje się ono niezupełnie sekwencyjnie — tak jak to ma zazwyczaj miejsce w interfejsie SAX; odwzorowanie przedrostków odbywa się bezpośrednio przed wywołaniem związanym z elementem deklarującym przestrzeń nazw. Oto przykład wywołania: /** *

* To oznacza początek odwzorowania przedrostka przestrzeni nazw XML. * Zazwyczaj powinno się pojawić wewnątrz elementu głównego dokumentu XML, * ale nie jest to reguła (moŜe pojawić się w dowolnym miejscu). * Odwzorowanie przedrostka danego elementu uruchamia wywołanie wsteczne * przed odwołaniem odnoszącym się do samego elementu * ({@link #startElement}). *

* * @param prefix String przedrostek dla odnalezionej * przestrzeni nazw * @param uri String URI dla odnalezionej * przestrzeni nazw * @throws SAXException jeśli coś pójdzie nie tak */ public void startPrefixMapping(String prefix, String uri) { System.out.println("Początek odwzorowania dla przedrostka " + prefix + " odwzorowanego dla URI " + uri); }

W naszym dokumencie jedynym zadeklarowanym odwzorowaniem jest atrybut elementu głównego. Oznacza to, Ŝe powinniśmy oczekiwać tego wywołania przed wywołaniem związanym z pierwszym elementem (o którym za chwilę), ale juŜ po wywołaniu startDocument() oraz po wszelkich instrukcjach PI, jakie znajdują się na początku dokumentu. Drugie z tej pary wywołań związanych z przestrzeniami nazw oznacza napotkanie końca odwzorowania i pojawia się bezpośrednio po znaczniku zamykającym elementu, w którym zadeklarowano odwzorowanie: /** *

* To oznacza koniec odwzorowania przedrostka, kiedy nie jest juŜ dostępna * przestrzeń nazw określona w odwołaniu * {@link #startPrefixMapping}. *

* * @param prefix String znalezionej przestrzeni nazw * @throws SAXException jeśli coś pójdzie nie tak

Procedury obsługi zawartości

69

*/ public void endPrefixMapping(String prefix) { System.out.println("Koniec odwzorowania dla przedrostka " + prefix); }

W przypadku pokazanego powyŜej fragmentu dokumentu XML moŜna oczekiwać następującego komunikatu po napotkaniu znacznika element2: Początek odwzorowania dla przedrostka mojaPrzestrzenNazw odwzorowanego dla URI http://mojUrl.pl

W ten sposób moŜna poznać odwzorowywany przedrostek oraz skojarzony z nim identyfikator URI.

Wywołania związane z elementami Teraz najprawdopodobniej przygotowani juŜ jesteśmy na faktyczne pobranie danych z dokumentu XML. To prawda, Ŝe ponad połowa wywołań wstecznych SAX nie ma nic wspólnego z elementami, atrybutami i danymi XML. Wynika to stąd, Ŝe proces przetwarzania nie polega po prostu na przekazaniu aplikacji danych XML; aplikacja otrzymuje takŜe instrukcje PI, dzięki którym wie, jakie działanie ma zostać podjęte; aplikacja „dowiaduje się” takŜe, kiedy przetwarzanie rozpoczyna się i kończy, a nawet gdzie znajdują się białe znaki, które moŜna zignorować. Jeśli niektóre z tych wywołań wydają się Czytelnikowi pozbawione sensu, to naleŜy uzbroić się w cierpliwość — jeszcze w tym rozdziale niektóre zagadnienia zostaną wyjaśnione; więcej wiadomości na ten temat znaleźć moŜna w rozdziale 5. Oczywiście, istnieją wywołania SAX słuŜące do uzyskiwania dostępu do danych XML zawartych w dokumentach. Pierwsze trzy zdarzenia, jakie zostaną omówione, to początek i koniec elementu oraz wywołanie characters(). Informują one, kiedy przetwarzany jest element, jakie dane zawiera oraz kiedy parser napotkał znacznik zamykający elementu. Pierwsze z wywołań, startElement(), informuje aplikację o elemencie XML i ewentualnych jego atrybutach. Parametry wywołania to nazwa elementu (w róŜnych postaciach) oraz egzemplarz klasy org.xml.sax.Attributes (Czytelnik powinien przypomnieć sobie opisywaną wcześniej instrukcję importującą). Ta klasa pomocnicza zawiera referencje do wszystkich atrybutów elementu. UmoŜliwia proste przetwarzanie kolejnych atrybutów elementu w postaci podobnej do Vector. Oprócz moŜliwości odwołania się do atrybutu za pomocą indeksu (kiedy przetwarzamy wszystkie atrybuty po kolei), moŜliwe jest równieŜ odwołanie się poprzez nazwę. Oczywiście, w tej chwili Czytelnik powinien juŜ być ostroŜniejszy, słysząc słowo „nazwa” związane z elementem lub atrybutem XML — moŜe ono znaczyć róŜne rzeczy. W tym przypadku moŜna uŜyć albo pełnej nazwy atrybutu (z przedrostkiem przestrzeni nazw, o ile taki tam jest) — to nazwiemy „surową” nazwą; albo połączenia nazwy lokalnej i identyfikatora URI, jeśli wykorzystano przestrzeń nazw. Istnieją takŜe metody pomocnicze, takie jak getURI(int index) i getLocalName(int index), dzięki którym moŜna uzyskać dodatkowe informacje o przestrzeni nazw związanej z danym atrybutem. Cały interfejs Attributes stanowi więc wszechstronne źródło danych o atrybutach elementu. Jak wspomnieliśmy, nie tylko atrybuty, ale równieŜ nazwa samego elementu moŜe przyjmować róŜne formy. I znów chodzi tu o przestrzeń nazw w XML-u. Najpierw dostarczany jest identyfikator URI przestrzeni nazw danego elementu. Dzięki temu element umieszczany jest w poprawnym kontekście i odpowiedniej relacji do pozostałych przestrzeni nazw w dokumencie. Następnie podawana jest lokalna nazwa elementu, czyli fragment bez przedrostka. Oprócz tego (na potrzeby zgodności wstecz), podawana jest „surowa” nazwa elementu. Chodzi tu o niezmodyfikowaną nazwę elementu, zawierającą ewentualny przedrostek przestrzeni nazw — czyli to, co umieszczone było w dokumencie XML; dla naszego elementu Ksiazka byłaby to nazwa JavaXML:

Procedury obsługi zawartości

70

Ksiazka. Obecność tych trzech typów nazw umoŜliwia opisanie dowolnego elementu, z przestrzenią nazw, czy teŜ bez niej. Skoro wiemy juŜ, jak udostępnia się element i jego atrybuty, spójrzmy na implementację wywołania wstecznego SAX, wyświetlającą informację na ekranie. W tym przykładzie sprawdzamy, czy nazwa elementu posiada skojarzony z nią identyfikator URI przestrzeni nazw; jeśli tak — drukujemy przestrzeń nazw; jeśli nie — drukujemy komunikat, informujący, Ŝe z elementem nie skojarzono Ŝadnej przestrzeni nazw: /** *

* * @param namespaceURI String URI przestrzeni nazw, z którą * skojarzony jest ten element lub pusty. * String * @param localName String nazwa elementu (bez * przedrostka przestrzeni nazw, jeśli taki istnieje) * @param rawName String Wersja XML 1.0 nazwy elementu: * [namespace prefix]:[localName] * @param atts Attributes -- lista atrybutów tego elementu. * @throws SAXException jeśli coś pójdzie nie tak. */ public void startElement(String namespaceURI, String localName, String rawName, Attributes atts) throws SAXException { System.out.print("startElement: " + localName); if (!namespaceURI.equals("")) { System.out.println(" w przestrzeni nazw " + namespaceURI + " (" + rawName + ")"); } else { System.out.println(" nie posiada skojarzonej przestrzeni nazw"); } for (int i=0; i
Wywołanie SAX bardzo upraszcza cały ten proces. W przypadku wywołania startElement() trzeba jeszcze zwrócić uwagę na fakt, Ŝe nie zachowuje się kolejności atrybutów. Podczas iteracji po implementacji klasy Attributes atrybuty niekoniecznie będą pojawiały się w kolejności, w jakiej zostały przetworzone (czyli w takiej, w jakiej wpisano je do dokumentu). Nie naleŜy więc polegać na uzyskanej kolejności atrybutów — i język XML nie wymaga od parserów zachowywania tej kolejności. W niektórych parserach kolejność jest zachowywana, ale nie naleŜy to do udokumentowanych funkcji takich parserów. Zamykająca część wywołania związanego z elementem to metoda endElement(). To proste wywołanie właściwie tłumaczy się samo — przekazywana mu jest tylko nazwa elementu, co umoŜliwia dopasowanie do odpowiedniego elementu przekazanego wcześniej do wywołania startElement(). Głównym przeznaczeniem tego wywołania jest zaznaczenie zamknięcia elementu — dzięki temu aplikacja wie, czy dalsze znaki są częścią innego zakresu, czy zamykanego właśnie elementu. W naszym przykładzie, podczas zamykania elementu wydrukujemy po prostu jego nazwę:

Procedury obsługi zawartości

71

/** *

* Oznacza, Ŝe osiągnięto koniec elementu * (). NaleŜy zauwaŜyć, Ŝe parser * nie rozróŜnia pomiędzy elementami pustymi i niepustymi, * a więc to będzie się odbywało identycznie w obu przypadkach. *

* * @param namespaceURI String URI przestrzeni nazw, z jaką skojarzony * jest ten element. * @param localName String nazwa elementu bez przedrostka * @param rawName String nazwa elementu w postaci XML. 1.0 * @throws SAXException jeśli coś pójdzie nie tak. */ public void endElement(String namespaceURI, String localName, String rawName) throws SAXException { System.out.println("endElement: " + localName + "\n"); }

Dane elementu Po określeniu początku i końca bloku elementu oraz po „wyłuskaniu” atrybutów tego elementu kolejną istotną informacją do pobrania są same dane zawarte w elemencie. Dane składają się zazwyczaj z kolejnych elementów, danych tekstowych lub obu jednocześnie. Kiedy pojawiają się kolejne elementy, następują dla nich odpowiednie wywołania i rozpoczyna się proces pseudorekurencyjny — elementy zagnieŜdŜone w elementach powodują wywołania „zagnieŜdŜone” w wywołaniach. W pewnej chwili parser napotyka dane tekstowe. Te są zazwyczaj dla klienta najwaŜniejsze — informacje takie przewaŜnie są wyświetlane lub słuŜą do zbudowania odpowiedzi. W XML-u dane tekstowe w elementach przesyłane są do aplikacji za pomocą wywołania characters(). Metoda ta udostępnia aplikacji tablicę znaków oraz indeksy początkowy i końcowy, które wskazują, gdzie naleŜy odczytać odpowiednie dane: /** *

* Tutaj wyświetlamy dane tekstowe (zawarte wewnątrz elementu). *

* * @param ch char[] tablica znaków zawartych w elemencie. * @param start int indeks w tablicy, w którym zaczynają się dane. * @param end int indeks w tablicy, w którym kończą się dane. * @throws SAXException jeśli coś pójdzie nie tak. */ public void characters(char[] ch, int start, int end) throws SAXException { String s = new String(ch, start, end); System.out.println("znaki: " + s); }

To, wydawałoby się, proste wywołanie niejednokrotnie powoduje spore zamieszanie, poniewaŜ interfejs i standard SAX nie definiują ściśle, jak korzystać z tego wywołania przy przetwarzaniu większych ilości danych tekstowych. Innymi słowy, parser moŜe zwrócić długi ciąg danych w jednym wywołaniu lub rozbić dane na wiele wywołań. Dla danego elementu metoda ta moŜe zostać

Procedury obsługi zawartości

72

wywołana zero razy (jeśli element nie zawiera danych tekstowych) albo jeden lub więcej razy. W róŜnych parserach będzie się to odbywało inaczej, niejednokrotnie z wykorzystaniem algorytmów mających na celu przyspieszenie przetwarzania. Nigdy nie naleŜy liczyć na uzyskanie wszystkich danych tekstowych po jednym wywołaniu metody; podobnie nigdy nie naleŜy zakładać, Ŝe wiele wywołań zwróci nam ciąg danych pochodzący z jednego tylko elementu. Przy tworzeniu procedur obsługi SAX trzeba takŜe pamiętać o postępowaniu hierarchicznym. Innymi słowy, nie wolno uwaŜać, Ŝe dowolny element posiada swoje dane oraz elementy potomne, naleŜy traktować go jako element macierzysty. Pamiętać naleŜy równieŜ, Ŝe parser „porusza się”, obsługując elementy, atrybuty i dane w miarę ich osiągania. Mogą z tego wynikać pewne niespodzianki. Spójrzmy na taki fragment dokumentu XML: To jestzagnieŜdŜony tekstdalszy tekst

Jeśli zapomnimy, Ŝe SAX przetwarza sekwencyjnie i wywołuje metody w miarę napotykania elementów i danych, oraz nie uwzględnimy faktu, Ŝe XML jest konstrukcją hierarchiczną, moŜemy spodziewać się następującego rezultatu: startElement: macierzysty nie posiada skojarzonej przestrzeni nazw znaki: To jest dalszy tekst. startElement: potomny nie posiada skojarzonej przestrzeni nazw znaki: zagnieŜdŜony tekst. endElement: potomny. endElement: macierzysty.

To wydawałoby się logiczne, bo macierzysty całkowicie „zawiera” element potomny, prawda? Ale dzieje się inaczej — dla kaŜdego zdarzenia SAX wywoływana jest metoda, co powoduje następujący wynik: startElement: macierzysty nie posiada skojarzonej przestrzeni nazw. znaki: To jest. startElement: potomny nie posiada skojarzonej przestrzeni nazw. znaki: zagnieŜdŜony tekst. endElement: potomny. znaki: dalszy tekst. endElement: macierzysty.

SAX nie wybiega z przetwarzaniem naprzód, a wiec wynik jest dokładnie taki, jaki uzyskalibyśmy czytając dokument XML sekwencyjnie, bez „ludzkich” przyzwyczajeń. Warto o tym pamiętać. I jeszcze jedno — metoda characters() często informuje o białych znakach. To powoduje dalsze niezrozumienie, bo przecieŜ inne wywołanie SAX, ignorableWhitespace(), takŜe komunikuje o białych znakach. W naszym przykładzie nie sprawdzamy poprawności składni dokumentu XML; ale moŜemy przecieŜ korzystać z parsera sprawdzającego poprawność składni. To dość waŜny szczegół, bo sposób komunikowania o białych znakach zaleŜy od tego, czy parser ma funkcję sprawdzania poprawności składni, czy nie. Parsery sprawdzające poprawność składni będą komunikowały o wszystkich białych znakach poprzez metodę ignorableWhitespace() — jest to spowodowane pewnymi czynnikami związanymi ze sprawdzaniem poprawności składni, które zostaną omówione w następnych dwóch rozdziałach. Parsery nie sprawdzające poprawności składni komunikują o białych znakach albo poprzez metodę ignorableWhitespace(), albo poprzez metodę characters(). Konieczne jest więc sprawdzenie, czy mamy do czynienia z parserem sprawdzającym poprawność składni. NaleŜy wiedzieć, Ŝe na wiele parserów faktycznie składają się dwie implementacje parsera — jedna sprawdzająca, a druga nie sprawdzająca poprawności składni. W czasie działania parsera odpowiednia klasa ładowana jest dynamicznie. Wynika to stąd, Ŝe parser nie sprawdzający poprawności

Procedury obsługi zawartości

73

często pracuje bardziej wydajnie niŜ ten sprawdzający, nawet jeśli sprawdzanie poprawności faktycznie się nie odbywa (z powodu konieczności implementacji dodatkowych struktur danych w parserze sprawdzającym). Tak właśnie jest w parserze Apache Xerces. W naszym przykładzie wykorzystany zostanie egzemplarz parsera nie sprawdzającego składni, ale gdyby określono definicję DTD lub schemat i gdyby zaŜądano sprawdzania poprawności, uŜyta zostałaby klasa parsera sprawdzającego poprawność. Aby uniknąć tego całego zamieszania, najlepiej w ogóle nie czynić Ŝadnych załoŜeń dotyczących białych znaków. Rzadko konieczne jest wykorzystanie białych znaków jako danych w dokumencie XML. Jeśli zachodzi taka potrzeba (np. w przypadku konstrukcji typu „kilka spacji + dane + kilka spacji”, gdzie liczba spacji ma znaczenie w danej aplikacji), to naleŜy korzystać z konstrukcji CDATA. To zapewni, Ŝe dane, w których liczy się liczba spacji, nie będą w ogóle przetwarzane — obsłuŜone zostaną przez aplikację nadrzędną jako duŜy „wycinek” danych tekstowych. W pozostałych przypadkach naleŜy unikać stosowania spacji w reprezentowaniu danych i czynienia jakichkolwiek załoŜeń odnośnie sposobu zwracania spacji przez wywołania.

Spokojnie, to tylko białe znaki Zagadnienia związane z białymi znakami zostały juŜ omówione. Teraz wystarczy dodać to ostatnie wywołanie SAX do naszej klasy MyContentHandler. Metoda ignorableWhitespace() pobiera parametry w dokładnie takim samym formacie jak metoda characters() i powinna wykorzystywać indeksy początkowy i końcowy, udostępniane w celu czytania znaków z dostarczonej tablicy: /** *

* Tutaj pokazujemy encję pominiętą przez parser. Zdarzenie powinno * pojawiać się jedynie w parserach nie sprawdzających poprawności; * jego zachowanie zaleŜy od konkretnej implementacji. *

* * @param name String nazwa pomijanej encji. * @throws SAXException gdy coś pójdzie nie tak. */ public void skippedEntity(String name) throws SAXException { System.out.println("Pomijam encję " + name); }

Zanim spróbujemy wykorzystać powyŜszą metodę, musimy pamiętać, Ŝe większość istniejących parserów nie pomija encji, nawet jeśli nie są to parsery sprawdzające poprawność. Na przykład parser Apache Xerces nigdy nie skorzysta z tego wywołania. Parser ten tłumaczy encję, a otrzymany wynik dołącza do danych otrzymywanych po przetworzeniu. Innymi słowy, wywołanie to czeka na wykorzystanie przez parser, ale niełatwo będzie nam znaleźć parser, który z niego skorzysta! Jeśli jednak posiadamy parser, który korzysta z powyŜszego wywołania, naleŜy pamiętać, Ŝe przekazany parametr nie zawiera otwierającego znaku „ampersand” ani końcowego średnika. W przypadku &OReillyCopyright; do metody skippedEntity() przekazywany jest tylko łańcuch OReillyCopyright.

Wyniki Teraz naleŜy zarejestrować procedurę obsługi w klasie XMLReader, której egzemplarz stworzyliśmy. SłuŜy do tego metoda setContentHandler(), której jedynym argumentem jest implementacja ContentHandler. Do metody demo() w naszym przykładowym programie dodajemy następujące wiersze: /** *

* Tutaj przetwarzamy plik za pomocą zarejestrowanych procedur obsługi SAX; * wyświetlamy zdarzenia zachodzące w cyklu przetwarzania. *

* * @param uri String URI pliku do przetworzenia. */

Procedury obsługi zawartości

75

public void performDemo(String uri) { System.out.println("Przetwarzanie pliku XML: " + uri + "\n\n"); // Stwórz egzemplarze procedur obsługi ContentHandler contentHandler = new MyContentHandler(); try { // Stwórz egzemplarz parsera XMLReader parser = new SAXParser(); // Zarejestruj procedurę obsługi zawartości parser.setContentHandler(contentHandler); // Przetwórz dokument parser.parse(uri); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); } }

Jeśli Czytelnik dołączył wszystkie omawiane wyŜej wywołania do pliku, powinien skompilować klasę MyContentHandler oraz zawierający ją plik SAXParserDemo. Po udanej kompilacji moŜna uruchomić program demonstrujący działanie parsera na stworzonym wcześniej przykładowym pliku XML. Pełne polecenie wywołujące Javę powinno mieć postać: D:\prod\JavaXML> java SAXParserDemo D:\prod\JavaXML\contents\contents.xml

Polecenie to powinno zwrócić duŜo danych wyjściowych. Jeśli Czytelnik korzysta z systemu Windows, moŜe się okazać konieczne zwiększenie bufora dla okna DOS-owego w takim stopniu, aby moŜliwe było przewinięcie ekranu i obejrzenie wszystkich danych wyjściowych. Dane te powinny mieć postać podobną do tych przedstawionych w przykładzie 3.22.

Przykład 3.2. Dane wyjściowe zwracane przez program SAXParserDemo Przetwarzanie pliku XML: contents.xml

* setDocumentLocator() została wywołana. Rozpoczyna się przetwarzanie... Początek odwzorowania dla przedrostka JavaXML odwzorowanego dla URI. http://www.oreilly.com/catalog/javaxml/ startElement: Ksiazka w przestrzeni nazw. http://www.oreilly.com/catalog/javaxml/ (JavaXML:Ksiazka) znaki: startElement: Tytul w przestrzeni nazw. http://www.oreilly.com/catalog/javaxml/ (JavaXML:Tytul) znaki: Java i XML endElement: Tytul

2

W tym oraz innych przykładach danych zwracanych przez programy moŜliwe jest, Ŝe zostały dodatkowo przełamane wiersze w celu poprawnego umieszczenia wydruku w ksiąŜce. O ile jednak same dane tekstowe się zgadzają, to na pewno wszystko jest w porządku!

Procedury obsługi zawartości

76

znaki: startElement: Spis w przestrzeni nazw. http://www.oreilly.com/catalog/javaxml/ (JavaXML:Spis) znaki:

startElement: Rozdzial w przestrzeni nazw. http://www.oreilly.com/catalog/javaxml/ (JavaXML:Rozdzial) Atrybut: tematyka=XML znaki: startElement: Naglowek w przestrzeni nazw http://www.oreilly.com/catalog/javaxml/ (JavaXML:Naglowek) znaki: Wprowadzenie endElement: Naglowek znaki: startElement: Temat w przestrzeni nazw http://www.oreilly.com/catalog/javaxml/ (JavaXML:Temat) Atrybut: podRozdzialy=7 znaki: Co to jest? endElement: Temat znaki: startElement: Temat w przestrzeni nazw http://www.oreilly.com/catalog/javaxml/ (JavaXML:Temat) Atrybut: podRozdzialy=3 znaki: Jak z tego korzystać? endElement: Temat znaki: startElement: Temat w przestrzeni nazw http://www.oreilly.com/catalog/javaxml/ (JavaXML:Temat) Atrybut: podRozdzialy=4 znaki: Dlaczego z tego korzysta? endElement: Temat znaki: startElement: Temat w przestrzeni nazw http://www.oreilly.com/catalog/javaxml/ (JavaXML:Temat) Atrybut: podrozdzialy=0 znaki: Co dalej? endElement: Temat ...

Takich danych pojawi się na wyjściu sporo, poniewaŜ przetwarzany dokument XML ma wiele elementów. Wyraźnie widać, Ŝe parser sekwencyjnie przetwarza kaŜdy element, atrybuty elementu, dane w nim zawarte, elementy zagnieŜdŜone oraz znacznik końcowy elementu. Proces powtarza się dla kaŜdego elementu. W naszym przykładzie został zastosowany parser Apache Xerces w wersji nie sprawdzającej poprawności dokumentu, a więc białe znaki są zgłaszane za pomocą wywołań characters(). W następnych dwóch rozdziałach zostaną omówione zagadnienia związane ze sprawdzaniem poprawności i wówczas będzie moŜna porównać wynik działania.

Procedury obsługi błędów

77

Teraz wiemy juŜ, w jaki sposób parser zgodny z interfejsem SAX przetwarza dokument XML. Powinniśmy równieŜ rozumieć wywołania pojawiające się w czasie procesu przetwarzania oraz to, w jaki sposób moŜna z nich uzyskać informacje potrzebne aplikacji. W następnych dwóch rozdziałach zostaną omówione zagadnienia związane ze sprawdzaniem poprawności dokumentu XML za pomocą dodatkowych klas SAX słuŜących do obsługi definicji DTD. Teraz sprawdzimy, jakie błędy mogą się pojawić, gdy dokument nie będzie poprawny, co dzieje się, gdy dokument XML nie jest poprawny i jakie błędy mogą z tego wynikać.

Procedury obsługi błędów Oprócz interfejsu ContentHandler, SAX udostępnia równieŜ interfejs ErrorHandler, słuŜący do obsługi sytuacji awaryjnych zaistniałych w czasie przetwarzania. Klasa ta działa podobnie jak omówiona wcześniej procedura obsługi dokumentu, ale zdefiniowano w niej jedynie trzy wywołania wsteczne. Przy pomocy tych trzech metod SAX obsługuje i powiadamia o wszystkich moŜliwych błędach. KaŜda metoda otrzymuje informacje o błędzie lub ostrzeŜeniu poprzez klasę SAXParseException. Obiekt ten zawiera numer wiersza, w którym wystąpił błąd, identyfikator URI przetwarzanego dokumentu (dokument przetwarzany lub zewnętrzne odwołanie wewnątrz tego dokumentu) oraz zwykłe informacje o błędzie, takie jak komunikat i dane ze śledzenia stosu. Ponadto kaŜda metoda moŜe zgłosić SAXException. Na początku moŜe się to wydawać nieco dziwne — program obsługi wyjątków zgłaszający wyjątek? NaleŜy jednak pamiętać, Ŝe kaŜda z procedur obsługi błędów otrzymuje wyjątki związane z przetwarzaniem. MoŜe to być ostrzeŜenie, które nie powinno przerwać procesu przetwarzania, lub błąd, który naleŜy rozwiązać, aby to przetwarzanie mogło być kontynuowane. Jednak wywołanie takie moŜe takŜe wykonywać operacje wejścia-wyjścia lub inne, które mogą spowodować zgłoszenie wyjątku — i wyjątek ten naleŜy przekazać aŜ „na samą górę”, do aplikacji. SłuŜy do tego właśnie wyjątek SAXException. ZałóŜmy, Ŝe procedura obsługi błędów otrzymuje powiadomienia o błędzie i zapisuje je do pliku dziennika błędów. Metoda taka musi być w stanie albo dopisać informacje do pliku istniejącego, albo stworzyć nowy plik. Gdyby w czasie przetwarzania dokumentu XML wystąpiło ostrzeŜenie, takŜe „dowiadywałaby” się o nim ta metoda. OstrzeŜenie miałoby na celu wywołanie odpowiedniej procedury i nie przerywałoby przetwarzania. JednakŜe, jeśli procedura obsługi błędów nie byłaby w stanie zapisywać do pliku dziennika, musiałaby zakomunikować parserowi i aplikacji, Ŝe przetwarzanie ma zostać przerwane. Efekt taki moŜna uzyskać poprzez przechwycenie wszystkich wyjątków wejścia-wyjścia i ponowne zgłoszenie ich aplikacji wywołującej, powodując przerwanie przetwarzania. PowyŜszy przykład wyjaśnia, dlaczego procedury obsługi błędów muszą mieć moŜliwość zgłaszania wyjątków (patrz przykład 3.3).

Przykład 3.3. Procedura obsługi, która moŜe zgłosić SAXException public void warning(SAXParseException exception) throws SAXException { try { FileWriter fw = new FileWriter("error.log"); BufferedWriter bw = new BufferedWriter(fw); bw.write("OstrzeŜenie: " + exception.getMessage() + "\n"); bw.flush(); bw.close(); fw.close();

Procedury obsługi błędów

78

} catch (Exception e) { throws new SAXException("Brak moŜliwości zapisu do pliku dziennika", e); } }

Teraz moŜna juŜ zdefiniować szkielet procedury obsługi błędów i zarejestrować ją w parserze w taki sam sposób, jak w przypadku procedury obsługi zawartości. Najpierw trzeba zaimportować klasę SAXParseException i ErrorHandler: import import import import import import import import

java.io.IOException; org.xml.sax.Attributes; org.xml.sax.ContentHandler; org.xml.sax.ErrorHandler; org.xml.sax.Locator; org.xml.sax.SAXException; org.xml.sax.SAXParseException; org.xml.sax.XMLReader;

Teraz w tym samym pliku z programem w Javie (znów na dole, po klasie MyContentHandler) naleŜy zaimplementować interfejs ErrorHandler, zdefiniowany w ramach SAX-a. Podobnie jak przy omawianiu klasy ContentHandler, poniŜej są przedstawione puste implementacje, które wkrótce zostaną wypełnione treścią: /** * MyErrorHandler implementuje interfejs SAX * ErrorHandler i definiuje zachowanie wywołań * wstecznych powiązanych z błędami w XML-u. */ class MyErrorHandler implements ErrorHandler { /** *

* Powiadomienie o ostrzeŜeniu; Ŝadne zasady XML nie zostały "złamane", * ale wydaje się, Ŝe czegoś brakuje lub coś jest wpisane niepoprawnie. *

* Tutaj komunikujemy o błędzie, jeśli taki się pojawi; błąd oznacza, Ŝe * złamano regułę i zazwyczaj pojawia się w czasie sprawdzania składni; * przetwarzanie moŜe jeszcze być kontynuowane. *

* Tutaj komunikujemy, Ŝe nastąpił błąd krytyczny; oznacza to, Ŝe * złamano regułę w ten sposób, Ŝe dalsze przetwarzanie * nie jest moŜliwe albo jest bezcelowe. *

* * @param exception SAXParseException -- wyjątek, który nastąpił. * @throws SAXException jeśli coś pójdzie nie tak. */ public void fatalError(SAXParseException exception) throws SAXException { } }

Aby procedura obsługi błędów mogła zostać uŜyta, naleŜy ją zarejestrować w parserze SAX. SłuŜy do tego metoda setErrorHandler() interfejsu XMLReader w naszej przykładowej metodzie demo(). Metoda setErrorHandler() pobiera jako jedyny parametr interfejs ErrorHandler lub jego implementację: // Stwórz egzemplarze procedur obsługi ContentHandler contentHandler = new MyContentHandler(); ErrorHandler errorHandler = new MyErrorHandler(); try { // Stwórz egzemplarz parsera XMLReader parser = new SAXParser(); // Zarejestruj procedurę obsługi zawartości parser.setContentHandler(contentHandler); // Zarejestruj procedurę obsługi błędów parser.setErrorHandler(errorHandler); // Przetwórz dokument parser.parse(uri); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); } ...

A teraz spróbujmy sprawić, Ŝeby na ekranie pojawiały się komunikaty w przypadku wywołania tych metod.

OstrzeŜenia Za kaŜdym razem, gdy pojawi się ostrzeŜenie (wynikające ze specyfikacji XML 1.0), metoda ta wywoływana jest w zarejestrowanej procedurze obsługi błędów. Są róŜne sytuacje powodujące wygenerowanie ostrzeŜenia; wszystkie związane są z definicjami DTD i poprawnością składniową dokumentu. Zostaną one omówione w następnych dwóch rozdziałach. Tymczasem zdefiniujemy prostą metodę wyświetlającą numer wiersza, identyfikator URI i komunikat w przypadku wystąpienia ostrzeŜenia.

Procedury obsługi błędów

80

PoniewaŜ chcemy, aby w razie ostrzeŜenia przetwarzanie zostało przerwane, zgłaszamy wyjątek SAXException i pozwalamy aplikacji nadrzędnej elegancko zakończyć działanie i zwolnić zasoby: /** *

* Powiadomienie o ostrzeŜeniu; Ŝadne zasady języka XML nie zostały złamane, * ale wydaje się, Ŝe czegoś brakuje lub coś jest wpisane niepoprawnie. *

* * @param exception SAXParseException -- wyjątek, jaki nastąpił. * @throws SAXException gdy coś pójdzie nie tak. */ public void warning(SAXParseException exception) throws SAXException { System.out.println("**Przetwarzanie ostrzeŜenia**\n" + " Wiersz: " + exception.getLineNumber() + "\n" + " URI: " + exception.getSystemId() + "\n" + " Komunikat: " + exception.getMessage()); throw new SAXException("Napotkano ostrzeŜenie"); }

Błędy niekrytyczne Błędy występujące w czasie przetwarzania, które moŜna naprawić, ale które stanowią pogwałcenie fragmentu specyfikacji XML, postrzegane są jako błędy niekrytyczne. Procedura obsługi błędów powinna je przynajmniej odnotować w pliku dziennika, bo zazwyczaj są na tyle powaŜne, Ŝe zasługują na zwrócenie uwagi uŜytkownika lub administratora aplikacji; jednak nie są aŜ tak istotne, by przerwać jej działanie. Tak jak w przypadku ostrzeŜeń, większość błędów niekrytycznych związanych jest z poprawnością dokumentu, która zostanie omówiona w odpowiednich rozdziałach. Podobnie jak w przypadku ostrzeŜeń, nasza prosta procedura obsługi błędów wyświetli informacje przesłane do wywołania wstecznego i zakończy proces przetwarzania: /** *

* * @param exception SAXParseException -- wyjątek, który nastąpił. * @throws SAXException jeśli coś pójdzie nie tak. */ public void error(SAXParseException exception) throws SAXException { System.out.println("**Przetwarzanie błędu**\n" + " Wiersz: " + exception.getLineNumber() + "\n" + " URI: " + exception.getSystemId() + "\n" + " Komunikat: " + exception.getMessage()); throw new SAXException("Napotkano błąd"); }

Procedury obsługi błędów

81

Błędy krytyczne Błędy krytyczne to te, które wymuszają zatrzymanie działania parsera. Zazwyczaj wynikają z niepoprawnego sformatowania dokumentu i ich pojawienie się oznacza, Ŝe albo dalsze przetwarzanie nie ma sensu, albo jest technicznie niemoŜliwe. Procedura obsługi błędu powinna niemal zawsze poinformować uŜytkownika lub administratora o wystąpieniu takiego błędu; pozostawienie aplikacji samej sobie moŜe grozić całkowitym jej zawieszeniem. W naszym przykładzie będziemy emulowali zachowanie dwóch pozostałych metod i zatrzymamy przetwarzanie, wyświetlając komunikat o błędzie na ekranie: /** *

* Tutaj komunikujemy, Ŝe nastąpił błąd krytyczny; oznacza to, Ŝe * złamano regułę w ten sposób, Ŝe dalsze przetwarzanie * nie jest moŜliwe albo jest bezcelowe. *

* * @param exception SAXParseException -- wyjątek, który nastąpił. * @throws SAXException jeśli coś pójdzie nie tak. */ public void fatalError(SAXParseException exception) throws SAXException { System.out.println("**Przetwarzanie błędu krytycznego**\n" + " Wiersz: " + exception.getLineNumber() + "\n" + " URI: " + exception.getSystemId() + "\n" + " Komunikat: " + exception.getMessage()); throw new SAXException("Napotkano błąd krytyczny"); }

Po zakodowaniu procedury obsługi tego trzeciego typu błędu powinno być moŜliwe przekompilowanie pliku źródłowego i powtórne uruchomienie go na naszym dokumencie XML. Uzyskany wynik nie powinien róŜnić się od poprzedniego, bo dokument XML nie zawiera błędów, o których aplikacja mogłaby poinformować. W kolejnych podrozdziałach zostaną omówione błędy w dokumentach XML, w których nie jest wykonywane sprawdzanie poprawności.

Rozbijanie danych Skoro posiadamy juŜ procedury obsługi błędów, to warto zobaczyć, jak one działają. Jak juŜ to było wspomniane, większość ostrzeŜeń i błędów niekrytycznych związanych jest z poprawnością składni dokumentu — zagadnienia te zostaną omówione w kilku następnych rozdziałach. Jest jednak jeden błąd niekrytyczny, który pojawia się w dokumentach XML nie sprawdzonych pod względem poprawności. Chodzi tutaj o wersję języka XML zgłaszaną przez dokument. Aby zobaczyć, jak ten błąd jest zgłaszany, zmieńmy nasz przykładowy dokument w następujący sposób:

Procedury obsługi błędów

82

Teraz naleŜy uruchomić przykładowy program na takim zmienionym pliku XML. Wynik powinien być zbliŜony do przedstawionego w przykładzie 3.4.

Przykład 3.4. Program SAXParserDemo wyświetlający błąd D:\prod\JavaXML>java SAXParserDemo D:\prod\JavaXML\contents.xml Przetwarzanie pliku XML: contents.xml

* setDocumentLocator() została wywołana Rozpoczyna się przetwarzanie... **Przetwarzanie błędu** Wiersz: 1 URI: file:/D:/prod/JavaXML/contents/contents.xml Komunikat: XML version "1.2" is not supported. Błąd w przetwarzaniu: Napotkano błąd

Kiedy parser XML operuje na dokumencie, którego wersja języka XML została określona jako nowsza niŜ te obsługiwane przez parser, zgłaszany jest błąd niekrytyczny, zgodnie ze specyfikacją XML 1.0. W ten sposób aplikacja zostaje poinformowana o tym, Ŝe nowe funkcje, które mogły zostać uŜyte w dokumencie, nie muszą być rozpoznawane przez parser w tej wersji. Przetwarzanie moŜe być kontynuowane, a więc taki błąd nie jest postrzegany jako krytyczny. JednakŜe moŜe on mieć istotny wpływ na dokument (np. nowa składnia moŜe powodować dalsze błędy), a więc ma wyŜszą rangę niŜ ostrzeŜenie. To dlatego wywoływana jest metoda error(), powodująca wysłanie komunikatu informującego o błędzie i zatrzymanie przetwarzania w naszym przykładowym programie. Wszystkie inne istotne ostrzeŜenia będą omawiane w następnych dwóch rozdziałach; wciąŜ istnieją jednak błędy krytyczne, które mogą się pojawiać w dokumencie nie sprawdzonym pod kątem poprawności. Są one związane z niepoprawnym formatowaniem dokumentu. Parsery XML nie potrafią naprawiać takich dokumentów, a więc błąd w składni powoduje zatrzymanie procesu przetwarzania. Najprostszym sposobem demonstracji tego zagadnienia jest wprowadzenie błędów do dokumentu XML. Ponownie zmieńmy deklarację wersji na 1.0 i wprowadźmy następujące zmiany w naszym dokumencie: Java i XML

Taki dokument nie jest poprawnie sformatowany. Uruchamiamy program SAXParserDemo na tak zmodyfikowanym pliku. Wynik przestawiony jest w przykładzie 3.5.

Lepszy sposób ładowania parsera

83

Przykład 3.5. Program SAXParserDemo wyświetlający błąd krytyczny D:\prod\JavaXML>java SAXParserDemo D:\prod\JavaXML\contents.xml Przetwarzanie pliku XML: contents.xml

* setDocumentLocator() została wywołana Rozpoczyna się przetwarzanie... startElement: Ksiazka w przestrzeni nazw http://www.oreilly.com/catalog/javaxml/ (JavaXML:Ksiazka) znaki: **Przetwarzanie błędu krytycznego** Wiersz: 13 URI: file:/D:/prod/JavaXML/contents/contents.xml Komunikat: The element type "JavaXML:Ksiazka" must be terminated by the matching end-tag "".

Parser zgłasza niepoprawne zakończenie elementu JavaXML:Ksiazka. Aby zrozumieć komunikat o błędzie, naleŜy zdać sobie sprawę z faktu, Ŝe parser „widzi” znak ukośnika przed elementem JavaXML:Tytul i zakłada, Ŝe element, który musi zostać zamknięty, to JavaXML: Ksiazka — czyli ten, który jest obecnie „otwarty”. Kiedy znajduje znacznik zamykający elementu JavaXML:Tytul, zgłasza niepoprawność tego znacznika jako zamknięcia otwartego elementu JavaXML:Ksiazka. UwaŜna analiza omawianej procedury obsługi błędów pozwala rozumieć, na jakie problemy moŜna natknąć się w czasie przetwarzania i jak moŜna ich unikać. W rozdziale 5. ponownie zajmiemy się procedurami obsługi błędów i przyjrzymy się problemom zgłaszanym przez parser wykonujący sprawdzanie poprawności składni.

Lepszy sposób ładowania parsera Choć potrafimy juŜ przetwarzać dokumenty XML z wykorzystaniem interfejsu SAX, w naszym kodzie wciąŜ znajduje się pewien ewidentny błąd. Przeanalizujmy powtórnie proces tworzenia egzemplarza klasy XMLReader: try { // Stwórz egzemplarz parsera XMLReader parser = new SAXParser(); // Zarejestruj procedurę obsługi zawartości parser.setContentHandler(contentHandler); // Zarejestruj procedurę obsługi błędów parser.setErrorHandler(errorHandler); // Przetwórz dokument parser.parse(uri); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); }

Lepszy sposób ładowania parsera

84

Czy powyŜszy fragment nie budzi Ŝadnych wątpliwości? Wskazówką moŜe być jeszcze inny wiersz naszego kodu: // Tutaj importujemy implementację czytnika XML (XML Reader) import org.apache.xerces.parsers.SAXParser;

Jawnie importujemy implementację klasy XMLReader danego producenta, a następnie bezpośrednio tworzymy egzemplarz tej implementacji. Problem nie wynika z trudności tego zadania, ale z faktu, Ŝe gubimy jedną z najwaŜniejszych cech Javy — przenośność. Takiego kodu nie da się uruchomić, a nawet skompilować na platformie nie wykorzystującej parsera Apache Xerces. A przecieŜ moŜliwe jest nawet, Ŝe w zaktualizowanej wersji Xerces nazwa uŜywanej klasy moŜe ulec zmianie! A zatem nasz kod nie jest przenośny. W związku z tym zaleca się stworzenie egzemplarza klasy o nazwie klasy pobranej z implementacji. W ten sposób w kodzie źródłowym moŜliwe jest zastosowanie rozwiązania polegającego na zmianie prostego parametru String. Wszystko to jest moŜliwe w interfejsie SAX 2.0, a klasa, która udostępni potrzebną nam metodę, nosi nazwę org.xml.sax.helpers.XMLReaderFactory: /** * Próba utworzenia egzemplarza czytnika XML z nazwy klasy. * *

Po otrzymaniu nazwy klasy metoda ta usiłuje załadować * i stworzyć egzemplarz klasy jako czytnika XML.

* * @return Nowy czytnik XML. * @exception org.xml.sax.SAXException Jeśli klasa nie moŜe zostać * załadowana; nie moŜna stworzyć egzemplarza lub * wykonać rzutowania na XMLReader. * @see #createXMLReader() */ public static XMLReader createXMLReader (String className) throws SAXException { // Implementacja }

Metody tej w naszym kodzie uŜyjemy następująco: try { // Stwórz egzemplarz parsera XMLReader parser = XMLReaderFactory.createXMLReader( "org.apache.xerces.parsers.SAXParser"); // Zarejestruj procedurę obsługi zawartości parser.setContentHandler(contentHandler); // Zarejestruj procedurę obsługi błędów parser.setErrorHandler(errorHandler); // Przetwórz dokument parser.parse(uri); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); }

Lepszy sposób ładowania parsera

85

Ta statyczna metoda pobiera nazwę klasy parsera do załadowania, a zwraca wersję tej klasy w postaci egzemplarza rzutowanego na interfejs XMLReader (zakładając, Ŝe faktycznie implementowany jest XMLReader). Ewentualne problemy są zgłaszane do programu wywołującego za pośrednictwem SAXException. Teraz wystarczy dodać jedną instrukcję importującą, usunąć odwołanie do parsera konkretnego producenta, wprowadzić powyŜsze zmiany i juŜ moŜna przekompilować nasz kod źródłowy: import java.io.IOException; import import import import import import import import

org.xml.sax.Attributes; org.xml.sax.ContentHandler; org.xml.sax.ErrorHandler; org.xml.sax.Locator; org.xml.sax.SAXException; org.xml.sax.SAXParseException; org.xml.sax.XMLReader; org.xml.sax.helpers.XMLReaderFactory;

// To usuwamy // import org.apache.xerces.parsers.SAXParser;

No i znów mamy przenośny kod! Aby jeszcze bardziej rozszerzyć przenośność, warto przechowywać nazwę klasy parsera w pliku właściwości. UmoŜliwia to ładowanie klasy „na gorąco”, a kod moŜna przenosić pomiędzy platformami bez konieczności rekompilacji — zmianie ulega jedynie plik właściwości. Tak przebiega proces odczytywania plików właściwości w programie: try { // Stwórz egzemplarz parsera XMLReader parser = XMLReaderFactory.createXMLReader( PropertiesReader().getInstance() .getProperty("parserClass")); // Zarejestruj procedurę obsługi zawartości parser.setContentHandler(contentHandler); // Zarejestruj procedurę obsługi błędów parser.setErrorHandler(errorHandler); // Przetwórz dokument parser.parse(uri); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); }

Klasa narzędziowa PropertiesReader posłuŜyła tutaj do odczytania pliku właściwości i zwrócenia wartości odpowiadającej kluczowi parserClass (wartość ta będzie zawierała nazwę klasy parsera, którą naleŜy wykorzystać dla danej platformy. W naszych przykładach byłby to łańcuch org.apache.xerces.SAXParser. Oczywiście, moŜna byłoby takŜe skorzystać z systemowych właściwości Javy, ale nie są one odpowiednie dla rozproszonych aplikacji WWW przedstawionych w tej ksiąŜce (obsługiwane są z poziomu wiersza poleceń). Często aplikacje rozproszone uruchamiane są jako całość, a nie indywidualnie, a więc określenie właściwości systemowych dla jednego tylko komponentu byłoby trudne.

Uwaga! Pułapka!

86

Uwaga! Pułapka! Programista w trakcie pracy moŜe napotkać wiele pułapek. Czytelnik powinien wiedzieć, jak unikać typowych błędów programistycznych związanych z uŜywaniem interfejsu SAX; w dalszych rozdziałach zostaną takŜe omówione pułapki związane z innymi interfejsami API.

Mój parser nie obsługuje interfejsu SAX 2.0. Co robić? Nie załamywać się. Przede wszystkim zawsze moŜna zmienić parser na inny — utrzymanie zgodności z najnowszą wersją SAX naleŜy do obowiązku producenta parsera. Jeśli producent nie nadąŜa za standardami, to znaczy, Ŝe w naszym parserze mogą teŜ istnieć inne błędy. Istnieją jednak przypadki, kiedy zmuszeni jesteśmy korzystać z danego parsera (np. z powodu konieczności obsługi zastanego kodu lub aplikacji). Jednak nawet w takich sytuacjach nie wszystko jest stracone. SAX 2.0 wyposaŜony jest w klasę pomocniczą org.xml.sax.helpers.ParserAdapter, która powoduje, Ŝe implementacja klasy Parser w SAX 1.0 zachowuje się jak implementacja XMLReader w interfejsie SAX 2.0. To poręczne narzędzie pobiera implementację Parser z wersji 1.0 jako parametr wejściowy i dalej moŜe być uŜywane zamiast tej implementacji. UmoŜliwia ustawienie ContentHandler i poprawnie obsługuje wszystkie wywołania związane z przestrzenią nazw. Jedyna funkcja, do jakiej nie będziemy mieli dostępu, to obsługa pomijania encji (nie była ona po prostu dostępna w implementacji 1.0 w jakiejkolwiek formie, więc nie moŜe być emulowana). Sposób uŜycia tej klasy przedstawiony jest w przykładzie 3.6.

Przykład 3.6. Korzystanie z klasy Parser z SAX 1.0 jako klasy XMLReader z 2.0. try { // Zarejestruj parser w SAX Parser parser = ParserFactory.makeParser( "org.apache.xerces.parsers.SAXParser"); ParserAdapter myParser = new ParserAdapter(parser); // Zarejestruj procedurę obsługi zawartości myParser.setContentHandler(contentHandler); // Zarejestruj procedurę obsługi błędów myParser.setErrorHandler(errorHandler); // Przetwórz dokument myParser.parse(uri); } catch (ClassNotFoundException e) { System.out.println( "Nie znaleziono klasy parsera."); } catch (IllegalAccessException e) { System.out.println( "Niewystarczające przywileje do załadowania klasy parsera."); } catch (InstantiationException e) { System.out.println( "NiemoŜliwe utworzenie egzemplarza klasy parsera."); } catch (ClassCastException e) { System.out.println( "Parser nie ma zaimplementowanego org.xml.sax.Parser"); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage());

Uwaga! Pułapka!

87

} catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); }

Jeśli Czytelnik dopiero zaczyna poznawać interfejs SAX i ma kłopoty ze zrozumieniem tego przykładu, nie powinien się martwić — w przypadku korzystania z najnowszej i najlepszej wersji SAX (2.0) prawdopodobnie nigdy nie będzie trzeba uŜywać kodu podobnego do powyŜszego. Przydatny jest on tylko tam, gdzie konieczne jest korzystanie z parsera 1.0.

SAX XMLReader — wielokrotne uŜycie a współbieŜność Jedną z najciekawszych cech Javy jest fakt, Ŝe w niezwykle prosty sposób moŜna wielokrotnie uŜywać tych samych obiektów. Cechę tę posiadają równieŜ parsery SAX. Po utworzeniu egzemplarza XMLReader moŜliwe jest ciągłe jego uŜywanie i przekazywanie mu wielu (nawet setek) dokumentów. Kolejne dokumenty lub źródła InputSources przekazywane są parserowi, zatem moŜe być on wykorzystany do róŜnych zadań. Parsery nie są jednak współbieŜne. Kiedy juŜ rozpoczął się proces przetwarzania, parsera nie będziemy w stanie wykorzystać ponownie dopóty, dopóki to pierwsze przetwarzanie nie zostanie zakończone. Dla tych z Czytelników, którzy lubią korzystać z algorytmów rekurencyjnych, to właśnie moŜe stanowić pułapkę. Kiedy spróbujemy uŜyć parsera wtedy, gdy ten jest akurat w trakcie przetwarzania innego dokumentu, zgłoszony zostanie raczej niemiły SAXException i całe przetwarzanie zostanie zatrzymane. Jaki z tego wynika wniosek? Dokumenty naleŜy przetwarzać jeden po drugim, albo — godząc się na wszelkie tego skutki — tworzyć więcej egzemplarzy parsera.

Locator w złym miejscu Kolejną niebezpieczną (a z pozoru niewinną) cechą zdarzeń SAX jest fakt udostępniania egzemplarza Locator poprzez wywołanie metody setDocumentLocator(). W ten sposób aplikacja poznaje źródło zdarzenia SAX, co umoŜliwia podjęcie decyzji o dalszym przetwarzaniu oraz sposobie reagowania na inne zdarzenia. JednakŜe to miejsce jest określone poprawnie jedynie na czas istnienia egzemplarza ContentHandler. Po ukończeniu przetwarzania Locator nie jest juŜ poprawny (szczególnie wtedy, gdy rozpoczyna się następne przetwarzanie). Błędem popełnianym przez nowicjuszy jest przechowywanie referencji do obiektu Locator wewnątrz zmiennej naleŜącej do klasy spoza wywołania wstecznego: public void setDocumentLocator(Locator locator) { // Zachowanie Locator w klasie poza ContentHandler mojaInnaKlasa.setLocator(locator); } ... public metodaInnejKlasy() { // Próba uŜycia poza ContentHandler System.out.println(locator.getLineNumber()); }

To bardzo zły pomysł — Locator traci znaczenie, bo jesteśmy juŜ poza implementacją ContentHandler. Często korzystanie z takiej zmiennej powoduje nie tylko otrzymywanie przez aplikację nieprawidłowych informacji, ale równieŜ uszkodzenie dokumentu XML. Innymi słowy, obiektu tego naleŜy uŜywać lokalnie, a nie globalnie. W naszej implementacji ContentHandler otrzymany Locator zachowaliśmy do zmiennej. Następnie moglibyśmy jej uŜyć w poprawny sposób (np. do podania numerów wierszy, w których napotkaliśmy poszczególne elementy):

Co dalej?

88 public void startElement(String namespaceURI, String localName, String rawName, Attributes atts) throws SAXException { System.out.print("startElement: " + localName + " w wierszu " + locator.getLineNumber()); if (!namespaceURI.equals("")) { System.out.println(" w przestrzeni nazw " + namespaceURI + " (" + rawName + ")"); } else { System.out.println(" nie posiada skojarzonej przestrzeni nazw"); } for (int i=0; i
Wyprzedzanie danych Wywołanie characters() przyjmuje tablicę znaków oraz parametry start i end, które wskazują, gdzie naleŜy rozpocząć, a gdzie skończyć odczytywanie z tej tablicy. MoŜe to prowadzić do pomyłek — typowym błędem jest odczytywanie znaków z tablicy w następujący sposób: public void characters(char[] ch, int start, int end) throws SAXException { for (int i=0; i
Błąd polega na odczytaniu tablicy od początku do końca. To naturalne zachowanie programisty, wynikające z przyzwyczajeń programowania w Javie, C czy innym języku, gdzie iteracje po pętlach są często spotykane. Jednak w przypadku zdarzenia SAX takie postępowanie moŜe powodować powaŜny błąd. Parsery SAX przekazują początek i koniec tablicy, z której naleŜy korzystać we wszystkich pętlach czytających z tej tablicy. W ten sposób dane tekstowe przetwarzane są na niŜszym poziomie, co umoŜliwia optymalizację pracy parsera (np. odczytywanie danych z wyprzedzeniem oraz wielokrotne wykorzystanie tej samej tablicy). Wszystko to jest poprawnym działaniem w interfejsie SAX, poniewaŜ zakłada się, Ŝe aplikacja nie będzie próbowała „wybiegać przed” parametr end przekazany do wywołania. Tego typu błąd powoduje wyświetlenie na ekranie (lub przetworzenie przez aplikację) przypadkowych danych. Pętla wygląda zupełnie zwyczajnie i kompiluje się „bez zająknięcia”, a więc jest to prawdziwa pułapka, na którą musi juŜ uwaŜać sam programista.

Co dalej? Teraz Czytelnik powinien juŜ dobrze rozumieć zasady działania interfejsów SAX oraz sposób, w jaki współdziałają z parserem XML i procesem przetwarzania — wszystko w kontekście parsera nie sprawdzającego poprawności dokumentu XML. Interfejsy te mają kluczowe znaczenie dla reszty zagadnień opisywanych w tej ksiąŜce — w następnych rozdziałach zostaną poszerzone wiadomości o interfejsie SAX, a w programie zastosowane będą dodatkowe klasy tego interfejsu. W następnym rozdziale omówione zostaną zagadnienia związane z zawęŜaniem XML-a, procesem sprawdzania poprawności dokumentu, a takŜe przedstawione zostaną definicje DTD i schematy.

89

4 ZawęŜanie danych XML Nauka XML-a, zarówno jako reprezentacji danych, jak i materiału wykorzystywanego przez aplikację w Javie, to proces wieloetapowy. Kolejne poznawane cechy XML-a lub technologii siostrzanych przyczyniają się do odkrywania całych pokładów wiedzy o tym języku. Istnieje wiele projektów i specyfikacji związanych z XML-em; pojawia się pokusa „poznania wszystkiego”. A kiedy w końcu wydaje nam się, Ŝe poznaliśmy wszystkie strony zagadnienia, pojawiają się nowe wersje... Im lepiej jednak rozumiemy zasadę działania poszczególnych komponentów składających się na krajobraz XML-a, tym lepiej przygotowani jesteśmy na wszelkie nowinki w naszym programistycznym warsztacie. Pamiętając o tym, na jakiś czas porzucimy teraz język Java i wrócimy do specyfikacji związanych z samym XML-em. W rozdziałach 2. i 3. uzyskaliśmy wiedzę, która powinna wystarczyć do stworzenia poprawnie sformatowanego dokumentu oraz do późniejszej manipulacji (w ograniczonym zakresie) tym dokumentem z poziomu Javy. Powinniśmy takŜe rozumieć, jak przetwarzane są dokumenty XML i jak w tym procesie moŜna wykorzystać klasy SAX. W tym rozdziale zostanie omówione zawęŜanie dokumentów XML, a w następnym — wpływ zawęŜania na przetwarzanie takiego dokumentu w Javie.

Po co zawęŜać dane XML? Wypada najpierw wytłumaczyć, do czego potrzebne są Czytelnikowi wiadomości dotyczące definicji DTD i schematów. Niektórzy uŜytkownicy XML-a twierdzą, Ŝe w ogóle nie ma potrzeby zawęŜania dokumentów XML i sprawdzania ich poprawności. Jak juŜ powiedzieliśmy, poprawny dokument XML spełnia wymogi zawęŜeń na niego narzuconych przez odpowiednią definicję DTD lub schemat. Napisaliśmy równieŜ, Ŝe choć dokument jest poprawnie sformatowany, to nie musi jeszcze być poprawny. Po cóŜ więc zadawać sobie trud tworzenia definicji DTD lub schematu, który narzuca dodatkowe reguły na dane XML?

Komentarze w programach Jako programujący w Javie, Czytelnik zapewne potrafi juŜ dokumentować swój kod za pomocą narzędzia Javadoc lub komentarzy w samym kodzie. Prawdopodobnie wie takŜe, jak waŜne jest dokumentowanie własnej pracy — być moŜe na kogoś spadnie obowiązek czytania naszego kodu,

90 poprawiania, czy po prostu zrozumienia. Komentowanie kodu jest jeszcze waŜniejsze w projektach open source. Być moŜe zdarzyło nam się kiedyś, Ŝe poganiani terminami nie byliśmy zbyt rozlewni w komentowaniu programu. A trzy miesiące później programista, któremu powierzono zadanie kontynuowania projektu, zasypywał nas telefonami o przeznaczenie danego fragmentu kodu. Dobrze, jeśli jeszcze pamiętaliśmy; gorzej, jeśli dawno juŜ zapomnieliśmy, jak udało nam się zrobić „tę sztuczkę”. Właśnie w takich chwilach poznajemy wartość dokumentacji. Dane XML to z pewnością nie kod. W wyniku zagnieŜdŜania i innych reguł składniowych niemal zawsze łatwiej jest zrozumieć dokument XML niŜ fragment kodu w Javie. JednakŜe nie naleŜy zakładać, Ŝe to, jak my widzimy naszą reprezentację danych, będzie identycznie postrzegane przez innych. Świetnie obrazuje to plik XML z przykładu 4.1.

Przykład 4.1. Dwuznaczny plik XML SprzedaŜ #CC9900 Arial

Tu idzie cała zawartość.

Przeznaczenie powyŜszego pliku wydaje się zupełnie oczywiste. Za jego pomocą aplikacja otrzymuje informacje o sposobie wyświetlenia konkretnego ekranu u klienta. Podany jest kolor, rodzaj czcionki oraz zawartość ekranu. GdzieŜ tutaj dwuznaczność? CóŜ, staje się ona ewidentna dopiero po obejrzeniu innego dokumentu wykorzystywanego w tej samej aplikacji (przykład 4.2).

Przykład 4.2. Mniej dwuznaczny plik XML SprzedaŜ #CC9900 Arial Komunikaty #9900FF Arial Nowości #EECCEE Helvetica

Tu idzie cała zawartość.

I nagle nasza interpretacja pierwszego pliku nie wydaje się juŜ poprawna. Element ekran nie moŜe reprezentować bieŜącego ekranu, bo w drugim przykładzie widzimy aŜ trzy takie elementy.

91 W rzeczywistości aplikacja tworzy na górze strony odsyłacze do dostępnych ekranów i właśnie element ekran opisuje, jak odsyłacze te mają wyglądać — podana jest nazwa odsyłacza, kolor fragmentu ekranu i czcionka. W pierwszym przypadku tak się złoŜyło, Ŝe był tylko jeden ekran, do którego tworzono odsyłacz, i stąd to zamieszanie. Tylko autor dokumentu XML lub programista aplikacji od razu zrozumieliby, o co tutaj chodzi. ZawęŜanie dokumentów XML umoŜliwia udokumentowanie takich dwuznacznych sytuacji. Gdybyśmy wiedzieli, Ŝe w danej stronie XML dozwolony jest tylko jeden element ekran, moglibyśmy bezpiecznie poczynić takie załoŜenie, jakie zrobiliśmy odnośnie pierwszego przykładu. Gdybyśmy jednak wiedzieli, Ŝe dozwolonych jest wiele elementów ekran, to nawet patrząc tylko na pierwszy przykład moglibyśmy trafniej odgadnąć przeznaczenie dokumentu. Innymi słowy, poprawnie sformatowany dokument XML zawiera słowa występujące w słowniku. Słowa te mają pewne znaczenia, ale mogą być wykorzystywane w róŜny sposób. Jako przykład weźmy słowa: „Lis kot bieg chleb ser”. Poprawność (ang. validity) dokumentu daje nam gwarancje, Ŝe „słowa” te (elementy i atrybuty dokumentu XML) zostaną złoŜone w sensowny sposób: „Lisy i koty biegną w kierunku chleba z serem”. Udokumentowanie „poprawnych” czy „właściwych” połączeń elementów i atrybutów to właśnie zadanie definicji DTD lub schematu. UmoŜliwiają one samodokumentowanie się danych XML — teraz juŜ nie tylko my będziemy wiedzieli, co właściwie chcieliśmy przekazać za pomocą danych XML.

Przenośność ZawęŜanie XML-a pomaga nie tylko zrozumieć sposób reprezentacji danych innym osobom; pomaga takŜe zrozumieć dane innym aplikacjom. Wspomnieliśmy o tym juŜ wcześniej — jeśli weźmiemy dwie dowolne aplikacje, to nie moŜemy zakładać, Ŝe korzystają one ze wspólnych zasobów. Mówiąc inaczej, program, który utworzył dokument XML w jednej aplikacji, moŜe nie być dostępny w drugiej; ta druga aplikacja „nie rozumie” logiki, według której powstał dokument XML. Druga aplikacja musi więc określić sama, jaki typ danych jest przekazywany za pośrednictwem dokumentu XML. Nie mając Ŝadnych wskazówek, druga aplikacja mogłaby tylko zakładać, co „autor miał na myśli” — i często byłyby to załoŜenia błędne. Przypomina to nieco problemy z językiem C, których starali się uniknąć twórcy Javy. Java, niezaleŜna od platformy i nie polegająca na kodzie własnym, jest obecnie najbardziej przenośnym językiem programowania. Wynika to stąd, Ŝe nałoŜono szereg zawęŜeń na to, co Java moŜe robić i zawęŜenia te działają na wszystkich platformach. Takie szczegóły implementacyjne jak zarządzanie pamięcią czy wątkami pozostawiono do rozwiązania poszczególnym platformom, ale interfejs do obsługi tych zadań przez programistę jest zawsze taki sam. ZawęŜanie dokumentów za pomocą definicji DTD lub schematów gwarantuje podobną przenośność w języku XML. Przypomnijmy sobie pierwszy z dwóch powyŜszych przykładów — gdyby inna aplikacja mogła uzyskać dostęp do zasobu opisującego dozwolone formaty przetwarzanych danych, mogłaby przetworzyć te dane za pomocą narzędzi XML-a. PoniewaŜ zawęŜenia dokumentu nie zostały zakodowane bezpośrednio w aplikacji (pierwszej czy drugiej), logika aplikacji nie zmieni się po zmianie formatu dokumentu. Definicja DTD lub schemat mógłby ulec zmianie, ale poniewaŜ pracujemy na tekstowym opisie zawęŜeń, aplikacja mogłaby natychmiast wykorzystać dokument o zmienionej strukturze, bez konieczności modyfikacji samej aplikacji. W ten sposób uzyskuje się przenośność danych XML bez konieczności ingerencji w kod aplikacji — tak jak próbuje się unikać kodu własnego w programach w Javie.

92 Czy to na potrzeby dokumentacji, przenośności pomiędzy aplikacjami i systemami, czy po prostu ze względu na bardziej restrykcyjne sprawdzanie poprawności danych XML, zawęŜanie przydaje się w niemal wszystkich przypadkach. Przeciwnicy zawęŜania mają rację właściwie tylko w jednym — sprawdzanie poprawności danych ma duŜy wpływ na wydajność całego procesu. JednakŜe w wielu strukturach publikacji, np. takich jak Apache Cocoon, moŜna określić, czy dany dokument ma być sprawdzany pod kątem poprawności, czy nie. Oznacza to, Ŝe tworzenie dokumentu moŜna przeprowadzać przy włączonym sprawdzaniu poprawności i wyłączyć je dopiero wtedy, gdy struktura dokumentu została juŜ solidnie przetestowana. Aplikacje otrzymujące dane równieŜ mogą sprawdzać lub nie sprawdzać poprawności dokumentu. W razie potrzeby zawsze jest to moŜliwe, bo dokument ten zawierać będzie odwołanie do definicji DTD lub schematu. A więc moŜliwe jest korzystanie ze sprawdzania składni bez jednoczesnego zmniejszania wydajności aplikacji. Wcześniej naleŜy jednak sprawdzić, czy funkcja włączania-wyłączania sprawdzania jest dostępna w wykorzystywanej strukturze publikacji. W systemach produkcyjnych sprawdzanie poprawności oznacza wyŜszą jakość aplikacji typu firma-firma (ang. business-to-business). Sprawdzanie poprawności daje gwarancję, Ŝe dane otrzymane z innych aplikacji — często takich, na które nie mamy wpływu — są poprawnie sformatowane. Dzięki temu unikamy błędów wynikających z niepoprawnego formatu danych wejściowych. Tutaj definicje DTD i schematy są wprost nieocenione.

Definicje typu dokumentu Jak juŜ to zostało powiedziane, dokument XML ma niewielką wartość bez towarzyszącej mu definicji DTD. XML w wydajny sposób opisuje dane, a DTD przygotowuje te dane do uŜycia w wielu róŜnych programach poprzez zdefiniowanie ich struktury. W tej części ksiąŜki zajmiemy się konstrukcjami DTD. W funkcji przykładowego pliku XML znów zostanie wykorzystany fragment spisu treści niniejszej ksiąŜki, dla którego zbudujemy definicję DTD. Zadaniem definicji DTD jest określenie sposobu formatowania danych. Zdefiniowany musi zostać kaŜdy element dozwolony w danym dokumencie XML, sposoby występowania i zagnieŜdŜania elementów, a takŜe zewnętrzne encje. Tak naprawdę w definicji DTD moŜna określić jeszcze wiele innych aspektów dokumentu, ale tutaj skoncentrujemy się na tych podstawowych. Poznamy konstrukcje oferowane przez DTD — za ich pomocą zawęzimy nasz przykładowy plik z rozdziału 2. PoniewaŜ do pliku tego będziemy się często odwoływali w tym rozdziale, warto przytoczyć go tutaj jeszcze raz (przykład 4.3).

Przykład 4.3. Plik XML zawierający spis treści Java i XML Wprowadzenie Co to jest?

93 Jak z tego korzystać? Dlaczego z tego korzystać? Co dalej? Tworzenie dokumentów XML Dokument XML Nagłówek Zawartość Co dalej? Przetwarzanie kodu XML Przygotowujemy się Czytniki SAX Procedury obsługi zawartości Procedury obsługi błędów Lepszy sposób ładowania parsera "Pułapka!" Co dalej? Struktury publikacji WWW Wybór struktury Instalacja Korzystanie ze struktury publikacji XSP Cocoon 2.0 i dalej Co dalej? &OReillyCopyright;

Określanie elementów Najpierw zajmiemy się określaniem, które elementy są w naszym dokumencie dozwolone. Chcemy, aby definicja DTD umoŜliwiała autorom umieszczanie w naszym dokumencie takich elementów jak JavaXML:Ksiazka i JavaXML:Spis, ale nie JavaXML:jas czy JavaXML:malgosia. Określenie zestawu dozwolonych elementów oznacza nadanie takiemu dokumentowi znaczenia semantycznego; innymi słowy określamy dopuszczalny (sensowny) kontekst. Najpierw naleŜy więc stworzyć listę dopuszczalnych elementów. Najprostszym sposobem jest przejrzenie dokumentu i odnotowanie kaŜdego wykorzystanego elementu. Dobrze jest takŜe zdefiniować przeznaczenie poszczególnych znaczników. Co prawda na określenie przeznaczenia elementów

94 nie pozwala bezpośrednio DTD (chyba Ŝe za pomocą komentarzy — to całkiem niezłe rozwiązanie), ale coś takiego uprościłoby pracę autora DTD. W tabeli 4.1 przedstawiono pełne zestawienie elementów dokumentu contents.xml.

Tabela 4.1. Elementy dozwolone w naszym dokumencie XML Nazwa elementu

Znaczenie

JavaXML:Ksiazka JavaXML:Tytul JavaXML:Spis JavaXML:Rozdzial JavaXML:Naglowek JavaXML:Temat JavaXML:PodzialSekcji JavaXML:Copyright

element główny tytuł dokumentowanej ksiąŜki oznacza spis treści ksiąŜki rozdział ksiąŜki nagłówek (tytuł) rozdziału tematyka rozdziału podział pomiędzy rozdziałami oznaczający nową część ksiąŜki informacje o prawach autorskich

Teraz poszczególne elementy moŜemy zdefiniować w DTD. Wykonujemy to za pomocą następujących konstrukcji:

Konstrukcja [Nazwa elementu] to faktyczna nazwa elementu, taka jak w tabelce powyŜej. Powinna ona, podobnie jak w tabeli, zawierać przedrostek przestrzeni nazw. W DTD nie istnieje pojęcie elementu z przedrostkiem przestrzeni nazw ani odwzorowania przestrzeni nazw według identyfikatora URI. Nazwa elementu ma postać albo samej nazwy (gdy nie uŜyto przestrzeni nazw), albo nazwy poprzedzonej przedrostkiem i dwukropkiem. Najbardziej uŜytecznym fragmentem jest konstrukcja [Definicja/typ elementu]. Tutaj definiujemy element, nadając mu „typ” i określając, czy są to „czyste dane”, czy teŜ typ złoŜony z danych i innych elementów. Najmniej restrykcyjnym typem elementu jest ten określony za pomocą słowa kluczowego ANY. Wtedy element moŜe zawierać dane tekstowe, elementy zagnieŜdŜone, lub teŜ dowolną (prawidłową) kombinację ich obu. Ta wiedza umoŜliwia juŜ zdefiniowanie wszystkich elementów dokumentu XML, choć moŜe w niezbyt uŜyteczny sposób. W przykładzie 4.4 jest przedstawiony początek definicji DTD naszego dokumentu XML.

Przykład 4.4. „Gołe” definicje elementów w DTD
JavaXML:Ksiazka ANY> JavaXML:Tytul ANY> JavaXML:Spis ANY> JavaXML:Rozdzial ANY> JavaXML:Naglowek ANY> JavaXML:Temat ANY> JavaXML:PodzialSekcji ANY> JavaXML:Copyright ANY>

Oczywiście, taka prosta definicja DTD, nie opisująca ani atrybutów, ani encji, jest niezbyt przydatna. Określony jest kaŜdy dozwolony element, ale nie ma mowy ani o typach tych dokumentów, ani o dozwolonym zagnieŜdŜaniu. MoŜna stworzyć dokument zgodny z tą DTD, a jednak zupełnie bezsensowny (przykład 4.5).

95

Przykład 4.5. Dokument zgodny z DTD, ale bezuŜyteczny Oto moja ksiąŜka Rozdział pierwszy A tu inna część

W powyŜszym fragmencie zostały uŜyte wyłącznie elementy dozwolone w DTD, a jednak jego struktura nie jest poprawna. Wynika to stąd, Ŝe nasza definicja DTD nie określa, w jaki sposób mogą być zagnieŜdŜane elementy i które z nich mogą zawierać dane tekstowe.

ZagnieŜdŜanie elementów Jedną z najwaŜniejszych cech struktury dokumentu XML jest zagnieŜdŜanie elementów. Naszą wcześniejszą tabelkę rozszerzymy teraz o informację o dozwolonym zagnieŜdŜaniu elementów. W ten sposób powstanie hierarchia elementów, którą następnie zdefiniujemy w DTD. Spójrzmy na tabelę 4.2.

Tabela 4.2. Hierarchia elementów Nazwa elementu JavaXML:Ksiazka

Dozwolone zagnieŜdŜone elementy

JavaXML:Tytul JavaXML:Spis JavaXML:Copyright JavaXML:Tytul brak JavaXML:Spis JavaXML:Rozdzial JavaXML:PodzialSekcji JavaXML:Rozdzial JavaXML:Naglowek JavaXML:Temat JavaXML:Naglowek brak JavaXML:Temat brak JavaXML:PodzialSekcj brak i JavaXML:Copyright brak

Znaczenie element główny

tytuł dokumentowanej ksiąŜki oznacza spis treści ksiąŜki rozdział ksiąŜki nagłówek (tytuł) rozdziału tematyka poruszana w rozdziale podział pomiędzy rozdziałami oznaczający nową część ksiąŜki informacje o prawach autorskich

Teraz moŜemy juŜ określić sposób zagnieŜdŜania w DTD. Robimy to za pomocą następującej konstrukcji:

W tym przypadku typem elementu staje się lista elementów rozdzielonych przecinkami. Istotna jest kolejność elementów, z czego wynika dalsze zawęŜenie dokumentu XML. W ten sposób gwa-

96 rantujemy, Ŝe np. element copyright znajdzie się na końcu ksiąŜki, albo Ŝe tytuł występuje przed spisem. Teraz moŜemy naszą definicję DTD wzbogacić o opis zagnieŜdŜania (przykład 4.6).

Przykład 4.6. Definicja DTD określająca hierarchię elementów
JavaXML:Tytul ANY> JavaXML:Spis (JavaXML:Rozdzial, JavaXML:PodzialSekcji)> JavaXML:Rozdzial (JavaXML:Naglowek, JavaXML:Temat)> JavaXML:Naglowek ANY> JavaXML:Temat ANY> JavaXML:PodzialSekcji ANY> JavaXML:Copyright ANY>

Choć niektóre elementy — te, które zawierają przetwarzane dane — nie uległy zmianie, stworzyliśmy hierarchię, która nadaje znaczenie zawęŜonemu dokumentowi. Wcześniejszy bezsensowny przykład teraz traktowany byłby juŜ jako niepoprawny. WciąŜ jednak jest tutaj sporo problemów związanych z dozwolonymi typami danych w pozostałych elementach.

Przetwarzane dane Typ elementu wykorzystywany do określania danych tekstowych to #PCDATA. Nazwa tego typu wywodzi się ze słów Parsed Character Data (przetwarzane dane tekstowe). Za jego pomocą oznaczamy elementy zawierające dane tekstowe, które mają być w zwyczajny sposób traktowane przez parser XML. Zastosowanie tego typu wyklucza jednak moŜliwość obecności w elemencie innych, zagnieŜdŜonych elementów. Tego typu sytuacje zostaną przedstawione dalej. Tymczasem moŜemy juŜ zmienić elementy określające tytuł, nagłówek i temat — w nich mogą być zawarte dane tekstowe (przykład 4.7).

Przykład 4.7. Definicja DTD opisująca hierarchię elementów i elementy zawierające dane tekstowe
JavaXML:Tytul (#PCDATA)> JavaXML:Spis (JavaXML:Rozdzial, JavaXML:PodzialSekcji)> JavaXML:Rozdzial (JavaXML:Naglowek, JavaXML:Temat)> JavaXML:Naglowek (#PCDATA)> JavaXML:Temat (#PCDATA)> JavaXML:PodzialSekcji ANY> JavaXML:Copyright ANY>

Elementy puste Oprócz elementów zawierających dane tekstowe oraz tych, które zawierają inne elementy, mamy jeden element, JavaXML:PodzialSekcji, który nie ma zawierać Ŝadnych danych. Oczywiście, moŜna by określić, Ŝe element ten zawiera przetwarzane dane tekstowe i nigdy ich tam nie wstawiać, ale nie tak naleŜy korzystać z zawęŜeń. Lepiej jawnie określić, Ŝe element ma być pusty — w ten sposób zapobiegamy przypadkowym błędom. Tym razem odpowiednie słowo kluczowe

97 to EMPTY. Nie musi ono pojawiać się w nawiasach, poniewaŜ określa pewien typ i nie moŜe być łączone z innymi elementami, na co — jak wkrótce zobaczymy — pozwalają właśnie nawiasy. Wprowadźmy więc kolejną poprawkę do definicji DTD (przykład 4.8).

Przykład 4.8. Definicja DTD z określonym elementem EMPTY
JavaXML:Tytul (#PCDATA)> JavaXML:Spis (JavaXML:Rozdzial, JavaXML:PodzialSekcji)> JavaXML:Rozdzial (JavaXML:Naglowek, JavaXML:Temat)> JavaXML:Naglowek (#PCDATA)> JavaXML:Temat (#PCDATA)> JavaXML:PodzialSekcji EMPTY> JavaXML:Copyright ANY>

Encje Ostatnim elementem, który naleŜy uściślić, jest JavaXML:Copyright. Jak juŜ to było wspomniane, element ten faktycznie zawiera encję odwołującą się do innego pliku, który w tym miejscu ma zostać zawarty. Kiedy dokument XML „zobaczy” &OReillyCopyright;, będzie usiłował odnaleźć encję OReillyCopyright w DTD, która w naszym przypadku powinna stanowić odwołanie do zewnętrznego pliku. Plik ten zawiera informacje o prawach autorskich wszystkich ksiąŜek udokumentowanych za pomocą języka XML. Zadaniem DTD jest określenie miejsca połoŜenia pliku oraz sposobu uzyskania dostępu do niego. Tutaj zakładamy, Ŝe plik z prawami autorskimi znajduje się na dysku lokalnym i Ŝe do niego właśnie będziemy się odwoływali. Encje określane są w ramach definicji DTD za pomocą następującego zapisu:

ZauwaŜmy, Ŝe umoŜliwia się podanie zestawu znaków podstawianych (zamiast pliku zewnętrznego). To właśnie w ten sposób określane są „sekwencje unikowe” w dokumentach XML: ">"> ...

Tak więc jeśli nasza informacja o prawach autorskich byłaby krótka, moglibyśmy napisać:

JednakŜe my zamierzamy uŜyć dłuŜszego tekstu, a więc wygodniej będzie pobrać go z zewnętrznego pliku. W ten sposób moŜemy z niego korzystać w wielu dokumentach bez konieczności duplikowania danych w poszczególnych definicjach DTD. Wymaga to podania identyfikatora zasobu systemowego, dlatego korzystamy tutaj z następującego zapisu:

Tak jak w przypadku dokumentu XML, URI moŜe być zarówno zasobem lokalnym, jak i sieciowym. W naszym przypadku odwołujemy się do pliku znajdującego się na serwerze zewnętrznym, więc musimy zastosować adres URL:

98 Dzięki takiemu zapisowi parser XML rozpozna referencję OReillyCopyright w dokumencie i odpowiednio przetłumaczy ją w czasie przetwarzania. Z tego właśnie powodu musieliśmy ten fragment oznaczyć jako komentarz w rozdziale 3. W następnym rozdziale usuniemy symbole komentarza i zobaczymy, w jaki sposób parser sprawdzający poprawność składni obsłuŜy tę encję z wykorzystaniem definicji DTD. Na koniec w elemencie zawierającym encję musimy podać, Ŝe oczekujemy w tym miejscu przetwarzanych danych tekstowych:

Powtórz to, a... Ostatnią waŜną konstrukcją, jaką omówimy w związku z definicjami DTD, jest opis grupowania, wielokrotnego występowania i dopuszczalnych kombinacji w ramach elementu. Innymi słowy, chodzi tu np. o sytuacje, w których element X moŜe wystąpić tylko raz, lub teŜ po elemencie Y musi wystąpić element Z. To niezwykle istotne konstrukcje DTD. Domyślnie, jeśli nie podaliśmy w elemencie specjalnych modyfikatorów, element moŜe wystąpić dokładnie raz:

W tym przypadku ZagniezdzonyElement ma wystąpić tylko raz, a po nim koniecznie musi znajdować się InnyElement. Jeśli struktura dokumentu XML jest inna, to dokument ten nie jest poprawny. Aby zmienić to domyślne zawęŜenie, moŜna zastosować specjalne modyfikatory.

Zero, jeden lub więcej Najczęściej do elementu dodawany jest operator rekurencji. UmoŜliwia on określenie, czy dany element ma się pojawić zero lub więcej razy, jeden lub więcej razy, wcale lub (ustawienie domyślne) dokładnie raz. W tabeli 4.3 przedstawione są operatory rekurencyjne i ich znaczenia.

Tabela 4.3. Operatory rekurencyjne Operator

Opis

[Domyślnie] ? + *

musi wystąpić dokładnie raz musi wystąpić raz albo wcale musi wystąpić przynajmniej raz (1 ... n razy) moŜe wystąpić dowolną liczbę razy (0 ... n razy)

Modyfikatory dodawane są na końcu nazwy elementu. W naszym poprzednim przykładzie, aby zezwolić na jedno lub więcej wystąpień elementu ZagniezdzonyElement, a potem na tylko jedno (lub wcale) wystąpienie elementu InnyElement, naleŜałoby uŜyć następującej konstrukcji:

Wtedy taki zapis XML byłby zupełnie poprawny: Jeden Dwa

99 W definicji DTD, którą tworzymy, z taką sytuacją mamy do czynienia w przypadku elementu JavaXML:Rozdzial. Chcemy, aby nagłówek rozdziału (JavaXML:Naglowek) mógł wystąpić raz lub wcale, chcemy równieŜ pozwolić na wystąpienie jednego lub więcej elementów JavaXML:Temat. Wykorzystujemy modyfikatory rekurencyjne:

Ta prosta zmiana czyni naszą reprezentację rozdziału w XML bardziej realistyczną. Musimy takŜe dokonać zmian w definicji elementu JavaXML:Spis. MoŜe się w nim pojawić jeden lub więcej rozdziałów, a potem, ewentualnie, podział sekcji. Podział jest opcjonalny, bo ksiąŜka moŜe się składać wyłącznie z rozdziałów. Rekurencję rozdziałów i podziałów sekcji zapiszemy następująco:

WciąŜ jednak definicja DTD „nie wie”, Ŝe po elemencie JavaXML:PodzialSekcji moŜe wystąpić więcej rozdziałów. Chcemy, aby cała ta struktura mogła pojawić się kilkakrotnie. Po rozdziale podział sekcji, potem znów rozdziały i znów podziały sekcji. Musimy zastosować grupowanie.

Grupowanie Grupowanie umoŜliwia rozwiązywanie problemów takich jak ten z zagnieŜdŜaniem elementów wewnątrz JavaXML:Spis. Często rekurencja dotyczy bloku elementów, a nie jednego elementu. Dlatego operatory rekurencji moŜna dodawać takŜe do grup elementów. Grupę elementów tworzymy poprzez ujęcie elementów w nawiasy. Jeśli w tej chwili Czytelnikowi przypomniały się zajęcia z języka LISP, to niech się nie zamartwia — w naszych przykładach wszystko będzie dosyć proste, a liczba nawiasów nie wymknie się spod kontroli. Oczywiście, zagnieŜdŜanie nawiasów jest dozwolone. Tak więc, aby stworzyć grupę elementów, zastosujemy następującą konstrukcję:

Do kaŜdej grupy (a nie tylko do poszczególnych jej elementów) moŜna dopisać modyfikator. W opisywanym scenariuszu musimy tak zmienić zapis, aby moŜliwe było wielokrotne wystąpienie grupy zawierającej elementy rozdziału i podziału sekcji:

Teraz dozwolone są juŜ róŜne kombinacje — kilka rozdziałów plus jeden podział sekcji i to wszystko powtórzone wiele razy lub teŜ nie powtórzone wcale. MoŜliwy jest takŜe przypadek, w którym wystąpią same tylko rozdziały, bez podziałów sekcji. JednakŜe tutaj sprawa nie jest zupełnie jasna (według naszego opisu w DTD). Lepiej byłoby określić, Ŝe pojawić się moŜe jeden lub więcej rozdziałów lub taka struktura. Zachowanie DTD się nie zmieni, ale z pewnością definicja będzie bardziej czytelna. Aby to uzyskać, naleŜy wprowadzić pojęcie „lub”.

To lub tamto W definicjach DTD moŜliwe jest stosowanie pojęcia „lub”, oznaczanego symbolem kreski pionowej. Symbol ten jest często wykorzystywany w połączeniu z grupowaniem. Częstym, choć niekoniecznie udanym przykładem uŜycia operatora „lub” jest umoŜliwienie wystąpienia wewnątrz elementu pewnego innego elementu (elementów) lub danych:

W przypadku tej definicji DTD oba poniŜsze fragmenty będą poprawne:

100 Jeden Dwa Dane tekstowe

Nie zaleca się jednak stosowania takiego rozwiązania, gdyŜ wówczas staje się niejasne znaczenie elementu zamykającego. Zazwyczaj element powinien zawierać dane tekstowe, dane przetwarzane lub inne elementy — ale nie wszystko razem. W naszym dokumencie zaleŜy nam na bardziej przejrzystej reprezentacji elementu JavaXML: Spis. Zastosujemy następujące rozwiązanie:

Teraz jest juŜ jasne, Ŝe moŜe pojawić się tutaj albo pewna liczba rozdziałów, albo rozdziały, po których następuje podział sekcji. W ten sposób tworzy się przejrzyście udokumentowaną definicję, a jednocześnie zapewnia odpowiednie zawęŜenie dokumentu XML. Teraz nasze elementy XML są juŜ poprawnie określone i zawęŜone. Definicja przedstawiona w przykładzie 4.9 powinna działać bezproblemowo na naszym przykładowym dokumencie. Pozostały nam jeszcze definicje argumentów, które omawiamy poniŜej.

Przykład 4.9. Opis elementów w definicji DTD

Definiowanie atrybutów Po tym dość dokładnym omówieniu sposobu definiowania elementów moŜemy przejść do definiowania atrybutów. PoniewaŜ tutaj nie będziemy mieli do czynienia z zagnieŜdŜaniem, czynność ta jest nieco prostsza niŜ opisywanie elementów. Nie będziemy teŜ potrzebowali operatorów rekurencji, poniewaŜ o tym, czy obecność danego atrybutu jest wymagana, mówi określone słowo kluczowe. Definicje atrybutów przyjmują następującą formę:

Pierwsze dwa parametry, nazwa elementu i atrybutu, nie powinny sprawiać trudności. Za pomocą jednej konstrukcji ATTLIST dowolnemu elementowi moŜemy przypisać wiele atrybutów. Taki

101 schemat jak powyŜej zostanie dodany teraz do naszej definicji DTD, dzięki czemu lepiej będzie przedstawiona struktura opisywania atrybutów. Najlepiej definicje atrybutów dodawać zaraz po opisie elementu (to kolejny krok w kierunku utworzenia samodokumentującego się opisu DTD). Spójrzmy na przykład 4.10.

Przykład 4.10. Definicja DTD opisująca elementy i zawierająca ogólny szkielet opisów atrybutów

Teraz zdefiniujmy typy dozwolone dla poszczególnych atrybutów.

Typy atrybutów Wartością wielu atrybutów będą dane tekstowe. To najprostszy typ wartości atrybutu, ale teŜ najmniej zawęŜony. Typ ten określamy za pomocą słowa kluczowego CDATA (Character Data — dane tekstowe). Jest to ta sama konstrukcja CDATA, która w samym dokumencie XML reprezentuje dane wchodzące w skład „sekwencji unikowej”. Typ ten jest zazwyczaj uŜywany wtedy, gdy atrybut moŜe przyjąć dowolną wartość i słuŜy jako komentarz lub dodatkowa informacja o danym elemencie. Wkrótce Czytelnik przekona się, Ŝe lepszym rozwiązaniem jest zdefiniowanie zestawu wartości dozwolonych dla atrybutu danego elementu. W naszym dokumencie typem tekstowym jest atrybut xmlns. Co prawda xmlns to słowo kluczowe XML oznaczające deklarację przestrzeni nazw, ale wciąŜ jest to atrybut, którego poprawność ma zostać sprawdzona — i musi zostać opisany w definicji DTD. Atrybut podRozdzialy elementu JavaXML:Temat przyjmuje takŜe wartość tekstową:

102

Następny typ atrybutu (jeden z najczęściej uŜywanych) to wyliczenie. UmoŜliwia określenie konkretnych wartości atrybutu. Wartości nie wymienione w wyliczeniu powodują, Ŝe dokument XML jest niepoprawny. Rozwiązanie to przydaje się wszędzie tam, gdzie zestaw wartości atrybutu znamy juŜ w czasie tworzenia dokumentu i umoŜliwia on bardzo ścisłe zawęŜenie definicji elementu. Taki typ ma nasz atrybut tematyka, poniewaŜ dozwolone są dla niego jedynie wartości „Java” lub „XML”. Wartości dozwolone umieszczane są w nawiasach i rozdzielane znakiem operatora „lub”, podobnie jak przy określaniu zagnieŜdŜania elementów:

Być albo nie być ... W definicji atrybutu naleŜy jeszcze określić, czy atrybut ten jest w danym elemencie wymagany. SłuŜą do tego trzy słowa kluczowe: #IMPLIED, #REQUIRED lub #FIXED. Atrybut niejawny (ang. implied) nie jest wymagany. Takim modyfikatorem moŜna określić atrybut podRozdzialy, jako Ŝe nie jest on wymagany do stworzenia poprawnego dokumentu:

Jeśli chodzi o atrybut xmlns, to chcemy zagwarantować, Ŝeby autor zawartości zawsze określał przestrzeń nazw dla danej ksiąŜki. W przeciwnym razie nasze przedrostki określające przestrzeń nazw na nic by się nie zdały. W takim przypadku naleŜy zastosować słowo #REQUIRED (wymagany). Gdyby atrybut ten nie został zawarty w elemencie JavaXML:Ksiazka, dokument nie byłby poprawny:

Ostatnie słowo kluczowe, #FIXED, nie jest zbyt często uŜywane w aplikacjach. Najczęściej stosuje się je w systemach bazowych; określa ono, Ŝe uŜytkownik nie moŜe nigdy zmienić wartości danego atrybutu. Format jest tutaj następujący:

PoniewaŜ atrybut ten nie przydaje się w aplikacjach dynamicznych (nie jest moŜliwa jego zmiana), nie będziemy się nim tutaj zajmować. Do omówienia pozostał jeszcze atrybut tematyka. Wymieniliśmy wszystkie moŜliwe wartości, jakie moŜe przyjmować, ale poniewaŜ w tej ksiąŜce koncentrujemy się głównie na Javie, chcie-

103 libyśmy, aby autor nie musiał jawnie definiować atrybutu jako „Java” w tych rozdziałach, w których rzeczywiście Java jest głównym tematem. W ksiąŜce składającej się z dwudziestu czy trzydziestu rozdziałów ciągłe wpisywanie atrybutu moŜe okazać się męczące. Wyobraźmy sobie listę ksiąŜek w bibliotece naukowej, w której jako temat kaŜdej ksiąŜki naleŜałoby podać „nauka”! Duplikowanie danych wydłuŜa proces, a więc wymaganie podawania atrybutu za kaŜdym razem nie jest dobrym rozwiązaniem. Chcemy więc przypisać atrybutowi pewną domyślną wartość, kiedy Ŝadna wartość nie zostanie podana przez autora (i nie załatwia tego słowo #IMPLIED, które powoduje, Ŝe atrybutowi nie zostaje przypisana Ŝadna wartość). Domyślną wartość moŜna określić poprzez wpisanie jej w cudzysłowach zamiast wpisania słowa kluczowego modyfikatora. Jeśli typem atrybutu jest wyliczanie (enumeration), wartość ta powinna być jednym z wymienionych łańcuchów znaków. Zdefiniujmy więc nasz atrybut tematyka:

Nasza definicja DTD jest juŜ gotowa! Składnia definicji DTD moŜe wydawać się nieco dziwaczna, ale mam nadzieję, Ŝe Czytelnikowi nie sprawiło trudności śledzenie kolejnych etapów definiowania elementów, atrybutów i encji. Nie omówiliśmy oczywiście wszystkich zagadnień związanych z definicjami DTD, poniewaŜ niniejsza ksiąŜka nie traktuje o samym XML-u, ale o Javie i XML-u. Mam jednak nadzieję, Ŝe przykładowa definicja DTD jest zrozumiała i Ŝe Czytelnik będzie potrafił stworzyć proste definicje dla własnych dokumentów. Zanim przejdziemy do omawiania schematów, spójrzmy raz jeszcze na gotową definicję DTD (przykład 4.11).

Przykład 4.11. Gotowa definicja DTD

Po dokładnym przyjrzeniu się tej definicji DTD moŜna uznać, Ŝe jest ona zbyt złoŜona. Struktura definicji DTD rządzących organizacją plików XML zupełnie nie przypomina samych plików XML. Struktura DTD jest odmienna od struktury schematu, arkusza stylu XSL i niemal kaŜdego innego dokumentu związanego z językiem XML. Definicje DTD opracowano jako część specyfikacji XML 1.0. Niektóre decyzje projektowe podjęte w ramach tej specyfikacji odbiły się piętnem na uŜytkownikach i programistach korzystających z XML. Podstawy definicji DTD w standardzie

104 XML oparte są w duŜej części na SGML-u — specyfikacji o wiele starszej. JednakŜe struktura definicji DTD z czasów SGML-a stanowi niezbyt dobry wybór w odniesieniu do XML-a. Te róŜnice strukturalne stara się naprawić standard XML Schema, który skoncentrowany jest właśnie na XML-u i nie narusza stylu poprawnego programowania. Schematy XML Schema zostaną wkrótce omówione. Najprawdopodobniej schematy całkowicie zastąpią definicje DTD, ale zastępowanie to przebiega powoli — w wielu aplikacjach XML został juŜ wdroŜony w systemach produkcyjnych, w których są uŜywane dokumenty zawęŜane definicjami DTD. To dlatego właśnie zrozumienie definicji DTD jest tak istotne — nawet jeśli mają one odejść do lamusa.

Czego brak w definicji DTD? Co ciekawe, aŜ całą sekcję poświęcić trzeba sprawom, które nie zostały ujęte w definicji DTD. W DTD podać trzeba wszystkie elementy i zdefiniować wszystkie atrybuty dokumentu XML, ale nie muszą się tam znaleźć instrukcje przetwarzania (PI). Co więcej, w ogóle nie ma moŜliwości określenia instrukcji PI, podobnie jak deklaracji XML znajdującej się na samym początku dokumentu XML. Definicja DTD rozpoczyna się wraz z pierwszym wystąpieniem pierwszego elementu w pliku XML. Takie podejście moŜe się wydawać naturalne — po co określać, Ŝe dokument ma zawierać taką, a nie inną instrukcję przetwarzani?. Odpowiedzią jest przenośność. Są powody, dla których określanie instrukcji przetwarzania przydałoby się w definicjach DTD. Na przykład moŜliwa jest sytuacja, w której autor zawartości chciałby mieć gwarancję, Ŝe jego dokument XML zostanie zawsze przekształcony — a więc wymaga instrukcji opisującej arkusz stylu xml-stylesheet. Ale który arkusz chcemy wykorzystać? To trzeba równieŜ określić. A jaki mechanizm ma wykonać przekształcenia? Cocoon? Servlet Jamesa Clarka? Inna struktura? To wszystko równieŜ trzeba zdefiniować. Jednak kiedy wszystko zostanie dokładnie określone, dokument utraci przenośność. Będzie mógł być wykorzystany juŜ tylko do jednego konkretnego celu i w jednej specyficznej strukturze publikacji. Nie będzie go łatwo przenieść na inną platformę, strukturę czy aplikację. Dlatego instrukcje PI i deklaracje XML pozostają niezawęŜone w ramach definicji DTD. Zajmujemy się tylko elementami i atrybutami dokumentu, począwszy od elementu głównego.

XML Schema XML Schema to nowy projekt roboczy grupy W3C, uwzględniający dotychczasowe problemy i ograniczenia definicji DTD. UmoŜliwia on bardziej precyzyjną reprezentację zawęŜeń struktury XML i, co istotne, wykorzystuje w tym celu sam język XML. Schematy to właściwie dokumenty XML — dobrze sformatowane i poprawne. Mogą więc być obsługiwane przez parsery i inne aplikacje „znające XML” w sposób podobny jak zwykłe dane XML. Nie trzeba stosować specjalnych technik, jak przy obsłudze definicji DTD. PoniewaŜ XML Schema to jeszcze „młoda” i niepełna specyfikacja, zostanie omówiona pokrótce. Szczegóły implementacji mogą w kaŜdej chwili ulec zmianie; jeśli więc Czytelnik ma problemy z omawianymi przykładami, moŜe przejrzeć najnowszą wersję projektu pod adresami http://www.w3.org/TR/xmlschema-1/ i http://www.w3.org/TR/xmlschema-2/. NaleŜy takŜe pamiętać, Ŝe wiele parserów XML nie obsługuje schematów XML, bądź teŜ obsługuje je tylko częściowo. Stopień obsługi XML Schema opisany jest w instrukcji parsera. Istnieje róŜnica pomiędzy dokumentem poprawnym a dokumentem poprawnym z punktu widzenia schematu. XML Schema nie stanowi części specyfikacji XML 1.0, a więc dokument zgodny z danym schematem moŜe być niepoprawny. Tylko dokument XML zgodny z definicją DTD określo-

105 ną w deklaracji DOCTYPE moŜe być uwaŜany za poprawny. W związku z tym w środowisku uŜytkowników XML-a rodzą się wątpliwości dotyczące sposobu obsługi sprawdzania poprawności poprzez XML Schema. Ponadto, nawet jeśli dokument posiada odpowiadający mu schemat, to nie znaczy jeszcze, Ŝe jego poprawność będzie sprawdzana — poniewaŜ XML Schema nie jest opisany w specyfikacji XML 1.0, aplikacja lub parser wcale nie muszą dokonywać takiego sprawdzania (bez względu na poziom obsługi schematów przez parser). Dlatego zawsze trzeba sprawdzić, czy parser będzie sprawdzał poprawność dokumentu, oraz jak obsługuje schematy. Na potrzeby przejrzystości opisu będziemy zakładać, Ŝe sprawdzanie poprawności to jedno pojęcie, obejmujące zarówno schematy, jak i definicje DTD; znaczenie tego pojęcia będzie zaś musiało być interpretowane w odpowiednim kontekście. Na ewentualne dwuznaczności zawsze będziemy zwracali uwagę. NajwaŜniejsze przy budowaniu schematu jest to, Ŝe w trakcie tego procesu powstaje po prostu nowy dokument XML. W przeciwieństwie do definicji DTD, korzystających z zupełnie odmiennego formatu opisu elementów i definiowania atrybutów, schemat jest zwyczajnym dokumentem XML. Składnia nie będzie więc znacząco odbiegała od tej opisanej w rozdziale 2. Co ciekawe, sam schemat XML jest zawęŜony za pomocą definicji DTD. Jeśli to wydaje się nieco osobliwe, to naleŜy przypomnieć, Ŝe przed powstaniem XML Schema jedynym sposobem zawęŜania dokumentów było właśnie zastosowanie definicji DTD. Aby poprzez XML Schema moŜna było sprawdzać poprawność, trzeba najpierw określić zawęŜenia samego schematu, korzystając z „zewnętrznego mechanizmu”. A tym zewnętrznym mechanizmem musi być definicja DTD. Jednak juŜ po stworzeniu tej początkowej definicji wszystkie inne dokumenty XML w ogóle nie będą korzystały z DTD. Ta nieco dziwna kolej rzeczy jest zjawiskiem dość pospolitym w ewoluującym świecie specyfikacji — nowe wersje powstają na bazie starych.

Przestrzeń nazw schematu MoŜna oczekiwać, Ŝe dokumenty XML Schema rozpoczynają się standardową deklaracją XML, po czym następuje odwołanie do przestrzeni nazw schematu. I tak jest w rzeczywistości. Ponadto istnieją standardy nazywania elementu głównego. Przyjęło się, Ŝe element główny nosi nazwę schema. Przy tworzeniu elementu głównego buduje się równieŜ definicje przestrzeni nazw — podobnie jak to robiliśmy w naszym przykładowym dokumencie XML. Przede wszystkim konieczne jest podanie domyślnej deklaracji przestrzeni nazw:

Jak to zostało przedstawione w rozdziale 2., pominięcie identyfikatora po atrybucie xmlns powoduje zastosowanie w dokumencie domyślnej przestrzeni nazw. W naszym wcześniejszym dokumencie XML definicja przestrzeni nazw odpowiadała konkretnie przestrzeni JavaXML:

W ten sposób informowaliśmy parser XML, Ŝe wszystkie dokumenty z przedrostkiem JavaXML naleŜą do tej konkretnej przestrzeni nazw, skojarzonej z podanym adresem URL. W naszym dokumencie XML dotyczyło to wszystkich elementów, bo wszystkie opatrzone były tym przedrostkiem. Ale przecieŜ mogły tam pojawić się takŜe elementy bez takich przedrostków. Elementy takie nie są, oczywiście, skazane na niebyt — one równieŜ muszą zostać przypisane jakiejś przestrzeni nazw. Przypisuje się im przestrzeń domyślną, która nie jest zdefiniowana w dokumencie. MoŜna zdefiniować ją za pomocą dodatkowej deklaracji przestrzeni nazw w elemencie głównym:

106 Spowodowałoby to, Ŝe dowolny element nie poprzedzony przedrostkiem JavaXML lub innym kojarzony byłby z domyślną przestrzenią nazw, identyfikowaną za pomocą adresu http://www.jakisInnyUrl.com. Tak więc w następującym fragmencie dokumentu elementy Ksiazka, Spis i Tytul skojarzono z przestrzenią JavaXML, zaś element1 i element2 z domyślną przestrzenią nazw: Mój tytuł

PoniewaŜ w naszym schemacie opisujemy inny dokument, wszystkie elementy związane z konstrukcjami samego XML Schema powinny naleŜeć do domyślnej przestrzeni nazw — i dlatego podajemy na początku jej deklarację. JednakŜe konstrukcje te oddziaływają na przestrzeń nazw w zawęŜanym dokumencie XML. Innymi słowy, konstrukcje XML Schema stanowią część przestrzeni nazw XML Schema, ale wykorzystywane są do zawęŜenia elementów w innych przestrzeniach nazw — w tych, które opisują dokument lub dokumenty XML opisywane przez ten schemat. W naszym przykładzie dotyczyłoby to przestrzeni nazw JavaXML. Tak więc do elementu schema trzeba dodać następującą deklarację:

Teraz jeszcze naleŜy „poinformować” schemat, Ŝe przedmiotem zawęŜania jest druga przestrzeń nazw. W tym celu naleŜy zastosować atrybut targetNamespace (docelowa przestrzeń nazw), którego działanie jest zgodne z nazwą:

W ten sposób otrzymaliśmy definicje dwóch przestrzeni nazw (domyślna oraz JavaXML) oraz określiliśmy przedmiot zawęŜania w postaci drugiej przestrzeni nazw (JavaXML). A skoro jest juŜ zdefiniowany element główny, moŜna rozpocząć nakładanie zawęŜeń na tę przestrzeń nazw. NaleŜy pamiętać jeszcze o jednej rzeczy: w świecie protokołu HTTP i serwerów WWW moŜliwe jest, Ŝe adres URL skojarzony z daną przestrzenią nazw moŜe być prawdziwym adresem; w naszym przypadku, gdybyśmy do przeglądarki wpisali http://www.oreilly.com/catalog/javaxml, otrzymalibyśmy odpowiedź HTML. Ale zwracany dokument tak naprawdę nie jest wykorzystywany; adres URL wcale nie musi być osiągalny — słuŜy wyłącznie jako element kojarzony z przestrzenią nazw. Nie zawsze jest to łatwo zrozumieć, dlatego Czytelnik nie powinien zaprzątać sobie głowy tym, na co wskazuje podany identyfikator URI; waŜniejsze jest skoncentrowanie się na deklarowanej przestrzeni nazw oraz na sposobie, w jaki wykorzystywana jest ona w dokumencie. Uwaga! Zagadnienia omawiane w dalszej części rozdziału nie są proste, więc Czytelnik nie powinien przejmować się ewentualnymi trudnościami z ich zrozumieniem. Koncepcje związane ze schematami XML Schema nie są „łatwe i przyjemne”, a cała ta specyfikacja jest dopiero w fazie rozwoju. Wielu autorów zawartości korzysta z technologii XML Schema, my zaś staramy się tutaj

107 zrozumieć ją — to subtelna, ale istotna róŜnica. Dzięki zrozumieniu zagadnień związanych z XML Schema Czytelnik będzie potrafił bardziej efektywnie projektować dokumenty XML i tworzyć lepsze aplikacje. Szczególnie złoŜoną sprawą jest sposób wykorzystania w schematach definicji DTD i przestrzeni nazw; na szczęście większość pozostałych konstrukcji nie jest juŜ tak skomplikowana. Tak więc warto teraz zrelaksować się, napić kawy i uwaŜnie, bez pośpiechu kontynuować lekturę. To na pewno zaowocuje w przyszłości.

Określanie elementów Zagadnienie określania elementów zostało juŜ poruszone przy omawianiu definicji DTD. W schematach określanie elementów okaŜe się nieco bardziej logiczne. Proces ten dość dokładnie odzwierciedla strukturę deklaracji w Javie (plus kilka dodatkowych opcji). Do określania elementów posłuŜymy się elementem... element:

[Nazwa elementu] określa element w zawęŜanym dokumencie XML. JednakŜe w przeciwieństwie do definicji DTD, nie powinno być tutaj przedrostka przestrzeni nazw. Czytelnik winien przypomnieć sobie uwagi na temat docelowej przestrzeni nazw. Zostało tam powiedziane, Ŝe przestrzenią docelową (ang. target) jest JavaXML, a więc specyfikacje wszystkich elementów, a takŜe typy zdefiniowane przez uŜytkownika, są kojarzone i przypisywane właśnie tej docelowej przestrzeni nazw. To przyczynia się do utworzenia bardziej przejrzystego dokumentu XML Schema, poniewaŜ najpierw definiowane są wszystkie elementy, a potem narzuca się przestrzeń nazw. Konstrukcja [Typ elementu] to albo wstępnie zdefiniowany typ danych w schemacie, albo typ zdefiniowany przez uŜytkownika. W tabeli 4.4 zestawiono typy danych obsługiwane przez bieŜącą wersję standardu XML Schema.

Tabela 4.4. Typy danych w XML Schema Typ

Podtypy

Znaczenie

string

łańcuchy znaków

boolean float double decimal timeInstant

NMTOKEN, language brak brak brak integer brak

timeDuration recurringInstant

brak date, time

binary uri

brak enumeration

binarna wartość logiczna (prawda lub fałsz) 32-bitowy typ zmiennoprzecinkowy 64-bitowy typ zmiennoprzecinkowy standardowy zapis dziesiętny, dodatni i ujemny połączenie daty i czasu, wskazujące konkretny moment w czasie czas trwania specyficzny czas, powtarzający się przez okres timeDuration dane binarne jednolity identyfikator zasobów (URI).

W naszych przykładach wykorzystamy tylko niektóre typy. Widać jednak od razu, Ŝe wybór jest tutaj większy niŜ w DTD.

108

Zaczynamy od dołu MoŜliwe jest takŜe tworzenie złoŜonych typów danych, definiowanych przez uŜytkownika. Typy takie budowane są z kombinacji elementów. Na przykład moŜna określić, Ŝe typ Ksiazka składa się z elementu Tytul, Spis i Copyright (zwróćmy uwagę, Ŝe przy opisywaniu elementów nie jest juŜ podawany przedrostek przestrzeni nazw — w schematach najpierw odczytywana jest tylko nazwa elementu, dopiero potem definiuje się odpowiednią przestrzeń). Te zaś elementy mogą znów być typami zdefiniowanymi przez uŜytkownika, składającymi się z dalszych elementów. Tak powstaje piramida hierarchii; na jej spodzie znajdują się elementy o podstawowych typach XML Schema; wyŜej — warstwy elementów zdefiniowanych przez uŜytkownika; na samej górze — element główny. Taka struktura wymusza określony sposób działania — najlepiej zaczynać budowanie schematu od określenia elementów znajdujących się u podstaw tej hierarchii — czyli tych, które moŜna zdefiniować jako standardowe typy XML Schema. Sytuacja jest więc tutaj nieco inna niŜ w definicjach DTD, gdzie zazwyczaj postępuje się zgodnie z kolejnością elementów w dokumencie XML. Ale dzięki temu budowanie schematu jest prostsze. Jeśli spojrzymy na nasz dokument XML, to moŜemy określić, które elementy stanowią typy „prymitywne” — (patrz tabela 4.5).

Tabela 4.5. Elementy „prymitywne” Nazwa elementu

Typ

Tytul Naglowek Temat

string string string

Teraz elementy te moŜna wpisać do schematu (przykład 4.12). Aby budowany schemat nie utracił przejrzystości, zostaną w nim pominięte deklaracje XML i DOCTYPE; znajdą się one w wersji ostatecznej, ale teraz tylko zmniejszałyby czytelność przykładów. Przykład 4.12. Schemat z elementami „prymitywnymi”

Zbyt proste? CóŜ, to jest proste. Po zdefiniowaniu tych „podstawowych”, czy teŜ „prymitywnych” elementów moŜemy przejść do budowania elementów bardziej złoŜonych.

Typy danych definiowane przez uŜytkownika Podobnie jak w przypadku elementów niepodzielnych, elementy bardziej złoŜone naleŜy budować takŜe „od dołu” piramidy. Niemal zawsze oznacza to, Ŝe programista rozpoczyna tworzenie od elementów najgłębiej zagnieŜdŜonych i posuwa się „w górę”, aŜ do elementu głównego. W naszym przypadku najbardziej zagnieŜdŜone są Naglowek i Temat. PoniewaŜ elementy te juŜ zostały

109 określone jako prymitywne, moŜna przenieść się o poziom wyŜej — do elementu Rozdzial. To właśnie będzie pierwszy element zdefiniowany przez uŜytkownika. W definicji musi zostać zawarta informacja, Ŝe składa się on z jednego elementu Naglowek oraz jednego lub więcej elementów Temat. Typy złoŜone definiujemy za pomocą elementu complexType: <[Specyfikacja elementu]> <[Specyfikacja elementu]> ...

Naszemu elementowi przypisujemy nowy typ. Dla elementu Rozdzial stworzymy typ TypRozdzial: ...

Powstały w ten sposób typ staje się, oczywiście, częścią docelowej przestrzeni nazw JavaXML. Tak więc aby przypisać ten typ naszemu elementowi Rozdzial, uŜyjemy następującej specyfikacji dokumentu:

Teraz, jakąkolwiek strukturę określimy wewnątrz typu TypRozdzial, będzie ona zawęŜała element Rozdzial. NaleŜy zauwaŜyć, Ŝe typ elementu określany jest jako JavaXML:TypRozdzial, a nie po prostu jako TypRozdzial. Typ ten był tworzony w ramach docelowej przestrzeni nazw, JavaXML. Jednak elementy, jakie wykorzystujemy w schemacie (element, complexType itd.), nie mają przedrostka przestrzeni nazw, poniewaŜ naleŜą do przestrzeni domyślnej schematu. Gdybyśmy więc próbowali określić typ jako TypRozdzial, parser przeszukałby przestrzeń domyślną (tę odnoszącą się do schematu), a nie znajdując tam naszego elementu, zgłosiłby wyjątek. Aby parser „wiedział”, gdzie szukać definicji typu, naleŜy wskazać poprawną przestrzeń nazw — w tym przypadku JavaXML. Ogólną strukturę Czytelnik juŜ zna, pora zająć się szczegółami. W przypadku tego elementu trzeba zdefiniować w schemacie dwa elementy, które są w tym typie zagnieŜdŜane. PoniewaŜ juŜ zostały określone dwa zagnieŜdŜane elementy (prymitywne Naglowek i Temat), naleŜy się do nich dowołać w nowym typie:

Atrybut ref informuje parser XML, Ŝe definicja danego elementu znajduje się w innej części schematu. Tak jak przy określaniu typu i tutaj równieŜ trzeba wskazać parserowi przestrzeń nazw, w jakiej znajdują się elementy (zazwyczaj jest to przestrzeń docelowa). Ale moŜna tutaj dopatrzyć się pewnej nadmiarowości i „przegadania”. Dwa elementy definiujemy jako prymitywy, a potem się do nich odwołujemy — to daje cztery linijki. Elementy te jednak nie są wykorzystywane nigdzie indziej w naszym dokumencie, a więc czy nie logiczniej byłoby zdefiniować element od razu wewnątrz typu? Nie trzeba byłoby wtedy odwoływać się do elementu i wymuszać na czytających nasz schemat przeszukiwanie dokumentu w celu odnalezienia elementu wykorzystanego tylko raz. Tak moŜna zrobić. Specyfikacja elementu moŜe zostać zagnieŜdŜona w typie zdefiniowanym przez uŜytkownika, a więc nieco przerobimy teraz nasz schemat — tak, aby był bardziej czytelny:

110

Oprócz usunięcia niepotrzebnych wierszy, pozbyliśmy się takŜe niepotrzebnych odwołań do przestrzeni nazw JavaXML. To na pewno zwiększy czytelność, szczególnie wśród odbiorców nie mających doświadczenia w pracy z XML-em. Znając sposób tworzenia typów definiowanych przez uŜytkownika, moŜemy teraz określić pozostałe elementy, tak jak w przykładzie 4.13.

Przykład 4.13.

Dzięki temu kaŜdy uŜyty element XML zostanie zdefiniowany, a schemat będzie czytelny. Nie znaczy to jednak, Ŝe wszystkie problemy zostały rozwiązane.

Typy niejawne i pusta zawartość Do tej pory korzystaliśmy wyłącznie z typów nazwanych, często określanych mianem jawnych. Typ jawny to taki, w którym podano nazwę typu; element wykorzystujący ten typ zazwyczaj znajduje się w innym miejscu pliku. To bardzo obiektowe podejście — ten sam typ jawny moŜe być zastosowany dla róŜnych elementów. JednakŜe istnieją sytuacje, kiedy taka struktura jest rozwiązaniem na wyrost; innymi słowy, typ jest tak specyficzny względem elementu, Ŝe jego nazywanie nie jest potrzebne. W naszym przykładzie definicję elementu Rozdzial moglibyśmy skonsolidować poprzez zdefiniowanie typu w samej definicji elementu. SłuŜą do tego typy niejawne, zwane takŜe nienazwanymi:

111

Zastosowanie typu niejawnego powoduje, Ŝe schemat jest jeszcze bardziej czytelny. JednakŜe Ŝaden inny element nie moŜe być tego samego typu, co zdefiniowany w ten sposób typ niejawny — chyba Ŝe zdefiniowano kolejny typ niejawny. Innymi słowy, typów niejawnych uŜywamy tylko wtedy, gdy jesteśmy zupełnie pewni, Ŝe typ ten nie będzie wykorzystywany przez wiele elementów. Typy niejawne mogą takŜe słuŜyć do podawania informacji o definiowanych elementach. Na przykład, do tej pory definiowaliśmy element PodzialSekcji jako string. Faktycznie nie jest to określenie zbyt precyzyjne, poniewaŜ element ten ma być pusty. Aby określić element jako pusty, uŜyjemy typu niejawnego:

To moŜe wydawać się dziwne — dlaczego nie moŜna po prostu przypisać temu elementowi „pustego” (ang. empty) typu danych? Czy twórcy specyfikacji XML Schema coś przeoczyli? Wręcz przeciwnie — we wcześniejszych wersjach specyfikacji istniał typ danych empty, ale go usunięto. Zrobiono tak, aby wymóc definicje typu elementu. Aby to zrozumieć, zauwaŜmy, Ŝe większość pustych elementów moŜe przyjmować atrybuty do określania danych:

W takich przypadkach określenie elementu jako empty nie pozwoliłoby na intuicyjne określenie, jakie atrybuty są w nim dozwolone. Sprawa jest natomiast prosta, jeśli uŜyjemy typu elementu:

Sposoby definiowania atrybutów zostaną omówione dalej. Tymczasem warto pamiętać, Ŝe typy niejawne pomagają budować schemat w sposób bardziej intuicyjny oraz umoŜliwiają definiowanie właściwości elementu — np. tego, Ŝe jest pusty.

Ile? Oprócz powyŜszych, w definicji elementu naleŜy określić rodzaj rekurencji (lub zdefiniować jej brak). Schemat zachowuje się tutaj podobnie jak DTD — jeśli elementu nie opatrzono modyfikatorami, moŜe pojawić się tylko raz. Jak juŜ wcześniej wspomniano, nie zawsze akurat tak musi być. Nasza ksiąŜka moŜe mieć wiele rozdziałów, ale moŜe nie mieć podziału sekcji; niektóre rozdziały mogą mieć nagłówki, a inne nie. Musimy umieć zdefiniować te wszystkie szczegóły w naszym schemacie. Podobnie jak w definicji DTD, słuŜy do tego odpowiedni mechanizm. Ale w przeciwieństwie do DTD stworzono intuicyjny zestaw atrybutów (zamiast nieco zagadkowych operatorów rekurencji typu ?, + czy *). W XML Schema wykorzystuje się atrybuty minOccurs i maxOccurs:

112 Jeśli atrybuty te nie zostaną określone, przyjmują domyślną wartość 1 — czyli jeden dozwolony element na definicję. Jeśli maksymalna wartość nie jest określona, wykorzystuje się symbol wieloznaczny. Konstrukcje te pozwalają w prosty sposób narzucić zawęŜenia związane z rekurencją (przykład 4.14).

Przykład 4.14. Schemat XML z definicjami elementów

Zdefiniowaliśmy jeden element główny, Ksiazka, typu TypKsiazka. Element ten zawiera trzy bezpośrednio potomne elementy: Tytul, Spis i Copyright. Z tych trzech dwa są prymitywnymi łańcuchami XML, a trzeci (Spis) to kolejny typ zdefiniowany przez uŜytkownika, TypSpis. Typ ten zawiera z kolei element potomny Rozdzial, który moŜe pojawić się raz lub więcej razy, oraz element potomny PodzialSekcji, który wcale nie musi się pojawić. Element Rozdzial zawiera dwa elementy zagnieŜdŜone, Naglowek i Temat. KaŜdy z nich jest prymitywnym łańcuchem XML; Naglowek moŜe pojawić się zero lub więcej razy, a Temat jeden lub więcej razy. Element PodzialSekcji moŜe wystąpić zero lub więcej razy i jest elementem pustym. Teraz w schemacie zdefiniowane są juŜ wszystkie elementy — pozostaje dodać atrybuty.

Definiowanie atrybutów Proces definiowania atrybutów jest o wiele prostszy od definiowania elementów, przede wszystkim dlatego, Ŝe nie trzeba zwracać uwagi na tyle spraw, co w przypadku elementów. Domyślnie atrybut nie musi występować, a zagnieŜdŜanie w ogóle atrybutów nie dotyczy. Choć istnieje wiele zaawansowanych konstrukcji, których moŜna uŜyć do zawęŜania atrybutów, my przyjrzymy się tylko tym podstawowym, koniecznym do zawęŜenia omawianego dokumentu XML. W razie potrzeby zastosowania tych trudniejszych konstrukcji Czytelnik powinien zajrzeć do specyfikacji XML Schema.

113

Czego brakuje? Przy zawęŜaniu atrybutów na potrzeby dokumentu XML wchodzą w grę pewne pominięcia; wszystkie mają związek z róŜnymi definicjami przestrzeni nazw opisywanego dokumentu. Dokument XML, jak to juŜ było powiedziane, musi zawierać definicje przestrzeni nazw w odniesieniu do schematu oraz definicje przestrzeni nazw „na własne potrzeby” — tj. odnoszące się do jego zawartości. Definicje te tworzy się za pomocą atrybutu xmlns:[PrzestrzenNazw] elementu głównego. Atrybuty te nie powinny być definiowane w schemacie. Próba zdefiniowania kaŜdej dozwolonej przestrzeni nazw dałaby bardzo zagmatwany schemat. PołoŜenie deklaracji przestrzeni nazw nie musi być stałe; moŜna ją przemieszczać, o ile tylko pozostaje dostępna dla wszystkich odpowiednich elementów. Dlatego w schemacie zezwala się na pominięcie definicji atrybutów przestrzeni nazw. Pora przypomnieć sobie wiadomości dotyczące definicji DTD. Aby zezwolić na deklaracje przestrzeni nazw w dokumencie XML, trzeba było wstawić taką definicję atrybutu jak poniŜej:

Aby moŜna było korzystać z DTD, wystarczyło określić przestrzeń nazw w danym dokumencie XML, bo definicje DTD nie posiadają „świadomości” istnienia przestrzeni nazw w XML. W schematach XML Schema sprawa jest trochę bardziej skomplikowana. Czytelnik wie juŜ, Ŝe istnieją trzy róŜne atrybuty słuŜące do określenia schematu dla dokumentu:
Gdyby Czytelnik miał napisać schemat w oparciu o poznane dotąd wiadomości o DTD, prawdopodobnie zadeklarowałby, Ŝe xmlns:xsi, xmlns i xsi:schema-Location to poprawne atrybuty elementu głównego. JednakŜe deklaracje te moŜna pominąć, poniewaŜ schematy są „świadome” istnienia przestrzeni nazw i wystarczająco „inteligentne”, Ŝeby nie wymagać wstawiania takich deklaracji w zawęŜanym dokumencie XML.

Definicja Atrybuty definiuje się za pomocą elementu XML Schema attribute (ciekawe, prawda?). Innymi słowy, oprócz elementu element, w schematach zdefiniowany jest element attribute, za pomocą którego określa się atrybuty dozwolone dla bieŜącej definicji elementu lub typu. Oto format tego elementu:

Format ten jest podobny do definicji elementów — właściwie jest niemal identyczny. Przy definiowaniu atrybutów dostępne są te same typy danych, co przy definiowaniu elementów. Oznacza to, Ŝe dodanie atrybutów do naszego schematu nie będzie przedstawiało trudności. Dla kaŜdego elementu posiadającego zdefiniowany typ dodamy wymagane atrybuty wewnątrz definicji tego typu. W przypadku elementów nie posiadających zdefiniowanego typu musimy typ taki dodać. W ten sposób „poinformujemy” schemat, Ŝe atrybuty, które deklarujemy, „naleŜą” do opisywane-

114 go typu elementu. W tych nowych typach elementów moŜna określić typ zawartości za pomocą atrybutu content elementu complexType — zachowując oryginalne zawęŜenia i dodając definicje atrybutów. Po tych zmianach uzyskamy schemat taki jak w przykładzie 4.15.

Przykład 4.15. Schemat XML z definicjami atrybutów

Po przyjrzeniu się elementowi Temat Czytelnik z pewnością zauwaŜy, Ŝe na potrzeby zdefiniowania atrybutu podRozdzialy konieczne jest stworzenie nowego typu. Wewnątrz tego typu, za pomocą atrybutu content, wymagamy, aby atrybut był typu integer. Z tego samego mechanizmu korzystaliśmy wcześniej, przy przypisywaniu elementowi PodzialSekcji typu empty — w ten sposób zapewnialiśmy, Ŝe element ten pozostanie pusty. Pozostałe dodane atrybuty nie wymagają juŜ tak wielu modyfikacji, bo odpowiednie typy dla złoŜonych elementów juŜ istniały.

Atrybuty wymagane, wartości domyślne i wyliczenia Pozostaje juŜ tylko „dostroić” definicje atrybutów. W definicjach DTD, w celu określenia, czy atrybuty mają się pojawić oraz czy posiadają wartości domyślne (jeśli ich nie podano), uŜywaliśmy słów kluczowych #IMPLIED, #FIXED i #REQUIRED. Podobnie jak w przypadku operatorów rekurencji w elementach, w schematach zdefiniowano prostszy sposób zapisu tego samego. Jeśli atrybut jest wymagany, wykorzystuje się ten sam atrybut minOccurs, który uŜywany był przy definiowaniu elementów, przypisując mu wartość 1. W naszym przykładzie chcemy zdefiniować, Ŝe w elemencie Rozdzial istnieje atrybut o nazwie sekcja. UŜyjemy takiego zapisu:

115 Jak wspomnieliśmy, domyślnie kaŜdy element wymagany jest w jednym egzemplarzu (domyślna wartość minOccurs to 1). Atrybuty natomiast nie są wymagane (minOccurs ma wartość domyślną 0). W XML Schema nie istnieje pojęcie wartości stałej atrybutów (#FIXED); jak to zostało powiedziane wcześniej, wartość ta jest wykorzystywana rzadko i nie stanowi zapisu „intuicyjnego”. Przydaje się za to moŜliwość określenia wartości domyślnej i słuŜy do tego atrybut default. Na przykład, aby określić domyślną wartość atrybutu tematyka elementu Rozdzial jako „Java”, skorzystamy z zapisu:

Mam nadzieję, Ŝe Czytelnik zdąŜył juŜ polubić prostotę XML Schema! Jest to standard bardziej intuicyjny i przez to prostszy niŜ DTD. Kolejnym dowodem na to są wyliczenia. Dla atrybutu tematyka określiliśmy za pomocą DTD tylko dwie moŜliwe wartości: Java i XML. Skorzystaliśmy z operatora LUB (OR):

Nie jest to moŜe zapis trudny, ale nie jest teŜ najbardziej intuicyjny. Dozwolone wartości nie są nawet umieszczane w cudzysłowach — a to jest właśnie de facto standard reprezentacji wartości. W XML Schema, aby uzyskać to samo, trzeba napisać więcej — ale za to zrozumienie zapisu jest o wiele prostsze. NaleŜy otworzyć definicję atrybutu, po czym skorzystać z elementu simpleType. Element ten umoŜliwia zawęŜenie istniejącego typu danych (np. string) do podanych wartości. W tym przypadku zaleŜy nam na podaniu dwóch wartości (wyliczenia) i kaŜdą z nich określimy za pomocą elementu enumeration. Typ bazowy elementu określimy za pomocą słowa kluczowego base. Zmieńmy więc definicję atrybutu tematyka:

Tak, tekstu jest więcej niŜ w przypadku bliźniaczej konstrukcji w DTD, a jednak powyŜszy zapis jest prostszy w zrozumieniu, szczególnie dla nowych uŜytkowników standardu XML. Po wprowadzeniu tej zmiany nasz schemat jest juŜ gotowy; zawarto w nim wszystkie zawęŜenia, które są zamieszczone w stworzonej wcześniej definicji DTD. Spójrzmy na przykład 4.16.

Przykład 4.16. Gotowy dokument XML Schema

116

Co dalej? W niniejszym rozdziale Czytelnik poznał dwa sposoby zawęŜania dokumentów XML: zawęŜanie z wykorzystaniem definicji DTD oraz sposób nowszy — zawęŜanie z wykorzystaniem XML Schema. Czytelnik zapewne dostrzegł juŜ, jak waŜne jest zawęŜanie dokumentów, szczególnie jeśli mają one być wykorzystane przez aplikacje. Jeśli aplikacja nie rozpoznaje typu informacji zawartych w dokumencie, manipulacja i przetwarzanie takich danych stają się o wiele trudniejsze. W następnym rozdziale zostaną omówione klasy interfejsu SAX. Czytelnik dowie się, jak z programu w Javie uzyskać dostęp do definicji DTD oraz schematów. Do parsera dodamy przykładowy program, który zbudowaliśmy w rozdziale 3. — będzie on odczytywał zawęŜenia dokumentu i zwracał błędy, jeśli dokument XML nie będzie poprawny; będzie równieŜ wykorzystywał odwołania wsteczne dostępne w procesie sprawdzania poprawności składni.

Konfiguracja parsera

117

5 Sprawdzanie poprawności składni XML-a Po lekturze poprzednich rozdziałów Czytelnik potrafi juŜ stworzyć dokument XML, przetworzyć go za pomocą klas SAX oraz zawęzić. W tym rozdziale zostanie omówione kolejne zagadnienie — sprawdzanie poprawności dokumentu XML za pomocą Javy. Bez takiej moŜliwości tworzenie aplikacji firma-firma oraz komunikacji międzyaplikacyjnej staje się o wiele trudniejsze. ZawęŜenie zwiększa przenośność danych; natomiast sprawdzanie poprawności — spójność. Innymi słowy, moŜliwość zawęŜenia dokumentu nie zda się na wiele, jeśli stworzonych zawęŜeń nie przeforsujemy w aplikacji XML. W tym rozdziale przedstawione zostaną klasy i interfejsy SAX słuŜące do sprawdzania poprawności dokumentów XML względem ich zawęŜeń. Czytelnik dowie się, jak ustawić cechy i właściwości parsera zgodnego z SAX, aby moŜliwe było proste sprawdzanie poprawności, obsługa przestrzeni nazw i wykonywanie innych czynności. Ponadto szczegółowo omówione zostaną błędy i ostrzeŜenia zgłaszane przez parsery sprawdzające poprawność.

Konfiguracja parsera W obliczu bogactwa specyfikacji i technologii autorstwa konsorcjum W3C związanych z językiem XML, dodanie obsługi nowej cechy lub właściwości nie jest proste. W wielu implementacjach parserów dodano własne rozszerzenia lub metody kosztem przenośności kodu. W pakietach tych mógł zostać zaimplementowany interfejs XMLReader, ale metody do ustawiania sprawdzania poprawności, obsługi przestrzeni nazw i innych kluczowych cech są odmienne w róŜnych implementacjach parserów. W związku z tym w interfejsie SAX 2.0 zdefiniowano standardowy mechanizm do ustawiania istotnych właściwości i cech parsera. UmoŜliwia on dodawanie nowych właściwości i cech w miarę przyjmowania ich przez W3C, bez konieczności stosowania własnych metod lub rozszerzeń.

Konfiguracja parsera

118

Ustawianie właściwości i cech Na szczęście dla nas, interfejs SAX 2.0 wyposaŜono w metody słuŜące do ustawiania właściwości i cech interfejsu XMLReader. Oznacza to, Ŝe w celu zaŜądania sprawdzania poprawności, ustawienia separatora przestrzeni nazw czy obsługi innych cech nie trzeba zmieniać zbyt wiele w istniejącym kodzie. Odpowiednie metody przedstawione są w tabeli 5.1.

Tabela 5.1. Metody do obsługi właściwości i cech parsera Metoda

Zwraca

setProperty() void setFeature()

void

Parametry

Składnia

String IDwlasciwosci, Object wartosc String IDcechy, boolean stan

parser.setProperty(„[URI wlasciwosci]”, „[Parametr obiektu]”); parser.setFeature(„[URI cechy]”, true); String separator = (Stringparser.getProperty(„[URI wlasciwosci]”); if (parser.getFeature(„[URI cechy]”)) {robiCos();}

getProperty() Object

String IDwlasciwosci

getFeature()

String IDcechy

boolean

W kaŜdej z powyŜszych metod identyfikatorem ID określonej właściwości lub cechy jest identyfikator URI. Lista najwaŜniejszych właściwości i cech jest zamieszczona w dodatku B. Producent parsera XML powinien udostępnić dodatkową dokumentację informujacą o obsługiwanych cechach i właściwościach. Pamiętajmy jednak, Ŝe identyfikatory te, podobnie jak identyfikatory URI przestrzeni nazw, słuŜą wyłącznie do kojarzenia odpowiednich cech. Dobry parser umoŜliwi korzystanie z nich bez posiadania połączenia z siecią. W tym sensie identyfikatory URI moŜna postrzegać jako proste stałe, które akurat mają format URI. Po skorzystaniu z takiej metody następuje lokalne przetworzenie identyfikatora, często jako stałej reprezentującej odpowiednią czynność, którą naleŜy podjąć. W kontekście konfiguracji parsera właściwość wymaga obecności obiektu, z którego moŜna skorzystać. Na przykład w celu obsługi leksykalnej jako wartość właściwości moŜna dostarczyć klasę LexicalHandler. Cecha natomiast ma postać znacznika wykorzystywanego przez parser w celu określenia, czy ma nastąpić przetwarzanie określonego typu. Typowe cechy to sprawdzanie poprawności, obsługa przestrzeni nazw i dołączanie encji zewnętrznych. Najwygodniejsza własność powyŜszych metod polega na tym, Ŝe umoŜliwiają one łatwe dodawanie i zmianę róŜnych cech. Nowe lub zaktualizowane właściwości wymagają obsługi ze strony parsera, ale dostęp do nich uzyskuje się wciąŜ za pomocą tych samych metod — konieczne jest tylko zdefiniowanie nowego identyfikatora URI. Bez względu na złoŜoność nowych koncepcji związanych z XML, ich implementacja w parserach przebiega bezproblemowo, właśnie dzięki tym metodom.

Włączanie sprawdzania poprawności Czytelnik dowiedział się juŜ, jak ustawiać cechy i właściwości, ale nie poznał jeszcze samych cech i właściwości. W tym rozdziale interesujemy się przede wszystkim sprawdzaniem poprawności w czasie przetwarzania. Aby zilustrować, jak waŜne są wspomniane wyŜej metody, trzeba odwołać się do historii. W interfejsie SAX 1.0 implementacje parserów musiały udostępniać własne rozwiązania do obsługi przetwarzania ze sprawdzaniem poprawności lub bez. Nie było moŜliwości

Konfiguracja parsera

119

włączenia lub wyłączenia sprawdzania poprawności w sposób standardowy, więc najprostszy sposób polegał na dostarczeniu dwóch niezaleŜnych klas przetwarzających. Na przykład, aby wykonać przetwarzanie bez sprawdzania poprawności we wczesnych wersjach parsera Project X firmy Sun, trzeba było skorzystać z przedstawionego poniŜej fragmentu kodu.

Przykład 5.1. Uruchamianie parsera nie sprawdzającego poprawności w interfejsie SAX 1.0 try { // Rejestrujemy parser w SAX Parser parser = ParserFactory.makeParser( "com.sun.xml.parser.Parser"); // Przetwarzamy dokument parser.parse(uri); } catch (Exception e) { e.printStackTrace(); }

PoniewaŜ nie istniał standardowy mechanizm włączania sprawdzania poprawności, trzeba było załadować inną klasę; ta nowa klasa jest niemal identyczną implementacją interfejsu Parser w SAX 1.0, ale wykonującą sprawdzanie poprawności. Kod pozwalający na uŜycie parsera jest niemal identyczny (przykład 5.2), róŜnica jest tylko w klasie załadowanej w celu przetwarzania.

Przykład 5.2. Uruchamianie parsera sprawdzającego poprawność w interfejsie SAX 1.0 try { // Rejestrujemy parser w SAX Parser parser = ParserFactory.makeParser( "com.sun.xml.parser.ValidatingParser"); // Przetwarzamy dokument parser.parse(uri); } catch (Exception e) { e.printStackTrace(); }

Włączając lub wyłączając sprawdzanie poprawności trzeba więc było zmieniać i kompilować kod. Ponadto wynikał z tego dodatkowy problem z przetwarzaniem. Standardowe środowisko programistyczne wykorzystuje kod, który sprawdza poprawność danych XML wytwarzanych przez aplikację. To sprawdzanie poprawności, choć obniŜa wydajność, zapewnia, Ŝe aplikacja tworzy zawsze poprawny kod XML albo Ŝe otrzymuje poprawne dokumenty XML na wejściu. Często takie zawęŜenia po intensywnym testowaniu moŜna usunąć, dzięki czemu odzyskuje się wysoką wydajność działania aplikacji. Pozbawienie parsera moŜliwości sprawdzania poprawności jest uzasadnione, poniewaŜ dogłębne testy potwierdziły poprawność tworzonego dokumentu XML; ale zmiana ta wymaga modyfikacji i rekompilacji kodu. Wydaje się to być sprawą banalną, ale wiele firm nie pozwala na wdroŜenie do produkcji kodu, który był modyfikowany później niŜ przed jakimś określonym czasem — często kilka dni, a nawet tygodni. Taka niewielka zmiana moŜe więc spowodować dodatkowy cykl testowy — niejednokrotnie niepotrzebny, a dodatkowo wydłuŜający czas wdroŜenie aplikacji. Ale przecieŜ nazwę parsera moŜna pobrać z pliku właściwości (zostało to juŜ powiedziane w rozdziale 2. przy okazji opisywania aspektów przenośności aplikacji XML). Tak, ale zmiana całej

Konfiguracja parsera

120

implementacji parsera tuŜ przed wdraŜaniem aplikacji do produkcji to zmiana powaŜna, która powinna być naleŜycie przetestowana. Jeśli porównamy to ze zmianą wartości zestawu cech (zakładając, Ŝe wartość do ustawiania tej cechy takŜe pobierana jest z pliku właściwości), to łatwo zgadnąć, które rozwiązanie jest lepsze. Z tych wszystkich powodów w interfejsie SAX 2.0 do XMLReader dodano omawiane metody. Dzięki nim włączenie sprawdzania poprawności polega na wykorzystaniu odpowiedniego identyfikatora URI: http://xml.org/sax/features/validation. Moglibyśmy zaŜądać równieŜ przetwarzania encji zewnętrznych i przestrzeni nazw, ale tymczasem „włączymy” tylko sprawdzanie poprawności (przykład 5.3).

Przykład 5.3. Włączanie sprawdzania poprawności // Stwórz egzemplarze procedur obsługi ContentHandler contentHandler = new MyContentHandler(); ErrorHandler errorHandler = new MyErrorHandler(); try { // Stwórz egzemplarz parsera XMLReader parser = XMLReaderFactory.createXMLReader( "org.apache.xerces.parsers.SAXParser"); // Zarejestruj procedurę obsługi zawartości parser.setContentHandler(contentHandler); // Zarejestruj procedurę obsługi błędów parser.setErrorHandler(errorHandler); parser.setFeature("http://xml.org/sax/features/validation", true); // Przetwórz dokument parser.parse(uri); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); }

Po tych prostych zmianach moŜemy juŜ zmodyfikować nasz przykładowy plik XML tak, by znów zawierał odwołanie do definicji DTD i zewnętrzną encję (zostały one opatrzone komentarzami w poprzednim rozdziale).

Java i XML

Wynik sprawdzania poprawności

121

... &OReillyCopyright;

Upewniamy się, czy w podanym tutaj katalogu mamy stworzoną wcześniej definicję DTD. Zanim uruchomimy przykład, musimy połączyć się z Internetem — pamiętajmy, Ŝe encje muszą zostać „przetłumaczone”. W naszym przykładowym pliku mamy taką encję — OReillyCopyright. W definicji DTD odwołujemy się do identyfikatora URI http://www.oreilly.com/catalog/javaxml/ docs/copyright.xml. Jeśli w czasie sprawdzania poprawności identyfikator URI nie jest dostępny, pojawią się błędy przetwarzania. Jeśli nie mamy dostępu do Internetu albo nie chcemy z niego korzystać, moŜemy odwołanie sieciowe zastąpić odwołaniem do pliku lokalnego. Na przykład tworzymy jednowierszowy plik jak w przykładzie 5.4.

Przykład 5.4. Lokalny plik z opisem praw autorskich Przykładowy współdzielony plik z opisem praw autorskich.

Plik ten zachowujemy w katalogu dostępnym z poziomu programu parsera i zamieniamy deklarację encji w DTD na ścieŜkę do tego pliku:

W tym przykładzie plik tekstowy zachowany jest pod nazwą copyright.txt w katalogu encje/. Po takiej zmianie moŜemy juŜ uruchomić nasz program na przykładowym pliku XML.

Wynik sprawdzania poprawności Sprawdzamy, czy pliki XML, DTD, plik z prawami autorskimi (o ile taki stworzyliśmy) oraz odpowiednie klasy Javy znajdują się w jednym miejscu, i uruchamiamy przykładowy program. Wynik moŜe być zaskakujący (przykład 5.5).

Przykład 5.5. Wynik działania programu SAXParserDemo D:\prod\JavaXML> java SAXParserDemo D:\prod\JavaXML\contents\contents.xml Przetwarzanie pliku XML: contents.xml

* setDocumentLocator() została wywołana Rozpoczyna się przetwarzanie... **Przetwarzanie błędu** Wiersz: 11 URI: file:/D:/prod/JavaXML/contents/contents.xml Komunikat: Document root element "JavaXML:Ksiazka", must match DOCTYPE root "JavaXML:Ksiazka".

Ten dość enigmatyczny komunikat wynika z istnienia powaŜnego problemu związanego z uŜywaniem definicji DTD i przestrzeni nazw. Z informacji wynikałoby, Ŝe element główny określony w deklaracji DOCTYPE (JavaXML:Ksiazka) jest róŜny od elementu głównego samego dokumentu. Ale przecieŜ elementy te są identyczne, prawda? OtóŜ nie! Domyślnie SAX 2.0 wymaga

Wynik sprawdzania poprawności

122

od parserów włączenia przetwarzania przestrzeni nazw, chyba Ŝe jawnie wyłączymy tę cechę1. My ustawienia domyślnego nie zmienialiśmy, a więc nasza implementacja interfejsu XMLReader jest „świadoma” przestrzeni nazw. Nieoczekiwany rezultat wynika stąd, Ŝe nasz element główny jest postrzegany (przez parser) jako Ksiazka z przedrostkiem przestrzeni nazw JavaXML. Ale pamiętajmy, Ŝe XML 1.0 oraz definicje DTD nie rozróŜniały pomiędzy przedrostkiem a nazwą elementu, a więc element główny DTD oczekuje nazwy JavaXML:Ksiazka. Kiedy znajduje Ksiazka, zgłasza błąd. Jedynym sposobem obejścia tej nieco uciąŜliwej cechy SAX-a jest wyłączenie „świadomości” przestrzeni nazw w dokumentach, w których sprawdzanie poprawności odbywa się za pomocą DTD. Dodajemy następujący fragment kodu: try { // Stwórz egzemplarz parsera XMLReader parser = XMLReaderFactory.createXMLReader( "org.apache.xerces.parsers.SAXParser"); // Zarejestruj procedurę obsługi zawartości parser.setContentHandler(contentHandler); // Zarejestruj procedurę obsługi błędów parser.setErrorHandler(errorHandler); // Włącz sprawdzanie poprawności parser.setFeature("http://xml.org/sax/features/validation", true); // Wyłącz "świadomość" przestrzeni nazw parser.setFeature("http://xml.org/sax/features/namespaces", false); // Przetwórz dokument parser.parse(uri); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); }

Po tej zmianie wszystkie nazwy traktowane są jako zawierające zarówno przedrostek przestrzeni nazw, jak i nazwę lokalną elementu. Do korzystania z przestrzeni nazw powrócimy w dalszej części rozdziału. Tymczasem spróbujmy ponownie uruchomić program z zaimplementowanymi zmianami. Powinniśmy uzyskać wynik widoczny w przykładzie 5.6.

Przykład 5.6. Wynik działania programu SAXParserDemo po wyłączeniu obsługi przestrzeni nazw D:\prod\JavaXML> java SAXParserDemo D:\prod\JavaXML\contents\contents.xml Przetwarzanie pliku XML: contents.xml

1

Domyślne włączanie obsługi przestrzeni nazw miało miejsce w czasie pisania tej ksiąŜki, jednakŜe niektórzy programiści związani z XML-em (np. zespół programistów Apache Xerces) postulowali wyłączenie tej funkcji. Jeśli Czytelnik nie otrzymuje wspomnianego wyŜej komunikatu, to być moŜe domyślne ustawienie zostało juŜ zmienione. (W czasie tłumaczenia ksiąŜki, w grudniu 2000 r., obsługa przestrzeni nazw była juŜ domyślnie wyłączona — przyp. tłum.).

Wynik sprawdzania poprawności

123

* setDocumentLocator() została wywołana Rozpoczyna się przetwarzanie... startElement: nie posiada skojarzonej przestrzeni nazw Atrybut: =http://www.oreilly.com/catalog/javaxml/ ignorableWhitespace: [ ] startElement: nie posiada skojarzonej przestrzeni nazw znaki: Java i XML endElement: ...

Wynik moŜe nas nieco rozczarować. Nie róŜni się niczym od wyniku uzyskanego w przypadku parsera nie sprawdzającego poprawności (zob. rozdział 3.)! To dlatego, Ŝe nasz dokument jest poprawny i poprawnie sformatowany — parser sprawdzający poprawność nie ma o czym komunikować. To waŜne — zachowanie parsera w przypadku sprawdzania poprawnego dokumentu niemal nie róŜni się od zachowania parsera nie sprawdzającego poprawności. Jeśli to wydaje się dziwne, to naleŜy przypomnieć, Ŝe sprawdzanie poprawności ma na celu zagwarantowanie, Ŝe dokument nie łamie zdefiniowanych wcześniej zasad. Jeśli wszystkie reguły są przestrzegane, aplikacja uŜyje dokumentu XML zgodnie z jego przeznaczeniem. Tylko kiedy nastąpi złamanie zasad, parser sprawdzający poprawność wkracza do akcji — poniŜej zostaną omówione takie przypadki. Wcześniej jednak trzeba zauwaŜyć, Ŝe mimo wszystko powyŜszy wynik nieco róŜni się od poprzednich. Wcześniej wszystkie znaki białe pomiędzy elementami w dokumencie XML zgłaszane były poprzez wywołanie metody characters() w implementacji ContentHandler. W dokumencie XML, którego poprawność nie jest sprawdzana, parser ma moŜliwość zgłoszenia białych znaków albo przez tę metodę, albo przez ignorableWhitespace().Wynika to z faktu, Ŝe parser nie moŜe zakładać określonego przeznaczenia obecności białych znaków pomiędzy elementami bez definicji DTD zawęŜającej XML. Kiedy w programie włączamy sprawdzanie poprawności, widzimy, Ŝe wszystkie znaki białe zgłaszane są za pomocą ignorableWhitespace(). Przy sprawdzaniu poprawności wszystkie białe znaki są ignorowane i traktowane tak, jakby ich nie było — chyba Ŝe zostanie to inaczej ujęte w definicji DTD. Dzięki temu parser potrafi określić, czy zawartość elementu XML zgodna jest z definicją DTD bez analizowania białych znaków otaczających tę zawartość. Innymi słowy, parser potraktuje taki fragment XML: Cześć!

dokładnie tak samo jak: Cześć!

Drugi fragment jest co prawda mniej miły dla ludzkiego oka, ale zgodny jest z tymi samymi zawęŜeniami co fragment pierwszy i powinien być identycznie traktowany w czasie sprawdzania poprawności. Brak wcięć nie moŜe wpłynąć na działanie aplikacji korzystających z danych XML. Gdyby białe znaki tworzące wcięcia zgłaszane były poprzez wywołanie characters(), aplikacja monitorująca to wywołanie uznałaby, Ŝe dokumenty nie są identyczne.

OstrzeŜenia W wyniku Ŝądania sprawdzania poprawności nie mogą się pojawić niemal Ŝadne ostrzeŜenia. Jakiekolwiek dane XML niezgodne z odpowiednią definicją DTD są postrzegane jako błąd. Niepo-

Wynik sprawdzania poprawności

124

prawność dokumentu została uznana przez W3C za rzecz na tyle waŜną, Ŝe zawsze zgłaszany jest wtedy błąd. Dlatego trudno jest, szczególnie za pomocą parsera SAX 2.0, wywołać ostrzeŜenie. Jednak istnieją parsery SAX 1.0, w których jest to moŜliwe. Na przykład parser Project X firmy Sun zawiera obecnie klasę słuŜącą do sprawdzania poprawności XML-a w czasie przetwarzania i klasę nie wykonującą takiego sprawdzania. Jest to rozwiązanie podobne do omawianego wcześniej. Jeśli parser sprawdzający poprawność przetwarza dokument nie deklarujący definicji DTD w sposób jawny, generowane jest ostrzeŜenie. Dotyczy to tylko niektórych implementacji parserów SAX 1.0, dlatego w niniejszej ksiąŜce nie zostanie przedstawiony kod powodujący zgłoszenie ostrzeŜenia. Czytelnik moŜe natomiast obejrzeć wynik działania takiego ostrzeŜenia (przykład 5.7) — podobny do tych opisywanych w rozdziale 3.

Przykład 5.7. Program SAXParserDemo zgłaszający ostrzeŜenie D:\prod\JavaXML> java SAXParserDemo D:\prod\JavaXML\contents\contents.xml Przetwarzanie pliku XML: contents.xml

* setDocumentLocator() została wywołana Rozpoczyna się przetwarzanie... **Przetwarzanie ostrzeŜenia** Wiersz: 6 URI: file:/D:/prod/JavaXML/contents/contents.xml Komunikat: Valid documents must have a
Taki komunikat pojawiłby się, gdyby konstrukcja była opatrzona komentarzami lub gdyby została pominięta. PoniewaŜ niemal wszystkie parsery XML (w tym Project X firmy Sun) ewoluują w kierunku zgodności z SAX 2.0, takiego ostrzeŜenia najprawdopodobniej nigdy nie zobaczymy.

Błędy niekrytyczne Najbardziej typowym problemem z interfejsem SAX, jaki będzie zgłaszany w czasie sprawdzania poprawności XML, jest błąd o statusie „niekrytyczny”. Błąd taki generowany jest za kaŜdym razem, gdy pogwałcone zostaną zawęŜenia XML. Aby to zademonstrować, wykonajmy następującą zmianę w naszym przykładowym dokumencie XML (czyniąc go niepoprawnym): Java i XML

Taka zmiana, choć nie wpływa na poprawność danych XML, nie jest zgodna z narzuconymi regułami — atrybut dataPublikacji nie został zadeklarowany w definicji DTD i w czasie przetwarzania zgłoszony zostanie błąd (przykład 5.8).

Wynik sprawdzania poprawności

125

Przykład 5.8. Błąd zgłaszany przez program SAXParserDemo D:\prod\JavaXML> java SAXParserDemo D:\prod\JavaXML\contents\contents.xml Przetwarzanie pliku XML: contents.xml

* setDocumentLocator() została wywołana Rozpoczyna się przetwarzanie... **Przetwarzanie błędu** Wiersz: 14 URI: file:///mnt/teksty_zdalny/biura/helion/javaxml/cwiczenia/contents.xml Komunikat: Attribute "dataPublikacji" must be declared for element type "JavaXML:Ksiazka". Błąd w przetwarzaniu: Napotkano błąd

Analizator przesyła błąd do implementacji ErrorHandler, która zgłasza błąd — w tym przypadku mówiący, Ŝe atrybut nie został zadeklarowany dla zamykającego go elementu. Oczywiście, poprawność dokumentu moŜna zburzyć na wiele sposobów — to tylko jeden z nich; zawsze jednak zgłoszony zostanie ten sam błąd, warto więc poeksperymentować. NaleŜy po prostu pamiętać, Ŝe jakiekolwiek pogwałcenie DTD spowoduje zgłoszenie błędu. Dotyczy to przypadków, w których zawartość dokumentu nie jest poprawna, elementy nie są prawidłowo zagnieŜdŜone, atrybuty znajdują się nie tam, gdzie trzeba, lub są niepoprawne itd.

Błędy krytyczne Co ciekawe, dokument niezgodny z zawęŜeniami DTD nigdy nie spowoduje wygenerowania błędu krytycznego. W czasie przetwarzania dokumentu nie mogą zajść takie warunki, które spowodują przerwanie tego procesu. MoŜe nam się wydawać, Ŝe kontynuacja przetwarzania niepoprawnego dokumentu kłóci się z celowością sprawdzania poprawności. NaleŜy jednak pamiętać o tym, Ŝe w większości przypadków dokumenty XML są generowane przez aplikacje. Innymi słowy, aplikacja otrzymuje dane wejściowe XML z innego programu lub podprogramu. Jeśli dane te są niepoprawne, aplikacja usiłująca z nich skorzystać powinna zgłosić aplikacji klienta błąd, a nie przerywać przetwarzanie. Co więcej, przetwarzanie to niejednokrotnie powinno być kontynuowane, aby moŜliwe było zakończenie procesu w sposób elegancki — w ten sposób aplikacja jest w stanie precyzyjnie zakomunikować, jakie błędy wystąpiły. Dokumenty błędnie sformatowane spowodują zatrzymanie przetwarzania, a dokumenty niepoprawne wskaŜą, Ŝe albo nastąpił błąd, który moŜna poprawić, albo zaszła sytuacja, o której klient powinien wiedzieć, np. wprowadzono niepoprawne dane. Zastanówmy się, jak trudno byłoby obsługiwać edytor XML lub środowisko programistyczne IDE, jeśli za kaŜdym razem, gdy nie do końca przestrzegaliśmy zawęŜeń DTD, edytor kończyłby działanie z błędem krytycznym, lub teŜ odmawiałby w ogóle przetwarzania dokumentu; a przecieŜ niektóre edytory mogłyby takie błędy poprawiać za nas! Dlatego właśnie niepoprawne dokumenty powodują zgłaszanie ostrzeŜeń i błędów, ale nigdy błędów krytycznych. Jedyny błąd krytyczny, na jaki moŜemy się natknąć przy uŜywaniu definicji DTD w dokumentach, których poprawność nie jest sprawdzana, to błąd składniowy w wykorzystywanej definicji DTD. To nie powinno Czytelnika dziwić, jako Ŝe błędy składniowe w dokumencie XML takŜe powodują błędy krytyczne. Ma tutaj miejsce to samo rozumowanie — nie jest moŜliwe dalsze przetwarzanie lub sprawdzanie poprawności, jeśli nie moŜna określić zawęŜeń (a tak jest, gdy składnia DTD nie jest poprawna). Powinniśmy zdawać sobie sprawę, Ŝe to nie to samo co błąd generowany, gdy mamy do czynienia z niepoprawnie sformatowanym dokumentem XML — główna róŜnica polega na

Interfejs DTDHandler

126

tym, Ŝe definicja DTD nigdy nie jest postrzegana jako „poprawnie sformatowana”, bo przecieŜ nie jest to tak naprawdę dokument XML. Ale rezultat wystąpienia błędów składniowych w DTD jest taki sam, jak rezultat przetwarzania niepoprawnie sformatowanych danych XML.

Interfejs DTDHandler Ostatnia waŜna procedura obsługi udostępniania przez SAX rejestruje metody wywołań wstecznych w czasie procesu czytania i przetwarzania definicji DTD dokumentu. W interfejsie tym nie są zdefiniowane zdarzenia, jakie występują w czasie sprawdzania poprawności, a jedynie te, które występują w czasie czytania DTD. W podrozdziale dotyczącym pułapek zostaną omówione problemy wywoływane przez to zróŜnicowanie. Ta procedura obsługi zachowuje się w taki sam sposób jak interfejsy ContentHandler i ErrorHandler, omawiane w rozdziale 3. — definiowane są dwie metody wywoływane w czasie przetwarzania. Sprawdzanie poprawności dokumentu XML jest bardzo waŜne, ale zdarzenia związane z odczytywaniem dokumentu DTD — juŜ mniej. Są tylko dwie metody, obie nie są wykorzystywane tak często, a więc prawdopodobnie rzadko Czytelnik będzie musiał korzystać z interfejsu DTDHandler (chyba Ŝe pisząc edytor lub IDE dla XML-a będzie chciał tworzyć lub przetwarzać dokumenty DTD w celu sprawdzenia poprawności zapisu i składni). Dlatego pokrótce omówimy tutaj te dwie metody udostępniane przez SAX, ale nie będziemy poświęcali im zbyt duŜo czasu. O opcjonalnej procedurze obsługi SAX, słuŜącej do pobierania innych informacji z DTD, moŜna przeczytać w części DeclHandler, w dodatku A (pakiet org.xml.sax.ext).

Nieprzetwarzane deklaracje encji Pierwsze wywołanie wsteczne, unparsedEntityDecl(), wywoływane jest, kiedy deklaracja encji w DTD mówi, iŜ encja ta ma nie być przetwarzana przez parser XML. Choć nie omawialiśmy jeszcze przykładu takiego zachowania, nieprzetwarzane encje są dość typowe w dokumentach XML, w których istnieją odwołania do plików graficznych lub innych danych binarnych (często plików multimedialnych). Metoda ta pobiera nazwę encji, identyfikatory, publiczny i systemowy, oraz nazwę notacyjną encji. Nazwy notacyjne w XML-u nie były jeszcze omawiane. Spójrzmy na przykład dokumentu XML odwołującego się do pliku graficznego (np. do logo firmy) — przykład 5.9.

Przykład 5.9. Dokument XML z nieprzetwarzaną encją &LogoFirmy;

Podczas przetwarzania parser stara się przetłumaczyć wszystkie encje i wstawić w ich miejsce przetworzoną wartość. JednakŜe parser nie potrafi przetwarzać plików graficznych i powinien pozostawić dane binarne w postaci nieprzetworzonej. MoŜna go o tym „poinformować” poprzez następującą definicję typu dokumentu:

Słowo kluczowe NDATA powoduje, Ŝe parser XML nie przetworzy tej encji. Gdyby ta definicja DTD była przetwarzana za pośrednictwem zarejestrowanej implementacji DTDHandler, informacja w deklaracji encji zostałaby przekazana do wywołania. Inną waŜną sprawą jest tutaj fakt, Ŝe wywołanie następuje w miejscu deklaracji w DTD, a nie w chwili, gdy deklaracja ta jest prze-

Interfejs DTDHandler

127

twarzana w dokumencie XML. Oznacza to, Ŝe nawet jeśli encja nie znajduje się w dokumencie XML, to i tak wywołanie nastąpi. To ma sens — przecieŜ wywołanie to stanowi część interfejsu DTDHandler, a nie ContentHandler.

Deklaracje notacji Deklaracje notacji zawsze skojarzone są z nieprzetwarzanymi deklaracjami i stanowią przedmiot działania drugiej metody wchodzącej w skład DTDHandler. Ostatnia część powyŜszej deklaracji nieprzetwarzanej encji to słowo „gif”. Słowo to określa typ nieprzetwarzanej encji i musi stanowić odwołanie do typu zdefiniowanego w innym miejscu DTD, za pośrednictwem konstrukcji NOTATION. W ten sposób parser poznaje identyfikator URI dla danego typu — często jest to odwołanie publiczne dla typów binarnych. Przypomina to odwoływanie się do DTD z dokumentu XML, poniewaŜ specyficzne dane (w tym przypadku plik GIF) są kojarzone z publicznym identyfikatorem lub URI. Przetwarzanie definicji NOTATION i deklaracji nieprzetwarzanej encji powoduje w rezultacie, Ŝe parser XML nie przetwarza danych binarnych. A o to właśnie chodziło.

Wystąpienia takich deklaracji zgłaszane są zarejestrowanej procedurze obsługi poprzez wywołanie notationDecl(). Po wywołaniu metoda ta otrzymuje deklarację notacji, identyfikator systemowy i dostępny identyfikator publiczny. Podobnie jak w przypadku nieprzetwarzanych encji, metoda ta wywoływana jest podczas odczytywania definicji DTD, a nie samego dokumentu XML.

Rejestrowanie procedury obsługi Rejestrowanie implementacji DTDHandler w naszym parserze XML nie róŜni się niczym od rejestrowania procedur obsługi błędów i zawartości. Egzemplarz klasy przekazywany jest metodzie setDTDHandler(), a parser rejestruje odpowiednie zdarzenia związane z metodami SAX w tej klasie: import java.io.IOException; import import import import import import import import import

org.xml.sax.Attributes; org.xml.sax.ContentHandler; org.xml.sax.DTDHandler; org.xml.sax.ErrorHandler; org.xml.sax.Locator; org.xml.sax.SAXException; org.xml.sax.SAXParseException; org.xml.sax.XMLReader; org.xml.sax.helpers.XMLReaderFactory;

... // Stwórz egzemplarze procedur obsługi ContentHandler contentHandler = new MyContentHandler(); ErrorHandler errorHandler = new MyErrorHandler(); DTDHandler dtdHandler = new MyDTDHandler(); try { // Stwórz egzemplarz parsera XMLReader parser = XMLReaderFactory.createXMLReader( "org.apache.xerces.parsers.SAXParser");

Uwaga! Pułapka!

128 // Zarejestruj procedurę obsługi zawartości parser.setContentHandler(contentHandler); // Zarejestruj procedurę obsługi błędów parser.setErrorHandler(errorHandler); // Zarejestruj procedurę obsługi DTD parser.setDTDHandler(dtdHandler); // Włącz sprawdzanie poprawności parser.setFeature("http://xml.org/sax/features/validation", true); // Wyłącz "świadomość" przestrzeni nazw parser.setFeature("http://xml.org/sax/features/namespaces", false); // Przetwórz dokument parser.parse(uri);

} catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); }

I cała reszta... Czytelnik moŜe odnieść wraŜenie, Ŝe interfejs procedury obsługi DTD został omówiony dość pobieŜnie, szczególnie w porównaniu z innymi procedurami. JednakŜe aplikacje wykorzystujące XML rzadko muszą rejestrować tego typu procedury. W systemach XML-owych często sprawdza się poprawność dokumentu, ale szczegółowe informacje odnośnie nieprzetworzonych encji rzadko przydają się na wyŜszym poziomie wykorzystania XML-a. Dlatego właśnie przejdziemy do innych szczegółowych informacji, bardziej przydatnych przy tworzeniu aplikacji korzystających z XML-a. Czytelnik mógłby oczekiwać, Ŝe teraz zostanie omówione sprawdzanie poprawności za pomocą XML Schema; schematy są jednakŜe w coraz większym stopniu wykorzystywane nie tylko do sprawdzania poprawności, ale takŜe do zwykłej reprezentacji danych. Dlatego właśnie omawianie schematów z poziomu Javy zostało przeniesione do rozdziału 14. — wtedy Czytelnik będzie juŜ znał XSL i róŜnego rodzaju praktyczne sposoby uŜycia XML-a w aplikacjach. Interfejsy SAX do obsługi schematów są o wiele potęŜniejsze niŜ DTDHandler i będą wymagały od Czytelnika większej wiedzy z zakresu XML-a. W niniejszym rozdziale omawianie sprawdzania poprawności danych XML zostanie zakończone przedstawieniem typowych problemów, na jakie moŜna się natknąć w czasie tego procesu.

Uwaga! Pułapka! Podczas sprawdzania poprawności dokumentu XML na programistę czyha wiele pułapek. PoniŜej zostaną omówione problemy, z którymi najczęściej mają do czynienia początkujący programiści XML, a takŜe te, których rozwiązanie wcale nie jest łatwe. Warto dobrze się zapoznać z poniŜszym materiałem, bo opisywane trudności spędziły sen z oczu juŜ niejednemu programiście.

Uwaga! Pułapka!

129

Obsługa sprawdzania poprawności a obsługa definicji DTD Jednym z typowych nieporozumień odnośnie SAX-a i sprawdzania poprawności jest błędne załoŜenie, Ŝe sprawdzanie poprawności dokumentu XML następowało automatycznie po zarejestrowaniu implementacji DTDHandler w parserze XML. Często zdarza się, Ŝe programista implementuje ten interfejs i rejestruje go w parserze, ale nie włącza funkcji sprawdzania poprawności parsera. Ten błąd wynika z zagubienia róŜnicy pomiędzy obsługą samego DTD a wykorzystaniem DTD do sprawdzania poprawności. W tym przypadku definicja DTD zostanie przetworzona, wystąpią teŜ wszystkie wywołania związane z DTD (o ile są konieczne), jednakŜe nie nastąpi sprawdzenie poprawności dokumentu XML — zostanie on wyłącznie przetworzony. NaleŜy pamiętać, Ŝe wynik sprawdzania poprawności poprawnego dokumentu XML wygląda niemal tak samo jak wynik przetwarzania dokumentu bez sprawdzania jego poprawności; zawsze naleŜy śledzić, kiedy występuje sprawdzanie poprawności — w ten sposób moŜna uniknąć błędów w aplikacji: try { // Stwórz egzemplarz parsera XMLReader parser = XMLReaderFactory.createXMLReader( "org.apache.xerces.parsers.SAXParser"); // Zarejestruj procedurę obsługi zawartości parser.setContentHandler(contentHandler); // Zarejestruj procedurę obsługi błędów parser.setErrorHandler(errorHandler); // Z tego nie wynika włączenie sprawdzania poprawności parser.setDTDHandler(dtdHandler); // Włącz sprawdzanie poprawności parser.setFeature("http://xml.org/sax/features/validation", true); // Wyłącz "świadomość" przestrzeni nazw parser.setFeature("http://xml.org/sax/features/namespaces", false); // Przetwórz dokument parser.parse(uri); } catch (IOException e) { System.out.println("Błąd przy wczytywaniu URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); }

Trzeba koniecznie pamiętać o tym, Ŝe zarejestrowanie DTD nie ma nic wspólnego z procesem sprawdzania poprawności; parser z zarejestrowaną implementacją DTDHandler nie zawsze sprawdza poprawność XML-a; zaś parser bez zarejestrowanej tej procedury moŜe sprawdzić poprawność. To od cech (w implementacjach SAX 2.0) lub klasy (w implementacjach sprzed SAX 2.0) parsera XML zaleŜy, czy sprawdzanie poprawności będzie się odbywało — a nie od zarejestrowanej procedury obsługi. Pamiętajmy o tym — implementacja DTDHandler do sprawdzania poprawności nie jest potrzebna; potrzebne jest natomiast ustawienie odpowiednich cech parsera lub uŜycie innej klasy.

Co dalej?

130

W czasie tworzenia priorytetem jest poprawność; w gotowej aplikacji liczy się szybkość Programista powinien wiedzieć, kiedy naleŜy korzystać ze sprawdzania poprawności, a kiedy nie. Jednym z największych problemów związanych ze sprawdzaniem poprawności jest często niezwykle powolne działanie aplikacji produkcyjnej. Programista analizuje przyczyny takiego spadku wydajności pracy aplikacji, nie pamiętając o tym, Ŝe w środowisku produkcyjnym pozostawił włączone sprawdzanie poprawności. Zazwyczaj sprawdzanie poprawności powinno mieć miejsce tylko w czasie testowania lub w czasie działania procesu kontrolowania jakości (ang. Quality Assurance). Jeśli część aplikacji generuje lub modyfikuje pliki XML, sprawdzanie poprawności wynikowego dokumentu XML powinno odbywać się właśnie w czasie testowania. To proces kosztowny — parser przetwarza o wiele więcej danych i musi podjąć więcej decyzji dotyczących dokumentu. Po sprawdzeniu poprawności wyników generowanych przez aplikację zazwyczaj dobrze jest wyłączyć sprawdzanie poprawności. Aplikacja produkcyjna zyskuje dzięki temu na wydajności, a jeśli testowanie przeprowadzono zgodnie z zasadami tej sztuki, to nie powinny pojawić się Ŝadne problemy. Jedyną sytuacją, w której nie naleŜy wyłączać sprawdzania poprawności w aplikacji produkcyjnej, jest ta, w której w tworzeniu danych XML bierze aktywny udział klient — np. w narzędziach XML IDE lub GUI, albo ta, w której dane XML uzyskuje się od innych aplikacji — np. w e-biznesie. Wynika to stąd, Ŝe dane wejściowe są poza naszą kontrolą i mogą być niepoprawne — sprawdzanie poprawności jest więc zalecane, a nawet oczekiwane przez klienta. Jednak w większości przypadków gotowa aplikacja moŜe pracować bez sprawdzania poprawności.

Co dalej? Czytelnik powinien juŜ dobrze znać zasady tworzenia dokumentów XML oraz sposoby ich zawęŜania. W niniejszym rozdziale zostały omówione wszystkie najwaŜniejsze aspekty korzystania z interfejsów i klas SAX. Czytelnik poznał juŜ cykle przetwarzania i sprawdzania poprawności oraz dostępne wywołania. Powinien potrafić skonfigurować i uŜyć parsera XML oraz zarejestrować w nim róŜne procedury obsługi SAX. W następnym rozdziale zostanie przedstawiona kolejna specyfikacja — XSL, czyli rozszerzalny język arkuszy stylów. Omówienie przekształcania za pomocą XSL to wstęp do dyskusji o obiektowym modelu dokumentu i mechanizmach publikacyjnych, a takŜe do bardziej dogłębnego poznawania zagadnień programowania aplikacji.

Cel

131

6 Przekształcanie kodu XML Jeśli Czytelnik bierze udział w tworzeniu systemów wewnętrznych lub projektuje systemy, to juŜ na tym etapie czytania powinien doceniać moŜliwości XML-a. Język reprezentujący dane w sposób niezaleŜny od producenta, prosty w przetwarzaniu, przenośny i obsługiwany z poziomu Javy — czy to właśnie ten format danych rozwiąŜe wszystkie problemy ze współpracą pomiędzy aplikacjami? MoŜliwe. Jeśli jednak Czytelnik jest programistą zawartości, budowniczym aplikacji, lub teŜ zaangaŜowany jest w prezentację aplikacji, moŜe odczuwać zniecierpliwienie — po przeczytaniu pięciu rozdziałów nie wie jeszcze, jak generować zawartość dla klientów z wykorzystaniem XML-a, jak separować prezentacje od danych. W tym rozdziale zostanie rozpoczęte omawianie przekształcania danych XML. Jest to obszerny temat obszerny. Najpierw zostaną przedstawione cele i sposoby przekształcania danych XML. W następnym rozdziale przedstawiony zostanie procesor Java XSLT, który pobiera dokument XML i generuje róŜne rodzaje zawartości — często róŜniące się w sposób zasadniczy od pierwotnych danych XML. Czytelnik dowie się równieŜ, jak w tym procesie wykorzystywany jest obiektowy model dokumentu (DOM). Przekształcanie XML-a jest tak obszernym tematem, Ŝe nie sposób omówić tutaj wszystkich dostępnych konstrukcji składniowych. Referencyjne podejście do przekształcania przedstawione jest w ksiąŜce XML Pocket Reference Roberta Ecksteina (O'Reilly & Associates). Przekształcaniu XML-a poświęcono równieŜ sporą część serwisu WWW grupy W3C: http://www.w3.org/Style/XSL/.

Cel Przed przystąpieniem do omawiania procesu przekształcania danych XML, warto powiedzieć kilka słów o samym celu przekształcania. Podobnie jak w przypadku omawiania istoty zawęŜania danych XML, dobre zrozumienie przekształcania umoŜliwi poprawne wykonywanie tego procesu. Przekształcanie nie jest rozwiązaniem ostatecznym w zakresie prezentacji danych i nie wszędzie powinno być wykorzystywane; jednak są sytuacje, w których przekształcanie oszczędzi wiele godzin naszej pracy.

Cel

132

W następnych dwóch rozdziałach skoncentrujemy się na sposobie, w jaki dane XML mogą zostać przedstawione róŜnym klientom. JednakŜe niekoniecznie oznacza to, Ŝe będziemy zajmować się prezentacją danych samemu uŜytkownikowi... właściwie o tym nie powiemy prawie nic! Jeśli Czytelnik czuje się teraz nieco zagubiony, to nic nie szkodzi. Najpierw przypomnijmy sobie, co rozumiemy pod pojęciem klienta.

Klient klienta mojego klienta Najczęściej klienta lub aplikację klienta opisuje się jako uŜytkownika końcowego. Ale pogląd, Ŝe klientem aplikacji jest po prostu człowiek siedzący przed przeglądarką WWW lub interfejsem GUI jest nieścisły. Powiedzieliśmy juŜ o tym, jak róŜne mogą być klienty korzystające z aplikacji; teraz rozszerzymy tę definicję jeszcze bardziej. Weźmy na przykład mechanizm bazy danych. Dane w bazie rzadko wyświetlane są bezpośrednio uŜytkownikowi, bez wcześniejszego sformatowania ich przez inny program. Czy moŜemy więc powiedzieć, Ŝe z bazy nie korzystają Ŝadne klienty? A co z aplikacją przetwarzającą dane o pogodzie z innej strony HTML i wyświetlającą je uŜytkownikowi w nowym formacie? Czy aplikacja ta ma dwa klienty? A np. system X Windows, gdzie wyświetlany obraz generowany jest na serwerze, a aplikacja zdalna jest klientem? Oczywiste jest, Ŝe definicja klienta jest bardzo pojemna. Na potrzeby niniejszej ksiąŜki klientem będziemy nazywali wszystko to, co korzysta z danych aplikacji, programu lub mechanizmu. Klientem w tym pojęciu byłby więc program korzystający z opisanej wyŜej bazy danych, a takŜe uŜytkownik, który przegląda sformatowane dane. Program formatujący dane o pogodzie jest klientem; są nimi takŜe uŜytkownicy korzystający ze sformatowanych danych. Jak widać, granica między pojęciami „uŜytkownik” a „program” zaciera się. W wielowarstwowym systemie, w którym uruchomiono bazę danych, pojemnik Enterprise JavaBean, mechanizm serwletów i strukturę publikacji istnieją cztery, pięć lub więcej klientów! Czytelnik winien zrozumieć, Ŝe w przypadku XML-a nie rozróŜniamy pomiędzy klientem a programem korzystającym z danych. Pozwala to nam postrzegać przekształcanie danych w sposób bardziej uŜyteczny — jeśli aplikacja A wymaga danych (w formacie A) od aplikacji B (przechowującej dane w formacie B), musimy te dane przekształcić (ang. transform). W przekształcaniu biorą udział dwa formaty, natomiast same dane pozostają nienaruszone. Kiedy znamy juŜ nową definicję klienta, to moŜemy jeszcze od procesu tego oddzielić szczegółowe informacje o aplikacji wykorzystującej dane. Jeśli aplikacja C wykorzystuje sformatowane dane aplikacji B w formacie C, musi się odbyć kolejne przekształcanie. Nie jest istotne, czy formaty te to HTML, SQL, XML zgodny z róŜnymi DTD, czy coś jeszcze zupełnie innego. Nie jest równieŜ istotne to, czy klient jest kolejnym programem, uŜytkownikiem czy systemem własnym. Przekształcanie to po prostu przekładanie z jednego formatu na drugi. Wszystkie te informacje pomogą Czytelnikowi zrozumieć, dlaczego przekształcanie danych XML jest tak waŜne.

Ja nie rozumiem chińskiego ... Jak moŜna się domyślać, najwaŜniejszym celem przekształcania danych XML jest doprowadzenie ich do takiej postaci, aby były czytelne dla danego klienta. Czasami moŜna to osiągnąć poprzez przekształcenie dokumentu XML zgodnego z pewną definicją DTD na dokument zgodny z inną definicją (lub schematem). Innym razem konieczne jest uzyskanie zupełnie innych dokumentów z dokumentu bazowego. Tak czy inaczej, potrzebne tutaj będą informacje dotyczące zawęŜania i sprawdzania poprawności danych XML. Nawet jeśli aplikacja „zna” format danych, to nie będzie go mogła jeszcze zinterpretować — do tego konieczne są definicje DTD, schematy lub inne zawę-

Składniki

133

Ŝenia dokumentu. Wtedy dopiero aplikacja „zrozumie”, jakiej konwersji moŜna dokonać i jakie struktury danych są obecne w dokumencie źródłowym. Problemy pojawiają się wtedy, gdy wzrasta liczba permutacji współpracujących ze sobą aplikacji; innymi słowy, im więcej jest składników biorących udział w wymianie danych, tym więcej moŜliwości przekształcania tych danych. KaŜdy komponent musi znać zawęŜenia innych komponentów. Dlatego właśnie stworzono zestaw specyfikacji i standardów słuŜących do przekształcania danych XML. Powstała warstwa pośrednia, niezaleŜna od poszczególnych komponentów aplikacji, która umoŜliwia konwersję danych z jednego formatu lub stylu na inny; samym komponentom pozostawia się czuwanie nad logicznym przetwarzaniem danych. Tę powłokę pośrednią będziemy nazywali procesorem. Procesor ma za zadanie pobrać jeden lub więcej dokumentów, określić ich formaty i zawęŜenia i dokonać przekształcenia (transformacji), po której powstają dane w nowym formacie (a to moŜe nawet oznaczać rozdzielenie ich na wiele plików). Dokument wynikowy moŜe potem zostać uŜyty przez inny komponent. Oczywiście, ta aplikacja moŜe z kolei przekazać dane do innego procesora, który przekaŜe dokument w jeszcze innym formacie trzeciemu komponentowi i tak dalej. W ten sposób aplikacje nie znające tego samego „języka” mogą się ze sobą porozumiewać. PoniŜej omówione zostaną „podzespoły” biorące udział w tym procesie.

Składniki Przekształcanie danych XML jest bardzo przydatne, ale wcale nie łatwe w implementacji. Nie określono sposobów przekształcania w oryginalnej specyfikacji XML 1.0; zamiast tego powstały trzy oddzielne zalecenia dotyczące przekształcania. Jeden z tych sposobów (XPath) jest równieŜ wykorzystywany w specyfikacji XPointer, ale na pewno najwaŜniejszym celem opisywanych niŜej komponentów jest przekształcanie XML-a z jednego formatu na inny. Te trzy specyfikacje są ze sobą ściśle powiązane (i niemal zawsze wykorzystywane wspólnie), więc zwykle opisuje się je razem. Powstały opis jest prostszy w zrozumieniu, ale niekoniecznie poprawny technicznie. Innymi słowy, termin XSLT, oznaczający dokładnie „przekształcenia XSL”, często stosowany jest jako określenie zarówno rozszerzalnych arkuszy stylów (XSL), jak i specyfikacji XPath. Podobnie, za pomocą terminu XSL określa się często wszystkie te trzy technologie. Tutaj zalecenia te zostaną rozdzielone. Jednak w celu uproszczenia będziemy uŜywać skrótów XSL i XSLT przemiennie — określając za ich pomocą cały proces przekształcania. Nie jest to moŜe zgodne z wytycznymi wspomnianych specyfikacji, ale na pewno zgodne z ich duchem i prostsze w zrozumieniu.

Rozszerzalny język arkuszy stylów (XSL) XSL to rozszerzalny język arkuszy stylów (ang. Extensible Stylesheet Language). SłuŜy do tworzenia arkuszy stylów. To obszerna definicja, którą moŜna rozbić na dwie części: • XSL to język słuŜący do przekształcania dokumentów XML; • XSL to zbiór słów XML słuŜących do formatowania dokumentów XML. Te definicje są do siebie podobne. Jedna z nich opisuje przekształcanie z jednego formatu XML na inny; druga odnosi się do samej prezentacji zawartości dokumentu. Mówiąc prościej, XSL opisuje, jak przekształcać dokument z formatu A na format B. Składniki tego języka opisują sposób takiego przekształcania.

Składniki

134

XSL a drzewa Aby zrozumieć istotę XSL, trzeba przede wszystkim uświadomić sobie, Ŝe wszystkie dane biorące udział w przetwarzaniu XSL mają strukturę drzewiastą (patrz rysunek 6.1). Nawet same reguły definiowane za pomocą arkuszy XSL umieszczane są w takiej strukturze. Dzięki temu przetwarzanie dokumentów XML (takŜe posiadających strukturę drzewiastą) jest bardzo proste. Za pomocą szablonów dopasowuje się element główny przetwarzanego dokumentu XML. Następnie dalsze reguły („liście”) stosuje się na dalszych elementach („liściach”) dokumentu XML, aŜ do tych połoŜonych najniŜej. Elementy mogą być przetwarzane, przekształcane za pomocą stylów, ignorowane, kopiowane lub w inny sposób „obrabiane” na dowolnym etapie tego procesu.

Rysunek 6.1. Operacje na drzewach w XSL Struktura drzewiasta ma tę zaletę, Ŝe umoŜliwia grupowanie dokumentów XML. Jeśli element A zawiera elementy B i C i nastąpi jego przeniesienie lub skopiowanie to elementy w nim zawarte będą podlegały tej samej operacji. Dzięki temu obsługa duŜych porcji danych za pomocą arkusza XSL jest spójna i przejrzysta. O budowie takiego drzewa powiemy więcej w następnej części, przy okazji omawiania standardu XSLT.

Obiekty formatujące Niemal cała specyfikacja XSL to definicje obiektów formatujących. Obiekt formatujący oparty jest na duŜym modelu określanym — jak łatwo się domyślić — nazwą modelu formatującego. W ramach modelu zdefiniowano zestaw obiektów, które przekazywane są na wejście programu formatującego. Program taki „aplikuje” obiekty formatujące na całym albo na części dokumentu; w rezultacie powstaje nowy dokument składający się z wszystkich lub tylko z części danych oryginalnego dokumentu XML, ale juŜ w nowym formacie, odpowiadającym obiektom wykorzystanym przez program formatujący. Jest to, jak widać, koncepcja bardzo luźno zdefiniowana; dlatego teŜ w ramach specyfikacji XSL starano się stworzyć bardziej konkretny model, z którym obiekty miałyby być zgodne. Innymi słowy, istnieje obszerny zestaw właściwości i słów kluczowych,

Składniki

135

które moŜna wykorzystać w obiektach formatujących. Mamy tutaj typy obszarów podlegających wizualizacji, właściwości linii, czcionek, grafiki i innych obiektów wizualnych, obiekty formatujące typu „inline” i blokowe oraz wiele innych konstrukcji składniowych. Obiekty formatujące są szczególnie intensywnie wykorzystywane przy konwersji tekstowych danych XML na formaty binarne, takie jak pliki PDF lub dokumenty binarne w rodzaju Microsoft Word. Przy przekształcaniu danych XML na innegy format tekstowy obiekty te rzadko wykorzystuje się jawnie. PoniewaŜ większość aplikacji uŜywanych w przedsiębiorstwach jest obecnie przynajmniej częściowo oparta na architekturze WWW, a w funkcji klienta wykorzystywana jest przeglądarka WWW, skoncentrujemy się głównie na przekształcaniu do formatu HTML-a lub XHTML-a. Będzie to wymagało jedynie pobieŜnego omówienia obiektów formatujących; temat obiektów formatujących jest jednak na tyle obszerny, Ŝe zasługuje na oddzielną ksiąŜkę lub witrynę WWW. Więcej informacji na ten temat moŜna znaleźć w specyfikacji XSL pod adresem http://www.w3.org/TR/WD-xsl.

Transformacje XSL (XSLT) Drugim istotnym elementem opisywanego zagadnienia są transformacje XSL. Językiem opisującym konwersję dokumentu z jednego formatu na drugi jest XSLT. Składnia XSLT opisuje głównie te transformacje, które nie generują danych binarnych. Chodzi tu na przykład o przekształcanie dokumentu XML do HTML-a lub WML-a (Wireless Markup Language). Faktycznie, specyfikacja XSLT opisuje składnię arkuszy XSL w sposób bardziej jawny niŜ sama specyfikacja XSL! Podobnie jak w przypadku XSL, XSLT to zawsze poprawnie sformatowany i poprawny dokument XML. Dozwolone konstrukcje opisane są w odpowiedniej definicji DTD. W celu korzystania z XSLT konieczne jest więc nauczenie się jedynie nowej składni — a nie całkowicie nowych struktur, jak to ma miejsce w przypadku definicji DTD. Podobnie jak w przypadku XSL, XSLT oparty jest na hierarchii drzewiastej — elementy zagnieŜdŜone to „liście” lub „potomki”. XSLT udostępnia mechanizm dopasowania wzorców występujących w oryginalnym dokumencie XML (za pośrednictwem wyraŜeń XPath, które wkrótce zostaną przedstawione), a następnie stosowania formatowania na znalezionych w ten sposób danych. Formatowanie moŜe polegać po prostu na wysłaniu danych pozbawionych nazw elementów XML na wyjście albo na wstawieniu ich do złoŜonej tabeli HTML i wyświetleniu w róŜnych kolorach. XSLT udostępnia równieŜ rozmaite popularne operatory, takie jak instrukcje warunkowe, moŜliwość kopiowania fragmentów drzewa dokumentu, zaawansowane dopasowania wzorca oraz dostęp do elementów XML poprzez ścieŜki absolutne i względne. Wszystko to upraszcza proces przekształcania dokumentu XML na nowy format.

Język XML Path (XPath) XPath to ostatni element uŜywany w procesie przekształcania XML-a. XPath to mechanizm umoŜliwiający odwoływanie się do róŜnych nazw elementów i atrybutów w dokumencie XML. Jak wspomnieliśmy wcześniej, wiele specyfikacji XML korzysta z technologii XPath, ale tutaj skupimy się jedynie na wykorzystaniu jej w ramach XSLT. Przy złoŜonej strukturze, jaką moŜe mieć dokument XML, zlokalizowanie konkretnego elementu lub grupy elementów moŜe sprawiać trudności — tym większe, Ŝe nie moŜna zakładać istnienia definicji DTD lub innych zawęŜeń opisujących strukturę dokumentu. Musi istnieć moŜliwość przekształcania zarówno dokumentów podlegających, jak i nie podlegających sprawdzaniu poprawności. Adresowanie elementów w XPath odbywa się za pomocą składni odpowiadającej strukturze drzewiastej dokumentu XML oraz operującym na niej procesom i konstrukcjom XSLT.

Składniki

136

Najprościej odwołać się do dowolnego elementu lub atrybutu w dokumencie XML poprzez podanie ścieŜki do tego elementu względem elementu bieŜącego (przetwarzanego w danej chwili). Innymi słowy, jeśli element B jest elementem bieŜącym, a w nim zagnieŜdŜone są elementy C i D, to te dwa ostatnie najprościej zlokalizujemy za pomocą ścieŜki względnej. Przypomina to ścieŜki względne w strukturze katalogów systemu operacyjnego. W XPath zdefiniowano równieŜ sposób adresowania elementów względem elementu głównego. Konieczne jest tutaj odwołanie się do elementu nie znajdującego się w zakresie nazwy elementu bieŜącego; innymi słowy — elementu nie zagnieŜdŜonego w obecnie przetwarzanym elemencie. W XPath zdefiniowano wreszcie składnię dopasowywania wzorca („znajdź element, którego elementem macierzystym jest E i którego elementem siostrzanym jest F”). W ten sposób zapełniono lukę pomiędzy ścieŜkami absolutnymi i względnymi. We wszystkich wyraŜeniach moŜna równieŜ korzystać z atrybutów (i stosować na nich podobne dopasowania). W przykładzie 6.1 reprezentowane są róŜne sposoby uŜycia Xpath.

Przykład 6.1. WyraŜenia XPath

PoniewaŜ często dokument wejściowy nie ma ustalonej struktury, moŜe się okazać, Ŝe wyraŜenie XPath przetwarza puste dane wejściowe, jeden element lub atrybut wejściowy, lub teŜ wiele elementów i atrybutów wejściowych. Ta poŜyteczna moŜliwość wiąŜe się z wprowadzeniem szeregu dodatkowych pojęć. Wynik przetwarzania wyraŜenia XPath określa się mianem zestawu węzłów (ang. node set). To nie powinno Czytelnika dziwić, poniewaŜ termin „węzeł” był juŜ uŜywany wcześniej. Koncepcja ta jest zbieŜna z hierarchiczną strukturą drzewiastą, często opisywaną pojęciami „liści” lub właśnie „węzłów”. Wynikowy zestaw węzłów moŜe być następnie przekształcony, skopiowany, zignorowany lub poddany innym dozwolonym operacjom. Oprócz wyraŜeń umoŜliwiających wybór zestawów węzłów, XPath udostępnia równieŜ funkcje operujące na zestawach węzłów, takie jak not() i count(). Funkcje te pobierają zestaw węzłów (zazwyczaj w postaci wyraŜenia XPath) i poddają je dalszym przeliczeniom. Wszystkie wyraŜenia i funkcje stanowią część specyfikacji i implementacji XPath; pojęcie XPath jest jednak równieŜ uŜywane do opisania wyraŜenia zgodnego z samą specyfikacją. Nie jest to (podobnie jak w XSL i XSLT) zawsze technicznie poprawne, ale upraszcza opisywanie XSL i XPath. Opis składni tych trzech komponentów jako takiej byłby po prostu kopiowaniem specyfikacji. Dlatego po raz kolejny posłuŜymy się naszym przykładowym dokumentem XML. Stworzymy fragment dokumentu HTML na podstawie poznanego juŜ spisu treści w formacie XML. Pozwoli nam to zaznajomić się z językami XSL, XSLT i XPath w kontekście praktycznego zastosowania.

Składnia

137

Składnia Skoro juŜ znamy funkcje poszczególnych fragmentów układanki o nazwie „przekształcanie XML”, spróbujmy poukładać je w całość. Rozpoczniemy od naszego pierwotnego dokumentu XML reprezentującego fragment spisu treści niniejszej ksiąŜki. Za zadanie postawimy sobie uzyskanie sformatowanego według naszego uznania dokumentu HTML. Operacje tego typu przeprowadza się niezwykle często. My zastosujemy jedynie proste formatowanie, ale moŜliwości są tutaj ogromne — ograniczeniem jest tylko wiedza i doświadczenie programisty. W poniŜszych ćwiczeniach zbudujemy arkusz stylu, który zastosujemy na naszym dokumencie XML i przy okazji omówimy najistotniejsze konstrukcje XSLT oraz sposób ich działania w aplikacjach XML. PoniewaŜ niniejszy rozdział stanowi wprowadzenie do technologii XSLT, nie będziemy omawiać bardziej złoŜonych przekształceń z jednego formatu XML na inny. Przekształcenia takie, typowe w duŜych aplikacjach typu firma-firma, często zaleŜą od konkretnego zastosowania i reguł panujących w danym przedsiębiorstwie. Przekształcenia tego typu zostaną omówione w dalszych rozdziałach. Konstrukcje stosowane w przekształceniu będą identyczne — inny będzie jedynie wynik ich działania.

XSL to XML Dowolny arkusz stylów XSL musi być przede wszystkim zgodny ze specyfikacją XML. NaleŜy pamiętać, Ŝe XSL posiada swoje własne konstrukcje, ale tak naprawdę składają się one na jeden konkretny zasób słów zdefiniowanych w XML-u. Oznacza to, Ŝe arkusz XSL musi być poprawnie sformatowany, musi zawierać deklarację XML i muszą w nim być zadeklarowane wykorzystywane przestrzenie nazw. W przestrzeni nazw XSL (z przedrostkiem xsl) zdefiniowano elementy konieczne do przeprowadzenia transformacji (przekształcania). KaŜdy element arkusza „obsługujący” przekształcanie będzie więc rozpoczynał się przedrostkiem xsl. Na przykład element główny kaŜdego arkusza stylu XSL powinien nosić nazwę xsl:stylesheet. Ta przestrzeń nazw nie tylko umoŜliwia identyfikację przestrzeni XSL przez parser i procesor, ale równieŜ upraszcza przeglądanie arkusza XSL — widzimy, które elementy słuŜą do transformacji, a które nie. Oprócz deklaracji XML i wspomnianego elementu głównego, musimy wstawić odwołanie do przestrzeni nazw xsl. To nie powinno juŜ stanowić dla Czytelnika niespodzianki — jeśli wstawiamy przedrostki jakiejś przestrzeni nazw, to parser musi znać identyfikator URI dla tej przestrzeni. Najnowszą wersję specyfikacji przestrzeni nazw XSL znaleźć moŜna na stronach W3C, pod adresem http://www.w3.org/1999/XSL/Transform. W dokumentacji procesora XSL naleŜy sprawdzić typ wersji XSL. Oprócz przestrzeni nazw XSL, będziemy się równieŜ odwoływali do elementów w naszym spisie treści XML, naleŜących do przestrzeni JavaXML — jej deklarację musimy więc równieŜ zawrzeć w arkuszu stylu, taką samą jak w dokumencie XML. NaleŜy pamiętać, Ŝe deklaracje te są wykorzystywane jedynie jako sposób przypisania wybranej przestrzeni nazw, nie reprezentują natomiast schematu, definicji DTD czy jakichkolwiek innych faktycznych danych. Z tej początkowej deklaracji, elementu głównego i deklaracji przestrzeni nazw moŜemy juŜ utworzyć prosty szkielet arkusza XSL (przykład 6.2).

Przykład 6.2. Szkielet arkusza XSL
Składnia

138 version="1.0"

>

Czytelnik winien zauwaŜyć, Ŝe dodano atrybut version, który obecnie jest wymagany w arkuszach XSL. PowyŜszy arkusz stylów jest juŜ poprawny, ale jeszcze zupełnie bezuŜyteczny. Nie zdefiniowaliśmy Ŝadnych reguł dopasowujących elementy wejściowych danych XML. Zadanie to zostanie wykonane w następnym podrozdziale.

Szablony XSL Podstawowym zadaniem arkuszy XSL jest wyszukiwanie określonych elementów lub grup elementów w wejściowym dokumencie XML i stosowanie do nich reguł lub zestawów reguł. W języku Javy moŜemy to wyrazić następująco: wywołujemy akcesor np. pobierzWezly(kryteria) i wykonujemy obliczanie (transformację) na wartości, którą zwraca. Proces ten jest wykonywany za pośrednictwem szablonu XSL. Szablon to zestaw reguł, jakie naleŜy zastosować w danych XML odpowiadających określonej ścieŜce XPath. A więc teraz zaczynamy wykorzystywać wszystkie te komponenty, które zostały opisane wcześniej. Szablon definiujemy za pomocą elementu XSL template. Po dodaniu przedrostka przestrzeni nazw będzie to, oczywiście, element xsl:template. Element ten powinien zawierać atrybut match (dopasuj). Wartość atrybutu jest wyraŜeniem XPath, dopasowującym zero lub więcej elementów przetwarzanego dokumentu XML.

Jak widać, jedyną trudnością w procesie tworzenia szablonu jest sformułowanie wyraŜenia XPath dopasowującego element lub elementy XML, które chcemy „obrabiać”. Najprościej zastosować względne wyraŜenie XPath. Podobnie jak podajemy katalog lib/ względem katalogu głównego, moŜemy określać elementy po prostu podając ich nazwę — o ile tylko znajdujemy się „o stopień wyŜej” w hierarchii. Procesor XSLT „ustawia” nas na samym szczycie hierarchii elementów, a więc element główny dokumentu określamy podając jego nazwę:

W tym przypadku dopasowywany jest dokładnie jeden element, ale moŜliwe jest równieŜ dopasowanie wielu lub teŜ Ŝadnego elementu danych wejściowych. Takie sytuacje zostaną omówione w dalszej kolejności. Kiedy juŜ element jest dopasowany, wypadałoby coś z nim zrobić. W szablonie mamy dostęp do wszystkich elementów znajdujących się wewnątrz dopasowanego elementu. Wracając do przykładu z katalogami, moŜemy powiedzieć, Ŝe zmieniliśmy katalog bieŜący na lib/. Teraz moŜemy odwoływać się za pomocą zwykłych nazw do elementów niŜszego poziomu (JavaXML:Tytul

Składnia

139

i JavaXML:Spis); odwołania do wszelkich innych elementów wymagają bardziej złoŜonych wyraŜeń XPath. Zanim jednak się tym zajmiemy, spróbujmy uzyskać jakikolwiek wynik zastosowania arkusza. Np. zdanie „Witaj świecie!” uzyskamy po prostu wpisując je w szablonie: Witaj świecie!

Oczywiście, taki wynik nie jest zbyt imponujący — chcemy przecieŜ uzyskać dostęp do naszych danych, a nie wysyłać z arkusza XSL zwykły tekst. Najprościej uzyskamy poŜądany efekt poprzez wykorzystanie domyślnego „zachowania” arkusza XSL. Skoro dopasowaliśmy element główny, to do szablonu została załadowana cała hierarchia elementów dokumentu XML. Dalej moŜemy zaŜądać, aby na danych zastosowane zostały wszystkie inne szablony naszego arkusza stylu. To moŜe nie brzmi zbyt rozsądnie (przecieŜ nie zdefiniowaliśmy Ŝadnych innych szablonów); jednak w takim przypadku procesor XSLT przetwarza całą hierarchię elementów i po napotkaniu kaŜdego węzła („liścia”) dodaje dane do strumienia wynikowego transformacji. W wyniku tego wszystkie dane dokumentu XML są drukowane hierarchicznie, bez stosowania jakiegokolwiek formatowania. Odpowiednia konstrukcja XSL nosi nazwę xsl:apply-templates. Jeśli nie zostaną podane Ŝadne atrybuty, element ten spowoduje, Ŝe procesor dopasuje wszystkie elementy podrzędne względem bieŜącego za pomocą wszystkich szablonów w arkuszu:

Jednak taki zapis jest wciąŜ bezuŜyteczny — są to przecieŜ dane bez Ŝadnego formatowania. My chcemy zastosować znaczniki HTML i stworzyć stronę WWW. Podobnie jak w przypadku tekstu „Witaj świecie!”, standardowe znaczniki HTML wystarczy po prostu wstawić. Do tekstu wynikowego dodajemy więc znaczniki head i body, a następnie wstawiamy dane XML „wewnątrz” tych znaczników — właśnie za pomocą omówionego wyŜej elementu xsl:apply-templates. W ten sposób wykonaliśmy pierwszy krok w kierunku stworzenia faktycznego dokumentu HTML. Wprowadźmy więc do naszego arkusza stylu zmiany wskazane w przykładzie 6.3.

Przykład 6.3. Tworzenie wyjściowego pliku HTML Moja strona HTML!

Wynikowy plik HTML wyglądałby tak, jak w przykładzie 6.4.

Składnia

140

Przykład 6.4. Plik HTML powstały z przykładu 6.3 i pliku XML ze spisem treści Moja strona HTML! Java i XML

Wprowadzenie Co to jest? Jak z tego korzystać? Dlaczego z tego korzystać? Co dalej?

Pisanie w XML-u Dokument XML Nagłówek Zawartość Co dalej? Przykładowy współdzielony plik z opisem praw autorskich.

Nareszcie coś zaczyna się dziać. Na razie nie musieliśmy korzystać z wyszukanych funkcji XSL-a, ale juŜ widać efekt w postaci wyjściowych danych HTML, i to przy niewielkim wysiłku z naszej strony. MoŜna zauwaŜyć, Ŝe elementy, których specjalne znaczenie w arkuszu powinno być zniesione (np. nawiasy trójkątne), zostały bezproblemowo przeniesione do drzewa wyjściowego. Dzieje się tak, poniewaŜ w samym arkuszu XSL elementy nie wchodzące w skład specyfikacji XSL (np. head i body) są wstawiane do drzewa wyjściowego bezpośrednio. To umoŜliwia nam dodawanie znaczników bez konieczności znoszenia ich specjalnego znaczenia. Zanim przejdziemy dalej, powiemy jeszcze o tym, jak dopasować w szablonie specyficzny element. ZałóŜmy, Ŝe chcemy, aby tytuł dokumentu HTML był identyczny z zawartością elementu JavaXML:Tytul. Dobrze byłoby, gdyby nie trzeba było tworzyć oddzielnego szablonu dla tego elementu — nie ma tutaj Ŝadnego formatowania, więc byłoby to działanie na wyrost. My chcemy tylko uzyskać wartość elementu i „wpleść” ją w nasz HTML. Jak łatwo się domyślić, coś takiego moŜna zrobić za pomocą jednej prostej konstrukcji — mianowicie xsl:value-of. Konstrukcja ta, zamiast przetwarzać dalej wyraŜenie XPath, powoduje uzyskanie wartości dopasowanych przez XPath elementów. WyraŜenie XPath podawane jest jako wartość atrybutu select tego elementu. Wkrótce Czytelnik przekona się, Ŝe atrybut ten stosowany jest w wielu elementach XSL i Ŝe zawsze słuŜy do podawania ścieŜki XPath. W naszym arkuszu chcemy dopasować element JavaXML: Tytul, będący podrzędnym względem elementu bieŜącego — czyli znów nie musimy w wyraŜeniu XPath stosować jakichś specjalnych zabiegów. Po prostu wstawiamy tam nazwę elementu: <xsl:value-of select="JavaXML:Tytul" />

Składnia

141

Zanim przejdziemy do bardziej skomplikowanych struktur i wyraŜeń, warto wspomnieć o jeszcze jednej rzeczy. W ostatnim przykładzie dopasowaliśmy element JavaXML:Tytul. Jednak wybranie wartości tego elementu nie oznacza usunięcia go z hierarchii elementów stanowiącej dane wejściowe procesora XSLT. To nieco osobliwe — nie tylko wartość elementu pojawi się w tytule dokumentu; zostanie ona powielona w jego treści, w wyniku działania xsl:apply-templates. Jeśli to zachowanie wydaje się Czytelnikowi niewłaściwe, warto zauwaŜyć, Ŝe dane wejściowe procesora są nienaruszalne — nie moŜna ich zmienić, a jedynie określić, w jaki sposób mają być przetwarzane i jakie informacje naleŜy do nich dodać. Aby uniknąć przetwarzania jakiegoś elementu, musimy stworzyć wyraŜenie XPath nie obejmujące go albo spowodować, aby szablon dopasowywał element, ale nie generował Ŝadnych danych wyjściowych. Innymi słowy, musimy stworzyć szablon jawnie dopasowujący element JavaXML:Tytul i zrobić tak, aby po jego napotkaniu nie były tworzone Ŝadne dane wyjściowe:

Kiedy wszystkie szablony w ramach szablonu elementu głównego zostaną juŜ zastosowane, dopasowany — i zignorowany — zostanie takŜe powyŜszy element. Mam nadzieję, Ŝe Czytelnik spostrzegł, Ŝe to rozwiązanie jest nieeleganckie i zastanawia się, jak stworzyć wyraŜenie XPath ignorujące określony element. O tym wszystkim powiemy!

Struktury sterujące XSL, jak kaŜdy dobry język przetwarzania, udostępnia struktury sterujące. Nie przypominają one moŜe instrukcji sterujących Javy czy C, ale bardzo pomagają w sterowaniu przetwarzaniem drzewa wejściowego w procesorze XSLT. Przyjrzymy się najpopularniejszym z nich i zobaczymy, jak za ich pomocą określić dane, do których mamy mieć dostęp, oraz jak ustalić kolejność i sposób uzyskiwania tego dostępu.

Filtrowanie w XPath Omawianie struktur sterujących XSL zaczniemy od omówienia sterowania przetwarzaniem drzewa dokumentów. Czynność ta nie wymaga stosowania Ŝadnej specjalnej konstrukcji, ale łatwo ją wykonać za pomocą wyraŜeń XPath. Na przykład, jeśli zbudujemy wyraŜenie XPath mówiące, Ŝe element opisujący tytuł ma nie być dublowany, to będzie to równie sprawna struktura sterująca, jak „typowe” struktury sterujące, o których powiemy dalej. Problem elementu JavaXML:Tytul moŜna rozwiązać w prosty sposób. Pamiętamy, Ŝe zestaw węzłów zwróconych z wyraŜenia XPath jest przetwarzany hierarchicznie; innymi słowy, procesor XSLT „nie widzi” wszystkich elementów dokumentu XML naraz. Rozpoznaje wszystkie elementy na określonym poziomie zagnieŜdŜenia, a następnie przetwarza w głąb struktury drzewiaste poszczególnych elementów. W przypadku naszego dokumentu elementy postrzegane przez procesor XSLT znajdujące się w dokumencie głównym to te zagnieŜdŜone dokładnie o jeden poziom niŜej: JavaXML:Tytul, JavaXML: Spis oraz JavaXML:Copyright. Chcemy wyłączyć z przetwarzania JavaXML:Tytul. Najprościej wykorzystać tutaj funkcję XPath not(). SłuŜy ona do generowania zestawu węzłów nie pasujących do podanego wyraŜenia XPath. Najpierw dodajemy atrybut umoŜliwiający wprowadzenie wyraŜenia XPath do szablonów. Na razie wystarczy podać atrybut select z gwiazdką

Składnia

142

— czyli wybieramy wszystkie węzły potomne węzła bieŜącego. Nazwiemy to wybieraniem osi, na której będziemy przeprowadzać operację — tutaj wybieramy oś potomną. Oczywiście, w ten sposób nie rozwiązujemy do końca naszego problemu, ale początek mamy juŜ za sobą: <xsl:value-of select="JavaXML:Tytul" />

Teraz musimy dokładnie dopasować zestaw wynikowy. Na końcu kryterium wyboru dodamy nawiasy kwadratowe, w których wstawimy wyraŜenie opisujące zestaw węzłów i zwracające węzły do przetworzenia. W naszym przykładzie w miejscu tym pojawi się funkcja not(), a następnie węzły osi potomnej, których nie chcemy przetwarzać: <xsl:value-of select="JavaXML:Tytul" />

WyraŜenie, które teraz wstawimy, powinno zawierać nazwę (wraz z przedrostkiem przestrzeni) ignorowanego elementu, czyli tutaj JavaXML:Tytul. JednakŜe to wciąŜ nie wszystko. PoniewaŜ wybieramy węzły znajdujące się na określonej osi, musimy poinformować procesor XSLT, skąd pochodzi węzeł, do którego się odwołujemy. To dziwne — dlaczego programista ma sam podawać miejsce pochodzenia węzła? ZauwaŜmy jednak, Ŝe często wybierana oś nie jest osią potomną, a więc konieczne jest podanie „punktu odniesienia” — nawet w naszym prostym przykładzie. W tym celu uŜywamy słowa kluczowego self. Dzięki niemu procesor dowiaduje się, Ŝe węzły umieszczone po tym słowie są potomne względem węzła bieŜącego (JavaXML:Ksiazka). Do oddzielenia słowa kluczowego od elementów (w naszym przypadku jednego elementu) uŜywamy podwójnego dwukropka (jeden dwukropek pozostaje zarezerwowany jako separator przestrzeni nazw). <xsl:value-of select="JavaXML:Tytul" />

Jeśli to wydaje się Czytelnikowi zagmatwane, nie powinien się przejmować — to jest zagmatwane! Zestawy węzłów, osie i transformacje to wcale nie banalna sprawa. Te zagadnienia warte są osobnej publikacji. Tymczasem Czytelnik powinien starać się zrozumieć jak najwięcej z powyŜ-

Składnia

143

szego opisu i odnotować, co wciąŜ pozostaje niejasne. Po przeczytaniu tego i następnego rozdziału Czytelnik moŜe znaleźć dodatkowe wyjaśnienia na stronach W3C (http://www.w3.org). MoŜe równieŜ przejrzeć i dołączyć się do listy adresowej http://www.mulberrytech.com.

Pętle XSL udostępnia równieŜ konstrukcje do sterowania przetwarzaniem, analogiczne do standardowych programistycznych struktur sterujących. Pierwszą konstrukcją sterującą, jaką omówimy, jest xsl:for-each. Doskonale nadaje się ona do iteracji po danych w ramach jednego typu elementu. Na przykład — nasz spis treści zawiera szereg rozdziałów. Przetwarzając kolejne rozdziały, chcemy wydrukować ich tytuły. Aby to osiągnąć, tworzymy nowy szablon w pliku XSL, dopasowujący element JavaXML:Spis. Tak powstaje baza, w której zbudujemy pętlę (inaczej nie mielibyśmy gdzie jej wstawić). Moglibyśmy dodawać kolejne elementy do pierwszego szablonu JavaXML:Ksiazka, ale wtedy nasz arkusz szybko zapełniłby się złoŜonymi wyraŜeniami XPath, odwołującymi się do węzłów leŜących wiele warstw niŜej. Tworząc nowy szablon dla elementu JavaXML:Spis, umoŜliwiamy budowanie wyraŜeń XPath, w których „bazą” jest właśnie JavaXML:Spis, a nie JavaXML:Ksiazka. WyraŜenia XPath pozostają dzięki temu proste, a cały arkusz stylu — czytelny. Po przejściu do nowego szablonu moŜna wydrukować nagłówek informujący, Ŝe teraz wyświetlony zostanie spis treści — wystarczy bezpośrednio wstawić odpowiedni fragment kodu HTML. Następnie dodajemy linię poziomą (

), oddzielającą tytuł od zawartości:

Spis treści

Zanim jednak stworzymy pętlę, musimy rozwiązać jeden problem związany z powyŜszym fragmentem. Jeśli Czytelnik nie widzi błędu, winien przypomnieć sobie, Ŝe plik XSL musi zawsze być poprawnie sformatowanym dokumentem XML. Nawet kiedy dodajemy statyczne fragmenty kodu HTML, to muszą one być zgodne z powyŜszą zasadą (co w praktyce czyni te fragmenty danymi XHTML!). A więc przy przetwarzaniu powyŜszego fragmentu zgłoszony zostałby błąd, poniewaŜ znacznik

nie posiada odpowiadającego mu znacznika zamykającego. Z punktu widzenia XML-a nie jest to nic zaskakującego, ale jeśli Czytelnik jest przyzwyczajony do HTML-a, to tutaj natrafia na coś nowego. Proste rozwiązanie polega na stworzeniu pustego zapisu w znaczniku, ignorowanego przez przeglądarki przetwarzające wynikowy HTML:

Spis treści

Do takich zapisów trzeba się po prostu przyzwyczaić — z biegiem czasu stają się one równie naturalne jak pisanie w mniej formalnym standardzie HTML. Skoro ten drobny szczegół mamy juŜ za sobą, moŜemy budować pętlę. Konstrukcja xsl:for-each pobiera wyraŜenie XPath (wstawione w atrybut select) opisujące węzeł, po którym następować będzie iteracja. W naszym przypadku Ŝyczymy sobie, aby wyraŜenie zwracało wszystkie elementy JavaXML:Rozdzial. Tyle potrafimy juŜ zrobić:

Składnia

144

Spis treści

Teraz wystarczy dodać zawartość. KaŜdy przetwarzany węzeł na czas kolejnej iteracji pętli staje się węzłem bieŜącym hierarchii. Oznacza to, Ŝe aby odwołać się do elementów i atrybutów zagnieŜdŜonych w elemencie JavaXML:Rozdzial, naleŜy potraktować je jako podrzędne względem tego elementu, a nie elementu przetwarzanego w szablonie (JavaXML:Spis). My chcemy wydrukować nagłówek kaŜdego rozdziału. Aby wynik wyglądał ładniej, kaŜdy nagłówek będzie stanowił element nieponumerowanej listy HTML:

Spis treści

Wynikowy kod HTML zaczyna juŜ wyglądać obiecująco! Informacje o tym, jak taką zawartość stworzyć w mechanizmie serwletów, Czytelnik znajdzie w rozdziale 9. Wynikowy kod HTML wygląda następująco:

Przykład 6.5. Dane HTML powstałe w wyniku zastosowania zmodyfikowanego arkusza XSL Java i XML

Spis treści

Wprowadzenie
Pisanie w XML-u
Przetwarzanie XML-a
Struktury publikacji WWW

Przykładowy współdzielony plik z opisem praw autorskich.

Czytelnik prawdopodobnie chciałby juŜ się dowiedzieć, w jaki sposób faktycznie została przeprowadzona ta transformacja; o tym powiemy jednak dopiero w następnym rozdziale, po omówieniu konstrukcji XSL. Przed uŜywaniem procesora XSLT naleŜy poznać składnię XSL-a — to będzie procentowało na dalszym etapie nauki. Czytelnik moŜe teraz zadawać sobie pytanie: dlaczego właściwie w stylach XSL korzystamy z pętli? Czy nie prościej byłoby stworzyć nowy szablon dla elementu, który zamierzamy sformatować (np. JavaXML:Rozdzial) i obsłuŜyć formatowanie w ramach tego szablonu? Tak, byłoby to

Składnia

145

prostsze (i robiliśmy to juŜ wcześniej w przypadku wspomnianego elementu), ale problemem staje się wtedy czytelność kodu. W naszym arkuszu doskonale widać, do czego słuŜy pętla — na pewno jest to rozwiązanie czytelniejsze, niŜ gdybyśmy tworzyli szablony dla kaŜdego elementu JavaXML:Naglowek oddzielnie. W prosty sposób daje się takŜe wyświetlić tylko te dane, które chcemy uwidocznić — w naszym przypadku nagłówek. Nie musimy pokazywać innych zagnieŜdŜonych w szablonie elementów (np. JavaXML:PodzialSekcji), ale rozdziały są wykorzystywane do formatowania w ramach listy (

) tworzonej w szablonie JavaXML:Spis. Gdybyśmy rzeczywiście stworzyli szablon dla rozdziałów, musielibyśmy pamiętać, Ŝe zawartość szablonu musi być elementem listy (

). To mało eleganckie. Podobnie jak w przypadku innych aspektów języka XML, moŜliwość zrobienia czegoś nie oznacza jeszcze, Ŝe jest to do końca poprawne. Tak więc odpowiedź brzmi: owszem, byłoby prościej stworzyć szablon, ale nie jest to dobre rozwiązanie.

Wybór elementów do przetwarzania Oprócz stosowania pętli, często przydaje się takŜe moŜliwość przetwarzania tylko tych węzłów, które spełniają pewne kryteria. Programistom od razu przychodzi tutaj na myśl konstrukcja typu if-then, obecna w większości języków. W języku XSL zachowanie takie symulujemy konstrukcją xsl:if, zwracającą tylko te węzły, które odpowiadają wymogom zarówno wyraŜenia XPath, jak równieŜ kryteriom uŜytkownika. Przydaje się to wszędzie tam, gdzie konieczne jest przeanalizowanie wszystkich danych pewnego typu i gdzie chcemy wyświetlić lub sformatować w określony sposób jedynie podzbiór tych danych. W naszym przykładzie oddzielimy rozdziały dotyczące Javy od tych poświęconych głównie XML-owi. Informacje o tematyce rozdziału pobierzemy z atrybutu tematyka, juŜ obecnego w naszym dokumencie XML. Atrybutem uzupełniającym konstrukcję xsl:if jest test. Wynikiem obliczenia wyraŜenia test powinna być wartość „prawda” lub „fałsz”. W pierwszym przypadku element xsl:if będzie obliczany, w drugim ignorowany. Nic trudnego, prawda? Spójrzmy na nasz przykład. Za pomocą opisywanej konstrukcji wyświetlimy teraz tylko te rozdziały, które zawierają atrybut tematyka o wartości „Java”:

Spis treści

Mamy tutaj kilka nowych rzeczy. Nowy jest sposób odwołania do atrybutu XML. Zamiast nazwy (jak w przypadku elementów), jako przedrostek wstawiamy znak @. Dzięki temu procesor XSLT „wie”, Ŝe odwołujemy się do atrybutu, a nie do elementu. Spójrzmy takŜe na wartość dosłowną „Java”, wstawioną w apostrofy (czyli jako tekst statyczny). W przypadku dwóch rozdziałów, w których wyraŜenie nie jest prawdziwe (rozdziały 1. i 2.), nagłówek nie jest drukowany; pozostałe dwa, spełniające zadane kryteria, są przetwarzane i drukowane na ekranie. To dość typowy i przydatny sposób „podejmowania decyzji” w czasie transformacji; jednak w przypadku naszego dokumentu — wciąŜ nie najlepszy. Zamiast tylko pokazywać rozdziały o XML-u lub o Javie, moŜemy zaŜyczyć sobie wyświetlania nazwy rozdziału, a potem jego tematyki w na-

Składnia

146

wiasach. Owszem, moglibyśmy osiągnąć to za pomocą konstrukcji xsl:if, ale konieczne byłoby uŜycie dwóch pętli; pierwsza sprawdzałaby, czy tematyką poszczególnych rozdziałów jest XML, a druga sprawdzałaby, czy tematyką jest Java. Nie tylko odbiłoby się to na wydajności, ale równieŜ spowodowało wyświetlenie rozdziałów w złej kolejności — rozdziały o XML-u byłyby pierwsze, a te o Javie — ostatnie. Chcemy więc przeprowadzić podobny test, ale tak, aby zadana czynność wykonywana była w obu przypadkach. SłuŜy do tego element xsl:choose. Pozwala on na przetestowanie warunku i wykonanie pewnej czynności, gdy warunek został spełniony, a innej, jeśli nie został. Element ten otacza blok czynności do wykonania w obu przypadkach. Wewnątrz bloku wstawiany jest element xsl:when („jeśli”), w którym za pomocą atrybutu test określa się rodzaj testu do przeprowadzenia. Test ten jest identyczny z podanym w atrybucie elementu xsl:if. Wewnątrz tego elementu wstawia się instrukcje przetwarzania, jakie mają zostać wykonane, gdy test zwróci wartość „prawda”. RóŜnica polega na tym, Ŝe jest jeszcze element xsl:otherwise („w przeciwnym razie”), zawierający instrukcje przetwarzania wykonywane, gdy warunek nie zostanie spełniony. Ten element zachowuje się podobnie jak słowo kluczowe default w instrukcji switch Javy. Do naszego przykładu wprowadzimy teraz drobne poprawki — za kaŜdym razem drukowana będzie nazwa elementu i, na podstawie testu, wyświetlana odpowiednia tematyka:

Spis treści

(Tematyka: Java)

(Tematyka: XML)

NaleŜy sobie zdać sprawę z faktu, Ŝe powyŜszy przykład działa tylko dlatego, Ŝe dla atrybutu tematyka istnieją tylko dwie wartości. Trzeba takŜe pamiętać, Ŝe moglibyśmy po prostu wysłać wartość tego atrybutu na ekran. Oczywiście, ale w ten sposób nie dowiedzielibyśmy się nic nowego o XSL-u! A mówiąc powaŜnie, element xsl:choose bardzo przydaje się do sterowania przetwarzaniem zestawu węzłów zwróconego z wyraŜenia XPath, szczególnie gdy pewien podzbiór węzłów musi zostać wyizolowany i potraktowany w inny sposób. Nasz wynikowy plik HTML coraz bardziej przypomina rzeczywisty spis treści (przykład 6.6).

Przykład 6.6. Wynikowy plik HTML po zastosowaniu instrukcji sterujących Java i XML

Spis treści

Składnia

147

Wprowadzenie (Tematyka: XML)
Pisanie w XML-u (Tematyka: XML)
Przetwarzanie XML-a (Tematyka: Java)
Struktury publikacji WWW (Tematyka: Java)

Przykładowy współdzielony plik z opisem praw autorskich.

Struktury sterujące umoŜliwiają wykonanie wielu róŜnych zadań; przydają się równieŜ do zrozumienia bardziej złoŜonych wyraŜeń XPath oraz testów. W następnych rozdziałach Czytelnik dowie się, jak za pomocą języka XSL przetwarzać i tworzyć elementy i atrybuty uzupełniające te juŜ obecne na wejściu procesora.

Elementy i atrybuty Teraz czytelnik powinien juŜ rozumieć, jak duŜą kontrolę nad dokumentem XML daje nam arkusz XSL. Nie powinno być zaskoczeniem, Ŝe moŜna równieŜ definiować własne atrybuty i elementy. Mogą one słuŜyć do obliczeń lub po prostu zostać dodane do danych wyjściowych. Najczęściej wykorzystuje się takie elementy w zaawansowanych szablonach i przy przetwarzaniu parametrów, tego tematu nie będziemy jednak obszernie omawiali. Aby dowiedzieć się więcej o tych bardziej zaawansowanych zastosowaniach arkuszy XSL, warto zapisać się na listę adresową XSL, na której tematyka ta jest często poruszana. Informacje o liście uzyskamy pod adresem http://www.mulberrytech.com/xsl/xsl-list. Jednym z typowych powodów, dla których tworzy się elementy i atrybuty w arkuszu stylów, jest konieczność zbudowania dynamicznych odwołań HTML wewnątrz danych XML. Aby to zademonstrować, do naszego arkusza dodamy sekcję zawierającą informacje o materiałach dodatkowych (być moŜe nie nadaje się to do spisu treści, ale słuŜy jako doskonały przykład!), zagnieŜdŜoną w elemencie JavaXML:Ksiazka (naleŜy pamiętać o wyłączeniu sprawdzania poprawności — w przeciwnym razie zostaną złamane zasady zdefiniowane w DTD!): Java i XML Grupa W3C http://www.w3.org/Style/XSL Lista XSL http://www.mulberrytech.com/xsl/xsl-list

Aby obsłuŜyć taki fragment, trzeba dodać nowy szablon do arkusza stylu. MoŜna równieŜ dodać formatowanie HTML oraz pętlę przebiegającą po odsyłaczach w dokumencie — wszystko to juŜ potrafimy:

Składnia

148

PoŜyteczne informacje dodatkowe

Pozostaje teraz utworzyć odsyłacz HTML. Powinien on zawierać wartość elementu JavaXML: Nazwa jako etykietę oraz JavaXML:Url jako adres. Ale jak dodać to do zdefiniowanego znacznika? Musimy uzyskać coś takiego: [wartość elementu Nazwa]

Trik polega na tym, Ŝe atrybut na wyjściu musi składać się z elementu znajdującego się na wejściu procesora. Dobrym sposobem osiągnięcia takiego rezultatu jest zastosowanie konstrukcji xsl: element i xsl:attribute — pozwalają one ustawić wartości odpowiednich elementów i atrybutów. Pierwsza z nich zawiera atrybut name, w którym podawana jest nazwa budowanego elementu. Innymi słowy, zapis Cześć! spowoduje wyświetlenie Cześć!. Do definicji moŜemy takŜe dodać znaczniki , działające w analogiczny sposób. Tak więc następujący arkusz XSL: Java jest świetna!

zostałby przetworzony do postaci wynikowej: jest świetna!

W elementach xsl:element i xsl:attribute mogą pojawić się złoŜone wyraŜenia, co umoŜliwia tworzenie naprawdę dowolnych „wplecionych” wartości. I teraz wiemy juŜ, jak rozwiązać nasz problem z adresami URL:

PoŜyteczne informacje dodatkowe

Składnia

149

Potrafimy juŜ wstawiać wartości elementów i tworzyć atrybuty, które potem interpretowane są jako odsyłacze w HTML-u. Wynik transformacji, przedstawiony w przykładzie 6.7, jest zgodny z naszymi oczekiwaniami:

Przykład 6.7. Wynikowy plik HTML zawierający „poŜyteczne informacje” Java i XML

Spis treści

Wprowadzenie (Tematyka: XML)
Pisanie w XML-u (Tematyka: XML)
Przetwarzanie XML-a (Tematyka: Java)
Struktury publikacji WWW (Tematyka: Java)

PoŜyteczne informacje dodatkowe

Przykładowy współdzielony plik z opisem praw autorskich.

Dane... po prostu dane MoŜna dowieść, Ŝe w idealnej sytuacji w dowolnym dokumencie XML wystarczy przeprowadzić tylko jedną transformację. MoŜna takŜe twierdzić, Ŝe dokument XML powinien zawierać czyste dane, bez jakiegokolwiek znacznika formatującego lub elementu, który powinien pozostać nieprzetworzony. Niestety, sytuacje idealne zdarzają się rzadko. Czasem elementy dokumentu XML są wykorzystywane jako dane. Jeśli to wydaje się dziwne, to nic nie szkodzi — to jest dziwne dla wielu osób. Ale prawdopodobnie niejeden Czytelnik dobrze juŜ wie, o co tutaj chodzi. Wielokrotnie zdarza się, Ŝe chcemy stworzyć kod HTML wewnątrz dokumentu XML i powiedzieć procesorowi XSLT: „Tego HTML-a proszę mi nie ruszać!”. Zdarza się tak w sytuacji, gdy trzeba łączyć w łańcuchy róŜne arkusze stylów lub generować elementy, które mają pozostać nieprzetworzone i wykorzystane w innej aplikacji „znającej XML”. Sytuacja taka ma równieŜ miejsce w przypadku danych, które mają zostać wyświetlone na ekranie bez przetwarzania. Jednym słowem — jeśli jeszcze na taką sytuację Czytelnik się nie natknął, to prędzej czy później mu się to przydarzy! Ostatnią konstrukcją, jaką omówimy w związku z przetwarzaniem XSLT, jest konstrukcja zabraniająca przetwarzania! Najlepiej posłuŜyć się przykładem. Zamiast korzystać z encji odwołującej się do praw autorskich, wstawmy w tym miejscu dane HTML. Dane te mogą być pobrane z innego pliku lub teŜ mogą zostać wygenerowane poza naszą kontrolą. Innymi słowy, otrzymujemy dane HTML, na któ-

Składnia

150

re nie mamy wpływu — a to zdarza się często. Dodajmy więc do naszego dokumentu XML kod HTML:

I to mamy teraz obsłuŜyć w transformacji XSL. Po bezpośrednim przetworzeniu otrzymalibyśmy tekst „Copyright O'Reilly and Associates, 2000” bez jakiegokolwiek formatowania. Nie powinno to Czytelnika dziwić, jeśli przypomni sobie opis sposobu dopasowania w szablonie. Trzeba pamiętać, Ŝe jeśli dla elementu nie podano szablonu, dane wynikowe nie będą zawierały nic, a drzewo wejściowe jest przetwarzane dopóty, dopóki nie zostaną znalezione jakieś dane do wydrukowania. To, co zostało dostarczone do procesora jako znaczniki HTML, jest traktowane jako XML i wszystkie znaczniki typu center, table itd. są ignorowane — pozostają tylko dane tekstowe, niesformatowane i niezmienione. Na szczęście istnieje proste rozwiązanie tego problemu. Aby pewne elementy oznaczyć jako dane, wystarczy uŜyć konstrukcji xsl:copy-of. Działa ona identycznie jak xsl:value-of, pobierając wyraŜenie XPath poprzez wartość atrybutu select. Jednak zamiast dawać w wyniku wartości zwróconego zestawu węzłów, przekazuje taki zestaw bezpośrednio z wejścia na wyjście. Cała zawartość zestawu węzłów nie jest przetwarzana.

Zawartość elementu JavaXML:Copyright (wraz z całym kodem HTML) jest przekazywana bez zmian. Nie znaczy to jednak, Ŝe moŜemy teraz dowolnie łamać zasady XML-a! Zawartość tego węzła jest przetwarzana dokładnie tak samo, jak dowolne inne dane XML, zanim w ogóle nastąpi transformacja. Innymi słowy, korzystanie ze znaku & lub elementów bez znaczników zamykających (np.
) jest niedozwolone. Ale moŜliwość bezpośredniego przesłania danych na wyjście w celu ewentualnego dalszego przetwarzania jest bardzo przydatna wszędzie tam, gdzie dane te nie są XML-em lub gdzie konieczne jest zastosowanie wielu arkuszy stylów i nie wszystkie elementy mają być przetwarzane przez jeden styl. Teraz spójrzmy na gotowy arkusz XSL z dodanym nowym szablonem (przykład 6.8):

Przykład 6.8. Gotowy arkusz XSL
Składnia

151

> <xsl:value-of select="JavaXML:Tytul" />

Spis treści

(Tematyka: Java)

(Tematyka: XML)

PoŜyteczne informacje dodatkowe

Tabele HTML zostały przekazane na wyjście bez zmian; wynikowy dokument HTML moŜna obejrzeć w przykładzie 6.9.

Przykład 6.9. Wynikowy dokument HTML ze skopiowaną zawartością XHTML

Składnia

152

Java i XML

Spis treści

Wprowadzenie (Tematyka: XML)
Pisanie w XML-u (Tematyka: XML)
Przetwarzanie XML-a (Tematyka: Java)
Struktury publikacji WWW (Tematyka: Java)

PoŜyteczne informacje dodatkowe

Rysunek 6.2, będący zapowiedzią rozdziału o procesorze XSLT, przedstawia otrzymany plik HTML w takiej postaci, w jakiej będzie on widoczny w przeglądarce.

Składnia

153

Rysunek 6.2. Wynikowa strona HTML w przeglądarce WWW

Kiedy tekst nie wystarcza ... Przekształcanie danych XML na inny format jest przydatne i często stosowane. Jednak czasami to nie wystarcza. Powiedzieliśmy, Ŝe dane XML moŜna przekształcić na niemal dowolne formaty, a nie tylko na formaty tekstowe w rodzaju HTML i WML. Na przykład XML moŜna przetworzyć i przekształcić na format PDF (Portable Document Format), który to format odczytywany jest później np. za pomocą programu Adobe Acrobat. Do takich binarnych przekształceń wykorzystuje się obiekty formatujące. Wspomnieliśmy o nich krótko juŜ wcześniej, przy okazji omawiania specyfikacji XSL. PoniewaŜ w wyniku działania XSL musi powstać poprawnie sformatowany XML, nie jest moŜliwe, aby procesor XSLT bezpośrednio zwrócił dane binarne. Obiekty formatujące umoŜliwiają zdefiniowanie zestawu elementów i atrybutów XML, które wykorzystuje się do reprezentacji obszarów (ang. areas) formatu wyjściowego. Obszar jest następnie wykorzystywany przez procesor obiektów formatujących i przekształcany na format binarny. Jako przykład rozwaŜmy następujący fragment arkusza XSL, przekształcający XML z wykorzystaniem obiektów formatujących:

Wynik transformacji elementu JavaXML:Title, którego wartość to „Java i XML”, miałby następującą postać: Java i XML

Co dalej?

154

PowyŜszy zapis jest sam w sobie nieco zagadkowy i na pewno nie jest fragmentem dokumentu PDF. JednakŜe procesor obiektów formatujących, taki jak FOP autorstwa grupy Apache XML (http://xml.apache.org), moŜe przekształcić taki fragment na binarne dane PDF. Uzyskalibyśmy wtedy tytuł „Java i XML” umieszczony na środku strony, wpisany czcionką o podanej wielkości. Ten sam fragment XML moŜna byłoby przekształcić na dokument programu Word lub na arkusz kalkulacyjny Star Office — o ile tylko istniałyby odpowiednie procesory. W arkuszu XSL generowane są „obszary” XML z wykorzystaniem obiektów formatujących; te reprezentacje danych moŜna potem przekształcać w celu uzyskania odpowiedniej postaci binarnej. Jednocześnie zachowany jest format XML, zarówno w postaci oryginalnej, jak i w przekształconych dokumentach — dane te są więc cały czas przenośne. Tak więc ustalenie tego, czy wystarcza uzyskanie danych tekstowych, czy nie, nic nie zmienia w samej technice przetwarzania XSL — zmieniają się tylko przekształcane obiekty. WciąŜ mamy jeden dokument źródłowy, z którego moŜna uzyskać wiele dokumentów wynikowych.

Co dalej? Mamy juŜ pełny, działający arkusz XSL. Czytelnik powinien juŜ potrafić przetwarzać i przekształcać dane XML oraz tworzyć nowe dane w arkuszu XSL. Aby jednak rzeczywiście zrealizować współpracę standardów XML i XSL, potrzebny jest nam procesor XSLT. Procesor taki, w naszym przypadku napisany w Javie, zajmie się faktyczną transformacją i stworzy dane wynikowe — dokument XML z narzuconymi stylami XSL. W następnym rozdziale zostanie omówiona obsługa takiego właśnie procesora XSLT — zarówno standardowa, z wiersza poleceń, jak i z poziomu programu w Javie. Przedstawiony zostanie równieŜ obiektowy model dokumentu (DOM); słuŜy on do generowania danych XML w formacie odpowiednim dla danych wejściowych procesora XSLT. W zakończeniu rozdziału 7. zostaną podsumowane poznane dotychczas wiadomości dotyczące przetwarzania XML-a — Czytelnik zobaczy, w jaki sposób łączą się one w jedną całość i są wykorzystywane w większych aplikacjach XML.

Uzyskiwanie danych wyjściowych

155

7 Czerpanie z XML-a W poprzednim rozdziale Czytelnik nauczył się tworzyć arkusze stylów XSL dla posiadanych dokumentów XML. W niniejszym rozdziale temat ten będzie kontynuowany. Czytelnik dowie się, jak dokument i arkusz stylów są przetwarzane i przekształcane na dane wyjściowe. Podobnie jak w poprzednich rozdziałach, tym razem przyjrzymy się poznanym strukturom języka XML z punktu widzenia Javy. Omówimy procesory XSLT, interfejsy API Javy do obsługi wejścia XML w formacie drzewiastym oraz powiemy, czym róŜnią się te interfejsy od opisywanego juŜ SAX-a. Najpierw przeanalizujemy sposób, w jaki wykonywane są w komputerze transformacje. Stworzymy w ten sposób „wirtualny plac zabaw”, gdzie będziemy mogli eksperymentować z własnymi konstrukcjami XSL i XSLT. Spróbujemy równieŜ dodać nieco bardziej złoŜone formatowanie do arkusza stylów, który stworzyliśmy w ostatnim rozdziale. Ponadto zaczniemy dokładniej analizować sposób działania procesora XSLT; na końcu szczegółowo omówimy, jakiego rodzaju i formatu danych wejściowych oczekuje taki procesor. Tym samym rozpoczniemy dyskusję o obiektowym modelu dokumentu (DOM) — alternatywnym względem SAX-a sposobie uzyskiwania dostępu do danych XML. Na koniec odejdziemy od tematu parserów, procesorów i interfejsów API, spróbujemy natomiast poskładać wszystkie elementy „układanki XML” w jedną całość. Będzie to wstęp do pozostałej części ksiąŜki — spróbujemy bardziej przekrojowo opisać róŜne typy aplikacji XML i sposoby wykorzystania wzorców projektowych i struktur XML do własnych potrzeb. Przed lekturą dalszej części ksiąŜki Czytelnik powinien zrozumieć nie tylko tematykę niniejszego rozdziału, ale takŜe to, jakich tematów ten rozdział nie porusza. Czytelnik nie znajdzie tutaj opisu tworzenia procesora XSLT (podobnie jak wcześniej nie znalazł receptury tworzenia parsera XML). Opisywane tutaj zagadnienia są bardzo waŜne — w zasadzie kluczowe — do korzystania z procesora XSLT; to takŜe świetny wstęp do ewentualnego zaangaŜowania się w rozbudowę istniejących procesorów XSLT, takich jak Xalan grupy Apache. JednakŜe parsery i procesory to programy niezwykle złoŜone i próba wyjaśnienia ich wewnętrznych mechanizmów zajęłaby resztę ksiąŜki, a moŜe i całą następną! My natomiast zajmiemy punkt widzenia programisty aplikacji lub architekta programów w Javie; postaramy się wykorzystać istniejące juŜ narzędzia i w razie konieczności rozbudować je do własnych potrzeb. Innymi słowy, zanim zabierzemy się za programowanie procesorów, powinniśmy nauczyć się ich uŜywać!

Uzyskiwanie danych wyjściowych

156

Uzyskiwanie danych wyjściowych Jeśli Czytelnik śledził przykłady z ostatniego rozdziału, powinien być juŜ przygotowany na przekazanie arkusza i dokumentu XML do procesora. W przypadku większości procesorów jest to dość prosta czynność. Zgodnie z przyjętą taktyką korzystania z najlepszych w branŜy produktów typu open source, uŜyjemy procesora Apache Xalan (moŜna go pobrać i uzyskać o nim informacje pod adresem http://xml.apache.org). Nad Xalanem pracują najtęŜsze umysły — programiści firm Lotus, IBM, Sun, Oracle i innych. Ponadto procesor ten świetnie współpracuje z opisywanym we wcześniejszych rozdziałach parserem Apache Xerces. Jeśli jednak Czytelnik posiada juŜ inny procesor, to takŜe nie powinien mieć problemów ze znalezieniem informacji, dotyczących uruchamiania przykładów opisywanych w tym rozdziale, a wynik działania programu powinien być identyczny lub bardzo podobny do uzyskiwanego w ksiąŜce. Najpierw spróbujemy uruchomić procesor XSLT z wiersza poleceń. Często robi się to na potrzeby testowania, usuwania błędów i tworzenia zawartości dokumentów w trybie offline. Warto pamiętać, Ŝe w wielu „powaŜnych” witrynach WWW zawartość tworzona jest właśnie offline, często w godzinach nocnych lub raz w tygodniu, dzięki czemu w czasie Ŝądania pobrania strony nie ma spadku wydajności związanego z dynamicznym przetwarzaniem XML-a na HTML lub inny język znaczników. Uruchamiany w ten sposób procesor pomoŜe nam równieŜ w przeanalizowaniu róŜnych warstw transformacji XML. Dokumentacja uŜywanego procesora powinna zawierać instrukcje dotyczące sposobu uruchamiania go z wiersza poleceń. W przypadku procesora Apache Xalan polecenie ma następującą postać D:\prod\JavaXML> java org.apache.xalan.xslt.Process -IN [Dokument XML] -XSL [Arkusz stylu XSL] -OUT [Plik wyjściowy]

Xalan, jak kaŜdy inny procesor, umoŜliwia podanie takŜe wielu innych opcji w wierszu poleceń, ale my będziemy korzystali głównie z tych trzech powyŜszych. Xalan domyślnie korzysta z parsera Xerces, a więc w ścieŜce dostępu do klas będą musiały się znaleźć zarówno klasy parsera, jak i procesora. W wierszu poleceń moŜna zaŜądać zmiany parsera XML, ale w Xalanie obsługa parsera Xerces jest najbardziej zaawansowana. Jeśli przekształcanie odbywa się w powyŜszy sposób, nie trzeba odwoływać się do arkusza stylu z poziomu dokumentu; procesor XSLT sam zastosuje arkusz stylu podany w wierszu poleceń. Wewnętrzne deklaracje arkuszy stylów zostaną uŜyte dopiero w rozdziale 9., Struktury publikacji WWW. Tak więc do zbudowania polecenia uruchamiającego nasz procesor potrzebujemy nazwy dokumentu XML i arkusza XSL (w tym przypadku znajdującego się w podkatalogu). PoniewaŜ w wyniku mamy uzyskać plik HTML, jako plik wyjściowy podajemy contents.html: D:\prod\JavaXML> java org.apache.xalan.xslt.Process -IN contents.xml -XSL XSL/JavaXML.html.xsl -OUT contents.html

Uruchomienie takiego polecenia w odpowiednim katalogu spowoduje, Ŝe Xalan rozpocznie proces transformacji. Uzyskamy wynik podobny do tego przedstawionego w przykładzie 7.1.

Przykład 7.1. Przekształcanie pliku XML za pomocą procesora Apache Xalan D:\prod\JavaXML> java org.apache.xalan.xslt.Process -IN contents.xml -XSL XSL/JavaXML.html.xsl -OUT contents.html

Pobieranie danych wejściowych

157

========== Parsing file:D:/prod/JavaXML/XSL/JavaXML.html.xsl ========= Parse of file:D:/prod/JavaXML/XSL/JavaXML.html.xsl took 1161 milliseconds ========= Parsing contents.xml ========== Parse of contents.xml took 311 milliseconds ============================= Transforming... transform took 300 milliseconds XSLProcessor: done

Po ukończeniu przetwarzania powinno być moŜliwe otworzenie uzyskanego pliku contents.html w edytorze lub przeglądarce WWW. Jeśli Czytelnik postępował zgodnie z instrukcjami w ostatnim rozdziale, to w przeglądarce powinna zostać wyświetlona strona widoczna na rysunku 7.1.

Rysunek 7.1. Strona HTML uzyskana po transformacji danych XML Teraz Czytelnik wie juŜ, jak wprowadzać zmiany i testować dane wynikowe plików XML i arkuszy XSL. Procesor Xalan uruchomiony z wiersza poleceń posiada takŜe poŜyteczną funkcję odnajdywania błędów w plikach XML lub XSL i podawania numerów wierszy, w których one wystąpiły — to jeszcze bardziej upraszcza usuwanie błędów i testowanie plików.

Pobieranie danych wejściowych Poza powodami, o których juŜ wspomnieliśmy, jest jeszcze jedna istotna przyczyna, dla której nie będziemy zajmować się omawianiem wewnętrznych mechanizmów procesora — dane wejściowe i wyjściowe procesora są o wiele bardziej zajmujące! Widzieliśmy juŜ, jak moŜna przetwarzać dokument przyrostowo za pomocą interfejsów i klas SAX. W procesie tym w prosty sposób decydujemy, co zrobić z napotkanymi elementami, jak obsłuŜyć określone atrybuty i jakie czynności powinny zostać podjęte w przypadku napotkania błędów. JednakŜe korzystanie z takiego modelu w pewnych sytuacjach rodzi równieŜ problemy. Jedną z takich sytuacji jest przekazywanie danych wejściowych dla procesora XSLT.

Pobieranie danych wejściowych

158

SAX działa sekwencyjnie Model sekwencyjny oferowany przez interfejs SAX nie umoŜliwia uzyskania swobodnego dostępu do dokumentu XML. Innymi słowy, korzystając z SAX-a pobieramy informacje o dokumencie XML wtedy, kiedy robi to parser — i podobnie jak parser informacje te tracimy. Kiedy pojawia się element 2., to nie moŜna uzyskać dostępu do informacji w elemencie 4., poniewaŜ nie został on jeszcze przetworzony. Natomiast kiedy pojawi się element 4., to nie moŜemy powrócić do elementu 2. Oczywiście, mamy prawo zachować informacje napotkane w procesie przetwarzania, ale zakodowanie tego typu przypadków specjalnych moŜe być bardzo trudne. Przeciwną skrajnością jest stworzenie reprezentacji dokumentu XML w pamięci. Wkrótce okaŜe się, Ŝe parser DOM postępuje właśnie w ten sposób; tak więc wykonywanie tego w interfejsie SAX byłoby bezcelowe, a prawdopodobnie takŜe wolniejsze i bardziej kłopotliwe.

SAX a elementy siostrzane Innym zadaniem trudnym do wykonania w interfejsie SAX jest przechodzenie z elementu na element „w poziomie”. Dostęp do elementów poprzez SAX jest w duŜym stopniu hierarchiczny i sekwencyjny. Uzyskujemy dostęp do krańcowego elementu węzła, potem przechodzimy z powrotem „w górę” drzewa i znów schodzimy do innego elementu na dole hierarchii. Nie ma przejrzystego odniesienia do „poziomu” hierarchii, na którym aktualnie się znajdujemy. Identyfikację poziomów moŜna co prawda wdroŜyć poprzez wprowadzenie wyszukanych liczników, ale ogólnie SAX nie jest do tego typu operacji przystosowany. Nie ma zaimplementowanego pojęcia elementu siostrzanego, następnego elementu na tym samym poziomie; nie ma teŜ moŜliwości sprawdzenia, które elementy są zagnieŜdŜone w których. Procesor XSLT musi znać elementy siostrzane danego elementu; co waŜniejsze, musi znać jego elementy potomne. Spójrzmy na taki fragment szablonu XSL:

Szablony nakładane są poprzez konstrukcję xsl:apply-templates, ale to nakładanie odbywa się na konkretnym zestawie węzłów, pasującym do podanego wyraŜenia XPath. W powyŜszym przykładzie szablon powinien być nałoŜony jedynie na elementPotomny1 lub elementPotomny2 (są one rozdzielone operatorem LUB wyraŜeń XPath, czyli kreską poziomą). Ponadto, poniewaŜ wykorzystujemy ścieŜkę względną, wspomniane elementy muszą być bezpośrednio potomne względem elementu elementMacierzysty. Określenie i zlokalizowanie tych węzłów w reprezentacji dokumentu XML oferowanej przez SAX byłoby niezwykle trudne. Dzięki hierarchicznej reprezentacji dokumentu w pamięci czynność ta jest bardzo łatwa — i jest to kolejny powód, dla którego tak często korzysta się z modelu DOM jako wejścia dla procesorów XSLT.

Przyczyny korzystania z SAX-a Wszystkie te „wady” SAX-a skłaniają zapewne Czytelnika do zastanawiania się, dlaczego w ogóle korzysta się z interfejsu SAX. Warto więc tutaj przypomnieć, Ŝe powyŜsze problemy odnoszą się do konkretnego zastosowania danych XML, w tym przypadku przetwarzania poprzez XSL. OtóŜ „wady” te są jednocześnie... zaletami SAX-a! Czy to nie wydaje się zagmatwane? Wkrótce okaŜe się, Ŝe nie tak bardzo.

Obiektowy model dokumentu (DOM)

159

Wyobraźmy sobie, Ŝe przetwarzamy spis treści czasopisma National Geographic w postaci danych XML. Dokument taki często osiąga 500 wierszy długości, czasem więcej. Teraz wyobraźmy sobie indeks ksiąŜki O'Reilly w postaci pliku XML. Setki słów z numerami stron, odsyłaczami itd. Wszystko to przykłady w miarę małych, spójnych aplikacji XML. W miarę wzrostu dokumentu XML rośnie obszar zajmowanej przez niego pamięci, jeśli korzystamy z drzewa DOM. Weźmy teraz pod uwagę sytuację, w której dokument XML staje się tak wielki, Ŝe jego reprezentacja w modelu DOM zaczyna wpływać na wydajność aplikacji. I wyobraźmy jeszcze sobie, Ŝe te same wyniki moŜna uzyskać poprzez przetworzenie dokumentu wejściowego sekwencyjnie, za pomocą SAX-a — przy wykorzystaniu jednej dziesiątej lub jednej setnej zasobów systemowych. PowyŜszy przykład obrazuje, Ŝe podobnie jak w Javie istnieje wiele sposobów wykonania tego samego zadania, tak i w róŜny sposób moŜna uzyskać dane dokumentu XML. W wielu scenariuszach SAX stanowi lepszy wybór — oferuje szybkie przetwarzanie i przekształcanie. W innych przypadkach zwycięŜa DOM — zapewnia prosty, przejrzysty interfejs danych określonego formatu. To my, programiści, musimy zastanowić się nad celem budowania aplikacji i wybrać odpowiednią metodę (albo opracować sposób współdziałania obydwu metod). Jak zwykle umiejętność podjęcia właściwej decyzji wynika ze znajomości dostępnych rozwiązań. Mając to na uwadze, przyjrzyjmy się takiemu właśnie nowemu rozwiązaniu.

Obiektowy model dokumentu (DOM) W przeciwieństwie do interfejsu SAX, obiektowy model dokumentu wywodzi się z kręgów konsorcjum W3C. SAX to oprogramowanie będące własnością publiczną, stanowiące owoc długich dyskusji na liście adresowej XML-dev. Natomiast DOM jest samym w sobie standardem, tak jak XML. DOM nie został równieŜ opracowany wyłącznie dla Javy; jego zadaniem jest reprezentacja zawartości i modeli dokumentów we wszystkich językach i narzędziach programistycznych. Istnieją interfejsy DOM dla JavaScriptu, Javy, CORBA i innych języków. Jest to więc specyfikacja neutralna językowo i platformowo. Kolejna róŜnica polega na tym, Ŝe DOM jest dostarczany jako „poziomy”, a nie wersje. DOM Level One (DOM poziomu pierwszego) ma status przyjętego zalecenia W3C, a pełną specyfikację moŜemy przejrzeć pod adresem http://www.w3.org/TR/REC-DOM-Level-1/. Level One opisuje funkcje i sposób nawigacji po zawartości dokumentu. Dokument w modelu DOM nie musi być dokumentem XML — moŜe to być HTML bądź dowolny inny rodzaj zawartości! Level Two (DOM poziomu drugiego), ukończony w roku 2000, uzupełnia Level One o moduły i opcje dla poszczególnych modeli zawartości, takich jak XML, XSL czy CSS (kaskadowe arkusze stylów). W ten sposób „uzupełniane są luki” pozostawiane przez bardziej ogólne narzędzia Level One. BieŜący dokument kandydujący do oficjalnego zalecenia W3C znajduje się pod adresem http://www.w3.org/TR/DOM-Level-2/. Trwają juŜ prace nad modelem Level Three (DOM poziomu trzeciego), udostępniającym kolejne narzędzia dla specyficznych typów dokumentów — np. procedury obsługi sprawdzania poprawności dla XML-a.

DOM a Java Aby móc korzystać z modelu DOM w określonym języku programowania, naleŜy zastosować interfejsy i klasy oraz zaimplementować sam model DOM. PoniewaŜ wykorzystywane metody nie są określone w samej specyfikacji DOM (specyfikacja ta charakteryzuje jedynie model dokumentu), konieczne było opracowanie interfejsów języka reprezentujących konceptualną strukturę modelu DOM — zarówno dla Javy, jak i innych języków. Interfejsy te umoŜliwiają manipulację dokumentami w sposób określony właśnie w specyfikacji DOM.

Obiektowy model dokumentu (DOM)

160

Oczywiście, w tej ksiąŜce najbardziej interesuje nas interfejs dla Javy. Dowiązania dla tego języka (ang. bindings), określane nazwą DOM Level Two Java bindings, moŜna pobrać ze strony http://www.w3.org/TR/DOM-Level-2/java-binding.html. Klasy, które powinniśmy dodać do ścieŜki dostępu do klas, znajdują się w pakiecie org.w3c.dom (i podpakietach). JednakŜe zanim je pobierzemy z sieci, warto zerknąć do posiadanego parsera XML i procesora XSLT. Podobnie jak pakiet SAX, DOM jest często dostarczany wraz z tymi narzędziami. W ten sposób mamy równieŜ zagwarantowane, Ŝe parser, procesor i posiadana wersja DOM poprawnie współpracują ze sobą. Większość procesorów nie generuje samodzielnie danych wejściowych DOM. Korzystają w tym celu z parsera XML, któremu powierza się zadanie wygenerowania drzewa DOM. Dlatego często to parser XML, a nie procesor XSLT będzie posiadał wymagane klasy DOM. Ponadto w ten sposób zapewnia się niezaleŜność obu narzędzi — zawsze moŜna zamienić parser albo procesor na produkt innego producenta. PoniewaŜ domyślnie Apache Xalan wykorzystuje parser Xerces do przetwarzania i generowania modelu DOM, zajmiemy się tutaj obsługą DOM z poziomu tego narzędzia.

Uzyskanie parsera DOM Aby zorientować się w sposobie działania modelu DOM, powiemy teraz, w jaki sposób procesor Apache Xalan i inne programy wymagające danych wejściowych w formacie DOM otrzymują dokument XML w strukturze drzewiastej DOM. W ten sposób poznamy pierwsze dowiązania języka Java do modelu DOM i wyjaśnimy koncepcje leŜące u podstaw obsługi dokumentów XML poprzez model DOM. Model DOM nie określa, w jaki sposób tworzone jest drzewo DOM. Autorzy specyfikacji skoncentrowali się na strukturze i interfejsach API słuŜących do manipulacji tym drzewem; pozostawiono duŜą dowolność implementacji parsera DOM. W przeciwieństwie do klasy SAX XMLReader, dynamicznie ładującej implementację, w przypadku DOM to my musimy jawnie zaimportować i stworzyć egzemplarz klasy parsera DOM określonego producenta. Na początek stwórzmy nowy plik w Javie o nazwie DOMParserDemo.java. Zbudujemy prosty program przetwarzający z wykorzystaniem modelu DOM; będzie on wczytywał dokument XML i wyświetlał jego zawartość na ekranie. Zacznijmy od nakreślenia szkieletu naszej przykładowej klasy (przykład 7.2).

Przykład 7.2. Klasa DOMParserDemo // Importujemy parser DOM określonego producenta import org.apache.xerces.parsers.DOMParser; /** * DOMParserDemo pobiera plik XML i wyświetla * jego zawartość za pomocą modelu DOM. * * @author Brett McLaughlin * @version 1.0 */ public class DOMParserDemo { /** *

* Tutaj przetwarzamy plik i drukujemy dokument * za pomocą modelu DOM. *

* * @param uri String URI pliku do przetworzenia. */

Obiektowy model dokumentu (DOM)

161

public void performDemo(String uri) { System.out.println("Przetwarzanie pliku XML: " + uri + "\n\n"); // Tworzymy egzemplarz implementacji parsera DOM danego producenta DOMParser parser = new DOMParser(); try { // parser.parse(uri) } catch (Exception e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); } } /** *

* Obsługa wiersza poleceń programu. *

*/ public static void main(String[] args) { if (args.length != 1) { System.out.println("UŜycie: java DOMParserDemo [XML URI]"); System.exit(0); } String uri = args[0]; DOMParserDemo parserDemo = new DOMParserDemo(); parserDemo.performDemo(uri); } }

Struktura jest podobna do tej wykorzystywanej wcześniej w klasie SAXParserDemo, ale tym razem importujemy bezpośrednio klasę Apache Xerces DOMParser i tworzymy jej egzemplarz. Faktyczną metodę parse() opatrzyliśmy tymczasem komentarzami; zanim zajmiemy się przetwarzaniem struktury DOM, musimy omówić zagadnienia związane z wyborem parsera określonego producenta. NaleŜy pamiętać, Ŝe powyŜszy przykład jest bardzo prosty i działa w wielu aplikacjach, ale nie jest przenośny na inne implementacje parsera, tak jak to było w przypadku SAX-a. MoŜe pojawić się pokusa uŜycia konstrukcji Javy w rodzaju Class.forName(parserClass).newInstance() i pobrania za jej pomocą klasy parsera odpowiedniego producenta. JednakŜe inne implementacje modelu DOM zachowują się rozmaicie — czasem metoda parse() zwraca obiekt org.w3c.dom.Document (o którym powiemy niŜej), a czasem konieczne jest wywołanie tej metody z róŜnymi parametrami (InputSource, InputStream, String, URI itd.). Innymi słowy, drzewo DOM jest konstrukcją przenośną, natomiast metoda uzyskania tego drzewa — juŜ nie, chyba Ŝe programista zastosuje dość złoŜone klasy i metody dynamiczne.

Dane wyjściowe modelu DOM Jak pamiętamy, w interfejsie SAX działanie parsera skoncentrowane było wokół cyklu Ŝycia procesu — metody wsteczne oferowały „punkty zaczepienia” danych. Działanie modelu DOM skoncentrowane jest natomiast na danych wyjściowych procesu przetwarzania. Danych nie moŜna uŜyć, dopóki cały dokument nie zostanie przetworzony i dodany do wyjściowej struktury drzewia-

Obiektowy model dokumentu (DOM)

162

stej. Dane wyjściowe z procesu przetwarzania, które mają zostać wykorzystane przez interfejsy DOM, mają postać obiektu org.w3c.dom.Document. Obiekt ten działa jako „procedura obsługi” drzewa, w którym znajdują się nasze dane XML; z punktu widzenia hierarchii elementów, o której cały czas mówimy, obiekt ten znajduje się jeden poziom „ponad” elementem głównym dokumentu XML. Innymi słowy, kaŜdy element naszego wejściowego dokumentu XML jest bezpośrednio lub pośrednio potomny względem niego. Niestety, standaryzacja modelu DOM dotyczy samej obróbki danych, ale nie sposobu ich uzyskania. Powstało więc kilka mechanizmów uzyskiwania obiektu Document po przetwarzaniu. W wielu implementacjach, np. w starszych wersjach parsera IBM XML4J, obiekt Document był zwracany przez metodę parse(). Kod wykorzystujący tego typu implementację wyglądałby następująco: public void performDemo(String uri) { System.out.println("Przetwarzanie pliku XML: " + uri + "\n\n"); // Tworzymy egzemplarz implementacji parsera DOM danego producenta DOMParser parser = new DOMParser(); try { Document doc = parser.parse(uri); } catch (Exception e) { e.printStackTrace(); System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); } }

Większość nowszych parserów, takich jak Apache Xerces, korzysta z innych sposobów. W celu zachowania standardowego interfejsu w parserach SAX i DOM metoda parse() jest typu void, podobnie jak ta, którą poznaliśmy przy okazji omawiania SAX-a. Dzięki temu w aplikacji moŜna korzystać z klasy parsera DOM i SAX zamiennie; jednakŜe wiąŜe się to z koniecznością stworzenia nowej metody, słuŜącej do uzyskania obiektu Document będącego wynikiem przetwarzania XML. W parserze Apache Xerces metoda ta nosi nazwę getDocument(). Jeśli więc korzystamy z tego parsera, to aby uzyskać drzewo wynikowe DOM z procesu przetwarzania, uzupełniamy nasz przykładowy kod następująco: public void performDemo(String uri) { System.out.println("Przetwarzanie pliku XML: " + uri + "\n\n"); // Tworzymy egzemplarz implementacji parsera DOM danego producenta DOMParser parser = new DOMParser(); try { parser.parse(uri); Document doc = parser.getDocument(); } catch (Exception e) { e.printStackTrace(); System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); } }

NaleŜy równieŜ pamiętać o zaimportowaniu odpowiedniej klasy DOM: // Importujemy parser DOM określonego producenta import org.apache.xerces.parsers.DOMParser;

Obiektowy model dokumentu (DOM)

163

Aby dowiedzieć się, w jaki sposób moŜna uzyskać rezultat przetwarzania, naleŜy zajrzeć do dokumentacji posiadanego parsera. W następnym rozdziale przyjrzymy się interfejsowi API JAXP firmy Sun oraz innym, bardziej ustandaryzowanym sposobom uzyskiwania dostępu do drzewa DOM z dowolnej implementacji parsera. Jak widać, istnieją pewne róŜnice pomiędzy sposobami uzyskiwania opisywanych danych, natomiast uzyskane dane są zawsze takie same, a więc nie powinniśmy mieć dalszych kłopotów w przypadku uŜywania innego parsera.

Zastosowanie drzewa DOM Skoro juŜ uzyskaliśmy ten „drzewiasty” obiekt, spróbujmy wykorzystać go do czegoś poŜytecznego. Na przykład, „przejdziemy” przez strukturę, do której mamy dostęp, i wyświetlimy dane XML. W tym celu najprościej pobrać wstępny obiekt Document i przetworzyć kaŜdy węzeł, oraz — rekursywnie — wszystkie jego węzły potomne. Jeśli Czytelnik kiedykolwiek miał do czynienia ze strukturami drzewiastymi, ta czynność nie powinna stanowić problemu. W celu zrozumienia zasady działania całego procesu, naleŜy przyjrzeć się podstawowym obiektom, przez które zostaną udostępnione nasze dane XML. Poznaliśmy juŜ obiekt Document; ten oraz inne podstawowe interfejsy obiektów DOM zostały zaprezentowane na rysunku 7.2 (są tam równieŜ rzadziej wykorzystywane interfejsy). Za pomocą tych właśnie interfejsów będziemy przetwarzali dane w drzewie DOM. Warto dobrze przyjrzeć się przedstawionym interfejsom. Szczególną uwagę naleŜy poświęcić interfejsowi Node — stanowi on interfejs bazowy wszystkich innych. Widząc tego typu strukturę, powinniśmy natychmiast pomyśleć o rozpoznawaniu typu obiektu w czasie pracy programu. Innymi słowy, moŜliwe jest napisanie metody pobierającej węzeł, rozpoznającej, jakiego typu strukturę DOM ten węzeł stanowi i wyświetlającej węzeł w odpowiedni sposób. W ten sposób moŜemy wyświetlić całe drzewo DOM za pomocą jednej metody. Kiedy węzeł jest juŜ wyświetlony, korzystamy z dostępnych metod „przenoszących” nas do następnego elementu siostrzanego, pobierających atrybuty (jeśli jest to element) i obsługujących wszelkie moŜliwe sytuacje specjalne. Następnie, wykonując iterację po węzłach potomnych, rekurencyjnie uruchamiamy metodę na kaŜdym z tych węzłów, dopóki nie wyświetlimy całego drzewa DOM — oto prosty i przejrzysty sposób obsługi drzew DOM.

Do dzieła PoniewaŜ sam obiekt Document stanowi węzeł Node modelu DOM, moŜemy przekazać go w postaci niezmienionej do metody wyświetlającej. Zanim stworzymy szkielet takiej metody, musimy jednak dodać odpowiednie instrukcje importujące: import org.w3c.dom.Document; import org.w3c.dom.Node; // Importujemy parser DOM określonego producenta import org.apache.xerces.parsers.DOMParser;

Następnie dodajemy sygnaturę naszej metody, pobierającej i wyświetlającej obiekt DOM Node:

Obiektowy model dokumentu (DOM)

Rysunek 7.2. Model klasy UML podstawowych interfejsów i klas DOM Level 2 /** *

* Tutaj wyświetlamy węzeł DOM i przechodzimy * przez wszystkie węzły potomne. *

* * @param node Node obiekt do wyświetlania. * @param indent String białe znaki do wyświetlania * przed Node */ public void printNode(Node node, String indent) { // Rozpoznajemy typ węzła // Wyświetlamy węzeł // Przetwarzamy rekurencyjnie węzły potomne }

164

Obiektowy model dokumentu (DOM)

165

Kiedy szkielet metody jest juŜ we właściwym miejscu, moŜemy uruchomić metodę na początkowym obiekcie Document i przetwarzać rekursywnie dopóty, dopóki nie zostanie wyświetlone całe drzewo. Jest to moŜliwe właśnie dlatego, Ŝe interfejs Document to część wspólnego interfejsu Node: public void performDemo(String uri) { System.out.println("Przetwarzanie pliku XML: " + uri + "\n\n"); // Tworzymy egzemplarz implementacji parsera DOM danego producenta DOMParser parser = new DOMParser(); try { parser.parse(uri); Document doc = parser.getDocument(); // Wyświetlamy dokument z drzewa DOM printNode(doc);

} catch (Exception e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); } }

Teraz moŜemy juŜ skompilować plik programu w Javie. Nie uzyskamy Ŝadnych danych wyjściowych, ale przekonamy się chociaŜ, Ŝe stworzenie aplikacji wykorzystującej wejście DOM z parsera XML jest dość proste. W dalszej części spróbujemy nieco uatrakcyjnić nasz program demonstracyjny.

Rozpoznawanie typu węzła Wewnątrz metody wyświetlającej musimy przede wszystkim rozpoznać typ węzła. Moglibyśmy wykorzystać w tym celu metodologię Javy (instanceof i refleksja), ale dowiązania DOM dla Javy znacznie upraszczają ten proces. W interfejsie Node zdefiniowano metodę pomocniczą getNodeType(), zwracającą wartość typu całkowitego. Wartość ta porównywana jest z zestawem stałych zdefiniowanych równieŜ w ramach interfejsu Node i w ten sposób rozpoznajemy typ węzła. Takie rozwiązanie w sposób naturalny pasuje do konstrukcji switch Javy — za jej pomocą moŜemy w naszej metodzie rozbić wydruk na logiczne części. Typ węzła porównujemy z najczęściej spotykanymi typami; co prawda istnieje szereg innych typów (patrz rysunek 7.2), ale te wymienione poniŜej są najbardziej popularne, a opisywane rozwiązania w razie potrzeby moŜna zastosować takŜe do pozostałych. public static void printTree(Node node)

{

// Wybieramy czynność do wykonania na podstawie typu węzła switch (node.getNodeType()) { case Node.DOCUMENT_NODE: // Wyświetlamy zawartość obiektu Document break; case Node.ELEMENT_NODE: // Wyświetlamy element i jego atrybuty break; case Node.TEXT_NODE: case Node.CDATA_SECTION_NODE: // Wyświetlamy dane tekstowe break; case Node.PROCESSING_INSTRUCTION_NODE:

Obiektowy model dokumentu (DOM)

166

// Wyświetlamy instrukcję przetwarzania (PI) break; case Node.ENTITY_REFERENCE_NODE: // Wyświetlamy encję break; case Node.DOCUMENT_TYPE_NODE: // Wyświetlamy Wyświetlamy deklarację DTD break; } }

Warto zauwaŜyć, Ŝe węzły CDATASection i Text obsługujemy za pomocą jednej instrukcji case. W tym przykładzie nie będzie nas bowiem interesować, czy w oryginalnym dokumencie tekst znajduje się w części CDATA, czy nie; chcemy go tylko wyświetlić. Teraz w odpowiednich blokach kodu moŜemy dodać instrukcje wyświetlające i przetwarzające rekurencyjnie.

Typy węzłów DOM Skoro wiemy juŜ, jak wygląda i działa model DOM, wystarczy tylko poznać składnię dla poszczególnych typów węzłów — w ten sposób uzyskamy solidną wiedzę o działaniu modelu. Innymi słowy, teraz moŜemy juŜ traktować dowiązania Javy dla DOM-a tak jak inne interfejsy API — np. pakiety JNDI czy rozszerzenia serwletów. Zazwyczaj najtrudniejszą częścią nauki języka jest poznanie zasady jego działania; opanowanie składni wymaga juŜ tylko materiałów referencyjnych i przykładowego kodu. W tej części przedstawimy taki właśnie przykładowy kod. Wyświetlimy najczęściej spotykane typy węzłów oraz przyjrzymy się przetwarzaniu drzewa DOM. Później jako materiał referencyjny moŜna wykorzystać dokumentację online modelu DOM, znajdującą się pod adresem http://www.w3.org/DOM; podobną rolę pełni dodatek A, zawierający materiały referencyjne dla interfejsów SAX, DOM i JDOM (o tym ostatnim powiemy w następnym rozdziale).

Węzeł Document PoniewaŜ Document to część samego węzła Node, moŜemy uŜywać go wymiennie z innymi typami węzłów. Stanowi on jednak swoisty „przypadek specjalny”, poniewaŜ zawiera element główny i definicję DTD dokumentu oraz szereg innych specjalnych informacji nie naleŜących do hierarchii elementów XML. Dlatego przetwarzając ten węzeł, musimy uzyskać element główny i przekazać go funkcji wyświetlającej. Wyświetlimy równieŜ prostą deklarację wersji, tak aby dokument wyjściowy utrzymywał zgodność ze specyfikacją XML: case Node.DOCUMENT_NODE: System.out.println("\n"); Document doc = (Document)node; printTree(doc.getDocumentElement()); break;

PoniewaŜ chcemy uzyskać dostęp do metody specyficznej dla obiektu Document, najpierw musimy wykonać rzutowanie implementacji Node przekazanej do metody wyświetlającej na interfejs Document. Później moŜna juŜ uzyskać element główny dokumentu wejściowego XML za pomocą metody getDocumentElement() i przekazać go do metody wyświetlającej, rozpoczynając rekurencyjne przetwarzanie drzewa DOM.

Obiektowy model dokumentu (DOM)

167

Niestety, model DOM Level 2 (podobnie jak SAX 2.0) nie udostępnia deklaracji XML. Wydaje się, Ŝe nie jest to duŜy problem, ale tylko dopóki nie zdamy sobie sprawy, Ŝe w deklaracji tej zawarta jest równieŜ informacja o kodowaniu dokumentu. DOM Level 3 ma rozwiązać to niedopatrzenie (wersję roboczą specyfikacji udostępniono we wrześniu 2000 r. — przyp. tłum.). Do czasu rozwiązania problemu naleŜy unikać stosowania mechanizmu DOM w tym celu.

Elementy DOM Oczywiście, najbardziej typowym zadaniem wykonywanym w aplikacji będzie pobranie węzła DOM Element i wyświetlenie jego nazwy, atrybutów i wartości, a następnie jego elementów potomnych. Jak moŜna oczekiwać, wszystko to wykonuje się w bardzo prosty sposób metodami DOM. Najpierw pobieramy nazwę elementu (metoda getNodeName() wchodząca w skład interfejsu Node) i wyświetlamy ją. Chwilowo pominiemy obróbkę atrybutów i wydrukujemy nawias zamykający elementu. Następnie odnajdujemy elementy potomne względem bieŜącego i równieŜ wyświetlamy ich nazwy. Elementy potomne węzła Node są udostępniane poprzez metodę getChildNodes(), zwracającą egzemplarz DOM NodeList. Większość interfejsów API Javy wykorzystuje Vector, Hashtable lub inne zbiory klas obsługujące przetwarzanie list. DOM zwraca natomiast specjalny interfejs, NodeList. Nie moŜemy oczekiwać, Ŝe zaczniemy obsługiwać atrybuty poprzez metody Javy, do których jesteśmy przyzwyczajeni — korzystając z DOM-a, będziemy musieli zaznajomić się z nowymi strukturami.

Uzyskanie długości takiej listy jest zadaniem banalnym; podobnie jest z iteracją po elementach potomnych, wywoływaniem na nich metod wyświetlających i kontynuacją algorytmu rekurencyjnego. Na koniec wstawiamy znacznik zamykający elementu. Najpierw dodajemy wymagany interfejs DOM: import org.w3c.dom.Document; import org.w3c.dom.Node; import org.w3c.dom.NodeList; // Importujemy parser DOM określonego producenta import org.apache.xerces.parsers.DOMParser;

Teraz wymagane klasy i interfejsy są dostępne „po imieniu” — moŜemy więc dodać opisane wyŜej fragmenty kodu. Uzyskujemy nazwę implementacji Node, drukujemy ją w formacie XML, drukujemy jej elementy potomne (za pomocą wartości null sprawdzając, czy elementy takie istnieją) i zamykamy element. PoniŜszy kod nie obsługuje jeszcze atrybutów, ale powinien wyświetlić elementy XML z całego drzewa DOM: case Node.ELEMENT_NODE: String name = node.getNodeName(); System.out.print("<" + name); // Wyświetlamy atrybuty System.out.println(">"); // Rekurencyjne przetwarzanie elementów potomnych NodeList children = node.getChildNodes(); if (children != null) { for (int i=0; i
Obiektowy model dokumentu (DOM)

168

printTree(children.item(i)); } } System.out.println(""); break;

Proste, prawda? Równie łatwo wykonuje się iterację po atrybutach węzła DOM Element. Tym razem wykorzystujemy metodę getAttributes(), równieŜ zdefiniowaną w interfejsie Node. W ten sposób uzyskujemy listę atrybutów XML, zwróconą w postaci klasy NamedNodeMap. Interfejs ten wykorzystywany jest do gromadzenia węzłów o niepowtarzalnych nazwach, tak więc idealnie nadaje się do przechowywania atrybutów elementu XML. Kolejną czynnością jest iteracja po uzyskanej w ten sposób liście i wyświetlenie nazwy i wartości kaŜdego atrybutu. Jest to procedura podobna do tej, za pomocą której dokonywaliśmy iteracji po węzłach potomnych elementu; do uzyskania wartości do wyświetlenia uŜywamy metod getNodeName() i getNodeValue(). Wykonamy to zadanie poniŜej (naleŜy pamiętać o dodaniu instrukcji importującej dla NamedNodeMap): import import import import

org.w3c.dom.Document; org.w3c.dom.NamedNodeMap; org.w3c.dom.Node; org.w3c.dom.NodeList;

// Importujemy parser DOM określonego producenta import org.apache.xerces.parsers.DOMParser; ... case Node.ELEMENT_NODE: String name = node.getNodeName(); System.out.print("<" + name); NamedNodeMap attributes = node.getAttributes(); for (int i=0; i"); // Rekurencyjne przetwarzanie elementów potomnych NodeList children = node.getChildNodes(); if (children != null) { for (int i=0; i"); break;

No i sporą część pracy mamy juŜ za sobą! Te kilkaset wierszy kodu pozwala nam „przejść” przez całe drzewo DOM i wyświetlić elementy i atrybuty. To właśnie ta prostota (szczególnie w porównaniu z SAX-em) powoduje, Ŝe DOM jest tak popularny w aplikacjach obsługujących dane XML. Oczywiście — o czym juŜ wspominaliśmy i do czego jeszcze wrócimy — nie zawsze jest to rozwiązanie najlepsze; jednak na pewno udostępnia prostą reprezentację danych XML, do których programista ma bardzo łatwy dostęp.

Obiektowy model dokumentu (DOM)

169

Formatowanie Jeśli jeszcze tego nie zrobiliśmy, skompilujmy plik źródłowy i spróbujmy uruchomić go z argumentem w postaci pliku spisu treści. Powinniśmy uzyskać wynik działania podobny do fragmentu pokazanego w przykładzie 7.3.

Przykład 7.3. Wynik działania programu DOMParserDemo D:\prod\JavaXML> java DOMParserDemo D:\prod\JavaXML\contents.xml Przetwarzanie pliku XML: contents.xml

...

Wynik jest zgodny z oczekiwaniami, wciąŜ jednak uzyskane informacje nie są ani przejrzyste, ani zbyt przydatne. Bardzo trudno stwierdzić, gdzie elementy zaczynają się, a gdzie kończą — nie ma wcięć, które były w oryginalnym dokumencie. Jak pamiętamy, białe znaki występujące pomiędzy elementami są „obcinane” i zazwyczaj ignorowane przez parsery, tak więc tutaj musimy ponownie je dodać. W tym celu przekaŜemy prosty łańcuch z „wcięciami” do metody wyświetlającej. Wcięcia będą dodawane w miarę rekurencyjnego przechodzenia po drzewie DOM: /** *

* Tutaj drukujemy węzeł DOM i przechodzimy * przez wszystkie węzły potomne. *

* * @param node Node obiekt do wyświetlania. * @param indent String białe znaki do wyświetlania * przed Node */ public void printNode(Node node, String indent) {

// Wybieramy czynność do wykonania na podstawie typu węzła switch (node.getNodeType()) { case Node.DOCUMENT_NODE: System.out.println("\n");

Obiektowy model dokumentu (DOM)

170

Document doc = (Document)node; printNode(doc.getDocumentElement(), ""); break; case Node.ELEMENT_NODE: String name = node.getNodeName(); System.out.print(indent + "<" + name); NamedNodeMap attributes = node.getAttributes(); for (int i=0; i"); // Rekurencyjne przetwarzanie elementów potomnych NodeList children = node.getChildNodes(); if (children != null) { for (int i=0; i"); break; case Node.TEXT_NODE: case Node.CDATA_SECTION_NODE: // Wyświetlamy dane tekstowe break; case Node.PROCESSING_INSTRUCTION_NODE: // Wyświetlamy instrukcję przetwarzania (PI) break; case Node.ENTITY_REFERENCE_NODE: // Wyświetlamy encję break; case Node.DOCUMENT_TYPE_NODE: // Wyświetlamy deklarację DTD break; } }

Teraz jeszcze wykonamy małą zmianę polegającą na przekazaniu naszej metodzie początkowego wcięcia w postaci łańcucha pustego: public void performDemo(String uri) { System.out.println("Przetwarzanie pliku XML: " + uri + "\n\n"); // Tworzymy egzemplarz implementacji parsera DOM danego producenta DOMParser parser = new DOMParser(); try { parser.parse(uri); Document doc = parser.getDocument(); // Wyświetlamy dokument z drzewa DOM // z wcięciem w postaci łańcucha pustego printNode(doc, "");

Obiektowy model dokumentu (DOM)

171

} catch (Exception e) { System.out.println("Błąd w przetwarzaniu: " + e.getMessage()); } }

Po tych niewielkich zmianach dane wynikowe prezentują się o wiele bardziej estetycznie (przykład 7.4).

Przykład 7.4. Wynik działania programu DOMParserDemo po zastosowaniu wcięć D:\prod\JavaXML> java DOMParserDemo D:\prod\JavaXML\contents.xml Przetwarzanie pliku XML: contents.xml

...

Teraz moŜna juŜ dodać wartości tekstowe zawarte w elementach.

Węzły tekstowe Czytelnik być moŜe zastanawia się teraz, gdzie w ksiąŜce zawarte są informacje dotyczące węzłów o wartościach typu całkowitego, numerycznych czy boolowskich. OtóŜ w niniejszej ksiąŜce nie ma ich wcale. Jak pamiętamy, wszystkie dane XML w elementach zwracane są przez wywołanie SAX characters(). JuŜ to powinno podpowiedzieć Czytelnikowi, Ŝe parser XML „postrzega” wszystkie dane jako tekst i Ŝe to aplikacja dokonuje w razie potrzeby konwersji typów. Tak więc aby wyświetlić wartości elementów w DOM-ie, naleŜy skupić uwagę na interfejsach Text i CDATASection. Wyświetlanie wartości jest całkiem proste — korzystamy ze znanej juŜ metody getNodeValue() interfejsu DOM Node: case Node.TEXT_NODE: case Node.CDATA_SECTION_NODE: System.out.print(node.getNodeValue()); break;

Po dodaniu tego fragmentu przetwarzanie modelu DOM jest juŜ niemal kompletne. Zanim jednak przejdziemy dalej, przyjrzyjmy się kilku rzadziej uŜywanym, ale równie przydatnym interfejsom DOM (i odpowiadającym im typom Node): ProcessingInstruction, DocumentType i EntityReference — wszystkie występują w naszym dokumencie.

Obiektowy model dokumentu (DOM)

172

Instrukcje przetwarzania W ramach dowiązań DOM do Javy zdefiniowano interfejs do obsługi instrukcji przetwarzania występujących w wejściowym dokumencie XML. To bardzo przydatne rozwiązanie, poniewaŜ instrukcje te są budowane według tego samego modelu znaczników co elementy i atrybuty XML, a mimo to stanowią istotną część XML-a i powinna o nich wiedzieć aplikacja. W naszym przykładowym dokumencie procesorowi XSLT przekazujemy instrukcje informujące o arkuszu stylów, a strukturze publikacji (Apache Cocoon) — instrukcję informującą o tym, jakie przetwarzanie ma zostać wykonane. Jeśli w pliku Czytelnika instrukcje PI są wciąŜ opatrzone komentarzami, to naleŜy je teraz usunąć:

Węzeł PI w modelu DOM stanowi pewne odstępstwo od schematu, który poznaliśmy — aby zachować zgodność ze składnią interfejsu Node, metoda getNodeValue() zwraca wszystkie instrukcje w PI w postaci jednego łańcucha String. To pozwala w prosty sposób wyświetlić instrukcję PI na ekranie; wciąŜ jednak do pobrania nazwy PI musimy korzystać z metody getNodeValue(). Gdybyśmy pisali aplikację, która otrzymywałaby instrukcje PI z dokumentu XML, skorzystalibyśmy raczej z interfejsu ProcessingInstruction; dzięki temu uzyskujemy dostęp do takich samych danych, ale nazwy metod (getTarget() i getData()) są bardziej zgodne z formatem PI. Mając to na uwadze, moŜemy juŜ dodać kod wyświetlający instrukcje przetwarzania: case Node.PROCESSING_INSTRUCTION_NODE: System.out.println(""); break;

Po skompilowaniu i uruchomieniu tak zmienionego programu znów moŜe nas spotkać niespodzianka — Ŝadne instrukcje przetwarzania w dokumencie nie zostały wyświetlone na ekranie! Dlaczego? OtóŜ kod w takiej postaci uzyskuje obiekt Document z parsera XML i przetwarza tylko element główny wejściowych danych XML. PoniewaŜ instrukcje przetwarzania znajdują się na tym samym „poziomie” co element główny — są one ignorowane. Aby to poprawić, musimy zmienić część kodu obsługującą węzeł typu Document. Wprowadzimy fragment podobny do tego, jakim obsługiwaliśmy elementy potomne w celu przetworzenia wszystkich struktur XML „najwyŜszego poziomu”, a nie tylko elementu głównego: case Node.DOCUMENT_NODE: System.out.println("\n"); // Rekurencyjne przetwarzanie elementów potomnych NodeList nodes = node.getChildNodes(); if (nodes != null) { for (int i=0; i
Obiektowy model dokumentu (DOM)

173

} /* Document doc = (Document)node; printNode(doc.getDocumentElement(), ""); */ break;

Po wprowadzeniu tych zmian instrukcje PI powinny pojawić się na początku zwracanych danych, zgodnie z oczekiwaniami. To kolejna subtelna cecha DOM, o której warto pamiętać — zawsze naleŜy uwaŜać nie tylko na te węzły, które przetwarzamy, ale takŜe na te, których nie przetwarzamy!

Typy dokumentów Oprócz instrukcji PI, moŜe okazać się konieczne uzyskanie deklaracji DTD — daje nam to informacje, do jakich zawęŜeń odwołuje się dokument XML. JednakŜe, poniewaŜ mogą istnieć identyfikatory publiczne i systemowe, a takŜe inne dane specyficzne dla DTD, w celu uzyskania tych dodatkowych danych musimy skorzystać z interfejsu DocumentType (w ramach naszego egzemplarza Node). Potem do pobrania nazwy z Node uŜyjemy metod pomocniczych; Node zwraca element główny zawęŜanego dokumentu, identyfikator publiczny (jeśli istnieje) oraz identyfikator systemowy definicji DTD, do której następuje odwołanie. Spróbujmy zrekonstruować odwołanie do DTD w naszym dokumencie: import import import import import

org.w3c.dom.Document; org.w3c.dom.DocumentType; org.w3c.dom.NamedNodeMap; org.w3c.dom.Node; org.w3c.dom.NodeList;

// Importujemy parser DOM określonego producenta import org.apache.xerces.parsers.DOMParser; ... case Node.DOCUMENT_TYPE_NODE: DocumentType docType = (DocumentType)node; System.out.print(""); break;

Encje Ostatni typ węzła, jaki omówimy, to interfejs EntityReference. Obsługuje on encje występujące w dokumencie XML — takie jak ta opisująca prawa autorskie. Sposób drukowania tego typu węzła nie stanowi niespodzianki: case Node.ENTITY_REFERENCE_NODE: System.out.print("&" + node.getNodeName() + ";"); break;

Niespodzianką mogą natomiast okazać się uzyskane w ten sposób dane. Definicja sposobu przetwarzania encji w modelu DOM zostawia duŜą swobodę implementacji i sposób działania w duŜym

Obiektowy model dokumentu (DOM)

174

stopniu zaleŜy tutaj od parsera. Większość parserów XML tłumaczy i przetwarza encje, zanim w ogóle dane XML „dostaną się” do drzewa DOM. Często więc spodziewamy się zobaczenia encji w strukturze DOM, a zamiast tego widzimy tekst lub wartości. Aby sprawdzić, jak zachowuje się nasz parser, opatrzmy komentarzami „HTML-ową” wersję elementu JavaXML:Copyright (wstawiliśmy ją w poprzednim rozdziale) i zamieńmy ją na encję OReillyCopyright:

--> &OReillyCopyright;

Takie zachowania mogą stanowić przyczynę błędu w aplikacji. CóŜ więc za poŜytek z typu węzła opisującego encję, jeśli i tak jest ona wcześniej przetwarzana przez parser? OtóŜ węzeł taki powstał z myślą o tworzeniu nowego, a nie przetwarzaniu istniejącego dokumentu XML. To zagadnienie stanowić będzie treść kolejnego podrozdziału.

Mutacje drzewa DOM Czytelnik obeznany z modelem DOM zapewne zauwaŜył, Ŝe pominęliśmy jeden bardzo istotny temat — moŜliwość zmiany drzewa DOM. MoŜliwe jest proste dodawanie węzłów do drzewa DOM. Właściwie jeśli pominąć prostotę, ta zdolność modyfikacji i dodawania węzłów do drzewa jest faktycznie jedną z najczęściej wykorzystywanych i najbardziej cenionych cech. I w ten sposób powróciliśmy do kwestii transformacji XML-a. Dlaczego model DOM jest tak istotny dla procesora XSLT? OtóŜ nie tylko chodzi tu o dane wejściowe, udostępniane w prosty sposób; waŜne jest takŜe to, Ŝe procesor XSLT moŜe tworzyć nowe drzewo DOM na potrzeby dokumentu wyjściowego — a takŜe w prosty sposób kopiować, modyfikować, dodawać i usuwać węzły drzewa wejściowego. Takie przetwarzanie preferowane jest szczególnie w złoŜonych aplikacjach — często dane wejściowe przekazywane są na drzewo wyjściowe bez rzutowania klas czy tworzenia nowych egzemplarzy obiektów — to istotnie zmniejsza złoŜoność i zwiększa wydajność procesora XSLT. To dlatego poświęciliśmy tak duŜo czasu modelowi DOM. Omówienie mutowania, na które z pewnością czeka Czytelnik, zawarte jest w kolejnych rozdziałach. Teraz omówienie tego tematu oddaliłoby nas od tematu arkuszy XSL, ale w dalszych rozdziałach powrócimy do zagadnień związanych z tworzeniem i modyfikacją XML-a. Zanim jednak przejdziemy do bardziej zaawansowanych rozdziałów, naleŜy omówić pułapki, jakie mogą czyhać na programistę Javy korzystającego z potęŜnego interfejsu DOM.

Uwaga! Pułapka!

175

Uwaga! Pułapka! Podobnie jak w poprzednich rozdziałach, zostaną tutaj omówione najczęstsze pułapki czyhające na programistów Javy zajmujących się XML-em, ze szczególnym uwzględnieniem modelu DOM. Niektóre z poniŜszych uwag mają charakter bardziej informacyjny niŜ praktyczny, ale na pewno przyczynią się do podejmowania właściwych decyzji odnośnie stosowania modelu DOM i pomogą w zrozumieniu, co dzieje się „pod maską” naszych aplikacji XML.

Pamięć i wydajność w modelu DOM DuŜo czasu zajęło nam wcześniej omawianie powodów, dla których warto zdecydować się na DOM lub SAX. JuŜ wcześniej podkreślaliśmy, Ŝe korzystanie z modelu DOM wymaga wczytania całego dokumentu XML do pamięci i przechowywania go tam w postaci struktury drzewiastej — o tym trzeba koniecznie pamiętać! Niezwykle często zdarza się sytuacja, w której programista ładuje cały zbiór złoŜonych dokumentów XML do procesora XSLT i zostawia je do przetworzenia w trybie offline. Po powrocie komputer z systemem Windows wyświetla straszliwy „niebieski ekran śmierci”, a Linux zalewa ekran komunikatami o braku pamięci. Powtórzmy więc jeszcze raz — naleŜy uwaŜać na DOM przy przetwarzaniu duŜych ilości danych! Korzystanie z modelu DOM wymaga zaangaŜowania pamięci w ilości proporcjonalnej do rozmiaru i złoŜoności dokumentu XML. Nie ma sposobu obniŜenia wymogów odnośnie pamięci. Co więcej, same transformacje to „zasoboŜerne” operacje; w połączeniu z wymaganiami pamięciowymi to naprawdę daje duŜo do myślenia. CzyŜ więc programista nie powinien nigdy nie korzystać z DOM-a? Oczywiście, powinien korzystać! Trzeba jednak zachować duŜą ostroŜność i uwaŜać na to, co przekazujemy do modelu. Jeśli operujemy na niewielkich, mniejszych niŜ megabajt dokumentach, prawdopodobnie Ŝadne kłopoty nigdy nam się nie przydarzą. Większe dokumenty — podręczniki techniczne czy całe ksiąŜki — mogą pochłonąć zasoby systemowe i wpłynąć na wydajność aplikacji.

Analizatory DOM zgłaszające wyjątki SAX W naszych przykładach związanych z modelem DOM nie wspomnieliśmy o wyjątkach zgłaszanych w wyniku przetwarzania dokumentu. Wynika to stąd, Ŝe — jak mówiliśmy — proces generowania drzewa DOM pozostawiono implementacji parsera, a te róŜnią się przecieŜ miedzy sobą. JednakŜe zawsze dobrze jest przechwytywać specyficzne wyjątki i odpowiednio na nie reagować. Odpowiednia zmiana głównej pętli parsera moŜe być nieco zaskakująca. Oto wersja dla Apache Xerces: /** *

* Tutaj przetwarzamy plik i wyświetlamy dokument * za pomocą modelu DOM. *

* * @param uri String URI pliku do przetworzenia. */ public void performDemo(String uri) { System.out.println("Przetwarzanie pliku XML: " + uri + "\n\n"); // Tworzymy egzemplarz implementacji parsera DOM danego producenta DOMParser parser = new DOMParser(); try { parser.parse(uri); Document doc = parser.getDocument();

Co dalej?

176 // Wyświetlamy dokument z drzewa DOM // z wcięciem w postaci łańcucha pustego printNode(doc, ""); } catch (IOException e) { System.out.println("Błąd wczytywania URI: " + e.getMessage()); } catch (SAXException e) { System.out.println("Błąd przetwarzania: " + e.getMessage()); }

}

Niespodzianką nie jest IOException (wskazuje błąd w lokalizacji podanego URI, podobnie jak w przykładzie SAX). Zastanawia coś innego — moŜliwość zgłoszenia wyjątku SAXException. Nasz parser DOM zgłasza wyjątek SAX? Chyba zaimportowaliśmy nie te klasy! Nie, klasy są właściwe. Pamiętajmy o tym, co mówiliśmy wcześniej — moŜliwe jest własnoręczne zbudowanie struktury drzewiastej danych w dokumencie XML za pomocą SAX-a, ale DOM stanowi ciekawą alternatywę. To prawda, ale nie wyklucza to jeszcze uŜycia interfejsu SAX. Rzeczywiście SAX udostępnia wydajny i szybki sposób przetworzenia dokumentu; akurat w naszym przypadku dokument jest przetwarzany przez SAX i wstawiany do struktury DOM. PoniewaŜ nie istnieje standard rządzący sposobem tworzenia struktury DOM, takie rozwiązanie jest dopuszczalne, a nawet popularne. Nie naleŜy więc dziwić się, Ŝe importujemy i przechwytujemy org.xml.sax.SAXException w aplikacjach DOM.

Co dalej? Rozdziały 1. – 7. stanowią pokaźny zbiór informacji o XML-u. Czytelnik powinien juŜ potrafić posługiwać się XML-em, definicjami DTD i schematami oraz XSLT. To najwaŜniejsze technologie w programowaniu z wykorzystaniem języka XML. W kolejnych rozdziałach pojawią się oczywiście jeszcze inne skróty i specyfikacje, ale omówione zagadnienia to klucz do korzystania z XML-a z poziomu Javy. Oprócz specyfikacji zostały omówione takŜe SAX i DOM, zatem Czytelnik potrafi reprezentować większość danych XML w Javie. MoŜna powiedzieć, Ŝe Czytelnik jest juŜ oficjalnie programistą znającym Javę i XML! W następnym rozdziale powrócimy do omawiania interfejsów SAX i DOM; wykaŜemy ich zalety i wady. Przed zagłębieniem się w kodach aplikacji (czemu poświęcona jest reszta ksiąŜki) zostanie omówiony interfejs JDOM. Twórcy JDOM starali się naprawić problemy i dokuczliwości związane z interfejsami SAX i DOM. Powstały w ten sposób interfejs API otwiera przed programistą XML-a nowe moŜliwości.

Parsery i JAXP

177

8 JDOM Nasza podróŜ po krainie języka XML dobiegła półmetka. Czytelnik powinien juŜ mieć ogólne pojęcie o przydatności opisywanych narzędzi — niektóre z nich są bardzo uŜyteczne, inne nieco siermięŜne. Powinien równieŜ umieć korzystać z tych interfejsów i koncepcji w swoich aplikacjach, a przede wszystkim doceniać, jak bardzo moŜe się mu przydać XML. W tym rozdziale — zanim zagłębimy się w specyficzne tematy związane z XML-em — zostaną omówione dodatkowe interfejsy programistyczne łączące Javę i XML. Najpierw omówimy pomocniczy interfejs programistyczny, Java API for XML Parsing (JAXP). Interfejs ten, opracowany przez firmę Sun, udostępnia abstrakcyjną warstwę w procesie uzyskiwania egzemplarza parsera SAX lub DOM; Czytelnik zapewne spostrzegł we wcześniejszych rozdziałach, Ŝe zadanie to nie wszędzie zostało ustandaryzowane (szczególnie chodzi tu o DOM) i nie przekłada się na niezaleŜność XML-a względem konkretnego producenta. Po omówieniu interfejsu JAXP zostanie przedstawiony nowy interfejs programistyczny, JDOM. Interfejs ten nie jest spokrewniony z DOM-em w obszarze struktury czy implementacji, ale — podobnie jak DOM — oferuje kompletną reprezentację dokumentu XML. Został jednak stworzony z myślą o konkretnym celu — rozwiązaniu szeregu opisanych juŜ problemów związanych z SAX-em i DOM-em (patrz podrozdziały Uwaga! Pułapka!) i zwiększeniu przydatności i wydajności względem istniejących interfejsów API dla Javy. Czytelnik pozna cel utworzenia, oferowane funkcje i przyszłość tego interfejsu jako alternatywy dla SAX-a, DOM-a i JAXP-a. Najpierw jednak do naszego zestawu narzędzi dodajmy interfejs JAXP.

Parsery i JAXP Czytelnik zainteresowany tematem XML-a i Javy prawdopodobnie natknął się na produkt firmy Sun o nazwie Java API for XML Parsing, najczęściej określanego skrótem JAXP. Wspomnieliśmy o nim równieŜ skrótowo w rozdziale 1. Jeśli wziąć pod uwagę, Ŝe JAXP jest często wymieniany jednym tchem z SAX-em i DOM-em, moŜe nieco zaskakiwać fakt, Ŝe zajmujemy się nim dopiero teraz. JednakŜe cały pakiet JAXP, wchodzący w skład javax.xml.parsers, to ledwie sześć klas, z których cztery są abstrakcyjne. Pozostałe dwie opisują wyjątki zgłaszane przez pierwsze cztery. Czytelnik zapewne pamięta, Ŝe podczas korzystania z interfejsu DOM (i SAX bez klasy XMLReaderFactory) trzeba jawnie zaimportować i wpisać odwołanie do klasy parsera danego producenta. W Apache Xerces odpowiednie klasy to org.apache.xerces.parsers.SAXParser oraz

Parsery i JAXP

178

org.apache.xerces.parsers.DOMParser. Problem polega na tym, Ŝe zmiana parsera wymaga zmiany kodu aplikacji i rekompilacji. To istotna wada — dobrze byłoby, gdyby parsery moŜna było dołączać na zasadzie „wtyczek”. Do tego właśnie słuŜy interfejs JAXP. Kiedy korzystamy z interfejsu JAXP, to zamiast bezpośrednio importować klasę parsera określonego producenta, definiujemy ją za pomocą właściwości systemowej. JAXP odczytuje tę właściwość i zajmuje się załadowaniem danego parsera. W ten sposób zmiana implementacji parsera wymaga tylko zmiany właściwości systemowej — kod aplikacji wykorzystuje dostarczoną przez firmę Sun warstwę abstrakcyjną.

Współpraca JAXP-SAX Kiedy korzystamy z interfejsu SAX, powinniśmy skorzystać z klas JAXP SAXParser i SAXParserFactory. Pierwsza przejmuje rolę implementacji parsera SAX, a druga obsługuje dynamiczne ładowanie implementacji. Przed omówieniem tych zmian zobaczymy, w jaki sposób moŜna stworzyć abstrakcję konkretnej implementacji parsera XML (przykład 8.1).

Przykład 8.1. Pobieranie implementacji parsera SAX za pomocą JAXP import javax.xml.parsers.SAXParser; import javax.xml.parsers.SAXParserFactory; import javax.xml.parsers.ParserConfigurationException; import org.xml.sax.SAXException; import org.xml.sax.helpers.HandlerBase; public class JAXPSAXTest { public void doSomeParsing() { SAXParser parser; SAXParserFactory factory = SAXParserFactory.newInstance(); HandlerBase myHandler = new MyHandlerBase(); factory.setValidating(true); factory.setNamespaceAware(true); try { parser = factory.newSAXParser(); parser.parse(myURI, myHandler); } catch (SAXException e) { // Obsługa błędów SAX } catch (IOException e) { // Obsługa błędów związanych z wczytywaniem URI } catch (ParserConfigurationException e) { // Obsługa błędów związanych z niemoŜnością // załadowania określonej implementacji parsera } } }

Przykład nie róŜni się specjalnie od tych, które widzieliśmy w poprzednich rozdziałach, z tym Ŝe nie ma tutaj kodu specyficznego dla Apache Xerces czy jakiegokolwiek innego konkretnego parsera. Klasa SAXParser przechwytuje egzemplarz wykorzystywanej implementacji parsera i pobiera ten egzemplarz z egzemplarza klasy SAXParserFactory. Jedyne, czym powyŜszy kod się róŜni od omawianych wcześniej, to fakt, Ŝe sprawdzanie poprawności i „świadomość” przestrzeni nazw włączana jest poprzez SAXParserFactory, a nie przez sam egzemplarz parsera.

Parsery i JAXP

179

RóŜnica polega na tym, Ŝe tutaj wszystkie egzemplarze uzyskują podane właściwości; naleŜy więc pamiętać, aby funkcji nie włączać zbyt wcześnie, i zapomnieć, Ŝe jest włączona przy pobieraniu implementacji parsera w dalszej części kodu. Inne odstępstwo od kodu, w którym bezpośrednio korzystaliśmy z implementacji parsera SAX, polega na tym, Ŝe do metody parser() klasy SAXParser konieczne jest przekazanie egzemplarza klasy pomocniczej HandlerBase. Tak więc wszystkie programy obsługi zawartości, błędów i inne gromadzone są w jednej podklasie HandlerBase. NaleŜy uwaŜać, aby nie implementować bezpośrednio interfejsów SAX i próbować korzystać z nich indywidualnie (poprzez metody setXXXHandler() dostępne w interfejsie SAX Parser). Jeśli klasa HandlerBase z niczym się Czytelnikowi nie kojarzy, to prawdopodobnie Czytelnik nie zna interfejsu SAX 1.0. Niestety, JAXP obsługuje tylko SAX 1.0 — w SAX-ie 2.0 klasę HandlerBase zastąpiono klasą DefaultHandler. W klasie tej zaimplementowano najwaŜniejsze interfejsy SAX 1.0, udostępniając puste implementacje wszystkich metod zdefiniowanych w ErrorHandler, DTDHandler, EntityResolver i DocumentHandler (który w SAX-ie 2.0 zarzucono na rzecz ContentHandler). W podklasie HandlerBase nadpisujemy wszystkie wywołania, w których ma nastąpić jakieś działanie. Po utworzeniu programu obsługi metoda parse() moŜe zostać wywołana na egzemplarzu SAXParser — jako parametry podaje się identyfikator URI dokumentu do przetworzenia oraz egzemplarz DefaultHandler.

Współpraca JAXP-DOM Podstawy współpracy JAXP-a z DOM-em są takie same jak w przypadku współpracy JAXP — SAX. Klasami analogicznymi do SAXParser i SAXParserFactory są DocumentBuilder i DocumentBuilderFactory, słuŜące do tworzenia drzewa modelu DOM (takŜe w pakiecie javax.xml.parsers). Faktycznie obie te klasy wykorzystują do komunikacji z resztą aplikacji interfejsy API SAX — zgłaszają równieŜ te same wyjątki co klasy SAX (w tym SAXException). Specyfikacja JAXP nie wymaga, aby implementacje DOMBuilder uŜywały SAX-a do tworzenia drzewa DOM; wymaga za to wykorzystania interfejsu API w komunikacji z aplikacją. Kod wykorzystujący klasy JAXP DOM (przykład 8.2) jest niemal identyczny z kodem poprzedniego przykładu.

Przykład 8.2. Pobieranie implementacji parsera DOM za pomocą JAXP import javax.xml.parsers.DocumentBuilder; import javax.xml.parsers.DocumentBuilderFactory; import javax.xml.parsers.ParserConfigurationException; import org.xml.sax.SAXException; import org.xml.sax.helpers.HandlerBase; public class JAXPDOMTest { public void doSomeParsing() { DocumentBuilder parser; DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setValidating(true); factory.setNamespaceAware(true); try { parser = factory.newDocumentBuilder(); Document doc = parser.parse(myURI);

Parsery i JAXP

180

} catch (SAXException e) { // Obsługa błędów SAX } catch (IOException e) { // Obsługa błędów związanych z wczytywaniem URI. } catch (ParserConfigurationException e) { // Obsługa błędów związanych z niemoŜnością // załadowania określonej implementacji parsera. } } }

Klasa DocumentBuilderFactory umoŜliwia włączenie sprawdzania poprawności i „świadomości” przestrzeni nazw; ustawienia te zostaną utrzymane dla wszystkich egzemplarzy DocumentBuilder uzyskanych w wyniku działania metody newDocumentBuilder(). Po określeniu połoŜenia dokumentu do przetwarzania moŜna wywołać metodę parse(), zwracającą obiekt DOM Document, będący wynikiem przetwarzania. Po przetworzeniu moŜna wykorzystać standardowe obiekty i metody DOM — aplikacja jest zupełnie oddzielona od detali związanych z parserem określonego producenta.

Wybór parsera Nie powiedzieliśmy jeszcze o sposobie ustalenia, jaki parser ma być zastosowany. Jak wspomnieliśmy, JAXP ma uprościć zmianę implementacji parsera. JednakŜe nie jest to czynność tak prosta, jak mogłoby się wydawać. PoniewaŜ JAXP zawiera cztery klasy abstrakcyjne, kaŜdy parser obsługujący ten interfejs musi udostępniać implementacje klas JAXP. Na przykład Apache Xerces posiada wymagane klasy w org.apache.xerces.jaxp. Specyfikacja JAXP mówi, Ŝe kaŜda implementacja moŜe domyślnie udostępniać dowolny parser; innymi słowy, implementacja Apache Xerces udostępnia jako domyślny parser Apache Xerces, a Oracle — najprawdopodobniej parser Oracle. Zmiana domyślnej klasy parsera na inną moŜe zostać wykonana poprzez ustawienie właściwości systemowej javax.xml.parsers.SAXParserFactory tak, by wskazywała na nowego producenta SAX, lub przez ustawienie javax.xml.parsers.DocumentBuilderFactory tak, by wskazywała na nowego producenta DOM. Właściwości systemowe moŜna ustawiać za pomocą opcji -D w programach uruchamianych z wiersza poleceń lub poprzez System.setProperty() w kodzie Javy. Klasy JAXP odczytują właściwości systemowe i odpowiednio reagują na wywołania newSAXParser() i newDocumentBuilder() — udostępniają egzemplarze klas danego producenta. JednakŜe większość współczesnych aplikacji nie jest obsługiwana z wiersza poleceń, ale poprzez interfejs WWW; czasem stanowią one część większego pakietu. Co więcej, uŜycie System.setProperty() w zwyczajny sposób spowodowałoby odczytanie informacji przekazanych do setProperty() (takich jak nazwa własności i klasa sterownika SAX) z pliku właściwości. Plik taki nie moŜe być plikiem XML (o tym więcej w rozdziale 11.), poniewaŜ nie istnieje jeszcze odpowiedni parser. Pakiet Java Development Kit (JDK) 1.3 udostępnia moŜliwość określania właściwości we wdraŜanym pliku jar; jednak w czasie pisania tej ksiąŜki wiele popularnych platform (np. Linux) nie obsługiwało jeszcze JDK 1.3. Innymi słowy, duŜe moŜliwości konfiguracyjne w ramach JAXP dopiero powstają. Mimo tych niedogodności, koncepcje przyświecające utworzeniu interfejsu JAXP są niezwykle wartościowe; ponadto firma Sun przekazała niedawno kody JAXP i parsera Project X opiekunom projektu Apache Xerces (kod nosi nazwę „Crimson”), co oznacza, Ŝe Sun zamierza przyspieszyć rozwój swojego API i Ŝe sprzyja otwartym standardom. Pod koniec roku 2000 moŜna oczekiwać

JDOM — kolejny API?

181

wersji JAXP 1.1, obsługującej DOM Level 2, SAX 2.0 i umoŜliwiającej bardziej ogólny sposób wyboru parsera. (Wersja robocza specyfikacji JAXP 1.1 została udostępniona w grudniu 2000 r. — przyp. tłum.).

JDOM — kolejny API? Czytelnik poznał juŜ interfejsy API słuŜące do korzystania z XML-a z poziomu Javy; zostały omówione ich największe wady i zalety. Jednak trudno zafascynować się tym, co mają nam do zaoferowania SAX, DOM i JAXP. O ile społeczność XML-a ma juŜ konieczne do pracy narzędzia, o tyle programiści Javy są nieco zdezorientowani niestandardowymi sposobami zachowania SAX-a i DOM-a oraz ogólną trudnością manipulacji dokumentami XML, a nawet po prostu problemami z uzyskaniem parsera! Dlatego, zgodnie z tradycją oprogramowania open source, projektów związanych z językiem Java i wydawnictwa O'Reilly & Associates, postanowiliśmy naprawić ten błąd i zaprezentować nowe rozwiązanie — interfejs JDOM.

Skąd nazwa? Pierwsi testerzy JDOM byli nieco zaskoczeni nazwą — zbliŜoną do DOM, który to interfejs jest z natury bardziej pojemny. PoniewaŜ jednak JDOM po prostu reprezentuje dokument w Javie, nazwa wydaje się odpowiednia. Innymi słowy, została wybrana ze względu na precyzyjne odwzorowanie przeznaczenia interfejsu mimo podobieństwa do nazwy innego API. Co więcej, JDOM jest tylko luźno związany z XML-em. Obsługuje dowolny hierarchiczny format danych i moŜe równie łatwo podlegać serializacji, jak zwracać w wyniku dane XML — za pomocą obiektów OutputStream lub File oraz klas wyjściowych JDOM. Implementacja JDOM org.jdom.input.Builder udostępnia równieŜ sprawny sposób tworzenia obiektu JDOM Document; obiekt ten moŜe zostać utworzony z pliku właściwości w niestandardowym formacie lub w formacie XML. JDOM faktycznie reprezentuje dowolny zbiór danych w Javie.

Na interfejs JDOM składa się specyfikacja autorstwa Bretta McLaughlina i Jasona Huntera (K&A Software), utworzona przy współpracy Jamesa Duncana Davidsona (autor specyfikacji JAXP). JDOM jest mało wymagającym mechanizmem do analizowania i przeglądania dokumentu XML. Opisano dane wejściowe i wyjściowe słuŜące do stworzenia obiektu JDOM Document z istniejących danych XML i zwrócenia go w określonym celu. Stworzono działającą implementację w postaci pakietu org.jdom (wersja 1.0) — moŜna go pobrać ze strony pod adresem http://www.jdom.org. Celem stworzenia JDOM było rozwiązanie problemów związanych z interfejsami SAX, DOM i JAXP. Zobaczymy, co oferuje nowy interfejs i czy w ogóle był potrzebny (mało jeszcze tych skrótów?). Twórcy JDOM mieli na celu stworzenie skupionego wokół Javy, wysoko wydajnego zamiennika interfejsów SAX i DOM w większości zastosowań1. Nie jest oparty na DOM-ie czy SAX-ie. Pozwala uŜytkownikowi pracować na dokumencie XML w postaci drzewiastej bez konieczności 1

Oczywiście, w niektórych przypadkach JDOM nie jest dobrym zamiennikiem większego interfejsu DOM; nie jest obsługiwany przez róŜne języki programowania i nie udostępnia ściśle określonej reprezentacji drzewiastej oferowanej przez DOM. Jednak przynajmniej w 80% przypadków JDOM potrafi rozwiązać problemy programistów związane z obróbką XML-a.

JDOM — kolejny API?

182

stosowania specyficznych rozwiązań typowych dla DOM-a. Jednocześnie jest tak wydajny jak SAX — przetwarza i zwraca wynik bardzo szybko. Jest „świadomy” przestrzeni nazw, obsługuje sprawdzanie poprawności poprzez DTD (i będzie obsługiwał schematy, gdy specyfikacja XML Schema zostanie sfinalizowana) i nigdy nie zwraca obiektów w formie NodeList lub Attributes; zamiast tego zwracane są klasy zbiorowe Java 2, takie jak List i Map. W pełni obsługiwane są dodatkowe implementacje, ale sam JDOM składa się z konkretnych (nieabstrakcyjnych) klas, a więc do stworzenia elementów, atrybutów, komentarzy i innych konstrukcji JDOM nie jest potrzebna informacja o producencie.

Spowalnianie specyfikacji To dobrze, Ŝe standardy takie jak DOM i SAX są tak rzetelnie weryfikowane przez — odpowiednio — konsorcjum W3C oraz Davida Megginsona i społeczność XML. Jednak często pomiędzy opublikowaniem kolejnych wersji mija duŜo czasu. Ponadto coraz większe zainteresowanie oprogramowaniem open source i umoŜliwienie publicznego dostępu (i niejednokrotnie moŜliwości modyfikacji) kodu wymaga przyspieszenia procesu weryfikacji i tworzenia jak najświeŜszych specyfikacji związanych z Javą i XML-em. JDOM, będący w całości oprogramowaniem typu open source, to krok w kierunku przyspieszenia wdraŜania standardów i specyfikacji. Na przykład JDOM juŜ teraz obsługuje przestrzenie nazw XML we wszystkich obiektach Document (nawet jeśli Document został zbudowany za pomocą parsera nie znającego przestrzeni nazw!). JDOM zostanie równieŜ wkrótce przeniesiony do serwera CVS z dostępem publicznym. To umoŜliwi modyfikowanie kodu, lepsze jego zrozumienie oraz prostsze aktualizacje. JDOM będzie nieustannie ewoluował w kierunku rozwiązania odpowiadającego większości programistów Javy korzystających z XML-a (serwer CVS JDOM-a juŜ działa — przyp. tłum.).

Zoptymalizowany pod kątem Javy JuŜ wspomnieliśmy, Ŝe JDOM to pełny interfejs API oparty na Javie 2, korzystający z klas zbiorowych. Na razie nie ma planów przeniesienia JDOM na inny język; nie jest to więc interfejs standardowy w zakresie obsługi wielu języków, ale za to istotnie zwiększa funkcjonalność w samej Javie, a taki właśnie był cel projektu. Podstawowe klasy JDOM oparte są na języku Java 2, co umoŜliwiło korzystanie z klas Collection i „słabych” odwołań; dostępna jest jednak równieŜ wersja JDK 1.1. Interfejs JDOM został zaprojektowany z myślą o programiście. Jest prosty w nauce i w zastosowaniu, poniewaŜ utrzymuje zgodność ze sprawdzonymi wzorcami projektowymi Javy. Konstrukcje JDOM (elementy, komentarze, atrybuty itd.) tworzone są w wyniku budowania egzemplarzy obiektów. Dokument XML (jak i dowolny inny) moŜe być postrzegany jako jedna całość i kaŜdy element dokumentu jest przez cały czas dostępny. Tworzenie, usuwanie i modyfikację fragmentów danych XML przeprowadza się za pomocą prostych metod. Obsługę wejścia i wyjścia zapewniają klasy Javy (URL, InputStream, OutputStream, File itd.). Próba unowocześnienia interfejsów SAX i DOM zabrałaby z pewnością więcej czasu aniŜeli stworzenie zupełnie nowego rozwiązania. W pozostałej części rozdziału zostanie omówione to właśnie nowe rozwiązanie — Czytelnik dowie się, jak korzystać z niego w celu manipulacji danymi XML z poziomu Javy.

Uzyskiwanie dokumentu

183

Uzyskiwanie dokumentu Pierwszym zadaniem, jakie zawsze naleŜy wykonać przy korzystaniu z JDOM-a, jest uzyskanie obiektu JDOM Document. Obiekt ten stanowi podstawową klasę JDOM, reprezentującą dokument XML. Jak wszystkie inne obiekty w modelu JDOM, klasa org.jdom.Document została opisana w dodatku A; wymieniono tam równieŜ sygnatury metod. Pod adresem http:// www.jdom.org dostępna jest teŜ pełna dokumentacja Javadoc.

Istnieją dwa sposoby uzyskania obiektu JDOM Document: utworzenie obiektu od podstaw (kiedy nie ma potrzeby odczytywania istniejących danych XML) lub zbudowanie go z istniejących danych XML.

Tworzenie dokumentu od podstaw Kiedy nie ma potrzeby pobierania istniejących danych, tworzenie dokumentu JDOM Document ogranicza się do wywołania konstruktora: Document doc = new Document(new Element("root));

Jak wspomnieliśmy wcześniej, JDOM to zestaw konkretnych klas, a nie interfejsów. Nie trzeba więc korzystać z bardziej zawiłego kodu związanego z konkretnymi producentami i koniecznego do stworzenia obiektu org.w3c.dom.Element. Wystarczy wykonać operację new na obiekcie Document — powstaje poprawny obiekt JDOM Document, gotowy do uŜytkowania. Document nie jest teŜ związany z Ŝadnym konkretnym parserem. Dane XML często tworzy się z pustego szablonu, a nie z istniejących danych i JDOM udostępnia nam w tym zakresie konstruktor dla org.jdom.Document, wymagający tylko podania głównego elementu Element jako parametru. W przykładzie 8.3 powstaje właśnie taki dokument XML od podstaw. import org.jdom.Document; import org.jdom.Element; /** *

* Tworzenie obiektu JDOM Document od zera *

* * @version 1.0 */ public class FromScratch { /** *

* Tworzymy prosty dokument XML w pamięci *

*/ public static void main(String[] args) { Document doc = new Document(new Element("root")); System.out.println("Dokument został utworzony"); } }

Uzyskiwanie dokumentu

184

Ten fragment kodu tworzy nowy obiekt JDOM Document z elementem głównym (Element o nazwie „root”). Document ten moŜe potem zostać przetworzony w pamięci i wyprowadzony na strumień wyjściowy.

Budowanie obiektu Document z XML-a Częściej jednak korzystamy z pewnych danych wejściowych i dopiero te przekształcamy w obiekt Document. Jest to równie proste. PoniewaŜ dokumenty JDOM mogą powstawać z wielu źródeł, udostępniony został oddzielny pakiet z klasami tworzącymi obiekt JDOM Document z róŜnych formatów wejściowych. W pakiecie tym, org.jdom.input, zdefiniowano interfejs Builder, którego metody przedstawione są w przykładzie 8.4.

Przykład 8.4. Interfejs org.jdom.input.Builder public interface Builder { // Tworzenie obiektu JDOM Document z InputStream public Document build(InputStream in) throws JDOMException; // Tworzenie obiektu JDOM Document z File public Document build(File file) throws JDOMException; // Tworzenie obiektu JDOM Document z URL public Document build(URL url) throws JDOMException; }

Programista otrzymuje mechanizm do tworzenia obiektu JDOM Document na podstawie róŜnych źródeł i budowania róŜnych implementacji dla róŜnych formatów wejściowych. Obecnie JDOM udostępnia dwie takie implementacje, SAXBuilder i DOMBuilder2. UmoŜliwiają one wykorzystanie istniejących obecnie standardowych parserów bez konieczności wprowadzania w nich Ŝadnych zmian.

SAXBuilder Budowanie dokumentu JDOM z istniejącego źródła danych XML za pomocą klasy org.jdom.input.SAXBuilder jest całkiem proste. Konstruktor SAXBuilder pobiera dwa opcjonalne parametry — nazwę klasy parsera SAX do wykorzystania (powinna ona implementować org.xml.sax.XMLReader) oraz znacznik informujący, czy ma nastąpić sprawdzanie poprawności. Jeśli Ŝadnego parametru nie podano, wykorzystywany jest parser domyślny (obecnie Apache Xerces), a sprawdzanie poprawności nie odbywa się. Stwórzmy prostą klasę SAXTest, pobierającą plik z wiersza poleceń i tworzącą obiekt JDOM Document na podstawie pliku i za pomocą klasy SAXBuilder: import java.io.File; import org.jdom.Document; import org.jdom.Element; 2

Być moŜe w czasie, kiedy ksiąŜka trafi do rąk Czytelników, w interfejsie JDOM 1.0 będą istniały dodatkowe implementacje Builder. Podstawowy interfejs 1.0 jest juŜ „zamroŜony”, ale pakiety pomocnicze (org.jdom.input, org. jdom.output i org.jdom.adapters) — nie. MoŜliwe jest więc, Ŝe w czasie powstawania ksiąŜki pojawią się nowe implementacje (w czasie tłumaczenia, w styczniu 2001 r., wciąŜ istniały tylko dwie wspomniane implementacje interfejsu Builder — przyp. tłum.).

Uzyskiwanie dokumentu

185

import org.jdom.JDOMException; import org.jdom.input.Builder; import org.jdom.input.SAXBuilder; public class SAXTest { public static void main(String[] args) { if (args.length != 1) { System.out.println("UŜycie: SAXTest [plik do przetworzenia]"); return; } try { // Budowanie dokumentu bez sprawdzania poprawności Builder builder = new SAXBuilder(false); Document doc = builder.build(new File(args[0])); System.out.println("Dokument został odczytany"); } catch (JDOMException e) { e.printStackTrace(); } } }

Proste, prawda? SAXBuilder obsługuje wszystkie zawiłości związane z tworzeniem róŜnych klas procedur obsługi SAX, rejestrowaniem ich w implementacji XMLReader i budowaniem obiektu JDOM Document. Przypomina to sposób, w jaki wiele parserów DOM buduje obiekt DOM Document za pomocą parsera SAX; jednak w celu uproszczenia interfejs SAXBuilder w JDOM-ie obsługuje wszystkie wyjątki SAXException i konwertuje je na JDOMException. Kod SAX pozostaje odizolowany od procesu tworzenia obiektu Document, a JDOM gwarantuje, Ŝe przekonwertowane wyjątki zawierają informacje o specyficznych problemach, jakie wystąpiły w procesie przetwarzania (wraz z wierszem, w którym wystąpiły).

DOMBuilder Klasa org.jdom.input.DOMBuilder działa niemal tak samo jak SAXBuilder. Z jej pomocą równieŜ moŜemy uzyskać obiekt JDOM Document, ale tym razem za pomocą modelu DOM i parsera DOM. PoniewaŜ specyfikacja DOM nie definiuje standardu interfejsu parsera, stworzono pakiet org.jdom.adapters, który udostępnia abstrakcyjną warstwę dla parserów określonych producentów i tym samym sposób utworzenia obiektu DOM Document. Konstruktor DOMBuilder pobiera znacznik wskazujący, czy ma nastąpić sprawdzanie poprawności, oraz nazwę klasy adaptera. MoŜe to być dowolna klasa (w tym zdefiniowana przez uŜytkownika), o ile tylko implementuje interfejs DOMAdapter zdefiniowany w org.jdom.adapters. Po stworzeniu DOMBuilder działa dokładnie tak jak SAXBuilder. Oto sposób tworzenia obiektu Document za pomocą interfejsu DOM: import java.io.File; import import import import import

org.jdom.Document; org.jdom.Element; org.jdom.JDOMException; org.jdom.input.Builder; org.jdom.input.DOMBuilder;

Uzyskiwanie dokumentu

186

public class DOMTest { public static void main(String[] args) { if (args.length != 1) { System.out.println("UŜycie: DOMTest [plik do przetworzenia]"); return; } try { // Budowanie dokumentu bez sprawdzania poprawności, parser Oracle Builder builder = new DOMBuilder("org.jdom.adapters.OracleV2DOMAdapter"); Document doc = builder.build(new File(args[0])); System.out.println("Dokument został odczytany"); } catch (JDOMException e) { e.printStackTrace(); } } }

Pakiet org.jdom.adapters został utworzony na potrzeby interfejsu JDOM, ale moŜe być równieŜ wykorzystany w aplikacjach korzystających tylko z DOM-a, jako elastyczna alternatywa dla JAXP-a. Oferuje on pełne oddzielenie od procesu przetwarzania DOM i umoŜliwia dostarczenie danych wejściowych jako InputStream lub w postaci nazwy pliku. Udostępnia takŜe znacznik informujący o sprawdzaniu poprawności. W wyniku działania pakietu zwracany jest gotowy obiekt DOM Document. Innymi słowy, tych klas moŜna uŜyć w aplikacji w celu zapobieŜenia konieczności importowania specyficznych dla DOM-a implementacji parsera. Co więcej, klasy adaptera wykorzystują refleksję, a więc nie wymagają obecności implementacji parsera w ścieŜce dostępu do klas w czasie kompilacji. To zapewnia całkowitą konfigurowalność i przenośność aplikacji, jeśli chodzi o zastosowany parser DOM.

Drzewo DOM tworzone jest za pomocą parsera Oracle V2 XML. Następnie w oparciu o to drzewo budowany jest obiekt JDOM Document. Aby wykorzystać parser domyślny, wystarczy wywołać Builder builder = new DOMBuilder(). Wszystkie obecne implementacje parsera DOM do tworzenia drzewa DOM faktycznie wykorzystują SAX. Dlatego korzystanie z interfejsu DOMBuilder w JDOM nie ma raczej sensu; zawsze proces ten będzie wolniejszy niŜ w przypadku zastosowania SAXBuilder (w obu przypadkach korzystamy z SAX-a), zawsze pochłonie teŜ więcej pamięci, poniewaŜ na czas konwersji na format JDOM musi w niej powstać pełny obraz drzewa DOM. DOMBuilder nie powinien być więc często wykorzystywany. Jego zasadnicza wartość leŜy w metodzie, jaką udostępnia do tworzenia obiektu JDOM Document z istniejącego drzewa DOM (np. uzyskanego jako dane wejściowe aplikacji z innej aplikacji, nie obsługującej JDOM-a). Metoda ta, build(org.w3c.dom.Document), jest opisana szczegółowo w dodatku A.

Po utworzeniu dokumentu JDOM Document dalsze działanie programu przebiega w zwykły sposób.

Korzystanie z obiektu Document

187

Korzystanie z obiektu Document Kiedy mamy juŜ obiekt Document (uzyskany albo poprzez bezpośrednie stworzenie egzemplarza, albo poprzez wykorzystanie którejś z klas wejściowych), moŜemy wykonywać na nim operacje niezaleŜnie od formatu czy interfejsu API. Nie ma dowiązań do SAX-a, DOM-a czy do oryginalnego formatu danych. Jak zobaczymy dalej, nie ma takŜe sprzęŜenia z formatem wyjściowym. Dowolny obiekt JDOM Document moŜe na wyjściu przybrać postać dowolnego poŜądanego formatu! Sam obiekt Document posiada metody do obsługi czterech składników, jakie moŜe przyjąć: DocType (określa zewnętrzną DTD lub udostępnia definicje wewnętrzne), ProcessingInstruction, Element główny i Comment. KaŜdy z tych obiektów odwzorowuje jakiś fragment XML-a. W ten sposób powstaje reprezentacja tych konstrukcji XML w Javie.

Obiekt DocType Obiekt JDOM DocType to prosta reprezentacja deklaracji DOCTYPE dokumentu XML. ZałóŜmy, Ŝe mamy następujący plik XHTML:

PoniŜszy kod wydrukuje element, publiczny identyfikator ID oraz systemowy identyfikator ID obiektu JDOM DocType odwzorowującego powyŜszą deklarację: DocType docType = doc.getDocType(); System.out.println("Element: " + docType.getElementName()); System.out.println("Public ID: " + docType.getPublicID()); System.out.println("System ID: " + docType.getSystemID());

Wynik działania kodu wygląda następująco: Element: html Public ID: -//W3C//DTD XHTML 1.0 Transitional//EN System ID: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd

Interfejs JDOM 1.0 pozwala na odwoływanie się do zewnętrznych definicji DTD, ale nie umoŜliwia jeszcze wplatania definicji zawęŜeń (definicje „inline”). Obsługa ta zostanie prawdopodobnie dodana przy okazji kolejnej mniejszej zmiany numeru wersji JDOM. Obiekt DocType moŜe zostać utworzony z nazwą zawęŜanego elementu (zazwyczaj elementu głównego dokumentu); moŜliwe jest teŜ podanie publicznego identyfikatora określającego połoŜenie zewnętrznej definicji DTD. Odwołanie do obiektu Document wyglądałoby następująco: Document doc = new Document(new Element("cos:tam")); doc.setDocType(new DocType( "html", "-//W3C//DTD XHTML 1.0 Transitional//EN", "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"));

Jeśli JDOM Document konstruowany jest z istniejących danych XML, obiekt DocType jest tworzony automatycznie przez wybraną implementację Builder.

Korzystanie z obiektu Document

188

Instrukcje przetwarzania Instrukcje PI w dokumencie XML reprezentuje w Javie klasa ProcessingInstruction, udostępniająca proste akcesory i mutatory. Listę wszystkich instrukcji przetwarzania3 w Document uzyskamy za pomocą następującego kodu: // Pobierz wszystkie PI List pis = doc.getProcessingInstructions(); // Przeanalizuj je wszystkie po kolei, drukując cel i dane for (int i=0, size=pis.size(); i
MoŜna równieŜ pobrać listę wszystkich instrukcji PI zawierających określony cel. SłuŜy do tego metoda getProcessingInstructions(String target). Instrukcje PI tworzymy poprzez podanie celu i danych do konstruktora ProcessingInstruction: ProcessingInstruction pi = new ProcessingInstruction("cocoon-process", "type=\"xslt\"");

PowyŜszy fragment kodu spowodowałby utworzenie następującej instrukcji PI:

Istnieje szereg metod pomocniczych. Bardzo często dane do instrukcji przetwarzania dostarcza się w postaci par nazwa-wartość:

MoŜliwe jest wprowadzenie takich par za pomocą klasy ProcessingInstruction i wartości Map: Map map = new HashMap(); map.put("href", "XSL\\JavaXML.wml.xsl"); // znosimy specjalne znaczenie "\" map.put("type", "text/xsl"); map.put("media", "wap"); ProcessingInstruction pi = new ProcessingInstruction("xml-stylesheet", map);

Klasa ProcessingInstruction udostępnia równieŜ metody pozwalające na pobieranie danych z instrukcji PI w formacie par nazwa-wartość. Podstawową metodą jest getValue(). Pobiera ona nazwę z pary nazwa-wartość i zwraca odpowiednią wartość lub pusty String, jeśli odpowiednia para nie została znaleziona. Na przykład poniŜszy kod pozwala określić typ nośnika (medium) dla przedstawionej wyŜej instrukcji xml-stylesheet: String mediaType = pi.getValue("media");

Powinien zostać zwrócony String „wap”, który moŜe potem zostać wykorzystany w aplikacji. PoniewaŜ dane PI nie muszą mieć postaci par nazwa-wartość, istnieje równieŜ metoda getDa-

3

Interfejs JDOM obsługuje obiekty ProcessingInstruction zagnieŜdŜone w obiektach Element, umieszczonych w obiekcie Document. Te zagnieŜdŜone PI nie zostaną zwrócone przez metody poziomu obiektu Document; poniewaŜ zagnieŜdŜone instrukcje przetwarzania są stosunkowo rzadko spotykane, nie będziemy ich tutaj omawiać.

Korzystanie z obiektu Document

189

ta(), zwracająca obiektowi ProcessingInstruction zwykły String. Dodanie ProcessingInstruction do obiektu JDOM Document moŜe zostać wykonane na wiele sposobów: Document doc = new Document(new Element("root")); .addProcessingInstruction( new ProcessingInstruction("instrukcja-1", "jeden sposób")) .addProcessingInstruction("instrukcja-2", "wygodniejszy sposób");

Instrukcje PI dodaliśmy za pomocą metody: addProcessingInstruction(ProcessingInstruction pi)

(podając utworzony obiekt ProcessingInstruction) albo przy uŜyciu wygodniejszej metody: addProcessingInstruction(String target, String data)

wykonującej to samo zadanie z wykorzystaniem podanych danych.

Elementy NajwaŜniejszymi informacjami w obiekcie Document są zawarte w nim dane, znajdujące się w elementach. Klasa JDOM Element stanowi reprezentację jednego takiego elementu. Zapewnia dostęp do wszystkich znajdujących się w nim danych. Egzemplarz JDOM Element „zna” przestrzenie nazw, dlatego kaŜdą metodę operującą na klasie Element i jego obiektach Attribute moŜna wywołać za pomocą zwykłej nazwy w postaci String lub lokalnej nazwy String odwołania do obiektu Element i Namespace (o tym za chwilę). Innymi słowy, w egzemplarzu Element mamy dostępne następujące metody: // Tworzenie elementu Element element = new Element("nazwaElementu"); // Tworzenie elementu z przestrzenią nazw Element element = new Element ("nazwaElementu", Namespace.getNamespace( "JavaXML", "http://oreilly.com/catalog/javaxml/")); // Dodanie atrybutu element.addAttribute("nazwaAtrybutu"); element.addAttribute("nazwaAtrybutu", Namespace.getNamespace( "JavaXML", "http://oreilly.com/catalog/javaxml/")); // Wyszukiwanie atrybutu o podanej nazwie List attributes = element.getAttributes("poszukiwanaNazwa");

Element główny dokumentu pobierany jest z obiektu JDOM Document za pomocą doc.getRootElement(). KaŜdy Element posiada metody udostępniające jego elementy potomne (metoda getChildren()). Dla wygody klasa Element udostępnia szereg wariacji metody getChildren() — pobieranie specyficznego elementu z wykorzystaniem jego przestrzeni nazw i nazwy lokalnej, pobieranie wszystkich elementów o określonej nazwie w domyślnej przestrzeni nazw oraz pobieranie wszystkich zagnieŜdŜonych elementów bez względu na nazwę: public class Element { // Pobierz wszystkie zagnieŜdŜone obiekty Element tego elementu public List getChildren(); // Pobierz wszystkie zagnieŜdŜone obiekty Element o określonej nazwie // (w domyślnej przestrzeni nazw)

Korzystanie z obiektu Document

190

public List getChildren(String name); // Pobierz wszystkie zagnieŜdŜone obiekty Element o określonej nazwie // i przestrzeni nazw public List getChildren(String name, Namespace ns); // Pobierz Element o określonej nazwie - jeśli istnieje wiele elementów // o tej nazwie, zwróć pierwszy public Element getChild(String name) throws NoSuchElementException; // Pobierz Element o określonej nazwie - jeśli istnieje wiele elementów // o tej nazwie, zwróć pierwszy public Element getChild(String name, Namespace ns) throws NoSuchElementException; // Inne metody

}

Wersje pobierające określony Element mogą zgłosić wyjątek NoSuchElementException, a jeśli zwracana jest lista List — mogą zwrócić listę pustą. Elementy potomne moŜna pozyskiwać poprzez podanie nazwy (z lub bez przestrzeni nazw); moŜna teŜ pobrać wszystkie „potomki” bez względu na nazwę. Pierwszy sposób wymaga wywołania metody getChild(), a drugi — metody getChildren(). Przyjrzyjmy się następującemu dokumentowi XML:

Enligtenment 0.16.2

KWM dla KDE 1.1.2

Sound Blaster Platinum 7 0

Kiedy — podobnie jak w tym przykładzie — struktura dokumentu znana jest z wyprzedzeniem, specyficzny Element, łącznie z jego wartością, moŜe zostać w prosty sposób pobrany z obiektu JDOM Document: Element root = doc.getRootElement(); String menedzerOkien = root.getChild("gui") .getChild("menedzer-okien") .getChild("nazwa") .getContent();

Korzystanie z obiektu Document

191

String przerwanieKarty = root.getChild("dzwiek") .getChild("karta") .getChild("irq") .getContent();

NaleŜy zauwaŜyć, Ŝe w tym wypadku zwrócony zostanie tylko pierwszy element o nazwie menedzer-okien — takie jest domyślne zachowanie metody getChild(String name). Aby pobrać wszystkie elementy o danej nazwie, naleŜy zastosować metodę getChildren(String name): List menedzeryOkien = root.getChild("gui") .getChildren("menadzer-okien");

Kiedy Element zawiera dane tekstowe, mogą one zostać pobrane za pomocą metody getContent(), tak jak w poprzednim przykładzie. Kiedy zawiera tylko elementy potomne, moŜna pobrać je za pomocą metody getChildren(). W raczej rzadko spotykanym przypadku, gdy Element posiada zarówno zawartość tekstową, jak i elementy potomne, a nawet komentarze, mówi się, Ŝe element ma zawartość mieszaną (ang. mixed content). Zawartość mieszaną dokumentu moŜna pobrać za pomocą metody getMixedContent(). Metoda ta zwraca listę zawartości zawierającą obiekty String, Element, ProcessingInstruction i Comment. Z technicznego punktu widzenia, metoda getContent() zwraca dane typu String zawarte w obiekcie Element. Te dane mogą się róŜnić od faktycznej zawartości elementu. Co więcej, metoda getChildren() zwraca tylko zagnieŜdŜone Elementy, a nie wszystkie obiekty potomne Elementu. Zadanie pobrania całej zawartości elementu wykonuje bardziej skomplikowana metoda getMixedContent(). To upraszcza manipulację plikami XML z punktu widzenia Javy — nie trzeba wykonywać operacji instanceof na wszystkich rezultatach zwracanych przez metody. Nazwy metod nie są więc moŜe technicznie precyzyjne, ale za to odpowiadają „intuicyjnemu” zachowaniu programistów.

Elementy są często dodawane do innych przy uŜyciu metody addChild(Element). MoŜna dodać wiele elementów naraz: element .addChild(new Element("synek").setContent("czyste zloto")) .addChild(new Element("corka").setContent("diabel wcielony") .addChild(new Element("wnuczek")) );

Taki skrótowy zapis jest moŜliwy, poniewaŜ addChild() zwraca Element, do którego dodano element. NaleŜy bardzo uwaŜnie wstawiać nawiasy. W przeciwnym razie to, co miało być rodzeństwem, moŜe okazać się rodzicem i dzieckiem! Elementy potomne usuwa się za pomocą metod removeChild() i removeChildren(), przyjmujących takie same parametry jak getChild() i getChildren(). Elementy konstruowane są poprzez podanie nazwy. Obecność przestrzeni nazw wymagała utworzenia czterech róŜnych konstruktorów: // Pobierz odwołanie do przestrzeni nazw Namespace ns = Namespace.getNamespace( "JavaXML", "http://oreilly.com/catalog/javaxml/");

Korzystanie z obiektu Document

192

// Utwórz element JavaXML:Ksiazka Element element1 = new Element("Ksiazka", ns); // Utwórz element JavaXML:Ksiazka Element element2 = new Element("Ksiazka", "JavaXML", "http://oreilly.com/catalog/javaxml/"); // Utwórz element Ksiazka Element element3 = new Element("Ksiazka", "http://oreilly.com/catalog/javaxml/"); // Utwórz element Ksiazka Element element4 = new Element("Ksiazka");

Pierwsze dwa egzemplarze Element, element1 i element2, posiadają równoznaczne nazwy, jako Ŝe klasa Element obsłuŜy składowanie podanej nazwy i przestrzeni nazw. Trzeci egzemplarz, element3, przypisywany jest domyślnej przestrzeni nazw i przestrzeń ta opisywana jest identyfikatorem URI. Czwarty egzemplarz tworzy Element bez przestrzeni nazw. Zawartość elementu ustawiana jest za pomocą metody setContent(String content). Jej wywołanie powoduje nadpisanie istniejącej zawartości elementu, w tym elementów potomnych. Aby dodać String jako „dodatkowy fragment” mieszanej zawartości elementu, korzystamy z metody addChild(String content). Bardzo przydatną cechą interfejsu JDOM jest moŜliwość dodawania i usuwania elementów poprzez dokonywanie zmian w liście zwróconej z wywołania getChildren(). PoniŜej usuniemy ostatnie „niegrzeczne dziecko” (i w ten sposób damy przykład innym): // Pobierz element główny Element root = doc.getRootElement(); // Pobierz wszystkie "niegrzeczne" potomki List niedobreDzieci = roog.getChildren("niegrzeczne"); // Pozbądź się ostatniego niegrzecznego dziecka if (niedobreDzieci.size() > 0) { niedobreDzieci.remove(niedobreDzieci.size()-1); }

Klasy zbiorowe Javy 2 udostępniają szybkie metody sortowania, a więc chociaŜ metody działające na obiektach JDOM są wygodne w uŜyciu, w zaawansowanych aplikacjach warto przetwarzać obiekty List bezpośrednio. Teraz moŜemy zająć się dodaniem odwzorowania przestrzeni nazw do obiektu Document oraz dodaniem i udostępnieniem atrybutów.

Przestrzenie nazw Zalecenie odnośnie przestrzeni nazw w XML-u definiuje odwzorowanie przedrostków na identyfikatory URI. Aby moŜna było korzystać z przedrostka przestrzeni nazw, musi on zostać odwzorowany na identyfikator poprzez atrybut xmlns:[przedrostek]. Odwzorowanie to w JDOMie odbywa się automatycznie przy tworzeniu danych wyjściowych. Czytelnik juŜ wie, Ŝe przestrzenie nazw XML obsługiwane są poprzez klasę org.jdom.Namespace: Namespace ns = Namespace.getNamespace("przedrostek", "uri");

Korzystanie z obiektu Document

193

Obiekt ns moŜe zostać następnie wykorzystany przez obiekty Element i Attribute. Ponadto klasa Namespace utworzy nowe obiekty w razie potrzeby; zaŜądanie istniejącej przestrzeni nazw zwróci odwołanie do istniejącego obiektu.

Atrybuty Do pobrania atrybutu elementu słuŜy metoda getAttribute(String name). Metoda ta zwraca obiekt Attribute, którego wartość pobierana jest za pomocą getValue(). W poniŜszym kodzie pobierany jest atrybut „rozmiar” danego elementu: element.getAttribute("rozmiar").getValue();

Dostęp do atrybutu jako specyficznej wartości moŜna uzyskać za pomocą dodatkowych metod: getIntValue(), getFloatValue(), getBooleanValue() i getByteValue(). Metody te zwracają DataConversionException, jeśli wartość nie istnieje lub nie moŜe zostać przekonwertowana na Ŝądany typ. Metody te mają równieŜ swoje odpowiedniki umoŜliwiające przekazanie wartości domyślnej, która zostanie zwrócona zamiast zgłaszania powyŜszego wyjątku w razie niemoŜności przeprowadzenia konwersji. PoniŜszy fragment pobiera rozmiar jako int, a zwraca 0, jeśli nie moŜna przeprowadzić konwersji: element.getAttribute("rozmiar") .getIntValue(0);

Dodanie atrybutów do elementu jest równie proste. Atrybut moŜe zostać dodany za pomocą metody addAttribute(String name, String value) lub za pomocą bardziej formalnej metody addAttribute(Attribute attribute). Konstruktor Attribute pobiera nazwę atrybutu do utworzenia (jako parametr String lub przedrostek przestrzeni nazw i nazwę lokalną) oraz wartość, jaką naleŜy przypisać utworzonemu atrybutowi: doc.getRootElement() .addAttribute("kernel", "2.2.14") // prosty sposób .addAttribute("new Attribute("dist", "Red Hat 6.1)); // formalny sposób

Komentarze Obiekt JDOM Comment reprezentuje dane nie stanowiące funkcjonalnych informacji obiektu Document, a słuŜące jedynie do podwyŜszenia czytelności programu. W XML-u informacje takie oznacza się . Komentarze w JDOM reprezentowane są przez klasę Comment; egzemplarze tworzone są na poziomie dokumentu lub jako elementy potomne. Innymi słowy, zarówno obiekt JDOM Document, jak i elementy mogą posiadać komentarze. Aby uzyskać komentarze dokumentu, naleŜy zastosować getContent(), zwracającą listę zawierającą wszystkie obiekty Comment dokumentu, jak równieŜ element główny. Komentarze umieszczone przed elementem głównym pojawią się na liście przed elementem głównym; a te po nim — znajdą się w dalszym miejscu listy. Aby uzyskać komentarze dla danego Elementu, naleŜy wywołać metodę getMixedContent(), która zwraca wszystkie obiekty Comment, Element i String (dane tekstowe), zagnieŜdŜone wewnątrz elementu i w takiej kolejności, w jakiej występują w dokumencie. ZałóŜmy, Ŝe mamy następujący plik XML: Java i XML

Dokument wyjściowy

194

Czytamy sobie spis treści!

Zazwyczaj komentarze nie są uŜywane przez aplikację. Gdyby jednak zaszła taka potrzeba, poniŜszy kod pozwoli nam je „wyciągnąć” z dokumentu: List docContent = doc.getContent(); List elemContent = root.getMixedContent(); for (int i=0, size=docContent.size(); i
Konstruktor Comment jako jedyny argument pobiera tekst komentarza. Obiekt Document umoŜliwia dodawanie komentarzy metodą addComment(Comment), a klasa Element udostępnia do tego samego celu metodę addChild(Comment): // Utwórz komentarz Comment docComment = new Comment("Komentarz na najwyŜszym (głównym) poziomie"); // Dodaj komentarz do obiektu Document doc.addComment(docComment); // Utwórz jeszcze jeden komentarz Comment elemComment = new Comment("Komentarz zagnieŜdŜony w elemencie"); // Dodaj komentarz do elementu doc.getRootElement() .getChild("Spis") .addChild(elemComment);

Dokument wyjściowy Proces uzyskiwania wyjściowego obiektu JDOM Document jest jeszcze prostszy niŜ jego tworzenie. Uzyskanie takiego obiektu dla róŜnych źródeł umoŜliwia pakiet klas narzędziowych i pomocniczych org.jdom.output. Nie ma interfejsu do definiowania wymaganego zachowania, poniewaŜ dane wyjściowe mogą zostać wykorzystane na rozmaite sposoby — od prostego zapisania do pliku aŜ po tak złoŜone zastosowania, jak np. powodowanie zdarzeń w innej aplikacji.

Dokument wyjściowy

195

Standardowe wyjście XML Najczęściej dane wyjściowe z obiektu JDOM Document przekazywane są jako kod XML do pliku lub innego składnika aplikacji za pomocą metody OutputStream. Oczywiście, strumień taki moŜe być skierowany na konsolę, do pliku, pod adres URL lub do dowolnego innego celu potrafiącego odbierać dane. Zadanie to obsługiwane jest w JDOM przez klasę org.jdom.output.XMLOutputter. Klasa ta udostępnia następujące konstruktory i metody: public class XMLOutputter { // Akceptujemy ustawienia domyślne: wcięcie 2 spacje, obecne znaki nowego wiersza public XMLOutputter() // Określamy wcięcie, akceptujemy domyślnie włączone znaki nowego wiersza public XMLOutputter(String indent); // Określamy wcięcie oraz to, czy znaki nowego wiersza mają być wstawiane public XMLOutputter(String indent, boolean newlines); // Wyrzucamy JDOM Document na wyjście public void output(Document doc, OutputStream out)throws IOException; }

Domyślny konstruktor zwraca „ładnie wydrukowany” obiekt JDOM Document; dzięki opcjom moŜna „ścisnąć” plik (wyłączyć znaki nowego wiersza i usunąć wcięcia). PoniŜej widoczna jest przedstawiana wcześniej klasa SAXTest, tym razem drukująca dokument na wyjście standardowe: import java.io.File; import java.io.IOException; import import import import import import

org.jdom.Document; org.jdom.Element; org.jdom.JDOMException; org.jdom.input.Builder; org.jdom.input.SAXBuilder; org.jdom.output.XMLOutputter;

public class SAXTest { public static void main(String[] args) { if (args.length != 1) { System.out.println("UŜycie: SAXTest [plik do przetworzenia]"); return; } try { // Budowanie dokumentu bez sprawdzania poprawności Builder builder = new SAXBuilder(false); Document doc = builder.build(new File(args[0])); printDocument(doc); } catch (JDOMException e) { if (e.getRootCause() != null) { e.getRootCause().printStackTrace(); } e.printStackTrace(); } catch (Exception e) { e.printStackTrace(); }

Dokument wyjściowy

196

} public static void printDocument(Document doc) throws IOException { XMLOutputter fmt = new XMLOutputter(); fmt.output(doc, System.out); } }

NaleŜy zauwaŜyć, Ŝe w metodach tworzących obiekty JDOM Document za pomocą SAXBuilder i DOMBuilder nie wykonaliśmy Ŝadnych operacji na danych; zbudowany Document jest od razu gotowy do wysłania na wyjście, co czyni proces odczytywania i zapisywania danych XML (np. z jednego źródła do drugiego) niezwykle prostym.

Uruchamianie zdarzeń SAX Poznaliśmy juŜ zastosowania JDOM — nawet gdy oryginalne dane XML są dostępne jedynie w postaci gotowego drzewa DOM; DOMBuilder konwertuje to drzewo na duŜo „lŜejszy” obiekt JDOM Document, a do operacji na danych XML moŜna wykorzystać interfejs JDOM API. W podobny sposób JDOM potrafi się komunikować z innymi aplikacjami, oczekującymi jako wejścia zdarzeń SAX. Klasa org.jdom.SAXOutputter umoŜliwia uruchamianie zdarzeń SAX z poziomu dostarczonego obiektu JDOM Document. Składniki aplikacji są więc całkowicie odizolowane — korzystamy z JDOM-a, ale nie tracimy interakcji z aplikacją nie znającą tego standardu (albo jeszcze nie znającą!). Co więcej, istnieje klasa DOMOutputter, umoŜliwiająca wykonanie tych samych zadań, ale przy konwersji dokumentu JDOM na drzewo DOM. Bardzo istotna jest elastyczność, jaką charakteryzują się obie klasy: nie są związane ze specyficznym formatem, tzn. umoŜliwiają wykorzystanie dowolnego źródła wejściowego i typu wyjściowego. Na przykład klasa ApacheOutputter moŜe słuŜyć do uzyskania obiektu wyjściowego Document stworzonego poprzez ApacheBuilder i zapisania go w postaci pliku konfiguracyjnego serwera Apache. Formaty wynikowe mogą być tak róŜne, jak róŜne są formaty wejściowe — JDOM to tylko model obiektowy, a nie specyficzny model XML.

JDOM w działaniu Przed nami bardziej kompletny przykład wykorzystania interfejsu JDOM. W przykładzie 8.5 przedstawiony jest „pakiet testowy” budujący od podstaw obiekt JDOM Document, korzystając zarówno z klasy SAXBuilder, jak i z DOMBuilder.

Przykład 8.5. Pakiet testowy JDOM import java.io.File; import java.io.IOException; import java.io.OutputStream; import import import import import import import import import import import

org.jdom.Attribute; org.jdom.Comment; org.jdom.DocType; org.jdom.Document; org.jdom.Element; org.jdom.JDOMException; org.jdom.Namespace; org.jdom.ProcessingInstruction; org.jdom.input.Builder; org.jdom.input.DOMBuilder; org.jdom.input.SAXBuilder;

Dokument wyjściowy import org.jdom.output.XMLOutputter; /** *

* Demonstruje budowanie obiektów JDOM Documents od zera i z istniejących * źródeł danych. *

* * @version 1.0 */ public class JDOMTest { public JDOMTest() { } /** *

* Buduje JDOM Document od zera *

* * @param out OutputStream tu zapisany utworzony XML * @throws IOException kiedy pojawi się błąd. */ public void newDocument(OutputStream out) throws IOException, JDOMException { Namespace ns = Namespace.getNamespace("linux", "http://www.linux.org"); Document doc = new Document(new Element("config", ns)) .setDocType(new DocType("linux:config", "DTD/linux.dtd")) .addProcessingInstruction("cocoon-process", "type=\"xsp\"") .addProcessingInstruction( new ProcessingInstruction("cocoon-process", "type=\"xslt\"")); doc.getRootElement() .addAttribute("kernel", "2.2.14") .addAttribute( new Attribute("dist", "RedHat 6.1")) .addChild(new Element("gui", ns) .setContent("Nie zainstalowano menadŜera okien")) .addChild(new Comment("Konfiguracja karty dźwiękowej")) .addChild(new Element("dzwiek") .addChild(new Comment("Karta Sound Blaster")) .addChild(new Element("karta") .addChild(new Element("nazwa") .setContent("Sound Blaster Platinum"))) ); XMLOutputter fmt = new XMLOutputter(); fmt.output(doc, out); } public void domDocument(File file, OutputStream out) throws IOException, JDOMException { Builder builder = new DOMBuilder(true); Document doc = builder.build(file);

197

Dokument wyjściowy XMLOutputter fmt = new XMLOutputter(); fmt.output(doc, out); } public void saxDocument(File file, OutputStream out) throws IOException, JDOMException { Builder builder = new SAXBuilder(true); Document doc = builder.build(file); XMLOutputter fmt = new XMLOutputter(); fmt.output(doc, out); } /** *

* Statyczny punkt wyjściowy do przeprowadzenia testu JDOM. *

*/ public static void main(String[] args) { if (args.length != 1) { System.out.println("UŜycie: JDOMTest [plik do przetworzenia]"); System.exit(-1); } try { JDOMTest test = new JDOMTest(); System.out.println( "\n\n----------------------"); System.out.println( "Testuję tworzenie dokumentu od zera..."); System.out.println( "----------------------\n\n"); test.newDocument(System.out);

System.out.println( "\n\n----------------------"); System.out.println( "Testuję odczytywanie dokumentu z DOM..."); System.out.println( "----------------------\n\n"); test.domDocument(new File(args[0]), System.out); System.out.println( "\n\n----------------------"); System.out.println( "Testuję odczytywanie dokumentu z SAX..."); System.out.println( "----------------------\n\n"); test.saxDocument(new File(args[0]), System.out); System.out.println( "\n\n----------------------"); System.out.println( "Test powiódł się. Zbudowano odpowiednie obiekty."); } catch (Exception e) { e.printStackTrace(); if (e instanceof JDOMException) { System.out.println(((JDOMException)e).getRootCause() .getMessage());

198

Dokument wyjściowy

199

} else { System.out.println(e.getMessage()); } } } }

Skompilujmy powyŜszy program i spójrzmy na zwracany wynik. Plik wynikowy z pobranych danych zostanie wyświetlony dwukrotnie (raz tworzony jest za pomocą SAX-a, a raz za pomocą DOM-a). Wcześniej jednak wyświetlane są dane XML stworzone „od zera”. W przykładzie 8.6 przedstawiony jest fragment wyniku działania programu.

Przykład 8.6. Wynik działania klasy JDOMTest $java JDOMTest contents.xml

---------------------Testuję tworzenie dokumentu od zera... ----------------------

Nie zainstalowano menedŜera okien Sound Blaster Platinum ---------------------Testuję odczytywanie dokumentu z DOM... ----------------------

Java i XML Wprowadzenie

Dokument wyjściowy

200

Co to jest? ... ---------------------Testuję odczytywanie dokumentu z SAX... ----------------------

Java i XML Wprowadzenie ...

Taki wynik został uzyskany po uruchomieniu programu testującego na pliku contents.xml, utworzonym we wcześniejszych rozdziałach. Element JavaXML:Dodatkowe (i elementy potomne) został opatrzony komentarzami, poniewaŜ definicja DTD nie pozwala na jego istnienie. Jeśli nie byłoby komentarzy, program zgłosiłby następujący komunikat o błędzie (kiedy przy tworzeniu egzemplarza SAXBuilder lub DOMBuilder zaŜądano by sprawdzania poprawności): org.jdom.JDOMException: Error in building from stream: Error on line 59 of XML document: Element type "JavaXML:Dodatkowe" must be declared. at org.jdom.input.DOMBuilder.build(DOMBuilder.java, Compiled Code) at org.jdom.input.DOMBuilder.build(DOMBuilder.java, Compiled Code) at JDOMTest.domDocument(JDOMTest.java, Compiled Code) at JDOMTest.main(JDOMTest.java, Compiled Code) Error on line 59 of XML document: Element type "JavaXML:Dodatkowe" must be declared.

Jedną z istotnych cech interfejsu JDOM jest diagnozowanie błędów — powyŜszy komunikat dostarcza szczegółowych informacji o błędach w danych wejściowych XML i tym samym upraszcza sprawdzanie ich poprawności. PoniewaŜ metody wejścia i wyjścia zajmują tylko cztery wiersze kodu (patrz domDocument() i saxDocument()), JDOM moŜe zostać wykorzystany właśnie do sprawdzania poprawności i formatowania dokumentów XML. Nadeszła pora, aby przypomnieć sobie programy SAXParserDemo i DOMParserDemo z rozdziałów 3. i 7. Oba te programy wyswietlały dokumenty XML pobrane z pliku wejściowego; SAXParserDemo udostępniał podgląd samego procesu przetwarzania, zaś DOMParserDemo to właściwie klasa „ładnie drukująca” dokument XML. Przykład 8.7 to kod źródłowy com.oreilly.xml.PrettyPrinter, klasy narzędziowej wykonującej to samo zadanie co DOMParserDemo, ale poprzez JDOM.

Dokument wyjściowy

UwaŜny Czytelnik mógł zauwaŜyć, Ŝe w powyŜszym kodzie nie zajęliśmy się sprawdzaniem poprawności ani przestrzeniami nazw. PoniewaŜ JDOM obsługuje przestrzenie nazw wewnętrznie (a nie polegając na informacjach dostarczanych przez DOM Level 2 czy SAX 2.0), sprawdzanie poprawności odbywa się przy jednoczesnej obsłudze przestrzeni nazw. JDOM faktycznie wyłącza „świadomość” przestrzeni nazw w klasach SAXBuilder i DOMBuilder! Nie tylko umoŜliwia to przeprowadzenie sprawdzania poprawności, ale takŜe przyspiesza przetwarzanie dokumentów XML.

Przykład 8.7. Klasa narzędziowa com.oreilly.xml.PrettyPrinter package com.oreilly.xml; import java.io.File; import import import import

org.jdom.Document; org.jdom.input.Builder; org.jdom.input.SAXBuilder; org.jdom.output.XMLOutputter;

/** * PrettyPrinter wyświetla dokument XML spod podanego URI * * @author Brett McLaughlin * @author Jason Hunter * @version 1.0 */ public class PrettyPrinter { /** *

* Ładnie drukuje XML danego URI *

*/ public static void main(String[] args) { if (args.length != 1) { System.out.println("UŜycie: " + "java com.oreilly.xml.PrettyPrinter [XML_URI]"); return; } String filename = args[0]; try { // Budowanie dokumentu z uŜyciem SAX i Xerces, bez sprawdzania poprawności Builder builder = new SAXBuilder(); // Tworzenie dokumentu (ze sprawdzaniem poprawności) Document doc = builder.build(new File(filename)); // Wyświetlenie dokumentu, standardowy program formatujący XMLOutputter fmt = new XMLOutputter(); fmt.output(doc, System.out); } catch (Exception e) { e.printStackTrace(); } } }

201

Co dalej?

202

Szybki przegląd interfejsu JDOM mamy juŜ za sobą. Czytelnik poznał jedynie ułamek jego moŜliwości. Pełna dokumentacja znajduje się w dodatku A — opisane są tam klasy i interfejsy DOM oraz dostępne w nich metody. Opisano tam równieŜ pakiety dodatkowe dla JDOM-a, org. jdom.adapters, org.jdom.input i org.jdom.output. Interfejsu JDOM będziemy uŜywali w przykładach w pozostałej części ksiąŜki. Wielokrotnie powrócimy teŜ do róŜnic pomiędzy interfejsami JDOM, SAX i DOM, aby w razie potrzeby Czytelnik umiał skorzystać z dowolnego z nich i aby na koniec sam wyrobił sobie opinię na temat ich przydatności. Najnowsza wersja JDOM i odpowiadająca jej dokumentacja Javadoc znajduje się pod adresami: http://www.jdom.org i http://www.newInstance.com.

Co dalej? W niniejszym rozdziale Czytelnik poznał interfejs JDOM. Znając równieŜ JAXP, moŜe przystąpić juŜ do tworzenia specyficznych aplikacji korzystających z XML-a. Nadal korzystając z interfejsów SAX, DOM i JDOM, w drugiej połowie ksiąŜki omówimy struktury publikacji WWW, aplikacje typu firma-firma, XML-RPC, Rich Site Summary (RSS), konfiguracje XML i szereg spokrewnionych z nimi zagadnień. Poznawane wiadomości pozwolą Czytelnikowi tworzyć nowe, bardziej efektywne aplikacje.

Wybór struktury

203

9 Struktury publikacji WWW Czytelnik poznał juŜ podstawy korzystania z XML-a z poziomu języka Java. Omówione zostały interfejsy SAX i DOM, umoŜliwiające manipulację i tworzenie danych XML. Czytelnik poznał równieŜ JDOM, udostępniający bardziej naturalny dla programistów Javy sposób korzystania z danych XML. Skoro Czytelnik wie juŜ, jak uŜywać języka XML z poziomu programów, pora zająć się konkretnymi aplikacjami. W następnych sześciu rozdziałach przedstawione zostaną najistotniejsze zastosowania języka XML i, co najwaŜniejsze, omówione zostaną sposoby implementowania tych aplikacji w Javie. Są dosłownie setki, a wkrótce będą tysiące waŜnych zastosowań języka XML, ale tutaj opiszemy tylko te najwaŜniejsze — te, które mogą zrewolucjonizować proces tworzenia oprogramowania. Jako pierwsze zostaną omówione aplikacje będące przedmiotem najgorętszych dyskusji w społecznościach XML-a i Javy — struktury publikacji WWW. Jak to juŜ zostało wspomniane, moŜliwość tworzenia prezentacji z zawartości jest raczej przereklamowana — duŜo waŜniejsza jest przenośność danych oferowana przez XML. Nie zmienia to jednak faktu, Ŝe XML świetnie nadaje się równieŜ do generowania wartości prezentacyjnej. Jest to cecha szczególnie istotna w aplikacjach WWW. Za pięć lat praktycznie dowolna duŜa aplikacja będzie albo całkowicie wykorzystywała moŜliwości WWW, albo będzie przynajmniej udostępniała „webowy” interfejs. UŜytkownicy domagają się coraz bogatszych zestawów funkcji, a działy marketingowe — coraz większej elastyczności w wyglądzie i zachowaniu aplikacji. Powstał nowy zawód — artysta WWW; to nie to samo co webmaster — nie musi dobrze znać Perla, ASP, JavaScriptu czy innych języków skryptowych. Cały dzień nic nie robi, tylko tworzy, modyfikuje i projektuje dokumenty HTML. Gwałtowne zmiany na rynku wymagają często kompletnej przebudowy witryny nawet raz w tygodniu, więc takie stanowisko jest bardzo potrzebne. Style kaskadowe (CSS) okazały się tutaj bardzo pomocne, ale i tak utrzymanie spójności wielu stron wymaga bardzo duŜo czasu. Taką sytuację na siłę moŜna by zaakceptować, ale na pewno Ŝaden programista nie chciałby spędzić całego Ŝycia na wprowadzaniu zmian w stronach HTML. Wraz z popularyzacją programów Javy uruchamianych po stronie serwera, ten problemstał się bardziej dokuczliwy. Twórcy serwletów długie godziny spędzają wyłącznie na poprawianiu instrukcji out.println() zwracających dane HTML. Ta sytuacja doprowadziła do powstania

Wybór struktury

204

specyfikacji Java Server Pages (JSP); jednakŜe JSP nie stanowi rozwiązania — przenosi jedynie cięŜar na programistę HTML-a, który cały czas musi unikać wprowadzania zmian w zagnieŜdŜonym w stronach kodzie Javy. Co więcej, w JSP nie ma obiecanego jednoznacznego oddzielenia warstwy danych i prezentacji. Oczekiwano więc sposobu generowania czystych danych i — później — nakładania jednolitego stylu o określonej porze (generowanie statyczne) lub bezpośrednio w czasie działania (dynamiczne generowanie zawartości). Czytelnik juŜ wie, Ŝe powyŜsze problemy rozwiązują technologie XSL i XSLT. Jest jednak pewien problem — aby generować zawartość, szczególnie dynamicznie, trzeba dysponować odpowiednim mechanizmem. Co z tego, Ŝe na serwerze mamy setki dokumentów XML, jeśli nie ma mechanizmu umoŜliwiającego przekształcenie ich do potrzebnej postaci. Jeśli dodamy do tego potrzebę istnienia serwletów i innych elementów znajdujących się po stronie serwera, umoŜliwiają tworzenie wynikowych danych XML, to otrzymujemy zespół wymagań określający właśnie strukturę publikacji WWW. W niniejszym rozdziale przyjrzymy się takim właśnie strukturom. Czytelnik będzie mógł przekonać się, Ŝe dzięki nim zniknie potrzeba „ślęczenia nad HTML-em”. „Artyści WWW” staną się specjalistami od XML-a i XSL-a, co na pewno wyjdzie im na dobre, zaś wygląd i zachowanie aplikacji będzie moŜna zmienić w dowolnej chwili i w dowolny sposób. Struktura publikacji WWW (ang. web publishing framework) stanowi rozwiązanie wszystkich opisywanych wyŜej problemów. Tak jak serwer WWW odpowiada na Ŝądanie pobrania pliku, struktura publikacji WWW odpowiada na Ŝądanie publikowanej wersji pliku. Publikowany plik (ang. published file) to plik przekształcony za pomocą XSLT, stworzony na poziomie aplikacji lub przekształcony z innego formatu (np. PDF). śądający nie widzi danych, z których powstał taki plik; nie musi równieŜ jawnie Ŝądać wykonania publikacji. Często z identyfikatora URI (np. http://naszHost.com/publish) wynika, Ŝe w serwerze WWW uruchomiony jest mechanizm publikacji. Jak moŜna podejrzewać, sama koncepcja jest duŜo prostsza niŜ faktyczna implementacja, a wybranie odpowiedniej struktury publikacji dla własnych potrzeb to wcale nie łatwe zadanie.

Wybór struktury Czytelnik z pewnością zaczyna juŜ doceniać znaczenie struktur publikacji. Rozwiązań jest jednak bardzo wiele. Język Java oferuje prosty sposób współpracy z rozmaitymi narzędziami XML wykorzystywanymi w strukturach publikacji. Serwlety Javy umoŜliwiają natomiast prostą obsługę Ŝądań i odpowiedzi WWW. Ale lista struktur publikacji jest krótka, a lista tych dobrych i stabilnych — jeszcze krótsza. Jednym z najlepszych zasobów informacji o tego typu oprogramowaniu jest lista XML Software dostępna pod adresem http://xmlsoftware.com/publishing. Ta lista zmienia się tak często, Ŝe nie warto jej tutaj przytaczać. Tym niemniej istnieje szereg istotnych kryteriów, którymi programista powinien się kierować przy wyborze struktury publikacji — i właśnie one zostaną tutaj omówione.

Stabilność Obecnie programiści mają problemy ze znalezieniem produktu w wersji o numerze wyŜszym niŜ 2.x. Mało tego — ze świecą trzeba szukać struktury publikacji nawet drugiej generacji! Oczywiście, wyŜszy numer wersji nie jest jeszcze gwarancją stabilności, ale często odzwierciedla ilość czasu, wysiłków i rzetelność testowania, jakiemu poddano daną strukturę. System publikacji XML to na tyle nowa technologia, Ŝe rynek zalewany jest produktami w wersjach 1.0 i 1.1 — często po prostu niewystarczająco stabilnymi do praktycznego uŜycia.

Wybór struktury

205

O stabilności produktu mogą równieŜ świadczyć inne, stabilne produkty tego samego producenta. Często producent wypuszcza cały pakiet narzędzi; jeśli inne narzędzia nie obsługują interfejsów SAX 2.0 i DOM Level 2 albo wszystkie są w wersjach 1.0 lub 1.1, to strukturę publikacji pochodzącą z takiego pakietu najlepiej na razie wykluczyć z wyboru i poczekać, aŜ nieco „dojrzeje” i będzie zgodna z nowszymi standardami XML. NaleŜy równieŜ unikać technologii przeznaczonych dla konkretnej platformy — jeśli struktura publikacji została scalona z konkretnym systemem (np. Windows), to nie jest to juŜ „czyste” rozwiązanie w Javie. Pamiętajmy, Ŝe struktura publikacji ma obsługiwać klientów ze wszystkich platform; dlaczego więc mamy zadowalać się produktem, który nie moŜe zostać uruchomiony na dowolnej platformie?

Integracja z innymi narzędziami i interfejsami XML Oprócz stabilności, struktura publikacji musi równieŜ obsługiwać róŜne parsery i procesory XML. Jeśli jest związana z konkretnym parserem lub procesorem, to tak naprawdę jest to XML-owa wersja Microsoftu — ograniczamy się do jednej konkretnej implementacji technologii. Struktury publikacji mogą dobrze „integrować się” z parserem konkretnego producenta, ale zawsze naleŜy sprawdzić, czy w razie potrzeby parser moŜna zmienić. Jeśli mamy jakiś ulubiony procesor (albo musimy korzystać z procesora przejętego po kimś razem z projektem), trzeba upewnić się, czy struktura z nim współpracuje. Obsługa interfejsów SAX i DOM to bezwzględna konieczność. Warto teŜ szukać takiej struktury, której producent monitoruje specyfikacje XML Schema, XLink, XPointer i inne technologie XML. Od takiego producenta moŜna oczekiwać poprawek struktury mających na celu obsłuŜenie tych nowych technologii; ponadto mamy gwarancję, Ŝe takiej publikacji nie będziemy musieli zmieniać przez długi czas. NaleŜy śmiało pytać o to, kiedy zostanie uruchomiona obsługa nowej specyfikacji.

WdroŜenia w środowiskach produkcyjnych Jedną z najwaŜniejszych przesłanek ułatwiających wybór struktury publikacji jest fakt zastosowania jej w aplikacjach produkcyjnych. Jeśli producent nie potrafi pokazać nam przynajmniej kilku aplikacji referencyjnych lub serwisów wykorzystujących określoną strukturę, to całkiem moŜliwe, Ŝe... po prostu takie nie istnieją. Producenci (oraz programiści z „branŜy” open source) uwielbiają chwalić się miejscami, w których ich aplikację moŜna zobaczyć w działaniu. Jeśli wyczuwamy tutaj pewne wahanie, to być moŜe aplikacja jest jeszcze zupełnie pionierska — a przecieŜ nie o to nam chodzi.

Podejmujemy decyzję Kiedy juŜ Czytelnik rozpatrzy wszystkie powyŜsze kryteria, wybór struktury publikacji nie będzie szczególnie trudny — tylko niewiele rozwiązań jest zgodnych z postawionymi wymaganiami, a dochodzą przecieŜ jeszcze wymogi naszej konkretnej aplikacji. W czasie pisania tej ksiąŜki struktury publikacji obsługujące najświeŜsze wersje SAX-a, DOM-a i JAXP-a, wdroŜone przynajmniej w jednej aplikacji produkcyjnej i mające za sobą przynajmniej trzy znaczące poprawki kodu, moŜna było policzyć na palcach jednej ręki. Nie wymieniamy ich tutaj, bo — co tu duŜo mówić — po pół roku mogą juŜ nie istnieć, mogą teŜ zostać zupełnie zmienione. Krajobraz struktur publikacji zmienia się tak gwałtownie, Ŝe próba rekomendacji tego czy tamtego produktu moŜe raczej przeszkodzić niŜ pomóc. JednakŜe jedna struktura publikacji nieustannie się sprawdza i jest szczególnie doceniana przez programistów Javy i XML-a. Struktura ta jest szczególnie istotna dla programistów pracujących na zasadach open source oraz piszących w Javie. Chodzi o projekt Apache Cocoon, zapoczątkowany

Instalacja

206

przez Stefano Mazzocchiego — od samego „poczęcia” niezwykle solidną strukturę publikacji. Została opracowana dość dawno, kiedy większość z nas próbowała rozgryźć, co to w ogóle jest ten XML. Cocoon, struktura publikacji oparta w całości na Javie, wchodzi juŜ w drugą fazę rozwoju. Stanowi część projektu Apache XML i domyślnie obsługuje Apache Xerces i Apache Xalan. Pozwala na uŜycie dowolnego standardowego parsera XML i wykorzystuje niezwykle popularną architekturę serwletów Javy. Jest wykorzystywana w wielu serwisach produkcyjnych (w wersji 1.x) i sprawuje się świetnie. Dlatego właśnie — a takŜe znów konsekwentnie wybierając oprogramowanie open source — w tej ksiąŜce wybieramy Apache Cocoon. W poprzednich rozdziałach kwestia wyboru parsera i procesora XML była w znacznym stopniu otwartą; przykłady wymagałyby tylko niewielkich modyfikacji w przypadku korzystania z innych implementacji. JednakŜe struktury publikacji WWW nie zostały znormalizowane — kaŜda z nich implementuje róŜne funkcje i konwencje. Dlatego opisane w niniejszym rozdziale przykłady wykorzystujące Apache Cocoon nie są przenośne; jednakŜe popularność koncepcji i wzorców projektowych zastosowanych w Apache Cocoon usprawiedliwiają poświęcenie całego rozdziału tej właśnie strukturze. Jeśli Czytelnik wybiera inną strukturę publikacji, to powinien przynajmniej przejrzeć opisane tutaj przykłady — ogólne koncepcje są na pewno przenośne, nawet jeśli kod będzie działał tylko w jednej implementacji.

Instalacja We wcześniejszych rozdziałach instrukcja instalacji ograniczała się do wskazania strony WWW, z której naleŜało pobrać oprogramowanie, oraz do przypomnienia o konieczności dodania odpowiedniego pliku jar do ścieŜki dostępu do klas. Instalacja struktury publikacji, takiej jak Cocoon, nie jest juŜ tak banalnym zadaniem, dlatego cała procedura została opisana szczegółowo. Jeśli chcemy uzyskać najświeŜszą wersję struktury, powinniśmy pobrać ją z systemu współbieŜnych wersji CVS. Będzie to kod prosto z repozytorium kodów źródłowych, a nie publikowana rzadziej wersja „oficjalna”. Oprogramowanie CVS moŜna pobrać spod adresu http://www.cyclic.com/cyclic-pages/howget.html. W tej ksiąŜce zajmiemy się wersją 1.x struktury Cocoon. Kiedy ksiąŜka będzie w sprzedaŜy, wersja beta 2.0 będzie juŜ prawdopodobnie dostępna (według informacji na stronie http://xml.apache.org/cocoon/cocoon2.html w czasie tłumaczenia ksiąŜki Cocoon 2.0 był wciąŜ w fazie „alfa” i twórcy stanowczo odradzali jego uŜycie w aplikacjach produkcyjnych — przyp. tłum.); jednak z powodu duŜych zmian planowanych w tej nowej generacji tutaj skupimy się na wersjach 1.x, obecnie uŜywanych najpowszechniej. Na końcu rozdziału zostaną pokrótce omówione nowe funkcje, jakie pojawią się w Cocoon 2. Jeśli w czasie instalacji czytelnik napotka problemy, moŜe skorzystać z zasobów online. Projekt Cocoon gości na stronach projektu Apache XML, pod adresem http://xml.apache.org. Dostępne są tam listy adresowe (http://xml.apache.org/mail.html), a takŜe bardzo przydatne odpowiedzi na najczęściej zadawane pytania FAQ (http://xml.apache.org/cocoon/faqs.html). Nie trzeba obawiać się zadawania pytań — instalacja złoŜonych struktur publikacji to niełatwe zadanie, a zawsze istnieje duŜa szansa, Ŝe ktoś juŜ przez to przebrnął i moŜe słuŜyć radą.

Instalacja

207

Korzystanie z narzędzia Ant Weterani systemów uniksowych i Linuksa znają na pamięć poniŜsze polecenia wykonywane przy kompilacji oprogramowania: /home/bmclaugh (mejis)> ./configure /home/bmclaugh (mejis)> make /home/bmclaugh (mejis)> make install

Współpraca kodu źródłowego i programów make oraz autoconf ma długie tradycje. Ale make nie współpracuje zbyt dobrze z kodem w Javie — uŜytkownicy Windows muszą korzystać z dodatkowych narzędzi przy kompilacji na tej platformie; uruchomienie dokumentacji Javadoc i innych dodatkowych poleceń wymaga długiego procesu konfiguracji; kompilacja RMI (rmic) jest takŜe złoŜona itd. Rozwiązanie świetnie spisujące się w przypadku Perla, skryptów powłoki czy kodu C, w zetknięciu z Javą traci na uŜyteczności. Na szczęście James Duncan Davidson (związany z projektami Jakarta, JAXP i specyfikacją serwletów) nie poprzestał na narzekaniu na make. Zapoczątkował projekt znany obecnie pod nazwą Ant i stanowiący część projektu Apache Jakarta. Ant to narzędzie do budowania oprogramowania oparte na Javie. Jego konfiguracja oparta jest na XML-u i jest to narzędzie niezaleŜne od platformy. Kompilacje RMI, Javadoc, polecenia zewnętrzne — wszystko to jest obsługiwane w tym jednym środowisku. Do „zbudowania” źródeł Cocoon posłuŜy nam właśnie Ant. Nowa wersja narzędzia Ant została zawarta w pakiecie Cocoon, w katalogu lib/. Ant moŜna równieŜ pobrać ze strony Jakarty, http://jakarta.apache.org. Sposób uŜycia Anta w przypadku oprogramowania Cocoon został zawarty w tym ostatnim; informacje bardziej ogólne znaleźć moŜna pod wymienionym adresem projektu Jakarta.

Uzyskanie pakietu Cocoon Kiedy narzędzie Ant mamy juŜ pod ręką, moŜemy pobrać źródła Cocoon 1.x. Oprócz moŜliwości pobrania ich ze stron projektu Apache XML (http://xml.apache.org), najświeŜszą wersję, wyposaŜoną we wszystkie nowe funkcje, znaleźć moŜna takŜe w systemie CVS. Jeśli Czytelnik dopiero zaczyna uŜywać oprogramowania Cocoon, moŜe skorzystać z pakietu przygotowanego do pobrania; jednak teraz juŜ Czytelnik zna kod Javy i XML-a, więc moŜe warto pobrać zupełnie najświeŜszą wersję 1.x.dev z repozytorium CVS. MoŜna to zrobić w następujący sposób: cvs -d :pserver:[email protected]:/home/cvspublic login Password: ******* (Haslo: 'anoncvs') cvs -d :pserver:[email protected]:/home/cvspublic checkout xml-cocoon

W katalogu xml-cocoon pojawi się najnowsza wersja oprogramowania Cocoon. Zawiera ona plik sterujący kompilacją przez Anta, wszystkie wymagane biblioteki i właściwe źródła. Wystarczy teraz przejść do tego katalogu i juŜ moŜna rozpocząć budowanie struktury Cocoon.

Budowanie struktury Cocoon Znajdujemy się w katalogu głównym oprogramowania Cocoon. Aby zbudować strukturę w systemie Windows, naleŜy wpisać następujące polecenie: D:\dev\xml-cocoon> build.bat

natomiast w systemach Unix i Linux: $ sh build.sh

Instalacja

208

Podkatalog lib/ zawiera wszystkie biblioteki konieczne do zbudowania projektu Cocoon. Skrypty instalacyjne dodadzą kaŜdy plik jar tego katalogu do ścieŜki dostępu do klas, zawierającej najnowsze wersje Apache Xerces, Apache Xalan i innych programów niezbędnych do prawidłowego działania Cocoon 1.x. Nawet jeśli Czytelnik juŜ ma te biblioteki (Xerces czy Xalan), zalecane jest zastosowanie tych dostarczonych z Cocoon — producent gwarantuje ich współpracę z wersją pobraną z CVS-u. Po skończeniu instalacji ścieŜka dostępu do klas będzie obejmowała następujące biblioteki: • JDK Tools: tools.jar • Jakarta Ant: ant.jar • Servlet API 2.2: servlet_2_2.jar • Apache Xerces: xerces_x_y_z.jar • Apache Xalan: xalan_x_y_z.jar • Apache FOP1: fop_x_y_z.jar • Apache Stylebook2: stylebook-x.y-z.jar Skrypt budujący informuje następnie narzędzie Ant, Ŝe projekt ma zostać zainstalowany z wykorzystaniem pliku build.xml, znajdującego się w bieŜącym katalogu. Po jego wykonaniu Czytelnik powinien uzyskać następujący wynik: Cocoon Build System ------------------Building with classpath lib/ant_1_1.jar:lib/bsf.jar:lib/bsfengines.jar:lib/fop_0_13_0.jar:lib/ servlet_2_2.jar:lib/stylebook-1.0-b2.jar:lib/turbine-pool.jar:lib/ xalan_1_2_D02.jar:lib/xerces_1_2.jar:/usr/local/jdk1.2.2/lib/tools.jar: Starting Ant... Buildfile: build.xml init: ------------------- Cocoon 1.8 [1999-2000] --------prepare: [mkdir] Created dir: /home/adam/cocoon-1.8/build prepare-projectx: prepare-xt: prepare-ecma: prepare-ldap: prepare-src: [mkdir] Created dir: /home/adam/cocoon-1.8/build/src [mkdir] Created dir: /home/adam/cocoon-1.8/build/classes [copydir] Copying 126 files to /home/adam/cocoon-1.8/build/src

1

2

Chodzi o ten sam procesor FOP (procesor obiektów formatujących), który został przedstawiony w rozdziale 6., Przekształcanie XML-a, przy okazji opisywania konwersji XML-a na formaty nietekstowe. Stylebook obsługuje tworzenie bardzo złoŜonych dokumentów (w tym w HTML-u); słuŜy do generowania dokumentacji i strony WWW Cocoon. Projekt Stylebook ma być zintegrowany z Cocoon w wersji 2.0.

Instalacja

209

compile: [javac] Compiling 108 source files to /home/adam/cocoon-1.8/build/classes [javac] Copying 18 support files to /home/adam/cocoon-1.8/build/classes package: [jar] Building jar: /home/adam/cocoon-1.8/build/cocoon.jar BUILD SUCCESSFUL Total time: 3 minutes 14 seconds

Uzyskany wynik moŜe się nieco róŜnić numerami wersji lub liczbą plików, ale nie powinny wystąpić Ŝadne błędy; jeśli wystąpiły, naleŜy poprawić ścieŜkę dostępu do klas zgodnie z komunikatami zgłaszanymi przez program i ponownie uruchomić skrypt budujący. Po zakończeniu procesu cała dystrybucja Cocoon powinna się znaleźć w jednym pliku cocoon.jar w podkatalogu build/. NaleŜy równieŜ sprawdzić, czy posiadamy przykładowy plik właściwości dostarczany z projektem, cocoon.properties, w katalogu bin/. Jeśli go tam nie ma, być moŜe znajduje się w podkatalogu build/classes/org/apache/cocoon/. Z pomocą Anta moŜna takŜe wygenerować dokumentację Javadoc i wykonać inne zadania związane z projektem. Wykonuje się je poprzez określenie celu (ang. target) polecenia budującego. Cele to słowa kluczowe dostarczane jako argumenty programu Ant; kompletna lista obsługiwanych celów dla oprogramowania Cocoon znajduje się w pliku build.xml. Celem do utworzenia dokumentacji jest docs, a dla Javadoc — javadocs. Na przykład, aby zbudować dokumentację, naleŜy wykonać polecenie: Building with classpath lib/ant_1_1.jar:lib/bsf.jar:lib/bsfengines.jar:lib/fop_0_13_0.jar:lib/ servlet_2_2.jar:lib/stylebook-1.0-b2.jar:lib/turbine-pool.jar:lib/ xalan_1_2_D02.jar:lib/xerces_1_2.jar:/usr/local/jdk1.2.2/lib/tools.jar: Starting Ant... Buildfile: build.xml init: ------------------- Cocoon 1.8 [1999-2000] --------prepare-docs: [replace] Replacing ./xdocs/dtd/ --> dtd/ [replace] Replacing ./xdocs/dtd/ --> dtd/ docs: [mkdir] Created dir: /home/adam/cocoon-1.8/build/docs ...

W ten sposób pełna dokumentacja projektu znajdzie się w podkatalogu build/docs/. Po przygotowaniu projektu moŜna przejść do konfigurowania mechanizmu serwletów pod kątem korzystania z niego.

Konfiguracja mechanizmu serwletów Trzeba poinformować mechanizm serwletów o oprogramowaniu Cocoon oraz wskazać, które Ŝądania ma do tego oprogramowania przekazywać. Skonfigurujemy Cocoon do współpracy z mechanizmem serwletów Jakarta Tomcat3 — jest to implementacja referencyjna interfejsu Java 3

W przykładach wykorzystano wersję 3.1, ale Cocoon wymaga tylko wersji 2.x tego interfejsu serwletów. Opcje konfiguracyjne nie powinny się zmienić w innych wersjach; innymi słowy, instrukcje podane w tym rozdziale powinny „działać” w dowolnej wersji 3.x Tomcata.

Instalacja

210

Servlet API 2.2. Czytelnik powinien potrafić uzyskać podobne wyniki takŜe w innych mechanizmach serwletów. Struktura Cocoon działa na poziomie mechanizmu serwletów, a nie jako kolejny serwlet. Dlatego trzeba dodać Cocoon oraz współpracujące z nim mechanizmy do ścieŜki dostępu do klas samego mechanizmu serwletów, a nie do określonej strefy serwletów czy kontekstu. Kopiujemy pliki jar Cocoon, Xerces, Xalan i FOP do podkatalogu lib/ głównego katalogu instalacyjnego Tomcat. Następnie biblioteki te dodajemy do ścieŜki dostępu do klas mechanizmu serwletów; w tym celu w mechanizmie Tomcat edytujemy plik inicjalizacyjny. W systemie Windows jest to plik /bin/tomcat.bat, a w systemach Unix /bin/tomcat.sh. W plikach tych znajdziemy wiersze ustawiające ścieŜkę dostępu do klas odczytywane przez Tomcat w czasie uruchamiania. NaleŜy tam dodać ścieŜki dostępu do klas Cocoon i programów towarzyszących — tak, by odczytywane były przed innymi wpisami w tym pliku4. W systemie Windows wpisy te wyglądają następująco: set CLASSPATH=. set CLASSPATH=%TOMCAT_HOME%\classes rem set set set set

Klasy i biblioteki Cocoon CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\xerces_1_2.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\xalan_1_2_D02.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\fop_0_13_0.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\cocoon.jar

set set set set set

CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\webserver.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\jasper.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\xml.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\servlet.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\tools.jar

a w systemach uniksowych: set CLASSPATH=. # Klasy i biblioteki Cocoon CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/xerces_1_2.jar CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/xalan_1_2_D02.jar CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/fop_0_13_0.jar CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/cocoon.jar for i in ${TOMCAT_HOME}/lib/* ; do CLASSPATH=${CLASSPATH}:$i done

WaŜne jest, aby klasy Cocoon poprzedzały pozostałe klasy Tomcat, a w szczególności xml.jar. Xerces, Xalan i Cocoon wykorzystują interfejs SAX 2 i DOM Level 2, zaś parser Sun Project X zawarty w xml.jar — jeszcze nie. Jeśli ta klasa i jej wersje SAX-a i DOM-a zostaną znalezione jako pierwsze, wystąpi błąd w strukturze publikacji Cocoon. Po dodaniu bibliotek trzeba jeszcze „poinformować” Cocoon o połoŜeniu jego pliku właściwości (potem Czytelnik dowie się, do czego faktycznie słuŜy ten plik). NaleŜy skopiować plik cocoon.properties z katalogu Cocoon do /conf/. W tym samym katalogu jest umieszczony plik web.xml, opisujący właściwości i odwzorowania globalne serwletów w mechanizmie. Tutaj naleŜy wskazać konfigurację struktury Cocoon. Wpisujemy tam następujące dane: 4

W najnowszych wersjach dla systemów uniksowych Tomcat sam odnajduje klasy skopiowane do lib/, dlatego podawanie ścieŜek dostępu nie jest konieczne; trzeba jednak wtedy pamiętać, Ŝe pliki z tego katalogu będą odczytywane w kolejności zgodnej z kolejnością alfabetyczną nazw i w razie potrzeby odpowiednio zmienić te nazwy — przyp. tłum.

Korzystanie ze struktury publikacji

211

org.apache.cocoon.Cocoon

properties

/usr/lib/jakarta-tomcat/conf/cocoon.properties

org.apache.cocoon.Cocoon

*.xml

Nie ma znaczenia, w którym miejscu pliku zostanie wstawiony powyŜszy fragment, o ile tylko nie naruszy to zagnieŜdŜenia elementów (ostateczny plik musi być poprawnym plikiem XML). NaleŜy takŜe zmienić na właściwą ścieŜkę dostępu do pliku cocoon.properties, będącą wartością parametru properties. Parametr ten jest przekazywany przez mechanizm serwletów do serwleta Cocoon, co umoŜliwia poprawną jego konfigurację. Parametr servlet-mapping informuje mechanizm, Ŝe Ŝądania kończące się rozszerzeniem .xml mają być przeadresowywane do struktury Cocoon. Po wprowadzeniu zmian naleŜy wykonać restart serwera Tomcat i sprawdzić, czy w czasie uruchamiania nie występują Ŝadne błędy. Jeśli wszystko zostało skonfigurowane poprawnie, moŜna wyświetlić w przeglądarce stronę http:// :/Cocoon.xml. Jeśli nie wystąpiły Ŝadne błędy, czytelnik powinien ujrzeć stronę podobną do tej na rysunku 9.1 (w zaleŜności od rodzaju przeglądarki moŜe się róŜnić formatowanie tabeli). Jeśli wystąpiły jakieś błędy, Czytelnik powinien ujrzeć komunikaty definiujące problem. Zazwyczaj kłopoty wynikają z nieobecności wymaganych klas w ścieŜce dostępu do klas, w nieprawidłowym określeniu połoŜenia pliku właściwości lub w niemoŜności jego odczytania przez serwlet. Ewentualne błędy naprawić i ponownie uruchomić mechanizm. Po uzyskaniu Ŝądanego efektu Czytelnik jest gotów do wypróbowania działania struktury Cocoon i skonfigurowania jej w taki sposób, by obsługiwała róŜne typy Ŝądań.

Korzystanie ze struktury publikacji Korzystanie z dobrej struktury publikacji w rodzaju Cocoon nie wymaga jakichś specjalnych instrukcji — nie jest to złoŜona aplikacja, której obsługi trzeba się najpierw nauczyć. Wszystko właściwie sprowadza się do wpisania prostego adresu URL do standardowej przeglądarki WWW. Generowanie dynamicznych stron HTML z XML-a, przeglądanie danych XML przekształconych na format PDF, a nawet aplikacje VRML generowane z XML-a — wszystko to uzyskać moŜna poprzez wpisanie adresu URL pliku XML do przeglądarki; resztą zajmie się juŜ Cocoon.

Korzystanie ze struktury publikacji

212

Rysunek 9.1. Strona konfiguracji Cocoon

Przeglądanie plików XML przekonwertowanych na HTML Mając poprawnie działającą strukturę publikacji, moŜemy za jej pomocą wyświetlić posiadane pliki XML. Wraz z oprogramowaniem Cocoon dostarczane są przykładowe pliki XML i towarzyszące im arkusze stylów XSL (w podkatalogu samples/). My jednak mamy juŜ własnoręcznie utworzone pliki XML i XSL, a więc spróbujmy przekształcić fragment spisu treści XML za pomocą arkusza stylów XSL utworzonego w rozdziale 6. Plik XML powinien nosić nazwę contents.xml (moŜna go równieŜ pobrać ze strony WWW niniejszej ksiąŜki). NaleŜy skopiować go do katalogu głównego dokumentów mechanizmu serwletów. W przypadku domyślnej instalacji Tomcata jest to katalog /webapps/ROOT/. Dokument odwołuje się do arkusza stylów XSL/ JavaXML.html.xsl, a więc trzeba jeszcze w katalogu głównym utworzyć katalog XSL i skopiować tam arkusz utworzony w rozdziale 6. NaleŜy sprawdzić, czy definicja DTD w dokumencie XML jest opatrzona komentarzami (pamiętajmy, sprawdzanie poprawności rzadko ma sens w zastosowaniu produkcyjnym), a takŜe zamienić encję OReillyCopyright na HTML, tak jak to zostało opisane w rozdziale 6. Cocoon obsługuje sprawdzanie poprawności i encje zewnętrzne, ale na razie nie naleŜy zaprzątać sobie głowy zbyt wieloma szczegółami. Teraz moŜna juŜ załadować plik, wpisując adres http://:/contents.xml. Jeśli Czytelnik wprowadził modyfikacje opisywane w rozdziale 6., przekształcony plik XML powinien wyglądać tak jak na rysunku 9.2.

Korzystanie ze struktury publikacji

213

Rysunek 9.2. Plik XML z rozdziału 6. po przekształceniu

Pliki PDF utworzone z danych XML Do tej pory mówiliśmy niemal wyłącznie o przekształcaniu dokumentów XML na HTML; w pozostałych przypadkach zakładaliśmy, Ŝe dane będą przesyłane pomiędzy dwoma aplikacjami. Format był całkowicie umowny, jako Ŝe zarówno aplikacja wysyłająca, jak i otrzymująca przekształcały dane XML za pomocą określonej definicji DTD lub schematu. JednakŜe struktura publikacji oferuje o wiele więcej moŜliwości. Nie tylko obsługiwane jest przekształcanie na liczne języki znaczników; dostępne są równieŜ biblioteki przekształcające XML na niektóre formaty nie wykorzystujące znaczników. Najbardziej popularną i stabilną biblioteką tej kategorii jest Formatting Objects Processor (FOP) grupy Apache XML, który pokrótce został juŜ omówiony w rozdziale 6. Pozwala on na przekształcanie dokumentów XML na pliki PDF, których oglądanie umoŜliwia oprogramowanie Adobe Acrobat (http://www.adobe.com). Trudno przecenić moŜliwość przekształcania danych XML na dokumenty PDF; szczególnie w serwisach operujących na dokumentach, takich jak firmy drukarskie czy wydawnictwa, technologia ta moŜe zrewolucjonizować operacje na danych. PoniŜszy przykład przedstawia dokument XML opisujący fragment oryginalnej, angielskiej wersji rozdziału 1. niniejszej ksiąŜki (przykład 9.1).

Przykład 9.1. Wersja XML rozdziału 1.

Korzystanie ze struktury publikacji

214

Java and XML Brett McLaughlin XML. These three letters have brought shivers to almost every developer in the world today at some point in the last two years. While those shivers were often fear at another acronym to memorize, excitement at the promise of a new technology, or annoyance at another source of confusion for today's developer, they were shivers all the same. Surprisingly, almost every type of response was well merited with regard to XML. It is another acronym to memorize, and in fact brings with it a dizzying array of companions: XSL, XSLT, PI, DTD, XHTML, and more. It also brings with it a huge promise-what Java did for portability of code, XML claims to do for portability of data. Sun has even been touting the rather ambitious slogan "Java + XML = Portable Code + Portable Data" in recent months. And yes, XML does bring with it a significant amount of confusion. We will seek to unravel and demystify XML, without being so abstract and general as to be useless, and without diving in so deeply that this becomes just another droll specification to wade through. This is a book for you, the Java developer, who wants to understand the hype and use the tools that XML brings to the table. Today's web application now faces a wealth of problems that were not even considered ten years ago. Systems that are distributed across thousands of miles must perform quickly and flawlessly. Data from heterogeneous systems, databases, directory services, and applications must be transferred without a single decimal place being lost. Applications must be able to communicate not only with other business components, but other business systems altogether, often across companies as well as technologies. Clients are no longer limited to thick clients, but can be web browsers that support HTML, mobile phones that support Wireless Application Protocol (WAP), or handheld organizers with entirely different markup languages altogether. Data, and the transformation of that data, has become the crucial centerpiece of every application being developed today.

Czytelnik wie juŜ, jak przekształcać taki dokument na dokument HTML. Ale przekształcenie całego rozdziału ksiąŜki do tego formatu dałoby w wyniku ogromny dokument HTML, bardzo trudny w odczycie; potencjalny Czytelnik na pewno wolałby otrzymać dokument PDF. Z drugiej strony, jeśli generujemy statycznie PDF, to musimy zapewnić, Ŝe zmiany wprowadzone w rozdziale zostaną odzwierciedlone w nowym pliku PDF. Przechowywanie pliku w jednolitym formacie XML umoŜliwia prostą jego aktualizację (za pomocą dowolnego edytora XML), formatowanie do SGML-a w celu wydrukowania, przesyłanie do innych firm i aplikacji oraz dołączanie do innych ksiąŜek lub kompendiów. Jeśli dodamy do tego prostotę uŜytkowania (wystarczy wpisać w przeglądarce adres URL), to otrzymujemy kompletny system publikacji.

Korzystanie ze struktury publikacji

215

Nie będziemy szczegółowo omawiali obiektów formatujących i interfejsu FOP — definicja takich obiektów znajduje się w specyfikacji XSL pod adresem http://www.w3.org/TR/xsl/. W przykładzie 9.2 pokazano arkusz stylu XSL, który umoŜliwia przekształcenie danych XML na dokument PDF.

Przykład 9.2. Arkusz XSL konwertujący dane z przykładu 9.1 na dokument PDF

type="text/xslfo"

Korzystanie ze struktury publikacji

216

Po utworzeniu obu powyŜszych plików i zapisaniu rozdziału jako plik chapterOne.xml oraz arkusza jako JavaXML.fo.xsl w katalogu XSL/, moŜna obejrzeć wyniki transformacji w przeglądarce. Przeglądarka musi być wyposaŜona we wtyczkę (ang. plug-in) Adobe Acrobat Reader, co umoŜliwi bezpośrednie obejrzenie pliku w przeglądarce (inaczej trzeba byłoby go zachować i przejrzeć przy uŜyciu innego programu). Wynikowy dokument PDF przedstawiony jest na rysunku 9.3.

Styl zaleŜny od przeglądarki Oprócz jawnego określania typu transformacji (np. na format PDF), Cocoon umoŜliwia takŜe przekształcanie w zaleŜności od rodzaju Ŝądania. Typowym przykładem takiego zachowania jest formatowanie zaleŜne od programu klienta. W tradycyjnym środowisku WWW dokument XML moŜe więc zostać przekształcony w róŜny sposób, zaleŜnie od tego, czy klient korzysta np. z przeglądarki Internet Explorer czy Netscape. Biorąc pod uwagę ostatnie przepychanki firm Netscape i Microsoft odnośnie wersji HTML-a i DHTML-a, jest to na pewno bardzo przydatna funkcja. Cocoon fabrycznie obsługuje wiele popularnych typów przeglądarek. PoniŜej ptrzedstawiony jest końcowy fragment pliku cocoon.properties. ########################################## # User Agents (Browsers) # ########################################## # # # # # #

NOTE: numbers indicate the search order. This is very important since some words may be found in more than one browser description. (MSIE is presented as "Mozilla/4.0 (Compatible; MSIE 4.01; ...") for example, the "explorer=MSIE" tag indicates that the XSL stylesheet associated to the media type "explorer" should be mapped to those browsers

Korzystanie ze struktury publikacji

217

Rysunek 9.3. Dokument PDF powstały z przykładów 9.1 i 9.2 # that have the string "MSIE" in their "user-Agent" HTTP header. browser.0 = explorer=MSIE browser.1 = pocketexplorer=MSPIE browser.2 = handweb=HandHTTP browser.3 = avantgo=AvantGo browser.4 = imode=DoCoMo browser.5 = opera=Opera browser.6 = lynx=Lynx browser.7 = java=Java browser.8 = wap=Nokia browser.9 = wap=UP browser.10 = wap=Wapalizer browser.11 = mozilla5=Mozilla/5 browser.12 = mozilla5=Netscape6/ browser.13 = netscape=Mozilla

Słowa kluczowe znajdujące się po pierwszych znakach równości (np. explorer, opera, lynx, java, netscape) określają agenty uŜytkowników i kody, jakie są przez nie wysyłane wraz z Ŝądaniem. Spróbujmy wykorzystać te właściwości w przykładowym pliku arkusza XSL, stosowanym w przypadku, gdy klientem jest Internet Explorer. Kopiujemy nasz oryginalny arkusz stylów JavaXML.html.xsl do JavaXML.explorer-html.xsl i wprowadzamy zmiany przedstawione w przykładzie 9.3.

Korzystanie ze struktury publikacji

218

Przykład 9.3. Arkusz stylu dla przeglądarki Internet Explorer <xsl:value-of select="JavaXML:Title" /> (wersja dla Explorera)

Table of Contents (wersja dla Explorera)

Natychmiast pobierz Netscape! ...

To oczywiście dość banalny przykład, ale dobrze obrazuje prostotę zmiany sposobu wyświetlania dokumentu i np. wysyłania innych danych do przeglądarki Internet Explorer 5.0, która szerzej obsługuje DHTML niŜ Netscape Navigator. Konieczne jest jeszcze poinformowanie dokumentu XML, Ŝe jeśli typ agenta uŜytkownika pasuje do zdefiniowanego we właściwościach typu explorer, to naleŜy uŜyć innego arkusza XSL. MoŜna to wykonać za pomocą instrukcji przetwarzania przedstawionej w przykładzie 9.4.

Przykład 9.4. Dokument XML odwołujący się do wielu arkuszy stylów w zaleŜności od klienta

Jeśli dokument obejrzymy za pomocą Netscape Navigatora, uzyskamy takie wyniki jak poprzednio, a jeśli za pomocą Internet Explorera — uzyskamy dokument przekształcony za pomocą innego arkusza stylu (rysunek 9.4.).

WAP i WML PotęŜne moŜliwości takich dynamicznych arkuszy stylów wiąŜą się równieŜ z wykorzystaniem urządzeń bezprzewodowych. Oto znany juŜ Czytelnikowi fragment pliku właściwości Cocoon:

Korzystanie ze struktury publikacji

219

browser.0 = explorer=MSIE browser.1 = pocketexplorer=MSPIE browser.2 = handweb=HandHTTP browser.3 = avantgo=AvantGo browser.4 = imode=DoCoMo browser.5 = opera=Opera browser.6 = lynx=Lynx browser.7 = java=Java browser.8 = wap=Nokia browser.9 = wap=UP browser.10 = wap=Wapalizer browser.11 = mozilla5=Mozilla/5 browser.12 = mozilla5=Netscape6/ browser.13 = netscape=Mozilla

Rysunek 9.4. „Explorerowa” wersja wygenerowanej strony HTML WyróŜnione wpisy pozwalają wykryć agenta bezprzewodowego, np. telefon z dostępem do Internetu. Cocoon, tak jak wcześniej rozpoznawał przeglądarkę, teraz wysyła arkusz stylu odpowiedni dla urządzenia WAP. Do tej pory nie przywiązywaliśmy duŜej wagi do poniŜszego fragmentu naszego pliku XML, określającego arkusz stylu uŜywanego w przypadku takiego urządzenia:

Korzystanie ze struktury publikacji

220

Teraz jednak omówimy go szczegółowo. W urządzeniach WAP wykorzystywany jest zazwyczaj język Wireless Markup Language (WML). Jest to odmiana HTML-a, róŜniąca się sposobem reprezentacji poszczególnych stron. Kiedy urządzenie bezprzewodowe wysyła Ŝądanie pobrania pliku spod adresu URL, zwrócona treść musi być zawarta w znaczniku wml. W tym elemencie głównym definiuje się szereg kart (ang. cards) — kaŜdą opisuje element WML card. Urządzenie pobiera wiele kart jednocześnie (określane są one mianem pliku kart (ang. deck of cards)), dzięki czemu nie musi ponownie odwoływać się do serwera w celu wyświetlenia kolejnych ekranów. W przykładzie 9.5 pokazano przykładową stronę XML wykorzystującą takie konstrukcje.

Przykład 9.5 Prosta strona WML

Menu główne
Strona tytułowa
Moja strona

Witam na mojej stronie domowej!
Tak miło was tu gościć.

Hello World!

Na Ŝądanie treści WML zwrócona zostałaby odpowiedź w postaci menu i dwóch ekranów zawartości, dostępnych poprzez odsyłacze z menu. Pełna specyfikacja WML 1.1 dostępna jest pod adresem http://updev.phone.com/dev/ts/; wcześniej trzeba się nieodpłatnie zarejestrować pod adresem http://updev.phone.com. Z tej witryny moŜna równieŜ pobrać oprogramowanie UP.SDK, emulujące urządzenie bezprzewodowe. Wystarczy w nim wpisać adres http://:/contents.xml i obejrzeć wynik działania arkusza XSL dla urządzenia WAP. PoniewaŜ wyświetlacze telefonów są bardzo małe, będziemy chcieli wyświetlić jedynie podzbiór informacji zawartych w naszym spisie treści. W przykładzie 9.6 przedstawiono arkusz wyświetlający trzy karty w WML-u. Pierwsza to menu z odsyłaczami do dwóch pozostałych. Druga karta to wynik generacji spisu treści z dokumentu contents.xml. Trzecia to prosty ekran z prawami autorskimi. Arkusz stylów zachowujemy jako JavaXML.wml.xsl w podkatalogu XSL/ katalogu głównego serwera.

Przykład 9.6. Arkusz XSL umoŜliwiający wyświetlenie spisu treści w urządzeniu WAP

Korzystanie ze struktury publikacji

221

type="text/wml"

Spis
Copyright

Spis

Poza nowymi znacznikami WML, powyŜszy przykład nie powinien sprawiać Czytelnikowi Ŝadnych trudności. Wprowadzono nową funkcję XSL, position() oraz nowy element xsl:number. W ten sposób w pętli xsl:for-each dodawana jest numeracja: 1: Wprowadzenie 2: Pisanie w XML-u ...

Dodano takŜe instrukcje przetwarzania dla struktury Cocoon, w której cel określono jako cocoonformat. Przesyłane dane, type="text/wml", instruują Cocoon, Ŝe arkusz stylu ma być wyświetlony z nagłówkiem zawartości w postaci text/wml (a nie text/html lub text/plain, jak to się dzieje standardowo). I jeszcze jeden istotny dodatek w postaci atrybutu w elemencie głównym arkusza:

XSP

222

Domyślnie kaŜda deklaracja przestrzeni nazw XML inna niŜ przestrzeń XSL jest dodawana do elementu głównego danych wyjściowych transformacji. W naszym przykładzie element główny danych wyjściowych, wml, zostałby opatrzony następującą deklaracją przestrzeni nazw: ...

Spowodowałoby to błąd przeglądarki WAP, jako Ŝe xmlns:JavaXML nie jest dozwolonym atrybutem elementu wml. Przeglądarki tego typu nie są tak tolerancyjne jak przeglądarki HTML i reszta zawartości po prostu nie zostałaby wyświetlona. JednakŜe my musimy zadeklarować przestrzeń nazw, aby arkusz XSL mógł dopasować szablon dla dokumentu wejściowego — a to właśnie wykonujemy poprzez przestrzeń JavaXML. Problem moŜna rozwiązać poprzez dodanie atrybutu exclude-result-prefixes do elementu xsl:stylesheet. Przedrostek przestrzeni nazw określony w tym atrybucie nie będzie dodawany do danych wyjściowych — a tego właśnie sobie Ŝyczymy. Teraz dane wyjściowe będą „otoczone” znacznikami: ...

Taki zapis przeglądarka WAP rozumie doskonale. Jeśli pobraliśmy przeglądarkę UP.SDK, moŜemy wpisać w niej adres naszego spisu treści i obejrzeć wynik (do wyświetlenia stron WAP tłumacz wykorzystał emulator Deck-It firmy PyWeb, który moŜna nieodpłatnie pobrać ze strony http://PyWeb.com; przeglądarka UP.SDK w czasie tłumaczenia nie była dostępna w wersji dla systemu Linux — przyp.tłum.). Na rysunku 9.5 widoczne jest menu główne wyświetlane wtedy, gdy pliku contents.xml zaŜąda poprzez Cocoon urządzenie WAP. Na rysunku 9.6 widzimy wygenerowany spis treści, dostępny po odwiedzeniu odsyłacza „Spis”, pokazanego na poprzednim rysunku. Więcej informacji o standardach WML i WAP moŜna znaleźć na stronach http://www.phone.com i http://www.wapforum.org; oba te miejsca są obszernymi źródłami wiedzy o urządzeniach bezprzewodowych. Teraz juŜ Czytelnik powinien dość dobrze orientować się, jak róŜne dane wyjściowe moŜna uzyskać dzięki oprogramowaniu Cocoon. Niewielki wysiłek, jakiś dodatkowy arkusz stylu — i juŜ ten sam dokument moŜna serwować w wielu formatach rozmaitym klientom. To między innymi dlatego struktury publikacji są tak potęŜnym narzędziem. Bez XML-a i podobnego oprogramowania, dla kaŜdego typu klienta trzeba byłoby tworzyć oddzielny serwis. Skoro jednak znamy juŜ moŜliwości struktury Cocoon, przejdźmy do omówienia sposobu dynamicznego tworzenia i dostosowania danych wejściowych transformacji przy uŜyciu oprogramowania Cocoon.

XSP XSP to Extensible Server Pages, czyli rozszerzalne strony serwera. To chyba najwaŜniejsza nowinka mająca swoje źródła w projekcie Cocoon. Z pewnością Czytelnik spotkał się juŜ z terminem Java Server Pages (JSP). JSP to (w skrócie) znaczniki i zagnieŜdŜony kod Javy wstawiany do, skądinąd zupełnie zwyczajnej, strony HTML. Po otrzymaniu Ŝądania takiej strony zawarty w niej kod

XSP

Rysunek 9.5. Główne menu WML

Rysunek 9.6. Spis treści WML

223

XSP

224

jest wykonywany, a wynik wstawiany bezpośrednio do danych wynikowych HTML5. Technologia ta zawładnęła Javą i ASP, upraszczając programowanie w Javie po stronie serwera i umoŜliwiając separację danych wyjściowych i procesów logicznych. JednakŜe nie uniknięto pewnych istotnych problemów. Po pierwsze, JSP tak naprawdę nie oddziela zawartości i prezentacji. Problem ten juŜ był sygnalizowany w ksiąŜce — zmiana bannera, koloru fontu czy rozmiaru tekstu wymaga modyfikacji JSP (wraz z wpisanymi odwołaniami do Javy i JavaBean). Zawartość (czyste dane) miesza się z prezentacją, podobnie jak w statycznym HTML-u. Po drugie, nie ma moŜliwości przekonwertowania JSP na jakikolwiek inny format lub uŜycia go do komunikacji pomiędzy aplikacjami — JSP stworzono głównie do prezentacji danych wyjściowych. XSP stanowi remedium na oba te problemy. Po pierwsze, XSP to właściwie zwykły XML. W przykładzie 9.7 przedstawiona jest strona XSP.

Przykład 9.7. Przykładowa strona XSP private static int numHits = 0; private synchronized int getNumHits() { return ++numHits; } Licznik odwiedzin

Pobierano mnie getNumHits() razy.

Utrzymano zgodność ze wszystkimi konwencjami XML; chwilowo element xsp:logic odczytujemy jako „zakaz wstępu” dla parsera — element ten zostanie omówiony w dalszej części rozdziału. Poza tym cały dokument to zwykłe dane XML zawierające parę nowych elementów. Jest tu nawet odwołanie do arkusza stylu, który nie zawiera Ŝadnych nowości (przykład 9.8).

Przykład 9.8. Arkusz stylu XSL dla przykładu 9.7

5

To oczywiście karygodne uproszczenie; JSP jest najpierw prekompilowane do postaci serwleta, a wyjście obsługuje PrintWriter. Więcej informacji o JSP znaleźć moŜna w ksiąŜce Java Servlet Programming Jasona Huntera (O'Reilly & Associates).

XSP

225 type="text/html"

<xsl:value-of select="title"/>

Zatem XSP w prosty sposób likwiduje więc pierwszy problem związany z JSP — umoŜliwia oddzielenie zawartości od prezentacji. Dzięki takiej separacji programista moŜe zająć się generacją treści (strona XSP moŜe być statyczna, ale moŜe być takŜe generowana z serwletu lub innego kodu Javy), zaś autorzy XML i XSL zajmują się prezentacją i stylami poprzez modyfikację arkusza stylu. W podobny sposób rozwiązywana jest druga bolączka JSP — poniewaŜ przetwarzanie XSP wykonywane jest przed zastosowaniem arkuszy stylów, wynikowy dokument XML moŜe zostać przetworzony na dowolny inny format. Strona XSP moŜe więc być przekazywana pomiędzy aplikacjami równie łatwo, jak wykorzystywana w prezentacji.

Tworzenie strony XSP Teraz, kiedy Czytelnik poznał juŜ XSP, spróbujmy stworzyć własną stronę w tym standardzie. Dalej jako przykład będziemy stosowali utworzony juŜ wcześniej dokument XML. Zamiast po prostu wyświetlać nasz dokument, załóŜmy, Ŝe autor chciałby pokazywać go redaktorowi w miarę pisania. Oprócz tekstu ksiąŜki redaktor powinien widzieć komentarze autora; komentarze te nie są jednak przeznaczone dla oczu zwykłego czytelnika — na przykład dotyczą formatowania i stylu. Najpierw dodajmy taki komentarz do stworzonego wcześniej pliku chapterOne.xml. Chapter 1: Introduction XML. These three letters have brought shivers to almost every developer in the world today at some point in the last two years. While those shivers were often fear at another acronym to memorize, excitement at the promise of a new technology, or annoyance at another source of confusion for today's developer, they were shivers all the same. Surprisingly, almost every type of response was well merited with regard to XML. It is another acronym to memorize, and in fact brings with it a dizzying array of companions: XSL, XSLT, PI, DTD, XHTML, and more. It also brings with it a huge promise-what Java did for portability of code, XML claims to do for portability of data. Sun has even been touting the rather ambitious slogan "Java + XML = Portable Code + Portable Data" in recent months. And yes, XML does bring with it a significant amount of confusion. We will seek to unravel and demystify XML, without being so abstract and general as to be useless, and without diving in so deeply that this becomes just

XSP

226 another droll specification to wade through. This is a book for you, the Java developer, who wants to understand the hype and use the tools that XML brings to the table. Czy ten akapit jest poprawnie sformatowany, czy rozdzielamy go na dwa oddzielne akapity? Mike, poinformuj mnie o swojej decyzji w tym zakresie. Today's web application now faces a wealth of problems that were not even considered ten years ago. Systems that are distributed across thousands of miles must perform quickly and flawlessly. Data from heterogeneous systems, databases, directory services, and applications must be transferred without a single decimal place being lost. Applications must be able to communicate not only with other business components, but other business systems altogether, often across companies as well as technologies. Clients are no longer limited to thick clients, but can be web browsers that support HTML, mobile phones that support Wireless Application Protocol (WAP), or handheld organizers with entirely different markup languages altogether. Data, and the transformation of that data, has become the crucial centerpiece of every application being developed today.

Po wstawieniu do dokumentu takiego komentarza dodajmy odpowiedni wpis w arkuszu stylów, JavaXML.fo.xsl.

Po wprowadzeniu powyŜszego wpisu komentarze będą nieco mniejsze niŜ reszta tekstu, niebieskie i pisane kursywą. Teraz nasz dokument XML naleŜy przekształcić na stronę XSP (jak w przykładzie 9.9) — dodając wymagane instrukcje przetwarzania dla struktury Cocoon i otaczając elementy nowym elementem głównym, xsp:page.

Przykład 9.9. Wersja XSP przykładu 9.1
XSP

227 > Java i XML Brett McLaughlin

Zanim zajmiemy się kodem XSP odpowiedzialnym za wyświetlenie komentarza, zbudujmy prostą stronę HTML umoŜliwiającą określenie, czy odwiedzający jest redaktorem ksiąŜki. W prawdziwej aplikacji na tej stronie odbywałoby się uwierzytelnianie i określanie roli uŜytkownika; w naszym przypadku uŜytkownik będzie mógł określić się jako autor, edytor lub po prostu ciekawski czytelnik i podać hasło. Odpowiednia strona HTML przedstawiona jest w przykładzie 9.10. Zapiszmy ją jako entry.html w katalogu głównym serwera WWW.

Przykład 9.10. Interfejs HTML do wyboru „roli” uŜytkownika Witamy na stronie roboczej wersji Java i XML

Java i XML wersja robocza

NaleŜy zauwaŜyć, Ŝe formularz HTML przekazujemy bezpośrednio do strony XSP. W tym przykładzie strona XSP działa jak serwlet. Chcemy, aby odczytała parametry Ŝądania, określiła, jaki rodzaj uŜytkownika został podany, przeprowadziła uwierzytelnianie za pomocą hasła i wyświetliła (lub nie) komentarz. Zacznijmy od zdefiniowania zmiennej typu boolean; będzie ona zawierała wynik porównania podanego hasła z właściwym. Następnie sprawdzimy wartość tej zmiennej i jeśli ta wartość to true, wyświetlimy element authorComment:

XSP

228 Java and XML Brett McLaughlin ... is a book for you, the Java developer, who wants to understand the hype and use the tools that XML brings to the table. boolean authorOrEditor = false; // Tu sprawdzimy, czy to autor, czy redaktor. if (authorOrEditor) { Czy ten akapit jest poprawnie sformatowany, czy rozdzielamy go na dwa oddzielne akapity? Mike, poinformuj mnie o swojej decyzji w tym zakresie. } Today's web application now faces a wealth of problems that were not even considered ten years ago. Systems that are ...

Czytelnik nie powinien mieć Ŝadnych trudności — poza znacznikami specyficznymi dla XSP definiujemy tylko zmienną i sprawdzamy jej wartość. Jeśli zmienna ma wartość true, element authorComment jest dodawany do danych wyjściowych XSP; w przeciwnym razie — nie. Interesujące jest to, Ŝe otaczamy faktyczne dane wyjściowe XML zawarte w xsp:logic elementem xsp: page. To gwarantuje, Ŝe procesor XSP nie będzie próbował interpretować Ŝadnych elementów ani tekstu wewnątrz tego bloku jako struktury XSP. I znów widać tutaj przewagę standardu XSP nad JSP — ten sam kod w tym ostatnim standardzie wyglądałby następująco: <% if (authorOrEditor) { %> Czy ten akapit jest poprawnie sformatowany, czy rozdzielamy go na dwa oddzielne akapity? Mike, poinformuj mnie o swojej decyzji w tym zakresie. <% } %>

Jest to mniej zrozumiała struktura — blok JSP kończy się, zanim jeszcze element authorComment się zaczyna; następnie po elemencie dołączany jest kolejny blok, zamykający nawias otwarty w bloku pierwszym. Bardzo łatwo pomylić sposoby kodowania lub zapomnieć o „zamykających” blokach JSP; XSP wymusza zamknięcie kaŜdego otwartego elementu (standardowe poprawne formatowanie XML-a), a jeden blok kodu odpowiada jednemu elementowi. Po wprowadzeniu struktur logicznych naleŜy juŜ tylko zinterpretować parametry Ŝądania. Do tego celu słuŜy wbudowana zmienna XSP request, ktora „naśladuje” obiekt HttpServletRequest. Kod po wprowadzeniu poniŜszych modyfikacji odczytuje wartość parametrów userRole i password (jeśli istnieją); wartość ta następnie jest porównywana z rolami, które mają prawo do obejrzenia komentarza (autor i redaktor). Jeśli dopasowanie się powiedzie, sprawdzane jest jeszcze hasło. Jeśli hasło odpowiada kluczowi podanej roli, zmienna boolowska jest włączana (wartość true), a element authorComments stanowi część danych wyjściowych XML:

XSP

229 boolean authorOrEditor = false; // PoniŜej sprawdzimy, czy to autor czy redaktor } if (authorOrEditor) { Czy ten akapit jest poprawnie sformatowany, czy rozdzielamy go na dwa oddzielne akapity? Mike, poinformuj mnie o swojej decyzji w tym zakresie. }

Czytelnik winien zauwaŜyć, Ŝe spory fragment instrukcji logicznych został ujęty w znacznik CDATA. Trzeba pamiętać, Ŝe XSP zawsze jest przetwarzane jako XML i musi być zgodne z zasadami tego standardu; ale cudzysłowy i „ampersandy” (symbole &apm;) uŜywane we fragmentach w Javie nie są dozwolone w XML-u; zamiast więc znosić ich specjalne znaczenie i wprowadzać ogromne zamieszanie, naleŜy uŜyć znacznika CDATA, w którym moŜna sobie spokojnie pisać w Javie. Bez niego kod wyglądałby następująco: boolean authorOrEditor = false; String[] roleValues = request.getParameterValues("userRole"); String[] passwordValues = request.getParameterValues("password"); if ((roleValues != null) && (passwordValues != null)) { String userRole = roleValues[0]; String password = passwordValues[0]; if (userRole.equals("author") && password.equals("brett")) { authorOrEditor = true; } else if (userRole.equals("editor") && password.equals("mike")) { authorOrEditor = true; } } ...

Teraz moŜna przetestować stronę „wejściową” i dokument PDF powstały z danych XML. Po „skierowaniu” przeglądarki na stronę http://://entry.html Czytelnik powinien uzyskać wynik podobny do tego na rysunku 9.7.

XSP

230

Rysunek 9.7. „Wejściowa” strona HTML Wybieramy rolę autora i podajemy hasło „brett” albo rolę redaktora i hasło „mike”. W obu przypadkach uzyskamy dokument PDF przedstawiony na rysunku 9.8.

Rysunek 9.8. Wygenerowany dokument PDF z komentarzami Trzeba juŜ tylko odizolować instrukcje logiczne od samej zawartości. Podobnie jak w JSP moŜliwe jest włączanie obiektów JavaBean i tym samym oddzielanie zawartości i prezentacji od logiki aplikacji, XSP umoŜliwia tworzenie bibliotek znaczników. Później, za pomocą znaczników XML, uruchamiany jest odpowiedni kod znajdujący się wewnątrz takiej biblioteki.

XSP

231

Biblioteki znaczników XSP Oprócz wyświetlenia komentarzy, naleŜy równieŜ zaznaczyć, Ŝe oglądany rozdział to wersja robocza; oprócz tego powinna zostać wyświetlona data zmian w wersji roboczej (która zostanie „zamroŜona” po ukończeniu rozdziału). Zamiast dopisywać kod Javy ładujący bieŜącą datę, moŜna stworzyć do tego celu własną bibliotekę znaczników. Przy okazji Czytelnik dowie się, jak stworzyć element XSP pobierający numer i tytuł rozdziału, a następnie formatujący odpowiedni nagłówek. Za pomocą tej funkcji moŜna obsłuŜyć równieŜ wspomnianą operację na dacie. Najpierw konieczne jest utworzenie biblioteki znaczników dostępnej z naszej strony XSP. Większa część takiej biblioteki oparta jest na arkuszu stylu XSL. Zaczniemy od szkieletu pokazanego w przykładzie 9.11, który po prostu przekazuje wszystkie otrzymane dane na wyjście. Szkielet ten zachowamy w podkatalogu XSL/, w pliku JavaXML.xsp.xsl. Trzeba pamiętać o dołączeniu deklaracji przestrzeni nazw JavaXML, poniewaŜ wykorzystamy ją do dopasowania elementów na naszych stronach XSP.

Przykład 9.11. Arkusz logiki XSP

Dopasowując znacznik xsp:page gwarantujemy, Ŝe wszystkie elementy zostaną dopasowane i obsłuŜone wewnątrz tego arkusza stylu (czy teŜ, zgodnie z nazewnictwem XSP, arkusza logiki). Teraz dodajemy metody Javy do wywołania przez szablony wewnątrz arkusza:

java.util.Date java.text.SimpleDateFormat

XSP

232 private String getDraftDate() { return (new SimpleDateFormat("MM/dd/yyyy")) .format(new Date()); } private String getTitle(int chapterNum, String chapterTitle) { return "Chapter " + chapterNum + ": " + chapterTitle; }

Wprowadzono tutaj szereg nowych elementów XSP. Po pierwsze, element xsp:structure otacza elementy xsp:include. Te ostatnie działają podobnie jak include w języku Java — udostępniają określone klasy Javy, których moŜna teraz uŜywać za pomocą niekwalifikowanych nazw (zamiast pełnych nazw pakietów). Następnie definiujemy i implementujemy dwie metody — jedna tworzy tytuł rozdziału z numeru i tekstowej postaci tytułu, a druga zwraca bieŜącą datę w postaci sformatowanej zmiennej String. Metody te dostępne są z poziomu dowolnego elementu w tym arkuszu logiki. Teraz naleŜy zdefiniować element określający, kiedy dane XSP mają zastąpić element XML. JuŜ zdefiniowaliśmy przestrzeń nazw JavaXML w elemencie głównym dokumentu, a więc uŜywamy jej w elementach naszej biblioteki znaczników. Dodajemy następujący szablon: getTitle(, "") - getDraftDate()

Kiedy w dokumencie odwołującym się do takiej biblioteki znaczników uŜyjemy elementu JavaXML:draftTitle, do wyniku metody getTitle() zostanie dołączony łącznik (-), a następnie wartość zwracana przez getDate(). Element JavaXML:draftTitle równieŜ wymaga zadeklarowania dwóch atrybutów: numeru rozdziału i tytułu w postaci tekstowej. Procesor XSP otrzymuje informację, Ŝe wywołujemy zdefiniowaną metodę, poprzez ujęcie wywołania tej metody w znaczniki . Aby zaznaczyć, Ŝe drugi argument (tytuł rozdziału) jest zmienną String, ujmujemy go w cudzysłowy. PoniewaŜ tytuł rozdziału powinien być traktowany jako int, zostawiamy go bez cudzysłowów. Po stworzeniu arkusza logiki XSP (moŜna go równieŜ pobrać ze strony WWW niniejszej ksiąŜki) trzeba go udostępnić strukturze Cocoon. MoŜna to zrobić na dwa sposoby. Pierwszy z nich polega na określeniu połoŜenia pliku (w postaci URI), aby mógł zostać odnaleziony przez mechanizm serwletów (a więc równieŜ przez Cocoon). Na przykład, aby dodać w ten sposób arkusz XSP do zasobów Cocoon, naleŜy wpisać następujący wiersz do pliku cocoon.properties. Wersja uniksowa:

XSP

233 processor.xsp.logicsheet.context.java = resource://org/apache/cocoon/processor/xsp/library/java/context.xsl processor.xsp.logicsheet.cookie.java = resource://org/apache/cocoon/processor/xsp/library/java/cookie.xsl processor.xsp.logicsheet.global.java = resource://org/apache/cocoon/processor/xsp/library/java/global.xsl processor.xsp.logicsheet.request.java = resource://org/apache/cocoon/processor/xsp/library/java/request.xsl processor.xsp.logicsheet.response.java = resource://org/apache/cocoon/processor/xsp/library/java/response.xsl processor.xsp.logicsheet.session.java = resource://org/apache/cocoon/processor/xsp/library/java/session.xsl processor.xsp.logicsheet.util.java = resource://org/apache/cocoon/processor/xsp/library/java/util.xsl processor.xsp.logicsheet.sql.java = resource://org/apache/cocoon/processor/xsp/library/sql/sql.xsl processor.xsp.logicsheet.fp.java = resource://org/apache/cocoon/processor/xsp/library/fp/fp.xsl processor.xsp.logicsheet.JavaXML.java = file:///usr/local/jakartatomcat/webapps/ROOT/XSL/JavaXML.xsp.xsl

Wersja Windows: processor.xsp.logicsheet.context.java = resource://org/apache/cocoon/processor/xsp/library/java/context.xsl processor.xsp.logicsheet.cookie.java = resource://org/apache/cocoon/processor/xsp/library/java/cookie.xsl processor.xsp.logicsheet.global.java = resource://org/apache/cocoon/processor/xsp/library/java/global.xsl processor.xsp.logicsheet.request.java = resource://org/apache/cocoon/processor/xsp/library/java/request.xsl processor.xsp.logicsheet.response.java = resource://org/apache/cocoon/processor/xsp/library/java/response.xsl processor.xsp.logicsheet.session.java = resource://org/apache/cocoon/processor/xsp/library/java/session.xsl processor.xsp.logicsheet.util.java = resource://org/apache/cocoon/processor/xsp/library/java/util.xsl processor.xsp.logicsheet.sql.java = resource://org/apache/cocoon/processor/xsp/library/sql/sql.xsl processor.xsp.logicsheet.fp.java = resource://org/apache/cocoon/processor/xsp/library/fp/fp.xsl processor.xsp.logicsheet.JavaXML.java = file:///C:/java/jakartatomcat/webapps/ROOT/XSL/JavaXML.xsp.xsl

Takie rozwiązanie wystarcza na potrzeby testowania, ale arkusze logiczne są wtedy silnie „związane” z mechanizmem serwletów, a dodawanie nowych jest kłopotliwe (konieczne jest wpisywanie kolejnych wierszy w pliku właściwości)6. Alternatywna metoda ładowania arkuszy logiki polega na określeniu zasobu w ścieŜce dostępu do klas mechanizmu serwletów. Arkusze logiki dodawane są do pliku jar, a plik ten — do ścieŜki dostępu do klas. W ten sposób w pliku powstaje centralna baza własnych arkuszy logiki XSP uŜytkownika. W podkatalogu XSL/ wykonujemy następujące polecenie, które spowoduje utworzenie pliku jar, zawierającego nasz arkusz logiki: jar cvf logicsheets.jar JavaXML.xsp.xsl

6

Co więcej, zdarzają się kłopoty (wersje 1.7.x) z załadowaniem arkusza wpisanego w postaci file://...; problemu tego moŜna uniknąć stosując zapis w postaci resource://

XSP

234

Utworzone w ten sposób archiwum logicsheets.jar przenosimy do katalogu /lib/ — tam, gdzie znajdują się pozostałe biblioteki Cocoon. Teraz musimy dodać tę bibliotekę do ścieŜki dostępu do klas serwera Tomcat; edytujemy plik tomcat.sh lub tomcat.bat zlokalizowany w katalogu /bin/. W systemie Unix plik ten ma wyglądać następująco: set CLASSPATH=. # Klasy i biblioteki Cocoon CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/xerces_1_2.jar CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/xalan_1_2_D02.jar CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/fop_0_13_0.jar CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/cocoon.jar CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/logicsheets.jar for i in ${TOMCAT_HOME}/lib/* ; do CLASSPATH=${CLASSPATH}:$i done CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/tools.jar

Natomiast w Windows: set CLASSPATH=. set CLASSPATH=%TOMCAT_HOME%\classes rem set set set set set

Klasy i biblioteki Cocoon CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\xerces_1_2.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\xalan_1_2_D02.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\fop_0_13_0.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\cocoon.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\logicsheets.jar

set set set set set

CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\webserver.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\jasper.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\xml.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\servlet.jar CLASSPATH=%CLASSPATH%;%TOMCAT_HOME%\lib\tools.jar

Teraz informujemy Cocoon, gdzie ma, szukać przestrzeni nazw JavaXML na stronach XSP. Edytujemy plik cocoon.properties, który wcześniej umieściliśmy w katalogu /conf. Odnajdujemy część mówiącą o zasobach XSP i dodajemy odwołanie do nowego arkusza logiki: processor.xsp.logicsheet.context.java = resource://org/apache/cocoon/processor/xsp/library/java/context.xsl processor.xsp.logicsheet.cookie.java = resource://org/apache/cocoon/processor/xsp/library/java/cookie.xsl processor.xsp.logicsheet.global.java = resource://org/apache/cocoon/processor/xsp/library/java/global.xsl processor.xsp.logicsheet.request.java = resource://org/apache/cocoon/processor/xsp/library/java/request.xsl processor.xsp.logicsheet.response.java = resource://org/apache/cocoon/processor/xsp/library/java/response.xsl processor.xsp.logicsheet.session.java = resource://org/apache/cocoon/processor/xsp/library/java/session.xsl processor.xsp.logicsheet.util.java = resource://org/apache/cocoon/processor/xsp/library/java/util.xsl processor.xsp.logicsheet.sql.java = resource://org/apache/cocoon/processor/xsp/library/sql/sql.xsl processor.xsp.logicsheet.fp.java = resource://org/apache/cocoon/processor/xsp/library/fp/fp.xsl processor.xsp.logicsheet.JavaXML.java

= resource://JavaXML.xsp.xsl

Cocoon 2.0 i dalej

235

PoniewaŜ nasz arkusz logiki nie jest zagnieŜdŜony w podkatalogach pliku logicsheets.jar, jako ścieŜkę dostępu wystarczy określić tutaj nazwę pliku. Po tych wszystkich operacjach restartujemy mechanizm serwletów — plik cocoon.properties zostanie ponownie załadowany, a arkusz logiki udostępniony do uŜycia. PoniewaŜ Ŝądania obsługuje mechanizm Cocoon, kaŜda strona XSP, na której zadeklarowano uŜycie JavaXML, będzie miała dostęp do arkusza logiki określonego jako biblioteka JavaXML. Tak więc do naszej strony XSP musimy dodać deklarację przestrzeni nazw JavaXML: ...

Skoro biblioteka znaczników jest juŜ udostępniona, dodajemy element JavaXML:draftTitle do naszego dokumentu XML, chapterOne.xml: <JavaXML:draftTitle chapterNum="1" chapterTitle="Introduction" />

Zakodowany „na stałe” tytuł rozdziału zamieniamy na element zdefiniowany w naszej bibliotece znaczników. W ten sposób zostanie wygenerowany tytuł i numer rozdziału oraz data wersji roboczej. Teraz moŜna juŜ zobaczyć efekt naszej pracy, wpisując adres dokumentu do przeglądarki WWW. To, oczywiście, proste przykłady zastosowania standardu XSP. Ale juŜ tutaj widać potęŜne moŜliwości XSP — tytuł moŜe przybrać inną postać po ukończeniu rozdziału bez konieczności modyfikacji zawartości czy warstwy prezentacyjnej strony, a jedynie arkusza XSP. Logika aplikacji jest odseparowana od zawartości i prezentacji. Do tego wszystkiego moŜna jeszcze dołączyć logikę biznesową za pomocą komponentów Javy uruchamianych po stronie serwera, np. Enterprise JavaBeans. Zastosowanie standardu XSP to rozwiązanie bardziej elastyczne niŜ JSP połączony z HTML-em — poszczególne komponenty nie są związane ze sobą tak ściśle. Standard XSP ma stanowić kluczowy element powstającej wersji 2.0 Cocoon.

Cocoon 2.0 i dalej Kolejna wersja Cocoon, o numerze 2.0 stanowi ogromny krok naprzód w porównaniu z wersjami wcześniejszymi. Cocoon 1.x, w którym przede wszystkim przetwarza się XML za pośrednictwem interfejsu XSL, jest wciąŜ w szerokim stopniu ograniczony. Po pierwsze, oprogramowanie to na razie nie przyczynia się do znacznego zmniejszenia kosztów utrzymania duŜych serwisów. Dokument XML moŜe zostać przekształcony w róŜne formy prezentacji, ale i tak na serwerze musi istnieć spora liczba dokumentów. Konieczne jest więc korzystanie z długich identyfikatorów URI

Cocoon 2.0 i dalej

236

(np. /content/publishing/books/javaxml/contents.xml), wielu odwzorowań wirtualnych ścieŜek (/javaxml odwzorowane na /content/publishing/books/javaxml/) albo z połączenia obu. Co więcej, wciąŜ nie jest łatwo odseparować prezentację od zawartości i logiki aplikacji. W projekcie Cocoon 2 skoncentrowano się na rozdzieleniu tych róŜnych warstw — ma to przyczynić się do zmniejszenia kosztów zarządzania witryną; całość ma skupiać się wokół standardu XSP. Plan witryny (o którym za chwilę) spowoduje, Ŝe uŜytkownik nie będzie widział róŜnicy pomiędzy stronami XSP, XML i statycznymi HTML. Wprowadzone zostaną równieŜ istotne zmiany w kompilacji i zarządzaniu pamięcią; Cocoon 2 będzie o tyle bardziej zaawansowany od Cocoon 1.x, o ile Cocoon 1.x był bardziej zaawansowany od zwykłego serwera WWW.

Odwzorowania w mechanizmie serwletów Istotna zmiana w Cocoon 2 polega na tym, Ŝe nie będzie juŜ trzeba stosować prostego odwzorowywania dokumentów XML. Odwzorowanie takie spisuje się nieźle w modelu 1.x, ale zarządzanie dokumentami innymi niŜ XML zrzucane jest na barki webmastera — osoby niekoniecznie związanej z administratorem odpowiedzialnym za dokumenty XML. Cocoon 2 ma umoŜliwić zarządzanie całą witryną. Główny serwlet Cocoon (org.apache.cocoon.servlet.CocoonServlet w modelu 2.0) jest zazwyczaj odwzorowywany na identyfikator URI, np. /Cocoon. MoŜliwe jest takŜe odwzorowanie na katalog główny całego serwera (czyli /) i tym samym sterowanie całą witryną. Adres URL przyjmuje postać wynikającą z takiego odwzorowania, np. http://mojHost.com/ Cocoon/mojaStrona.xml lub http://mojHost.com/Cocoon/mojaDynamicznaStrona.xsp. Przy takim odwzorowaniu nawet statyczne dokumenty HTML moŜna grupować z dokumentami XML. MoŜliwe jest więc centralne zarządzanie wszystkimi plikami umieszczonymi na serwerze. Jeśli dokumenty HTML i XML pojawią się w jednym katalogu, nie będzie kłopotu z ich oddzielną obsługą ani z tworzeniem identyfikatorów URI. Cocoon 2 będzie obsługiwał HTML oraz dane wszelkiego innego typu; po odwzorowaniu głównego katalogu serwera na Cocoon cała struktura publikacji staje się niewidoczna dla klienta.

Plan witryny Kolejną waŜną nowością w Cocoon 2 jest plan witryny (ang. sitemap). W strukturze Cocoon plan witryny stanowi centralne miejsce administracji serwisem. Na podstawie tego planu Cocoon decyduje o tym, jak przetwarzać otrzymany identyfikator URI. Na przykład, kiedy otrzymuje Ŝądanie w rodzaju http://mojaWitrynaCocoon.com/Cocoon/javaxml/chapterOne.html, serwlet Cocoon bada Ŝądanie i określa, Ŝe faktycznie Ŝądano /javaxml/chapterOne.html. ZałóŜmy jednak, Ŝe chapterOne.html nie ma być odwzorowywany na statyczny plik HTML, ale na wynik transformacji dokumentu XML (jak w naszych wcześniejszych przykładach). Tu właśnie przydaje się plan witryny. Spójrzmy na plan witryny w przykładzie 9.12.

Przykład 9.12. Przykładowy plan witryny w Cocoon 2.0

Cocoon 2.0 i dalej

237

Definicja DTD planu witryny jest juŜ na ukończeniu, ale w trakcie testowania beta mogą zostać wprowadzone zmiany. PowyŜszy przykład naleŜy traktować jako zarys moŜliwości Cocoon 2, a nie faktycznie działający kod.

Cocoon dopasowuje identyfikator URI /javaxml/chapterOne.html do instrukcji planu witryny /javaxml/*.html. Następnie określa, Ŝe jest to faktyczny plik i Ŝe odnaleziony on zostanie po uŜyciu odwzorowania /docs/javaxml/*.xml, tłumaczonego na /docs/javaxml/chapterOne.xml (nazwa pliku, którą chcemy przetworzyć). Następnie stosowany jest filtr XSLT; wykorzystywany arkusz stylu, JavaXML.html.xsl, jest takŜe określany w planie witryny. Wynik transformacji wyświetlany jest uŜytkownikowi. Co więcej, plik XML moŜe być plikiem XSP, przetwarzanym przed konwersją na XML. Według tego samego schematu generowany jest plik PDF z Ŝądania http://mojaWitrynaCocoon.com/Cocoon/javaxml/chapterOne.pdf — wystarczy tylko dodać parę wierszy do planu witryny (patrz wyŜej). Oznacza to równieŜ, Ŝe instrukcje przetwarzania w indywidualnych dokumentach moŜna usunąć, co stanowi istotną zmianę w stosunku do Cocoon 1.x. Stosowanie arkuszy stylów i przetwarzania odbywa się na podstawie połoŜenia katalogu. Wystarczy stworzyć dokument XML i umieścić go w katalogu /docs/javaxml (zgodnie z powyŜszym przykładem), a dokument ten będzie moŜna pobrać jako HTML lub PDF. Zmiana arkuszy stylów wykorzystywanych w dokumentach jest równieŜ banalna — w poprzedniej wersji był to proces kłopotliwy. Zamiast zmieniać kaŜdy dokument XML, wystarczy zmienić jeden wiersz w planie witryny. Plan witryny jest wciąŜ w trakcie rozwoju i prawdopodobnie będzie jeszcze zmieniany. Aby przyłączyć się do prac, naleŜy zapisać się na listy adresowe [email protected] i [email protected]. Pod adresem http://xml.apache.org moŜna znaleźć szczegółowe informacje o całym projekcie Cocoon.

Producenty i procesory Ostatnim istotnym ulepszeniem w strukturze Cocoon 2 jest wprowadzenie wstępnie kompilowanych i skoncentrowanych wokół zdarzeń producentów i procesorów (ang. producers, processors). W strukturze Cocoon producent obsługuje transformację Ŝądania URI na strumień danych XML. Procesor pobiera następnie strumień wejściowy (obecnie w postaci dokumentu XML w drzewie DOM) i wysyła dane wyjściowe moŜliwe do odczytania przez klienta. Nie omówiliśmy tych komponentów w modelu Cocoon 1.x, poniewaŜ w modelu 2.0 ulegną one bardzo duŜym zmianom; te, które uŜywane są obecnie, staną się prawdopodobnie bezuŜyteczne i trzeba będzie je przepisać. W Cocoon 2 zrezygnowano z uŜywania w tych strukturach modelu DOM na rzecz bardziej skoncentrowanego wokół zdarzeń SAX-a (a nawet JDOM-a!), „opakowanego” strukturą DOM. Do tej pory producent musiał generować dokument XML w pamięci i odpowiadająca mu struktura DOM mogła rozrosnąć się do wielkich rozmiarów. To powodowało wyczerpanie zasobów systemowych,

Co dalej?

238

szczególnie w tak skomplikowanych zadaniach jak złoŜone transformacje czy obsługa obiektów formatujących (generowanie PDF). Dlatego DOM będzie teraz tylko „interfejsem” do zdarzeń SAX, a producenty i procesory zyskają na wydajności. Producenty i procesory będą kompilowane z innych formatów. Na przykład arkusze XSL moŜna skompilować do procesorów, a strony XSP — do producentów. To jeszcze bardziej zwiększa wydajność i zdejmuje cięŜar przetwarzania z klienta. Tutaj i wszędzie indziej wykorzystywany będzie podział na poszczególne komponenty — nowy Cocoon będzie dzięki temu bardziej elastyczny i łatwy w rozbudowie. Najnowsze wiadomości dotyczące nowego projektu moŜna znaleźć na stronie WWW Cocoon.

Co dalej? W następnym rozdziale zostanie omówiona technologia umoŜliwiająca wykorzystanie XML-a jako formatu danych w modelu Ŝądań i odpowiedzi XML-RPC. Rozproszony system wywoływania zdalnych procedur XML-RPC umoŜliwia wykonywanie zadań na serwerze (lub serwerach) znajdujących się w innej części sieci. Do niedawna nie cieszył się on zbytnią popularnością, co spowodowane było przede wszystkim napływem technologii opartych na RMI i związanych z Javą (szczególnie EJB). JednakŜe przy wykorzystaniu XML-a jako formatu danych, XML-RPC umoŜliwia rozwiązanie wielu problemów.

RPC kontra RMI

239

10 XML-RPC W tym rozdziale zostanie omówione kolejne ciekawe zastosowanie języka XML — model Ŝądań i odpowiedzi XML-RPC. XML-RPC to po prostu specyficzna odmiana RPC, czyli technologii wywoływania zdalnych procedur. Jeśli Czytelnik nie jest doświadczonym programistą, bądź teŜ do tej pory posługiwał się tylko językiem Java, pojęcie zdalnego wywoływania procedur moŜe być mu obce; dla innych zaś poruszanie tego tematu moŜe wydać się dziwne — RPC w ostatnich czasach stracił na popularności. W trakcie lektury niniejszego rozdziału Czytelnik dowie się, dlaczego te trzy niepozorne literki przed skrótem RPC zrewolucjonizowały coś, co wydawało się być dinozaurem w świecie programistycznym. Czytelnik nauczy się równieŜ korzystać z XML-RPC z poziomu programów w Javie. Zakończenie rozdziału poświęcone jest praktycznym zastosowaniom modeli XML-RPC. Jeśli Czytelnik poddał się fali programowania obiektowego, tak popularnego w ostatnich latach, to pewnie wzdryga się na dźwięk słowa „procedura”. Języki proceduralne, takie jak PL/SQL czy ANSI C, nie są „modne” i jest ku temu wiele powodów. Zapewne niejednokrotnie Czytelnikowi zdarzyło się „oberwać” za nazwanie metody Javy funkcją lub procedurą; wie teŜ, jak unikać „kodu spaghetti” — czyli kodu polegającego na łączeniu wielu metod w jeden długi łańcuch. Wraz z tymi językami i sposobami programowania odsunięto na bok technologię RPC — nowe, obiektowe techniki umoŜliwiają osiągnięcie tych samych rezultatów przy bardziej przejrzystej strukturze programu i większej wydajności. Jednak, co ciekawe, popularyzacja XML-a przyczyniła się do upowszechnienia interfejsów API zbudowanych z myślą o XML-RPC oraz do coraz częstszego wykorzystywania XML-RPC mimo niedobrych skojarzeń, jakie się z tym skrótem wiąŜą. Zanim Czytelnik zacznie stosować te interfejsy, powinien przyjrzeć się technologii RPC i porównać ją z podobnymi rozwiązaniami Javy, a szczególnie z technologią RMI (Remote Method Invocation). Jeśli zdecydujemy się na wykorzystanie XML-RPC w aplikacji (a na pewnym etapie pracy z pewnością tak się stanie), na pewno będziemy musieli uzasadnić swój wybór innym programistom — szczególnie tym, którzy mają właśnie za sobą lekturę o EJB czy RMI. Wszystkie te technologie mają na pewno swoje miejsce, ale zrozumienie właściwego ich stosowania jest bardzo istotne. Najbardziej popularnymi sposobami operowania na obiektach poprzez sieć są RPC i RMI.

RPC kontra RMI Technologia RMI zyskuje ogromną popularność wśród programistów Javy. Cała specyfikacja EJB (Enterprise JavaBeans) została oparta na bazie RMI; umiejętność pisania trzywarstwowych aplika-

RPC kontra RMI

240

cji RMI jest koniecznością. Jeśli Czytelnik jeszcze tego nie potrafi, powinien sięgnąć po Java Enterprise in a Nutshell (autorzy: David Flanagan, Jim Farley, William Crawford i Kris Magnusson) lub Java Distributed Computing Jima Farleya (obie ksiąŜki wydawnictwa O'Reilly & Associates).

Co to jest RMI? Technologia RMI to wywoływanie zdalnych metod (remote method invocation). Koncepcja wydaje się dość prosta — RMI umoŜliwia wywoływanie metod na obiekcie znajdującym się na innym komputerze niŜ program. Na tym opiera się całe programowanie rozproszone w Javie i to właśnie stanowi szkielet technologii EJB oraz wielu implementacji aplikacji dla przedsiębiorstw. Bez zagłębiania się w detale moŜna powiedzieć, Ŝe RMI za pomocą procedur pośredniczących (ang. stub) oraz szkieletów opisuje metody dostępne do zdalnego wywołania. Klient wykorzystuje owe procedury pośredniczące (zazwyczaj mające postać interfejsów Javy), a RMI obsługuje całą „magię” tłumaczenia Ŝądań wysyłanych do procedury pośredniczącej na wywołania sieciowe. Metoda działa na faktycznym obiekcie komputera zdalnego; wynik przesyłany jest z powrotem drogą sieciową. Na koniec procedura pośrednicząca zwraca wynik klientowi, który jako pierwszy wywołał metodę, i klient moŜe działać dalej. Przede wszystkim trzeba pamiętać, Ŝe klienta „nie interesują” szczegółowe zasady działania RMI i sieci; procedura pośrednicząca wykorzystywana jest tak, jak gdyby był to faktyczny obiekt implementujący określone metody. Technologia RMI (za pomocą protokołu zdalnego JRMP™) działa tak, Ŝe cała komunikacja sieciowa odbywa się poza kulisami; klient ma dostęp do ogólnego wyjątku (java.rmi.RemoteException), a programista moŜe skupić się na regułach biznesowych i logice aplikacji. Technologia RMI umoŜliwia równieŜ korzystanie z róŜnych protokołów (np. Internet Inter-ORB Protocol) — dzięki temu moŜna uruchomić komunikację pomiędzy obiektami Java i CORBA, często takŜe w innych językach, np. C lub C++. Technologia RMI ma równieŜ jednak pewne wady. Po pierwsze, intensywnie wykorzystuje zasoby. UŜywanych jest całkiem sporo klas i choć stanowią one standardowe wyposaŜenie pakietu JDK, to przecieŜ stworzenie ich egzemplarza pochłania pamięć i inne zasoby. Protokół JRMP charakteryzuje się słabą wydajnością, a zastąpienie go wcale nie jest prostym zadaniem. Kiedy klienty wysyłają Ŝądania RMI, muszą zostać otwarte i utrzymane gniazda, a im jest ich więcej, tym bardziej spada wydajność systemu — szczególnie wtedy, gdy system dostępny jest w sieci (wtedy dla dostępu HTTP konieczne jest otworzenie dalszych gniazd). Technologia RMI wymaga równieŜ istnienia serwera lub usługodawcy, do których moŜna dowiązać obiekty. Dopóki obiekt nie zostanie dowiązany do nazwy odpowiadającej takiemu usługodawcy, dopóty nie będzie dostępny z poziomu innych programów. To wymaga uŜycia rejestru RMI, serwera usług katalogowych LDAP lub innych usług typu Java Naming and Directory Interface (JNDI). I jeszcze jedno — korzystanie z RMI moŜe wiązać się z koniecznością pisania duŜej ilości kodu, nawet biorąc pod uwagę to, jak wiele pomocnych klas udostępnia JDK. Konieczne jest zaprogramowanie zdalnego interfejsu opisującego metody dostępne do wywołania oraz (jeśli korzystamy z EJB) szeregu innych interfejsów. Oznacza to równieŜ, Ŝe oddanie kolejnej metody do klasy serwera powoduje zmianę interfejsu i przekompilowanie procedur pośredniczących, co często nie jest poŜądane (a niejednokrotnie jest po prostu niemoŜliwe).

Co to jest RPC? Technologia RPC to wywoływanie zdalnych procedur (remote procedure calls). RMI umoŜliwia bezpośrednie działanie na obiekcie Javy, natomiast RPC pozwala korzystać z metod samodzielnych (tak, tutaj nazywane są one procedurami!) za pośrednictwem sieci. To ogranicza interaktywność, ale upraszcza interfejs, z którym komunikuje się klient. Technologię RPC moŜna sobie wyobrazić

RPC kontra RMI

241

jako sposób korzystania z „usług” komputerów zdalnych, z kolei RMI umoŜliwia korzystanie z „serwerów”. Z tej subtelnej róŜnicy wynika fakt, Ŝe proces RMI jest zazwyczaj sterowany w całości przez klienta — zdarzenia następują po zdalnym wywołaniu metod. RPC to częściej klasa lub zestaw klas wykonujących zadania bez interwencji klienta; jednakŜe czasami klasy te obsługują Ŝądania przesłane przez klienty i wykonują ich „minizadania”. Przedstawione w dalszej części rozdziału przykłady pomogą zrozumieć te teoretyczne wywody. RPC nie jest środowiskiem tak interaktywnym jak RMI, ale oferuje szereg zalet względem tego ostatniego. UmoŜliwia współpracę oddzielnych systemów. Technologia RMI pozwala co prawda na łączenie Javy z serwerami i klientami CORBA (poprzez IIOP), ale RPC umoŜliwia komunikację dosłownie dowolnych aplikacji — protokołem transportowym moŜe być bowiem HTTP. PoniewaŜ niemal dowolny wykorzystywany obecnie język oferuje sposób komunikacji za pośrednictwem HTTP, RPC stanowi niezwykle atrakcyjne rozwiązanie w przypadku tych zastosowań, w których konieczne jest porozumiewanie się z systemami zastanymi. RPC jest zazwyczaj równieŜ mniej „zasoboŜerny” niŜ RMI (szczególnie wtedy, gdy do kodowania wykorzystywany jest XML — o czym za chwilę); RMI często wymaga przesłania przez sieć całych klas Javy (np. kodów apletów czy własnych klas pomocniczych EJB), a RPC musi tylko przekazać przez sieć parametry Ŝądania i wynik działania, zazwyczaj w postaci danych tekstowych. RPC pasuje równieŜ świetnie do modelu interfejsów API — systemy nie stanowiące części określonej aplikacji i tak mogą pobierać z niej informacje; oznacza to, Ŝe zmiany poczynione w serwerze nie przekładają się na zmiany w kodzie aplikacji klientów. Przy transferze opartym na zwykłym tekście dodatkowe metody moŜna dodawać bez konieczności rekompilacji klienta; uŜycie tych metod wymaga zaś tylko niewielkich zmian. Odwieczny problem z technologią RPC związany jest z kodowaniem przesyłanych danych. Wyobraźmy sobie, Ŝe chcemy stworzyć tekstową i niewielką objętościowo reprezentację struktur Javy Hastable lub Vector. Jeśli weźmiemy pod uwagę, Ŝe te struktury mogą z kolei zawierać inne obiekty Javy, taka reprezentacja nagle przestaje być zadaniem banalnym; stworzony format musi ponadto nadawać się do uŜycia przez dowolne języki programowania — inaczej umniejszymy korzyści płynące z zastosowania technologii RPC. Do niedawna zachodziła odwrotnie proporcjonalna relacja pomiędzy jakością i uŜytecznością kodowania w RPC a jego prostotą; innymi słowy, im prościej reprezentowane były złoŜone obiekty, tym trudniej było wykorzystać takie kodowanie w wielu językach bez tworzenia dodatkowego, własnego kodu. Rozbudowane tekstowe reprezentacje danych nie zostały ustandaryzowane i wymagały całkowicie nowych implementacji w poszczególnych językach. W tej chwili Czytelnik zapewne domyśla się juŜ, do czego zmierzam.

XML-RPC Największą przeszkodą w uŜywaniu technologii RPC był zawsze sposób kodowania. Kiedy pojawił się XML-RPC, wszystko uległo zmianie. XML oferował nie tylko prostą, tekstową reprezentację danych; stanowił takŜe standard strukturyzacji danych. Kiedy grupa W3C opublikowała specyfikację XML 1.0, zniknęły obawy o konieczność stosowania rozwiązań własnych — korzystający z RPC mieli pewność, Ŝe XML w najbliŜszym czasie nie sprawi im Ŝadnej niespodzianki. Co więcej, standard SAX stworzył moŜliwość uzyskania dostępu do XML-a w sposób wydajny i standardowy; to uprościło implementację bibliotek RPC. Pozostała więc juŜ tylko do uruchomienia transmisja poprzez HTTP (coś, co robimy juŜ od ponad 10 lat) oraz specyficzne interfejsy kodowania i dekodowania. Po kilku implementacjach beta bibliotek XML-RPC stało się jasne, Ŝe oprócz pozostałych zalet, XML jest równieŜ szybki i mało wymagający — wydajność bibliotek XML-RPC była większa niŜ oczekiwano. Model XML-RPC stanowi obecnie pręŜne i stabilne rozwiązanie zdalnego wywoływania procedur.

Powiedział „Witaj!”

242

Czytelnikowi, jako programiście Javy, XML-RPC oferuje sposób prostego tworzenia „punktów zaczepienia” w aplikacji i usługach, zarówno do uŜytku własnego, jak i do wykorzystania przez klienty aplikacji w róŜnych oddziałach, a nawet firmach. Interfejsy API są odseparowane od Javy, klienty nie muszą więc korzystać bezpośrednio z tego języka. Ponadto dzięki XML-RPC nie trzeba juŜ się uczyć o RMI, aby korzystać z usług rozproszonych (przynajmniej na początku). Niniejszy rozdział stanowi opis implementacji serwera i klienta XML-RPC. Czytelnik przekona się równieŜ, Ŝe serwer moŜe działać niezaleŜnie od klientów, wciąŜ jednak udostępniając interfejsy współpracujące z XML-RPC i pozwalając na komunikację i pobieranie danych. Porównanie technologii RMI z XML-RPC pozwoli wykazać wyŜszość tego ostatniego w wielu zastosowaniach.

Powiedział „Witaj!” Jeśli Czytelnikowi udało się przebrnąć przez te kilka stron wywodów o zdalnym wywoływaniu procedur, z pewnością jest przekonany, Ŝe XML-RPC to narzędzie przydatne i Ŝe moŜe rozwiązać wiele problemów programistycznych. Aby rozwinąć temat, spróbujemy teraz zbudować prawdziwy program wykorzystujący tę technologię. Zgodnie z tradycją, zaczniemy od prostego programu „Witaj świecie!”. W naszym serwerze XML-RPC zostanie zarejestrowana procedura obsługi. Procedura ta pobiera parametr String Javy (nazwę uŜytkownika) i zwraca łańcuch zawierający „Witaj” oraz pobraną nazwę, np. „Witaj Brett”. Następnie procedura ta zostanie udostępniona przez serwer klientom XML-RPC. Na koniec stworzymy prostego klienta łączącego się z serwerem i Ŝądającego wywołania tej metody. W rzeczywistości serwer i procedura obsługi XML-RPC znajdowałyby się na jednym komputerze (zazwyczaj wydajnym serwerze), a klient na innym i cała operacja odbywałaby się zdalnie. JednakŜe, jeśli nie mamy pod ręką kilku komputerów, przykłady moŜemy przećwiczyć lokalnie. Proces będzie przebiegał wtedy szybciej niŜ w rzeczywistym zastosowaniu, ale i tak będzie moŜna zaobserwować, jak poszczególne elementy układają się w jedną całość i jak ten cały XML-RPC działa.

Skąd wziąć biblioteki XML-RPC? Jak to zostało powiedziane wcześniej, w rozwój RPC, a ostatnio XML-RPC, włoŜono juŜ wiele pracy. Podobnie jak w przypadku uŜywania interfejsów SAX, DOM i JDOM do obsługi XML-a, nie trzeba drugi raz wynajdywać koła — na pewno istnieją dobre, a nawet świetne pakiety Javy spełniające nasze potrzeby. Centrum informacji o XML-RPC, a takŜe zasób odsyłaczy do odpowiednich bibliotek Javy i innych języków stanowi witryna pod adresem http://www.xml-rpc.com. Serwis ten, sponsorowany przez Userland (http://www.userland.com), zawiera publiczną specyfikację XML-RPC, informacje o obsługiwanych typach danych i samouczki. Co waŜniejsze jednak, moŜna tam znaleźć odsyłacz do miejsca w sieci, z którego pobierzemy pakiet XML-RPC dla Javy, a mianowicie do strony Hannesa Wallnofera http://helma.at/hannes/xmlrpc. Na stronie tej znajduje się opis klas zawartych w pakiecie XML-RPC Hannesa, a takŜe instrukcja ich obsługi. Pobieramy archiwum i rozpakowujemy je w katalogu roboczym lub środowisku programistycznym IDE. Następnie kompilujemy klasy; jeden z przykładów serwletów wymaga obecności klas serwleta (servlet.jar dla interfejsu Servlet PI 2.2). Odpowiednią klasę dla mechanizmu serwletów Tomcat znaleźć moŜna na stronie http://jakarta.apache.org. Jeśli Czytelnik nie zamierza „bawić się” przykładem z serwletem, to nie musi go kompilować — nie jest on wymagany do wykonania przykładów w tym rozdziale.

Powiedział „Witaj!”

243

Klasy XML-RPC są spakowane w pliku zip, xmlrpc-java.zip. Z tego archiwum trzeba wydobyć cały kod źródłowy znajdujący się w katalogu xmlrpc-java/src/. Nie dołączono dystrybucji w postaci jar, więc wymagana jest ręczna kompilacja klas. Po skompilowaniu Czytelnik moŜe sam utworzyć archiwum jar, co uprości włączanie klas do ścieŜki. (W wersji pobranej przez tłumacza w styczniu 2001 r. odpowiedni plik jar był juŜ dołączony — przyp. tłum.).

Zasadnicza dystrybucja (nie zawierająca przykładów apletów i wyraŜeń regularnych) składa się z ośmiu klas pakietu helma.xmlrpc: klasa zasadnicza XmlRpc, klient XmlRpcClient, serwer XmlRpcServer, XmlRpcHandler (precyzyjne sterowanie kodowaniem i przetwarzaniem XML-a) oraz szereg klas pomocniczych. Klasy zgłaszają wyjątek XmlRpcException; natomiast XmlRpcServlet demonstruje uŜycie serwleta jako procedury obsługi odpowiedzi HTTP; z kolei WebServer to „lekki” serwer HTTP zbudowany specjalnie do obsługi Ŝądań XML-RPC; zaś Benchmark umoŜliwia zmierzenie czasu obsługi Ŝądania XML-RPC z wykorzystaniem specyficznego sterownika SAX. Wymagane do pracy całego mechanizmu, a nie zawarte w dystrybucji, są klasy SAX (które Czytelnik powinien posiadać po wykonaniu wcześniejszych przykładów) oraz sterownik SAX; innymi słowy, trzeba mieć kompletną implementację parsera XML obsługującą SAX. W naszych przykładach będziemy ponownie korzystali z parsera Apache Xerces, ale biblioteki obsługują dowolny parser zgodny z SAX 1.0. Po skompilowaniu plików źródłowych naleŜy upewnić się, czy klasy XML-RPC, SAX i parsera XML znajdują się w ścieŜce dostępu do klas. Po tym Czytelnik powinien juŜ potrafić napisać pierwszy program. Warto trzymać gdzieś pod ręką pliki źródłowe XML-RPC, bo pozwalają one na podejrzenie, co dzieje się „pod maską” naszego przykładu.

Pisanie procedury obsługi Po pierwsze, konieczne jest napisanie klasy i metody, która ma być uruchamiana zdalnie. Nazywa się ją zazwyczaj procedurą obsługi. Pamiętajmy jednak, Ŝe mechanizm XML-RPC obsługujący Ŝądania często określany jest taką samą nazwą — znów daje się we znaki dwuznaczność przyjętego nazewnictwa. Procedura obsługi XML_RPC to metoda lub metody pobierające Ŝądanie XML-RPC, dekodujące jego zawartość i oddelegowujące to Ŝądanie do jakiejś klasy lub metody. Procedura obsługi odpowiedzi, czy teŜ po prostu procedura obsługi, to metoda wywoływana przez procedurę obsługi XML-RPC. Posiadając biblioteki XML-RPC dla Javy, nie musimy pisać procedury obsługi XML-RPC, poniewaŜ jest juŜ ona zawarta w klasie helma.xmlrpc.XmlRpcServer. Trzeba jedynie napisać klasę z jedną lub dwoma metodami, które zamierzamy zarejestrować w serwerze. Niespodzianką jest fakt, Ŝe tworzenie procedury obsługi nie wymaga budowania podklas ani innych specjalnych zabiegów w kodzie. Poprzez XML-RPC moŜna wywołać dowolną metodę, o ile tylko XML-RPC obsługuje jej parametry i zwracany typ danych (potrafi je zakodować). W tabeli 10.1 przedstawiono wszystkie obecnie obsługiwane typy Javy, jakie moŜna wykorzystać w sygnaturach metod XML-RPC. Lista zawiera tylko nieliczne typy, ale — jak się okazuje — umoŜliwiają one obsługę większości Ŝądań XML-RPC wysyłanych poprzez sieć. PoniewaŜ my chcemy pobrać tylko jeden parametr String i równieŜ String zwrócić, w naszym programie powyŜsze typy zupełnie wystarczą. Zbudujmy więc teraz prostą klasę procedury obsługi (przykład 10.1).

Powiedział „Witaj!”

244

Tabela 10.1. Typy Javy obsługiwane przez XML-RPC Typ danych XML-RPC

Typ danych Javy

int boolean string double dateTime.iso8601 struct array base64

int boolean java.lang.String double java.util.Date 1 java.util.Hashtable 1 java.util.Vector byte[]

Przykład 10.1. Klasa procedury obsługi z metodą uruchamianą zdalnie /** * HelloHandler to prosta procedura obsługi * rejestrowana w serwerze XML-RPC. * * @author Brett McLaughlin * @version 1.0 */ public class HelloHandler { /** *

* Pobieramy String i zwracamy komunikat * powitalny wskazanemu uŜytkownikowi. *

* * @param name String nazwa uŜytkownika. * @return String - komunikat Witaj. */ public String sayHello(String name) { return "Witaj " + name; } }

I to naprawdę tylko tyle. Metoda pobiera i zwraca dozwolone parametry XML-RPC, a więc moŜemy spokojnie zarejestrować ją w serwerze XML-RPC — mamy gwarantowane, Ŝe będzie ją moŜna przez XML-RPC wywołać.

Budowanie serwera Skoro procedura obsługi jest juŜ gotowa, musimy napisać program uruchamiający serwer XMLRPC, nasłuchujący Ŝądań i przekazujący je do procedury obsługi. W naszym przypadku w funkcji procedury obsługującej Ŝądania wykorzystamy klasę helma.xmlrpc.WebServer. MoŜna byłoby w tym celu uŜyć serwletu Javy, ale skorzystanie z „lekkiej” implementacji serwera pozwoli uniknąć konieczności uruchamiania mechanizmu serwletów. W zakończeniu rozdziału zostaną omówione serwlety w kontekście serwera XML-RPC. Wracając do naszego serwera — chcemy pozwolić na określenie portu, na którym serwer zostanie uruchomiony, a następnie spowodować, aby 1

Oczywiście, typy struct i array muszą zawierać tylko inne dozwolone typy XML-RPC.

Powiedział „Witaj!”

245

serwer nasłuchiwał Ŝądań XML-RPC dopóty, dopóki nie zostanie wyłączony. Następnie zarejestrujemy w tym serwerze stworzoną wcześniej klasę i określimy inne parametry specyficzne dla naszej aplikacji. Stwórzmy teraz szkielet tej klasy (przykład 10.2); konieczne jest zaimportowanie klasy WebServer oraz pobranie portu z wiersza poleceń.

Przykład 10.2. Szkielet serwera XML-RPC „Witaj!” import helma.xmlrpc.WebServer;

/** * HelloServer to prosty serwer XML-RPC, * który udostępni klasę HelloHandler * wywołaniom XML-RPC. * * @author Brett McLaughlin * @version 1.0 */ public class HelloServer { /** *

* Uruchamiamy serwer XML-RPC i rejestrujemy procedurę obsługi. *

*/ public static void main(String[] args) { if (args.length < 1) { System.out.println( "UŜycie: java HelloServer [port]"); System.exit(-1); } // Tu uruchomimy serwer na określonym porcie } }

Przed uruchomieniem serwera trzeba podać sterownik SAX, jaki zostanie wykorzystany do przetworzenia i kodowania XML. Domyślny sterownik SAX dla tych bibliotek to parser XP Jamesa Clarka (http://www.jclark.com). Jednak w naszym przykładzie zastosujemy parser Apache Xerces, określając w mechanizmie XML-RPC implementację SAX Parser2. Czynność tę wykonuje się poprzez wywołanie statycznej metody setDriver(), naleŜącej do klasy XmlRpc. Klasa ta leŜy u podstaw klasy WebServer, ale w celu uŜycia określonych sterowników SAX konieczne jest oddzielne jej zaimportowanie i bezpośrednie uŜycie. Metoda zgłasza wyjątek ClassNotFoundException, a więc trzeba go przechwycić w celu określenia, czy klasa sterownika została odnaleziona. Wprowadźmy teraz opisywane zmiany:

2

Obecnie nie istnieją biblioteki XML-RPC obsługujące SAX 2.0 i implementujące interfejs XMLReader. Oczekuje się, Ŝe wkrótce ten stan rzeczy ulegnie zmianie; poniewaŜ klasa Apache Xerces SAXParser implementuje zarówno stary, jak i nowy interfejs, po aktualizacji XML-RPC do SAX-a 2.0 nie trzeba będzie wprowadzać w kodzie Ŝadnych zmian. Jeśli jednak korzystamy z parsera innego producenta, moŜe się okazać konieczne jawne określenie klasy SAX 2.0.

Powiedział „Witaj!”

246

import helma.xmlrpc.WebServer; import helma.xmlrpc.XmlRpc; ... /** *

* Uruchamiamy serwer XML-RPC i rejestrujemy procedurę obsługi. *

*/ public static void main(String[] args) { if (args.length < 1) { System.out.println( "UŜycie: java HelloServer [port]"); System.exit(-1); }

Powiedział „Witaj!”

247

try { // Korzystamy ze sterownika Apache Xerces SAX XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser"); // Uruchamiamy serwer System.out.println("Uruchamianie serwera XML-RPC..."); WebServer server = new WebServer(Integer.parseInt(args[0])); } catch (ClassNotFoundException e) { System.out.println("Nie odnaleziono sterownika SAX"); } catch (IOException e) { System.out.println("Uruchomienie serwera nie jest moŜliwe: " + e.getMessage()); } } ...

MoŜemy teraz skompilować i wypróbować powyŜszą klasę. Powinien zostać wyświetlony komunikat o stanie, a następnie program powinien zatrzymać się, oczekując na Ŝądania. Teraz trzeba dodać klasę procedury obsługi przyjmującą Ŝądania. Jedną z najistotniejszych róŜnic pomiędzy technologiami RMI i RPC jest sposób udostępniania metod. W RMI zdalny interfejs posiada sygnatury metod odpowiadające wszystkim metodom zdalnym. Jeśli metoda implementowana jest na klasie serwera, ale do zdalnego interfejsu nie dodano pasującej sygnatury, nowa metoda nie będzie mogła zostać wywołana przez klienta RMI. Z całym procesem łączy się więc konieczność modyfikacji sporej ilości kodu i rekompilacji klas RMI. W RPC wszystko to wygląda inaczej — a sposób obsługi uznawany jest za elastyczniejszy i prostszy. Serwer RPC otrzymuje Ŝądanie zawierające parametry i wartość tekstową (zazwyczaj w postaci „nazwaklasy.nazwametody”). Serwer RPC „widzi”, Ŝe metoda znajduje się w klasie „nazwaklasy” i nosi nazwę „nazwametody”. Próbuje więc odnaleźć pasującą klasę i metodę pobierającą parametr takiego typu, jaki jest w Ŝądaniu RPC. Po znalezieniu określona metoda zostaje wywołana, a rezultat tego wywołania jest kodowany i odsyłany klientowi. Całe to nieco zawiłe wyjaśnienie sprowadza się do jednego — Ŝądana metoda nigdy nie jest jawnie definiowana w serwerze XML-RPC, a jedynie w Ŝądaniu otrzymanym od klienta. W serwerze rejestrowany jest jedynie egzemplarz klasy. Do klasy tej moŜna dodawać metody, a ich udostępnienie wymaga jedynie ponownego uruchomienia serwera — a nie zmian w kodzie. O ile tylko potrafimy określić i wysłać poprawne parametry do serwera, to metoda taka jest od razu dostępna. To właśnie jedna z zalet XML-RPC względem RMI — interfejs API jest reprezentowany w sposób bliŜszy rzeczywistości; w kliencie nie trzeba aktualizować Ŝadnych procedur pośredniczących, szkieletów czy interfejsów. Po dodaniu metody jej sygnatura moŜe zostać opublikowana klientom i natychmiast wykorzystana. Skoro wiemy juŜ, w jak prosty sposób wykorzystywana jest procedura obsługi RPC, zarejestrujmy taką procedurę w naszym przykładzie. Klasa WebServer umoŜliwia dodanie procedury poprzez metodę addHandler(). Metoda ta jako dane wejściowe pobiera nazwę, pod jaką procedura obsługi zostanie zarejestrowana, oraz sam egzemplarz klasy tej procedury. Zazwyczaj tworzy się w tym celu egzemplarz nowej klasy za pomocą jej konstruktora (poprzez słowo kluczowe new), choć w dalszej części Czytelnik zobaczy, w jaki sposób moŜna zrobić to inaczej (gdy egzemplarz ma być współdzielony przez wiele klientów, a nie tworzony dla kaŜdego oddzielnie). Ale w poniŜszym przykładzie stworzenie egzemplarza nowej klasy jest dobrym rozwiązaniem. Zarejestrujemy klasę HelloHandler pod nazwą „hello”. Dodamy takŜe instrukcje wyświetlające dalsze komunikaty, tak by moŜliwe było „podejrzenie”, co dzieje się w serwerze w czasie dodawania procedury obsługi:

Powiedział „Witaj!”

248

import java.io.IOException; import helma.xmlrpc.WebServer; import helma.xmlrpc.XmlRpc; /** * HelloServer to prosty serwer XML-RPC, * który udostępni klasę HelloHandler * wywołaniom XML-RPC. * * @author Brett McLaughlin * @version 1.0 */ public class HelloServer { /** *

* Uruchamiamy serwer XML-RPC i rejestrujemy procedurę obsługi. *

*/ public static void main(String[] args) { if (args.length < 1) { System.out.println( "UŜycie: java HelloServer [port]"); System.exit(-1); } try { // Korzystamy ze sterownika Apache Xerces SAX XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser"); // Uruchamiamy serwer System.out.println("Uruchamianie serwera XML-RPC..."); WebServer server = new WebServer(Integer.parseInt(args[0])); // Rejestrujemy klasę procedury obsługi server.addHandler("hello", new HelloHandler()); System.out.println( "Klasa procedury obsługi zarejestrowana jako \"hello\""); System.out.println("Teraz czekamy na Ŝądania..."); } catch (ClassNotFoundException e) { System.out.println("Nie odnaleziono sterownika SAX"); } catch (IOException e) { System.out.println("Uruchomienie serwera nie jest moŜliwe: " + e.getMessage()); } } }

Po skompilowaniu powyŜszego kodu źródłowego moŜna uruchomić serwer. Wynik powinien być podobny do tego z przykładu 10.33.

3

Jeśli Czytelnik korzysta z systemu Unix i chce uruchomić usługę na porcie niŜszym niŜ 1024, musi być zalogowany jako root. Aby uniknąć problemu, warto skorzystać z wyŜszego portu, tak jak to pokazano na przykładzie.

Powiedział „Witaj!”

249

Przykład 10.3. Uruchamianie klasy serwera XML-RPC HelloServer [adam@maly ch10]$ java HelloServer 8585 Uruchamianie serwera XML-RPC... Klasa procedury obsługi zarejestrowana jako "hello" Teraz czekamy na Ŝądania...

Tak, to właśnie jest takie proste! Teraz moŜemy utworzyć klienta i „bawić się” komunikacją w sieci poprzez XML-RPC. To właśnie kolejna zaleta XML-RPC — niewiele potrzeba, aby taki mechanizm uruchomić, szczególnie jeśli porównamy to rozwiązanie z technologią RMI. W trakcie lektury kolejnego podrozdziału Czytelnik przekona się, Ŝe utworzenie klienta jest równie łatwe.

Budowanie klienta Skoro serwer działa i przyjmuje Ŝądania, to mamy juŜ za sobą najtrudniejszy etap programowania aplikacji XML-RPC (tak, to była ta trudniejsza część!). Teraz zbudujemy prostego klienta wywołującego zdalnie naszą metodę sayHello(). Korzystamy w tym celu z klasy helma.xmlrpc.XmlRpcClient. Odpowiedzialna jest ona za wiele czynności odbywających się po stronie klienta; jej odpowiednikami po stronie klienta są XmlRpcServer i WebServer. Aby utworzyć klienta, oprócz wspomnianej klasy będziemy jeszcze potrzebowali klasy XmlRpc — klient musi umieć zakodować Ŝądanie, a więc znów musimy ustawić klasę sterownika SAX do wykorzystania w metodzie setDriver(). Zacznijmy tworzenie klienta właśnie od tych waŜnych instrukcji, sprawdzając argument przekazywany do metody sayHello() na serwerze oraz wykonując podstawową obsługę wyjątków. Tworzymy plik źródłowy Javy HelloClient.java — taki jak w przykładzie 10.4.

Przykład 10.4. Klient XML-RPC import helma.xmlrpc.XmlRpc; import helma.xmlrpc.XmlRpcClient;

/** * HelloClient to prosty klient XML-RPC * wysyłający Ŝądanie do HelloServer. * * @author Brett McLaughlin * @version 1.0 */ public class HelloClient { /** *

* Łączymy się z serwerem XML-RPC i wysyłamy Ŝądanie. *

*/ public static void main(String args[]) { if (args.length < 1) { System.out.println( "UŜycie: java HelloClient [twoje imie]"); System.exit(-1); } try { // Korzystamy ze sterownika Apache Xerces SAX XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser"); // Określamy serwer XmlRpcClient client = new XmlRpcClient("http://localhost:8585/"); // Tworzymy Ŝądanie Vector params = new Vector(); params.addElement(args[0]); // Wysyłamy Ŝądanie i wyświetlamy wynik. String result = (String)client.execute("hello.sayHello", params); System.out.println("Odpowiedź serwera: " + result); } catch (ClassNotFoundException e) { System.out.println("Nie odnaleziono sterownika SAX"); } catch (MalformedURLException e) { System.out.println( "Niepoprawny format URL serwera XML-RPC: " + e.getMessage()); } catch (XmlRpcException e) { System.out.println("Wyjątek XML-RPC: " + e.getMessage()); } catch (IOException e) { System.out.println("Wyjątek IO: " + e.getMessage()); } } ...

To juŜ wszystko! Przykład kompilujemy i uruchamiamy zgodnie z poniŜszym opisem.

Po co się męczyć? Niech serwer nas wyręczy!

253

Mów do mnie... NaleŜy sprawdzić, czy w ścieŜce dostępu do klas znajdują się klasy XML-RPC i klasy opisywanych wyŜej przykładów. Musi się tam znaleźć równieŜ Apache Xerces lub inny sterownik SAX —z jego pomocą programy wykonują przetwarzanie. Kiedy klasy są juŜ dostępne, uruchamiamy serwer z odpowiednim numerem portu. W systemie Windows, aby uruchomić serwer jako oddzielny proces, korzystamy z polecenia start: D:\prod\Java and XML\WEB-INF\classes>start java HelloServer 8585 Uruchamianie serwera XML-RPC... Klasa procedury obsługi zarejestrowana jako "hello" Teraz czekamy na Ŝądania...

W systemach Unix uruchamiamy proces w tle (wstawiając na końcu &), co umoŜliwi nam uruchomienie na tej samej konsoli równieŜ klienta; ewentualnie klienta moŜna uruchomić na innej konsoli, kopiując wcześniej środowisko uruchomieniowe: $ java HelloServer 8585 & Uruchamianie serwera XML-RPC... Klasa procedury obsługi zarejestrowana jako "hello" Teraz czekamy na Ŝądania...

Teraz uruchamiamy klienta, jako argument wywołania podając własne imię. Wkrótce pojawi się odpowiedź podobna do tej w przykładzie 10.5 — serwer HelloServer otrzymał i obsłuŜył Ŝądanie oraz zwrócił wynik działania metody sayHello():

Przykład 10.5. Działanie klasy HelloClient $ java HelloClient Brett Odpowiedź serwera: Witaj Brett

I tak właśnie działa XML-RPC. Oczywiście, aplikacja taka jak powyŜsza nie jest zbyt przydatna, ale na pewno dobrze ilustruje podstawy działania i łatwość budowania serwera i klienta XML-RPC w Javie. Po takim wprowadzeniu moŜemy przejść do bardziej realistycznego przykładu. W dalszej części rozdziału zbudujemy praktyczniejszy i poŜyteczniejszy serwer; Czytelnik będzie mógł równieŜ zobaczyć, jak wyglądają procedury obsługi XML-RPC. Następnie stworzymy klienta (podobnego do HelloClient) i przetestujemy działanie nowego kodu.

Po co się męczyć? Niech serwer nas wyręczy! Opisany wyŜej przykład Hello dobrze demonstruje sposób korzystania z XML-RPC w Javie, ale nie jest zbyt realistyczny. Kod jest banalny, serwer mało elastyczny, a sama procedura obsługi nie ukazuje praktycznego zastosowania technologii XML-RPC. PoniŜej przedstawione zostanie zastosowanie technologii XML-RPC w środowisku produkcyjnym — zbudujemy bardziej uŜyteczną procedurę obsługi i bardziej praktyczny serwer. Kod taki, choć moŜe wciąŜ jeszcze nieprzydatny w „prawdziwym” projekcie, na pewno zilustruje, do czego Czytelnik mógłby wykorzystać model XML-RPC w swojej przyszłej pracy.

WspółuŜytkowana procedura obsługi Utworzona wcześniej klasa HelloHandler była prosta i... bezuŜyteczna. Trzeba pamiętać, Ŝe z technologii XML-RPC w duŜej mierze korzysta się po to, aby zrzucić cięŜar wykonywania bardziej złoŜonych zadań na serwer — uproszczony klient ma tylko Ŝądać wywołania procedury i ko-

Po co się męczyć? Niech serwer nas wyręczy!

254

rzystać ze zwróconych wyników. Co więcej, moŜliwe jest, Ŝe część, a nawet wszystkie obliczenia wymagane do zwrócenia odpowiedzi na Ŝądanie moŜna wykonać zawczasu; inaczej mówiąc, klasa procedury obsługi sama wykonuje zadania i kiedy nadchodzi wywołanie metody, wyniki są juŜ gotowe do odesłania. W tej chwili programistom Javy powinny przyjść na myśl wątki i współuŜytkowane egzemplarze danych. Właśnie te zagadnienia zostaną poniŜej zilustrowane za pomocą prostej klasy Scheduler (rozkład zadań). Do stworzonego rozkładu zadań klienty będą mogły dodawać i usuwać zdarzenia. Będzie równieŜ moŜliwość pobrania z rozkładu listy wszystkich zdarzeń w kolejce. Aby aplikację jeszcze bardziej zbliŜyć do rzeczywistości (i Ŝeby serwer miał co robić), nakaŜemy sortowanie zwróconych zadań według kolejności ich wykonywania. Zdarzenia będą miały po prostu postać łańcucha String, zawierającego nazwę i czas zdarzenia w formacie java.util.Date. Nie jest to moŜe kompletna implementacja rozkładu zadań, ale dobrze demonstruje działanie serwera, wykonuje pewne zadania „za kulisami”. Po pierwsze, stworzymy metody addEvent() i removeEvent() (odpowiednio: dodaj i usuń zdarzenie). PoniewaŜ obie te metody są wywoływane przez klienta, nie ma tutaj nic nowego; ciekawe jest natomiast to, jak zachowamy te zadania w klasie Scheduler. Serwer XML-RPC stworzy egzemplarz tej klasy i egzemplarz ten będzie potem wykorzystywany we wszystkich Ŝądaniach przychodzących do serwera; jest jednak moŜliwe, a nawet prawdopodobne, Ŝe z naszym rozkładem zajęć będą komunikowały się inne klasy lub wręcz inne serwery XML-RPC. Jeśli listę zdarzeń będziemy składować jako zmienną przynaleŜną do klasy, nie będzie moŜliwe współuŜytkowanie tych danych przez wiele egzemplarzy. Trzeba więc stworzyć dane składowane statycznie i współuŜytkowane przez wszystkie egzemplarze klasy Scheduler. Do przechowania nazwy i czasu zdarzenia najbardziej odpowiedni wydaje się typ Hashtable, w którym dane przechowywane są w parach klucz-wartość. Oprócz tego nazwy zdarzeń zachowamy w wektorze Vector. Wymaga to wykorzystania dodatkowej pamięci masowej (oraz pamięci w wirtualnej maszynie Javy), ale za to sortować będziemy Vector, a nie Hashtable — zaleta takiego rozwiązania polega na tym, Ŝe będziemy zamieniać miejscami pozycje wektora (za kaŜdym razem tylko pojedyncza zamiana), a nie Hashtable (kaŜdorazowo dwie zamiany). Stwórzmy szkielet takiej klasy i dodajmy dwie pierwsze metody, pozwalające dodać lub usunąć zdarzenie. Dodamy takŜe miejsce składowania zdarzeń, ale implementację pobierania i sortowania zdarzeń zostawimy na później. Odpowiedni kod moŜna obejrzeć w przykładzie 10.6.

Przykład 10.6. Klasa rozkładu zadań Scheduler import java.util.Date; import java.util.Hashtable; import java.util.Vector; /** * Scheduler to klasa umoŜliwiająca * dodawanie, usuwanie i pobieranie posortowanych według czasu * występowania zadań. * * @author Brett McLaughlin * @version 1.0 */ public class Scheduler { /** Lista nazw zdarzeń (do sortowania) */ private static Vector events = null; /** Szczegóły zdarzeń (nazwa, czas) */

Po co się męczyć? Niech serwer nas wyręczy!

255

private static Hashtable eventDetails = null; /** *

* Tutaj inicjalizujemy miejsce składowania zdarzeń. *

*/ public Scheduler() { events = new Vector(); eventDetails = new Hashtable(); } /** *

* Tutaj dodajemy Ŝądane zdarzenie. *

* Tutaj usuwamy Ŝądane zdarzenie. *

* * @param eventName String nazwa zdarzenia do usunięcia. * @return boolean - wskazuje, czy usunięto zdarzenie. */ public synchronized boolean removeEvent(String eventName) { events.remove(eventName); eventDetails.remove(eventName); return true; } }

Metoda addEvent() dodaje nazwę zdarzenia do obu obiektów, w których składujemy dane, a czas zdarzenia — tylko do obiektu Hashtable. Metoda removeEvent() ma działanie przeciwne. Obie zwracają wartość boolean. Choć w przykładzie ta wartość to zawsze true, w bardziej złoŜonych aplikacjach moŜna ją wykorzystać do informowania o problemach związanych z dodawaniem lub usuwaniem zdarzeń. Skoro dodawanie i usuwanie zdarzeń jest juŜ moŜliwe, teraz musimy dodać metodę zwracającą listę zdarzeń. Metoda ta zwraca wszystkie składowane zdarzenia, bez względu na to, który klient (lub aplikacja) to zdarzenie dodał. Mogą więc to być zdarzenia dodane przez innego klienta XMLRPC, inny serwer XML-RPC, inną aplikację albo samodzielną implementację tego samego rozkładu zadań. PoniewaŜ zwracane dane to pojedynczy Object, moŜna zwrócić Vector sformatowa-

Po co się męczyć? Niech serwer nas wyręczy!

256

nych wartości String, zawierających nazwę i czas kaŜdego zdarzenia. Oczywiście, w aplikacji bliŜszej rzeczywistości mógłby zostać zwrócony Vector zdarzeń albo jakiś inny typ danych (z datą w obiekcie Date itd.). Nasza metoda ma jednak umoŜliwić podgląd danych, a nie wykonywanie na nich dalszych operacji. Do zwrócenia listy zdarzeń wykorzystamy klasę java.text.SimpleDateFormat, umoŜliwiającą tekstowe formatowanie obiektów Date. Odpowiedni String, zawierający nazwę i czas zdarzenia, tworzony jest w pętli dla kaŜdego zdarzenia; potem dołączany jest do listy wynikowej Vector, która to lista zostanie zwrócona klientowi. Dodajmy więc wymaganą instrukcję importującą oraz kod zwracający zdarzenia: import java.text.SimpleDateFormat; import java.util.Date; import java.util.Hashtable; import java.util.Vector; ... /** *

* Tutaj zwracamy bieŜącą listę zdarzeń. *

* * @return Vector - lista zdarzeń. */ public Vector getListOfEvents() { Vector list = new Vector(); // Tworzymy format danych. SimpleDateFormat fmt = new SimpleDateFormat("hh:mm a MM/dd/yyyy"); // Dodajemy kaŜde zdarzenie do listy for (int i=0; i
Teraz moŜna byłoby juŜ bez Ŝadnych problemów uŜyć powyŜszej klasy jako procedury obsługi XML-RPC. Jednak chcemy dowiedzieć się, co naleŜy zrobić, aby serwer wykonywał swoją pracę w czasie, gdy klient robi coś innego. Metoda getListOfEvents() zakłada, Ŝe lista zdarzeń (zmienna events typu Vector) jest posortowana — czyli Ŝe sortowanie miało juŜ wcześniej miejsce. Nie napisaliśmy jeszcze kodu sortującego, ale — co istotniejsze — nie napisaliśmy równieŜ kodu uruchamiającego to sortowanie. Co więcej, w miarę rozrastania się listy zdarzeń sortowanie będzie zajmowało coraz więcej czasu, a przecieŜ klient nie moŜe czekać. Najpierw dodamy metodę, za pomocą której nasza klasa posortuje zdarzenia. Dla uproszczenia zastosujemy technikę sortowania pęcherzykowego; omawianie algorytmów sortowania wykracza poza tematykę niniejszej ksiąŜki, a więc nie będziemy szczegółowo opisywali akurat tego fragmentu kodu. W kaŜdym razie na końcu metody zmienna Vector events zawiera juŜ zdarzenia posortowane według zaplanowanych dat. Więcej informacji o tym i o innych algorytmach sortowania moŜna znaleźć w ksiąŜce Algorithms in Java Roberta Sedgewicka i Tima Lindholma (Addison-Wesley). W następujący sposób dodamy algorytm i metodę sortującą zdarzenia:

Po co się męczyć? Niech serwer nas wyręczy! import import import import import

java.text.SimpleDateFormat; java.util.Date; java.util.Enumeration; java.util.Hashtable; java.util.Vector;

/** * Scheduler to klasa umoŜliwiająca * dodawanie, usuwanie i pobieranie posortowanych według czasu * występowania zadań. * * @author Brett McLaughlin * @version 1.0 */ public class Scheduler { /** Lista nazw zdarzeń (do sortowania) */ private static Vector events = null; /** Szczegóły zdarzeń (nazwa, czas) */ private static Hashtable eventDetails = null; /** Znacznik określający, czy zdarzenia są posortowane */ private static boolean eventsSorted; // Implementacje innych metod /** *

* Sortujemy zdarzenia na bieŜącej liście. *

*/ private synchronized void sortEvents() { if (eventsSorted) { return; } // Tworzymy tablicę zdarzeń "tak jak są" (nieposortowanych) String[] eventNames = new String[events.size()]; events.copyInto(eventNames); // Sortowanie pęcherzykowe String tmpName; Date date1, date2; for (int i=0; i 0) { // W razie potrzeby -- zamiana zdarzeń tmpName = eventNames[j]; eventNames[j] = eventNames[j+1]; eventNames[j+1] = tmpName; } } } // Wstawienie posortowanych zdarzeń do nowego wektora Vector sortedEvents = new Vector(); for (int i=0; i
257

Po co się męczyć? Niech serwer nas wyręczy!

258

sortedEvents.addElement(eventNames[i]); } // Aktualizacja zdarzeń globalnych events = sortedEvents; eventsSorted = true; } ... }

Poza wstawieniem samego algorytmu trzeba było jeszcze zaimportować klasę java.util.Enumeration oraz dodać zmienną boolean o nazwie eventsSorted. Znacznik ten umoŜliwia obejście całej procedury sortowania, jeśli zdarzenia są juŜ posortowane. Nie ma jeszcze kodu, który wpływałby na stan tego znacznika, ale jego dodanie nie powinno sprawić kłopotów. Nasza metoda sortująca juŜ teraz potrafi wskazać, czy po ukończeniu zdarzenia są posortowane. Konstruktor powinien więc na początku ustawić tę wartość na true, co oznacza, Ŝe zdarzenia są wstępnie posortowane. Dopiero po dodaniu nowych zdarzeń ten stan moŜe się zmienić na „nieposortowane”, a więc w metodzie addEvents() ustawiamy znacznik na false. Dzięki temu klasa Scheduler będzie „wiedzieć”, Ŝe sortowanie powinno zostać uruchomione. Kiedy więc wywołana zostanie metoda getListOfEvents(), zdarzenia będą posortowane i gotowe do zwrócenia. Dodajmy odpowiedni kod do naszego konstruktora: /** *

* Tutaj inicjalizujemy miejsce składowania zdarzeń. *

*/ public Scheduler() { events = new Vector(); eventDetails = new Hashtable(); eventsSorted = true; } /** *

* Tutaj dodajemy Ŝądane zdarzenie. *

* * @param eventName String nazwa zdarzenia do dodania. * @param eventTime Date data zdarzenia. * @return boolean - wskazuje, czy zdarzenie zostało dodane. */ public boolean addEvent(String eventName, Date eventTime) { // Dodajemy tę listę do listy zdarzeń if (!events.contains(eventName)) { events.addElement(eventName); eventDetails.put(eventName, eventTime); eventsSorted = false; } return true; }

Po co się męczyć? Niech serwer nas wyręczy!

259

W metodzie removeEvent() nie trzeba wprowadzać Ŝadnych zmian — usunięcie wpisu nie zmienia przecieŜ kolejności zdarzeń. Idealnym rozwiązaniem przetwarzania po stronie serwera bez angaŜowania klienta jest stworzenie wątku sortującego. Po uruchomieniu takiego wątku w wirtualnej maszynie Javy przetwarzanie po stronie klienta moŜe być kontynuowane bez konieczności czekania na zakończenie procesu po stronie serwera. Jest to szczególnie istotne w środowiskach wielowątkowych, gdzie wykorzystuje się synchronizację i wątki oczekujące na zwolnienie blokad obiektów. W tym przykładzie staramy się uniknąć tego typu zagadnień (to rozdział o XML-RPC, a nie o wątkach), ale dodanie odpowiedniego kodu nie stanowiłoby duŜego problemu. W naszym programie stworzymy wewnętrzną klasę Thread, która nie robi nic poza wywołaniem metody sortEvents(). Następnie dodamy metodę addEvents(), która tworzy i uruchamia ten wątek po dodaniu zdarzenia. Tak więc dodanie zdarzenia powoduje ponowne posortowanie zdarzeń, ale bez zatrzymywania pracy klienta (czyli np. dodawania kolejnych zdarzeń, a więc uruchamiania kolejnych wątków itd.). Kiedy klient zaŜąda listy zdarzeń, powinny one być juŜ posortowane, tak aby klient nie musiał oczekiwać albo wykonywać tej czynności samodzielnie. Dodanie wewnętrznej klasy sortującej oraz kodu uruchamiającego tę klasę w wątku do metody addEvents() to juŜ ostatnie zmiany, jakie wprowadzimy w klasie Scheduler: public class Scheduler { ... public boolean addEvent(String eventName, Date eventTime) { // Dodajemy tę listę do listy zdarzeń if (!events.contains(eventName)) { events.addElement(eventName); eventDetails.put(eventName, eventTime); eventsSorted = false; // Uruchamiamy na serwerze wątek sortujący SortEventsThread sorter = new SortEventsThread(); sorter.start(); } return true; } ... /** *

* Klasa wewnętrzna uruchamiająca sortowanie jako wątek * Thread. */ class SortEventsThread extends Thread { /** *

* Uruchamianie sortowania. *

*/ public void run() { sortEvents(); } } }

Po skompilowaniu zmodyfikowanego kodu powstaje wątkowy rozkład zadań, wykonujący „zasoboŜerne” zadanie sortowania po stronie serwera, nie przerywając w tym celu pracy klientów. Jest

Po co się męczyć? Niech serwer nas wyręczy!

260

to prosty przykład klasy procedury obsługi, ale dobrze ilustruje proces rozpraszania zasobów i sposób przekładania cięŜaru obsługi programu na serwer. Bardziej zaawansowana klasa procedury obsługi jest juŜ gotowa. Teraz jeszcze usprawnimy nieco sam serwer.

Serwer z moŜliwością konfiguracji Klasa serwera XML-RPC wymaga zmian. Obecna wersja wymaga wpisywania klas obsługi w kod — a więc równieŜ rekompilacji. To rozwiązanie niepoŜądane, niewygodne i czasochłonne — konieczne jest uzyskiwanie najświeŜszego kodu z systemu kontroli plików źródłowych, wprowadzanie zmian i testowanie procedur obsługi. Lepiej byłoby, gdyby serwer potrafił odczytywać tego typu informacje z pliku konfiguracyjnego i ładować odpowiednie klasy dynamicznie. Spróbujmy teraz stworzyć taki „lekki” serwer. Zaczniemy od zbudowania nowej klasy serwera. MoŜemy zacząć od podstaw albo skopiować kod z klasy HelloServer opisywanej we wcześniejszej części rozdziału. Rozpoczniemy od stworzenia struktury i po kolei dodamy wymagane instrukcje importujące i inne — podobnie jak robiliśmy to wcześniej. Tym razem jednak nie dodamy kodu rejestrującego procedury obsługi; posłuŜymy się metodą pomocniczą, ładującą wymagane informacje z pliku. Będzie więc trzeba równieŜ obsłuŜyć dodatkowy parametr wiersza poleceń, określający nazwę pliku. Stworzymy klasę LightweightXmlRpcServer (część pakietu narzędziowego com.oreilly.xml), która cały czas korzysta z niewielkiej klasy pomocniczej WebServer. Jej kod przedstawiony jest w przykładzie 10.7. Pełny pakiet com.oreilly.xml moŜna równieŜ pobrać ze stron http://www.oreilly.com/ catalog/javaxml/ lub http://www.newInstance.com. Przykład 10.7. Klasa LightweightXmlRpcServer package com.oreilly.xml; import java.io.IOException; import helma.xmlrpc.XmlRpc; import helma.xmlrpc.WebServer; /** * LightweightXmlRpcServer to klasa narzędziowa * uruchamiająca serwer XML-RPC nasłuchujący Ŝądań HTTP * i rejestrująca procedury obsługi zdefiniowane w pliku konfiguracyjnym. * * @author Brett McLaughlin * @version 1.0 */ public class LightweightXmlRpcServer { /** Klasa narzędziowa serwera XML-RPC */ private WebServer server; /** Port, na którym nasłuchujemy */ private int port; /** Plik konfiguracyjny */ private String configFile; /** *

* Tutaj będziemy przechowywać nr portu i plik konfiguracyjny * wykorzystywane przez serwer. *

Po co się męczyć? Niech serwer nas wyręczy! * * @param port int port, na * @param configFile String * pobrania informacji */ public LightweightXmlRpcServer(int port, this.port = port; this.configFile = configFile; }

261

którym nasłuchujemy nazwa pliku do o konfiguracji. String configFile) {

/** *

* Uruchomienie serwera. *

* * @throws IOException zgłaszany w razie problemów. */ public void start() throws IOException { try { // Korzystamy z parsera SAX Apache Xerces XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser"); System.out.println("Uruchamianie serwera XML-RPC..."); server = new WebServer(port); // Rejestracja procedur obsługi.

} catch (ClassNotFoundException e) { throw new IOException("Błąd ładowania parsera SAX: " + e.getMessage()); } }

/** *

* Statyczny punkt rozpoczęcia programu. *

*/ public static void main(String[] args) { if (args.length < 2) { System.out.println( "UŜycie: " + "java com.oreilly.xml.LightweightXmlRpcServer " + "[port] [plikKonfiguracyjny]"); System.exit(-1); } LightweightXmlRpcServer server = new LightweightXmlRpcServer(Integer.parseInt(args[0]), args[1]); try { // Uruchomienie serwera. server.start(); } catch (IOException e) { System.out.println(e.getMessage()); } } }

Po co się męczyć? Niech serwer nas wyręczy!

262

W powyŜszym kodzie nie ma nic nadzwyczajnego. Sprawdzamy, czy przekazywane są odpowiednie parametry, i uruchamiamy serwer na Ŝądanym porcie. Teraz trzeba dodać metody ładujące procedury obsługi z pliku, a następnie dodające procedury jedna po drugiej do serwera. PoniewaŜ kaŜda procedura obsługi ma postać nazwy i odpowiadającej jej klasy, plik konfiguracyjny oparty będzie właśnie na takich parach informacji. W przypadku Javy załadowanie i stworzenie egzemplarza klasy, której pełna nazwa jest nam znana, nie przedstawia Ŝadnych trudności — tak więc nową procedurę obsługi opiszemy za pomocą prostej pary łańcuchów tekstowych. W pliku konfiguracyjnym dodamy zarówno naszą wcześniejszą klasę HelloHandler, jak i nową — Scheduler. PoniewaŜ piszemy równieŜ parser pliku, decydujemy, Ŝe ogranicznikami wpisów będą przecinki, a znak

# oznaczać będzie komentarz. MoŜliwe jest zresztą zastosowanie dowolnej konwencji, o ile tylko dostosujemy odpowiednio kod. Tworzymy teraz plik konfiguracyjny taki jak ten w przykładzie 10.8. W wyniku jego odczytania do serwera zostaną dodane klasy HelloHandler (pod nazwą „hello”) oraz Scheduler (pod nazwą „scheduler”). Plik zachowujemy pod nazwą xmlrpc.conf.



Przykład 10.8. Plik konfiguracyjny XML-RPC # Procedura obsługi hello: sayHello() hello,HelloHandler # Scheduler: addEvent(), removeEvent(), getEvents() scheduler,Scheduler



Na potrzeby dokumentacji w komentarzach podajemy metody dostępne dla kaŜdej procedury obsługi. Osobom zajmującym się naszym kodem w przyszłości taki opis na pewno się przyda. Ładowanie pliku i odczytanie jego zawartości jest — dzięki klasom wejścia-wyjścia Javy — bardzo proste. Tworzymy metodę pomocniczą odczytującą określony plik i składującą pary wartości w strukturze Hashtable. Obiekt ten moŜe zostać następnie przekazany innej metodzie pomocniczej, ładującej i rejestrującej poszczególne procedury obsługi. W tej przykładowej metodzie nie sprawdzamy zbyt intensywnie, czy nie wystąpiły błędy, a kaŜda linijka nie będąca parą wartości jest po prostu ignorowana; w serwerze produkcyjnym prawdopodobnie posłuŜylibyśmy się bardziej zaawansowanym kodem (zresztą dodanie kodu sprawdzającego błędy byłoby naprawdę proste). Po odnalezieniu wiersza zawierającego parę wartości jest on rozbijany na części, a identyfikator i nazwa klasy zostają zachowane w strukturze Hashtable. Dodamy teraz instrukcje importujące oraz nową metodę getHandlers(): import import import import



java.io.BufferedReader; java.io.FileReader; java.io.IOException; java.util.Hashtable;



import helma.xmlrpc.XmlRpc; import helma.xmlrpc.WebServer; ... /** *  * Metoda przetwarzająca plik konfiguracyjny * (w minimalistyczny sposób) i odczytująca dostarczone * definicje procedur obsługi. * 
 *



Po co się męczyć? Niech serwer nas wyręczy!



263



* @return Hashtable - pary identyfikator/klasa. * @throws IOException - zgłaszany w razie wystąpienia * błędu przy przetwarzaniu/odczycie pliku. */ private Hashtable getHandlers() throws IOException { Hashtable handlers = new Hashtable(); BufferedReader reader = new BufferedReader(new FileReader(configFile)); String line = null; while ((line = reader.readLine()) != null) { // Składnia to "nazwaProceduryObslugi, klasaProceduryObslugi" int comma; // Pomijamy komentarze if (line.startsWith("#")) { continue; } // Pomijamy wiersze puste lub bezuŜyteczne if ((comma = line.indexOf(",")) < 2) { continue; } // Dodajemy nazwę i klasę procedury obsługi handlers.put(line.substring(0, comma), line.substring(comma+1)); } return handlers; } ...



Zamiast dodawać kod zachowujący wynik działania takiej metody, wyniku tego uŜyjemy w funkcji danych wejściowych metody przetwarzającej Hashtable i dodającej poszczególne procedury obsługi do serwera. Kod wykonujący to zadanie nie jest skomplikowany; warto jedynie zaznaczyć, Ŝe metoda addHandler() klasy WebServer wymaga podania jako parametru egzemplarza klasy. Trzeba więc pobrać nazwę klasy do zarejestrowania ze struktury Hashtable, załadować tę klasę do wirtualnej maszyny Javy za pomocą Class.forName() i stworzyć jej egzemplarz za pomocą newInstance(). Właśnie w ten sposób postępuje się w programach ładujących klasy i innych aplikacjach dynamicznych w Javie; Czytelnik moŜe nie znać tej metody, jeśli dopiero zaczyna przygodę z tym językiem lub nie musiał tworzyć dynamicznie egzemplarzy klas z nazwy tekstowej. Po załadowaniu klasy w ten sposób, zarówno ona, jak i jej identyfikator przekazywane są do metody addHandler() i pętla jest kontynuowana. Po załadowaniu całej zawartości Hashtable serwer jest gotowy do działania. Do „przechodzenia” po kluczach Hashtable uŜywamy klasy Enumeration, a więc trzeba dodać odpowiednią instrukcję importującą: package com.oreilly.xml; import import import import import



java.io.BufferedReader; java.io.FileReader; java.io.IOException; java.util.Enumeration; java.util.Hashtable;



Po co się męczyć? Niech serwer nas wyręczy!



264



import helma.xmlrpc.XmlRpc; import helma.xmlrpc.WebServer; ... /** *  * Tutaj zarejestrujemy procedury dostarczone do serwera * (zazwyczaj z {@link #getHandlers()}. * 
 * * @param handlers Hashtable procedur do zarejestrowania */ private void registerHandlers(Hashtable handlers) { Enumeration handlerNames = handlers.keys(); // Przetwarzanie procedur obsługi while (handlerNames.hasMoreElements()) { String handlerName = (String)handlerNames.nextElement(); String handlerClass = (String)handlers.get(handlerName); // Tę procedurę obsługi dodajemy do serwera try { server.addHandler(handlerName, Class.forName(handlerClass).newInstance()); System.out.println("Zarejestrowana w serwerze nazwa " + handlerName + " odpowiada klasie " + handlerClass); } catch (Exception e) { System.out.println("Nie jest moŜliwe zarejestrowanie procedury " + handlerName + " odpowiadającej klasie " + handlerClass); } } } ...



Mamy tu do czynienia z uzupełnieniem wcześniejszej metody getHandlers(); faktycznie jako wejście pobierany jest właśnie jej wynik działania. Wartości String z klasy Hashtable są pobierane i rejestrowane. Serwer załaduje i udostępni do zdalnych wywołań wszystkie procedury obsługi podane w pliku konfiguracyjnym. NaleŜy pamiętać, Ŝe metody te moŜna byłoby równie dobrze skonsolidować do postaci jednej, większej metody. JednakŜe obie opisywane metody mają róŜne cele: getHandlers() przetwarza plik, a registerHandlers() rejestruje procedury obsługi, gdy tylko informacje o nich zostaną udostępnione. To wszystko umoŜliwia prostą zmianę sposobu odczytywania pliku konfiguracyjnego (moŜna nawet sprawić, Ŝe informacje będą odczytywane z bazy danych), bez konieczności pamiętania o samym sposobie rejestrowania procedur obsługi. W następnym rozdziale pójdziemy dalej — usuniemy metodę getHandlers(), zastępując ją klasą pomocniczą odczytującą te informacje z pliku XML! W tym przypadku podjęcie właściwej decyzji odpowiednio wcześnie (a więc w tej chwili) oszczędzi nam potem wiele pracy związanej ze zmienianiem kodu (w następnym rozdziale). Po dodaniu tych dwóch metod pomocniczych dodajemy ich wywołanie do metody start() klasy serwera.



Po co się męczyć? Niech serwer nas wyręczy!



265



/** *  * Uruchomienie serwera. * 
 * * @throws IOException zgłaszany w razie problemów. */ public void start() throws IOException { try { // Korzystamy z parsera SAX Apache Xerces XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser"); System.out.println("Uruchamianie serwera XML-RPC..."); server = new WebServer(port); // Rejestracja procedur obsługi. registerHandlers(getHandlers()); } catch (ClassNotFoundException e) { throw new IOException("Błąd ładowania parsera SAX: " + e.getMessage()); } }



Wokół dodanych metod budujemy blok try-catch, dzięki czemu będziemy potrafili odróŜnić wyjątki występujące w samym serwerze (blok zewnętrzny) od tych związanych z budowaniem procedur obsługi. W tym ostatnim przypadku zgłaszamy błąd jako komunikat generowany przez metody procedur obsługi. Kompilujemy kod, upewniamy się, Ŝe plik konfiguracyjny jest na miejscu, i otrzymujemy serwer gotowy do uŜycia.



UŜyteczny klient W kliencie nie zastosujemy Ŝadnych nowych koncepcji czy technik; klasa SchedulerClient będzie równie prosta jak HelloClient. Będzie uruchamiała klienta XML-RPC, wywoływała metody procedur obsługi i wyświetlała wynik ich działania. Cały kod znajduje się poniŜej. O tym, co się dzieje w programie, informują komentarze; poniewaŜ tę stronę aplikacji juŜ omówiliśmy, wystarczy teraz tylko skompilować kod podany w przykładzie 10.9.



Przykład 10.9. Klasa SchedulerClient import import import import import import import



java.io.IOException; java.net.MalformedURLException; java.util.Calendar; java.util.Date; java.util.Enumeration; java.util.Hashtable; java.util.Vector;



import helma.xmlrpc.XmlRpc; import helma.xmlrpc.XmlRpcClient; import helma.xmlrpc.XmlRpcException; /** * SchedulerClient to klient XML-RPC wysyłający * Ŝądania XML-RPC do programu Scheduler. * * @version 1.0



Po co się męczyć? Niech serwer nas wyręczy! */ public class SchedulerClient { /** *  * Dodajemy zdarzenia do programu Scheduler. * 
 * * @param XmlRpcClient - klient, z którym się łączymy */ public static void addEvents(XmlRpcClient client) throws XmlRpcException, IOException { System.out.println("\nDodawanie zdarzeń...\n"); // Parametry zdarzeń. Vector params = new Vector(); // Zdarzenie na następny miesiąc. params.addElement("Zweryfikować ostateczną wersję roboczą".); Calendar cal = Calendar.getInstance(); cal.add(Calendar.MONTH, 1); params.addElement(cal.getTime()); // Dodanie zdarzenia. if (((Boolean)client.execute("scheduler.addEvent", params)) .booleanValue()) { System.out.println("Zdarzenie zostało dodane."); } else { System.out.println("Zdarzenie nie mogło zostać dodane."); } // Zdarzenie na jutro. params.clear(); params.addElement("Wysłać ostateczną wersję roboczą"); cal = Calendar.getInstance(); cal.add(Calendar.DAY_OF_MONTH, 1); params.addElement(cal.getTime()); // Dodanie zdarzenia. if (((Boolean)client.execute("scheduler.addEvent", params)) .booleanValue()) { System.out.println("Zdarzenie zostało dodane."); } else { System.out.println("Zdarzenie nie mogło zostać dodane."); } } /** *  * Wyświetlenie zdarzeń obecnych w programie Scheduler. * 
 * * @param XmlRpcClient - klient, z którym się łączymy. */ public static void listEvents(XmlRpcClient client) throws XmlRpcException, IOException {



266



Po co się męczyć? Niech serwer nas wyręczy!



267



System.out.println("\nWyświetlanie zdarzeń...\n"); // Pobieranie zdarzeń z planu zadań. Vector params = new Vector(); Vector events = (Vector)client.execute("scheduler.getListOfEvents", params); for (int i=0; i * Statyczny punkt wyjścia programu. * 
 */ public static void main(String args[]) { try { // Korzystamy z implementacji parsera SAX Apache Xerces. XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser"); // Łączenie z serwerem. XmlRpcClient client = new XmlRpcClient("http://localhost:8585/"); // Dodanie zdarzeń. addEvents(client); // Wyświetlenie zdarzeń listEvents(client); } catch (Exception e) { System.out.println(e.getMessage()); } } }



Warto zauwaŜyć, Ŝe dodawanie zdarzeń następuje w kolejności odwrotnej do kolejności ich występowania. Nasz serwer sam zajmie się ich posortowaniem (metoda sortEvents()) i gdy wywołamy metodę getListOfEvents(), zdarzenia zostaną zwrócone we właściwej kolejności.



Mów do mnie jeszcze... Po wpisaniu kodu procedury obsługi serwera i klienta wszystkie pliki źródłowe naleŜy skompilować. Trzeba równieŜ stworzyć plik konfiguracyjny, w którym umieszczone będą procedury obsługi do zarejestrowania w serwerze XML-RPC. Następnie najpierw uruchamiamy serwer XMLRPC jako oddzielny proces: D:\prod>start java com.oreilly.xml.LightweightXmlRpcServer 8585 D:\prod\conf\xmlrpc.conf



...czego odpowiednikiem w systemach Unix jest: [adam@maly ch10]$ java com.oreilly.xml.LightweightXmlRpcServer 8585 conf/xmlrpc.conf &



Praktyczne zastosowania technologii XML-RPC



268



Serwer powinien wyświetlić procedury obsługi odczytane z pliku konfiguracyjnego oraz odpowiadające im nazwy: Uruchamianie serwera XML-RPC... Zarejestrowana w serwerze nazwa scheduler odpowiada klasie Scheduler. Zarejestrowana w serwerze nazwa hello odpowiada klasie HelloHandler.



Jeśli wcześniej nie zatrzymaliśmy utworzonego wcześniej serwera XML-RPC, HelloServer, otrzymamy komunikat o błędzie wynikający z próby uruchomienia kolejnego serwera na tym samym porcie. Przed uruchomieniem obecnego serwera naleŜy zatrzymać poprzedni.



Teraz uruchamiamy klienta i obserwujemy wyniki: [adam@maly ch10]$ java SchedulerClient Dodawanie zdarzeń... Zdarzenie zostało dodane. Zdarzenie zostało dodane. Wyświetlanie zdarzeń... Zdarzenie "Wysłać ostateczną wersję roboczą" zaplanowane na 03:42 PM 01/20/2001 Zdarzenie "Zweryfikować ostateczną wersję roboczą" zaplanowane na 03:42 PM 02/19/2001



W czasie dodawania i wyświetlania zdarzeń nie powinniśmy odczuć znacznego opóźnienia, a mimo to zdarzenia są sortowane przez serwer. Odbywa się to po prostu w oddzielnym wątku wirtualnej maszyny Javy (a trzeba wiedzieć, Ŝe sortowanie pęcherzykowe nie naleŜy do szybkich algorytmów!). I tak właśnie napisaliśmy pierwszą uŜyteczną aplikację XML-RPC.



Praktyczne zastosowania technologii XML-RPC W zakończeniu rozdziału zostaną omówione zagadnienia zwiazane z wykorzystywaniem XMLRPC w rzeczywistych zastosowaniach. Czytelnik po raz kolejny będzie mógł się przekonać, Ŝe XML uŜywany jest nie dlatego, Ŝe to taka nowoczesna i modna technologia, ale dlatego, Ŝe w niektórych sytuacjach po prostu nie ma sobie równych. Cała wiedza zawarta w tej ksiąŜce, specyfikacje otaczające XML i inne ksiąŜki opisujące ten standard — wszystko to na nic się nie zda, jeśli programista nie będzie wiedział, jak korzystać z języka XML oraz modelu XML-RPC poprawnie! W niniejszej części zostaną przedstawione typowe problemy trapiące programistów XML-RPC.



Gdzie właściwie jest ten XML? Po lekturze dotychczasowej części rozdziału Czytelnik moŜe zastanawiać się, dlaczego w tworzonym kodzie nie zostały uŜyte interfejsy SAX, DOM lub JDOM. Co więcej, kod prawie wcale nie bazował bezpośrednio na XML-u. Wynika to stąd, Ŝe kodowanie i dekodowanie Ŝądań przesyłanych pomiedzy klientem a serwerem wykonywane było przez biblioteki XML-RPC. Choć XML nie został uŜyty bezpośrednio, to jednak całe to rozwiązanie oparte jest właśnie na technologii XML. Proste Ŝądanie wysyłane do metody sayHello() zostało tak naprawdę przetłumaczone na wywołanie HTTP o postaci przedstawionej w przykładzie 10.10.



Praktyczne zastosowania technologii XML-RPC



269



Przykład 10.10. śądanie XML-RPC po rozkodowaniu POST /RPC2 HTTP/1.1 User-Agent: Tomcat Web Server/3.1 Beta (Sun Solaris 2.6) Host: newInstance.com Content-Type: text/xml Content-length: 234   hello.sayHello   Brett   



Biblioteki XML-RPC po stronie serwera otrzymują takie Ŝądanie i rozkodowują je, dopasowując odpowiednią metodę procedury obsługi (o ile taka istnieje). Następnie Ŝądana metoda Javy jest uruchamiana, a serwer ponownie koduje wynik do postaci XML, tak jak to pokazano w przykładzie 10.11.



Przykład 10.11. Odpowiedź XML-RPC po zakodowaniu HTTP/1.1 200 OK Connection: close Content-Type: text/xml Content-length: 149 Date: Mon, 11 Apr 2000 03:32:19 CST Server: Tomcat Web Server/3.1 Beta-Sun Solaris 2.6     Hello Brett   



Komunikacja trwa, chociaŜ uŜytkownik wcale nie musiał zaprzątać sobie głowy szczegółami.



Egzemplarze współuŜytkowane Przedstawione przykłady zobrazowały sposoby wykorzystania statycznych obiektów do współuŜytkowania danych przez wiele egzemplarzy tej samej klasy. JednakŜe istnieją takŜe sytuacje, w których współuŜytkowany jest sam egzemplarz. Nie musi to wynikać z zastosowania modelu XML-RPC, ale z konieczności róŜnego uŜycia klasy po stronie serwera. Na przykład Java dopuszcza tworzenie tylko jednego egzemplarza danej klasy i egzemplarz ten współuŜytkowany jest przez wszystkie aplikacje. Zazwyczaj uzyskuje się to za pomocą statycznej metody getInstance(), a nie poprzez konstruowanie obiektu: Scheduler scheduler; // Pobieramy jeden egzemplarz, obsługiwany przez klasę Scheduler scheduler = Scheduler.getInstance() // Dodajemy zdarzenie waŜne w tej chwili scheduler.addEvent("Piknik", new Date());



Praktyczne zastosowania technologii XML-RPC



270



Aby zagwarantować, Ŝe Ŝadne klasy nie stworzą bezpośrednio egzemplarza klasy Scheduler, konstruktor zazwyczaj otrzymuje status prywatnego lub chronionego. Powoduje to, Ŝe do stworzenia egzemplarza klienty muszą uŜyć przedstawionego wyŜej kodu; jednak rozwiązanie takie pociąga za sobą trudności z uŜyciem takiej klasy jako procedury obsługi XML-RPC. Czytelnik pamięta, Ŝe zarejestrowanie procedury obsługi odbywało się poprzez stworzenie egzemplarza jej klasy. Jednak klasa WebServer wymaga jako parametru poprawnego egzemplarza, ale niekoniecznie nowego egzemplarza. Na przykład zupełnie poprawnym sposobem dodania procedury obsługi jest zastosowanie poniŜszego kodu: WebServer server = new WebServer(8585); // Tworzymy nową klasę procedury obsługi. HelloHandler hello = new HelloHandler(); server.addHandler("hello", hello);



Klasa serwera nie rozróŜnia powyŜszych sposobów, o ile tylko egzemplarz klasy procedury obsługi stworzono przed przekazaniem jej metodzie addHandler(). Tak więc, jeśli chcemy dodać egzemplarz do opisanej wyŜej jednorodnej klasy Scheduler, kod musimy nieco zmienić: WebServer server = new WebServer(8585); // Przekazujemy jednorodny egzemplarz server.addHandler("scheduler", Scheduler.getInstance());



Przekazywany jest egzemplarz współuŜytkowany — wszystko odbywa się tak, jakby egzemplarz klasy został utworzony poprzez konstruktor za pomocą słowa kluczowego new; wszystkie informacje współuŜytkowane w klasie jednorodnej zostają zachowane. Czytelnik będzie mógł się przekonać, Ŝe wiele klas wykorzystywanych w usługach typu XML-RPC tworzonych jest jako klasy jednorodne, co zapobiega uŜyciu statycznych danych. Zastosowanie egzemplarza współuŜytkowanego umoŜliwia przechowywanie danych w zmiennych przynaleŜnych, a więc ten jeden egzemplarz operuje na tych zmiennych w celu obsłuŜenia wszystkich Ŝądań klienta.



Z serwletem czy bez? Ostatnio jako serwer XML-RPC często wykorzystywany jest program działający jako serwlet (więcej informacji o serwletach moŜna znaleźć w ksiąŜce Jasona Huntera Java Servlet Programming, wyd. O'Reilly & Associates). Nawet w dystrybucji XML-RPC dla Javy znajduje się serwlet. UŜycie serwleta w ten sposób jest zupełnie poprawne i często spotykane — serwlet zajmuje się wtedy wyłącznie obsługą Ŝądań XML-RPC, jednakŜe nie zawsze jest to rozwiązanie najlepsze. Jeśli programista ma komputer, który musi obsłuŜyć inne Ŝądania HTTP związane z wykonywaniem zadań w Javie, wtedy na pewno uŜycie mechanizmu serwletów do obsługi takich Ŝądań mija się z celem. W takim przypadku uŜycie serwleta jako serwera XML-RPC jest dobrym rozwiązaniem. Jednak jedną z zalet XML-RPC jest moŜliwość odseparowania złoŜonych, „zasoboŜernych” zadań klas procedur obsługi od pozostałego kodu aplikacji. Nasza klasa Scheduler mogłaby zostać umieszczona na serwerze wraz z klasami wykonującymi złoŜone indeksowanie, modelowanie algorytmiczne czy transformacje graficzne. Wszystkie te funkcje bardzo obniŜają wydajność klientów. Jednak dodanie mechanizmu serwletów i przyjmowanie Ŝądań aplikacji dotyczących innych zadań oraz obsługi XMLRPC zmniejsza moc przetwarzania dostępną dla klas procedur obsługi. W takim przypadku jedyne Ŝądania przychodzące do serwera powinny dotyczyć właśnie klas procedur obsługi. W przypadku, gdy przyjmowane są tylko Ŝądania XML-RPC (jak wykazano powyŜej), zastosowanie serwleta jako serwera XML-RPC rzadko zdaje egzamin. Dostępna klasa WebServer jest bardzo mała, „lekka” i opracowana właśnie do obsługi XML-RPC poprzez HTTP. Mechanizm serwletów obsługuje dowolne Ŝądania HTTP i nie jest przystosowany do Ŝądań XML-RPC. Z biegiem



Co dalej?



271



czasu zacznie być zauwaŜane obniŜenie wydajności związane z uŜyciem mechanizmu serwletów zamiast klasy WebServer. Jeśli więc serwer nie będzie obsługiwał innych zadań niŜ związane z XML-RPC, lepiej pozostać przy „lekkim” serwerze XML-RPC, opracowanym właśnie do takich zastosowań.



Co dalej? Teraz Czytelnik powinien juŜ potrafić stosować XML na róŜne sposoby, tak jak to zostało przedstawione w rozdziałach „tematycznych”. W następnym rozdziale kontynuowane będzie omawianie praktycznych zastosowań XML-a. Tym razem skoncentrujemy się na wykorzystaniu tego języka w konfiguracji. Języka XML uŜywa się w plikach wdroŜeniowych Enterprise JavaBeans, wielu serwerów i coraz większej liczby aplikacji. W kolejnym rozdziale zostaną omówione przyczyny tej ekspansji XML-a; zostaną równieŜ przedstawione sposoby zastosowania tego języka do wyłącznych celów aplikacji, a nie tylko do przesyłania danych pomiędzy aplikacjami. Czytelnik dowie się, dlaczego w najbliŜszej przyszłości nie grozi nam likwidacja baz danych i serwerów usług katalogowych, dowie się równieŜ, gdzie warto stosować XML, a gdzie zastosowanie tego języka nie jest uzasadnione.



Co dalej?



272



Deskryptory wdroŜeniowe EJB



273



11 XML na potrzeby konfiguracji Niniejszy rozdział zawiera informacje dotyczące sposobów zastosowania języka XML w danych słuŜących do konfiguracji. W poprzednich rozdziałach Czytelnik poznawał sposoby zastosowania tego języka do przesyłania danych pomiędzy aplikacjami i do tworzenia warstwy prezentacyjnej — w tym rozdziale zostaną omówione sposoby wykorzystania XML-a do przechowywania danych. Aby zrozumieć przesłanki przemawiające za uŜyciem XML-a na potrzeby konfiguracji, wystarczy napisać aplikację korzystającą z obszernych plików właściwości albo serwer konfigurowany na podstawie plików, a nie argumentów wiersza poleceń. W obu tych przypadkach format plików dostarczających informacje do aplikacji jest umowny i zazwyczaj odpowiada tylko określonej aplikacji. Programista ustala format pliku, buduje moduł odczytujący taki plik i aplikacja zostaje związana ze swoim plikiem konfiguracyjnym na zawsze. Oczywiście, takie postępowanie nie uwzględnia dalekowzrocznych planów związanych z rozwijaniem tej aplikacji. Programiści i inŜynierowie systemów zdali sobie sprawę z kłopotów z pielęgnacją tak napisanego oprogramowania (zapominanie o przecinkach, niepewność dotycząca znaków wskazujących początek komentarza itd.). Jasne stało się, Ŝe potrzebny jest standard reprezentacji tego typu danych niezwiązany z konkretną aplikacją. Jednym z takich standardów, wciąŜ wykorzystywanym, ale pozbawionym wielu uŜytecznych cech, jest klasa java.util.Properties i odpowiednie pliki właściwości. Konstrukcje te, wprowadzone w pakiecie Java Development Kit (JDK) 1.0, umoŜliwiają wygodne z punktu widzenia Javy przechowywanie informacji konfiguracyjnych, jednakŜe nie udostępniają Ŝadnego sposobu grupowania lub budowania hierarchii. Aplikacja klienta ma taki dostęp do informacji serwera, jak serwer do informacji klienta i programista nie jest w stanie przeprowadzić Ŝadnego logicznego grupowania wewnątrz takiego pliku. Co więcej, kiedy hierarchiczne parametry konfiguracyjne zyskały na popularności, takie zagnieŜdŜanie było trudne do osiągnięcia za pomocą innych rozwiązań bez wprowadzania jeszcze bardziej złoŜonych (a wciąŜ współpracujących tylko z daną aplikacją) formatów plików. XML przyniósł rozwiązanie wszystkich tych problemów — oferował standardowy, prosty sposób reprezentacji informacji konfiguracyjnych.



Deskryptory wdroŜeniowe EJB



274



Format XML nadaje się do szerokich zastosowań administracyjnych. MoŜliwe jest zbudowanie ogólnej aplikacji ładującej definicję DTD lub schemat, a następnie plik konfiguracyjny i umoŜliwiającej dodawanie, aktualizację, usuwanie i modyfikację informacji konfiguracyjnych. Jedna aplikacja, wykorzystująca jeden lub wiele plików konfiguracyjnych XML, mogłaby słuŜyć jako jeden interfejs administracyjny. Jeśli porównamy to z całą mnogością plików haseł, plików shadow, uŜytkowników, grup i skryptów inicjalizacyjnych, to na pewno takie rozwiązanie jest przejrzystsze i prostsze w obsłudze. PoniewaŜ XML jest juŜ wykorzystywany w wielu aplikacjach, dodanie rozszerzenia do przetwarzania i obsługi plików konfiguracyjnych było tylko kwestią czasu. Aplikacje nie wykorzystujące jeszcze XML-a mogą wprowadzać pliki konfiguracyjne oparte na tym języku; jest to o wiele prostsze niŜ dodanie obsługi przesyłania danych XML lub przekształcania XML-a do innych formatów. Tak czy inaczej, konfiguracja za pomocą XML-a okazała się dobrym rozwiązaniem w wielu sytuacjach. Od kiedy przedstawiono specyfikację Enterprise JavaBeans(EJB) 1.1, wymagającą deskryptorów wdroŜeniowych EJB w formacie XML, wykorzystanie tego języka w konfiguracji stało się bardzo popularne. Wielu programistów obawiających się obciąŜenia wynikającego z uruchomienia parsera XML lub wątpiących w perspektywy standardu XML nagle musiało wykorzystać ten język do wdroŜenia obiektów biznesowych w serwerach EJB. Spowodowało to logiczną migrację wszystkich danych konfiguracyjnych do tego formatu i przyczyniło się nawet do zmniejszenia złoŜoności niejednej aplikacji. W niniejszym rozdziale zostaną przedstawione sposoby wykorzystania XML-a do konfigurowania własnej aplikacji. Najpierw zostaną omówione uŜywane obecnie sposoby korzystania z XML-a na potrzeby konfiguracji. Przedstawione zostaną deskryptory wdroŜeniowe EJB pod kątem decyzji projektowych, jakie podjęto przy tworzeniu specyfikacji tego rodzaju plików. To stanowić będzie przygotowanie do stworzenia własnych plików konfiguracyjnych XML. Zaczniemy od zbudowania pliku konfiguracyjnego dla serwera, który stworzyliśmy w poprzednim rozdziale. Następnie napiszemy klasy narzędziowe przetwarzające i ładujące te informacje do naszych klas XML-RPC — to znacznie zwiększy elastyczność omawianego serwera i jego klientów. Informacje o konfiguracji w prosty sposób załadujemy za pomocą interfejsów JDOM. W zakończeniu rozdziału zostaną porównane moŜliwości XML-a i innych mechanizmów składowania danych — baz danych i serwerów usług katalogowych. Dzięki temu Czytelnik będzie mógł wyrobić sobie opinię na temat praktycznych zastosowań XML-a.



Deskryptory wdroŜeniowe EJB Zanim zbudujemy własne pliki konfiguracyjne oraz oprogramowanie pozwalające z nich korzystać, przyjrzymy się istniejącym formatom i szablonom. Tematem niniejszej ksiąŜki nie jest specyfikacja EJB, ale krótki opis deskryptorów wdroŜeniowych EJB potrzebny jest do zrozumienia zasady działania plików konfiguracyjnych XML; opis ten podpowie równieŜ, jak zaprojektować własny format danych konfiguracyjnych. W niniejszym podrozdziale zostaną takŜe omówione najwaŜniejsze decyzje projektowe leŜące u podstaw plików konfiguracyjnych deskryptorów. Jednak przed omówieniem deskryptorów wdroŜeniowych warto zastanowić się, dlaczego w ogóle programiści EJB „przeszli” na XML. Specyfikacja EJB 1.0 wymagała stosowania uszeregowanych deskryptorów wdroŜeniowych; niestety, to była jedyna wskazówka oferowana przez autorów specyfikacji. KaŜdy producent EJB wymagał więc własnego formatu deskryptorów wdroŜeniowych dla swojego serwera i zmuszał programistę do uruchamiania narzędzia (a nawet pisania własnych narzędzi) szeregujących deskryptor. Specyfikacja EJB (a takŜe ogólnie język Java) utraciła prawo do miana WORA (Write Once Run Anywhere — aplikacja raz napisana moŜe zostać uruchomio-



Deskryptory wdroŜeniowe EJB



275



na gdziekolwiek). XML udostępniał standardowy sposób obsługi deskryptorów wdroŜeniowych, a takŜe zniwelował potrzebę korzystania z własnych narzędzi szeregujących. Co więcej, firma Sun udostępniła definicję DTD EJB, dzięki której deskryptory wdroŜeniowe dowolnego producenta zgodne są z jedną specyfikacją; system EJB został w duŜym stopniu uniezaleŜniony od platformy i produktów określonego producenta.



Podstawy Podobnie jak w przypadku dowolnego dokumentu XML, deskryptor wdroŜeniowy EJB posiada definicję DTD, z którą utrzymuje zgodność. Jak juŜ wcześniej wspomniano, w przyszłych wersjach specyfikacji definicja ta zostanie prawdopodobnie zastąpiona schematem. Tak czy inaczej, dokumenty XML uŜywane w konfiguracji muszą tutaj (nawet bardziej niŜ gdzie indziej) przestrzegać narzuconych na nie reguł. Bez zawęŜeń informacje w nich zamieszczone mogłyby okazać się niepoprawne lub bezuŜyteczne, a na tym cierpiałaby cała aplikacja. Po określeniu zawęŜeń deskryptor wdroŜeniowy rozpoczyna się od elementu głównego ejb-jar. Niniejsza uwaga moŜe wydawać się banalna, ale nazwanie elementu głównego stanowi istotny element budowania dowolnego dokumentu XML. Na elemencie tym spoczywa cięŜar odpowiedzialności za reprezentację wszystkich informacji zawartych w danym dokumencie XML. Szczególnie w przypadku, kiedy inne osoby będą musiały zarządzać naszymi dokumentami, właściwe ich nazwanie moŜe oszczędzić im wiele kłopotów. PoniŜej pokazano istotne fragmenty deskryptora wdroŜeniowego XML zgodnego ze specyfikacją EJB:     Ten plik ejb-jar zawiera obiekty enterprise beans będące częścią aplikacji samoobsługowej dla pracowników.  ... 



Zastosowanie przestrzeni nazw (które w czasie tworzenia specyfikacji EJB 1.1 były jeszcze w powijakach) powoduje, Ŝe nazewnictwo elementu głównego i pozostałych jest bardziej przejrzyste. To zaś upraszcza określenie celu dokumentu; naleŜy zauwaŜyć, jak wiele dwuznaczności uniknięto poprzez zastosowanie w deskryptorze wdroŜeniowym przestrzeni nazwy takiej jak DeploymentDescriptor lub nawet EJB-DD. Wystarczy spojrzeć na przedrostek elementu, a wszystkie wątpliwości znikają.



Organizacja Podobnie jak nazwy są istotne dla przejrzystości dokumentu, jego organizacja ma zasadnicze znaczenie dla uŜyteczności danych jako źródła konfiguracji. Sposób organizacji i zagnieŜdŜania elementów i atrybutów nie tylko pomaga w zrozumieniu przeznaczenia dokumentu, ale gwarantuje równieŜ, Ŝe zawarte w nim informacje konfiguracyjne będą mogły być wykorzystane w róŜnych aplikacjach. Równie waŜna jest umiejętność ustalenia, kiedy nie składować informacji tak, by była ona współuŜytkowana. Szczególnie istotny jest tutaj przypadek deskryptora wdroŜeniowego; kaŜdy obiekt EJB ma działać niezaleŜnie od innych i posiadać tylko te informacje, które uzyskał z odpowiadającego mu pojemnika (ang. containter). MoŜe to stanowić problem, jeśli obiekty bean



Deskryptory wdroŜeniowe EJB



276



współdziałają ze sobą poza ścisłymi zasadami narzucanymi przez programistę — istnieje wtedy moŜliwość zburzenia logiki biznesowej i obniŜenia wydajności. Dlatego właśnie kaŜdy wpis EJB jest niezaleŜny od pozostałych. W poniŜszym przykładzie za pomocą dokumentu XML opisano obiekt bean sesji:    Obiekt bean EmployeeServiceAdmin stanowi implementację sesji wykorzystywanej przez administratora aplikacji.  EmployeeServiceAdmin com.wombat.empl.EmployeeServiceAdminHome com.wombat.empl.EmployeeServiceAdmin com.wombat.empl.EmployeeServiceAdmin-Bean Stateful Bean   Referencja do bazy JDBC. EmployeeService zawiera dziennik wszystkich transakcji dokonywanych poprzez bean EmployeeService na potrzeby audytu.  jdbc/EmployeeAppDB javax.sql.DataSource Containter   



Elementy nie tylko izolują ten obiekt bean od wszelkich innych, ale równieŜ umoŜliwiają logiczne grupowanie danych. Element resource-ref zawiera informacje odpowiadające określonemu wpisowi związanemu ze środowiskiem. W ten sposób aplikacja przetwarzająca i wykorzystująca dane, a takŜe programiści i administratorzy systemu zarządzający aplikacją mogą w prosty sposób zlokalizować i zaktualizować informacje o obiekcie bean lub serwerze EJB. Większą grupą — i nie tak łatwo rozpoznawalną — jest element enterprise-beans. Dzięki niemu moŜliwe jest zamieszczenie informacji specyficznych dla danego pojemnika, a nie mających zastosowania do obiektów bean; informacje te nie zostaną wymieszane z tymi specyficznymi dla EJB. Jest to waŜne rozgraniczenie; za jego pomocą w dalszej części rozdziału oddzielimy informacje konfiguracji serwera i klientów XML-RPC. Wreszcie — do tego elementu macierzystego moŜna dodać dowolną liczbę obiektów bean; tutaj zamieszczony jest przykład tylko jednego obiektu sesji bean, ale moŜna ich wstawić dowolnie wiele, tak by odpowiadały wielu obiektom bean w tworzonym pliku jar. Choć pokazany plik XML został opisany pobieŜnie, Czytelnik moŜe juŜ domyślać się, jak nazywać i organizować pliki XML tego rodzaju we własnych aplikacjach oraz w opisywanym przykładzie XML-RPC. Niemal kaŜda aplikacja ma odmienne potrzeby, co pociąga za sobą odmienną organizację dokumentu XML oraz inny zestaw zawęŜeń. Skoro przyjrzeliśmy się juŜ przykładowi konfigurowania serwera aplikacji za pomocą języka XML i zaczęliśmy zastanawiać się nad stworzeniem własnego pliku konfiguracyjnego, spróbujmy podejść do tematu praktycznie i zbudować właśnie taki plik dla naszych klas XML-RPC.



Tworzenie pliku konfiguracyjnego XML



277



Tworzenie pliku konfiguracyjnego XML Aby zastosować naszą wiedzę w praktyce, zbudujemy plik konfiguracyjny XML dla klas XMLRPC, które napisaliśmy w poprzednim rozdziale. PosłuŜy nam to jako doskonały przykład zastosowania informacji konfiguracyjnych w formacie XML; mamy juŜ dostępny parser XML (wykorzystany w serwerze XML-RPC) i moŜliwe jest uŜycie tego samego pliku konfiguracyjnego dla klientów i serwera. Co więcej, plik konfiguracyjny mógłby być edytowany za pomocą interfejsu IDE XML, a nie za pomocą własnego interfejsu do edycji pliku we własnym formacie. To wszystko przyczynia się do zmniejszenia ilości kodu koniecznego do budowania złoŜonych aplikacji. Zanim zaczniemy pisać plik konfiguracyjny, musimy określić, jakie informacje będzie moŜna z niego odczytać: • port, na którym ma być uruchomiony serwer XML-RPC, • klasa parsera, którą serwer wykorzysta jako sterownik SAX, • procedury obsługi dla serwera XML-RPC, • identyfikator klasy, • nazwa klasy, • nazwa hosta, z którym mają się łączyć klienty XML-RPC, • port, z którym mają się łączyć klienty XML-RPC, • klasa parsera, którą klient wykorzysta jako sterownik SAX. To wszystkie informacje, jakie trzeba przekazać serwerowi i klientom, aby te mogły zostać uruchomione z tylko jednym parametrem — połoŜeniem pliku konfiguracyjnego. Pamiętając o tym, zabierzmy się do pisania samego pliku konfiguracyjnego.



Od czego zacząć? Podobnie jak w przypadku deskryptora wdroŜeniowego EJB, nasz plik musi zawierać standardowy nagłówek XML. To chyba nie powinno przedstawiać trudności; poza tym trzeba jeszcze tylko pamiętać o określeniu przestrzeni nazw i elementu głównego dokumentu. Choć w środowisku produkcyjnym uŜylibyśmy przestrzeni nazw kojarzącej się z przeznaczeniem dokumentu (np. XMLRPC lub XmlRpcConfig), tutaj wciąŜ będziemy uŜywać nazwy JavaXML, starając się zachować jednolity schemat we wszystkich przykładach w tej ksiąŜce. Deklarujemy przestrzeń nazw tak jak we wcześniejszych rozdziałach. Element główny pełni rolę identyfikatora przeznaczenia dokumentu; tak więc nazwa xmlrpc-config będzie tutaj odpowiednia. Często jest tak — szczególnie w złoŜonych dokumentach XML — Ŝe najprostsze rozwiązanie jest rozwiązaniem najlepszym. Nazewnictwo elementów XML nie stanowi tutaj wyjątku. Po podjęciu tych wstępnych decyzji moŜna rozpocząć budowę pliku konfiguracyjnego dla posiadanych klas XML-RPC. PoniŜej przedstawiona jest początkowa deklaracja XML oraz element główny:   



Tworzenie pliku konfiguracyjnego XML



278



W tym miejscu moŜna jeszcze dodać odwołanie do definicji DTD lub schematu zawęŜającego dokument oraz instrukcje przetwarzania dla aplikacji, które potem będą wykorzystywały i przetwarzały ten plik. Tutaj jednak pominiemy te elementy — nasz program będzie po prostu przetwarzał dokument „tak jak jest” i zwracał wymagane dane konfiguracyjne serwerowi i klientom XML-RPC.



Organizacja Mając juŜ taki szkielet pliku konfiguracyjnego, pora zastanowić się nad jego organizacją. Chodzi tu zarówno o grupowanie elementów, jak i o określenie, czy informacje konfiguracyjne będą współuŜytkowane przez serwery i klienty. Najlepszym wyjściem będzie pogrupowanie pliku tak, jak grupowalibyśmy informacje konfiguracyjne „ręcznie”. Nasze wymagania nie są zbyt wielkie, więc proces ten będzie łatwo przeprowadzić. Sam serwer wymaga przede wszystkim następujących informacji: • port, na którym ma być uruchomiony serwer XML-RPC, • klasa parsera, którą serwer wykorzysta jako sterownik SAX. Te natomiast będą powtarzane wielokrotnie i moŜna je pogrupować; w zestawie procedur obsługi kaŜda procedura obsługi będzie zawierała identyfikator i nazwę klasy: • procedury obsługi dla serwera XML-RPC, • identyfikator klasy, • nazwa klasy. Klient XML-RPC korzysta przynajmniej z trzech róŜnych informacji; wiemy jednak, Ŝe port klienta będzie taki sam jak serwera XML-RPC. Najprawdopodobniej to samo dotyczy sterownika SAX. Sensownie więc byłoby współdzielić tę informację tak, Ŝeby ewentualne zmiany wprowadzać tylko w jednym elemencie XML, a nie oddzielnie dla klienta i serwera. PoniewaŜ port i klasa SAX są współuŜytkowane, sensownie jest z kolei dodać do tych współuŜytkowanych informacji nazwę hosta; co prawda korzysta z niej tylko klient, ale „dobrze pasuje” do numeru portu wykorzystywanego w Ŝądaniach XML-RPC: • nazwa hosta, z którym mają się łączyć klienty XML-RPC, • port, z którym mają się łączyć klienty XML-RPC, • klasa parsera, którą klient wykorzysta jako sterownik SAX. Zasadnicza organizacja pliku jest juŜ określona. Mamy dwie grupy informacji konfiguracyjnych: „informacje współuŜytkowane” (wykorzystywane przez klienta i serwer) oraz „informacje o procedurach obsługi” z wpisami typu „procedura obsługi” dla kaŜdej procedury wykorzystanej w XML-RPC. Powstaną więc dwa podstawowe podzbiory w pliku konfiguracyjnym; ten ostatni będzie zawierał elementy zagnieŜdŜone, opisujące dalsze podzbiory.



Informacje współdzielone Niewiele pozostało do dodania odnośnie nazwy hosta, numeru portu i klasy parsera SAX, które nasz serwer oraz klienty wykorzystają w momencie uruchamiania i w czasie połączenia. Nawet nad nazwami odpowiednich elementów nie ma się co długo zastanawiać: hostname, port i parserClass. Znów obowiązuje zasada — im prościej, tym lepiej. Aby zobrazować sposób wykorzystania atrybutów, do elementu port dodamy atrybut type. Atrybut ten przyjmie wartość



Tworzenie pliku konfiguracyjnego XML



279



„protected” (chroniony) lub „unprotected” (niechroniony). Kiedy port jest chroniony, aby uzyskać połączenie, trzeba przedsięwziąć pewne dodatkowe czynności, np. zakodować Ŝądanie protokołem SSL. W naszych przykładowych klasach XML-RPC serwer nasłuchuje na porcie niechronionym; jednak zastosowanie takiego atrybutu przyczynia się do zwiększenia elastyczności rozwiązania — pozwala w przyszłości dodać obsługę portów chronionych:    localhost 8585  org.apache.xerces.parsers.SAXParser  



Procedury obsługi XML-RPC Definiując procedury obsługi przede wszystkim musimy zagwarantować, Ŝe będą one wykorzystywane tylko przez serwer XML-RPC. Choć nie mamy Ŝadnych innych informacji poza konfiguracją procedur obsługi rozumianą tylko przez serwer, to jest moŜliwe — a nawet dość prawdopodobne — Ŝe kiedyś do pliku konfiguracyjnego zostaną dodane informacje bardziej specyficzne dla serwera. Nasz parser, zamiast szukać specyficznych elementów (i wymuszać zmianę kodu po dodaniu nowych informacji konfiguracyjnych), moŜe szukać elementu specyficznego dla serwera, np. xmlrpc-server. Aplikacja serwera odczyta zawarte w nim informacje, zaś klienty zignorują je i w ogóle nie będą musiały znać ich składni. Oprócz tego tak przygotowany plik konfiguracyjny jest czytelniejszy dla człowieka. Tak więc elementem xmlrpc-server „otoczymy” informacje o procedurach obsługi. Ponadto konieczne jest pogrupowanie procedur obsługi — wykorzystamy tutaj element o nazwie handlers. I znów — grupowanie upraszcza określenie przeznaczenia i sposobu wykorzystania informacji konfiguracyjnych. Do konfiguracji serwera dodajemy informacje opisujące klasy HelloHandler i Scheduler jako procedury obsługi XML-RPC:    localhost 8585  org.apache.xerces.parsers.SAXParser    



Tworzenie pliku konfiguracyjnego XML



280



  hello HelloHandler   scheduler Scheduler    



Nawet w tak niewielkim dokumencie moŜna zastosować zamienne sposoby reprezentacji danych. MoŜliwe byłoby opisanie procedur obsługi za pomocą następującej struktury: 



W niemal kaŜdym dokumencie będziemy musieli wybrać nie tylko to, jakie dane przechowywać, ale równieŜ jak je przechowywać. W naszym przykładzie wykorzystujemy element handler; wynika to z faktu, Ŝe w przyszłości być moŜe zechcemy dodać nowe informacje o procedurze obsługi (np. opis lub lokalizacja klasy w sieci). Element z zagnieŜdŜonymi elementami potomnymi pozwala na bezproblemowe dodawanie takich informacji jako nowych elemenówy potomnych; dodawanie ich jako atrybuty pogorszyłoby czytelność zapisu (element byłby bardzo długi).



ZawęŜenia dokumentu Wspomnieliśmy, Ŝe w pliku deskryptora wdroŜeniowego EJB definicja DTD słuŜyła do zagwarantowania, Ŝe nie zostaną wykorzystane nieprawidłowe elementy i atrybuty — dzięki temu plik jest „rozumiany” przez dowolny serwer. To samo trzeba zrobić z naszym plikiem konfiguracyjnym. Stworzenie definicji DTD (w przypadku tak skromnego pliku będzie ona bardzo prosta) gwarantuje, Ŝe nasza aplikacja moŜe oczekiwać od dokumentu zgodności z pewnymi narzuconymi zasadami. W przykładzie 11.1 przedstawiono kompletną definicję DTD dla stworzonego pliku XML.



Przykład 11.1 Definicja DTD dla pliku konfiguracyjnego XML-RPC           



Tworzenie pliku konfiguracyjnego XML



281



Teraz do takiej definicji naleŜy odwołać się z pliku konfiguracyjnego:    ... 



Tutaj odwołujemy się do definicji XmlRpc.dtd umieszczonej w podkatalogu DTD/.



Ostatnie przygotowania Stworzenie pliku konfiguracyjnego i jego zawęŜeń okazało się dość łatwym zadaniem. Kiedy juŜ programista zrozumie mechanikę działania XML, jedyną trudnością będzie podjęcie odpowiednich decyzji projektowych. WaŜne jest uŜycie zrozumiałych i prostych nazw, logiczne pogrupowanie elementów i określenie, kiedy informacja ma być współdzielona przez wiele aplikacji. Po podjęciu takich decyzji samo zbudowanie pliku XML to kwestia kilku minut. W przypadku naszej aplikacji informacje zawarte w pliku konfiguracyjnym są naprawdę skromne, co dodatkowo upraszcza całą operację. Kompletny plik konfiguracyjny przedstawiony jest w przykładzie 11.2.



Przykład 11.2. Kompletny plik konfiguracyjny XML dla klas XML-RPC     localhost 8585  org.apache.xerces.parsers.SAXParser       hello HelloHandler   scheduler Scheduler    



Odczytywanie pliku konfiguracyjnego XML



282



PowyŜszy plik naleŜy zachować pod nazwą xmlrpc.xml i sprawdzić, czy jest dostępny dla kodu naszej aplikacji. Teraz zajmiemy się stworzeniem klasy SAX odczytującej te informacje i udostępniającej je serwerowi i klientom XML-RPC.



Odczytywanie pliku konfiguracyjnego XML Aby klasy XML-RPC mogły korzystać z utworzonego pliku konfiguracyjnego, trzeba zbudować klasę pomocniczą przetwarzającą te informacje i udostępniającą je serwerowi i klientom. MoŜna byłoby wbudować ten mechanizm w metody zawarte w klasach XML-RPC (podobnie jak korzystaliśmy z metody getHandlers() w klasie LightweightServer), ale uŜycie oddzielnej klasy umoŜliwia współuŜytkowanie jej przez serwer i klienty, dzięki czemu unikamy duplikacji kodu. Wiemy juŜ, jakie informacje mają zostać uzyskane i moŜemy rozpocząć budowanie szkieletu klasy, zawierającego metody dostępu do danych. Faktyczne zawartości stworzonych zmiennych przynaleŜnych zostaną uzyskane z procesu przetwarzania, który wkrótce skonstruujemy.



Pobieranie informacji o konfiguracji Kod przetwarzający moŜna byłoby dodać bezpośrednio do klasy com.oreilly.xml.LightweightXmlRpcServer i do klientów. Jednak w ten sposób powielony zostałby ten sam kod. Zamiast tego budujemy nową klasę narzędziową z pakietu com.oreilly.xml: XmlRpcConfiguration. ZaląŜek tej klasy przedstawiony jest w przykładzie 11.3. Konstruktor pobiera plik albo strumień InputStream, z którego zostaną odczytane informacje o konfiguracji. Stworzono równieŜ proste metody dostępu do danych po ich załadowaniu. Odizolowanie wejścia i wyjścia klas od specyficznych konstrukcji XML umoŜliwia zmianę mechanizmu przetwarzania (informacje na temat są zawarte w kolejnym podrozdziale) bez przebudowywania serwera i klienta XML-RPC. To o wiele bardziej obiektowe rozwiązanie niŜ zagnieŜdŜanie kodu przetwarzającego w kodzie klientów i serwera.



Przykład 11.3. Klasa XmlRpcConfiguration, odczytująca dane konfiguracyjne XML package com.oreilly.xml; import import import import import



java.io.FileInputStream; java.io.FileNotFoundException; java.io.InputStream; java.io.IOException; java.util.Hashtable;



/** * XmlRpcConfiguration to klasa narzędziowa * ładująca dane konfiguracyjne dla serwerów i klientów XML-RPC. * * @author Brett McLaughlin * @version 1.0 */ public class XmlRpcConfiguration { /** Z tego strumienia odczytujemy dane konfiguracyjne XML */ private InputStream in; /** Port, na którym działa serwer */ private int portNumber;



Odczytywanie pliku konfiguracyjnego XML /** Nazwa hosta, na którym uruchomiono serwer */ private String hostname; /** Klasa sterownika SAX do załadowania */ private String driverClass; /** Procedury obsługi do zarejestrowania w serwerze XML-RPC */ private Hashtable handlers; /** *  * Tutaj określamy plik, z którego odczytamy * informacje o konfiguracji. * 
 * * @param filename String nazwa pliku * zawierającego konfigurację XML. */ public XmlRpcConfiguration(String filename) throws IOException { this(new FileInputStream(filename)); } /** *  * Tutaj określamy plik, z którego odczytamy * informacje o konfiguracji. * 
 * * @param in InputStream z którego * odczytamy informacje o konfiguracji. */ public XmlRpcConfiguration(InputStream in) throws IOException { this.in = in; portNumber = 0; hostname = ""; handlers = new Hashtable(); // Przetwarzamy dane XML o konfiguracji } /** *  * Zwraca numer portu, na którym nasłuchuje serwer. * 
 * * @return int - port serwera. */ public int getPortNumber() { return portNumber; } /** *  * Zwraca nazwę hosta, w którym uruchomiono serwer. * 
 * * @return String - nazwa hosta serwera. */



283



Odczytywanie pliku konfiguracyjnego XML



284



public String getHostname() { return hostname; } /** *  * Zwraca klasę sterownika SAX do załadowania. * 
 * * @return String - nazwa klasy sterownika SAX. */ public String getDriverClass() { return driverClass; } /** *  * Zwraca procedury obsługi do zarejestrowania przez serwer. * 
 * * @return Hashtable - struktura procedur obsługi. */ public Hashtable getHandlers() { return handlers; } }



Po zbudowaniu takiego szkieletu dodamy kod wypełniający zmienne danymi konfiguracyjnymi za pośrednictwem interfejsu JDOM. Aby zagwarantować, Ŝe informacje te będą dostępne w razie potrzeby, metodę przetwarzającą umieścimy w konstruktorze klasy. Stworzenie tych podstawowych metod dostępu pozwoli ukryć mechanizm samego pobierania informacji konfiguracyjnych przed klasami i aplikacjami korzystającymi z tych informacji. Zmiany w wersji JDOM, a nawet wykorzystanie zupełnie innych metod dostępu do danych, wpłyną wyłącznie na tę klasę; klienty i serwer XML-RPC pozostaną niezmienione. To bardzo elastyczny i perspektywiczny sposób pobierania informacji konfiguracyjnych.



Ładowanie informacji konfiguracyjnych Teraz moŜna juŜ rozpocząć wpisywanie kodu odpowiedzialnego za przetwarzanie. My akurat mamy zadanie ułatwione — znamy strukturę wejściowego dokumentu XML (dzięki definicji DTD i narzucanym przez nią zawęŜeniom). MoŜemy więc bezpośrednio uzyskać dostęp do elementów dokumentu, których wartości zamierzamy pobrać. Najlepiej znów przywołać obraz hierarchii drzewiastej: „przechodzimy” po drzewie i pobieramy wartości tych elementów, na których nam zaleŜy. Na rysunku 11.1. przedstawiono taką właśnie reprezentację pliku konfiguracyjnego XML. Mając taki model przed oczami, łatwiej będzie uŜyć metod getChildren() oraz getChild(), udostępnianych przez JDOM i za ich pomocą nawigować po elementach XML; na „znalezionym” w ten sposób elemencie wywołujemy metodę getContent() i wykorzystujemy uzyskaną wartość w aplikacji. Wcześniej konieczne jest zaimportowanie odpowiednich klas JDOM (oraz klas pomocniczych Javy), stworzenie nowej metody przetwarzającej konfigurację i uruchomienie jej poprzez konstruktor XmlRpcConfiguration. Kod ładujący informacje konfiguracyjne przedstawiony jest poniŜej:



Odczytywanie pliku konfiguracyjnego XML



Rysunek 11.1. Drzewiasta struktura pliku konfiguracyjnego XML import import import import import import import



java.io.FileInputStream; java.io.FileNotFoundException; java.io.InputStream; java.io.IOException; java.util.Hashtable; java.util.Iterator; java.util.List;



import import import import import import



org.jdom.Document; org.jdom.Element; org.jdom.JDOMException; org.jdom.Namespace; org.jdom.input.Builder; org.jdom.input.DOMBuilder;



... /** *  * Tutaj określamy plik, z którego odczytamy * informacje o konfiguracji. * 
 * * @param in InputStream z którego * odczytamy informacje o konfiguracji. */ public XmlRpcConfiguration(InputStream in) throws IOException { this.in = in; portNumber = 0;



285



Odczytywanie pliku konfiguracyjnego XML



286



hostname = ""; handlers = new Hashtable(); // Przetwarzamy dane XML o konfiguracji parseConfiguration(); } ... /** *  * Przetwarzamy informacje o konfiguracji XML i * udostępniamy je klientom. * 
 * * @throws IOException w razie wystąpienia błędu. */ private void parseConfiguration() throws IOException { try { // śądamy implementacji DOM i parsera Xerces. Builder builder = new DOMBuilder("org.jdom.adapters.XercesDOMAdapter"); // Pobieramy dokument konfiguracyjny, wykonując sprawdzanie poprawności. Document doc = builder.build(in); // Pobieramy element główny. Element root = doc.getRootElement(); // Uzyskujemy przestrzeń nazw JavaXML. Namespace ns = Namespace.getNamespace("JavaXML", "http://www.oreilly.com/catalog/javaxml/"); // Ładujemy nazwę hosta, port i klasę procedury obsługi. hostname = root.getChild("hostname", ns).getContent(); driverClass = root.getChild("parserClass", ns).getContent(); portNumber = Integer.parseInt(root.getChild("port", ns).getContent()); // Pobieramy procedury obsługi List handlerElements = root.getChild("xmlrpc-server", ns) .getChild("handlers", ns) .getChildren("handler", ns); Iterator i = handlerElements.iterator(); while (i.hasNext()) { Element current = (Element)i.next(); handlers.put(current.getChild("identifier", ns).getContent(), current.getChild("class", ns).getContent()); } } catch (JDOMException e) { throw new IOException(e.getMessage()); } } }



Po stworzeniu egzemplarza klasy, informacje konieczne do skonfigurowania serwerów i klientów XML-RPC są przetwarzane i ładowane do zmiennych przynaleŜnych. Jedyna funkcja, jaka nie została tutaj zaimplementowana to rejestrowanie komunikatów o błędach; funkcja taka powinna



Odczytywanie pliku konfiguracyjnego XML



287



znaleźć się w aplikacji produkcyjnej — tutaj pomijamy tę sprawę ze względu na konieczność utrzymania zwięzłości i przejrzystości kodu. Po uzyskaniu elementu głównego (doc.getRootElement()) za pomocą interfejsu JDOM lokalizujemy elementy w oparciu o strukturę drzewiastą przestawioną na rysunku 11.1; po odnalezieniu kaŜdego elementu pobieramy jego zawartość tekstową i wstawiamy do zmiennej. W naszym przykładzie do stworzenia obiektu JDOM Document uŜyliśmy klasy DOMBuilder. Jest to decyzjanieco dyskusyjna, poniewaŜ juŜ po zbudowaniu elementu Document nie istnieją Ŝadne związki ani z interfejsem SAX, ani z DOM. Równie łatwo (i tak naprawdę szybciej) moŜna byłoby wykorzystać w tym celu klasę SAX SAXBuilder; w tej ksiąŜce wykorzystywane są na przemian oba te modele, co dowodzi elastyczności interfejsu JDOM. W ten sposób wykazujemy takŜe, Ŝe istnieje moŜliwość opracowania zupełnie nowych implementacji do tworzenia hierarchii drzewiastej, nie opartej ani na interfejsie SAX, ani na DOM.



PoniewaŜ elementów opisujących procedury obsługi jest wiele, do uzyskania ich listy List wykorzystujemy metodę getChildren(). Następnie przetwarzamy kaŜdy element listy. Po wykonaniu tych czynności skompilowana klasa moŜe juŜ zostać uŜyta w klasach XML-RPC z poprzedniego rozdziału.



Korzystanie z informacji konfiguracyjnych Niełatwe zadanie wykorzystania danych XML na potrzeby konfiguracji mamy juŜ za sobą. Za pomocą stworzonej klasy XmlRpcConfiguration w prosty sposób pobierzemy te dane do naszej aplikacji. Serwer i klienty powinny tylko znać połoŜenie pliku konfiguracyjnego, który następnie przekaŜą klasie pomocniczej XmlRpcConfiguration. W aplikacji produkcyjnej połoŜenie tego pliku określane byłoby za pomocą stałej w odpowiednim pliku lub klasie, ewentualnie podawane jako wstępny argument, gdyby aplikacja miała postać serwleta Javy.



Zmiany w serwerze Teraz zmienimy serwer LightweightXmlRpcServer tak, aby korzystał z konfiguracji w postaci danych XML, a nie z pliku właściwości stworzonego w poprzednim rozdziale. Usuniemy równieŜ argument wiersza poleceń określający port — tę informację program pobierze teraz z pliku konfiguracyjnego. Konieczne więc będzie takie zmodyfikowanie konstruktora, aby pobierał wyłącznie plik konfiguracyjny, a następnie za pomocą klasy XmlRpcConfiguration uzyskiwał informacje o porcie i procedurach obsługi do zarejestrowania. Z klasy serwera usuniemy równieŜ metodę getHandlers(). Zmiany przedstawione są w przykładzie 11.4.



Przykład 11.4. Klasa LightweightXmlRpcServer wykorzystująca plik konfiguracyjny XML /** * LightweightXmlRpcServer to klasa narzędziowa * uruchamiająca serwer XML-RPC nasłuchujący Ŝądań HTTP * i rejestrująca procedury obsługi zdefiniowane w pliku konfiguracyjnym. * * @author Brett McLaughlin * @version 1.0 */



Odczytywanie pliku konfiguracyjnego XML public class LightweightXmlRpcServer { /** Klasa narzędziowa serwera XML-RPC */ private WebServer server; /** Plik konfiguracyjny */ private XmlRpcConfiguration config; // Usunięto informacje o porcie i nazwie pliku /** *  * Tutaj będziemy przechowywać plik konfiguracyjny * wykorzystywany przez serwer. * 
 * * @param configFile String nazwa pliku do * pobrania informacji o konfiguracji. * @throws IOException kiedy serwer nie moŜe * pobrać informacji konfiguracyjnych */ public LightweightXmlRpcServer(String configFile) throws IOException { config = new XmlRpcConfiguration(configFile); } /** *  * Uruchomienie serwera. * 
 * * @throws IOException zgłaszany w razie problemów. */ public void start() throws IOException { try { // Korzystamy z parsera SAX Apache Xerces XmlRpc.setDriver("org.apache.xerces.parsers.SAXParser"); System.out.println("Uruchamianie serwera XML-RPC..."); server = new WebServer(config.getPortNumber()); // Register handlers registerHandlers(config.getHandlers()); } catch (ClassNotFoundException e) { throw new IOException("Błąd ładowania parsera SAX: " + e.getMessage()); } } // Metoda getHandlers() została usunięta z kodu źródłowego.



/** *  * Statyczny punkt rozpoczęcia programu. * 
 */



288



Odczytywanie pliku konfiguracyjnego XML



289



public static void main(String[] args) { if (args.length < 1) { System.out.println( "UŜycie: " + "java com.oreilly.xml.LightweightXmlRpcServer " + "[plikKonfiguracyjny]"); System.exit(-1); } // Utworzenie serwera przeniesiono do bloku try/catch, // dzięki czemu klient "dowiaduje się" o ewentualnych błędach // przy uruchamianiu



try { // Ładowanie informacji konfiguracyjnych LightweightXmlRpcServer server = new LightweightXmlRpcServer(args[0]); // Uruchomienie serwera. server.start(); } catch (IOException e) { System.out.println(e.getMessage()); } } }



Dzięki tym zmianom nasz serwer pobierze informacje o konfiguracji z pliku XML i będzie potrafił zakomunikować o ewentualnych błędach, jakie wystąpiły w czasie tego procesu. Istniejąca juŜ metoda registerHandlers() obsługuje strukturę Hashtable zwróconą z wywołania getHandlers() z klasy XmlRpcConfiguration, a więc w tym miejscu Ŝadne zmiany nie są potrzebne. Co prawda w czasie uruchamiania serwera nie widać nic nadzwyczajnego (przykład 11.5), ale nasza aplikacja jest teraz naprawdę o wiele lepsza.



Przykład 11.5. Komunikaty w czasie uruchamiania zmodyfikowanej klasy LightweightXmlRpcServer $ java com.oreilly.xml.LightweightXmlRpcServer conf/xmlrpc.xml Uruchamianie serwera XML-RPC... Port: 8585 Zarejestrowana w serwerze nazwa scheduler odpowiada klasie Scheduler Zarejestrowana w serwerze nazwa hello odpowiada klasie HelloHandler



Zmiany w kliencie Modyfikacja klienta pod kątem korzystania z nowego formatu danych konfiguracyjnych jest jeszcze prostsza. Po zaimportowaniu klasy XmlRpcConfiguration nasza klasa SchedulerClient potrafi juŜ pobrać nazwę hosta i numer portu, pod które moŜna zgłaszać Ŝądania XML-RPC. Wprowadźmy zmiany pokazane w przykładzie 11.6.



Przykład 11.6. Klasa SchedulerClient wykorzystująca plik konfiguracyjny XML import import import import import



java.io.IOException; java.net.MalformedURLException; java.util.Calendar; java.util.Date; java.util.Enumeration;



Odczytywanie pliku konfiguracyjnego XML import java.util.Hashtable; import java.util.Vector; import com.oreilly.xml.XmlRpcConfiguration; import helma.xmlrpc.XmlRpc; import helma.xmlrpc.XmlRpcClient; import helma.xmlrpc.XmlRpcException;



public class SchedulerClient { // implementacje metod addEvents() i listEvents().



public static void main(String args[]) { if (args.length < 1) { System.out.println( "Usage: java SchedulerClient [configFile]"); System.exit(-1); } try { // Ładowanie pliku konfiguracyjnego. XmlRpcConfiguration config = new XmlRpcConfiguration(args[0]); // Ładowanie klasy sterownika SAX. XmlRpc.setDriver(config.getDriverClass()); // Łączenie z serwerem. XmlRpcClient client = new XmlRpcClient("http://" + config.getHostname() + ":" + config.getPortNumber()); // Dodanie zdarzeń. addEvents(client); // Wyświetlenie zdarzeń. listEvents(client); } catch (MalformedURLException e) { System.out.println( "Niepoprawny format URL serwera: " + e.getMessage()); } catch (XmlRpcException e) { System.out.println("Wyjątek XML-RPC: " + e.getMessage()); } catch (IOException e) { System.out.println("Wyjątek IO: " + e.getMessage()); } catch (ClassNotFoundException e) { System.out.println("Odnalezienie parsera SAX nie jest moŜliwe: " + e.getMessage()); } } ... }



290



Rzeczywistość



291



Podobne zmiany moŜna równie łatwo wprowadzić w przykładzie HelloClient. Oba klienty zwrócą (co moŜe nie jest pasjonujące) dokładnie takie same wyniki, jak w poprzednim rozdziale; jednak jeśli chodzi o serwer, to zrobiliśmy rzeczywiście ogromny krok naprzód. Zmiana nazwy hosta czy numeru portu wymaga tylko wprowadzenia jednej tekstowej poprawki do pliku XML i zrestartowania klas serwera i klientów. Zanim przejdziemy do następnego rozdziału, przejrzymy alternatywne sposoby przechowywania tego typu informacji konfiguracyjnych i porównamy je z XML-em.



Rzeczywistość UwaŜny Czytelnik z pewnością zaobserwował, Ŝe granica pomiędzy przykładami w ksiąŜce a „prawdziwymi” aplikacjami zaczyna się coraz bardziej rozmywać. Serwer XML-RPC po zmianach wprowadzonych w tym rozdziale nadaje się niemal do wykorzystania produkcyjnego — posiada elastyczny format pliku konfiguracyjnego, dynamicznie rejestruje procedury obsługi i nie angaŜując potęŜnych zasobów, obsługuje Ŝądania XML-RPC. JednakŜe wykorzystanie XML-a do reprezentacji danych w „czystej postaci” to idea bardzo nowa — jak zresztą większość innych zagadnień związanych z XML-em. To tak jak z RMI i RPC — łatwo moŜna zapędzić się i przesadzić z uŜywaniem nowej technologii. PoniŜej zostaną porównane moŜliwości XML-a jako nośnika składowania danych z innymi, bardziej tradycyjnymi formatami. Czytelnik będzie mógł sam podejmować decyzje, kiedy lepiej stosować taki, a nie inny sposób zapisu, oraz porównać JDOM z innymi drogami dostępu do danych XML.



XML kontra bazy danych W zaleŜności od tego, z kim rozmawiamy na ten temat, bazy danych (a szczególnie bazy relacyjne) albo są absolutnie nie do zastąpienia, albo lada chwila znikną z powierzchni naszej planety na rzecz baz obiektowych i składnic danych XML. Jak to zwykle bywa, prawda leŜy gdzieś pośrodku. Dziesięć lat temu osoba wątpiąca w perspektywy systemów administracji bazami relacyjnymi (RDBMS) naraŜała się na śmieszność. Pięć lat temu, kiedy pojawiły się systemy administracji bazami obiektowymi (OODBMS), taka osoba miała juŜ prawo głosu, ale wciąŜ była traktowana sceptycznie. W ciągu ostatnich dwóch lat wszystko się zmieniło — dzięki OODBMS „wypłynął” XML, a niektórzy powaŜni informatycy przewidują, Ŝe XML całkowicie zastąpi tradycyjne systemy baz danych. Jaka jest prawda? Systemy RDBMS będą jeszcze przez wiele lat stosowane, o ile w ogóle kiedyś wyjdą z uŜycia. Nawet jeśli zignorujemy tak powaŜne sprawy, jak reprezentacja danych relacyjnych w XML-u, to jednak technologia RDBMS stanowi podstawę bardzo wielu uŜywanych współcześnie aplikacji. Zastosowanie XML-a stanowi realistyczne rozwiązanie w mniejszych aplikacjach, nie korzystających z własnych formatów lub własnych baz danych; jednak większość tzw. duŜych aplikacji produkcyjnych musi korzystać z istniejących juŜ danych. Dane te niemal zawsze znajdują się w relacyjnej bazie danych (zazwyczaj jest to komercyjny Oracle lub darmowy MySQL). Niemal wszystkie duŜe firmy mające wpływ na rozwój technologii wykorzystują takie systemy, dlatego zakładanie, Ŝe XML zastąpi systemy baz danych — czy nawet szybko zyska popularność — jest przesadą. Sama ilość danych składowanych w istniejących systemach (gigabajty, a często nawet terabajty) czyni XML niezbyt fortunnym sposobem reprezentacji. Nawet w idealnym projekcie XML, zupełnie nowym i nie korzystającym z Ŝadnych istniejących danych czy aplikacji i niezaleŜnym od systemów DBMS, moŜliwe jest, Ŝe na pewnym etapie trzeba będzie nawiązać komunikację ze starszymi rozwiązaniami. Przekonanie kadry zarządzającej do przejścia na format XML, kiedy dotychczasowe rozwiązanie spisuje się bez zarzutu, moŜe równieŜ sprawiać



Rzeczywistość



292



kłopoty. Nie powinniśmy więc oczekiwać, Ŝe nagle Oracle wprowadzi XML jako format przechowywania danych, czy teŜ Ŝe Sybase zakończy działalność; uŜywajmy XML do konfiguracji i transportu danych tam, gdzie jest to moŜliwe, ale przy duŜych ilościach danych nie próbujmy szukać lepszych rozwiązań niŜ istniejące. Warto jednak odnotować, Ŝe istnieje pewne rozwiązanie dla tych, którzy tak bardzo chcieliby wykorzystać XML wyłącznie do składowania danych. Istnieją produkty tworzące warstwę danych XML „na” danych relacyjnych i innych formatach (np. usługach katalogowych, o których powiemy za chwilę). W miarę dojrzewania tych narzędzi odwzorowujących, budowanie XML-owej reprezentacji baz danych staje się coraz bardziej niezawodne i proste. Nowsze firmy decydujące się na składowanie danych w czystej postaci XML-owej mają moŜliwość komunikacji ze starszymi systemami — pozwalają na to te same narzędzia. Najbardziej obiecującym produktem jest obecnie Castor, projekt open source grupy ExoLab1. Więcej informacji o systemie Castor i narzędziach dowiązywania danych ML moŜna znaleźć na stronie http://castor.exolab.org.



XML kontra usługi katalogowe i LDAP Kolejną nowością w obszarze technologii składowania danych jest protokół Lightweight Directory Access Protocol (LDAP) i usługi katalogowe. Protokół ten, początkowo opracowywany na uniwersytetach w Berkeley i Michigan, a teraz obecny w popularnym serwerze usług katalogowych firmy Netscape (http://www.netscape.com), stał się tematem wielu dyskusji. Po upowszechnieniu XML-a wiele osób waha się: kiedy lepiej korzystać z usług katalogowych niŜ z XML-a? Usługi katalogowe to doskonały sposób administracji katalogami, pocztą, adresami i kalendarzami w firmie; protokół LDAP zyskał takŜe popularność jako sposób administrowania konfiguracjami. Przechowywanie informacji o konfiguracji aplikacji oraz sposobie reagowania na podstawowe zdarzenia związane z aplikacją (np. autoryzacja) jest bardzo często wykonywane właśnie przez serwer usług katalogowych. UmoŜliwia on szybsze przeszukiwanie i pobieranie informacji niŜ baza danych; oferuje dane w formacie hierarchicznym i tym samym świetnie nadaje się na potrzeby konfiguracji. Po przeczytaniu niniejszego rozdziału, w którym przedstawiony jest sposób przechowywania informacji za pomocą XML-a, rodzi się pytanie, które z rozwiązań jest lepsze w konkretnych sytuacjach. I tu niespodzianka — samo pytanie jest źle postawione! Tak naprawdę technologii LDAP i XML nie moŜna porównywać, bo zostały stworzone w zupełnie innych celach. LDAP i usługi katalogowe słuŜą do udostępniania technologii lub komponentów pod określonymi nazwami; natomiast XML słuŜy do składowania i przesyłania danych zawartych w tych komponentach. Bardziej odpowiednie byłoby więc pytanie „W jakich sytuacjach naleŜy integrować LDAP i XML?”. Odpowiedź leŜy w tych samych technologiach dowiązywania danych XML, które zostały wspomniane przy okazji poruszania tematu baz danych; projekt Castor oferuje kompletne powiązanie technologii XML i LDAP. Co więcej, usługi katalogowe ewoluują w kierunku jednolitego sposobu przechowywania danych; takim nośnikiem z pewnością mógłby być XML. PoniewaŜ zarówno LDAP, jak i XML są formatami hierarchicznymi, połączenie usług LDAP i języka XML nie powinno nikogo dziwić.



1



KsiąŜka nie zawiera szczegółowych informacji na temat ExOffice i grupie ExoLab; warto jednak zauwaŜyć, Ŝe grupa ta silnie wspiera technologie open source, szczególnie te związane z XML-em i Javą. Więcej informacji moŜna znaleźć na stronie http://www.exolab.org.



Rzeczywistość



293



JDOM, SAX czy DOM Kiedy rozpatruje się alternatywy XML-a, waŜne jest takŜe rozwaŜenie róŜnych sposobów dostępu do danych XML. Czytelnik widział, w jak prosty sposób moŜna pobrać informacje o konfiguracji poprzez interfejs JDOM; tutaj zobaczy, jak moŜna to zrobić inaczej. Kiedy aplikacje XML wdraŜane są w środowiskach produkcyjnych, zrozumienie, dlaczego taka, a nie inna decyzja jest najlepsza, staje się często waŜniejsze niŜ sama ta decyzja! Dlatego teraz Czytelnik będzie mógł poznać inne sposoby uzyskania dostępu do danych XML z poziomu Javy. Do pobrania danych konfiguracyjnych XML zastosowany został interfejs JDOM: private void parseConfiguration() { try { // śądamy implementacji DOM i parsera Xerces Builder builder = new DOMBuilder("org.jdom.adapters.XercesDOMAdapter"); // Pobieramy dokument konfiguracyjny, wykonując sprawdzanie poprawności. Document doc = builder.build(in); // Pobieramy element główny. Element root = doc.getRootElement(); // Uzyskujemy przestrzeń nazw JavaXML. Namespace ns = Namespace.getNamespace("JavaXML", "http://www.oreilly.com/catalog/javaxml/"); // Ładujemy nazwę hosta, port i klasę procedury obsługi. hostname = root.getChild("hostname", ns).getContent(); driverClass = root.getChild("parserClass", ns).getContent(); portNumber = Integer.parseInt(root.getChild("port", ns).getContent()); // Pobieramy procedury obsługi. List handlerElements = root.getChild("xmlrpc-server", ns) .getChild("handlers", ns) .getChildren("handler", ns); Iterator i = handlerElements.iterator(); while (i.hasNext()) { Element current = (Element)i.next(); handlers.put(current.getChild("identifier", ns).getContent(), current.getChild("class", ns).getContent()); } } catch (JDOMException e) { throw new IOException(e.getMessage()); } }



Aby dobrze zilustrować róŜnicę pomiędzy JDOM-em, SAX-em i DOM-em, naleŜy pokazać, w jaki sposób moŜna uzyskać te same informacje poprzez SAX i DOM.



SAX Największą trudnością przy pisaniu kodu z wykorzystaniem interfejsu SAX jest to, Ŝe stosowane tutaj podejście nie jest w tak duŜym stopniu obiektowe, w jakim jest hierarchiczne. PoniewaŜ zdarzenia SAX występują sekwencyjnie, nie jest moŜliwe bezpośrednie operowanie na elementach



Rzeczywistość



294



potomnych. Konieczne jest zarezerwowanie pamięci do przechowania przetwarzanego elementu — dane tego elementu zostaną uzyskane dopiero w następnym wywołaniu. Przetwarzanie w tym interfejsie wymaga zazwyczaj odczytania dokumentu i przechowania danych przekazanych do wywołania characters() pod nazwą ostatniego przetwarzanego elementu (poprzez wywołanie startElement()). Następnie, pod koniec przetwarzania elementu (endElement() lub endDocument()), informacje te ładowane są z pamięci i wykorzystywane. SAX i jego sekwencyjny mechanizm są czasem szybsze od DOM-a (lub JDOM-a z implementacją DOM), ale uzyskany kod nie jest tak przejrzysty i trudniej usunąć z niego błędy. Metoda parseConfiguration(), przepisana do obsługi SAX-a, wyglądałaby następująco: private void parseConfiguration() { try { XMLReader parser = XMLReaderFactory.createXMLReader( "org.apache.xerces.parsers.SAXParser"); parser.setContentHandler(new ConfigurationHandler()); parser.parse(new InputSource(in)); } catch (JDOMException e) { // Komunikat o błędzie } }



Implementacja SAX XMLReader jest ładowana po zarejestrowaniu implementacji ContentHandler. Typowe dla SAX-a jest to, Ŝe większość kodu aplikacji znajdzie się w metodzie ContentHanlder: /** *  * Ta klasa wewnętrzna obsłuŜy wywołania * odczytujące dane konfiguracyjne. * 
 */ class ConfigurationHandler extends DefaultHandler { /** Miejsce składowania zawartości elementu */ private Hashtable storage; /** Nazwa ostatnio zgłoszonego elementu */ private String currentElement; /** Stałe odpowiadające nazwom elementów */ private static final String HOSTNAME_ELEMENT = "hostname"; private static final String PORTNUMBER_ELEMENT = "port"; private static final String DRIVER_CLASS_ELEMENT = "parserClass"; private static final String HANDLER_ELEMENT = "handler"; private static final String HANDLER_ID_ELEMENT = "identifier"; private static final String HANDLER_CLASS_ELEMENT = "class"; /** *  * Tutaj inicjalizujemy miejsce składowania. * 
 */ public ConfigurationHandler() { storage = new Hashtable(); }



Rzeczywistość



295



/** *  * Przechwytujemy nazwę zgłoszonego elementu. * 
 */ public void startElement(String namespaceURI, String localName, String rawName, Attributes atts) throws SAXException { currentElement = localName; } /** *  * Dodajemy zgłaszane dane znakowe do tych juŜ * znajdujących się w pamięci. * 
 */ public void characters(char[] ch, int start, int end) throws SAXException { String data = new String(ch, start, end).trim(); if (storage.containsKey(currentElement)) { data = (String)storage.get(currentElement) + data.trim(); } storage.put(currentElement, data); } /** *  * PoniewaŜ informacje zagnieŜdŜone składowane są w elemencie * procedury obsługi, a element ten moŜe wystąpić wielokrotnie, * obsługujemy dane składowane z takiego elementu za kaŜdym razem, * gdy osiągniemy koniec tego elementu. * 
 * */ public void endElement(String namespaceURI, String localName, String rawName) throws SAXException { // Dodanie procedury obsługi po zakończeniu. if (localName.equals(HANDLER_ELEMENT)) { String handlerName = (String)storage.get(HANDLER_ID_ELEMENT); String handlerClass = (String)storage.get(HANDLER_CLASS_ELEMENT); // Dodanie do miejsca składowania klasy zewnętrznej. handlers.put(handlerName, handlerClass); storage.remove(HANDLER_ID_ELEMENT); storage.remove(HANDLER_CLASS_ELEMENT); } } /** *  * Zachowujemy zgromadzone informacje na końcu dokumentu; * wtedy mamy gwarancję, Ŝe wszystkie elementy zostały przetworzone.



Rzeczywistość



296



* 
 */ public void endDocument() throws SAXException { hostname = (String)storage.get(HOSTNAME_ELEMENT); driverClass = (String)storage.get(DRIVER_CLASS_ELEMENT); try { portNumber = Integer.parseInt( (String)storage.get(PORTNUMBER_ELEMENT)); } catch (NumberFormatException e) { // Komunikujemy o błędzie } } }



Kolejne etapy opisano za pomocą dokumentacji Javadoc. Po uruchomieniu metody startElement() nazwa zgłaszanego elementu zostaje zachowana. Stanowi ona potem klucz do struktury Hashtable zawierającej pary element-dane, wypełnianej kolejnymi wywołaniami characters(). Po przetworzeniu kaŜdego elementu handler identyfikator i nazwa klasy muszą zostać zachowane, poniewaŜ kolejne pobrania elementu handler spowodowałyby ich nadpisanie. Wreszcie, po wywołaniu endDocument() zachowane zostają takŜe: nazwa hosta, numer portu i klasa parsera. Ten kod oczywiście działa i nawet nie jest bardzo skomplikowany (w czym duŜą rolę odgrywa dokumentacja). A jednak jest on mniej czytelny niŜ ten wykorzystujący JDOM. Co więcej, kiedy liczba elementów w dokumencie XML wzrośnie do pięćdziesięciu, stu czy więcej, kod SAX zupełnie straci czytelność — konieczne jest wtedy dopisywanie kolejnych stałych tekstowych oraz operacji logicznych. Ten sam kod uŜywający JDOM-a nie będzie „rósł” nawet w połowie tak szybko, poniewaŜ w tego typu rozwiązaniu dostęp do całego dokumentu XML uzyskujemy właśnie poprzez interfejs JDOM.



DOM Wykorzystanie interfejsu DOM do obróbki danych XML to, w pewnym sensie, rozwiązanie skrajnie odmienne od zastosowania SAX-a. DOM pozwala uzyskać pełny obraz dokumentu XML, ale wymaga to zawsze wczytania całego dokumentu do pamięci, zanim jeszcze w ogóle uzyskamy do niego dostęp programowo. W przypadku niewielkich plików nie stanowi to problemu, ale moŜe dać się we znaki przy większych dokumentach. Co więcej, DOM nie oferuje standardowego interfejsu do uzyskiwania obiektu DOM Document. W wyniku tego konieczne jest jawne importowanie klas określonego producenta lub — jeśli chcemy tego uniknąć — stosowanie zaawansowanych refleksji. Interfejs DOM charakteryzuje się równieŜ bardzo formalną reprezentacją struktury drzewiastej; zawartość tekstowa dokumentu dostępna jest tylko jako potomny węzeł Node (a nie bezpośrednio z elementu), z czym wiąŜe się określony sposób jej uzyskiwania. Metoda parseConfiguration() wykorzystująca DOM została zaprezentowana poniŜej: private void parseConfiguration() { org.apache.xerces.parsers.DOMParser parser = new.org.apache.xerces.parsers.DOMParser(); handlers = new Hashtable(); parser.setFeature("http://xml.org/sax/features/namespaces", true); try { parser.parse(uri); doc = parser.getDocument();



Rzeczywistość



297



Element root = doc.getDocumentElement(); // Pobierz nazwę hosta. NodeList nodes = doc.getElementByTagNameNS(NAMESPACE_URI, "hostname"); if (nodes.getLength() > 0) { hostname = nodes.item(0).getFirstChild() .getNodeValue(); } else { hostname = ""; } // Pobierz numer portu. nodes = root.getElementByTagNameNS(NAMESPACE_URI, "port") if (nodes.getLength() > 0) { portNumber = Integer.parseInt( nodes.item(0).getFirstChild() .getNodeValue(); } else { portNumber = 0; } // Pobierz procedury obsługi. nodes = root.getElementByTagNameNS(NAMESPACE_URI, "handler"); for (int i=0; i


PowyŜszy przykład jest na pewno krótszy niŜ ten wykorzystujący SAX, ale i tak kodu jest całkiem sporo. Trzeba bezpośrednio korzystać z parsera Apache Xerces (lub innego budującego drzewo DOM); są teŜ inne mało intuicyjne struktury. Oto sposób uzyskania wartości tekstowej węzła: hostname = nodes.item(0).getFirstChild() .getNodeValue();



Co dalej?



298



PoniewaŜ element hostname ma posiadać węzły potomne, zawierające wartości tekstowe tego elementu, konieczne jest uzyskanie wartości pierwszego elementu potomnego, a nie wartości węzła Node reprezentującego sam element hostname. Oto główna przyczyna błędów przy uŜywaniu DOM-a: element DOM nie posiada wartości tekstowej; moŜe posiadać elementy potomne w postaci węzłów Text Node, a dopiero te zawierają właściwe wartości. Wreszcie, struktura zwracana z wywołań w rodzaju getElementByTagName() czy getChildNodes() to lista DOM NodeList, a nie Java Vector czy List. Obiekt ten posiada własne metody dostępu (getLength() i item()), róŜniące się od odpowiednich klas Javy. Przez to DOM nie jest tak bliski Javie jak JDOM — w tym ostatnim zwracane typy mają postać standardowych obiektów Javy. Oczywiście, zarówno SAX, jak i DOM umoŜliwiają wykonanie tych samych zadań co JDOM; pytanie brzmi jednak, czy jakakolwiek oferowana przez nie cecha czyni je na tyle atrakcyjnymi, Ŝe warto przymknąć oko na małą czytelność kodu. Ponadto, dzięki klasie JDOM SAXBuilder, JDOM moŜe wykonywać operacje na poziomie porównywalnym z SAX-em, bez konieczności rezygnacji z korzyści płynących z posiadania w pamięci struktury drzewiastej dokumentu (poprzez obiekt JDOM Document); ponadto jest to rozwiązanie „lŜejsze” niŜ zastosowanie DOM-a. Najnowsze wersje i implementacje JDOM moŜna znaleźć pod adresem http://www.jdom.org. JDOM umoŜliwia takŜe separację od parserów i implementacji, emulowaną w interfejsie SAX poprzez XMLReaderFactory i zupełnie ignorowaną przez DOM. JAXP firmy Sun ma zaląŜki rozwiązania tego problemu, ale wciąŜ nieodpowiednio obsługuje nowsze wersje SAX-a i DOM-a. Tak czy inaczej, to programista zdecyduje, który interfejs najlepiej sprawdzi w określonym projekcie, a przy tym będzie najprostszy w uŜyciu dla nowych programistów, którzy do tego projektu mogą dołączyć w przyszłości.



Co dalej? Czytelnik potrafi juŜ odczytywać, przetwarzać, przekształcać i wykorzystywać XML na róŜne sposoby. Język XML został uŜyty do tworzenia zawartości i prezentacji, do wywoływania procedur poprzez sieć oraz do konfiguracji aplikacji. Trzeba uzupełnić te informacje o jeszcze jedno zagadnienie — tworzenie samych danych XML. W następnym rozdziale zostanie przedstawiona kolejna moŜliwość XML-a — zdolność mutacji. Tym samym warsztat programisty zostanie uzupełniony o umiejętność dynamicznego generowania dokumentów XML przy róŜnych rodzajach danych wejściowych.



Ładowanie danych



299



12 Tworzenie danych XML w języku Java W tym rozdziale zostanie omówione jeszcze jedno zagadnienie związane z operowaniem na danych XML — tworzenie i modyfikowanie danych. Do tej pory w naszych aplikacjach korzystaliśmy z istniejących dokumentów XML i stałych danych. Nie wprowadzaliśmy zmian do pierwotnego dokumentu. I to często wystarczy; jednak w coraz większej liczbie nowoczesnych rozwiązań dokumenty XML tworzy się dynamicznie, w pamięci (tak działa np. interfejs XSP, omówiony w rozdziale 9.). Inne aplikacje tego typu to edytory XML i środowiska programistyczne, a takŜe menedŜery konfiguracji, które zostaną przedstawione w niniejszym rozdziale. W poprzednim rozdziale został utworzony plik konfiguracyjny XML zawierający informacje dotyczące konfiguracji klas XML-RPC. ZałoŜyliśmy, Ŝe zmiany konfiguracji będą wprowadzane „ręcznie” przez administratora. Potem plik taki będzie sprawdzany pod kątem poprawności (o ile administrator nie będzie leniwy), po czym nastąpi ponowne uruchomienie serwera i klientów XML-RPC. Takie rozwiązanie jest obarczone duŜym ryzykiem wystąpienia błędów. Po pierwsze, zakładamy, Ŝe przy wprowadzaniu danych nie popełniono Ŝadnego błędu. Po drugie, Ŝe administrator jest na tyle zdyscyplinowany, Ŝe dokona sprawdzenia poprawności zmienionego dokumentu XML. Nawet jeśli wszystko do tej pory się sprawdzi przy kaŜdej zmianie konfiguracji (co jest mało prawdopodobne w rzeczywistych zastosowaniach), konfiguracja staje się skomplikowana, jeśli klient i serwer znajdują się na róŜnych komputerach. Jeśli serwer XML-RPC ma równieŜ postać rozproszoną, to plik konfiguracyjny moŜe znajdować się w innym miejscu; być moŜe nawet w czterech czy pięciu oddzielnych kopiach. Zmiany muszą być wprowadzane równolegle we wszystkich kopiach. Dobrym rozwiązaniem byłby tu serwlet lub aplikacja Javy modyfikująca plik konfiguracyjny i automatycznie aktualizująca go w róŜnych miejscach. I tutaj właśnie wymaga się od Javy „umiejętności” modyfikacji danych XML. W tym rozdziale Czytelnik dowie się, jak zmodyfikować i zachować zmieniony dokument XML. Wynikowe dane powinny zostać zapisane na dysku twardym jako inny plik XML, jako strumień danych przekazywany do innego składnika aplikacji lub jako dane XML przekształcane do postaci HTML. Wszystko to jest moŜliwe do uzyskania z poziomu interfejsu Javy do obsługi danych XML.



Ładowanie danych



300



Ładowanie danych Podobnie jak w poprzednich rozdziałach, aby Czytelnik mógł dobrze poznać opisywaną technologię i interfejsy, powinien wypróbować je na przykładzie. W związku z tym po raz kolejny rozbudujemy nasz pakiet klas i narzędzi XML-RPC. W poprzednim rozdziale dokonaliśmy migracji danych konfiguracyjnych naszej aplikacji do postaci danych XML. Mamy juŜ klasę, która potrafi odczytać konfigurację w tej postaci i wykorzystać uzyskane informacje do uruchomienia klientów i serwera XML-RPC poprzez interfejsy JDOM; Czytelnik poznał takŜe sposoby uzyskania tego samego rezultatu za pomocą SAX-a i DOM-a. Teraz napiszemy proste narzędzie do aktualizacji i modyfikacji konfiguracji oraz zapisywania tych zmian w pliku konfiguracyjnym. W tej części omówimy dwa składniki tego procesu: klasę narzędziową com.oreilly.xml. XmlRpcConfiguration, która obecnie zajmuje się ładowaniem danych, oraz serwlet Javy z interfejsem do edycji danych. Najpierw w naszej klasie narzędziowej stworzymy mutatory, które uzupełnią akcesory stworzone w rozdziale 11. Dzięki nim stworzony potem serlwet, a takŜe inne aplikacje, będą potrafiły modyfikować dane w klasie narzędziowej. Po stworzeniu tych podstaw do modyfikacji danych konfiguracyjnych, trzeba będzie utworzyć serwlet wyświetlający te informacje oraz umoŜliwiający ich modyfikację poprzez formularz HTML.



Punkt wyjścia do modyfikacji danych PoniewaŜ w naszej klasie narzędziowej XmlRpcConfiguration zaszyty jest proces odczytywania i zapisywania dokumentu XML w systemie plików, dodamy teraz do niej mutatory, a następnie procedury faktycznie zapisujące zmiany do pliku. W ten sposób powstanie warstwa abstrakcyjna pozwalająca na budowanie aplikacji w sposób równoległy — kiedy juŜ wstawimy odpowiednie metody, jeden programista lub teŜ grupa moŜe pracować nad interfejsem w postaci serwletu z wykorzystaniem akcesorów i mutatorów, zaś inna grupa moŜe opracować metodę wewnątrz klasy, zachowującą nową konfigurację. W przykładzie 12.1 przedstawiono klasę XmlRpcConfiguration, w której zaimplementowano mutatory; jest tu takŜe szkielet metody saveConfiguration, która ostatecznie będzie słuŜyła do zapisu danych konfiguracyjnych po podaniu nazwy pliku lub strumienia OutputStream.



Przykład 12.1. Klasa narzędziowa zawierająca mutatory package com.oreilly.xml; import import import import import import import import



java.io.FileInputStream; java.io.FileNotFoundException; java.io.FileOutputStream; java.io.InputStream; java.io.IOException; java.util.Hashtable; java.util.Iterator; java.util.List;



import import import import import import



org.jdom.Document; org.jdom.Element; org.jdom.JDOMException; org.jdom.Namespace; org.jdom.input.Builder; org.jdom.input.DOMBuilder;



/** * XmlRpcConfiguration to klasa narzędziowa



Ładowanie danych * ładująca dane konfiguracyjne dla serwerów i klientów XML-RPC. * * @author Brett McLaughlin * @version 1.0 */ public class XmlRpcConfiguration { /** Z tego strumienia odczytujemy dane konfiguracyjne XML */ private InputStream in; /** Port, na którym działa serwer */ private int portNumber; /** Nazwa hosta, na którym uruchomiono serwer */ private String hostname; /** Klasa sterownika SAX do załadowania */ private String driverClass; /** Procedury obsługi do zarejestrowania w serwerze XML-RPC */ private Hashtable handlers; /** Dowiązanie JDOM Document do pliku XML */ private Document doc; /** *  * Tutaj określamy plik, z którego odczytamy * informacje o konfiguracji. * 
 * * @param filename String nazwa pliku * zawierającego konfigurację XML. */ public XmlRpcConfiguration(String filename) throws IOException { this(new FileInputStream(filename)); } /** *  * Tutaj określamy plik, z którego odczytamy * informacje o konfiguracji. * 
 * * @param in InputStream z którego * odczytamy informacje o konfiguracji. */ public XmlRpcConfiguration(InputStream in) throws IOException { this.in = in; portNumber = 0; hostname = ""; handlers = new Hashtable(); // Przetwarzamy dane XML o konfiguracji parseConfiguration(); } /** *  * Zwraca numer portu, na którym nasłuchuje serwer.



301



Ładowanie danych * 
 * * @return int - port serwera. */ public int getPortNumber() { return portNumber; } /** *  * Ustawia numer portu, na którym nasłuchujemy. * 
 * * @param portNumber int - port do nasłuchiwania. */ public void setPortNumber(int portNumber) { this.portNumber = portNumber; } /** *  * Zwraca nazwę hosta, w którym uruchomiono serwer. * 
 * * @return String - nazwa hosta serwera. */ public String getHostname() { return hostname; } /** *  * Ustawia nazwę hosta, w którym działa serwer. * 
 * * @param hostname String nazwa hosta serwera. */ public void setHostname(String hostname) { this.hostname = hostname; } /** *  * Zwraca klasę sterownika SAX do załadowania. * 
 * * @return String - nazwa klasy sterownika SAX. */ public String getDriverClass() { return driverClass; } /** *  * Ustawia klasę sterownika do przetwarzania. * 
 * * @param driverClass String nazwa klasy parsera. */ public void setDriverClass(String driverClass) { this.driverClass = driverClass; }



302



Ładowanie danych /** *  * Zwraca procedury obsługi do zarejestrowania przez serwer. * 
 * * @return Hashtable - struktura procedur obsługi. */ public Hashtable getHandlers() { return handlers; } /** *  * Ustawia procedury obsługi do zarejestrowania. * 
 * * @param handlers Hashtable procedur do zarejestrowania. */ public void setHandlers(Hashtable handlers) { this.handlers = handlers; } /** *  * Przetwarzamy informacje o konfiguracji XML i * udostępniamy je klientom. * 
 * * @throws IOException w razie wystąpienia błędu. */ private void parseConfiguration() throws IOException { try { // śądamy implementacji DOM i parsera Xerces. Builder builder = new DOMBuilder("org.jdom.adapters.XercesDOMAdapter"); // Pobieramy dokument konfiguracyjny, wykonując sprawdzanie poprawności. doc = builder.build(in); // Pobieramy element główny. Element root = doc.getRootElement(); // Uzyskujemy przestrzeń nazw JavaXML. Namespace ns = Namespace.getNamespace("JavaXML", "http://www.oreilly.com/catalog/javaxml/"); // Ładujemy nazwę hosta, port i klasę procedury obsługi. hostname = root.getChild("hostname", ns).getContent(); driverClass = root.getChild("parserClass", ns).getContent(); portNumber = Integer.parseInt(root.getChild("port", ns).getContent()); // Pobieramy procedury obsługi. List handlerElements = root.getChild("xmlrpc-server", ns) .getChild("handlers", ns) .getChildren("handler", ns); Iterator i = handlerElements.iterator(); while (i.hasNext()) { Element current = (Element)i.next();



303



Ładowanie danych



304 handlers.put(current.getChild("identifier", ns).getContent(), current.getChild("class", ns).getContent());



} } catch (JDOMException e) { throw new IOException(e.getMessage()); } } /** *  * Tutaj zachowujemy bieŜący stan do pliku konfiguracyjnego XML-RPC. * 
 * * @throws IOException - w razie błędów przy zapisywaniu. */ public synchronized void saveConfiguration(String filename) throws IOException { saveConfigurationFromScratch(new FileOutputStream(filename)); } /** *  * Tutaj zachowujemy stan bieŜący do określonego strumienia * OutputStream. * 
 * * @throws IOException - w razie błędów przy zapisywaniu. */ public synchronized void saveConfiguration(OutputStream out) throws IOException { // Do zaimplementowania } }



Oprócz nowych metod została utworzona zmienna przynaleŜna obiektu Document, doc, którą wykorzystujemy zarówno do odczytywania, jak i do zapisywania dokumentu konfiguracyjnego. Sensowniej jest przechowywać odwołanie do obiektu JDOM Document, niŜ ładować je od nowa w metodzie saveConfiguration(). Metoda parseConfiguration() ładuje teraz dane do zmiennej doc, którą następnie moŜna wykorzystać ponownie w metodzie saveConfiguration().



Wyświetlanie informacji o konfiguracji Skoro klasa XmlRpcConfiguration jest juŜ gotowa, naleŜy teraz utworzyć interfejs do przeglądania i wprowadzania zmian w konfiguracji. Odpowiednim rozwiązaniem jest tutaj interfejs w postaci serwletu Javy — uzyskujemy dostęp do prostego modelu Ŝądań i odpowiedzi i nie musimy specjalnie zagłębiać się w programowanie sieciowe. Interfejs taki umoŜliwia równieŜ administrowanie zdalne, poprzez dowolną przeglądarkę internetową. Najpierw stworzymy tę część serwleta, która odpowie na proste Ŝądanie z przeglądarki (wysłane z wykorzystaniem metody GET) i wyświetli bieŜącą konfigurację. Wszystko to wymaga stworzenia egzemplarza klasy XmlRpcConfiguration i wyświetlenia formularza HTML z informacjami pobranymi z tej klasy. PoniewaŜ są to podstawy Javy i serwletów, kod przedstawiony jest w przykładzie 12.2 bez



Ładowanie danych



305



dalszych wyjaśnień. Jeśli Czytelnik chciałby lepiej zapoznać się z interfejsem serwletów w Javie, warto zajrzeć do ksiąŜki Jasona Huntera Java Servlet Programming, wyd. O'Reilly & Associates.



Przykład 12.2. Serwlet w Javie wyświetlający informacje o konfiguracji XML-RPC import import import import import import import import



java.io.IOException; java.io.PrintWriter; java.util.Enumeration; java.util.Hashtable; javax.servlet.ServletException; javax.servlet.http.HttpServlet; javax.servlet.http.HttpServletRequest; javax.servlet.http.HttpServletResponse;



import com.oreilly.xml.XmlRpcConfiguration; /** * XmlRpcConfigurationServlet to narzędzie administracyjne * umoŜliwiające zachowywanie zmian w pliku konfiguracyjnym XML. * * @author Brett McLaughlin * @version 1.0 */ public class XmlRpcConfigurationServlet extends HttpServlet { /** Składujemy plik konfiguracyjny XML-RPC jako stałą */ private static final String CONFIG_FILENAME = "/usr/local/projects/javaxml/xmlrpc/xmlrpc.xml"; /** * Przekazujemy działanie serwletowi (i metodzie * {@link #doPost()}). * W Servlet API 2.1 lub 2.2 moŜna to zrobić programowo, * ale chcemy, aby ten przykład działał takŜe z interfejsem Servlet 2.0. */ private static final String FORM_ACTION = "/javaxml/servlet/XmlRpcConfigurationServlet"; /** Obiekt konfiguracyjny, na którym pracujemy */ XmlRpcConfiguration config; /** *  * śądania GET są otrzymywane, gdy klient chce przejrzeć bieŜącą konfigurację. * UmoŜliwiamy tylko podgląd danych. Wygenerowany formularz HTML * jest ponownie przekazywany serwletowi metodą POST, co powoduje wywołanie * metody {@link #doPost}. * 
 */ public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html"); PrintWriter out = res.getWriter(); // Ładujemy informacje o konfiguracji za pomocą naszej klasy narzędziowej. config = new XmlRpcConfiguration(CONFIG_FILENAME);



Ładowanie danych // Wyświetlamy interfejs HTML. out.println(""); out.println("Konfiguracja XML-RPC"); out.println(""); out.println("Konfiguracja XML-RPC
"); out.println(""); out.println("Nazwa hosta: "); out.println(""); //out.println("
"); out.println("    "); out.println("Numer portu: "); out.println(""); out.println("
"); out.println("Klasa sterownika SAX: "); out.println(""); out.println("
"); out.println("
"); out.println("Procedury obsługi XML-RPC
"); // Wyświetlamy bieŜące procedury obsługi. Hashtable handlers = config.getHandlers(); Enumeration keys = handlers.keys(); int index = 0; while (keys.hasMoreElements()) { String handlerID = (String)keys.nextElement(); String handlerClass = (String)handlers.get(handlerID); out.println("Identyfikator: "); out.println(" "); out.println("Klasa: "); out.println(" "); out.println("
"); index++; } // Wyświetlamy puste pola na dodatkowe procedury obsługi for (int i=0; i<3; i++) { out.println("Identyfikator: "); out.println(" "); out.println("Klasa: "); out.println(" "); out.println("
"); index++;



306



Ładowanie danych } out.println("
"); out.println(""); out.println(""); out.println("
"); out.close(); } /** *  * Ta metoda otrzymuje Ŝądania zmiany konfiguracji poprzez metodę * {@link #doGet}. Do aktualizacji pliku konfiguracyjnego * zostanie ponownie wykorzystana klasa narzędziowa. Zapisem do pliku * zajmie się obiekt {@link XmlRpcConfiguration}. * 
 */ public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { // Aktualizacja informacji konfiguracyjnych. if (config == null) { config = new XmlRpcConfiguration(CONFIG_FILENAME); } // Zachowujemy nazwę hosta. String hostname = req.getParameterValues("hostname")[0]; if ((hostname != null) && (!hostname.equals(""))) { config.setHostname(hostname); } // Zachowujemy numer portu. int portNumber; try { portNumber = Integer.parseInt( req.getParameterValues("port")[0]); } catch (Exception e) { portNumber = 0; } if (portNumber > 0) { config.setPortNumber(portNumber); } // Zachowujemy klasę sterownika SAX. String driverClass = req.getParameterValues("driverClass")[0]; if ((driverClass != null) && (!driverClass.equals(""))) { config.setDriverClass(driverClass); } // Zachowujemy procedury obsługi. String[] handlerIDs = req.getParameterValues("handlerID"); String[] handlerClasses = req.getParameterValues("handlerClass"); Hashtable handlers = new Hashtable(); for (int i=0; i


307



Modyfikacja danych



308



} config.setHandlers(handlers); try { // śądamy zapisu zmian do pliku. config.saveConfiguration(CONFIG_FILENAME); } catch (IOException e) { res.setContentType("text/html"); PrintWriter out = res.getWriter(); out.println(e.getMessage()); return; } // Wyświetlamy komunikat potwierdzający. res.setContentType("text/html"); PrintWriter out = res.getWriter(); out.println("Zmiany zapisane 
"); out.println("Powrót do interfejsu administracyjnego" + ""); out.close(); } }



Zostały tutaj wykorzystane informacje mówiące o tym, Ŝe wstępne Ŝądania będą nadchodziły do serwleta poprzez metodę GET; natomiast przekazywanie naszego formularza będzie odbywało się poprzez POST. Tak więc po otrzymaniu Ŝądania GET (metoda doGet()) wyświetlamy informacje o konfiguracji, zaś po otrzymaniu Ŝądania POST (metoda doPost()) aktualizujemy zmiany. Jeśli Ŝądanie zostało wysłane metodą GET, w przeglądarce WWW zostanie wyświetlona bieŜąca konfiguracja (rysunek 12.1). Po kliknięciu przycisku wysyłany jest formularz HTML, który otrzymuje ten sam serwlet (tym razem metodą POST). Metoda doPost() odczytuje otrzymane parametry i za pomocą mutatorów klasy XmlRpcConfiguration aktualizuje konfigurację. Potem wywoływana jest metoda saveConfiguration() z parametrem w postaci tego samego pliku konfiguracyjnego. W następnej części Czytelnik dowie się, jak przetworzyć zaktualizowane dane do postaci obiektu JDOM Document, a następnie zapisać do pliku konfiguracyjnego XML. Na koniec nasz serwlet wyświetla odsyłacz HTML, który (poprzez metodę GET) przenosi uŜytkownika z powrotem do formularza konfiguracyjnego. Zaktualizowane dane są wyświetlane i cały proces moŜna rozpocząć od nowa.



Modyfikacja danych Teraz trzeba jeszcze tylko stworzyć kod wewnątrz metody saveConfiguration(), który „zajmie się” aktualizacją dokumentu XML po zmodyfikowaniu wartości zmiennych. Cały ten proces moŜna powierzyć całkowicie interfejsowi JDOM za pomocą obiektu Document (który załadowaliśmy i do którego zachowaliśmy odwołanie przy przetwarzaniu dokumentu XML) oraz dostarczony OutputStream (który, w naszym przypadku, stanowi tak naprawdę FileOutputStream odnoszący się do pliku). Po wykonaniu zmian w konfiguracji obiekt Document



Modyfikacja danych



309



Rysunek 12.1. Interfejs HTML do przeglądania, modyfikowania i konfiguracji musi zostać zaktualizowany, a zmiany zapisane do pliku. W innych aplikacjach zmodyfikowany Document mógłby zostać przekształcony za pomocą XSLT i wysłany jako HTML lub inny język znaczników, ewentualnie przekazany poprzez sieć do innej aplikacji.



Aktualizacja konfiguracji Aby aplikacja była całkowicie funkcjonalna, trzeba jeszcze tylko dodać kod do metody saveConfiguration(), który pobierze jako argument OutputStream. Obiekt Document jest juŜ zachowany, pozostało więc ustawić zawartość poszczególnych elementów zmodyfikowanych metodą setContent(), dostępną w egzemplarzach Element. Najpierw zajmujemy się elementami hostname, port i parserClass, zagnieŜdŜonymi bezpośrednio w elemencie głównym: import import import import import import import import



java.io.FileInputStream; java.io.FileNotFoundException; java.io.FileOutputStream; java.io.InputStream; java.io.IOException; java.util.Hashtable; java.util.Iterator; java.util.List;



import import import import



org.jdom.Document; org.jdom.Element; org.jdom.JDOMException; org.jdom.Namespace;



Modyfikacja danych



310



import org.jdom.input.Builder; import org.jdom.input.DOMBuilder; import org.jdom.output.XMLOutputter; ... /** *  * Tutaj zachowujemy stan bieŜący do określonego strumienia * OutputStream. * 
 * * @throws IOException - w razie błędów przy zapisywaniu. */ public synchronized void saveConfiguration(OutputStream out) throws IOException { try { Element root = doc.getRootElement(); // Pobieramy przestrzeń nazw JavaXML. Namespace ns = Namespace.getNamespace("JavaXML", "http://www.oreilly.com/catalog/javaxml/"); // Aktualizujemy nazwę hosta. root.getChild("hostname", ns) .setContent(hostname); // Aktualizujemy klasę sterownika SAX. root.getChild("parserClass", ns) .setContent(driverClass); // Aktualizujemy numer portu. root.getChild("port", ns) .setContent(portNumber + ""); // Prostszy sposób usuwania i ponownego dodawania procedur. Element handlersElement = root.getChild("xmlrpc-server", ns) .getChild("handlers", ns); handlersElement.removeChildren("handler", ns); // Przekazujemy dokument na wyjście, standardowy moduł formatujący XMLOutputter fmt = new XMLOutputter(); fmt.output(doc, out); } catch (JDOMException e) { // Komunikujemy o błędzie. throw new IOException(e.getMessage()); } }



Podobnie jak we wcześniejszych przykładach, uŜyta została tutaj wersja getChild(), która pobiera zarówno Namespace, jak i lokalną nazwę elementu. Ponadto wykonuje proste łączenie łańcucha String z numerem portu, tak aby uzyskać poprawny parametr setContent(). Na koniec naleŜy zapisać zmiany do dostarczonego strumienia OutputStream za pomocą klasy pomocniczej XMLOutputter, co gwarantuje, Ŝe wprowadzone zmiany zostaną odzwierciedlone w pliku.



Modyfikacja danych



311



Dodanie informacji o procedurach obsługi to zadanie nieco innej natury. Zamiast wykonywać iterację po bieŜących elementach handler i zamieniać je na inne, a następnie dodawać lub usuwać procedury obsługi tak, aby ich lista zgadzała się z tą dostarczoną przez uŜytkownika, prościej będzie usunąć je wszystkie i na powrót utworzyć nową listę. Przede wszystkim importujemy klasę Enumeration — posłuŜy ona do obsługi tablicy Hashtable zawierającej procedury do dodania: import import import import import import import import import import



java.io.FileInputStream; java.io.FileNotFoundException; java.io.FileOutputStream; java.io.InputStream; java.io.IOException; java.io.OutputStream; java.util.Enumeration; java.util.Hashtable; java.util.Iterator; java.util.List;



import import import import import import



org.jdom.Document; org.jdom.Element; org.jdom.JDOMException; org.jdom.Namespace; org.jdom.input.Builder; org.jdom.input.DOMBuilder;



Teraz z elementu handlers moŜna usunąć wszystkie elementy handler. W tym przypadku bezpiecznie byłoby wywołać removeChildren() bez argumentów (usunięte zostałyby wszystkie elementy potomne), jednak bardziej przejrzystym rozwiązaniem będzie jawne usunięcie poszczególnych elementów; gdyby kiedyś do elementu handlers zostały dodane nowe elementy, kod będzie działał poprawnie bez konieczności wprowadzania zmian. Po usunięciu elementów potomnych „przebiegamy” po procedurach obsługi zdefiniowanych przez uŜytkownika i kaŜdą z nich dodajemy do obiektu JDOM Document: /** *  * Tutaj zachowujemy stan bieŜący do określonego strumienia * OutputStream. * 
 * * @throws IOException - w razie błędów przy zapisywaniu. */ public synchronized void saveConfiguration(OutputStream out) throws IOException { try { Element root = doc.getRootElement(); // Pobieramy przestrzeń nazw JavaXML. Namespace ns = Namespace.getNamespace("JavaXML", "http://www.oreilly.com/catalog/javaxml/"); // Aktualizujemy nazwę hosta. root.getChild("hostname", ns) .setContent(hostname); // Aktualizujemy klasę sterownika SAX. root.getChild("parserClass", ns) .setContent(driverClass); // Aktualizujemy numer portu. root.getChild("port", ns)



Modyfikacja danych



312 .setContent(portNumber + "");



// Prostszy sposób usuwania i ponownego dodawania procedur. Element handlersElement = root.getChild("xmlrpc-server", ns) .getChild("handlers", ns); handlersElement.removeChildren("handler", ns); // Dodanie nowych procedur obsługi. Enumeration handlerIDs = handlers.keys(); while (handlerIDs.hasMoreElements()) { String handlerID = (String)handlerIDs.nextElement(); // Sprawdzamy, czy przypadkiem nie rejestrujemy pustego łańcucha. if (handlerID.trim().equals("")) { continue; } String handlerClass = (String)handlers.get(handlerID); handlersElement.addChild( new Element("handler", ns) .addChild( new Element("identifier", ns) .setContent(handlerID)) .addChild( new Element("class", ns) .setContent(handlerClass)) ); } // Przekazujemy dokument na wyjście, standardowy moduł formatujący XMLOutputter fmt = new XMLOutputter(); fmt.output(doc, out); } catch (JDOMException e) { // Log an error throw new IOException(e.getMessage()); } }



Po wkompilowaniu powyŜszych zmian do klasy XmlRpcConfiguration, moŜna przetestować aplikację. Na rysunku 12.2 pokazano przykładowe dane wejściowe wprowadzone do serwleta XmlRpcConfigurationServlet. Po przekazaniu takiego formularza do programu zmiany zostają zachowane, a wynikowy plik xmlrpc.xml powinien wyglądać tak jak w przykładzie 12.3.



Przykład 12.3. Zmodyfikowany plik konfiguracyjny XML-RPC   www.jdom.org 1310 



Modyfikacja danych



313



Rysunek 12.2. Przykładowe dane wejściowe przekazane do serwleta XmlRpcConfigurationServlet oracle.xml.parser.v2.DOMParser     newUserGreeting NewUserGreetingService   mailingList MailingListHandler   cvsUpdate CVSUpdateHandler    



Teraz moŜna byłoby juŜ uruchomić klasę com.oreilly.xml.LightweightXmlRpcServer i — przy załoŜeniu, Ŝe mamy parser Oracle i klasy procedur obsługi w ścieŜce dostępu do klas (a takŜe dostęp do http://www.jdom.org, którego Czytelnik prawdopodobnie nie posiada!) — moŜemy uŜywać serwera i klientów XML-RPC skonfigurowanych według podanych informacji.



Budowanie dokumentu XML od podstaw



314



Budowanie dokumentu XML od podstaw Zawsze istnieje moŜliwość zbudowania dokumentu XML od zera. MoŜliwość ta jest przydatna w sytuacji, kiedy nie istnieje oryginalny dokument albo jeśli dokument oryginalny jest tak złoŜony, Ŝe prościej jest zbudować go od nowa, niŜ modyfikować. Budowanie nowego dokumentu XML przydaje się równieŜ wtedy, gdy dane wyjściowe aplikacji powinny mieć postać danych XML nadających się do wykorzystania przez inny składnik aplikacji (np. w aplikacjach typu firmafirma, przedstawionych w rozdziale 13.). Na szczęście tworzenie nowego dokumentu XML nie wymaga wprowadzania bardzo powaŜnych zmian w kodzie JDOM. Interfejs JDOM do tworzenia obiektu Document wykorzystuje interfejsy SAX i DOM (lub inne implementacje), a więc pozostajemy „oddzieleni” od samego procesu budowania dokumentu. Jeśli konieczne jest utworzenie nowego dokumentu XML, klasy Builder nie są wykorzystywane. Buduje się nowy Document, posiadający nowy element główny; następnie dodaje się inne elementy i dowolnie modyfikuje zawartość, po czym wysyła na wyjście za pomocą klasy Formatter. Prawda, Ŝe proste? W przykładzie 12.4 pokazano metodę saveConfiguration() zmodyfikowaną tak, Ŝe tworzy nowy Document do zachowania jako plik konfiguracyjny XML-RPC.



Przykład 12.4. Budowanie dokumentu XML od podstaw import import import import import import import import import import



java.io.FileInputStream; java.io.FileNotFoundException; java.io.FileOutputStream; java.io.InputStream; java.io.IOException; java.io.OutputStream; java.util.Enumeration; java.util.Hashtable; java.util.Iterator; java.util.List;



import import import import import import import



org.jdom.DocType; org.jdom.Document; org.jdom.Element; org.jdom.JDOMException; org.jdom.Namespace; org.jdom.input.Builder; org.jdom.input.DOMBuilder;



... /** *  * Tutaj zapisujemy stan bieŜący do określonego strumienia * OutputStream. * 
 * * @throws IOException - w razie błędów przy zapisywaniu. */ public synchronized void saveConfigurationFromScratch(OutputStream out) throws IOException { // Pobieramy przestrzeń nazw JavaXML. Namespace ns = Namespace.getNamespace("JavaXML", "http://www.oreilly.com/catalog/javaxml/"); // Tworzymy element główny. Element root = new Element("xmlrpc-config", ns); Document doc = new Document(root);



Budowanie dokumentu XML od podstaw



315



doc.setDocType(new DocType("JavaXML:xmlrpc-config", "DTD/XmlRpc.dtd")); root.addChild(new Element("hostname", ns) .setContent(hostname)) .addChild(new Element("port", ns) .addAttribute("type", "unprotected") .setContent(portNumber + "")) .addChild(new Element("parserClass", ns) .setContent(driverClass)); Element handlersElement = new Element("handlers", ns); Enumeration e = handlers.keys(); while (e.hasMoreElements()) { String handlerID = (String)e.nextElement(); String handlerClass = (String)handlers.get(handlerID); handlersElement.addChild(new Element("handler", ns) .addChild(new Element("identifier", ns) .setContent(handlerID)) .addChild(new Element("class", ns) .setContent(handlerClass)) ); } root.addChild(new Element("xmlrpc-server", ns) .addChild(handlersElement)); // Przekazujemy dokument na wyjście, standardowy moduł formatujący. XMLOutputter fmt = new XMLOutputter(); fmt.output(doc, out); }



Najpierw została dodana dodatkowa instrukcja importująca org.jdom.DocType. PoniewaŜ element tworzony jest od początku, trzeba wstawić odwołanie do odpowiedniej definicji DTD. Usunięty został takŜe cały blok kodu try/catch, który wcześniej znajdował się w tym miejscu. Wyjątek JDOMException, który wcześniej przechwytywaliśmy, zgłaszany był przez klasy Builder; XMLOutputter zgłasza w razie problemów tylko jeden wyjątek: IOException. Następnie naleŜy utworzyć element główny, JavaXML:xmlrpc-config, po czym uŜyć go do tworzenia nowego obiektu JDOM Document. Elementy tekstowe (nazwa hosta, port i klasa SAX) dodawane są jako dodatkowe obiekty Element do elementu głównego, a ich zawartość tekstowa jest odpowiednio ustawiana (dodany został takŜe atrybut do elementu JavaXML:port). Na koniec naleŜy „przejść” po wszystkich procedurach obsługi wpisanych przez uŜytkownika, podobnie jak to było robione w poprzedniej wersji metody. KaŜda procedura obsługi dodawana jest jako Element JavaXML:handler, a ten z kolei dodawany jest do elementu JavaXML:handlers. Cały ten zbiór jest znów dodawany do węzła JavaXML:xmlrpc-server, który z kolei dodawany jest do elementu głównego dokumentu. Na koniec Document przekazywany jest do podanego strumienia OutputStream i... to wszystko! W zaleŜności od uŜytego interfejsu API, proces tworzenia dokumentu XML — czy to w pamięci, czy w systemie plików — moŜe być tak prosty, jak modyfikacja gotowego dokumentu (jak w tym przykładzie). Ale nie zawsze tak jest. Niektóre interfejsy wymagają tworzenia specyficznych dla producenta elementów i atrybutów. W ostatniej części tego rozdziału zostaną porównane róŜne interfejsy Javy do tworzenia danych XML i poruszone inne waŜne zagadnienia związane z wykonywaniem mutacji XML-a z poziomu tego języka.



Praktyka



316



Praktyka Tradycyjnie juŜ, na zakończenie rozdziału zostaną omówione zagadnienia związane z uŜywaniem opisywanych narzędzi w warunkach rzeczywistych. W tym rozdziale zostały poruszone następujące kwestie: tworzenie danych XML, alternatywy względem JDOM-a przy budowaniu danych XML oraz obsługa nieaktualnych odwołań do klasy narzędziowej XmlRpcConfiguration.



Wątkowanie, pisanie i arytmetyka Choć metoda saveConfiguration() oraz sposób, w jaki pozwala ona zapisać plik XML, zostały omówione bardzo pospiesznie, Czytelnik być moŜe zauwaŜył pewien istotny zapis w deklaracji metody: /** *  * Tutaj zachowujemy stan bieŜący do określonego strumienia * OutputStream. * 
 * * @throws IOException - w razie błędów przy zapisywaniu. */ public synchronized void saveConfiguration(OutputStream out) throws IOException { // implementacja metody }



Słowo kluczowe synchronized gwarantuje, Ŝe zanim dane konfiguracyjne zostaną zapisane, obiekt XmlRpcConfiguration zostanie opatrzony blokadą. Jest to szczególnie istotne w przypadku korzystania z XML-a, poniewaŜ interfejsy takie jak JDOM mogą być tworzone na implementacjach okresowo przeładowujących dane, z których korzystają; innymi słowy, zmiany wykonane przez inne programy mogłyby spowodować powaŜne błędy lub zniszczenie danych XML, jeśli jednocześnie ta metoda zapisywałaby do nich swoje informacje. Co więcej, naleŜy bardzo uwaŜać, kiedy XML zapisuje wiele aplikacji do tego samego źródła danych. Na potrzeby pesymistycznego i optymistycznego blokowania, współuŜytkowania danych oraz rozwiązania wielu innych złoŜonych zagadnień napisano całe systemy bazodanowe. XML to świetny sposób na uzyskanie przenośności danych, niemniej tym powyŜszych problemów nie rozwiązuje. Jest na to wszystko bardzo praktyczny sposób — pisanie do pliku XML powinno odbywać się poprzez jeden wspólny „punkt wejściowy”. W przypadku mutowania danych istnienie wielu takich punktów moŜe spowodować występowanie dziwnych błędów i w ogóle duŜo zamieszania.



JDOM, SAX lub DOM — jeszcze raz W rozdziale 11. zostały omówione alternatywy względem JDOM-a przy odczytywaniu danych XML. Teraz znowu zostaną one przedstawione, ale w odniesieniu do zapisu i modyfikacji danych. Dzięki temu Czytelnik uzyska kompletny obraz interfejsów programistycznych Javy i nie będzie miał problemu z wyborem takiego interfejsu pod kątem konkretnego projektu. Dla porównania — poniŜej przedstawiona jest metoda saveConfiguration() z poprzedniego rozdziału, wykorzystująca JDOM:



Praktyka



317 /** *  * Tutaj zapisujemy stan bieŜący do określonego strumienia * OutputStream. * 
 * * @throws IOException - w razie błędów przy zapisywaniu. */ public synchronized void saveConfiguration(OutputStream out) throws IOException { // Pobieramy przestrzeń nazw JavaXML. Namespace ns = Namespace.getNamespace("JavaXML", "http://www.oreilly.com/catalog/javaxml/"); // Tworzymy element główny. Element root = new Element("xmlrpc-config", ns); Document doc = new Document(root); doc.setDocType(new DocType("JavaXML:xmlrpc-config", "DTD/XmlRpc.dtd")); root.addChild(new Element("hostname", ns) .setContent(hostname)) .addChild(new Element("port", ns) .addAttribute("type", "unprotected") .setContent(portNumber + "")) .addChild(new Element("parserClass", ns) .setContent(driverClass)); Element handlersElement = new Element("handlers", ns); Enumeration e = handlers.keys(); while (e.hasMoreElements()) { String handlerID = (String)e.nextElement(); String handlerClass = (String)handlers.get(handlerID); handlersElement.addChild(new Element("handler", ns) .addChild(new Element("identifier", ns) .setContent(handlerID)) .addChild(new Element("class", ns) .setContent(handlerClass)) ); } root.addChild(new Element("xmlrpc-server", ns) .addChild(handlersElement)); // Przekazujemy dokument na wyjście, standardowy moduł formatujący. XMLOutputter fmt = new XMLOutputter(); fmt.output(doc, out); }



PoniŜej przedstawione są sposoby wykonania tego samego zadania za pomocą interfejsów SAX i DOM.



SAX W przypadku SAX-a sprawa jest prosta — mówiąc krótko, za pomocą tego interfejsu nie da się zmodyfikować danych XML. SAX oferuje podejście do danych XML oparte na zdarzeniach, a więc nadaje się tylko do przetwarzania gotowego dokumentu. Zdefiniowane w tym interfejsie wywołania słuŜą tylko do tego celu. SAX nie jest „świadomy” całościowej postaci dokumentu XML, nie potrafi więc takŜe całej tej postaci zmienić. To właśnie z tego powodu DOM zyskał



Praktyka



318



duŜą popularność — do niedawna stanowił jedyny sposób tworzenia danych XML z programów w Javie bez konieczności bezpośredniego zapisywania XML-a za pomocą strumieni.



DOM Model DOM umoŜliwia tworzenie i modyfikowanie dokumentu XML-a z języka Java. JednakŜe charakteryzuje go o wiele bardziej ścisłe przestrzeganie struktury drzewiastej dokumentu. Po pierwsze, w interfejsie tym kaŜdy fragment drzewa postrzegany jest jako węzeł Node (warto przypomnieć sobie informacje z rozdziału 7.). PoniewaŜ wszystkie węzły stanowią część drzewa, przy tworzeniu węzła Node konieczne jest skojarzenie go z konkretnym drzewem DOM, reprezentowanym przez obiekt DOM Document. Aby zagwarantować, Ŝe model ten jest przestrzegany, nie stworzono Ŝadnego mechanizmu do uzyskiwania egzemplarza Node bezpośrednio; zamiast tego operacje createElement(), createAttriute() oraz inne operacje na węzłach zostały zdefiniowane w interfejsie Document. Trzeba równieŜ pamiętać, Ŝe w takim ścisłym modelu drzewa wszystko postrzegane jest jako Node, w tym dane tekstowe. Nie istnieje więc pojęcie zawartości elementu — Element DOM posiada węzły potomne, z których część jest węzłami Text Node. Tak więc ustawienie wartości elementu wymaga skorzystania z metody createTextNode(), a następnie dodania tak uzyskanego węzła Text Node do macierzystego elementu Element. Oczywiście, na obiekcie Document wywoływana jest jeszcze sama metoda createTextNode(), zapewniająca odpowiednie skojarzenie elementu z drzewem DOM. To moŜe wydawać się nieco zagmatwane — utworzenie elementu XML wymaga „zaprzęŜenia” obiektów DOM Element Node, DOM Text Node oraz DOM Document. To niezbyt atrakcyjne rozwiązanie, szczególnie z perspektywy nowicjuszy w języku XML (którzy zwykle próbują zmienić zawartość tekstową elementu metodą setNodeValue() i otrzymują wyniki niezgodne z oczekiwaniami). Trzeba nieustannie pamiętać, Ŝe w interfejsie DOM bardzo ściśle przestrzega się struktury drzewiastej.



Pamiętając o tym, spróbujmy zbudować dokument XML z danych dostarczonych przez uŜytkownika w aplikacji XmlRpcConfigurationServlet. MoŜna byłoby oczekiwać, Ŝe będziemy powtarzali proces odnajdywania kaŜdego elementu zawierającego dane i zmieniania zawartości jego węzłów tekstowych, podobnie jak w naszej pierwszej metodzie saveConfiguration(), wykorzystującej JDOM. To oczywiście moŜliwe (DOM udostępnia w odniesieniu do węzłów tekstowych metodę setValue()), ale nie jest to sposób ani najłatwiejszy, ani najszybszy. Zamiast tego uŜyjemy metod z rodziny createXXX(), zdefiniowanych w interfejsie DOM Document. Mamy metody dla kaŜdego typu węzła DOM Node, takie jak createElement(), createTextNode() i createAttriute(). W miarę jak tworzone są te wszystkie obiekty, zostają one przypisane obiektowi Document. W ten sposób zachowana jest odpowiednia relacja „starszeństwa” pomiędzy kaŜdym utworzonym węzłem a drzewem DOM, do którego on naleŜy. W ten sposób tworzymy wszystkie wymagane elementy i dane. Ale to dopiero połowa zadania; kaŜdy element oraz jego dane muszą potem zostać wstawione do drzewa DOM i skonsolidowane do postaci jednej, poprawnej hierarchii. Najprostszym sposobem wstawienia węzła Node do drzewa jest wykonanie metody appendChild() na węźle macierzystym. W ten sposób moŜna juŜ zbudować kompletny dokument, rozpoczynając od elementu głównego. Następnie zamienimy stary element główny na nowy i uzyskamy zaktualizowany model drzewiasty.



Praktyka



319



Trzeba koniecznie zrozumieć róŜnice pomiędzy metodami createXXX() i appendNode(). Pierwsza metoda zwraca Node powiązany z obiektem DOM Document, ale nie wstawia tego węzła do dokumentu; na określonym elemencie macierzystym trzeba jeszcze wykonać metodę appendNode(). Nieumiejętność rozróŜnienia tych dwóch metod moŜe spowodować stworzenie wielkiej liczby węzłów skojarzonych z pewnym obiektem DOM Document, przy czym samo drzewo DOM pozostanie puste.



Nie musimy wykonywać skomplikowanego przeszukiwania i pozyskiwania elementów i danych, a ponadto takie podejście jest często o wiele szybsze. Przeszukiwanie drzewa DOM, szczególnie jeśli jest ono pokaźnych rozmiarów, moŜe zająć sporo czasu procesora; zbudowanie drzewa XML począwszy od elementu głównego to sposób o wiele szybszy. Kod wykonujący takie zadanie przedstawiono poniŜej: /** *  * Tutaj zachowujemy stan bieŜący do określonego strumienia * OutputStream, za pomocą DOM-a. * 
 * * @throws IOException - w razie błędów przy zapisywaniu. */ public synchronized void saveConfiguration(OutputStream out) throws IOException { String NAMESPACE_URI = "http://www.oreilly.com/catalog/javaxml/"; // Zakładamy, Ŝe obiekt DOM Document został załadowany w metodzie // parseConfiguration() i zachowany w zmiennej o nazwie // doc. Element oldRoot = doc.getDocumentElement(); Element newRoot = doc.createElementNS(NAMESPACE_URI, "JavaXML:xmlrpc-config"); // Obsługa nazwy hosta. Element hostnameNode = doc.createElementNS(NAMESPACE_URI, "JavaXML:hostname"); hostnameNode.appendChild( doc.createTextNode(hostname)); newRoot.appendChild(hostnameNode); // Obsługa numeru portu. Element portNumberNode = doc.createElementNS(NAMESPACE_URI, "JavaXML:port"); portNumberNode.appendChild( doc.createTextNode(portNumber + "")); portNumberNode.setValue("type", "unprotected"); newRoot.appendChild(portNumberNode); // Obsługa klas sterownika SAX. Element saxDriverNode = doc.createElementNS(NAMESPACE_URI, "JavaXML:parserClass"); saxDriverNode.appendChild( doc.createTextNode(driverClass)); newRoot.appendChild(saxDriverNode); Element serverNode = doc.createElementNS(NAMESPACE_URI, "JavaXML:xmlrpc-server");



Praktyka



320 Element handlersNode = doc.createElementNS(NAMESPACE_URI, "JavaXML:handlers"); // Obsługa procedur obsługi. Enumeration handlerIDs = handlers.keys(); while (handlerIDs.hasMoreElements()) { String handlerID = (string)handlerIDs.nextElement(); String handlerClass = (string)handles.get(handlerID); Element handlerIDNode = doc.createElementNS(NAMESPACE_URI, "JavaXML:identifier"); handlerIDNode.appendChild( doc.createTextNode(handlerID)); Element handlerClassNode = doc.createElementNS(NAMESPACE_URI, "JavaXML:class"); handlerClassNode.appendChild( doc.createTextNode(handlerClass)); Element handlerNode = doc.createElementNS(NAMESPACE_URI, "JavaXML:handler"); handlerNode.appendChild(handlerIDNode); handlerNode.appendChild(handlerClassNode); handlersNode.appendChild(handlerNode); } serverNode.appendChild(handlersNode); newRoot.appendChild(serverNode); doc.replaceChild(newRoot, oldRoot); // Serializacja drzewa DOM. }



Do stworzenia dokumentu XML „rozumiejącego” przestrzenie nazw wykorzystujemy metody DOM Level 2. Metoda createElementNS() pobiera przestrzeń nazw URI oraz pełną nazwę nowego elementu. Pełna nazwa zawiera przedrostek przestrzeni nazw, co gwarantuje, Ŝe zarówno przedrostek przestrzeni nazw, jak i identyfikator URI przestrzeni zostaną razem włączone (lub wyłączone) i powstanie poprawnie sformatowany dokument XML. Kolejne zadanie, które — podobnie jak uzyskiwanie obiektu DOM Document — nie zostało opisane w specyfikacji DOM, to serializacja drzewa DOM. Aby osiągnąć serializację, trzeba sprawdzić, czy określony producent oferuje klasę pomocniczą słuŜącą do przeprowadzenia takiej serializacji. Po jej wyszukaniu zazwyczaj wystarczy tylko ją zaimportować i przekazać jej egzemplarz OutputStream lub PrintWriter. W Apache Xerces odpowiednia klasa nosi nazwę org.apache.xml.serialize.XMLSerializer. Klasy tej uŜyjemy do zapisu do strumienia OutputStream, który został przekazany przez naszą metodę saveConfiguration(): /** *  * Tutaj zachowujemy stan bieŜący do określonego strumienia * OutputStream, za pomocą DOM-a. * 
 * * @throws IOException - w razie błędów przy zapisywaniu. */ public synchronized void saveConfiguration(OutputStream out) throws IOException {



Praktyka



321 // Modyfikacja obiektu Document. doc.replaceChild(newRoot, oldRoot); // Serializacja drzewa DOM. org.apache.xml.serialize.XMLSerializer out = new org.apache.xml.serialize.XMLSerializer(out, null); out.serialize(doc); }



Klasa Apache XMLSerializer posiada szereg róŜnych konstruktorów; konstruktor zastosowany tutaj pobiera OutputStream oraz format, jaki ma zostać uŜyty do uzyskania danych wynikowych. Format określamy jako null, co oznacza, Ŝe zdajemy się na format domyślny. Metoda serialize() pobiera jako parametry wejściowe obiekty Document, Element lub DocumentFragment. W przykładzie przekazujemy zmodyfikowane drzewo Document. I tak właśnie stworzyliśmy emulację tego, co uzyskaliśmy za pomocą JDOM-a — modyfikujemy i zwracamy dokument XML z danymi wynikającymi z informacji podanych przez uŜytkownika.



Gdzie się podziała klasa XmlRpcConfiguration? Kiedy rolę interfejsu uŜytkownika pełni serwlet lub inny mechanizm WWW, trzeba pamiętać o pewnych problemach, które klientów „statycznych” lub uproszczonych po prostu nie dotyczą. Jeden z nich to odśmiecanie i przestoje u uŜytkownika. Przestoje u uŜytkownika (ang. user lag) to sytuacja, w której uŜytkownik ładuje serwlet lub inny kod przez Internet, po czym robi sobie przerwę na kawę, idzie na trzy zebrania i odwiedza bar kanapkowy. Odwołania do obiektów w serwlecie, do których uzyskano dostęp, mogą w tym czasie zostać poddane procedurom odśmiecania. Kiedy jeden serwlet przekazuje Ŝądania do drugiego, to problemu nie ma; jednak w naszym przykładzie serwlet XmlRpcConfigurationServlet przekazywał dane do samego siebie. MoŜe pojawić się błąd polegający na tym, Ŝe zmienna config (egzemplarz com.oreilly.xml.XmlRpcConfiguration) zostanie tylko utworzona w metodzie doGet(), zaś ponowne jej uŜycie nastąpi w doPost(): public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html"); PrintWriter out = res.getWriter(); // Ładujemy informacje o konfiguracji za pomocą naszej klasy narzędziowej. config = new XmlRpcConfiguration(CONFIG_FILENAME); // Reszta metody. } public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { // Zachowujemy nazwę hosta. String hostname = req.getParameterValues("hostname")[0]; if ((hostname != null) && (!hostname.equals(""))) { config.setHostname(hostname);



Co dalej?



322 } // Reszta metody }



Jeśli pomiędzy pierwszym Ŝądaniem GET a następnymi Ŝądaniami POST upłynęło wystarczająco duŜo czasu, po próbie uzyskania dostępu do config z metody doPost() moŜe zostać zgłoszony NullPointerException. Taka sytuacja moŜe takŜe nastąpić, jeśli w trakcie Ŝądania kod serwleta zostanie zmieniony, a serwlet przeładowany (a pozwalają na to Jakarta Tomcat i inne popularne mechanizmy serwletów). Aby uniknąć tego problemu, sensownie byłoby zagwarantować, Ŝe zmienna config jest poprawna zarówno w metodzie doGet(), jak i doPost(). Jednak tworzenie egzemplarza klasy XmlRpcConfiguration wiąŜe się ze sporym nakładem pracy — konieczne jest ponowne przetworzenie podanego pliku. Zamiast za kaŜdym razem odtwarzać zmienną, moŜna wykorzystać fakt, Ŝe zmienne poddawane operacjom odśmiecania przyjmują wartości równe null1. Tak więc moŜna sprawdzić obecność wartości null i stworzyć nowy egzemplarz jedynie w razie potrzeby: public void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { // Aktualizujemy informacje o konfiguracji. if (config == null) { config = new XmlRpcConfiguration(CONFIG_FILENAME); } // Zachowujemy nazwę hosta. String hostname = req.getParameterValues("hostname")[0]; if ((hostname != null) && (!hostname.equals(""))) { config.setHostname(hostname); } // Reszta metody. }



PowyŜsze zmiany w kodzie gwarantują, Ŝe przestoje u uŜytkownika nie wpłyną na działanie programu.



Co dalej? NajwaŜniejsze zagadnienia związane z uŜywaniem XML-a z poziomu programów w Javie zostały juŜ omówione. Czytelnik potrafi tworzyć, przetwarzać, przekształcać zgodnie ze stylami oraz zawęŜać dokumenty XML i sprawdzać ich poprawność; poznał teŜ takie narzędzia jak struktury publikacji, XML z perspektywy zdalnego wywoływania procedur, przechowywanie konfiguracji w dokumentach XML oraz sposób tworzenia danych XML „w locie”. W rozdziale 13. zostaną omówione aplikacje typu firma-firma. Zostanie przedstawione wykorzystanie XML-a w hipotetycznych firmach i Czytelnik będzie mógł przyjrzeć się całemu procesowi komunikacji wewnętrznej firmy oraz pomiędzy przedsiębiorstwami. 1



To stwierdzenie nie jest zupełnie ścisłe, jednakŜe w przypadku zmiennej nielokalnej jest prawdziwe, szczególnie w przypadku serwletów. Więcej informacji o odśmiecaniu i wartościach zmiennych, których egzemplarzy nie utworzono lub które poddano odśmiecaniu moŜna znaleźć w ksiąŜce Java in a Nutshell Davida Flangana (O'Reilly & Associates).



Biblioteka Publiczna NaNiby



323



13 Firma-firma Czytelnik wie juŜ duŜo o XML-u. Poznał interfejsy SAX, DOM i JDOM, znajome mu są struktury publikacji i zaawansowane transformacje, jak równieŜ model XML-RPC; zna takŜe zagadnienia związane z zastosowaniem XML-a w procesach konfiguracji oraz z wykorzystaniem tego języka jako źródła danych; potrafi równieŜ tworzyć dane XML z programów w Javie. W niniejszym rozdziale zostanie omówiony bardzo modny temat, a mianowicie zastosowanie XML-a w aplikacjach typu firma-firma. Przedsiębiorstwa wkroczyły w erę internetową i właściwa komunikacja stała się najwaŜniejszym warunkiem prowadzenia handlu. Wiele firm przywiązuje większą wagę do procesów komunikacyjnych niŜ... do własnych produktów. Agresywne kampanie online i aplikacje e-biznesowe mogą przyczynić się do pokonania konkurencji, która moŜe nawet oferować atrakcyjniejsze produkty. Ogromną rolę w pojęciu „firma-firma” odgrywa XML. Język ten stanowi standardowy sposób reprezentacji danych i właśnie dzięki niemu firmy wykorzystujące róŜne aplikacje, systemy i języki programowania mają moŜliwość komunikowania się ze sobą. W niniejszym rozdziale Czytelnik dowie się, w jaki sposób za pomocą XML-a moŜna uzyskać taką właśnie moŜliwość porozumienia pomiędzy róŜnymi aplikacjami; na potrzeby rozdziału zostaną nawet stworzone wyimaginowane firmy. Tym razem XML nie posłuŜy do wymiany informacji pomiędzy składnikami jednej aplikacji ani teŜ jako źródło danych, ale do komunikacji pomiędzy róŜnymi aplikacjami. Najpierw zostanie zaprezentowana Biblioteka Publiczna NaNiby, której dostawcy będą mogli wprowadzać nowe tytuły w trybie online. KsiąŜki będą następnie dodawane do składnicy danych biblioteki do późniejszego wykorzystania. Niestety, w dzisiejszych czasach trudno o dobrych programistów Javy, a więc nasza biblioteka będzie opierała swoje działanie na programie CGI napisanym w Perlu. Nowe ksiąŜki wpisywane online są sortowane przez skrypt właśnie w tym języku. Będzie teŜ druga firma, KsiegarniaTechniczna.com. W tej księgarni sprzedaje się w systemie online — w porozumieniu z innymi duŜymi księgarniami — ksiąŜki o tematyce technicznej i komputerowej (takie jak ta). Ostatnio podpisano umowę z Biblioteką Publiczną NaNiby, zgodnie z którą firma będzie uzyskiwała ksiąŜki od tej biblioteki na specjalnych warunkach. KsiegarniaTechniczna.com opłaci koszty dostawy i administracyjne, zaś biblioteka zamówi dodatkowe egzemplarze ksiąŜek po specjalnej, obniŜonej cenie; te dodatkowe ksiąŜki sprzeda następnie KsiegarniaTechniczna.com. KsiegarniaTechniczna.com musi mieć dostęp do danych wprowadzanych w Bibliotece Publicznej NaNiby przez dostawców, tak aby wiedzieć o nowych tytułach i móc je reklamować u siebie. JednakŜe nie wiadomo, w jaki sposób uzyskać dostęp do danych systemu bi-



Biblioteka Publiczna NaNiby



324



blioteki opartego na Perlu. Co więcej, pomiędzy obiema firmami nie istnieją chronione połączenia sieciowe, a więc konieczne jest wykorzystanie zwyczajnego protokołu HTTP. Czytelnik będzie mógł spojrzeć na te aplikacje z punktu widzenia klientów KsiegarniaTechniczna.com. Księgarnia oferuje produkty osobom aktywnym w Internecie, a więc chce ogłaszać się w witrynach w rodzaju Netscape Netcenter; chce takŜe, aby klienci mogli w prosty sposób uzyskać informacje z ich witryny o nowych ofertach. JednakŜe, podobnie jak w przypadku Biblioteki Publicznej NaNiby, KsiegarniaTechniczna.com nie posiada informacji o tym, jak to zrobić. Przedstawiciele grupy Netscape Netcenter poinformowali programistów księgarni, Ŝe na potrzeby takiego reklamowania się najlepiej nadaje się RSS (Rich Site Summary). Ale programiści księgarni nawet nie wiedzą, czym jest RSS! Zaczniemy od Biblioteki Publicznej NaNiby — przyjrzymy się, jak zbudowany jest ich system napisany w Perlu. Następnie przejdziemy do firmy KsiegarniaTechniczna.com, a jeszcze później do klientów tej księgarni. Zobaczymy, jak pomiędzy tymi wszystkimi stronami stworzyć komunikację opartą na języku XML.



Biblioteka Publiczna NaNiby Tworzenie systemu typu firma-firma rozpoczniemy od zbadania, jaki stan rzeczy zastaliśmy w bibliotece. Zanim jednak przejdziemy do samego kodu aplikacji, musimy poznać wymagania biblioteki (aby nie tworzyć systemu, którego nie będzie moŜna potem obsłuŜyć).



Określenie wymagań Często dobre rozwiązanie nie oznacza jeszcze — w przypadku określonej firmy — rozwiązania zgodnego z wymaganiami. Świetnym przykładem jest tutaj Biblioteka Publiczna NaNiby — problemy tej biblioteki i firmy KsiegarniaTechniczna.com moŜna byłoby rozwiązać za pomocą serwletów Javy działających po obu stronach. JednakŜe nie zostałyby wówczas zaspokojone wymagania biblioteki. A więc najpierw naleŜy przyjrzeć się właśnie wymaganiom: • rozwiązanie musi być napisane w Perlu; w bibliotece nie ma programistów Javy; • rozwiązanie nie moŜe wymagać instalacji nowego oprogramowania czy bibliotek; • rozwiązanie nie moŜe wpłynąć na istniejący system zamawiania (nie moŜe być zmian w interfejsie). Nie są to moŜe jakieś zaporowe wymagania, ale na pewno zmuszają do ponownego przeanalizowania problemu. Nie wolno nam korzystać z Javy. Oczywiście, poniewaŜ ta ksiąŜka jest o XML-u, Czytelnik moŜe się domyślać, Ŝe dane o nowych ksiąŜkach będą zapisywane w formacie XML, następnie przekazywane klientom protokołem HTTP i wykorzystywane w dowolny sposób. Tak, i jest to o wiele lepsze rozwiązanie niŜ komunikacja pomiędzy serwletami; XML moŜe zostać uŜyty w dowolnej firmie lub u dowolnego klienta i nie trzeba „przywiązywać” biblioteki (i wszystkich jej ksiąŜek) do jednej, określonej firmy. I w ten sposób zostało nakreślone zadanie związane z aktualizacją systemu biblioteki — zachować wpisane informacje w postaci kodu XML, a następnie stworzyć klientom moŜliwość dostępu do tych danych poprzez protokół HTTP.



Biblioteka Publiczna NaNiby



325



Wprowadzanie ksiąŜek Po pierwsze trzeba poznać istniejący interfejs, za pomocą którego dostawcy wprowadzają nowe ksiąŜki do systemu. W przykładzie 13.1 pokazano, jak zbudowany jest sam statyczny formularz.



Przykład 13.1. Statyczny interfejs Biblioteki Publicznej NaNiby w HTML-u   Biblioteka Publiczna NaNiby: Wprowadzanie ksiąŜek        Opcje    Menu Główne  
   Katalog  
  Wprowadzanie ksiąŜek 
   Wylogowanie    Biblioteka Publiczna NaNiby
 - Dodawanie ksiąŜek -
   


Biblioteka Publiczna NaNiby


326

   Tytuł   
  
 



Autor    Temat   
  Wydawca    ISBN    
  Cena    Stron    
   Opis    
 
     
 
  
 
  



PowyŜszy plik, zachowany jako addBooks.html, umoŜliwia wprowadzenie nowych ksiąŜek przysyłanych do biblioteki. W tym rozdziale zostanie wydrukowany pełny kod wszystkich opisywanych przykładów, tak aby Czytelnik mógł sam stworzyć przykładową aplikację i dokładnie zaznajomić się z procesem uruchamiania komunikacji XML pomiędzy firmami. MoŜliwe jest teŜ obejrzenie działających przykładów pod adresem http://www.newInstance.com. Stamtąd, jak równieŜ spod adresu http://www.oreilly.com/catalog/javaxml/, moŜna takŜe pobrać przykładowe pliki. W tym rozdziale załoŜono, Ŝe Czytelnik uŜyje nazw plików zgodnych z opisywanymi; w przeciwnym razie trzeba odpowiednio dostosować kod (miejsca wymagające takich zmian odpowiednio zaznaczono).



Biblioteka Publiczna NaNiby



327



Po załadowaniu powyŜszego przykładu do przeglądarki, Czytelnik otrzyma wynik przypominający ten na rysunku 13.1. Tutaj nie będą omawiane pozostałe pozycje menu, ale przecieŜ dostawca moŜe chcieć przejrzeć katalog biblioteki, przejść do menu głównego czy wylogować się — wszystkie te opcje muszą więc znaleźć się w zasięgu ręki.



Rysunek 13.1. Interfejs HTML biblioteki Formularz taki pozwala dostawcy wprowadzić szczegółowe informacje o kaŜdej ksiąŜce przesyłanej do biblioteki. Wprowadzane są następujące dane: tytuł, autor, wydawca, liczba stron, cena, numer ISBN, opis, a takŜe kategoria tematyczna ksiąŜki. Po wprowadzeniu informacji formularz przesyłany jest do skryptu CGI:





Skrypt ten ma następnie zwrócić dane XML. Najprościej byłoby załadować bibliotekę Perla do obsługi przetwarzania XML, np. Xerces-Perl; naleŜy jednak pamiętać o tym, Ŝe jedno z wymagań brzmi: Ŝadnych nowych bibliotek i oprogramowania. Takie ograniczenie moŜe wydawać się głupie, ale trzeba pamiętać, Ŝe w wielu firmach oprogramowanie produkcyjne traktuje się w sposób bardzo mało elastyczny. Biblioteka Publiczna NaNiby ma „zaistnieć” w Internecie, ale nie moŜemy przeznaczyć na to Ŝadnych dodatkowych zasobów i środków. Na szczęście naszym zadaniem jest tylko uzyskać dane XML. MoŜna to zrobić w dość łatwy sposób — „brutalnie” generując pliki z informacjami wprowadzonymi do formularza. PoniewaŜ wszystkie dotychczasowe informacje i tak mają być zachowywane, zamiast tworzyć nowe pliki, wystarczy dołączyć nowe informacje do plików juŜ istniejących. Dla programistów Javy napisanie



Biblioteka Publiczna NaNiby



328



odpowiedniego programu w Perlu jest banalnym zadaniem — cały kod został zamieszczony w przykładzie 13.2.



Przykład 13.2. Skrypt Perl CGI generujący wpisy XML z wprowadzonych ksiąŜek #!/usr/local/bin/perl $baseDir = "/usr/local/projects/javaxml/foobar/books/"; $filename = "books.txt"; $bookFile = $baseDir . $filename; # Pobieramy dane od uŜytkownika. use CGI; $query = new CGI; $title = $query->param('title'); $author = $query->param('author'); $subject = $query->param('subject'); $publisher = $query->param('publisher'); $isbn = $query->param('isbn'); $price = $query->param('price'); $numPages = $query->param('numPages'); $description = $query->param('description'); # Zachowujemy dane w pliku XML. if (open(FILE, ">>" . $bookFile)) { print FILE "\n"; print FILE " <![CDATA[" . $title . "]]>\n"; print FILE " \n"; print FILE " \n"; print FILE " " . $numPages . "\n"; print FILE " \n"; print FILE " " . $isbn . "\n"; print FILE " " . $price . "\n"; print FILE " \n"; print FILE " \n"; print FILE "\n\n"; # Wysyłamy potwierdzenie uŜytkownikowi. print <<"EOF"; Content-type: text/html   Biblioteka Publiczna NaNiby: Potwierdzenie   KsiąŜka została dodana
  Dziękujemy. KsiąŜka została dodana do Biblioteki. 
   EOF } else { print <<"EOF"; Content-type: text/html  



Biblioteka Publiczna NaNiby



329



Biblioteka Publiczna NaNiby: Błąd   Błąd przy dodawaniu ksiąŜki.
  KsiąŜka NIE została wprowadzona do biblioteki. 
   EOF } close (FILE);



PowyŜszy program, zachowany jako addBook.pl, uruchamiany jest po wysłaniu formularza. Skrypt definiuje nazwę pliku, do którego mają zostać zapisane dane, a następnie przypisuje parametry pobrane z formularza zmiennym lokalnym: $title = $query->param('title'); $author = $query->param('author'); $subject = $query->param('subject'); $publisher = $query->param('publisher'); $isbn = $query->param('isbn'); $price = $query->param('price'); $numPages = $query->param('numPages'); $description = $query->param('description');



Kiedy juŜ wartości te są dostępne, skrypt otwiera plik zdefiniowany wcześniej w trybie do dopisywania (symbol >> poprzedzający nazwę pliku) i na jego końcu zapisuje dane sformatowane jako XML: print print print print print print print print print print print



FILE FILE FILE FILE FILE FILE FILE FILE FILE FILE FILE



"\n"; " <![CDATA[" . $title . "]]>\n"; " \n"; " \n"; " " . $numPages . "\n"; " \n"; " " . $isbn . "\n"; " " . $price . "\n"; " \n"; " \n"; "\n\n";



Temat wykorzystywany jest jako atrybut elementu znajdującego się wyŜej w hierarchii (book), natomiast pozostałe informacje zostają wprowadzone jako poszczególne elementy. PoniewaŜ pola zawierające tytuł, nazwisko autora, opis i nazwę wydawcy ksiąŜki mogą zawierać cudzysłowy, apostrofy, „ampersandy” i inne znaki wymagające wstawienia ich w sekwencje unikowe, dane te zamkniemy w sekcji CDATA, co zwolni nas z konieczności znoszenia specjalnych znaczeń tych znaków. Ponadto powinniśmy zauwaŜyć, Ŝe nie tworzymy deklaracji XML ani elementu głównego (w jednym pliku będą zawarte informacje o wielu ksiąŜkach). PoniewaŜ sprawdzenie, czy plik istnieje, zapisanie deklaracji i elementu głównego, jeśli nie istnieje, a następnie zapisanie elementu kończącego (który po kaŜdej nowej porcji informacji będzie musiał zostać nadpisany) jest nieco kłopotliwe, pozostawimy ten plik w takiej postaci, w jakiej jest — jako fragment dokumentu XML. Na przykład tak wyglądałby plik po wprowadzeniu dwóch ksiąŜek:  <![CDATA[Java Servlet Programming]]>   528 



Biblioteka Publiczna NaNiby



330



156592391X 36.95   



 <![CDATA[Second Foundation]]>   279  0553293362 5.59   



MoŜe nie jest to kompletny dokument XML, ale sam ten fragment jest sformatowany poprawnie i mógłby zostać wstawiony do dokumentu XML zawierającego juŜ nagłówek i element główny. I tak właśnie zrobimy, kiedy za chwilę zajmiemy się mechanizmem wyświetlającym listę ksiąŜek. Reszta skryptu zwraca odpowiednie dane HTML w zaleŜności od tego, czy dodawanie ksiąŜki się powiodło, czy nie. W pierwszym przypadku dostawca zobaczy proste potwierdzenie, takie jak na rysunku 13.2.



Rysunek 13.2. Komunikat potwierdzający dodanie ksiąŜki Teraz moŜna juŜ wykorzystać ten fragment dokumentu do udzielania odpowiednich informacji stronom Ŝądającym.



Wyświetlanie listy dostępnych ksiąŜek Do wyświetlenia listy nowych ksiąŜek znów posłuŜy Perl. ZałóŜmy, Ŝe jakaś inna porcja aplikacji biblioteki okresowo odczytuje dane XML i aktualizuje katalog. Ten składnik aplikacji byłby odpowiedzialny równieŜ za usuwanie wpisów w naszym pliku, tak aby ksiąŜki juŜ wprowadzone do katalogu nie były klasyfikowane jako „nowe”. Zadanie dla naszego drugiego skryptu w Perlu jest więc następujące: odczytać fragment kodu XML i dodać dane do dokumentu wyświetlanego na ekranie. Jak juŜ było wspomniane, konieczne jest takŜe dodanie deklaracji XML i elementu



Biblioteka Publiczna NaNiby



331



głównego, „otaczającego” dostarczoną zawartość. Nowy skrypt (przykład 13.3) odczytuje plik utworzony przez addBook.pl i wyświetla odpowiednią zawartość po otrzymaniu Ŝądania przez HTTP.



Przykład 13.3. Skrypt Perl CGI wyświetlający dokument XML z nowymi ksiąŜkami #!/usr/local/bin/perl $baseDir = "/usr/local/projects/javaxml/foobar/books/"; $filename = "books.txt"; $bookFile = $baseDir . $filename; # Najpierw otwieramy plik. open(FILE, $bookFile) || die "Could not open $bookFile.\n"; # Przekazujemy przeglądarce informacje o rodzaju przesyłanych danych. print "Content-type: text/plain\n\n"; # Wyświetlamy nagłówek i element główny XML. print "\n"; print "\n"; # Wyświetlamy ksiąŜki. while () { print "$_"; }



# Zamykamy element główny. print "\n"; close(FILE);



PowyŜszy skrypt, zachowany jako supplyBooks.pl, przyjmie Ŝądanie, odczyta plik stworzony przez addBook.pl i wyświetli dane XML po Ŝądaniu HTTP. Przykładowy wynik (z dodanymi ksiąŜkami) moŜna obejrzeć na rysunku 13.3.



KsiegarniaTechniczna.com



332



Rysunek 13.3. Wynik działania skryptu supplyBooks.pl Jak widać, prostą aplikację w Perlu łatwo moŜna zamienić w składnik, który potrafi dostarczyć uŜyteczne informacje klientom — takim jak księgarnia KsiegarniaTechniczna.com. Zrobiliśmy to bez instalacji nowego oprogramowania, bez zmiany architektury systemu lub aplikacji i bez pisania choćby jednej linijki kodu w Javie!



KsiegarniaTechniczna.com Biblioteka Publiczna NaNiby umoŜliwia juŜ uzyskanie dostępu do danych o nowych ksiąŜkach w formacie XML. Teraz KsiegarniaTechniczna.com jest juŜ bliska osiągnięcia zamierzonego celu — dostarczyć aktualne informacje swoim klientom. W firmie tej juŜ dawno wykorzystuje się Javę do budowania aplikacji, co bardzo uprości proces uzyskiwania dostępu i korzystania z danych XML oferowanych przez bibliotekę — Java świetnie obsługuje XML, o czym zresztą przekonuje cała niniejsza ksiąŜka. Najpierw chcemy umoŜliwić wyświetlanie w firmie KsiegarniaTechniczna.com danych dotyczących nowych ksiąŜek, a następnie udostępnić te informacje klientom tej firmy.



Filtrowanie danych XML W firmie KsiegarniaTechniczna.com mają być wyświetlane wyłącznie dane o ksiąŜkach technicznych. Jak zapewne Czytelnik pamięta, Biblioteka Publiczna NaNiby pozwalała na wprowadzanie ksiąŜek o zróŜnicowanej tematyce; KsiegarniaTechniczna.com akceptuje wyłącznie ksiąŜki o problematyce informatycznej. Na szczęście, odpowiednia informacja jest zawarta w atrybucie subject elementu book. Najpierw naleŜy więc odfiltrować wszystkie ksiąŜki, których tematem nie jest „Computers”. Kiedy juŜ uzyskamy w ten sposób ksiąŜki o tematyce informatycznej, musimy je sformatować do postaci strony HTML, którą pokaŜemy klientom odwiedzającym witrynę firmy KsiegarniaTechniczna.com.



KsiegarniaTechniczna.com



333



Tutaj nie będziemy korzystali ze strony statycznej, poniewaŜ strona z nowymi pozycjami musi zostać wygenerowana przy kaŜdej próbie jej pobrania. Oczywiście, tym razem do obsługi takich Ŝądań wykorzystamy serwlet. Do konwersji danych XML z biblioteki na postać HTML świetnie nadawałby się Apache Cocoon, ale pracownicy firmy KsiegarniaTechniczna.com muszą całe zadanie wykonać jak najszybciej i na razie nie chcą wprowadzać tak duŜych zmian w istniejącym systemie. Wolą wykorzystać parsery i procesory XML, a dopiero w drugiej fazie wdraŜania zainstalować Cocoon. A więc trzeba obsłuŜyć konwersję XML-HTML, a oprócz tego jeszcze filtrowanie i dodawanie elementów prezentacyjnych (np. logo firmy czy pasek menu). Ale jeśli Czytelnik przywoła całą wiedzę o XML-u i XSL-u, to być moŜe przypomni sobie, Ŝe nawet bez Cocoona moŜna przekształcać dokumenty XML na format HTML-a — za pomocą arkuszy XSL. W trakcie transformacji moŜna równieŜ odfiltrować ksiąŜki o tematyce innej niŜ komputerowa. Pamiętając o tym wszystkim, moŜemy juŜ stworzyć arkusz stylu, który zostanie zastosowany do dokumentu przesłanego z Biblioteki Publicznej NaNiby. Początkowy fragment takiego arkusza, obsługujący generację dokumentu HTML, został zamieszczony w przykładzie 13.4.



Przykład 13.4. Arkusz stylu dla danych otrzymywanych z Biblioteki Publicznej NaNiby      Księgarnia Techniczna - Twój sklep z literaturą komputerową       
  Twoje źródło ksiąŜek o tematyce komputerowej i technicznej. 
   Nowe pozycje  
      Strona główna  
  



KsiegarniaTechniczna.com Obecne pozycje  
   Nowe pozycje  
   Kontakt  
        Witamy w firmie KsiegarniaTechniczna.com, oferującej ksiąŜki o tematyce komputerowej i technicznej. Po lewej stronie zamieszczono najnowsze tytuły. Aby nabyć którąś z tych wspaniałych ksiąŜek, wystarczy kliknąć odsyłacz "Kup ksiąŜkę!" co spowoduje jej przeniesienie do koszyka. Miłych zakupów!  
   MoŜna takŜe przejrzeć nasze wcześniejsze tytuły, zajrzeć do informacji o sklepie, albo skontaktować się z nami. Wszystkie niezbędne odsyłacze znajdują się po lewej stronie. Dziękujemy za zakupy u nas!  
     
 
  
 
    



334



KsiegarniaTechniczna.com



335



Co prawda nie zostały jeszcze odfiltrowane przychodzące dane XML (nie zostały równieŜ przekształcone), ale interfejs HTML przedstawiany uŜytkownikowi jest juŜ gotowy. Często o wiele prościej jest najpierw zająć się tymi „prezentacyjnymi drobiazgami”, a dopiero potem samą logiką transformacji. Przy tworzeniu arkuszy XSL, szczególnie na potrzeby aplikacji WWW, naleŜy zawsze testować wynik poprzez procesor XSLT, wywołując go z wiersza poleceń. W ten sposób zostanie zagwarantowane, Ŝe na kaŜdym etapie tworzenia dokument przetwarzany jest zgodnie z oczekiwaniami. O wiele trudniej usuwać błędy w duŜym, gotowym juŜ arkuszu stylu. Informacje o tym, jak korzystać z procesora Apache Xalan z wiersza poleceń, zostały zawarte w rozdziale 7. W tym konkretnym przypadku moŜna pobrać plik supplyBooks.pl za pomocą przeglądarki, zachować wynik jego działania w pliku XML i wtedy przetestować arkusz stylu.



Podobnie jak w przypadku aplikacji w Bibliotece Publicznej NaNiby, po lewej stronie tworzone jest menu z odsyłaczami do innych części aplikacji; umieszczony jest równieŜ krótki opis firmy i jej oferty. Natomiast po prawej stronie pozostawiliśmy miejsce na nowe pozycje ksiąŜkowe. Przed odfiltrowaniem zawartości trzeba dodać szablon wyświetlający zawartość HTML z jednego elementu book. Wpis będzie wyglądał mniej więcej tak:  <![CDATA[Running Linux]]>   630  1565921518 29.95   



Takie dane naleŜy przekształcić w kod HTML za pomocą następującego szablonu XSL:          


KsiegarniaTechniczna.com


336

      



    Autor: 
 Wydawca: 
 Stron: 
 Cena: 
 
   /servlets/BuyBookServlet?isbn= =  Kup ksiąŜkę!   
 
  
 
 
  



Szablon dopasowuje element book, a następnie tworzy tabelę z nagłówkiem w jednym wierszu i zawartością w drugim. Cała tabela umieszczona jest wewnątrz innej tabeli, dzięki czemu w przeglądarce ta pierwsza tabela sprawia wraŜenie otoczonej czarną ramką. Tytuł wstawiany jest do nagłówka tabeli, a informacje o ksiąŜce (autor, wydawca, liczba stron i cena) do zawartości tabeli. Jest tam równieŜ odsyłacz do serwleta Javy BuyBookServlet, za pomocą którego moŜna w prosty sposób zakupić daną ksiąŜkę. Jako argument wywołania serwleta podawany jest numer ISBN tej ksiąŜki. W arkuszu XSL trzeba sprawdzić, czy wiersz opisujący uŜycie BuyBookServlet oraz wiersz z elementem xsl:value-of tworzą tak naprawdę jedną linijkę. W przeciwnym razie do wynikowego adresu URL mogłyby „przedostać się” spacje i znaki nowego wiersza i serwlet otrzymałby niepoprawne dane. W przedstawionym arkuszu stylów, w wyniku łamania tekstu w druku, te informacje zostały rozbite na dwa wiersze.



Teraz trzeba jeszcze zagwarantować, Ŝe nowy szablon zostanie zastosowany i Ŝe zostaną do niego przekazane wyłącznie ksiąŜki o tematyce „Computers”. Wartość atrybutu subject poznamy poprzez odwołanie się do niego za pomocą symbolu @; filtrowanie nastąpi poprzez atrybut select elementu xsl:apply-templates:       



KsiegarniaTechniczna.com



337



Odwołujemy się do wartości atrybutu i porównujemy go z łańcuchem znaków (w apostrofach — to dlatego, Ŝe całe wyraŜenie XPath znajduje się w cudzysłowach). PoniewaŜ „obrabiamy” atrybut elementu zagnieŜdŜonego, odwołujemy się do niego przez nazwę i otaczamy wyraŜenie związane z jego atrybutem nawiasami kwadratowymi. W ten sposób gwarantujemy, Ŝe szablon zostanie zastosowany tylko na ksiąŜkach o tematyce „Computers”. Po stworzeniu arkusza stylów moŜna go zachować jako computerBooks.xsl i odwoływać się do niego poprzez serwlet Javy, który zostanie przedstawiony poniŜej.



XSLT poprzez serwlet Arkusz stylu jest gotowy. Potrzebny jest jeszcze kod w Javie, który spowoduje zastosowanie tego arkusza na danych z biblioteki. Dostęp do danych odbędzie się za pośrednictwem klasy Javy URL, poprzez którą wyślemy Ŝądanie HTTP do systemu biblioteki. Po tym wszystkim pozostanie juŜ tylko wykonać faktyczną transformację z poziomu programu. W przykładzie 13.5 przedstawiono kod serwleta ładującego dane XML z biblioteki i ukazującego, w którym miejscu znajdzie się kod przekształcający (wykonujący transformację).



Przykład 13.5. Serwlet Javy przekształcający informacje o ksiąŜkach na postać kodu HTML package com.techbooks; import import import import import import import



java.io.FileInputStream; java.io.InputStream; java.io.IOException; java.io.PrintWriter; java.net.URL; javax.servlet.*; javax.servlet.http.*;



public class ListBooksServlet extends HttpServlet { /** Host, z którego pobierzemy listę ksiąŜek */ private static final String hostname = "newInstance.com"; /** Port powyŜszego hosta */ private static final int portNumber = 80; /** Plik (ścieŜka URI) zawierający listę ksiąŜek */ private static final String file = "/cgi/supplyBooks.pl"; /** Arkusz stylu, według którego przekształcimy XML */ private static final String stylesheet = "/home/client/java/newinstance/www/javaxml/techbooks/XSL/computerBooks .xsl"; public void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html"); // Łączymy się w celu pobrania listy ksiąŜek URL getBooksURL = new URL("http", hostname, portNumber, file); InputStream in = getBooksURL.openStream(); // Przekształcamy dane XML za pomocą arkusza stylu } }



KsiegarniaTechniczna.com



338



Ten prosty serwlet wysyła Ŝądanie HTTP do biblioteki i otrzymuje odpowiedź w języku XML w postaci strumienia InputStream1. Strumień zostanie następnie wykorzystany jako parametr procesora XSLT oraz jako baza do przekształcenia przez arkusz stylu zdefiniowany w serwlecie jako statyczny. Obecnie nie istnieje interfejs API Javy, który określałby, jak programowo wykonać transformację XSLT; jednakŜe kaŜdy producent procesora powinien udostępniać klasy umoŜliwiające uruchomienie przekształcania z kodu Javy. Tutaj ponownie zostanie wykorzystany procesor Apache Xalan; informacji o sposobie wywoływania metod transformacji w innym parserze naleŜy zasięgnąć u producenta. W przypadku procesora Apache Xalan do opisanego celu słuŜy klasa XSLTProcessor z pakietu org.apache.xalan.xslt. Jako parametry przyjmuje ona klasę XSLTInputSource reprezentującą plik XML do przetwarzania, klasę XSLTInputSource reprezentującą arkusz stylu oraz XSLTResultTarget reprezentującą wynik transformacji. Wszystkie te klasy pomocnicze znajdują się równieŜ w pakiecie org.apache.xalan.xslt. Klasy te tworzy się w wygodny sposób, przekazując InputStream (do XSLTInputSource) lub OutputStream (do XSLTResultTarget). Nasz dokument ma postać obiektu InputStream, arkusz stylu „zapakujemy” w FileInputStream, zaś interfejs serwleta pozwala nam w prosty sposób uzyskać dostęp do obiektu ServletOutputStream poprzez metodę getOutputStream(), wywołaną na obiekcie HttpServletResponse. Na koniec trzeba jeszcze omówić sposób uzyskania egzemplarza XSLTProcessor. PoniewaŜ do przetwarzania mogą być wykorzystane róŜne mechanizmy wewnętrzne, egzemplarza tej klasy nie tworzy się bezpośrednio, ale poprzez klasę XSLTProcessorFactory, równieŜ znajdującą się w pakiecie org.apache.xalan.xslt. Czytelnik wie juŜ, jak korzystać z klas typu „factory”, a więc pozostało tylko zaimportować wymagane klasy i dodać do serwleta wywołania metod przetwarzających: package com.techbooks; import import import import import import import



java.io.FileInputStream; java.io.InputStream; java.io.IOException; java.io.PrintWriter; java.net.URL; javax.servlet.*; javax.servlet.http.*;



// Import komponentów procesora Xalan XSLT import org.apache.xalan.xslt.XSLTInputSource; import org.apache.xalan.xslt.XSLTProcessor; import org.apache.xalan.xslt.XSLTProcessorFactory; import org.apache.xalan.xslt.XSLTResultTarget; public class ListBooksServlet extends HttpServlet { /** Host, z którego pobierzemy listę ksiąŜek */ private static final String hostname = "newInstance.com"; /** Port powyŜszego hosta */ private static final int portNumber = 80; /** Plik (ścieŜka URI) zawierający listę ksiąŜek */ private static final String file = "/cgi/supplyBooks.pl";



1



Więcej informacji o klasie URL i operacjach wejścia-wyjścia Javy moŜna znaleźć w ksiąŜce Java I/O Eliotte Rusty Harolda (O'Reilly & Associates).



KsiegarniaTechniczna.com



339



/** Arkusz stylu, według którego przekształcimy XML */ private static final String stylesheet = "/home/client/java/newinstance/www/javaxml/techbooks/XSL/computerBooks .xsl"; public void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/html"); // Łączymy się w celu pobrania listy ksiąŜek URL getBooksURL = new URL("http", hostname, portNumber, file); InputStream in = getBooksURL.openStream(); try { XSLTProcessor processor = XSLTProcessorFactory.getProcessor(); // Przekształcamy XML za pomocą arkusza stylu processor.process(new XSLTInputSource(in), new XSLTInputSource(new FileInputStream(stylesheet)), new XSLTResultTarget(res.getOutputStream())); } catch (Exception e) { PrintWriter out = res.getWriter(); out.println("Błąd: " + e.getMessage()); out.close(); } } }



Procesor wysyła dane wyjściowe do ServletOutputStream, a więc nie trzeba nawet dodawać Ŝadnych dodatkowych danych wynikowych, oczywiście poza przypadkami błędów! Teraz moŜna zachować serwlet jako ListBooksServlet.java i po kompilacji będzie on dostępny poprzez mechanizm serwletów i przeglądarkę. Jeśli Czytelnik stara się wykonywać opisywane przykłady, to przed uruchomieniem serwleta będzie musiał przedsięwziąć pewne kroki. Po pierwsze, musi ustanowić połączenie z Internetem albo dokonać zmian w przykładach, tak aby mogły być uruchamiane lokalnie; serwlet obsługujący KsiegarniaTechniczna.com musi mieć dostęp do danych biblioteki. Po drugie, warto wpisać kilka ksiąŜek o róŜnej tematyce do systemu biblioteki poprzez interfejs HTML. W ten sposób Czytelnik będzie mógł zobaczyć, co dokładnie robią aplikacje i jak ze sobą współpracują. Kiedy juŜ dane znajdują się w bibliotece, a do samej biblioteki mamy dostęp, moŜna uruchomić ListBooksServlet.



Uruchomiony serwlet wysyła Ŝądanie pobrania danych z Biblioteki Publicznej NaNiby. Dane te (lista nowych ksiąŜek) są następnie przekształcane i wyświetlane na ekranie jako HTML. Odpowiedź z serwleta powinna wyglądać podobnie do tej pokazanej na rysunku 13.4 — widzimy spis nowych ksiąŜek i aktualne informacje o nich (dzięki zmianom w bibliotece!); mamy takŜe odsyłacze pozwalające na natychmiastowy zakup wybranej ksiąŜki. Klienci firmy KsiegarniaTechniczna.com w prosty sposób przeglądają nowe tytuły online; pozostaje jeszcze „wypchnąć” te informacje do klientów tak, aby nie musieli nawet wpisywać adresu URL. Rozwiązanie tego problemu znajduje się w dalszej części rozdziału.



Pobieranie a „wypychanie” informacji



340



Pobieranie a „wypychanie” informacji Do tej pory aplikacje tworzyliśmy z załoŜeniem, Ŝe klienci sami będą pobierali dane i zawartość. Innymi słowy, klient musiał wpisać adres URL w przeglądarce (jak przy liście nowych ksiąŜek w witrynie KsiegarniaTechniczna.com), lub teŜ aplikacja taka jak opisywany wyŜej serwlet musiała wysłać Ŝądanie HTTP pobrania danych XML (jak w bibliotece). Oczywiście, nie ma tutaj Ŝadnego problemu — ale takie rozwiązanie nie zawsze jest najlepsze z marketingowego punktu widzenia. Klienci pobierający dane muszą pamiętać, gdzie kupować ksiąŜki, a często po jednej wizycie nie powracają w dane miejsce przez dni, tygodnie i miesiące. Sporadyczne zakupy na pewno nie przynoszą takich dochodów jak transakcje nawet mniejsze, ale za to częstsze. Dlatego KsiegarniaTechniczna.com chce mieć moŜliwość wypychania (ang. push) danych do klientów. Klient dowiaduje się o nowych pozycjach wydawniczych lub promocjach bez konieczności wykonywania jakichkolwiek działań. Wynikiem są częstsze zakupy — klient nie musi sam pamiętać o odwiedzaniu strony. Ale w Internecie nie jest łatwo uzyskać takie wypychanie danych — sieć globalna to nie klient uproszczony, nie da się tak po prostu wyświetlić okienka „pop-up” z nowymi informacjami. Popularność zyskują natomiast „strony startowe” w rodzaju My Netscape firmy Netscape czy My Yahoo firmy Yahoo. W rozmowach z Netscape przedstawiciele firmy KsiegarniaTechniczna.com usłyszeli o technologii RSS — moŜe to jest właśnie sposób uzyskania zaplanowanego celu?



Rysunek 13.4. Strona HTML powstała w wyniku pobrania listy ksiąŜek



Pobieranie a „wypychanie” informacji



341



Rich Site Summary Rich Site Summary (RSS) to szczególna odmiana języka XML. Posiada własną definicję DTD i definiuje pojęcie kanału. Kanał to sposób reprezentacji danych na określony temat. Zawiera tytuł i opis kanału, grafikę (logo) oraz szereg pozycji (ang. items) kanału. KaŜda pozycja to coś, co wiąŜe się z kanałem, ewentualnie produkt lub usługa. PoniewaŜ dozwolone elementy pozycji są raczej ogólne (tytuł, opis, odsyłacz), pozycją kanału moŜe być niemal wszystko. Kanał RSS nie ma dostarczać kompletnej zawartości serwisu, lecz raczej „streszczenie” informacji o firmie lub usłudze, wyświetlane w postaci „portalowej”, ewentualnie jako pasek informacji na innej stronie WWW. Tak naprawdę poszczególne „widŜety” w serwisie Netscape Netcenter to właśnie kanały RSS. Netscape udostępnia moŜliwość tworzenia nowych kanałów RSS, rejestrowanych w Netcenter. Netscape posiada równieŜ wbudowany system wyświetlania kanałów w formacie HTML, które wtedy świetnie spisują się jako strony startowe Netcenter. Czytelnik moŜe w tej chwili niepokoić się, czy RSS nie jest czasem dla firmy Netscape czymś takim jak parser Microsoft XML dla firmy Microsoft — czymś zupełnie nieuŜytecznym w połączeniu z innymi narzędziami czy produktami innych firm. Rozwiązanie to na początku faktycznie było opracowywane pod kątem Netcenter; jednak dzięki strukturze języka XML technologia RSS moŜe zostać wykorzystana przez dowolną aplikację potrafiącą „czytać” pliki DTD. Coraz więcej portali i aplikacji korzysta z RSS — przykładem moŜe być projekt Apache Jetspeed (http://java.apache.org/jetspeed), mający na celu stworzenie systemu Enterprise Information Portal w „stylu” open source. Jetspeed wykorzystuje dokładnie ten sam format RSS co Netscape, ale w zupełnie inny sposób. Jest to moŜliwe dzięki temu, Ŝe RSS ma bardzo spójną gramatykę. Wielu uŜytkowników korzysta ze stron „startowych” lub „domowych” — miejsc najczęściej odwiedzanych w sieci. KsiegarniaTechniczna.com postanowiła stworzyć kanał RSS przedstawiający listę najnowszych ksiąŜek i umoŜliwiający zainteresowanym natychmiastowy zakup określonego tytułu. To właśnie nazwać moŜna „wypychaniem” danych — produkty takie jak Netcenter automatycznie aktualizują zawartość kanału RSS tak często, jak Ŝyczy sobie tego klient.



Tworzenie dokumentu RSS XML Po pierwsze, konieczne jest utworzenie pliku RSS. A to jest prostsze, niŜ moŜna byłoby przypuszczać — poza wpisaniem odwołania do właściwej DTD i trzymania się określonych w tej definicji zasad, nie ma tutaj nic skomplikowanego. W przykładzie 13.6 pokazano propozycję pliku RSS dla naszej księgarni.



Przykład 13.6. Przykładowy dokument RSS opisujący kanał firmy KsiegarniaTechniczna.com     KsiegarniaTechniczna.com Nowe Tytuły http://www.newInstance.com/javaxml/techbooks/  Twoje źródło ksiąŜek i materiałów o tematyce komputerowej.  en-us 



Pobieranie a „wypychanie” informacji



342



KsiegarniaTechniczna.com  http://newInstance.com/javaxml/techbooks/images/techbooksLogo.gif  http://newInstance.com/javaxml/techbooks 140 23  Źródło ksiąŜek technicznych.    Java Servlet Programming  http://newInstance.com/javaxml/techbooks/buy.xsp?isbn=156592391X   Doskonałe wprowadzenie do serwletów Javy i róŜnych mechanizmow komunikacyjnych.    



Element główny musi nazywać się rss; musi zostać takŜe zdefiniowany atrybut version. Oprócz tego, wartość tego atrybutu musi odpowiadać wersji DTD, do której się odwołujemy. W elemencie głównym musi wystąpić dokładnie jeden element channel. Wewnątrz niego znajdują się natomiast elementy opisujące dany kanał (title, link, description i language). Z kanałem moŜna równieŜ skojarzyć opcjonalny plik graficzny (oraz informacje o tym pliku). Następnie moŜe wystąpić do 15 elementów item, z których kaŜdy opisuje jedną pozycję związaną z kanałem. KaŜdy item posiada elementy title, link i description (ich znaczenia nie trzeba chyba wyjaśniać). Tak jak w poprzednich przykładach, równieŜ tutaj w elementach link i url nie powinny znaleźć się białe znaki — całość powinna mieć postać jednego wiersza. W druku nie było to moŜliwe, dlatego wiersz został rozdzielony.



MoŜna takŜe dodać opcjonalne pole tekstowe i przycisk do wysyłania informacji, czego w tym przykładzie nie pokazano. Szczegółowy opis elementów i atrybutów znajduje się na stronie http:// my.netscape.com/publish/help/mnn20/quickstart.html. Tworzenie plików RSS programowo nie jest trudne; procedura podobna jest do tej, jaka została wykorzystana przy generowaniu pliku HTML na potrzeby księgarni. Połowa pliku RSS (informacje o kanale oraz o grafice) to treść statyczna; tylko elementy item są budowane dynamicznie. Ale kiedy juŜ programista uruchamia edytor vi i zasiada do tworzenia kolejnego arkusza XSL, na biurku znajduje kartkę z kolejnym wymogiem: komputer, na którym znajdzie się kanał RSS, to inny serwer niŜ ten uŜywany w ostatnim przykładzie; dostępne są na nim tylko bardzo stare wersje bibliotek Apache Xalan. PoniewaŜ na maszynie tej działają równieŜ pewne aplikacje wysokiej dyspozycyjności (np. system naliczania naleŜności), KsiegarniaTechniczna.com nie chce aktualizować tych bibliotek, chyba Ŝe przy precyzyjnej kontroli efektów zmian (taki proces zajmuje tydzień). Na samym serwerze są jednak dostępne nowsze wersje bibliotek Xerces (poniewaŜ w sys-



Pobieranie a „wypychanie” informacji



343



temie naliczania konieczne jest przetwarzanie XML-a), a więc dostępne są równieŜ interfejsy API Javy do obsługi XML-a.2 Oczywiście, dałoby się tutaj wykorzystać interfejsy SAX i DOM, ale po raz kolejny najlepszą metodą wydaje się JDOM. To za jego pomocą (przykład 13.7) dokonamy konwersji pliku XML z Biblioteki Publicznej NaNiby na format kanału RSS.



Przykład 13.7. Serwlet Javy konwertujący listę nowych ksiąŜek na dokument kanału RSS package com.techbooks; import import import import import import import import import



java.io.FileInputStream; java.io.InputStream; java.io.IOException; java.io.PrintWriter; java.net.URL; java.util.Iterator; java.util.List; javax.servlet.*; javax.servlet.http.*;



// JDOM import org.jdom.Document; import org.jdom.Element; import org.jdom.JDOMException; import org.jdom.input.Builder; import org.jdom.input.SAXBuilder; public class GetRSSChannelServlet extends HttpServlet { /** Z tego hosta pobieramy listę ksiąŜek */ private static final String hostname = "newInstance.com"; /** Numer portu powyŜszego hosta */ private static final int portNumber = 80; /** ŚcieŜka URI prowadząca do dokumentu */ private static final String file = "/cgi/supplyBooks.pl"; public void service(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException { res.setContentType("text/plain"); PrintWriter out = res.getWriter(); // Łączymy się i pobieramy listę ksiąŜek URL getBooksURL = new URL("http", hostname, portNumber, file); InputStream in = getBooksURL.openStream(); try { // śądamy implementacji SAX i korzystamy z domyślnego parsera. Builder builder = new SAXBuilder(); // Tworzymy dokument. Document doc = builder.build(in); // Wyświetlamy XML. out.println(generateRSSContent(doc));



2



Tak, to nieco wydumany przykład, pewnie mało prawdopodobny. Ale pozwala Czytelnikowi poznać jeszcze jedną alternatywę co do sposobu programowego tworzenia XML-a. Jednak tak naprawdę wszystkie przykłady w tej ksiąŜce (łącznie z tymi głupiutkimi) oparte są na prawdziwych doświadczeniach związanych z prowadzeniem konsultingu w rzeczywistych firmach!



Pobieranie a „wypychanie” informacji } catch (JDOMException e) { out.println("Error: " + e.getMessage()); } finally { out.close(); } } /** *

* Tutaj generujemy dokument RSS XML, korzystając z dostarczonego * obiektu JDOM Document. * Document dane wejściowe. * @return String - plik wyjściowy RSS. * @throws JDOMException w razie wystąpienia błędów. */ private String generateRSSContent(Document doc) throws JDOMException { StringBuffer rss = new StringBuffer(); rss.append("\n") .append("\n") .append("\n") .append(" \n") .append(" KsiąŜki techniczne\n") .append(" http://newInstance.com/javaxml/techbooks\n") .append(" \n") .append(" Twoje źródło ksiąŜek i materiałów o tematyce komputerowej.\n ") .append(" \n") .append(" en-us\n") .append(" \n") .append(" KsiegarniaTechniczna.com\n") .append(" ") .append("http://newInstance.com/javaxml/techbooks/images/techbooksLogo .gif") .append("\n") .append(" http://newInstance.com/javaxml/techbooks\n") .append(" 140\n") .append(" 23\n") .append(" \n") .append(" Źródło ksiąŜek technicznych.\n") .append(" \n") .append(" \n"); // Dodajemy element dla kaŜdego nowego tytułu, w którym jako temat // określono Computers. List books = doc.getRootElement().getChildren("book"); for (Iterator i = books.iterator(); i.hasNext(); ) { Element book = (Element)i.next(); if (book.getAttribute("subject") .getValue().equals("Computers")) { // Wyświetlamy pozycję. rss.append("\n") // Dodajemy tytuł

344

Pobieranie a „wypychanie” informacji

345

.append(" ") .append(book.getChild("title").getContent()) .append("\n") // Dodajemy odsyłacz umoŜliwiający kupno ksiąŜki .append(" ") .append("http://newInstance.com/javaxml/techbooks/buy.xsp?isbn=") .append(book.getChild("saleDetails") .getChild("isbn") .getContent()) .append("\n") .append(" ") // Dodajemy opis .append(book.getChild("description").getContent()) .append("\n") .append("\n"); } } rss.append(" \n") .append(""); return rss.toString(); } }

Na tym etapie nauki ani jeden fragment powyŜszego kodu nie powinien juŜ Czytelnika dziwić. Importujemy wymagane klasy JDOM i wejścia-wyjścia oraz uzyskujemy dostęp do aplikacji biblioteki publicznej dokładnie tak, jak w serwlecie ListBooksServlet. Wynikowy InputStream wykorzystywany jest do stworzenia obiektu JDOM Document, za pomocą parsera domyślnego (w JDOM 1.0 jest to Apache Xerces) oraz implementacji JDOM zbudowanej na bazie SAX-a: // śądamy implementacji SAX i korzystamy z domyślnego parsera Builder builder = new SAXBuilder(); // Tworzymy dokument. Document doc = builder.build(in);

Teraz przekazujemy Document do metody generateRSSContent(), która drukuje całą zawartość statyczną kanału. Metoda ta pobiera elementy book z biblioteki, przetwarza je kolejno i ignoruje te, w których jako subject określono coś innego niŜ „Computers”: // Dodajemy element dla kaŜdego nowego tytułu, w którym jako temat // określono Computers. List books = doc.getRootElement().getChildren("book"); for (Iterator i = books.iterator(); i.hasNext(); ) { Element book = (Element)i.next(); if (book.getAttribute("subject") .getValue().equals("Computers")) { // Wyświetlamy pozycję. } }

KaŜdy element, który przejdzie pomyślnie powyŜszy test, dodawany jest do kanału RSS. Prawda, Ŝe nic nadzwyczajnego? Na rysunku 13.5 przedstawiono przykładowe dane zwracane przez serwlet, który zachowano jako plik GetRSSChannelServlet.java.

Pobieranie a „wypychanie” informacji

346

KsiegarniaTechniczna.com udostępniła w ten sposób informacje wszystkim usługodawcom, którzy obsługują technologię RSS. śeby jeszcze klienci mogli korzystać z takiego kanału, KsiegarniaTechniczna.com zarejestruje kanał w Netscape Netcenter.

Sprawdzanie poprawności kanału RSS Po stworzeniu kanału naleŜy sprawdzić jego poprawność. W ten sposób nie tylko zagwarantujemy, Ŝe dokument jest zgodny z wymogami określonymi przez definicję RSS DTD; będzie on równieŜ zgodny z pewnymi ograniczeniami narzucanymi przez Netscape, a niemoŜliwymi do określenia w definicji DTD (w przyszłości być moŜe rozwiązaniem tego problemu będzie XML Schema). Firma Netscape oferuje mechanizm sprawdzania poprawności kanałów online, znajdujący się pod adresem http://my.netscape.com/publish/help/validate.tmpl. Po wpisaniu na tej stronie adresu naszego kanału RSS (który moŜe mieć postać serwleta, skryptu CGI lub pliku statycznego) odpowiedni program sprawdzi jego poprawność. Na rysunku 13.6 przedstawiono stronę wyświetlaną po udanym sprawdzeniu poprawności. Teraz moŜna juŜ zarejestrować nasz kanał w usłudze Netcenter.

Rysunek 13.5. Kanał RSS wygenerowany przez serwlet GetRSSChannelServlet

Pobieranie a „wypychanie” informacji

347

Rysunek 13.6. Potwierdzenie sprawdzania poprawności kanału RSS

Rejestracja kanału Po sprawdzeniu poprawności opublikujemy kanał w serwisie Netcenter (lub u innego usługodawcy). W tym celu wchodzimy na stronę http://my.netscape.com/publish. NaleŜy podać nazwę konta Netcenter, poniewaŜ e-mail potwierdzający zostanie wysłany na adres podany przy zakładaniu takiego konta. Po podaniu adresu poprawnego kanału RSS, Netcenter dodaje go do systemu kanałów i wysyła e-mail. W wiadomości takiej zawarte są instrukcje dotyczące dodania odsyłacza do kanału RSS ze strony WWW (np. z KsiegarniaTechniczna.com, o czym za chwilę) oraz dotyczące dodania kanału do strony startowej Netcenter.

Korzystanie z kanału Sprawdzenie poprawności i rejestracja kanału nie przedstawiały trudności. Otrzymany e-mail upraszcza nawet dodanie takiego kanału do strony startowej. Od tej pory nasz kanał RSS w postaci HTML będzie moŜna oglądać jako fragment strony startowej Netcenter. Po kaŜdym otwarciu tej strony startowej uŜytkownik zobaczy „ramkę” KsiegarniaTechniczna.com, w której znajdzie nowe tytuły i będzie mógł je natychmiast zakupić. To na pewno zwiększy przychody ze sprzedaŜy online. Aby rozreklamować kanał, do stworzonego arkusza stylu moŜna jeszcze dodać odsyłacz, który spowoduje automatyczne dodanie kanału do strony startowej oglądającego. Tak więc jedna operacja pobrania danych moŜe zaowocować codziennymi „wypchnięciami” oferty firmy. Oto sposób dodania odsyłacza do arkusza:

Kontakt

Pobieranie a „wypychanie” informacji

348

WIDTH="88" HEIGHT="31" BORDER="0" />

Witamy w firmie KsiegarniaTechniczna.com, oferującej ksiąŜki o tematyce komputerowej i technicznej. Po lewej stronie zamieszczono najnowsze tytuły. Aby nabyć którąś z tych wspaniałych ksiąŜek, wystarczy kliknąć odsyłacz "Kup ksiąŜkę!" co spowoduje przeniesienie wybranej pozycji do koszyka. Miłych zakupów!

Wprowadzenie takiego fragmentu (który otrzymujemy e-mailem z Netscape po rejestracji kanału) spowoduje dodanie elementu graficznego, odsyłającego prosto do strony, która dodaje kanał do strony startowej uŜytkownika. Sformatowana strona HTML po wprowadzeniu zmiany wygląda tak, jak na rysunku 13.9.

Rysunek 13.9. Strona HTML z odwołaniem do kanału RSS Netscape Przykładowy problem komunikacji typu firma-firma został rozwiązany. Punktem wyjścia była organizacja pracująca w jednym języku i bez moŜliwości wykorzystania XML-a (Biblioteka Publiczna NaNiby wraz z jej skryptami w Perlu); w wyniku działań przedstawionych w tym rozdziale uzyskała ona moŜliwość komunikacji z firmą korzystającą z zupełnie innej technologii (serwlety

Praktyka

349

Javy). Obie firmy nie były w Ŝaden sposób ze sobą zsynchronizowane — Ŝaden fragment kodu jednej nie łączył się w jakikolwiek sposób z kodem drugiej. PoniewaŜ jako nośnik informacji został uŜyty język XML, w obu firmach mogą się zmienić aplikacje, technologie, a nawet architektury, a i tak nie wpłynie to na stworzony w rozdziale mechanizm. Następnie Czytelnik dowiedział się, jak w wyniku takiej komunikacji moŜna stworzyć zawartość HTML prezentowaną uŜytkownikom (na zupełnie róŜne sposoby zaleŜnie od aplikacji) oraz jak „wypchnąć” tę zawartość do klientów w jeszcze jednym formacie HTML poprzez kanały RSS. Wszystko to moŜliwe było dzięki obecnemu „za kulisami” XML-owi.

Praktyka Niewiele więcej moŜna powiedzieć o aplikacjach typu firma-firma. Omawiany przykład został zaczerpnięty z Ŝycia — podobne wymagania i cele określone zostały w pewnych duŜych firmach. W kolejnych podrozdziałach Czytelnik dowie się, czym róŜni się to rozwiązanie skoncentrowane wokół XML-a od technologii Electronic Data Interchange (EDI); omówione zostaną równieŜ inne zastosowania kanałów RSS.

XML kontra EDI Zapotrzebowanie na komunikację pomiędzy firmami jest coraz większe i to przyczyniło się do spopularyzowania technologii Electronic Data Interchange (EDI). Drogie produkty i rozwiązania typu „heavy-duty”, jeśli tylko na ich pudełkach widnieje napis „EDI”, od razu sprzedają się jak świeŜe bułeczki. Ale te kosztowne rozwiązania, co oczywiste, nie są popularne w mniej zamoŜnych firmach. Od kiedy pojawił się XML, nawet firmy o wysokim budŜecie rezygnują z EDI na rzecz XML-a. Wynika to nie tylko z faktu, ze XML jest rozwiązaniem wysoce standardowym, ale równieŜ z prostoty tego języka. PrzecieŜ w jednym rozdziale został opisany sposób komunikacji zupełnie oddzielnych systemów! Dziesięć lat temu wymagałoby to całego zespołu programistów, a powstałe rozwiązanie i tak działałoby tylko w tych konkretnych warunkach. MoŜna dowieść, Ŝe XML całkowicie znosi potrzebę korzystania z EDI. Stare systemy, aplikacje własne, masywne bazy danych i produkty o podwyŜszonym stopniu bezpieczeństwa — one wszystkie mogą wymieniać dane za pomocą formatu XML. Interfejsy API w rodzaju SAX-a, DOM-a, a obecnie równieŜ JDOM-a powodują, Ŝe tworzenie pełnych rozwiązań XML jest praktyczne, a budowanie warstw XML „na” istniejących danych w róŜnych formatach to kwestia tygodni i miesięcy, a nie lat. EDI powoli zacznie znikać z rynku, jego miejsce zastąpią oferty e-biznesowe oparte na XML-u i Javie.

Kanały RSS — czy to coś trwałego? Często pada pytanie, czy formaty XML w rodzaju RSS to rozwiązanie „trwałe”. Format ten jest wykorzystywany w pewien konkretny sposób (np. na stronie Netscape Netcenter) — czy więc RSS jest rozwiązaniem firmy Netscape? Tak, RSS kojarzy się z konkretną firmą, ale poniewaŜ oparty jest na XML-u, moŜe być wykorzystywany tak jak dowolny inny dokument XML. Styl dokumentu jest całkowicie umowny, a napisanie arkusza przekształcającego RSS na WML dla telefonów bezprzewodowych to rzecz banalna. Zresztą zostało juŜ wspomniane, Ŝe projekt Apache Jetspeed korzysta z RSS, a sieć O'Reilly Network (http://www.oreillynet.com) „zatrudniła” kanały RSS w serwisach takich jak XML.com (http://www.xml.com). Jeszcze waŜniejsze jest to, Ŝe rozwiązania wykorzystujące XML z natury nie mają nic wspólnego z rozwiązaniami „własnymi”. Dowolny dokument XML moŜe być przekształcony tak, jak sobie

Co dalej?

350

tego zaŜyczy autor lub programista. Nie ulega wątpliwości, Ŝe w ciągu najbliŜszych lat dokonana zostanie migracja większości warstw prezentacyjnych do XML-a, bądź teŜ konkretnej odmiany XML-a (np. RSS). Firmy chcą budować strony o dynamicznej zawartości, ale nie mają zamiaru zatrudniać przy tym całej armii twórców witryn.

Co dalej? Czytelnik umie juŜ posługiwać się XML-em „wewnątrz” kodu w Javie. Potrafi tworzyć, przetwarzać, budować style, przekształcać, zawęŜać i sprawdzać poprawność XML-a. Wie równieŜ, jak korzystać ze struktur publikacji, ze zdalnych wywołań procedur, jak przechowywać informacje o konfiguracji w dokumencie XML oraz jak budować XML „w locie” z kodu Javy. To powinno wystarczyć do zbudowania niemal dowolnej aplikacji w języku XML. W następnym rozdziale, juŜ ostatnim w tej ksiąŜce, zostaną przedstawione schematy XML Schema. Czytelnik wie juŜ, jak za ich pomocą zawęŜać dokumenty XML; teraz dowie się, dlaczego XML Schema jest tak innowacyjny, oraz jak wpływa na sposób korzystania z języka XML. Rozdział ten nie dotyczy samego języka Java, ale omawiana w nim problematyka jest niezwykle istotna z punktu widzenia sposobu, w jaki wykorzystywany jest język XML w aplikacjach.

Co dalej?

351

Definicje DTD — stosować czy nie?

351

14 XML Schema XML Schema jest przedmiotem gorących dyskusji programistów korzystających z języka XML. Ostatnie rozdziały dotyczyły głównie sposobów manipulowania danymi XML za pomocą Javy; teraz zostanie przedstawiona XML Schema. Schematy XML to temat względnie nowy, a obsługa tej technologii ze strony klas i interfejsów Javy powstawała powoli. Mimo trudności związanych z korzystaniem z XML Schema bezpośrednio z poziomu Javy, specyfikacja ta jest na tyle waŜna, Ŝe zostanie jej poświęcony cały rozdział. Najpierw zastanowimy się, czy jest to technologia stabilna i czy stanowi dobry wybór w porównaniu z definicjami DTD. Potem przyjrzymy się, jak XML Schema odwzorowuje się na język Java oraz jak relacja ta moŜe wpłynąć na sposób składowania zawartości XML.

Definicje DTD — stosować czy nie? Niemal kaŜdy programista lub twórca zawartości XML słyszał o schematach XML; wciąŜ jednak niewiele osób jest do końca przekonanych, Ŝe „nadszedł juŜ czas” tej technologii. Wątpliwości wynikają po części ze zmian i z małej „dojrzałości” specyfikacji XML; w większym stopniu są jednak związane z faktem, Ŝe definicje DTD są juŜ dobrze znane. Wielu programistów XML wciąŜ zawęŜa dokumenty wyłącznie za pomocą DTD, nie bacząc na wzrastającą popularność XML Schema. Przed podjęciem decyzji o zaadaptowaniu nowej technologii trzeba rozwaŜyć wszelkie za i przeciw.

Stabilność specyfikacji XML Schema Jednym z największych problemów schematów XML są ciągłe zmiany wprowadzane w ich specyfikacji (patrz http://www.w3.org/TR/xmlschema-1/ oraz http://www.w3.org/TR/xmlschema-2/). W ciągu sześciu miesięcy (od sierpnia 1999 do marca 2000 r.) opublikowano trzy wersje specyfikacji; fakt ten sam w sobie nie jest niczym dziwnym, ale tutaj liczy się jeszcze coś innego — poczynione zmiany były bardzo istotne. Po wprowadzeniu kolejnej wersji schematy zgodne z poprzednimi stawały się praktycznie bezuŜyteczne — to nie mogło się podobać. Co więcej, w miarę upływu czasu specyfikacja XML Schema wydawała się coraz bardziej złoŜona, co jeszcze bardziej pogarszało nastroje programistów.

Definicje DTD — stosować czy nie?

352

Ale mimo całej tej „nieprzychylnej prasy”, specyfikacja XML Schema wydaje się obecnie przynajmniej tak waŜna, jak sam XML. Konsorcjum W3C zawsze zresztą ostrzegało, Ŝe dopóki nie zostanie opublikowana finalna wersja specyfikacji, zmiany będą nieuniknione. Co ciekawe, osoby narzekające na częste zmiany to często ci sami, którzy domagają się wprowadzenia pewnych zmian! Innymi słowy, częste zmiany w specyfikacji nie usprawiedliwiają jeszcze zaniechania korzystania z XML Schema. Niemal wszystkie zmiany, równieŜ te mniej istotne, przyczyniają się do zwiększenia przejrzystości i uŜyteczności specyfikacji.

Lepsze sposoby zawęŜenia dokumentu Chyba nie byłoby moŜliwe opisywanie schematów bez podkreślenia (juŜ nie po raz pierwszy w tej ksiąŜce) prostoty zawęŜania za pomocą XML Schema. Trudno znaleźć kogokolwiek (nawet wśród tych zatwardziałych zwolenników DTD), kto odmówiłby tej specyfikacji elastyczności i prostoty, z jaką określa się zawęŜenia danych. Co więcej, ta właśnie cecha usuwa w cień waŜniejsze pod względem merytorycznym aspekty schematów! Prawda jest taka, Ŝe twórca dowolnej aplikacji, w której konieczne jest określenie ścisłych typów danych i zakresów, musi korzystać z XML Schema. To pozwoli oszczędzić całe dni, jeśli nie tygodnie, wytęŜonej pracy. Oprócz tradycyjnych zawęŜeń, XML Schema umoŜliwia budowanie zawęŜeń modelu zawartości dla ogólnych formatów danych. ZawęŜenia takie mogą być potem współuŜytkowane i wykorzystywane przez inne schematy poprzez XLink lub XPointer. Definicje DTD, same w sobie nie będące dokumentami XML, mają w tym zakresie bardzo ograniczone moŜliwości. W przypadku duŜych aplikacji definicje DTD rozrośnięte do tysięcy wierszy to nic nadzwyczajnego. Takie podejście do danych trudno nazwać obiektowym, nie mówiąc juŜ o trudnościach w sprawdzaniu poprawności danych.

Definicje DTD — problemy z przestrzeniami nazw Czytelnik wie juŜ, Ŝe przetwarzanie dokumentu XML wykorzystującego przestrzenie nazw i wymagającego sprawdzenia poprawności moŜe sprawić powaŜne kłopoty, jeśli wybrane zostały definicje DTD. Przypomnijmy sobie ten kod: DOMParser parser = new DOMParser(); // Włączamy obsługę przestrzeni nazw. parser.setFeature("http://xml.org/sax/features/namespaces", true); // Włączamy sprawdzanie poprawności. parser.setFeature("http://xml.org/sax/features/validation", true); // Przetwarzamy. parser.parse(); // Pobieramy wyniki. Document doc = parser.getDocument();

Po kompilacji tego kodu (wewnątrz jakiejś aplikacji) wykonanie spowoduje następujący błąd krytyczny (przykład z Apache Xerces; inne parsery powinny zwrócić podobne komunikaty): org.xml.sax.SAXParseException: Document root element "JavaXML:Ksiazka", must match DOCTYPE root "JavaXML:Ksiazka". at org.apache.xerces.framework.XMLParser.reportError (XMLParser.java:1318) at org.apache.xerces.validators.dtd.DTDValidator .reportRecoverableXMLError(DTDValidator.java:1602)

Podobieństwo do Javy

353

at org.apache.xerces.validators.dtd .DTDValidator.footElementSpecified(DTDValidator.java:576) at org.apache.xerces.framework.XMLParser .scanAttributeName(XMLParser.java:2076) at org.apache.xerces.framework.XMLDocumentScanner .scanElement(XMLDocumentScanner.java, Compiled Code) at org.apache.xerces.framework .XMLDocumentScanner$ContentDispatcher.dispatch (XMLDocumentScanner.java, Compiled Code) at org.apache.xerces.framework.XMLDocumentScanner .parseSome(XMLDocumentScanner.java, Compiled Code) at org.apache.xerces.framework .XMLParser.parse(XMLParser.java:1208) at org.apache.xerces.framework .XMLParser.parse(XMLParser.java:1247)

Błąd wynika z faktu, Ŝe definicje DTD ignorują przestrzenie nazw; nie ignoruje ich natomiast mechanizm obsługujący element główny i konstrukcje znajdujące się wewnątrz niego. Ta rozbieŜność powoduje konflikty pomiędzy sprawdzaniem poprawności i przetwarzaniem przestrzeni nazw. Dokumenty XML często wymagają wykonania i jednego, i drugiego — co jeszcze bardziej zwiększa atrakcyjność schematów. Co więcej, XML Schema łatwo „przekłada się” na język Java i moŜliwości przyszłej integracji są bardzo interesujące.

Podobieństwo do Javy W miarę stabilizacji specyfikacji XML Schema zwiększyło się podobieństwo schematów do definicji klas i interfejsów Javy. XML Schema — choć to przecieŜ tylko ścisły zestaw zawęŜeń — bardzo przypomina kod, jaki piszemy w Javie, definiując klasę lub interfejs. Schemat określa zestaw danych, jakie dozwolone są w danym dokumencie XML; klasa lub interfejs określają metody i zmienne reprezentowane przez dany egzemplarz klasy. Podobnie jak program w Javie musi tylko „znać” definicję, aby korzystać z egzemplarza (bez znajomości detali implementacyjnych, takich jak adres w pamięci czy zawartość), aplikacja w XML-u musi tylko „znać” zawęŜenia dokumentu (zdefiniowane w XML Schema), aby móc z takiego dokumentu korzystać. Być moŜe to podobieństwo nie wydaje się Czytelnikowi zbyt istotne; jednak to właśnie ta cecha moŜe w ogromnym stopniu przyczynić się do powszechnego stosowania XML-a w nowych aplikacjach oraz w nowych implementacjach starych technologii. Tutaj zostaną opisane tylko niektóre z tych waŜnych zastosowań; Czytelnik sam będzie potrafił „dopowiedzieć” sobie pozostałe i przełoŜyć tę wiedzę na własne aplikacje.

RównowaŜność Istotną cechą XML Schema jest równowaŜność elementów. W XML 1.0 oraz w definicjach DTD jeden typ elementu musiał być odwzorowany na jeden element. Innymi słowy, jeśli dwa elementy współuŜytkowały identyczną zawartość, oba musiały zostać jawnie zdefiniowane:

Podobieństwo do Javy

354

Widać, Ŝe jest tutaj duŜo nadmiarowości; ponadto taki zapis podatny jest na błędy — jeśli definicja jednego elementu zostanie zmieniona, a drugiego nie. XML Schema, wprowadzając typy, rozwiązuje ten problem:

Dzięki temu mechanizmowi wystarczy zdefiniować typ elementu i potem stosować go dla róŜnych elementów. Jest to podobne do języka Java, w którym definiuje się klasę, a następnie tworzy róŜne jej egzemplarze. Ale XML Schema ma jeszcze inne ciekawe cechy. Oto fragment dokumentu XML reprezentującego fakturę transportową: Waza ceramiczna 400 doskonała Naczynie z kryształu 150 dobra

Zarówno dostawca, jak i producent moŜe chcieć dopisać dodatkowe informacje dotyczące produktów w fakturze, np. moŜe chcieć poinformować o pochodzeniu kryształowych naczyń albo o tym, Ŝe dwie wazy się stłukły: Waza ceramiczna 400 doskonała 2 wazy stłuczone w czasie transportu Naczynie z kryształu 150 dobra Naczynia zakupione w Wenecji, Włochy

Podobieństwo do Javy

355

Problem polega na tym, Ŝe źródło komentarzy nie jest jednoznaczne — mógł je dołączyć dostawca, producent lub pośrednik. Sprawę rozwiązuje zmiana nazw elementów: Waza ceramiczna 400 doskonała 2 wazy stłuczone w czasie transportu Naczynie z kryształu 150 dobra Naczynia zakupione w Wenecji, Włochy

To zwiększa przejrzystość dokumentu, ale powoduje pewne zagmatwanie schematu:

Zdefiniowano tutaj trzy róŜne elementy opisujące komentarze. KaŜdy z nich moŜe wystąpić zero lub więcej razy w elemencie produkt. Nie ma w tym nic błędnego, ale nieco niemądre wydaje się pozwalanie na wystąpienie kaŜdego z tych trzech elementów, bo przecieŜ kaŜdy z nich zawiera taki sam typ danych; komentarz obsługiwany jest zawsze jako dane tekstowe. W Javie problem moŜna byłoby rozwiązać definiując klasę Komentarz, a następnie rozszerzając ją na KomentarzPosrednika, KomentarzDostawcy i KomentarzProducenta. To pozwoliłoby na wystąpienie w elemencie produkt jednego lub więcej typów Komentarz (w XML-u komentarz). Na szczęście twórcy XML Schema myśleli podobnie i dzięki temu w schematach mamy słowo kluczowe equivClass. Definiuje się pewien element, a potem inne elementy jako równowaŜne z tym pierwszym. Te równowaŜne elementy mogą potem zostać podstawione w miejsce elementu bazowego, określanego mianem wzoru (ang. exemplar). Takie rozwiązanie bardzo upraszcza schemat:
name="komentarz" type="string" /> name="komentarzPosrednika" type="string" equivClass="comment" /> name="komentarzDostawcy" type="string" equivClass="comment" /> name="komentarzProducenta" type="string" equivClass="comment" />

Podobieństwo do Javy

356

Ten nowy schemat precyzyjniej odzwierciedla zamiar autora i bardziej przypomina składnię Javy. W elemencie produkt moŜe wystąpić dowolny element równowaŜny z elementem komentarz, a relacjami równowaŜności „zajmie się” juŜ sam proces sprawdzania zgodności z zawęŜeniami. MoŜna pójść jeszcze o krok dalej i zastosować takie konstrukcje na danych w aplikacjach w Javie — to rozwiązanie zostanie przedstawione w następnym podrozdziale.

Uzupełnianie kodu Javy schematem Spróbujmy spojrzeć na klasę Javy jak na zestaw zawęŜeń, a na egzemplarz klasy jak na dane zgodne z tymi zawęŜeniami. W tym przypadku dane mają postać binarną (kod bajtowy). ZawęŜenia definiują zmienne, które moŜna wypełnić danymi, metody, które moŜna zaimplementować, oraz dozwolone dane wejściowe i wyjściowe. JednakŜe same wartości zmiennych i metod nie są znane i pozostają nieokreślone aŜ do momentu uruchomienia programu. Podobnie jak autor zawartości „wypełnia” dokument XML danymi zgodnymi ze schematem, aplikacja „wypełnia” egzemplarz wartościami odpowiednimi dla wykonywanego właśnie zadania. Cała ta konstrukcja moŜe zostać „powielona” w kolejnych warstwach, jeśli jako kolejny zestaw zawęŜeń uznamy interfejs Javy; tym razem „elementami” są definicje klas. W interfejsie definiowane są sygnatury metod, dozwolone obiekty wejściowe i wyjściowe, zdefiniowane jest takŜe, czego muszą przestrzegać klasy implementujące interfejs. Interfejs zawęŜa definicje klas, które z kolei zawęŜają egzemplarze. Taki łańcuch zawęŜeń umoŜliwia wysoce efektywne modelowanie i projektowanie obiektowe; jednak dane, którymi „wypełniane” są wartości w egzemplarzu klasy, nie są zawęŜane w inny sposób niŜ poprzez podanie ich typu. Na przykład, dopuszczalne są dowolne wartości, o ile są typu int. Dalsze zawęŜanie wymaga stworzenia odpowiedniego kodu wewnątrz implementacji klasy lub metody. Podobnie nieograniczone są wartości zwracane. Jeśli więc wartość wywoływanej metody musi mieścić się w pewnym ściśle określonym przedziale, klient aplikacji musi sam wykonać sprawdzanie poprawności. To wymaga dodatkowego kodowania oraz moŜe sprawiać wraŜenie dwuznaczności z punktu widzenia osób, które będą w przyszłości korzystały ze stworzonych przez nas klas. Zwracane wartości mogą nie mieścić się w zakresie wartości dozwolonych przez klienta; jeśli jawnie nie zostanie wykonane sprawdzanie poprawności, moŜe to doprowadzić do nieoczekiwanych — i powaŜnych — błędów. W takich przypadkach Javę doskonale uzupełnia XML Schema. PoniewaŜ schemat zawęŜa dane dozwolone przez zmienne przynaleŜne do egzemplarza klasy, umoŜliwia o wiele precyzyjniejsze kontrolowanie danych zwracanych klientom z wywołań metod. XML Schema moŜe równieŜ słuŜyć do definiowania wartości dozwolonych w egzemplarzu klasy. Jako przykład niech posłuŜą niektóre zmienne przynaleŜne stworzonej w poprzednich rozdziałach klasy procedury obsługi XmlRpcConfiguration:

Podobieństwo do Javy

357

private String uri; private String hostname; private int portNumber = 0; private Hashtable handlers;

Problem polega na tym, Ŝe nazwa hosta moŜe mieć ograniczoną długość; numer portu powinien być zawsze dodatnią liczbą całkowitą mniejszą od 64000; a procedury obsługi mogą mieć jeszcze inne ograniczenia. Klient XML-RPC moŜe jednak wysłać dowolny typ wartości, a więc procedura obsługi musi wykonać sprawdzanie poprawności. Jednak do definicji klasy w Javie moŜna byłoby przecieŜ dodać następujący schemat (tutaj fragment), definiujący dozwolone parametry danych:

KaŜda zmienna przynaleŜna traktowana jest jako atrybut samej klasy. Jeśli naszemu kodowi w Javie towarzyszy schemat taki jak powyŜszy, sprawdzanie poprawności moŜe odbyć się poza kodem, za pomocą standardowego mechanizmu. Oprócz tego klient moŜe działać bardziej inteligentnie — rozumie, jakie wartości są dozwolone, i zna wszystkie zawęŜenia. Integracja takiego mechanizmu na poziomie wirtualnej maszyny Javy (JVM) to jeszcze odległa przyszłość, ale juŜ teraz warto zacząć zastanawiać się nad tym, w jaki sposób przeprowadzamy sprawdzanie poprawności. Jeśli konwertujemy zawęŜenia danych z DTD na XML Schema, to juŜ samo to działanie jest dobrym treningiem przed wprowadzeniem nowych rozwiązań. Są równieŜ sposoby na zintegrowanie zawęŜeń XML Schema z logiką aplikacji poprzez konwersję zawęŜeń.

Dopasowanie wzorca Teraz zostaną omówione moŜliwości dopasowania wzorca w XML Schema. Czytelnik wie juŜ, Ŝe zastosowanie XML Schema pozwala uniknąć skomplikowanego sprawdzania poprawności w kodzie Javy. Takie rozwiązanie ma jednak zastosowanie tylko wtedy, gdy schemat potrafi więcej, niŜ tylko definiować proste zakresy numeryczne i długości zmiennych String. Bardziej skomplikowane jest na przykład zdefiniowanie, Ŝe w danej zmiennej moŜe znaleźć się wartość typu „waluta”, i to o określonym formatowaniu. W takim przypadku konieczne jest zastosowanie dopasowania wzorca — bo przecieŜ choćby samą walutę dolarową moŜna zapisać na bardzo wiele sposobów (tutaj zapis amerykański): $4.50 $45.96 $54 $45.6

Aby schematy nadawały się do przeprowadzania sprawdzania poprawności, „obsługa” takich wartości jak powyŜsze musi być moŜliwa. XML Schema umoŜliwia wykonanie dopasowania wzorca poprzez atrybut pattern powiązany z elementem lub atrybutem. Typ „walutowy” moŜna przed-

Podobieństwo do Javy

358

stawić jako następującą definicję; wymagamy w niej wystąpienia wartości w jednym z powyŜszych formatów (i zaczynających się od znaku dolara):

Co dalej?

360

Kiedy mamy juŜ taki schemat, kod aplikacji moŜna „odchudzić”, a sprzęŜenie z bazą danych nie jest juŜ tak silne. Zmiany w bazie wymagają tylko zmian w schemacie, a nie zmian i ponownej kompilacji kodu. Jeśli dodamy do tego wbudowane lub pochodzące od niezaleŜnych firm narzędzia generujące taki schemat z istniejących tablic, to kompletne odwzorowanie danych moŜna uzyskać nawet nie ruszając kodu w Javie! To tylko niektóre z sytuacji, w jakich moŜna wykorzystać połączenie technologii XML Schema i Javy. Tylko przyszłość moŜe pokazać, jak bardzo uŜyteczne będzie to rozwiązanie; w przyszłości XML Schema niemal na pewno zajmie równie waŜne miejsce w warsztacie programisty Javy, co sam XML. Warto juŜ teraz zacząć korzystać ze schematów przy sprawdzaniu poprawności i zawęŜaniu danych, w przyszłości na pewno nie pójdzie to na marne; ponadto kaŜdy programista moŜe przyczynić się do rozwoju tej specyfikacji.

Co dalej? Dodatki. I indeks. I jeszcze trochę informacji o autorze. A dalej pewnie jeszcze oferta innych, świetnych ksiąŜek wydawnictwa O'Reilly. Mówiąc powaŜnie, niniejsza ksiąŜka stanowi potęŜną porcję wiedzy. Poznaną tutaj teorię naleŜy przekładać na praktykę zawodową. Wkrótce Czytelnik stanie się jednym z ekspertów w dziedzinie języka XML i będzie wiedział, jak zwiększyć elastyczność, prostotę konfiguracji i wydajność posiadanych aplikacji. A potem zobaczy, Ŝe takŜe inni (szef, a moŜe nowi szefowie...) doceniają ten nowy zasób wiedzy. śyczę powodzenia!

SAX 2.0

361

A Interfejs API — materiał referencyjny Niniejszy dodatek zawiera krótki materiał referencyjny. Przedstawione są stutaj najwaŜniejsze interfejsy API Javy: SAX, DOM, a takŜe JDOM, omówiony w rozdziale 8. oraz wspomniany w innych częściach ksiąŜki. Rozdział podzielony jest na części opisujące poszczególne interfejsy.

SAX 2.0 SAX 2.0 umoŜliwia sekwencyjną obsługę dokumentu XML. Został przedstawiony w rozdziałach 3. i 5. SAX zawiera interfejsy, które uŜytkownik implementuje w aplikacji i uruchamia jako wywołania następujące w trakcie przetwarzania danych XML. PoniŜej opisane są pakiety SAX, wraz z alfabetycznymi listami klas i interfejsów. W pakiecie org.xml.sax.helpers duŜy odsetek metod w klasach pomocniczych to implementacje interfejsów juŜ zdefiniowanych w podstawowym pakiecie SAX (org.xml.sax). W celu zachowania zwięzłości te zdublowane definicje metod pominięto; zamiast tego wstawiono komentarz mówiący, Ŝe zaimplementowano metody danego interfejsu.

Pakiet org.xml.sax Ten pakiet zawiera podstawowe interfejsy i klasy SAX 2.0. Większość zdefiniowanych interfejsów została zaprojektowana z myślą o implementacji przez nas, programistów Javy; wyjątkiem są właściwe implementacje XMLReader oraz Attributes. Interfejsy te powinny być implementowane przez oprogramowanie do przetwarzania XML, pochodzące od określonego producenta. Oprócz tego w niniejszym pakiecie zdefiniowano szereg wyjątków, jakie mogą zostać zgłoszone przez metody SAX. Niektóre interfejsy stanowią pozostałość po wersjach SAX 1.0 oraz 2.0 alfa i obecnie nie zaleca się korzystania z nich.

AttributeList Ten interfejs został zdefiniowany w SAX 1.0 i obecnie nie zaleca się korzystania z niego. Zamiast niego w implementacjach SAX 2.0 naleŜy uŜywać interfejsu Attributes.

SAX 2.0

362

public interface AttributeList { public public public public public public

abstract abstract abstract abstract abstract abstract

int getLength (); String getName (int i); String getType (int i); String getValue (int i); String getType (String name); String getValue (String name);

}

Attributes Interfejs ten reprezentuje listę atrybutów języka XML. Jest przekazywany do wywołań funkcji związanych z początkiem elementu (startElement() w klasie ContentHanlder) i przypomina w pewnym sensie Vector języka Java. MoŜna uzyskać liczbę reprezentowanych atrybutów, a takŜe ich nazwy w róŜnych postaciach (lokalne, przedrostek przestrzeni nazw i identyfikator URI oraz w postaci „surowej”) oraz wartości. Ponadto dostępne są metody odnajdujące indeks atrybutu po podaniu jego nazwy. Zasadnicza róŜnica pomiędzy tym interfejsem a jego poprzednikiem AttributeList polega na tym, Ŝe Attributes „rozumie” przestrzenie nazw. public interface Attributes { public abstract int getLength (); public abstract String getURI (int index); public abstract String getLocalName (int index); public abstract String getQName (int index); public abstract String getType (int index); public abstract String getValue (int index); public int getIndex (String uri, String localPart); public int getIndex (String qName); public abstract String getType (String uri, String localName); public abstract String getType (String qName); public abstract String getValue (String uri, String localName); public abstract String getValue (String qName); }

ContentHanlder W interfejsie tym zdefiniowano metody operujące na zawartości przetwarzanego dokumentu XML. Zgłaszają one rozpoczęcie i zakończenie przetwarzania (odpowiednio, przed i po wszelkich innych wywołaniach), napotkanie instrukcji przetwarzania oraz encji, które mogą zostać pominięte w parserach nie wykonujących sprawdzania poprawności. Dostępne są równieŜ wywołania dla elementów; w wywołaniach tych brane są pod uwagę przestrzenie nazw. Pełny opis interfejsu moŜna znaleźć w rozdziale 3. public interface ContentHandler { public void setDocumentLocator (Locator locator); public void startDocument () throws SAXException; public void endDocument() throws SAXException; public void startPrefixMapping (String prefix, String uri) throws SAXException; public void endPrefixMapping (String prefix) throws SAXException; public void startElement (String namespaceURI, String localName, String qName, Attributes atts) throws SAXException;

SAX 2.0

363 public void endElement (String namespaceURI, String localName, String qName) throws SAXException; public void characters (char ch[], int start, int length) throws SAXException; public void ignorableWhitespace (char ch[], int start, int length) throws SAXException; public void processingInstruction (String target, String data) throws SAXException; public void skippedEntity (String name) throws SAXException;

}

DocumentHandler Ten interfejs został zdefiniowany w SAX 1.0 i obecnie nie zaleca się korzystania z niego. Zamiast niego w implementacjach SAX 2.0 naleŜy uŜywać interfejsu ContentHandler. public interface DocumentHandler { public abstract void setDocumentLocator (Locator locator); public abstract void startDocument () throws SAXException; public abstract void endDocument () throws SAXException; public abstract void startElement (String name, AttributeList atts) throws SAXException; public abstract void endElement (String name) throws SAXException; public abstract void characters (char ch[], int start, int length) throws SAXException; public abstract void ignorableWhitespace (char ch[], int start, int length) throws SAXException; public abstract void processingInstruction (String target, String data) throws SAXException; }

DTDHandler W interfejsie tym zdefiniowano funkcje wywoływane w czasie przetwarzania definicji DTD. Interfejs ten nie udostępnia informacji o zawęŜeniach określonych w DTD, ale o odwołaniach do nieprzetworzonych encji i deklaracji NOTATION, czyli wskazuje na obiekty stanowiące nieprzetworzone dane. Pełny opis interfejsu znajduje się w rozdziale 5. public interface DTDHandler { public abstract void notationDecl (String name, String publicId, String systemId) throws SAXException; public abstract void unparsedEntityDecl (String name, String publicId, String systemId, String notationName) throws SAXException; }

EntityResolver Interfejs ten umoŜliwia obsługę zewnętrznych encji z poziomu aplikacji, np. gdy w dokumencie XML znajduje się odwołanie do definicji DTD czy arkusza stylu. Po zaimplementowaniu tego

SAX 2.0

364

interfejsu moŜliwe jest zwrócenie do programu wywołującego zmodyfikowanego lub nawet całkowicie innego obiektu SAX InputSource. Ponadto, jeśli dla określonego identyfikatora systemowego powinno zostać otwarte zwykłe połączenie URI, zwracana jest wartość null. public interface EntityResolver { public abstract InputSource resolveEntity (String publicId, String systemId) throws SAXException, IOException; }

ErrorHandler Interfejs ten umoŜliwia określenie, jak ma się zachować aplikacja po napotkaniu jednego z trzech błędów, jakie mogą być zgłoszone w trakcie przetwarzania kodu XML. KaŜda z metod otrzymuje wyjątek SAXParseException, wskazujący, jaki problem spowodował wywołanie. Interfejs zgłasza wyjątek SAXException, oznaczający sytuację, w której dalsze przetwarzanie nie jest moŜliwe. Pełny opis interfejsu zamieszczono w rozdziałach 3 i 5. public interface ErrorHandler { public abstract void warning (SAXParseException exception) throws SAXException; public abstract void error (SAXParseException exception) throws SAXException; public abstract void fatalError (SAXParseException exception) throws SAXException; }

HandlerBase Ta klasa pomocnicza udostępnia puste implementacje wszystkich podstawowych interfejsów procedur obsługi SAX 1.0. MoŜna ją rozszerzyć tak, by umoŜliwiała szybkie dodawanie procedur obsługi poprzez „nadpisywanie” metod kodem specyficznym dla danej aplikacji. Tak klasa została zdefiniowana w SAX 1.0 i obecnie nie zaleca się korzystania z niej. Zamiast niej w implementacjach SAX 2.0 naleŜy uŜywać klasy org.xml.sax.helpers.DefaultHandler. public class HandlerBase implements EntityResolver, DTDHandler, DocumentHandler, ErrorHandler { // implementacja EntityResolver public InputSource resolveEntity (String publicId, String systemId); //implementacja DTDHandler public void notationDecl (String name, String publicId, String systemId); public void unparsedEntityDecl (String name, String publicId, String systemId, String notationName); // implementacja DocumentHandler public void setDocumentLocator (Locator locator); public void startDocument () throws SAXException; public void endDocument () throws SAXException; public void startElement (String name, AttributeList attributes) throws SAXException; public void endElement (String name) throws SAXException;

SAX 2.0

365 public void characters (char ch[], int start, int length) throws SAXException; public void ignorableWhitespace (char ch[], int start, int length) throws SAXException; public void processingInstruction (String target, String data) throws SAXException; // implementacja ErrorHandler public void warning (SAXParseException e) throws SAXException; public void error (SAXParseException e) throws SAXException; public void fatalError (SAXParseException e) throws SAXException;

}

InputSource Ta klasa pełni rolę „kapsułki” zawierającej wszystkie informacje o zasobie wykorzystywanym w przetwarzaniu kodu XML. MoŜe to być po prostu obiekt String lub InputStream, ale moŜe to być takŜe obiekt bardzo złoŜony, np. encja zawierająca identyfikator publiczny i systemowy czy identyfikator URI określający publiczną definicję DTD. Klasy tej powinno się uŜywać jako „opakowania” danych wejściowych przekazywanych do parsera SAX. public class InputSource { public InputSource (); public InputSource (String systemId); public InputSource (InputStream byteStream); public InputSource (Reader characterStream); public void setPublicId (String publicId); public String getPublicId (); public void setSystemId (String systemId); public String getSystemId (); public void setByteStream (InputStream byteStream); public InputStream getByteStream (); public void setEncoding (String encoding); public void setCharacterStream (Reader characterStream); public Reader getCharacterStream (); }

Locator Klasa ta stanowi uzupełnienie dokumentu XML lub innej przetwarzanej konstrukcji. Udostępnia identyfikator systemowy i publiczny dokumentu oraz informacje o tym, w którym miejscu pliku ma miejsce przetwarzanie w danej chwili. Klasa szczególnie przydaje się w aplikacjach typu IDE oraz do określania, w którym momencie przetwarzania występują błędy. Pełny opis tego interfejsu znajduje się w rozdziale 3. public interface Locator { public abstract String getPublicId (); public abstract String getSystemId (); public abstract int getLineNumber (); public abstract int getColumnNumber (); }

Parser Ten interfejs został zdefiniowany w SAX 1.0 i obecnie nie zaleca się korzystania z niego. Zamiast niego w implementacjach SAX 2.0 naleŜy uŜywać interfejsu XMLReader.

SAX 2.0

366

public interface Parser { public abstract void setLocale (Locale locale) throws SAXException; public abstract void setEntityResolver (EntityResolver resolver); public abstract void setDTDHandler (DTDHandler handler); public abstract void setDocumentHandler (DocumentHandler handler); public abstract void setErrorHandler (ErrorHandler handler); public abstract void parse (InputSource source) throws SAXException, IOException; public abstract void parse (String systemId) throws SAXException, IOException; }

SAXException Podstawowy wyjątek zgłaszany przez wywołania SAX i implementacje parsera. PoniewaŜ często zgłaszany jest w wyniku zgłoszenia innych wyjątków, posiada konstruktor pozwalający na przekazanie wyjątku Exception „niŜszego poziomu” oraz metody umoŜliwiające pobranie informacji o tym wyjątku. Zawiera równieŜ klasę podstawową dla wszystkich innych klas SAX Exception. public class SAXException extends Exception { public SAXException (String message); public SAXException (Exception e); public SAXException (String message, Exception e); public String getMessage (); public Exception getException (); public String toString (); }

SAXNotRecognizedException Klasa ta umoŜliwia zgłaszanie przez implementację XMLReader wyjątku informującego, Ŝe otrzymany identyfikator nie został rozpoznany. Jest to sytuacja najbardziej typowa w metodach setProperty() oraz setFeature() (oraz ich odpowiednikach w postaci akcesorów) i oznacza, Ŝe otrzymano identyfikator URI, o którym parser nie posiada Ŝadnych informacji. public class SAXNotRecognizedException extends SAXException { public SAXNotRecognizedException (String message); }

SAXNotSupportedException Klasa ta umoŜliwia zgłaszanie przez implementację XMLReader wyjątku informującego, Ŝe otrzymany identyfikator został rozpoznany, ale nie jest obsługiwany. Jest to sytuacja najbardziej typowa w metodach setProperty() oraz setFeature() (oraz ich odpowiednikach w postaci akcesorów) i oznacza, Ŝe otrzymano identyfikator URI, który nie jest obsługiwany. public class SAXNotSupportedException extends SAXException { public SAXNotSupportedException (String message); }

SAXParseException Klasa ta reprezentuje wyjątki, jakie mogą zostać zgłoszone w czasie procesu przetwarzania. Informacje o miejscu wystąpienia błędu w dokumencie XML są dostępne poprzez akcesory tej klasy. Zaleca się dostarczanie tej informacji do klasy poprzez Locator, ale wiersz i kolumnę, w której wystąpiły problemy, moŜna zgłosić bezpośrednio przez przeładowane konstruktory. Identyfikato-

SAX 2.0

367

ry: systemowy i publiczny dokumentu, w którym wystąpiły problemy, są takŜe udostępniane na róŜne sposoby poprzez konstruktory. public class SAXParseException extends SAXException { public SAXParseException (String message, Locator locator); public SAXParseException (String message, Locator locator, Exception e); public SAXParseException (String message, String publicId, String systemId, int lineNumber, int columnNumber); public SAXParseException (String message, String publicId, String systemId, int lineNumber, int columnNumber, Exception e); public String getPublicId (); public String getSystemId (); public int getLineNumber (); public int getColumnNumber (); }

XMLFilter Jest to klasa analogiczna do XMLReader, jednak uzyskuje informacje o zdarzeniach z innej klasy XMLReader, a nie ze statycznego dokumentu czy zasobu sieciowego. Filtry tego typu moŜna równieŜ łączyć w łańcuchy. Klasa słuŜy głównie do modyfikacji wyjścia z interfejsu XMLReader znajdującego się „na niŜszym poziomie” i do odfiltrowania danych zgłaszanych metodom, jeszcze zanim informacje o tych danych otrzyma aplikacja. public interface XMLFilter extends XMLReader { public abstract void setParent (XMLReader parent); public abstract XMLReader getParent (); }

XMLReader Podstawowy interfejs definiujący sposób przetwarzania SAX 2.0. Oprogramowanie do przetwarzania danych XML dowolnego producenta musi zawierać przynajmniej jedną implementację tego interfejsu. Interfejs ten zastępuje Parser z SAX 1.0; względem swojego poprzednika został wzbogacony o obsługę przestrzeni nazw w elementach i atrybutach dokumentu. Za jego pomocą odbywa się przetwarzanie (poprzez pobranie jako parametru wejściowego identyfikatora systemowego lub obiektu InputSource); interfejs ten umoŜliwia równieŜ zarejestrowanie róŜnych procedur obsługi dostępnych w ramach SAX 2.0. Poprzez ten interfejs zostają takŜe odpowiednio ustawione funkcje i właściwości udostępniane implementacji parsera SAX. Pełny opis interfejsu moŜna znaleźć w rozdziale 3., a pełną listę podstawowych funkcji i właściwości SAX – w dodatku B. public interface XMLReader { public boolean getFeature (String name) throws SAXNotRecognizedException, SAXNotSupportedException; public void setFeature (String name, boolean value) throws SAXNotRecognizedException, SAXNotSupportedException; public Object getProperty (String name) throws SAXNotRecognizedException, SAXNotSupportedException; public void setProperty (String name, Object value) throws SAXNotRecognizedException, SAXNotSupportedException; public void setEntityResolver (EntityResolver resolver); public EntityResolver getEntityResolver (); public void setDTDHandler (DTDHandler handler); public DTDHandler getDTDHandler ();

SAX 2.0

368 public void setContentHandler (ContentHandler handler); public ContentHandler getContentHandler (); public void setErrorHandler (ErrorHandler handler); public ErrorHandler getErrorHandler (); public void parse (InputSource input) throws IOException, SAXException; public void parse (String systemId) throws IOException, SAXException;

}

Pakiet org.xml.sax.ext Ten pakiet zawiera rozszerzenia podstawowych klas i interfejsów SAX. Zdefiniowano tutaj w szczególności dodatkowe procedury obsługi odpowiadające mniej typowym zdarzeniom w procesie przetwarzania SAX. Od implementacji XMLReader nie wymaga się obsługi tych dodatkowych procedur obsługi.

DeclHandler Interfejs ten definiuje wywołania zwracające specyficzne informacje o deklaracjach DTD. Definicje elementów i atrybutów powodują wywołanie odpowiednich metod z parametrami w postaci nazw napotkanych obiektów (w przypadku atrybutów podawany jest takŜe parametr w postaci nazwy elementu, do którego atrybut przynaleŜy); przekazywana jest równieŜ informacja o zawęŜeniach. W przypadku atrybutów przekazywane informacje są bardzo zwięzłe; w przypadku elementów jest to tylko String zawierający zawęŜony model w postaci czystego tekstu. Ponadto w interfejsie tym zdefiniowano metody powiadamiające o wewnętrznych i zewnętrznych encjach. public interface DeclHandler { public abstract void elementDecl (String name, String model) throws SAXException; public abstract void attributeDecl (String eName, String aName, String type, String valueDefault, String value) throws SAXException; public abstract void internalEntityDecl (String name, String value) throws SAXException; public abstract void externalEntityDecl (String name, String publicId, String systemId) throws SAXException; }

LexicalHandler W tym interfejsie zdefiniowano wywołania związane z róŜnymi zdarzeniami na poziomie dokumentu, związanymi z przetwarzaniem, ale nie wpływającymi na dane wynikowe. Wywołania tego interfejsu uruchamiane będą na przykład w czasie obsługi deklaracji DTD, komentarzy i encji. Ponadto sygnalizowany jest początek i koniec sekcji CDATA (choć zgłaszane dane będą zawsze takie same). public interface LexicalHandler { public abstract void startDTD (String name, String publicId, String systemId)

SAX 2.0

369 throws SAXException; public abstract void endDTD () throws SAXException; public abstract void endEntity (String name) throws SAXException; public abstract void startCDATA () throws SAXException; public abstract void endCDATA () throws SAXException; public abstract void comment (char ch[], int start, int length) throws SAXException;

}

Pakiet org.xml.sax.helpers Ten pakiet zawiera rozszerzenia podstawowych klas i interfejsów SAX. Zdefiniowano tutaj w szczególności dodatkowe procedury obsługi odpowiadające mniej typowym zdarzeniom w procesie przetwarzania SAX. Od implementacji XMLReader nie wymaga się obsługi tych dodatkowych procedur obsługi.

AttributeListImpl Jest to domyślna implementacja interfejsu org.xml.sax.AttributeList. Nie zaleca się jej stosowania w SAX 2.0. UmoŜliwia dodawanie i usuwanie atrybutów oraz czyszczenie listy atrybutów. public class AttributeListImpl implements AttributeList { public AttributeListImpl (); public AttributeListImpl (AttributeList atts); // Implementacja interfejsu AttributeList // Dodatkowe metody public void setAttributeList (AttributeList atts); public void addAttribute (String name, String type, String value); public void removeAttribute (String name); public void clear (); }

AttributesImpl Domyślna implementacja interfejsu org.xml.sax.Attributes. UmoŜliwia dodawanie i usuwanie atrybutów oraz czyszczenie listy atrybutów. public class AttributesImpl implements Attributes { public AttributesImpl (); public AttributesImpl (Attributes atts);

// Implementacja interfejsu Attributes // Dodatkowe metody public void addAttribute (String uri, String localName, String qName, String type, String value); public void setAttribute (int index, String uri, String localName, String qName, String type, String value); public void clear (); }

SAX 2.0

370

DefaultHandler Ta klasa pomocnicza zawiera puste implementacje wszystkich podstawowych interfejsów procedur obsługi SAX 2.0. MoŜe zostać tak rozszerzona, aby umoŜliwić szybkie dodawanie procedur obsługi poprzez „nadpisywanie” metod kodem specyficznym dla danej aplikacji. Klasa ta zastępuje klasę org.xml.sax.HandlerBase z interfejsu SAX 1.0. public class DefaultHandler implements EntityResolver, DTDHandler, ContentHandler, ErrorHandler { // (Pusta) implementacja interfejsu EntityResolver // (Pusta) implementacja interfejsu DTDHandler // (Pusta) implementacja interfejsu ContentHandler // (Pusta) implementacja interfejsu ErrorHandler }

LocatorImpl Domyślna implementacja interfejsu org.xml.sax.Locator. UmoŜliwia równieŜ bezpośrednie ustawienie numerów wiersza i kolumny. public class LocatorImpl implements Locator { public LocatorImpl (); public LocatorImpl (Locator locator); // Implementacja interfejsu Locator // Dodatkowe metody public void setPublicId (String publicId); public void setSystemId (String systemId); public void setLineNumber (int lineNumber); public void setColumnNumber (int columnNumber); }

NamespaceSupport Ta klasa stanowi „kapsułkę” obejmującą wszystkie czynności wykonywane na przestrzeniach nazw. Dzięki niej w aplikacjach nie trzeba samodzielnie obsługiwać przestrzeni nazw, chyba Ŝe jest to konieczne ze względu na wydajność. Konteksty przestrzeni nazw mogą być obsługiwane poprzez „stos”. MoŜliwe jest równieŜ uzyskiwanie odpowiedników nazw dokumentu XML 1.0, opatrzonych przedrostkami zawierającymi przestrzenie nazw. public class NamespaceSupport { public NamespaceSupport (); public void reset (); public void pushContext (); public void popContext (); public boolean declarePrefix (String prefix, String uri); public String [] processName (String qName, String parts[], boolean isAttribute); public String getURI (String prefix); public Enumeration getPrefixes (String prefix); public Enumeration getDeclaredPrefixes (); }

SAX 2.0

371

ParserAdapter Ta klasa pomocnicza stanowi „opakowanie” implementacji SAX 1.0 Parser i powoduje, Ŝe zachowuje się ona jak implementacja 2.0 XMLReader (obsługuje przestrzenie nazw). Jedyna metoda, która nie będzie zachowywała się „zwyczajnie”, to skippedEntity() z interfejsu ContentHandler(); nigdy nie zostanie ona nawet wywołana. public class ParserAdapter implements XMLReader, DocumentHandler {; public ParserAdapter () throws SAXException; public ParserAdapter (Parser parser); // Implementacja interfejsu XMLReader // Implementacja interfejsu DocumentHandler }

ParserFactory Zawiera metody dynamicznie tworzące egzemplarz implementacji Parser po podaniu określonej nazwy klasy lub — jeśli nazwy nie podano — z właściwości systemowej „org.xml.sax.driver”. public class ParserFactory { public static Parser makeParser () throws ClassNotFoundException, IllegalAccessException, InstantiationException, NullPointerException, ClassCastException; public static Parser makeParser (String className) throws ClassNotFoundException, IllegalAccessException, InstantiationException, ClassCastException; }

XMLFilterImpl Domyślna implementacja interfejsu org.xml.sax.XMLFilter. public class XMLFilterImpl implements XMLFilter, EntityResolver, DTDHandler, ContentHandler, ErrorHandler { public XMLFilterImpl (); public XMLFilterImpl (XMLReader parent); // Implementacja interfejsu XMLFilter // Implementacja interfejsu XMLReader // Implementacja interfejsu EntityResolver // Implementacja interfejsu DTDHandler // Implementacja interfejsu ContentHandler // Implementacja interfejsu ErrorHandler }

DOM Level 2

372

XMLReaderAdapter Ta klasa pomocnicza pełni rolę „opakowania” implementacji SAX 2.0 XMLReader, powodując, Ŝe zachowuje się ona jak implementacja 1.0 Parser (brak obsługi przestrzeni nazw). Funkcja przestrzeni nazw (http://xml.org/sax/features/namespace) musi być obsługiwana; w przeciwnym razie w czasie przetwarzania wystąpią błędy. public class XMLReaderAdapter implements Parser, ContentHandler { public XMLReaderAdapter () throws SAXException; public XMLReaderAdapter (XMLReader xmlReader); // Implementacja interfejsu Parser // Implementacja interfejsu ContentHandler }

XMLReaderFactory Zawiera metody dynamicznie tworzące egzemplarz implementacji XMLReader po podaniu określonej nazwy klasy lub — jeśli nazwy nie podano — z właściwości systemowej „org.xml.sax.driver”. final public class XMLReaderFactory { public static XMLReader createXMLReader () throws SAXException; public static XMLReader createXMLReader (String className) throws SAXException; }

DOM Level 2 Interfejs DOM opracowany przez konsorcjum W3C słuŜy do budowania w pamięci pełnej reprezentacji dokumentu XML. UŜytkownikowi oferuje szczegółowe informacje o strukturze dokumentu po jego całkowitym przetworzeniu. KrąŜą plotki, Ŝe DOM Level 3 będzie definiował interfejs pozwalający na uzyskanie obiektu DOM Document; obecnie mechanizm taki nie istnieje w modelu DOM. Podobnie jak w interfejsie SAX, na większą część pakietu DOM składają się interfejsy definiujące struktury wewnątrz dokumentu XML oraz odwzorowujące je na język Java (te same odwzorowania stosowane są w standardzie CORBA, w języku JavaScript i innych).

Pakiet org.w3c.dom Pakiet ten zawiera podstawowe interfejsy i klasy DOM Level 2. Zazwyczaj w aplikacji wykorzystywane są implementacje tych interfejsów pochodzące od konkretnego producenta.

Attr Interfejs ten reprezentuje atrybut (lub element) XML w języku Java. UmoŜliwia dostęp do nazwy i wartości atrybutu oraz pozwala na ustawienie jego wartości (na potrzeby mutacji).1 Metoda getSpecified() wskazuje, czy atrybut (oraz jego wartość) został jawnie uŜyty w dokumencie

1

W tej oraz innych metodach z rodziny DOM setXXX() w wyniku próby modyfikacji węzła tylko do odczytu zostaje zgłoszony wyjątek DOMException.

DOM Level 2

373

XML lub czy jego wartość nie została określona, a zamiast tego pobrano wartość domyślną z definicji DTD. Poprzez ten interfejs moŜna takŜe pobrać informacje o elemencie „nadrzędnym”. public interface Attr extends Node { public String getName(); public boolean getSpecified(); public String getValue(); public void setValue(String value) throws DOMException; public Element getOwnerElement(); }

CDATASection W tym interfejsie nie zdefiniowano Ŝadnych metod; dziedziczy on wszystkie metody interfejsu Text. Jednak dzięki jego obecności (a więc równieŜ dzięki istnieniu oddzielnego typu węzła) moŜna dokonać rozróŜnienia pomiędzy tekstem w sekcjach XML CDATA a zwykłym tekstem w elemencie (nie znajdującym się w takiej sekcji). public interface CDATASection extends Text { }

CharacterData Jest to interfejs „nadrzędny” względem wszystkich typów Node modelu DOM (Text, Comment i — pośrednio — CDATASection). Zdefiniowano w nim metody pozwalające na uzyskanie dostępu do węzła tekstowego i ustawienie jego wartości. Są tu równieŜ metody umoŜliwiające operowanie na danych tekstowych bezpośrednio (jako na znakach) — pozwalają uzyskać długość łańcucha, dopisać, wstawić i usunąć dane albo zamienić wszystkie lub część znaków na inne. Wszystkie te metody zgłaszają wyjątek DOMException, jeśli węzeł jest tylko do odczytu. public interface CharacterData extends Node { public String getData() throws DOMException; public void setData(String data) throws DOMException; public int getLength(); public String substringData(int offset, int count) throws DOMException; public void appendData(String arg) throws DOMException; public void insertData(int offset, String arg) throws DOMException; public void deleteData(int offset, int count) throws DOMException; public void replaceData(int offset, int count, String arg) throws DOMException; }

DOM Level 2

374

Comment Interfejs ten umoŜliwia uzyskanie w języku Java reprezentacji komentarza XML. Podobnie jak CDATASection, sam nie zawiera Ŝadnych metod, ale pozwala na rozróŜnienie (na podstawie typu interfejsu) pomiędzy tekstem a komentarzami w dokumencie XML. public interface Comment extends CharacterData { }

Document Interfejs ten reprezentuje w modelu DOM kompletny dokument XML. UmoŜliwia równieŜ tworzenie nowych elementów, atrybutów, instrukcji przetwarzania oraz elementów XML. Pozwala nie tylko uzyskać informacje o deklaracji DTD (getDocType()) oraz elemencie głównym (getDocumentElement()), ale takŜe przeszukiwać drzewo dokumentu pod kątem wystąpienia konkretnego elementu (getElementByTagName()). PoniewaŜ model DOM wymaga dowiązania wszystkich implementacji Node do obiektu Document, interfejs ten pozwala tworzyć róŜne typy węzłów Node DOM. KaŜda metoda z serii createXXX() posiada swój odpowiednik obsługujący przestrzenie nazw (createXXXNS()). Ponadto moŜliwe jest importowanie węzłów do obiektu Document za pomocą metody importNode(); wartość boolean wskazuje, czy elementy potomne zaimportowanego węzła Node powinny równieŜ zostać rekurencyjnie zaimportowane. public interface Document extends Node { public DocumentType getDoctype(); public DOMImplementation getImplementation(); public Element getDocumentElement(); public Element createElement(String tagName) throws DOMException; public DocumentFragment createDocumentFragment(); public Text createTextNode(String data); public Comment createComment(String data); public CDATASection createCDATASection(String data) throws DOMException; public ProcessingInstruction createProcessingInstruction(String target, String data) throws DOMException; public Attr createAttribute(String name) throws DOMException; public EntityReference createEntityReference(String name) throws DOMException; public NodeList getElementsByTagName(String tagname); public Node importNode(Node importedNode, boolean deep) throws DOMException; public Element createElementNS(String namespaceURI, String qualifiedName) throws DOMException; public Attr createAttributeNS(String namespaceURI, String qualifiedName) throws DOMException; public NodeList getElementsByTagNameNS(String namespaceURI, String localName); public Element getElementById(String elementId); }

DOM Level 2

375

DocumentFragment Ten interfejs jednorazowo umoŜliwia operowanie tylko na fragmencie obiektu Document. SłuŜy do manipulacji częściami drzewa DOM bez konieczności przechowywania całego dokumentu w pamięci. public interface DocumentFragment extends Node { }

DocumentType Ten interfejs reprezentuje deklarację DOCTYPE w dokumencie XML. W tym przypadku nazwą (Name) jest nazwa elementu występującego zaraz po łańcuchu
DOMException Poprzez tę klasę interfejsy DOM zgłaszają wyjątek Exception w przypadku wystąpienia błędów. W klasie tej opisano równieŜ zestaw kodów błędów odpowiadających róŜnym problemom, jakie mogą wystąpić w czasie korzystania z modelu DOM i spowodować zgłoszenie wyjątku Exception. public class DOMException extends RuntimeException { public DOMException(short code, String message); // Kody wyjątków public static final public static final public static final public static final public static final public static final public static final public static final public static final public static final public static final public static final public static final public static final public static final

short short short short short short short short short short short short short short short

INDEX_SIZE_ERR; DOMSTRING_SIZE_ERR; HIERARCHY_REQUEST_ERR; WRONG_DOCUMENT_ERR; INVALID_CHARACTER_ERR; NO_DATA_ALLOWED_ERR; NO_MODIFICATION_ALLOWED_ERR; NOT_FOUND_ERR; NOT_SUPPORTED_ERR; INUSE_ATTRIBUTE_ERR; INVALID_STATE_ERR; SYNTAX_ERR; INVALID_MODIFICATION_ERR; NAMESPACE_ERR; INVALID_ACCESS_ERR;

}

DOMImplementation Interfejs ten stanowi standardowy „punkt wyjścia”, poprzez który zostaje udostępniona implementacja DOM określonego producenta. UmoŜliwia utworzenie w tej implementacji obiektów Do-

DOM Level 2

376

cumentType oraz Document.2 Pozwala takŜe na odpytanie implementacji (za pomocą metody hasFeature()) odnośnie obsługi określonej funkcji. public interface DOMImplementation { public boolean hasFeature(String feature, String version); public DocumentType createDocumentType(String String String throws

qualifiedName, publicId, systemId) DOMException;

public Document createDocument(String namespaceURI, String qualifiedName, DocumentType doctype) throws DOMException; }

Element Interfejs ten reprezentuje w języku Java element XML. Udostępnia metody pozwalające na uzyskanie nazwy i atrybutów elementu, a takŜe na ustawienie tych wartości. Oferuje takŜe róŜne sposoby uzyskania dostępu do atrybutów XML, włącznie z metodami getXXX() i setXXX() w wersjach z obsługą przestrzeni nazw. public interface Element extends Node { public String getTagName(); public String getAttribute(String name); public void setAttribute(String name, String value) throws DOMException; public void removeAttribute(String name) throws DOMException; public Attr getAttributeNode(String name); public Attr setAttributeNode(Attr newAttr) throws DOMException; public Attr removeAttributeNode(Attr oldAttr) throws DOMException; public NodeList getElementsByTagName(String name); public String getAttributeNS(String namespaceURI, String localName); public void setAttributeNS(String namespaceURI, String qualifiedName, String value) throws DOMException; public void removeAttributeNS(String namespaceURI, String localName) throws DOMException; public Attr getAttributeNodeNS(String namespaceURI, String localName); public Attr setAttributeNodeNS(Attr newAttr) throws DOMException; public NodeList getElementsByTagNameNS(String namespaceURI, String localName);

2

Niestety, aby uzyskać egzemplarz DOMImplementation, trzeba posiadać obiekt Document i wykonać metodę getDOMImplementation(), ewentualnie bezpośrednio załadować klasy danego producenta. Powstaje więc często problem „jajka i kury”; alternatywny sposób wykonania tego zadania znaleźć moŜna w opisach interfejsu JDOM (w rozdziale 8. oraz w dalszej części tego dodatku).

DOM Level 2

377

public boolean hasAttribute(String name); public boolean hasAttributeNS(String namespaceURI, String localName); }

Entity Interfejs reprezentujący w języku Java encję (przetworzoną lub nie). Odpowiednie akcesory umoŜliwiają uzyskanie dostępu do identyfikatorów — systemowego i publicznego, oraz do zapisu encji (pobranej z DTD). public interface Entity extends Node { public String getPublicId(); public String getSystemId(); public String getNotationName(); }

EntityReference Interfejs reprezentujący wartość powstałą w wyniku „przetłumaczenia” encji. Zakłada się, Ŝe przed wykorzystaniem interfejsu przez aplikację encje (znakowa lub definiowana przez uŜytkownika) juŜ wystąpiły w dokumencie. public interface EntityReference extends Node { }

NamedNodeMap W tym interfejsie zdefiniowano listę podobną do NodeList, ale wymagającą, aby kaŜdy naleŜący do niej węzeł Node był nazwany (czyli był np. obiektem Element lub Attr). Dzięki temu wymogowi moŜliwe było udostępnienie metod do pobierania pozycji z listy właśnie poprzez nazwę (z lub bez przestrzeni nazw). Poprzez listę moŜna takŜe usuwać lub modyfikować poszczególne obiekty. Wszystkie te metody zgłaszają DOMException, jeśli określony węzeł jest tylko do odczytu. public interface NamedNodeMap { public Node getNamedItem(String name); public Node setNamedItem(Node arg) throws DOMException; public Node removeNamedItem(String name) throws DOMException; public Node item(int index); public int getLength(); public Node getNamedItemNS(String namespaceURI, String localName); public Node setNamedItemNS(Node arg) throws DOMException; public Node removeNamedItemNS(String namespaceURI, String localName) throws DOMException; }

DOM Level 2

378

Node Centralny interfejs wszystkich obiektów DOM. Oferuje szeroki zestaw metod udostępniających informacje o węźle Node drzewa modelu DOM. UmoŜliwia takŜe obsługę elementów potomnych tego węzła (o ile takie istnieją). Działania większości metod nie trzeba właściwie wyjaśniać, natomiast na cechy niektórych z nich warto zwrócić uwagę: getAttributes() zwraca dane inne niŜ null tylko wtedy, gdy węzeł Node to Element; cloneNode() pozwala na „płytkie” lub „głębokie” kopiowanie węzła Node; normalize() przenosi cały tekst do nieprzystających węzłów Text (Ŝadne dwa węzły Text nie mogą być przystające; wszystkie „przetłumaczone” encje tekstowe są konsolidowane do postaci węzłów Text); zaś supports() oferuje informacje o funkcjach udostępnianych przez Node. Są tu równieŜ metody obsługujące przestrzenie nazw (getNamespaceURI(), getPrefix() oraz getLocalName()).Ponadto, zdefiniowano tutaj stałe określające typ węzła (porównuje się je z wartością zwróconą przez getNodeType()). public interface Node { public String getNodeName(); public String getNodeValue() throws DOMException; public void setNodeValue(String nodeValue) throws DOMException; public public public public public public public public public public

public

public public public public public public public public public public public

short getNodeType(); Node getParentNode(); NodeList getChildNodes(); Node getFirstChild(); Node getLastChild(); Node getPreviousSibling(); Node getNextSibling(); NamedNodeMap getAttributes(); Document getOwnerDocument(); Node insertBefore(Node newChild, Node refChild) throws DOMException; Node replaceChild(Node newChild, Node oldChild) throws DOMException; Node removeChild(Node oldChild) throws DOMException; Node appendChild(Node newChild) throws DOMException; boolean hasChildNodes(); Node cloneNode(boolean deep); void normalize(); boolean supports(String feature, String version); String getNamespaceURI(); String getPrefix(); void setPrefix(String prefix) throws DOMException; String getLocalName(); boolean hasAttributes();

// Stałe określające typ węzła public static final short ELEMENT_NODE; public static final short ATTRIBUTE_NODE; public static final short TEXT_NODE; public static final short CDATA_SECTION_NODE; public static final short ENTITY_REFERENCE_NODE;

DOM Level 2 public public public public public public public

379 static static static static static static static

final final final final final final final

short short short short short short short

ENTITY_NODE; PROCESSING_INSTRUCTION_NODE; COMMENT_NODE; DOCUMENT_NODE; DOCUMENT_TYPE_NODE; DOCUMENT_FRAGMENT_NODE; NOTATION_NODE;

}

NodeList Interfejs ten jest strukturą DOM analogiczną do struktur Vector lub List w języku Java. Jest to typ wartości zwracanej przez kaŜdą metodę, która udostępnia jednocześnie wiele implementacji Node. MoŜliwa jest iteracja po pozycjach listy oraz pobieranie węzła Node według indeksu. public interface NodeList { public Node item(int index); public int getLength(); }

Notation Interfejs ten reprezentuje konstrukcję NOTATION występującą w definicji DTD i słuŜącą do deklarowania nieprzetworzonej encji lub instrukcji przetwarzania (PI). Udostępnia identyfikatory publiczny i systemowy, znajdujące się w deklaracji. W obu przypadkach, jeśli identyfikatory nie są obecne, zwracana jest wartość null. public interface Notation extends Node { public String getPublicId(); public String getSystemId(); }

ProcessingInstruction Interfejs ten reprezentuje instrukcję przetwarzania (PI). Oferuje metody słuŜące do pobrania obiektu docelowego (ang. target) oraz danych instrukcji. Nie ma moŜliwości uzyskania dostępu do indywidualnych par nazwa-wartość w instrukcji. Istnieje moŜliwość ustawiania danych w PI: public interface ProcessingInstruction extends Node { public String getTarget(); public String getData(); public void setData(String data) throws DOMException; }

Text Ten interfejs stanowi reprezentację danych tekstowych elementu XML w języku Java. Do metod zdefiniowanych w klasie CharacterData dodaje tylko jedną, rozdzielającą dany węzeł na dwa oddzielne. Pierwotny węzeł Text będzie zawierał tylko tekst do pewnego (określonego przez programistę) miejsca; pozostały tekst zostanie zwrócony jako wynik działania metody w postaci nowego węzła Text. Podobnie jak w innych metodach dokonujących mutacji, jeśli węzeł jest tylko do odczytu, zostanie zgłoszony wyjątek DOMException.

JAXP 1.0

380

public interface Text extends CharacterData { public Text splitText(int offset) throws DOMException; }

JAXP 1.0 JAXP stanowi abstrakcyjną warstwę, poprzez którą pobierana jest implementacja parsera SAX lub DOM określonego producenta. Obecnie JAXP obsługuje tylko implementacje parserów SAX 1.0 oraz DOM Level 1.

Pakiet javax.xml.parsers Jest to jedyny pakiet JAXP. Zawiera klasy konieczne do stworzenia abstrakcyjnej warstwy JAXP.

DocumentBuilder Klasa ta stanowi „opakowanie” wykorzystywanej klasy implementacji parsera. Pozwala na przetwarzanie dokumentu XML w sposób niezaleŜny od producenta klasy. public abstract class DocumentBuilder { public Document parse(InputStream stream) throws SAXException, IOException, IllegalArgumentException; public Document parse(String uri) throws SAXException, IOException, IllegalArgumentException; public Document parse(File file) throws SAXException, IOException, IllegalArgumentException; public abstract Document parse(InputSource is) throws SAXException, IOException, IllegalArgumentException; public abstract boolean isNamespaceAware(); public abstract boolean isValidating(); public abstract void setEntityResolver(EntityResolver er); public abstract void setErrorHandler(ErrorHandler eh); public abstract Document newDocument(); }

DocumentBuilderFactory Ta klasa słuŜy do tworzenia egzemplarzy klasy DocumentBuilder. Przy jej tworzeniu moŜliwe jest włączenie lub wyłączenie obsługi przestrzeni nazw oraz sprawdzania poprawności. public abstract class DocumentBuilderFactory { protected DocumentBuilderFactory (); public static DocumentBuilderFactory newInstance(); public abstract DocumentBuilder newDocumentBuilder() throws ParserConfigurationException; public void setNamespaceAware(boolean aware); public void setValidating(boolean validating); public boolean isNamespaceAware(); public boolean isValidating(); }

JAXP 1.0

381

FactoryConfigurationException W tej klasie zdefiniowano wyjątek Error zgłaszany w przypadku, gdy nie jest moŜliwe utworzenie egzemplarza klasy. public class FactoryConfigurationError extends Error { public FactoryConfigurationError(); public FactoryConfigurationError(String msg); public FactoryConfigurationError(Exception e); public FactoryConfigurationError(Exception e, String msg); public String getMessage (); public Exception getException (); }

ParserConfigurationException W tej klasie zdefiniowano wyjątek Exception zgłaszany w przypadku, gdy wysyłane jest zgłoszenie pobrania egzemplarza parsera, ale nie jest moŜliwe jego utworzenie przy podanych przez programistę ustawieniach odnośnie obsługi przestrzeni nazw oraz sprawdzania poprawności. public class ParserConfigurationException extends Exception { public ParserConfigurationException(); public ParserConfigurationException(String msg); }

SAXParser Ta klasa stanowi „opakowanie” (interfejs) wykorzystywanej klasy implementacji parsera SAX 1.0 i umoŜliwia przeprowadzenie procesu przetwarzania w sposób niezaleŜny od producenta. public abstract class SAXParser { public void parse(InputStream stream, HandlerBase base) throws SAXException, IOException, IllegalArgumentException; public void parse(String uri, HandlerBase base) throws SAXException, IOException, IllegalArgumentException; public void parse(File file, HandlerBase base) throws SAXException, IOException, IllegalArgumentException; public void parse(InputSource source, HandlerBase base) throws SAXException, IOException, IllegalArgumentException; public abstract org.xml.sax.Parser getParser() throws SAXException; public abstract boolean isNamespaceAware(); public abstract boolean isValidating(); }

SAXParserFactory Ta klasa słuŜy do tworzenia egzemplarzy klasy SAXParser. Przy jej tworzeniu moŜliwe jest włączenie lub wyłączenie obsługi przestrzeni nazw oraz sprawdzania poprawności. public abstract class SAXParserFactory { public static SAXParserFactory newInstance(); public abstract SAXParser newSAXParser() throws ParserConfigurationException, SAXException; public void setNamespaceAware(boolean awareness); public void setValidating(boolean validating); public boolean isNamespaceAware(); public boolean isValidating(); }

JDOM 1.0

382

JDOM 1.0 JDOM 1.0, opisany w rozdziale 8., oferuje pełny wgląd w strukturę drzewiastą dokumentu XML. Model dokumentu jest podobny do tego w standardzie DOM, ale zasady, według których jest budowany, nie są aŜ tak ścisłe. Np. moŜliwe jest, bezpośrednie wpisanie zawartości obiektu Element (a nie poprzez wartość elementu potomnego). JDOM zawiera ponadto konkretne klasy, a nie interfejsy, dzięki czemu moŜliwe jest bezpośrednie tworzenie obiektów (nie poprzez klasę producenta). SAX i DOM są wykorzystywane w interfejsie JDOM jedynie do utworzenia obiektu JDOM Document na podstawie istniejących danych XML. Zostały zdefiniowane w pakiecie org.jdom.input.

Pakiet org.jdom3 Pakiet ten zawiera podstawowe klasy JDOM 1.0. Składają się na nie obiekty XML odwzorowane na język Java oraz zestaw wyjątków zgłaszanych w razie wystąpienia błędów.

Attribute W klasie Attribute zdefiniowano zachowanie atrybutu XML, odwzorowując je na język Java. Udostępniono tutaj metody pozwalające na uzyskanie wartości atrybutu oraz związanych z nim informacji o przestrzeni nazw. MoŜliwe jest utworzenie egzemplarza klasy poprzez podanie nazwy atrybutu i jego wartości lub poprzez obiekt Namespace, nazwę lokalną atrybutu i jego wartość. Udostępniono takŜe metody pomocnicze, słuŜące do automatycznej konwersji typu danych stanowiących wartość atrybutu. public class Attribute { public Attribute(String name, String value); public Attribute(String name, String prefix, String uri, String value); public Attribute(String name, Namespace ns, String value); public String getName(); public String getQualifiedName(); public String getNamespacePrefix(); public Namespace getNamespaceURI(); public String getValue(); public void setValue(String value); // Metody pomocnicze do przeprowadzania konwersji public public public public public public public public public public public public

3

String get StringValue(String default Value); int getIntValue(int defaultValue); int getIntValue() throws DataConversionException; log getLongValue (long defaultValue); long getLongValue() throws DataConversionException; float getFloatValue(float defaultValue); float getFloatValue() throws DataConversionException; double getDoubleValue(double defaultValue); double getDoubleValue() throws DataConversionException; boolean getBooleanValue(boolean defaultValue); boolean getBooleanValue() throws DataConversionException; char getCharValue(char defaultValue);

NaleŜy pamiętać, Ŝe choć interfejs API JDOM jest raczej stabilny, to wciąŜ jest to wersja beta. W czasie przygotowywania tej ksiąŜki do druku w interfejsie tym mogą zostać wprowadzone drobne zmiany. Najnowsze klasy JDOM moŜna znaleźć pod adresem http://www.jdom.org.

JDOM 1.0

383

public char getCharValue() throws DataConversionException; public byte getByteValue(byte defaultValue); public byte getByteValue() throws DataConversionException; }

Comment Comment to prosta reprezentacja komentarza XML. Zawiera tekst znajdujący się wewnątrz komentarza XML. public class Comment { public Comment(String text); public String getText(); public void setText(String text); public String toString(); }

DataConversionException Ten wyjątek zgłaszany jest w przypadku konwersji wartości elementu Attribute lub Element na określony typ. W zgłaszanym komunikacie zawarta jest nazwa przetwarzanego atrybutu oraz typ danych, na który następuje konwersja. Wyjątek ten stanowi podklasę JDOMException, a więc aplikacja wykorzystująca interfejs DOM moŜe przechwycić ten jeden wyjątek i otrzymać wszystkie informacje o błędach. public class DataConversionException extends JDOMException { public DataConversionException(String name, String dataType); }

DocType DocType reprezentuje deklarację DOCTYPE znajdującą się w dokumencie XML. Udostępnia nazwę zawęŜanego elementu oraz identyfikatory — publiczny i systemowy — zewnętrznej definicji DTD (jeśli taka istnieje). public class DocType { public DocType(String elementName, String publicID, String systemID); public DocType(String elementName, String systemID); public DocType(String elementName); public String getElementName(); public String getPublicID(); public DocType setPublicID(String publicID); public String getSystemID(); public DocType setSystemID(String systemID); }

Document Document stanowi odwzorowanie dokumentu XML w języku Java. Jest tworzony tylko poprzez główny element Element, ale zamiast klasy Element moŜna tutaj wykorzystać metodę setRootElement(). Pozwala równieŜ na ustawienie (lub pobranie) wartości DocType oraz listy List instrukcji ProcessingInstruction. Są tutaj takŜe metody pomocnicze, umoŜliwiające dodanie instrukcji przetwarzania do obiektu Document. Metoda getContent() zwraca całą zawartość obiektu Document, wraz z elementem głównym oraz komentarzami.

JDOM 1.0

384

public class Document { public Document(Element rootElement, DocType docType); public Document(Element rootElement); public Element getRootElement() throws NoSuchElementException; public Document setRootElement(Element rootElement); public DocType getDocType(); public Document setDocType(DocType docType); public List getProcessingInstructions(); public List getProcessingInstructions(String target); public ProcessingInstruction getProcessingInstruction(String target) throws NoSuchProcessingInstructionException; public Document addProcessingInstruction(ProcessingInstruction pi); public Document addProcessingInstruction(String target, String data); public Document addProcessingInstruction(String target, Map data); public Document setProcessingInstructions(List processingInstructions); public boolean removeProcessingInstruction( ProcessingInstruction processingInstruction); public boolean removeProcessingInstruction(String target); public boolean removeProcessingInstructions(String target); public Document addComment(Comment comment); public List getMixedContent(); }

Element Element stanowi reprezentację elementu XML w języku Java. W pełni obsługuje przestrzenie nazw, a więc wszystkie metody mogą jako argument przyjmować jedną nazwę elementu oraz opcjonalną informację o przestrzeni nazw. Wynikiem wywołania getContent() jest zawsze String, pusty albo zawierający tekst elementu. Zawartość elementu uwaŜa się za mieszaną (ang. mixed), gdy składają się na nią dane tekstowe i elementy zagnieŜdŜone, a takŜe opcjonalne komentarze, encje i instrukcje przetwarzania. Taką kompletną listę List zawartości elementu moŜna uzyskać poprzez wywołanie metody getMixedContent(). Zawartość tak uzyskanej listy przetwarza się instrukcją instanceof wykonywaną na obiektach String, Element lub Comment. Metody addXXX() zostały tak stworzone, aby programista łączył je ze sobą, a więc wszystkie zwracają zmodyfikowany Element: Element element = new Element(„rodzic”); element.addChild(new Element(„syn”) .addChild(new Element(„wnuk”) .addAttribute(„nazwa”, „wartosc”) .setContent(„Witaj świecie!”)) .addChild(new Element(„drugiSyn”)) );

Taki kod spowodowałby utworzenie następującego fragmentu dokumentu XML: Witaj świecie!

JDOM 1.0

385

Istnieją takŜe metody pomocnicze pozwalające na dodawanie w trybie „inline” atrybutów do elementów (setAttribute(String name, String value)). Podobnie działają metody usuwające obiekty; są równieŜ dostępne odpowiedniki tych metod obsługujące przestrzenie nazw. public class Element { public Element(String name, Namespace namespace); public Element(String name); public Element(String name, String uri); public Element(String name, String prefix, String uri); public String getName(); public String getNamespacePrefix(); public String getNamespaceURI(); public String getQualifiedName(); public String getContent(); public Element setContent(String textContent); public boolean hasMixedContent(); public List getMixedContent(); public Element setMixedContent(List mixedContent); public List getChildren(); public Element setChildren(List children); public List getChildren(String name); public List getChildren(String name, Namespace ns); public Element getChild(String name, Namespace ns) throws NoSuchElementException; public Element addChild(Element element); public Element addChild(ProcessingInstruction pi); public Element addChild(Comment comment); public Element addChild(String s); public boolean removeChild(Element element); public boolean removeChild(Comment comment); public boolean removeChild(String name); public boolean removeChild(String name, Namespace ns); public boolean removeChildren(String name); public boolean removeChildren(String name, Namespace ns); public boolean removeChildren(); public List getAttributes(); public Attribute getAttribute(String name) throws NoSuchAttributeException; public Attribute getAttribute(String name, Namespace ns) throws NoSuchAttributeException; public Element addAttribute(List attributes); public Element addAttribute(Attribute attribute); public Element addAttribute(String name, String value); public boolean removeAttribute(String name, Namespace ns, String value); public boolean removeAttribute(String name); public boolean removeAttribute(String name, Namespace ns); }

JDOMException Jest to podstawowy wyjątek JDOM, stanowiący podklasę wszystkich innych wyjątków. Dostarcza komunikatów o błędach oraz stanowi interfejs do wyjątków niŜszego poziomu, jeśli zachodzi potrzeba ich obsłuŜenia. public class JDOMException extends Exception { public JDOMException(); public JDOMException(String message); public JDOMException(String message, Throwable rootCause); public Throwable getRootCause(); }

JDOM 1.0

386

Namespace Klasa Namespace obsługuje odwzorowania przestrzeni nazw w obiektach JDOM Document. public class Namespace { public static Namespace getNamespaceURI(String uri); public static Namespace getNamespaceURI(String prefix, String uri); public String getProcessingInstruction(); public String getURI(); public boolean isDefault(); }

NoSuchAttributeException Wyjątek zgłaszany w przypadku, gdy określony atrybut nie został znaleziony. Zwracany komunikat zawiera nazwę atrybutu, którego poszukiwano. public class NoSuchAttributeException extends JDOMException { public NoSuchAttributeException(String elementName); }

NoSuchElementException Wyjątek zgłaszany w przypadku, gdy określony element nie został znaleziony. Zwracany komunikat zawiera nazwę elementu, którego poszukiwano. public class NoSuchElementException extends JDOMException { public NoSuchElementException(String elementName); }

NoSuchProcessingInstructionException Wyjątek zgłaszany w przypadku, gdy określona instrukcja przetwarzania nie została znaleziona. Zwracany komunikat zawiera nazwę obiektu docelowego instrukcji, której poszukiwano. public class NoSuchProcessingInstructionException extends JDOMException { public class NoSuchProcessingInstructionException(String target); }

ProcessingInstruction W klasie ProcessingInstruction zdefiniowano zachowanie instrukcji przetwarzania XML, odwzorowane na język Java. Klasa ta umoŜliwia obsługę zarówno obiektu docelowego jako całości, jak i „surowych” danych związanych z tym obiektem. Ponadto, poniewaŜ wiele instrukcji PI zawiera dane w postaci par nazwa-wartość (podobnie jak atrybuty), moŜliwe jest dodawanie i pobieranie takich par. Na przykład, w przypadku instrukcji przetwarzania wywołanie getValue(„type”) na obiekcie ProcessingInstruction reprezentującym tę instrukcję XML spowodowałoby zwrócenie xslt. public class ProcessingInstruction { public ProcessingInstruction(String target, Map data); public ProcessingInstruction(String target, String data); public String getTarget(); public String getData(); public ProcessingInstruction setData(String data); public ProcessingInstruction setData(Map data); public String getValue(String name); public ProcessingInstruction setValue(String name, String value); public boolean removeValue(String name); }

JDOM 1.0

387

Pakiet org.jdom.adapters Pakiet ten zawiera „adaptery” tworzące standardowy interfejs pozwalający na uzyskanie obiektu DOM Document z dowolnego parsera DOM (w tym z parserów DOM Level 1). MoŜliwe jest proste dodanie adaptera dla dowolnego parsera, w którym zachodzi potrzeba uzyskania obsługi interfejsu JDOM.

AbstractDOMAdapter Klasa opisująca domyślne zachowanie określonej wersji metody getDocument(); domyślnie metoda ta pobiera zawartość pliku poprzez „zapuszkowanie” go w obiekcie FileOutputStream i oddelegowanie do getDocument(InputStream). public abstract class AbstractDOMAdapter implements DOMAdapter { public Document getDocument(String filename, boolean validate) throws IOException; public abstract Document getDocument(InputStream in, boolean validate) throws IOException; public abstract Document createDocument() throws IOException; }

DOMAdapter W tej klasie zdefiniowano interfejs, który musi zostać zaimplementowany przez klasy pełniące rolę „adapterów”. Określono tutaj sposób utworzenia obiektu DOM Document po podaniu nazwy pliku lub obiektu InputStream, a takŜe sposób uzyskania nowego, pustego obiektu Document. public interface DOMAdapter { public Document getDocument(String filename, boolean validate) throws IOException; public Document getDocument(InputStream in, boolean validate) throws IOException; public Document createDocument() throws IOException; }

Nie opisano tutaj specyficznych klas „adapterów”, poniewaŜ mogą one ulec zmianie w czasie przygotowywania tej ksiąŜki do publikacji. W czasie pisania ksiąŜki dostępne były następujące działające „adaptery” dla następujących parserów: • Oracle Version 1 XML Parser • Oracle Version 2 XML Parser • Sun Project X Parser (teraz takŜe dla powstałego na jego bazie parsera Crimson — przyp. tłum.) • Apache Xerces Parser • IBM XML4J Parser

Pakiet org.jdom.input W tym pakiecie zdefiniowano interfejs słuŜący do budowania obiektu JDOM Document. MoŜliwe jest dodawanie nowych implementacji Builder dla innych interfejsów XML API lub dla nowych implementacji parserów (np. takich, w których odczyt całego dokumentu będzie odbywał się dopiero wtedy, gdy zaŜąda tego uŜytkownik).

JDOM 1.0

388

AbstractBuilder Ta podstawowa implementacja klasy Builder słuŜy do obsługi metod build(), które pobierają obiekt File lub URL i konwertują je na strumienie przekazywane do innej metody build(), wymagającej jako parametru obiektu InputStream. public abstract class AbstractBuilder implements Builder { public abstract Document build(InputStream in) throws JDOMException; public Document build(File file) throws JDOMException; public Document build(URL url) throws JDOMException; }

Builder Jest to podstawowy interfejs, w którym zdefiniowano zachowanie wszystkich metod tworzących obiekt Document. KaŜda implementacja Builder musi udostępniać mechanizm pozwalający na utworzenie obiektu JDOM Document z obiektów InputStream, File lub URL. Wszystkie te implementacje zgłaszają wyjątki JDOMException, w których zawarte są informacje o błędach związanych z formatowaniem lub poprawnością (odpowiednio do sytuacji) i występujących w czasie budowania obiektu Document. public interface Builder { public Document build(InputStream in) throws JDOMException; public Document build(File file) throws JDOMException; public Document build(URL url) throws JDOMException; }

DOMBuilder Ta klasa umoŜliwia utworzenie obiektu JDOM Document z wejściowych danych XML, za pomocą parsera obsługującego DOM (obiektowy model dokumentu). Wykorzystuje w tym celu róŜne „adaptery” z pakietu org.jdom.adapters, a więc jeśli chcemy uŜyć parsera, dla którego nie istnieje odpowiedni „adapter”, wystąpią błędy. W klasie tej jest takŜe metoda pozwalająca na zbudowanie obiektu JDOM Document na podstawie istniejącego drzewa DOM (org.w3c.dom.Document). Klasa DOMBuilder umoŜliwia włączenie sprawdzania poprawności, moŜna takŜe jawnie określić klasę adaptera do wykorzystania. Jeśli uŜytkownik nie poda Ŝadnego z tych parametrów, sprawdzanie poprawności nie odbywa się i zostanie wykorzystany parser Apache Xerces. public class DOMBuilder extends AbstractBuilder { public DOMBuilder(String adapterClass, boolean validate); public DOMBuilder(String adapterClass); public DOMBuilder(boolean validate); public DOMBuilder(); public Document build(InputStream in) throws JDOMException; public Document build(org.w3c.dom.Document domDocument); }

SAXBuilder Klasa umoŜliwiająca utworzenie obiektu JDOM Document z wejściowych danych XML za pomocą parsera obsługującego SAX (Simple API for XML). MoŜliwe jest wykorzystanie dowolnej implementacji parsera zgodnej z SAX 2.4 W czasie korzystania z SAXBuilder moŜna zaŜądać

4

Jeśli będzie takie zapotrzebowanie, być moŜe w późniejszych wersjach JDOM zostanie dodana obsługa SAX 1.0.

JDOM 1.0

389

włączenia sprawdzania poprawności oraz określić nazwę klasy sterownika SAX, jaki ma zostać uŜyty. Jeśli Ŝaden z tych parametrów nie zostanie podany, wykorzystuje się ustawienia domyślne — brak sprawdzania poprawności i parser Apache Xerces. public class SAXBuilder extends AbstractBuilder { public SAXBuilder(String saxDriverClass, boolean validate); public SAXBuilder(String saxDriverClass); public SAXBuilder(boolean validate); public SAXBuilder(); public Document build(InputStream in) throws JDOMException; }

Pakiet org.jdom.output W tym pakiecie określono, jak mają być zwracane obiekty JDOM Document. Obecnie jedyną klasą jest tutaj XMLOutputter, za pomocą którego moŜna uzyskać wyjściowy obiekt JDOM Document w postaci strumienia. MoŜliwe jest jednak dodawanie dalszych klas. Oczekuje się, Ŝe w finalnej wersji JDOM 1.0 pojawi się kilka dodatkowych klas. Szczególną uwagę warto zwrócić na klasę SAXOutputter, która umoŜliwia uruchamianie zdarzeń SAX poprzez JDOM Document w aplikacji, która obsługuje SAX.

XMLOutputter Ta klasa obsługuje wyjściowy obiekt Document, wysyłany w formacie XML do strumienia OutputStream. Dostępne są konstruktory umoŜliwiajace ustawienie głębokości wcięć oraz określenie, czy do danych wynikowych mają być dopisywane znaki nowego wiersza. Domyślnie dane wynikowe są „elegancko sformatowane” (ang. pretty-printing) — czyli dwie spacje dla kaŜdego poziomu wcięć oraz obecne znaki nowego wiersza. Po stworzeniu egzemplarza klasy metoda output() spowoduje wysłanie podanego obiektu Document do określonego strumienia OutputStream. public class XMLOutputter { public XMLOutputter(); public XMLOutputter(String indent); public XMLOutputter(String indent, boolean newlines); public void output(Document doc, OutputStream out) throws IOException; }

JDOM 1.0

390

B Funkcje i właściwości SAX 2.0 W tym dodatku przedstwione są standardowe funkcje i właściwości interfejsu SAX 2.0. W oprogramowaniu określonego producenta mogą znaleźć się dodatkowe funkcje i właściwości; tutaj jednak przedstawiono tylko cechy podstawowe, które powinny być obsługiwane przez kaŜdą implementację parsera zgodną ze standardem SAX 2.0.

Podstawowe funkcje Wymieniono tutaj podstawowe funkcje obsługiwane przez implementacje SAX 2.0 XMLReader. Funkcje te moŜna ustawić za pomocą metody setFeature(); wartość określonej funkcji moŜna uzyskać metodą getFeature(). KaŜda funkcja moŜe być tylko do odczytu lub do odczytu i zapisu. MoŜliwe jest takŜe, Ŝe określone funkcje da się modyfikować tylko w czasie przetwarzania lub przeciwnie — tylko wtedy, gdy przetwarzanie się nie odbywa.

Przetwarzanie przestrzeni nazw Włączenie tej funkcji powoduje, Ŝe parser wykonuje przetwarzanie przestrzeni nazw. W wyniku tego przetwarzania przedrostki i identyfikatory URI przestrzeni nazw oraz nazwy lokalne będą dostępne poprzez wywołania SAX obsługujące przestrzenie nazw (startPrefixMapping() oraz endPrefixMapping(), a takŜe niektóre parametry przekazywane do startElement() oraz endElement()). Kiedy tej funkcji przypisana jest wartość true, przetwarzanie przestrzeni nazw będzie miało miejsce; jeśli false — przetwarzania przestrzeni nazw nie będzie (w tym ostatnim przypadku automatycznie zakłada się, Ŝe funkcja komunikowania o przedrostku przestrzeni nazw jest włączona). URI: http://xml.org/sax/features/namespaces Dostęp — tylko do odczytu przy przetwarzaniu; do odczytu i zapisu w innych przypadkach.

F:\Ksiazki\Internet\Java i XML\b-08.doc — strona 391

392

Dodatek B Funkcje i właściwości SAX 2.0

Komunikowanie o przedrostku przestrzeni nazw Włączenie tej funkcji powoduje, Ŝe parser informuje o atrybutach wykorzystywanych w deklaracjach przestrzeni nazw, czyli o atrybutach w rodzaju xmlns:[przedrostek przestrzeni]. Kiedy funkcja ta nie jest włączona (przypisano jej wartość false) i parser przetwarza atrybuty związane z przestrzeniami (w celu poznania odwzorowania przedrostków na identyfikatory URI), nie informuje o tym. Ponadto, kiedy przetwarzanie przestrzeni nazw jest włączane, zazwyczaj odwzorowanie przedrostków zostaje wyłączone. URI: http://xml.org/sax/features/namespaces/namespace-prefixes Dostęp — tylko do odczytu przy przetwarzaniu, do odczytu i zapisu w innych przypadkach.

Internalizacja łańcuchów Włączenie tej funkcji powoduje, Ŝe wszystkie nazwy elementów (w postaci „surowej” oraz lokalne), przedrostki oraz identyfikatory URI przestrzeni nazw są „internowane” za pomocą metody java.lang.String.intern(). Kiedy funkcja jest wyłączona, wszystkie komponenty XML pozostają nienaruszone. URI: http://xml.org/sax/features/string-interning Dostęp — tylko do odczytu przy przetwarzaniu, do odczytu i zapisu w innych przypadkach.

Sprawdzanie poprawności Włączenie tej funkcji powoduje, Ŝe będzie sprawdzana poprawność dokumentu, a wszystkie błędy wynikłe z naruszenia zawęŜeń zostaną zgłoszone poprzez interfejs SAX ErrorHandler (jeśli zarejestrowano odpowiednią implementację). Jeśli funkcji przypisano wartość false, sprawdzanie poprawności nie odbędzie się. URI: http://xml.org/sax/features/validation Dostęp — tylko do odczytu przy przetwarzaniu, do odczytu i zapisu w innych przypadkach.

Przetwarzanie zewnętrznych encji (ogólnych) Włączenie tej funkcji powoduje, Ŝe wszystkie ogólne (tekstowe) w danym dokumencie XML zostaną przetworzone. URI: http://xml.org/sax/features/external-general-entities Dostęp — tylko do odczytu przy przetwarzaniu, do odczytu i zapisu w innych przypadkach.

Przetwarzanie zewnętrznych encji (parametrów) Włączenie tej funkcji powoduje, Ŝe przetworzone zostaną wszystkie zewnętrzne parametry, w tym te znajdujące się w zewnętrznych podzbiorach definicji DTD. URI: http://xml.org/sax/features/external-parameter-entities Dostęp — tylko do odczytu przy przetwarzaniu, do odczytu i zapisu w innych przypadkach.

F:\Ksiazki\Internet\Java i XML\b-08.doc — strona 392

Podstawowe właściwości

393

Podstawowe właściwości Właściwości opisują obiekty wykorzystywane w procesie przetwarzania, szczególnie w czasie pracy z procedurami obsługi takimi jak LexicalHandler i DeclHandler, które nie naleŜą do podstawowego zestawu procedur SAX 2.0 (te ostatnie to EntityResolver, DTDHandler, ContentHandler oraz ErrorHandler). KaŜda właściwość moŜe być tylko do odczytu lub do odczytu i zapisu. MoŜliwe jest takŜe, Ŝe określone funkcje da się modyfikować tylko w czasie przetwarzania lub przeciwnie — tylko wtedy, gdy przetwarzanie się nie odbywa.

Procedura obsługi fragmentów leksykalnych Właściwość ta umoŜliwia ustawienie (lub odczytanie ustawienia) implementacji LexicalHandler wykorzystywanej do obsługi komentarzy i odwołań do definicji DTD występujących w dokumencie XML. URI: http://xml.org/sax/properties/lexical-handler Typ danych: org.xml.sax.ext.LexicalHandler Dostęp: do odczytu i zapisu zarówno w czasie przetwarzania, jak i w innych przypadkach.

Procedura obsługi deklaracji Właściwość ta umoŜliwia ustawienie (lub odczytanie ustawienia) implementacji DeclHandler wykorzystywanej do obsługi zawęŜeń określonych w definicji DTD. URI: http://xml.org/sax/properties/declaration-handler Typ danych: org.xml.sax.ext.DeclHandler Dostęp: do odczytu i zapisu zarówno w czasie przetwarzania, jak i w innych przypadkach.

Węzeł DOM Kiedy odbywa się przetwarzanie, za pomocą tej właściwości moŜna pobrać bieŜący węzeł DOM (o ile korzystamy z parsera DOM). W pozostałych przypadkach za pomocą tej właściwości pobiera się węzeł główny DOM. URI: http://xml.org/sax/properties/dom-node Typ danych: org.w3c.dom.Node Dostęp: tylko do odczytu przy przetwarzaniu, do odczytu i zapisu w innych przypadkach.

Dosłowny łańcuch XML Za pomocą tej właściwości moŜna pobrać ten tekst dosłowny znajdujący się w dokumencie, który spowodował uruchomienie bieŜącego zdarzenia (tj. zdarzenia, które trwa w czasie uŜycia tej właściwości). URI: http://xml.org/sax/properties/xml-string Typ danych: java.lang.String Dostęp: tylko do odczytu zarówno w czasie przetwarzania, jak i w innych przypadkach.

F:\Ksiazki\Internet\Java i XML\b-08.doc — strona 393