JSP Web Service Client erstellen

Transkript

1 JSP Web Service Client erstellen Einleitung Dieses Tutorial soll bei der Erstellung eines JSP Web Service Clients helfen. Mit diesem JSP- Client soll die gesamte Funktionalität des AutoKauf-Services ansprechend für das Web dargestellt werden. Das Beispiel schließt an das Tutorial XML-Datei für Web Service auslesen und schreiben an. Unbedingte Voraussetzung ist jedoch das Durcharbeiten des Tutorials Java-basierten Web Service erstellen oder eine gleichwertige Lösung. Inhaltsverzeichnis 1 IMPORTIEREN DES WEB SERVICE AUTOKAUF 1 2 ERSTELLEN EINER EINFACHEN JSP 3 3 WEB SERVICE ZUGRIFF VIA JSP MIT TAGLIB IO JSP (SOAP-Request) JSP (Get-Request) TCP/IP-Monitor 7 4 JAVA SOAP-PROXY ERSTELLEN CalculatorProxy (einfache SOAP-Proxy Klasse) AutoKaufProxy (automatische Generierung) 10 5 IMPLEMENTIERUNG DER JSPS Implementierung der AutoKauf.jsp Implementierung der Ergebnis.jsp Implementieren der format.css Implementierung der script.js AutoKauf - Portal 21 6 ERSTELLEN DES ARCHIVS AKWS1011GXXJSPCLIENT 23

2 1 Importieren des Web Service AutoKauf Die Vorrausetzung für dieses Tutorial ist, dass der Web Service AutoKauf bereits implementiert ist. Um den Web Service in die Testumgebung zu integrieren, importieren wir das Archiv in Eclipse als Projekt. Dies geschieht mit File -> Import -> Web -> WAR file. Mit Rechtsklick auf das importierte Projekt AKWS1011GXX Run As -> Run on Server wird dem Server der Web-Kontext hinzugefügt. 1

3 Der Service ist also immer verfügbar, wenn das Tomcat-Plugin gestartet ist. Mit der folgenden URL kann getestet werden, ob der Service aktiv ist. 2

4 2 Erstellen einer einfachen JSP Greifen wir zunächst das aus dem Tutorial Java-basierten Web Service erstellen bekannte Additionsbeispiel auf. Wir erstellen also eine JSP-Datei, mit der zwei Zahlen addiert werden können. Dafür legen wir ein neues Dynamic Web Project AKWS1011GXXJSPClient in Eclipse an. Wir verwenden das Projekt für das gesamte Tutorial. Die Anfangsbeispiele können wir ja später wieder löschen. Mit Rechtsklick auf das Projekt New -> Other -> Web -> JSP erstellen wir im WebContent-Ordner ein neues Skelett einer JSP-Datei nennen wir sie add.jsp. Nun erstellen wir zwei Inputfelder und einen Button, und natürlich die Programmlogik. Der Code sieht dann so aus. 3

5 page language="java" contenttype="text/html; charset=iso " pageencoding="iso "%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso "> <title>calculator</title> </head> <body> <h2>addition</h2> <% String a = request.getparameter( "a" ); String b = request.getparameter( "b" ); a = ( null!= a )? a.trim() : "0"; b = ( null!= b )? b.trim() : "0"; %> <form method="post"> <p>a: <input type="text" name="a" value='<%= a %>' size=20></p> <p>b: <input type="text" name="b" value='<%= b %>' size=20></p> <p><input type="submit" name="submit" value="addieren"></p> </form> <p><%long c = Long.valueOf(a)+Long.valueOf(b);out.print(c);%></p> </body> </html> Mit Rechtsklick auf add.jsp Run As -> Run on Server -> Finish deployen wir das neue Projekt auf den Tomcat. Im Browser können wir nun mit der URL die JSP testen. 3 Web Service Zugriff via JSP mit Taglib IO Taglibs ist ein Apache Jarkata open source Projekt mit dem Hintergedanken JSP übersichtlicher zu machen indem man Scriptlets vermeidet und durch (eigene) Tags (<meintag/>) ersetzt. Scriptlets sind die Java-Blöcke zwischen den <% %>-Begrenzern. 4

6 Es gibt bereits einige vorgefertigte Tag-Bibliotheken. Mit der Taglib IO können verschiedene Input- und Output-Aufgaben aus JSP heraus komfortabel umgesetzt werden. Ein unterstütztes Protokoll ist SOAP. 3.1 JSP (SOAP-Request) Erstellen wir eine JSP, die den Calculator-Service aus dem Tutorial Java-basierten Web Service erstellen verwendet. Zunächst muss dafür der Web Service Calculator in Eclipse importiert werden. Dies geschieht analog dem Import des AutoKauf Web Services. Anschließend erstellen wir wieder eine neue JSP-Datei CalWSClientAdd.jsp und kopieren zunächst den Inhalt aus add.jsp. Nun ersetzen wir den Abschnitt <p><%long c = Long.valueOf(a)+Long.valueOf(b);out.print(c);%></p> mit <p> <io:soap url=" SOAPAction=""> <io:body> <SOAP-ENV:Envelope xmlns:soap- ENV=" <SOAP-ENV:Body> <add xmlns:m=" <a><%= a %></a> <b><%= b %></b> </add> </SOAP-ENV:Body> </SOAP-ENV:Envelope> </io:body> </io:soap> </p> Am Anfang der JSP fügen wir noch den Verweis auf den Tag Library Descriptor hinzu und speichern. <%@ taglib uri="web-inf/taglibs-io.tld" prefix="io" %> Nun müssen wir noch die Tag Library und den Descriptor in das Projekt einbinden. Dafür laden wir zunächst die ZIP-Datei herunter unter und entpacken anschließend taglibs-io.jar nach WebContent/WEB-INF/lib und den taglibs-io.tld nach WebContent/WEB-INF kopieren. Mit F5 refreshen wir den Projekt-Inhalt und mit Rechtsklick auf CalWSClientAdd.jsp Run As -> Run on Server öffnen wir die JSP im Browser. Mit Rechtsklick im Browserfenster View Source öffnen wir die Quelldatei und stellen fest, dass wir nicht nur den Wert, sondern die gesamte SOAP-Message erhalten haben. 5

7 Neben den vorgefertigten Taglibs (wie IO) können auch eigene (Custom) Taglibs erstellt werden. Für Bastler wäre es sicher eine interessante Aufgabe einen vollständig Scriptlet-losen JSP Web Service Client für den AutoKauf-Service zu erstellen. Achtung: Das Jakarta Taglibs Projekt wird seit 2008 nicht mehr weiter entwickelt und ist als deprecated eingestuft. Es wurde durch das Tomcat Taglibs Projekt ersetzt. ( 3.2 JSP (Get-Request) Bei der Verwendung des Get-Requests senden wir keine SOAP-Message als Anfrage. Stattdessen ist die Anfrage in der URL des HTTP-Get-Requests kodiert. Mit der URL-Parameter-Konkatenation basteln wir uns die URL zusammen, mit der eine Methode des Web Service aufgerufen wird. Hierfür nutzen wir die Möglichkeit, den Web Service direkt per URL anzusteuern. Mit der URL können wir den Web Service ja auch vom Browser aus aufrufen. Auch hier verwenden wir wieder die Taglib IO und erstellen eine neue JSP-Datei CalWSClientAdd2.jsp und kopieren den Inhalt der CalWSClientAdd.jsp hinein. Den gesamten SOAP-Teil ersetzen wir durch den folgenden. <p> <io:soap... > <%String url = " Calculator?method=add&a="+a+"&b="+b+"";%> <io:request url="<%=url%>" /> </p> Wenn wir im Browser die Datei CalWSClientAdd2.jsp und deren Quellcode ansehen gibt es im Ergebnis keinen Unterschied zu CalWSClientAdd.jsp. Auf diese Weise können wir auch auf den AutoKauf-Service zugreifen, indem wir den Code leicht abändern. <%String url = " Wie zu erwarten bekommen wir auch hier die SOAP-Antwort im XML-Format. Der Browser sucht uns freundlicherweise alle Werte heraus und schreibt sie hintereinander. Ein Blick in den Quellcode der Seite zeigt die gesamte SOAP-Antwort. Außer der Verwendung der Taglibs gibt es sicher noch zahlreiche Möglichkeiten direkt von der JSP aus auf den Web Service zuzugreifen. Alle haben allerdings den Nachteil, dass wir in der JSP die Verbindung zum Web Service herstellen und ggf. die SOAP-Antwort verarbeiten müssen. Das bläht die JSP unnötig auf. Deshalb werden wir später einen anderen Weg gehen 6

8 und einen SOAP-Proxy erstellen (eine Java-Klasse, die sich um die Web Service Verbindung kümmert). Doch dazu später mehr. 3.3 TCP/IP-Monitor An dieser Stelle lässt sich ein guter Vergleich zwischen dem SOAP-Request und dem Get- Request machen. Wie wir bereits gesehen haben gibt es zwei verschiedene Möglichkeiten einen Web Service anzusprechen. Zum einen durch Senden einer SOAP-Request-Nachricht mit der HTTP-Post-Methode und zum anderen durch einen einfachen HTTP-Get-Request. Was genau bei der Kommunikation geschieht kann mit dem in Eclipse-WTP integrierten TCP/IP-Monitor überwacht werden. Dabei fungiert der Monitor als ein Proxy-Server. Port 2 Port 1 Server TCP/IP Monitor Browser Es können also (Web) Anfragen auf dem einen Port (z.b. localhost:321) gestellt werden und der Proxy mappt die Anfragen dann auf den Zielport (z.b. localhost:80). Die dabei verarbeiteten Protokollnachrichten werden angezeigt. Eine neue Konfiguration kann über Window -> Preferences -> Run/Debug -> TCP/IP Monitor -> Add erstellt werden. Nach der Erstellung muss der neue Monitor in der Liste noch gestartet werden. 7

9 Nun stellen wir die Anfragen der beiden JSPs CalWSClientAdd.jsp und CalWSClientAdd2.jsp gegenüber. Dazu müssen wir zunächst die URLs in den JSPs etwas abändern. <p> <io:soap url=" </p> <p> <%String url = " Calculator?method=add&a="+a+"&b="+b+"";%>... </p> Nun können wir mit den entsprechenden URLs der JSPs die Anfragen im Browser starten. Die Antworten der beiden Anfragen sind natürlich identisch. 8

10 4 Java SOAP-Proxy erstellen 4.1 CalculatorProxy (einfache SOAP-Proxy Klasse) Wie weiter oben bereits angedeutet, ist es sinnvoller, den Zugriff auf den Web Service komplett aus der JSP auszulagern. Dafür erstellen wir eine (oder mehrere) Klasse(n), die die Anfragen von der JSP auf den Web Service mappen. Diese Klasse(n) werden als SOAP-Proxy bezeichnet. Zu Beginn werden wir die gesamte Funktionalität für den Calculator Web Service Zugriff in nur einer SOAP-Proxy Klasse unterbringen. Mit Rechtsklick auf src New > Class erstellen wir im neuen Package calculator eine neue Klasse CalculatorSoapProxy und kopieren den folgenden Quellcode hinein. package calculator; import java.net.url; import javax.xml.rpc.parametermode; import org.apache.axis.constants; import org.apache.axis.client.call; import org.apache.axis.client.service; public class CalculatorSoapProxy { public static void main(string[] args) { System.out.println(new CalculatorSoapProxy().add(5,7)); public CalculatorSoapProxy() { public long add(long a,long b){ try{ Service service = new Service(); Call call = (Call)service.createCall(); call.settargetendpointaddress( URL(" call.setoperationname("add"); call.addparameter("a",constants.xsd_long,parametermode.in); call.addparameter("b",constants.xsd_long,parametermode.in); call.setreturntype( Constants.XSD_LONG ); return (Long)call.invoke( new Object[] {a,b ); catch (Exception e){e.printstacktrace(); return -1; new In den Ordner WebContent/WEB-INF/lib kopieren wir die JAR-Archive axis.jar, axisant.jar, commons-logging.jar, commons-discovery-0.2.jar, jaxrpc.jar, log4j jar, Saaj.jar, wsdl4j.jar aus dem Verzeichnis <ECLIPSE_HOME>\plugins\ oder einem der bereits vorhandenen Projekte. Anschließend erstellen wir wieder eine neue JSP-Datei CalWSClientAdd3.jsp und kopieren zunächst den Inhalt aus Add.jsp. 9

11 Nun ersetzen wir den Abschnitt <p><%long c = Long.valueOf(a)+Long.valueOf(b);out.print(c);%></p> mit <p> <% CalculatorSoapProxy proxy = new CalculatorSoapProxy(); long c = proxy.add(long.valueof(a),long.valueof(b)); out.print(c); %> </p> Am Anfang der JSP fügen wir noch Import-Anweisung für den CalculatorProxy hinzu und speichern. <%@page import="calculator.calculatorsoapproxy"%> Mit Rechtsklick auf CalWSClientAdd3.jsp Run As -> Run on Server öffnen wir die JSP im Browser. Achtung! In der Serveransicht sollten wir vorher sicherstellen, dass der Tomcat auch läuft und dass der Web Service Calculator auch ausgeführt wird. An dieser Stelle dürfte ungefähr klar sein, wozu der Proxy gut ist. Er kümmert sich um die Verbindung zum Web Service. Wenn wir zukünftig Daten (z.b. aus einer JSP) vom Web Service abfragen, stellen wir die Anfrage nicht direkt an den Web Service, sondern an den Proxy. 4.2 AutoKaufProxy (automatische Generierung) Für umfangreichere Web Services ist es natürlich nicht nötig, die SOAP-Proxy Klasse(n) selbst zu implementieren. Dafür gibt es für die meisten Programmierumgebungen Code- Generatoren. Die Code-Generierung erfolgt anhand der WSDL-Referenz des Web Service. Aus dem Tutorial Java-basierten Web Service erstellen wissen wir, dass es zwei Typen von WSDL- Referenzen gibt: die lokale WSDL-Datei (AKWS1011GXX.wsdl) und die Web WSDL- Referenz ( Üblicherweise wird bei der Clienterstellung die Web WSDL-Referenz verwendet. 10

12 Wie im Tutorial Java-basierten Web Service erstellen erwähnt, unterscheiden sich die beiden WSDL-Referenzen unseres AutoKauf Web Services aufgrund eines Axis-Bugs erheblich. Wir werden uns immer die lokale WSDL-Datei anschauen, jedoch für die Code-Generierung die Web WSDL-Referenz verwenden. Mit File -> New -> Other -> Web Services -> Web Service Client öffnen wir den Wizard zum Erstellen eines Web Service Clients, den wir zukünftig als SOAP-Proxy verwenden. Als Service Definition nehmen wir die Web WSDL Referenz unseres AKWS1011GXX-Projektes Als Client Project legen wir AKWS1011GXXJSPClient fest und erstellen nun den Web Service Client. 11

13 Unser Projekt sollte nach der bisherigen Durcharbeitung des Tutorials nun die folgende Struktur haben. Mit der Einstellung Test client im Web Service Client Wizard wurden bereits einige Beispiel- JSP-Dateien erstellt, mit denen auf den Web Service zugegriffen werden kann. Unter der folgenden URL können wir mit diesen JSP-Dateien den Servicezugriff testen. 12

14 Interessierte können sich den Quellcode der JSP-Dateien genauer anschauen. Für uns ist eigentlich nur eine Zeile (in Result.jsp) interessant: <jsp:usebean id="sampleautokaufproxyid" scope="session" class="akws1011gxx.autokauf.autokaufproxy" /> Damit wird die Proxy-Klasse als Java Bean in die JSP-Datei eingebunden. Eine andere Möglichkeit wäre die import-anweisung, die wir im vorangegangenen Abschnitt verwendet haben. Erstellen wir nun mit Rechtsklick auf das Projekt AKWS1011GXXJSPClient New -> Other -> Web -> JSP im WebContent-Ordner unsere eigene JSP-Datei AutoKauf.jsp. Mit der URL können wir die JSP nun im Browser öffnen. Der Inhalt ist natürlich noch etwas mager. Bevor wir weitermachen, rekapitulieren wir noch einmal die Web Service Struktur anhand der WSDL-Datei AKWS1011GXX.wsdl. Dazu nutzen wir den in Eclipse WTP integrierten WSDL-Editor. 13

15 Jeder Input- bzw. Output-Parameter wird in Java durch eine eigene Klasse repräsentiert. Das bedeutet, dass wir z. B. beim Aufruf der Methode alleautosanzeigen ein Paramter- Objekt AlleAutosAnzeigenRequest übergeben müssen. Mit Klick auf den blauen Pfeil im WSDL-Editor erhalten wir nähere Informationen zu dem komplexen Typen. So besteht der Type alleautosanzeigenresponsetype aus einem Array (AutoArrayItems) vom Typ AutoArray. Mit Doppelklick auf die Typ-Definition erhalten wir nähere Informationen zu dem (ebenfalls komplexen) Typ AutoArray. Ein AutoArray kann wiederum 1 oder viele AutoArrayItems vom Typ Auto enthalten. Nun wird auch klar warum wir noch die Klasse Auto benötigen. Genau genommen müsste es eigentlich noch eine Klasse AutoArray geben. Diese würde jedoch lediglich die Funktion haben ein Array von Autos (Auto[]) zurückzugeben. Deshalb kann man diesen Schritt auch weglassen. Schauen wir uns noch die Definitionen für Auto an. Die Übergabe- und Rückgabewerte der anderen Methoden kaufeauto und verkaufeauto können wir uns hier ebenfalls anschauen auch in der XML-Ansicht. 14

16 Achtung: In der aktuellen Eclipse-Version (Helios) werden anscheinend aus Optimierungsgründen für einfache Request- oder Responsetypen keine Klassen zur Repräsentation erzeugt. Daher müssen die Typen explizit angegeben werden. Sie können in der Datei AutoKaufSoapBindingImpl.java des AutoKauf-Projekts überprüft werden. Übertragen wir dieses Wissen auf unsere AutoKauf.jsp und testen den Zugriff auf den Web Service mit folgendem Scriptlet. <body> <jsp:usebean id="proxy" scope="session" class="akws1011gxx.autokauf.autokaufproxy" /> <% AKWS1011GXX.AutoKauf.Types.Auto[] aaaresponse; aaaresponse = proxy.alleautosanzeigen(); long karequest = 1; boolean karesponse = proxy.kaufeauto(karequest); long vkarequest = 2; boolean vkaresponse = proxy.verkaufeauto(vkarequest); AKWS1011GXX.AutoKauf.Types.Auto[] autos = aaaresponse; if (autos!=null) for (int i=0; i<autos.length; i++) out.print(autos[i].getfarbe()+", "); out.print(karesponse+", "); out.print(vkaresponse);%> </body> Um die Daten der Browseransicht mit den Daten der XML-Datei zu vergleichen empfiehlt es sich die entsprechende XML-Datei Autos.xml in XMLSpy zu öffnen. Achtung Schusselgefahr! Wer sich Autos.xml im Verzeichnis <ECLIPSE_WORKSPACE>\AKWS1011GXX\WebContent\data anschaut und wundert, dass sich nichts ändert, das liegt daran, das dass gesamte WebContent- Verzeichnis im Eclipse-Workspace auf den Tomcat deployed wird. Wo das zu finden ist hängt davon ab, ob der Tomcat selbst (mit dem WAR-Archiv des AutoKauf Web Service) oder das Tomcat-Plugin (mit importierten AutoKauf Web Service Projekt) zum Testen verwendet wird. Autos.xml ist also entweder in oder <TOMCAT_ROOT>\webapps\AKWS1011GXX\data <ECLIPSE_WORKSPACE>\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\ 15

17 zu finden. webapps\akws1011gxx\data 5 Implementierung der JSPs Nachdem wir in den vorhergehenden Kapiteln die Grundlagen für den Web Service Zugriff via JSP gelegt haben, machen wir uns nun daran dem ganzen etwas Funktionalität zu verleihen. In diesem Kapitel geht es also um die reine Implementierung der AutoKauf.jsp, Ergebnis.jsp, script.js und format.css. Wofür die einzelnen Dateien nötig sind wird weiter unten erläutert. 5.1 Implementierung der AutoKauf.jsp Der erste Schritt ist alle Daten (Autos) im Browser anzeigen zulassen. Sinnvoll ist dabei eine Tabellenform. Also werden wir im ersten Schritt die im letzten Kapitel erstellte AutoKauf.jsp um eine dynamische Tabelle erweitern. <body> <jsp:usebean id="proxy" scope="session" class="akws1011gxx.autokauf.autokaufproxy" /> <h1 align="center">portal - Autokauf</h1> <table> <tr class="tr_head"> <th>autoid</th> <th>autofarbe</th> <th>sitzplätze</th> <th>bereits gekauft</th> </tr> <% AKWS1011GXX.AutoKauf.Types.Auto[] autos = proxy.alleautosanzeigen(); for (int i=0; i< autos.length;i++){ %> <tr id="tr_<%= autos[i].getautoid()%>" onmouseover="mouseover(this)" onmouseout="mouseout(this)" onclick="selectauto(this)"> <td><%= autos[i].getautoid() %></td> <td><%= autos[i].getfarbe() %></td> <td><%= autos[i].getanzahlsitze() %></td> <td><%= autos[i].isgekauft()?"ja":"nein" %></td> </tr> <% %> </table> </body> Die darin enthaltenen JavaScript-Event-Handler werden wir weiter unten in einer separaten Datei script.js implementieren. 16

18 Da wir die Autos auch kaufen bzw. verkaufen wollen, müssen wir noch die entsprechende Funktionalität (Button) in die Seite integrieren. Unter die Tabelle schreiben wir also die folgenden Zeilen. <p> <form method="post" action="ergebnis.jsp"> <input type="hidden" name="method" value=""/> <input type="hidden" name="autoid" value=""/> <input type="button" name="kaufeauto" value="kaufen" onclick="sendrequest(this)"/> <input type="button" name="verkaufeauto" value="verkaufen" onclick="sendrequest(this)"/> </form> </p> Die versteckten Felder werden ebenfalls in der JavaScript-Datei gesetzt. Diese (versteckten) Felder werden beim Aufruf der Ergebnis.jsp als Parameter übergeben. Ein entsprechend abgesendeter (submit) Request sieht z.b. folgendermaßen aus Implementierung der Ergebnis.jsp Für die Auswertung erstellen wir eine Ergebnis.jsp im selben Verzeichnis wie die AutoKauf.jsp Rechtsklick auf das Projekt AKWS1011GXXJSPClient New -> Other -> Web -> JSP. Den Body füllen wir mit folgendem Code. 17

19 <body> <jsp:usebean id="proxy" scope="session" class="akws1011gxx.autokauf.autokaufproxy" /> <br/> <h1 align="center">portal - Autokauf</h1> <% String methodname = request.getparameter("method"); long autoid = (long)long.valueof(request.getparameter("autoid")); if (methodname.equals("kaufeauto")) { boolean karesponse = proxy.kaufeauto(autoid); %> <p>der Autokauf konnte <%=karesponse?"":"leider <b>nicht</b>"%> erfolgreich durchgeführt werden.</p> <% else if (methodname.equals("verkaufeauto")) { boolean vkaresponse = proxy.verkaufeauto(autoid); %> <p>der Autokaufverkauf konnte <%=vkaresponse?"":"leider nicht" %> erfolgreich durchgeführt werden.</p> <% else { %> <p>unbekannter Fehler!</p> <% %> <input type="button" value="weiter" onclick="location.href='autokauf.jsp'"> </body> Hier wird nun geprüft, welche Methode aufgerufen wurde (also im Request übergeben wurde). Entsprechend des übergebenen Methodennamens wird dann mit Hilfe des AutoKaufProxys auf den Web Service AutoKauf zugegriffen und die Methode aufgerufen. Mit dem Rückgabewert wird dann eine dynamische Bestätigung erstellt. Der Button Weiter sorgt dafür, dass die AutoKauf.jsp neu geladen wird. Der Inhalt könnte sich durch den Methodenaufruf (kaufeauto bzw. verkaufeauto) geändert haben. Spätestens an dieser Stelle möchte man sicher Testen. Zuvor muss aber noch die JavaScript- Datei erstellt und eingebunden werden. Das können wir an dieser Stelle noch nicht (bzw. nur zum Teil) tun. Erst nach dem folgenden Abschnitt ist es wirklich sinnvoll. 5.3 Implementieren der format.css Die Datei format.css sorgt dafür, dass unsere Tabelle schön aussieht ( schön ist ja Geschmackssache deshalb soll das natürlich nur ein Vorschlag sein). Mit Rechtsklick auf den Ordner WebContent New -> Folder legen wir den Ordner css und anschließend mit Rechtsklick auf den Ordner css New -> File die Datei format.css an und füllen sie mit folgendem Inhalt. 18

20 body {background-color:floralwhite; font-family:arial; color:steelblue; h1 { text-align:left; font-size:18pt; font-style:normal; font-weight:bold; border-bottom:solid thin; table {border-collapse:collapse; border-width:1px; border-style:solid; border-color:navajowhite; tr {height:30px;.tr_selected {font-weight:bold; background-color:sandybrown; color:floralwhite;.tr_hover {font-weight:bold; background-color:navajowhite; color:floralwhite; cursor:pointer; th td {text-align:center; background-color:navajowhite; border-bottom:solid thin; padding:5px; padding-top:10px; {width:150px; border-top:dashed thin; border-color:navajowhite; padding-top:5px; padding-left:5px; Zur Erinnerung: Die Bezeichner ohne Punkt (body, h1, ) sind HTML-Tag-Namen. Die Bezeichner mit Punkt sind CSS-Klassen. HTML-Tags kann mit dem class-attribut eine solche CSS-Klasse zugeordnet werden. z. B. <tr class="tr_selected"><td>...</td><td>...</td></tr> Wir werden diese CSS-Klassen im Folgenden dynamisch (mit JavaScript) den HTML-Tags zuordnen. Zuvor müssen die CSS-Dateien jedoch noch in die JSP-Dateien AutoKauf.jsp und Ergebnis.jsp eingebunden werden. Dies geschieht indem die folgende Zeile in beiden Dateien in den Header integriert wird. <head> <style type="text/css"></style>... </head> 19

21 5.4 Implementierung der script.js Die JavaScript-Datei hat folgende Aufgaben: - die Selektion einer Tabellenzeile ermöglichen - den Formular-Request absenden Zunächst erstellen wir (analog der CSS-Datei) die JavaScript-Datei script.js im Ordner js und fügen folgenden Inhalt hinzu. var selectedelement=null; function sendrequest(source) { if (selectedelement==null) { alert("bitte Eintrag selektieren!"); exit; source.form.method.value=source.name; source.form.autoid.value=selectedelement.id.substring(3); source.form.submit(); function selectauto(element){ if (selectedelement!=null) { selectedelement.classname = ""; element.classname = "tr_selected"; selectedelement = element; function mouseover(element) { if (element!=selectedelement) { element.classname = "tr_hover"; function mouseout(element) { if (element!=selectedelement) { element.classname = ""; Die Variable selectedelement speichert den DOM-Knoten der ausgewählten Tabellen- Zeile. Die Funktion sendrequest wird entweder mit dem Button kaufen oder dem Button verkaufen (-> source) des Formulars der AutoKauf.jsp aufgerufen. Die Funktion prüft, ob eine Tabellenzeile selektiert wurde, setzt die versteckten (hidden) Felder (input) und sendet das Formular ab. Die Funktion selectauto markiert die mit der Maus ausgewählte Tabellenzeile indem dieser Tabellenzeile (<tr>) die CSS-Klasse tr_selected zugewiesen wird. Außerdem wird das selectedelement mit der ausgewählten Zeile festgelegt. Wurde bereits vorher eine Zeile selektiert, wird diese zunächst freigegeben. 20

22 Die Funktionen mouseover und mouseout sind die Implementierungen der Event-Handler onmouseover und onmouseout und haben genau diese Bedeutung. Die Reihenfolge der Abarbeitung ist so: onmouseover (Betreten des Elements) onmousemove (Weiterbewegen innerhalb des Elements) onmousemove onmouseout (Verlassen des Elements) Bei mouseover wird die Tabellenzeile hervorgehoben und beim Verlassen wieder freigegeben (CSS-Klasse gelöscht). Die JavaScript-Datei muss nun noch in die JSP-Datei AutoKauf.jsp integriert werden. Dies geschieht mit dem folgenden Header-Eintrag: <head> <script type="text/javascript" src="./js/script.js"></script>... </head> 5.5 AutoKauf - Portal Die fertigen JSP-Dateien können wir uns nun im Browser ansehen. Wenn wir auf den Kaufen-Button klicken, bekommen wir das folgende Ergebnis. 21

23 Mit Weiter wird die (evtl. veränderte) AutoKauf.jsp neu geladen. Das Format (also das Aussehen) des Endergebnis kann natürlich nach belieben angepasst/abgeändert werden. 22

24 6 Erstellen des Archivs AKWS1011GXXJSPClient Bevor wir abschließend das WAR-Archiv erstellen, schauen wir uns zum Vergleich im Package-Explorer die gesamte Dateistruktur noch einmal an. Für das Endergebnis sind die JSP-Dateien add.jsp, CalWSClientAddX.jsps und das calculator-package sowie der taglibs-id.tld und die taglibs-io.jar nicht relevant. Diese Dateien sind sozusagen Überbleibsel des Tutorials. Die WebApp-Libraries müssen (bis auf die taglibs) so vorhanden sein, da sie in das Archiv eingebunden werden und das Archiv später in einer anderen Umgebung läuft. 23

25 Mit Rechtsklick auf das Projekt AKWS1011GXXJSPClient Export -> WAR file erstellen wir das entsprechende WAR-Archiv. Zum Testen des Archivs können wir Eclipse beenden, die Datei AKWS1011GXXJSPClient.war in den Tomcat-WebApps-Ordner (<TOMCAT_ROOT>\WebApps\) kopieren und Tomcat als Applikation (bzw. Dienst) starten. Achtung! Für den Test ist natürlich auch der Web Service notwendig. Wir müssen also auch die Datei AKWS1011GXX.war an diese Stelle kopieren. Die Archive werden beim Starten von Tomcat automatisch deployed. Im Browser können wir uns das Ergebnis ansehen. 24