6. Klienty Flex usługi JEE dotyczącej spotkań

Przedstawiamy teraz dwa klienci Flex usługi internetowej JEE dotyczącej spotkań. Wykorzystywanym narzędziem jest Flex Builder 3. Wersję demonstracyjną tego produktu można pobrać pod adresem [https://www.adobe.com/cfusion/tdrc/index.cfm?loc=fr_fr&product=flex]. Flex Builder 3 jest IDE Eclipse. Ponadto do uruchomienia klienta Flex używamy serwera WWW Apache z narzędzia Wamp [http://www.wampserver.com/]. Nadaje się do tego dowolny serwer Apache. Przeglądarka wyświetlająca klienta Flex musi posiadać wtyczkę Flash Player w wersji co najmniej 9.

Aplikacje Flex charakteryzują się tym, że działają w ramach wtyczki Flash Player przeglądarki. Pod tym względem przypominają aplikacje Ajax, które osadzają w stronach wysyłanych do przeglądarki skrypty JavaScript, które są następnie wykonywane w przeglądarce. Aplikacja Flex nie jest aplikacją internetową w potocznym rozumieniu tego terminu: jest to aplikacja kliencka korzystająca z usług dostarczanych przez serwery internetowe. Pod tym względem przypomina aplikację biurkową, która byłaby klientem tych samych usług. Różni się jednak pod jednym względem: jest ona początkowo pobierana z serwera internetowego do przeglądarki wyposażonej we wtyczkę Flash Player zdolną do jej uruchomienia.

Podobnie jak aplikacja biurkowa, aplikacja Flex składa się głównie z dwóch elementów:

część prezentacyjna: widoki wyświetlane w przeglądarce. Widoki te charakteryzują się bogactwem funkcji typowym dla okien aplikacji biurowych. Widok jest opisany za pomocą języka znaczników o nazwie MXML.
część kodu, która zarządza głównie zdarzeniami wywołanymi przez działania użytkownika w widoku. Kod ten można napisać również w języku MXML lub w języku obiektowym o nazwie ActionScript. Należy rozróżnić dwa rodzaje zdarzeń:
zdarzenie wymagające wymiany danych z serwerem WWW: wypełnienie listy danymi dostarczonymi przez aplikację internetową, wysłanie danych z formularza na serwer itp. Flex udostępnia szereg metod umożliwiających komunikację z serwerem w sposób przezroczysty dla programisty. Metody te są domyślnie asynchroniczne: użytkownik może nadal korzystać z widoku podczas wysyłania żądania do serwera.
zdarzenie, które zmienia wyświetlany widok bez wymiany danych z serwerem, na przykład przeciągnięcie elementu z drzewa w celu umieszczenia go na liście. Tego typu zdarzenia są w całości przetwarzane lokalnie w przeglądarce.

Aplikacja Flex jest często uruchamiana w następujący sposób:

w [1], żądana jest strona HTML
w pliku [2], a następnie jest ona wysyłana. Zawiera ona plik binarny SWF (ShockWave Flash) zawierający całą aplikację Flex: wszystkie widoki oraz kod obsługi zdarzeń dla tych widoków. Plik ten zostanie uruchomiony przez wtyczkę przeglądarki o nazwie FlashPlayer.

Klient Flex działa lokalnie w przeglądarce, z wyjątkiem sytuacji, gdy potrzebuje danych zewnętrznych. W takim przypadku wysyła żądanie do serwera [3]. Otrzymuje je w pliku [4] w różnych formatach: XML lub binarnym. Aplikacja wywoływana na serwerze WWW może być napisana w dowolnym języku programowania. Liczy się wyłącznie format odpowiedzi.

Opisaliśmy architekturę działania aplikacji Flex, aby czytelnik dobrze zrozumiał różnicę między nią a klasyczną aplikacją internetową bez Ajaxu, taką jak opisana wcześniej aplikacja Asp.Net. W tej ostatniej przeglądarka pełni rolę bierną: po prostu wyświetla strony HTML utworzone na serwerze internetowym, który je do niej wysyła.

W dalszej części podajemy dwa przykłady klientów Flex wyłącznie w celu pokazania różnorodności klientów serwisu internetowego. Ponieważ autor sam jest początkującym użytkownikiem Flex, niektóre kwestie mogą nie zostać omówione tak szczegółowo, jak powinny.

6.1. Pierwszy klient Flex

Teraz napiszemy pierwszego klienta Flex, który wyświetli listę klientów. Wdrożona architektura klient-serwer będzie wyglądać następująco:

W tej architekturze występują dwa serwery internetowe:

serwer Glassfish, na którym działa zdalna usługa internetowa
serwer Apache, na którym działa klient Flex zdalnej usługi internetowej

Tworzymy klienta Flex przy użyciu programu IDE Flex Builder 3:

w programie Flex Builder 3 tworzymy nowy projekt o nazwie [1]
nadajemy mu nazwę w [2] i określamy w [3], w którym folderze ma zostać wygenerowany

w [4] nadajemy nazwę głównej aplikacji (tej, która będzie uruchamiana)
w polu [5] określa się, że po wygenerowaniu projektu
w [6], główny plik aplikacji MXML
plik MXML zawiera widok oraz kod obsługi zdarzeń tego widoku. Zakładka [Source] [7] zapewnia dostęp do pliku MXML. Znajdują się w nim tagi <mx> opisujące widok, a także kod ActionScript.
Widok można utworzyć graficznie, korzystając z zakładki [Design] [8]. Tagi MXML opisujące widok są wówczas generowane automatycznie w zakładce [Source]. Działa to również w drugą stronę: tagi MXML dodane bezpośrednio w zakładce [Source] są odzwierciedlane graficznie w zakładce [Design].

Podobnie jak w przypadku poprzednich klientów C# i Asp.Net, wygenerujemy lokalny proxy C [B] dla zdalnej usługi internetowej S [A]:

Aby można było wygenerować proxy w języku C, usługa internetowa JEE musi być aktywna.

w [1] należy wybrać opcję Dane / Importuj usługę internetową
w [2] należy wybrać folder, w którym mają być generowane klasy i interfejsy proxy C.

w [3] należy wprowadzić adres URI pliku WSDL zdalnej usługi internetowej S (patrz punkt 4.10.2), a następnie przejść do następnego etapu
w plikach [4] i [5], usługa internetowa opisana w pliku WSDL wskazanym w pliku [3]
w pliku [6]: lista metod, które zostaną wygenerowane dla proxy C. Należy zauważyć, że nie są to rzeczywiste metody serwisu S. Nie mają one prawidłowej sygnatury. W tym przypadku każda przedstawiona metoda ma jeden parametr, niezależnie od liczby parametrów rzeczywistej metody serwisu internetowego. Ten pojedynczy parametr jest instancją klasy, która w swoich polach zawiera parametry oczekiwane przez metodę zdalną.
w [7]: pakiet, w którym zostaną wygenerowane klasy i interfejsy proxy C
w [8]: nazwa klasy lokalnej, która będzie pełnić rolę proxy do zdalnej usługi internetowej
w [9]: zakończ pracę kreatora.
w [10]: lista klas i interfejsów wygenerowanego proxy C.

w [11]: klasa [WsDaoJpaService] implementująca metody proxy C.

Wygenerowana klasa [WsDaoJpaService] implementuje następujący interfejs [IWsDaoJpaService]:


/**
 * Service.as
 * This file was auto-generated from WSDL by the Apache Axis2 generator modified by Adobe
 * Any change made to this file will be overwritten when the code is re-generated.
 */
package generated.webservices{
    import mx.rpc.AsyncToken;
    import flash.utils.ByteArray;
    import mx.rpc.soap.types.*;
               
    public interface IWsDaoJpaService
    {
        //Funkcje zastępcze dla operacji getAllClients
        /**
         * Call the operation on the server passing in the arguments defined in the WSDL file
         * @param getAllClients
         * @return An AsyncToken
         */
        function getAllClients(getAllClients:GetAllClients):AsyncToken;
....
        function getAllClients_send():AsyncToken;
...
        function get getAllClients_lastResult():GetAllClientsResponse;
...
        function set getAllClients_lastResult(lastResult:GetAllClientsResponse):void;
...
       function addgetAllClientsEventListener(listener:Function):void;
...
        function get getAllClients_request_var():GetAllClients_request;
...
        function set getAllClients_request_var(request:GetAllClients_request):void;
...
    }
}

wiersz 11: interfejs [IWsDaoJpaService] zaimplementowany przez klasę [WsDaoJpaService]
wiersze 19–31: różne metody wygenerowane dla metody getAllClients() zdalnej usługi internetowej. Jedyna metoda zbliżona do tej faktycznie udostępnianej przez serwis internetowy znajduje się w wierszu 19. Ma ona właściwą nazwę, ale nie ma właściwej sygnatury: metoda getAllClients() zdalnego serwisu internetowego nie ma parametrów.

Jedyny parametr metody getAllClients wygenerowanego proxy C jest typu GetAllClients, jak poniżej:


/**
 * GetAllClients.as
 * This file was auto-generated from WSDL by the Apache Axis2 generator modified by Adobe
 * Any change made to this file will be overwritten when the code is re-generated.
 */

package generated.webservices
{
    import mx.utils.ObjectProxy;
    import flash.utils.ByteArray;
    import mx.rpc.soap.types.*;
    /**
     * Wrapper class for a operation required type
     */
    
    public class GetAllClients
    {
        /**
         * Constructor, initializes the type class
         */
        public function GetAllClients() {}
            
    }
}

Jest to pusta klasa. Może to wynikać z faktu, że docelowa metoda getAllClients nie przyjmuje żadnych parametrów.

Przyjrzyjmy się teraz klasom wygenerowanym dla encji Medecin, Client, Rv i Creneau. Weźmy na przykład klasę Client:


package generated.webservices
{
    import mx.utils.ObjectProxy;
    import flash.utils.ByteArray;
    import mx.rpc.soap.types.*;
    
    public class Client extends generated.webservices.Personne
    {
        public function Client() {}
            
    }
}

Klasa Client jest również pusta. Wywodzi się ona (wiersz 7) z następującej klasy Personne:


package generated.webservices
{
    import mx.utils.ObjectProxy;
    import flash.utils.ByteArray;
    import mx.rpc.soap.types.*;
    
    public class Personne
    {
        public function Personne() {}
            
        public var id:Number;
        public var nom:String;
        public var prenom:String;
        public var titre:String;
        public var version:Number;
    }
}

wiersze 11–15: znajdują się tu atrybuty klasy Personne zdefiniowanej w ramach serwisu internetowego JEE.

Mamy już główne elementy proxy C. Teraz możemy z niego korzystać.

Główny plik klienta [rdvmedecins01.xml] wygląda następująco:


<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" creationComplete="init();">
    <mx:Script>
        <![CDATA[
            import generated.webservices.Client;
...
            
            // dane
            private var ws:WsDaoJpaService;
            [Bindable]
            private var clients:ArrayCollection;
            
            private function init():void{
...
            }
            
            private function loadClients():void{
...
            }
            
...            
            private function displayClient(client:Client):String{
...
            } 
        ]]>
    </mx:Script>
    <mx:Label text="Liste des clients" fontSize="14"/>
    <mx:List dataProvider="{clients}" labelFunction="displayClient"></mx:List>
    <mx:Button label="Afficher les clients" click="loadClients()"/>
    <mx:Text id="txtMsgErreur" width="454" height="75"/>
    
</mx:Application>

W tym kodzie należy rozróżnić kilka elementów:

definicję aplikacji (wiersz 2)
opis widoku aplikacji (wiersze 27–30)
procedury obsługi zdarzeń w języku ActionScript wewnątrz tagu <mx:Script> (wiersze 3–26).

Na początek omówmy samą definicję aplikacji oraz opis jej widoku:

wiersz 2: określa
- sposób rozmieszczenia komponentów w kontenerze widoku. Atrybut layout="vertical" wskazuje, że komponenty będą umieszczone jeden pod drugim.
- metodę, która ma zostać wykonana po utworzeniu instancji widoku, c.a.d. moment, w którym wszystkie jego komponenty zostaną zainicjowane. Atrybut creationComplete="init();" oznacza, że należy wykonać metodę init z linii 13. creationComplete jest jednym ze zdarzeń, które może wygenerować klasa Application.
Wiersze 27–30 definiują komponenty widoku
wiersz 27: definiuje tekst
wiersz 28: lista, w której umieszczona zostanie lista klientów. Tag dataProvider="{clients}" wskazuje źródło danych, które mają wypełnić listę. W tym przypadku lista zostanie wypełniona obiektem clients zdefiniowanym w wierszu 11. Aby móc wpisać dataProvider="{clients}", pole clients musi posiadać atrybut [Bindable] (wiersz 10). Atrybut ten umożliwia odwołanie się do zmiennej ActionScript poza tagiem <mx:Script>. Pole clients jest typu ArrayCollection, czyli typu ActionScript, który umożliwia przechowywanie list obiektów, w tym przypadku listy obiektów typu Client.
wiersz 29: przycisk. Obsługiwane jest jego zdarzenie click. Atrybut click="loadClients()" wskazuje, że po kliknięciu przycisku ma zostać wykonana metoda loadClients z wiersza 17. To właśnie ten przycisk wywoła żądanie do serwisu internetowego dotyczące listy klientów.
wiersz 30: pole tekstowe przeznaczone do wyświetlania ewentualnego komunikatu o błędzie, który zostałby zwrócony przez serwer w odpowiedzi na poprzednie żądanie.

Wiersze 27–30 generują następujący widok w zakładce [Design]:

[1]: został wygenerowany przez komponent Label z wiersza 27
[2]: został wygenerowany przez komponent List z wiersza 28
[3]: został wygenerowany przez komponent Button z wiersza 29
[4]: został wygenerowany przez komponent Text z wiersza 30
[5]: przykład wykonania

Przyjrzyjmy się teraz kodowi ActionScript na stronie. Kod ten obsługuje zdarzenia widoku.


<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" creationComplete="init();">

    <mx:Script>
        <![CDATA[
            import generated.webservices.Client;
...
            
            // dane
            private var ws:WsDaoJpaService;
            [Bindable]
            private var clients:ArrayCollection;
            
            private function init():void{
                // tworzenie instancji proxy serwisu internetowego
                ws=new WsDaoJpaService();
                // konfiguracja obsługi zdarzeń
                ws.addgetAllClientsEventListener(loadClientsCompleted);
                ws.addEventListener(FaultEvent.FAULT,loadClientsFault);
            }
            
            private function loadClients():void{
                // pobieranie listy klientów
                ws.getAllClients(new GetAllClients());
            }
            
            private function loadClientsCompleted(event:GetAllClientsResultEvent):void{
                // pobieranie klientów z przesłanego wyniku
                clients=event.result as ArrayCollection;
            }
            
            private function loadClientsFault(event:FaultEvent):void{
                // wyświetla się komunikat o błędzie
                txtMsgErreur.text=event.fault.message;
            }
            
            private function displayClient(client:Client):String{
                // wyświetla się klienta
                return client.nom + " " + client.prenom;
            } 
        ]]>
    </mx:Script>
    <mx:Label text="Liste des clients" fontSize="14"/>
    <mx:List dataProvider="{clients}" labelFunction="displayClient"></mx:List>
    <mx:Button label="Afficher les clients" click="loadClients()"/>
<mx:Text id="txtMsgErreur" width="454" height="75"/>

wiersz 9: ws będzie wskazywać na proxy typu C o nazwie WsDaoJpaService, czyli wygenerowaną wcześniej klasę, która implementuje metody dostępu do zdalnej usługi internetowej.
wiersz 13: metoda init wykonywana po utworzeniu instancji widoku (wiersz 1)
wiersz 15: tworzona jest instancja proxy C
wiersz 17: do zdarzenia „metoda asynchroniczna GetAllClients zakończyła się pomyślnie” przypisano obsługę zdarzenia. Dla każdej metody m zdalnej usługi internetowej proxy C implementuje metodę addmEventListener, która umożliwia powiązanie obsługi zdarzenia z wydarzeniem „metoda asynchroniczna m zakończyła się pomyślnie”. W tym przypadku wiersz 17 wskazuje, że metoda loadClientsCompleted z wiersza 26 ma zostać wykonana, gdy klient Flex otrzyma listę klientów.
wiersz 18: do zdarzenia „asynchroniczna metoda serwera proxy C zakończyła się niepowodzeniem” przypisano procedurę obsługi zdarzenia. W tym przypadku wiersz 18 wskazuje, że metoda loadClientsFault z wiersza 31 ma zostać wykonana za każdym razem, gdy asynchroniczne żądanie z proxy C do serwisu internetowego S zakończy się niepowodzeniem. W tym przypadku jedynym wysyłanym żądaniem jest to, które dotyczy listy klientów.
Ostatecznie metoda init z linii 13 utworzyła instancję proxy C i zdefiniowała procedury obsługi zdarzeń dla żądania asynchronicznego, które zostanie wysłane w późniejszym czasie.
wiersz 21: metoda wykonywana po kliknięciu przycisku [Afficher les clients] (wiersz 44)
wiersz 23: wykonywana jest metoda asynchroniczna getAllClients proxy C. Przekazywana jest do niej instancja GetAllClients, której zadaniem jest hermetyzacja parametrów wywoływanej metody zdalnej. W tym przypadku nie ma żadnych parametrów. Tworzona jest pusta instancja. Metoda getAllClients jest asynchroniczna. Wykonanie jest kontynuowane bez oczekiwania na dane zwrócone przez serwer. Użytkownik może w szczególności nadal wchodzić w interakcję z widokiem. Wywoływane przez niego zdarzenia będą nadal obsługiwane. Dzięki metodzie init wiemy, że:
- metoda loadClientsCompleted (wiersz 26) zostanie wykonana, gdy klient Flex otrzyma listę klientów
- metoda loadClientsFault (wiersz 31) zostanie wykonana, jeśli żądanie zakończy się błędem.
wiersz 28: lista klientów jest pobierana w ramach zdarzenia. Wiemy, że metoda getAllClients zdalnej usługi internetowej zwraca listę. Umieszczamy ją w polu clients w wierszu 11. Konieczna jest konwersja typu. Ponieważ lista z wiersza 43 jest powiązana (Bindable) z polem klientów, otrzymuje powiadomienie o zmianie danych. Następnie wyświetla listę klientów. Wyświetli każdy element listy clients za pomocą metody displayClient (wiersz 43).
wiersz 36: metoda displayClient otrzymuje typ Client. Musi zwrócić ciąg znaków, który lista ma wyświetlić dla tego klienta. W tym przypadku jest to nazwisko i imię (wiersz 38).
wiersz 31: metoda wykonywana w przypadku niepowodzenia żądania skierowanego do serwisu internetowego. Otrzymuje parametr typu FaultEvent. Klasa ta posiada pole fault, które zawiera błąd zwrócony przez serwer. fault.message to komunikat towarzyszący błędowi.
linia 33: komunikat o błędzie jest wyświetlany w przeznaczonym do tego celu polu tekstowym.

Po skompilowaniu aplikacji jej kod wykonywalny znajduje się w folderze [bin-debug] projektu Flex:

Powyżej

plik [rdvmedecins01.html] stanowi plik HTML, o który przeglądarka zwróci się do serwera WWW w celu uzyskania klienta Flex
plik [rdvmedecins01.swf] to plik binarny klienta Flex, który zostanie osadzony w stronie HTML wysłanej do przeglądarki, a następnie uruchomiony przez wtyczkę Flash Player tej przeglądarki.

Jesteśmy gotowi do uruchomienia klienta Flex. Najpierw musimy jednak skonfigurować niezbędne środowisko uruchomieniowe. Wróćmy do testowanej architektury klient-serwer:

Po stronie serwera:

uruchom SGBD MySQL
uruchom serwer Glassfish
wdrożyć usługę internetową JEE, jeśli nie została jeszcze wdrożona
ewentualnie przetestować jednego z poprzednich klientów, aby sprawdzić, czy wszystko działa poprawnie po stronie serwera.

Po stronie klienta:

Uruchom serwer Apache, do którego będzie kierowany żądanie aplikacji Flex. W tym przypadku używamy narzędzia Wamp. Za pomocą tego narzędzia możemy przypisać alias do folderu [bin-debug] projektu Flex.

ikona Wamp znajduje się na dole ekranu [1]
klikając lewym przyciskiem myszy na ikonę Wamp, wybierz opcję Apache [2] / Alias Directories [3, 4]
wybrać opcję [5]: Dodaj alias

w [6] nadać alias (dowolną nazwę) aplikacji internetowej, która ma zostać uruchomiona
w [7] należy wskazać katalog główny aplikacji internetowej, która będzie nosiła ten alias: jest to folder [bin-debug] projektu Flex, który właśnie utworzyliśmy.

Przypomnijmy strukturę folderu [bin-debug] projektu Flex:

Plik [rdvmedecins01.html] jest plikiem HTML aplikacji Flex. Dzięki aliasowi, który właśnie utworzyliśmy dla folderu [bin-debug], plik ten będzie dostępny pod adresem URL [http://localhost/rdvmedecins/rdvmedecins01.html]. Adres ten należy wywołać w przeglądarce wyposażonej we wtyczkę Flash Player w wersji 9 lub nowszej:

w [1], adres URL aplikacji Flex
w [2] wywołujemy listę klientów
w [3] – wynik uzyskany, gdy wszystko działa poprawnie
w [4] – wynik uzyskany, gdy żądamy wyświetlenia klientów, mimo że usługa internetowa została zatrzymana.

Być może zechcą Państwo wyświetlić kod źródłowy otrzymanej strony HTML

<!-- zapisano z adresu url=(0014)about:internet -->
<html lang="en">

<!-- 
Smart developers always View Source. 

This application was built using Adobe Flex, an open source framework
for building rich Internet applications that get delivered via the
Flash Player or to desktops via Adobe AIR. 

Learn more about Flex at http://flex.org 
// -->

<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<!--   BEGIN Sekcja wymagająca historii przeglądarki -->
<link rel="stylesheet" type="text/css" href="history/history.css" />
<!--   END Sekcja wymagająca historii przeglądarki -->

<title></title>
<script src="AC_OETags.js" language="javascript"></script>
...
<script language="JavaScript" type="text/javascript">
<!--
// -----------------------------------------------------------------------------
// Zmienne globalne
// Wymagana główna wersja programu Flash
var requiredMajorVersion = 9;
// Wymagana wersja drugorzędna programu Flash
var requiredMinorVersion = 0;
// Wymagana wersja drugorzędna programu Flash
var requiredRevision = 124;
// -----------------------------------------------------------------------------
// -->
</script>
</head>

<body scroll="no">
<script language="JavaScript" type="text/javascript">
<!--
// Sprawdzanie wersji programu Flash Player umożliwiającego uruchomienie instalacji produktu Player (6.0r65)
....
// -->
</script>
<noscript>
        <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
                        id="rdvmedecins01" width="100%" height="100%"
                        codebase="http://fpdownload.macromedia.com/get/flashplayer/current/swflash.cab">
                        <param name="movie" value="rdvmedecins01.swf" />
                        <param name="quality" value="high" />
                        <param name="bgcolor" value="#869ca7" />
                        <param name="allowScriptAccess" value="sameDomain" />
                        <embed src="rdvmedecins01.swf" quality="high" bgcolor="#869ca7"
                                width="100%" height="100%" name="rdvmedecins01" align="middle"
                                play="true"
                                loop="false"
                                quality="high"
                                allowScriptAccess="sameDomain"
                                type="application/x-shockwave-flash"
                                pluginspage="http://www.adobe.com/go/getflashplayer">
                        </embed>
        </object>
</noscript>
</body>
</html>

Treść strony zaczyna się w wierszu 39. Nie zawiera ona klasycznego kodu HTML, lecz obiekt (wiersz 47) typu „application/x-shockwave-flash” (wiersz 60). Jest to plik [rdvmedecins01.swf] (wiersz 54), który można znaleźć w folderze [bin-debug] projektu Flex. Jest to plik o znacznej wielkości: około 600 K dla tego prostego przykładu.

6.2. Drugi klient Flex

Drugi klient Flex nie będzie korzystał z serwera proxy w języku C wygenerowanego dla pierwszego. Chcemy pokazać, że ten etap nie jest niezbędny, nawet jeśli ma pewne zalety w porównaniu z rozwiązaniem, które zostanie tutaj przedstawione.

Projekt rozwija się w następujący sposób:

do [1] – nowa aplikacja Flex
w [2] – powiązane z nią pliki wykonywalne
w [3] nowy widok: wyświetlimy listę lekarzy.

Kod MXML aplikacji [rdvmedecins02.mxml] wygląda następująco:


<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical">
    <mx:Script>
        <![CDATA[
            import mx.rpc.events.ResultEvent;
            import mx.rpc.events.FaultEvent;
            import mx.collections.ArrayCollection;
            
            // dane
            [Bindable]
            private var medecins:ArrayCollection;
            
            private function loadMedecins():void{
                // żądana jest lista lekarzy
                wsrdvmedecins.getAllMedecins.send();
            }
            
            private function loadMedecinsCompleted(event:ResultEvent):void{
                // pobieranie listy lekarzy
                medecins=event.result as ArrayCollection;
            }
            
            private function loadMedecinsFault(event:FaultEvent):void{
                // wyświetlanie komunikatu o błędzie
                txtMsgErreur.text=event.fault.message;
            } 
            
            // wyświetlenie danych lekarza
            private function displayMedecin(medecin:Object):String{
                return medecin.nom + " " + medecin.prenom;
            } 

        ]]>
    </mx:Script>
    <mx:WebService id="wsrdvmedecins" 
        wsdl="http://localhost:8080/serveur-webservice-ejb-dao-jpa-hibernate/WsDaoJpaService?wsdl">
        <mx:operation name="getAllMedecins" 
            result="loadMedecinsCompleted(event)" fault="loadMedecinsFault(event);">
            <mx:request/>
        </mx:operation>
    </mx:WebService>
    <mx:Label text="Liste des médecins" fontSize="14"/>
    <mx:List dataProvider="{medecins}" labelFunction="displayMedecin"></mx:List>
    <mx:Button label="Afficher les médecins" click="loadMedecins()"/>
    <mx:Text id="txtMsgErreur" width="300" height="113"/>
    
</mx:Application>

Omówimy tylko nowości:

wiersze 42–45: nowy widok. Jest on identyczny z poprzednim, z tą różnicą, że został dostosowany do wyświetlania lekarzy zamiast klientów.
wiersze 35–41: usługa internetowa jest tutaj opisana za pomocą tagu <mx:WebService> (wiersz 35). Proxy C używane w poprzedniej wersji nie jest już tutaj stosowane.
wiersz 35: atrybut id nadaje nazwę usłudze internetowej.
wiersz 36: atrybut wsdl podaje adres URI pliku WSDL usługi internetowej. Jest to ten sam adres URI, który był używany przez poprzedniego klienta i zdefiniowany w paragrafie 4.10.2.
wiersze 37–40: definiują metodę zdalnej usługi internetowej za pomocą tagu <mx:operation>
wiersz 37: odwołana metoda jest zdefiniowana przez atrybut name. W tym przypadku odwołujemy się do zdalnej metody getAllMedecins.
wiersz 38: definiuje się metody, które mają zostać wykonane w przypadku pomyślnego zakończenia operacji (atrybut result) oraz w przypadku niepowodzenia (atrybut fault).
wiersz 39: tag <mx:request> służy do zdefiniowania parametrów operacji. W tym przypadku metoda zdalna getAllMedecins nie ma parametrów, więc nie wpisujemy niczego. W przypadku metod przyjmujących parametry, takich jak param1 i param2, zapisalibyśmy:

<mx:Request>
    <param1>{param1}</param1>
    <param1>{param1}</param1>
</mx:Request>

gdzie param1 i param2 byłyby zmiennymi zadeklarowanymi i zainicjowanymi w tagu <mx:Script>

[Bindable]
private var param1:Type1;
[Bindable]
private var param2:Type2;

W tagu <mx:Script> znajduje się kod ActionScript analogiczny do tego, który analizowaliśmy w poprzednim kliencie. Różni się jedynie metoda loadMedecins w wierszach 13–16. Różni się sposób wywołania metody zdalnej [getAllMedecins]:

wiersz 15: wykorzystuje się usługę internetową [wsrdvmedecins] zdefiniowaną w wierszu 35 oraz jej operację [getAllMedecins] zdefiniowaną w wierszu 37. Do wykonania tej operacji używana jest metoda send. To właśnie ona inicjuje asynchroniczne wywołanie metody getAllMedecins usługi internetowej zdefiniowanej w wierszu 35. Metoda send wykona wywołanie z parametrami zdefiniowanymi przez tag <mx:request> w wierszu 39. W tym przypadku nie ma żadnych parametrów. Gdyby metoda miała parametry param1 i param2, skrypt loadMedecins przypisałby wartości do tych parametrów przed wywołaniem metody send.

Pozostaje nam tylko przetestować tę nową aplikację: