15 WebFacing Programmiertipps
von Don Denoncourt
Als Ergänzung zum Artikel „IBM WebFacing Tool – Ein Blick hinter die Kulissen“, erschienen in NEWSolutions, Ausgabe Mai 2005, lesen Sie hier 15 Programmiertipps.Der Autor
Don Denoncourt (denoncourt@comappsspec.com) ist WebSphere Consultant der Fa. Computer Applications Specialists, Inc. und technischer Autor für NEWSolutions. Übersetzt und für den deutschsprachigen Markt überarbeitet von Joachim Riener.
1. Konfigurationseinstellungen:
Einstellungen auf Anwendungsebene, wie beispielsweise IP-Adresse und Port des Host lassen sich in der Datei WEB/web.xml direkt auf der Einsatzplattform modifizieren.
2. Performance Tuning:
Zur Optimierung der Performance können die Einstellungen diverser web.xml Kontext-Parameter (wie z.B. die Bean Cache-Größe oder ein Abschalten der Komprimierung) verändert werden.
3. Detaillierung der Fehlernachrichten:
Der web.xml Kontext-Parameter WFErrorJSPDetail erlaubt einen Wertebereich von 0 – 3. Je höher der eingetragene Wert ist, umso detaillierter sind die Fehlernachrichten in error.jsp.
4. Server-Alternativen:
Da die WebFacing-Anwendung auf J2EE basiert, kann sie auf jedem Web-Anwendungs-Server auf beliebigen Plattformen ausgeführt werden. Für den Betrieb des TCP-WebFacing 5250-Server (STRTCPSVR *WEBFACING) sowie für die Ausführung der 5250-Anwendungen wird ein iSeries Server benötigt. Da der WebFacing-TCP-Server aber über einen TCP-Port (üblicherweise Port 4004) verfügbar gemacht wird, kann der Web- Anwendungs-Server auf jeder beliebigen Plattform laufen. Ich habe beispielsweise WebFacing-Anwendungen auf Apache Tomcat implementiert, ausgeführt auf einer Intel-basierten Linux-Plattform.
5. WebFace Link:
Der Code, der hinzugefügt werden muss, um einen Link zu der Website Ihres Unternehmens zu etablieren, ist aus der JavaScript-Funktion launchApplication() in index.html zu finden.
6. Anpassung der Logon-Seite:
Um eine angepasste Logon-Seite zu definieren, öffnet man die WebFacing-Standard Logon-Seite, wählt das Anzeigen des Quellencodes im Internet Explorer aus und sichert diese Seite in die Web Content Directory des WDSc-Projektes als logon.html. Nach der Modifikation der Seite setzt man den web.xml Kontext-Parameter WFUserDefinedSignon auf „true“. Werden dabei JSP-Scriplets eingesetzt, kann die modifizierte Seite optional den Namen logon.jsp erhalten.
7. Arbeiten mit dem WebFacing Job:
der spezifische QQFINVOKER Job eines Benutzers lässt sich mit der Anweisung WRKUSRJOB ermitteln.
8. Angepasste Server-seitige Verarbeitung:
Obwohl es möglich ist, den erstellten WebFacing Java Code nachträglich zu modifizieren, ist der Einsatz eines J2EE 1.3 Servlet-Filters sicherlich die bessere Strategie. Servlet-Filter erlauben die Aktivierung einer web.xml Einstellung, die dafür sorgt, dass Servlet Requests vor dem Aufruf des eigentlichen Servlet zuerst den definierten Servlet-Filter durchlaufen.
9. Anpassung der Funktionstasten JSP:
Zur Anpassung des Erscheinungsbildes der Funktionstasten wird der web.xml Kontext-Parameter useCmdJSP auf „true“ gesetzt. Anschließend werden die gewünschten Modifikationen in der Datei CmdKeys.jsp vorgenommen, die sich bereits in dem Verzeichnis Web Content/styles/chrome in dem WDSc WebFacing-Projekt befindet.
10. Anpassung der Schaltflächen-Ereignisse:
Alle Funktionstasten-Schaltflächen sind für Aufruf von drei webface.js Routinen zur Abhandlung entsprechender Ereignisse vorbereitet. Nachdem diese IBM Funktionen ihre Verarbeitung abgeschlossen haben, können angepasste Routinen aufgerufen werden. Soll eine Schaltfläche eine besondere Funktion ausführen, müssen die folgenden Funktionen in einer angepassten JavaScript-Datei codiert werden:
bo_usr(this): behandelt das Ereignis button over oder mouse over bu_usr(this): behandelt das Ereignis button up bg_usr(this): behandelt das Ereignis button down
11. Angepasste JavaScript-Lokation:
Vermeiden Sie Modifikationen in der Datei webface.js! Diese Datei wird bei WDSc-Produkt-Upgrades überschrieben. Eigenes JavaScript sollte stattdessen in gesonderten Dateien im Verzeichnis WebContent\Client\Script\usr abgelegt werden. Das hat den Vorteil, dass WDSc solche Dateien nicht berührt und überdies das WebFacing Tool automatisch eine JavaScript-Referenz in die aus dem Satzformat generierten JSPs einbringt. Verfügen Sie über JavaScript-Definitionen, die für alle Projekte verfügbar sein sollten, legen Sie die Datei im folgenden Verzeichnis ab: x:\WDSC\WSSD\plugins\com.ibm.ettols.iseries.webfacing\ProjectTemplate\webApplication\ClientAcript\us. Wann immer Sie ein neues Projekt anlegen, wird die Datei als Teil des Projektes mit aufgenommen.
12. XML DDS Anpassung:
Die XML-Definitionen für die Satzformate der Anwendung befinden sich in der Datei DDSGeneratedData.jar in WEB-INF/lib. Um die XML-Definitionen zu modifizieren, muss der Inhalt der JAR-Datei in das Java Quellenverzeichnis des Projekts extrahiert werden. Das geschieht durch Auswahl von: File, Import, App Client Jar File im WDSc-Anwendungsfenster. Dies ist z.B. eine schnelle Möglichkeit, die Beschriftung der Funktionsschaltflächen zu ändern. Es ist empfehlenswert, nur diejenigen .xml Dateien zu extrahieren, die tatsächlich auch verändert werden sollen. Der Grund hierfür ist, dass das XML aus dem Java Quellenverzeichnis nach WEB-INF/classes verschoben wird. WEB-INF/classes wird in der Reihenfolge vor WEB-INF/lib/DDSGeneratedData.jar durchsucht. Nachfolgend durchgeführte Bildschirmumsetzungen führen zu einem Update von DDSGeneratedData.jar, verändern jedoch die Java Quelle oder WEB-INF/classes nicht.
13. Objektorientiertes JavaScript:
Die HTML-Ausführungszeit-Attribute und das Verhalten von Eingabefeldern lassen sich durch direkten Zugriff auf die wfInfoDB Object Array modifizieren. Annähernd alles, was sich in DDS definieren – und anschließend mit der Standard WebFacing-Verarbeitung behandeln – lässt, kann dynamisch in eigenen JavaScript-Routinen abgehandelt werden. Ein gutes Beispiel hierfür ist die dynamische Modifikation von zulässigen Wertebereichen, die von webface.js Routinen geprüft werden. WebFacing bietet überdies einen Pop-Up-Dialog, wenn der Cursor über das entsprechende Eingabefeld bewegt wird. Das IBM Redbook: The IBM WebFacing Tool: Converting 5250 Applications to Browser-based GUIs (SG24-6801) enthält u.a. ein Beispiel für die Definition angepasster JavaScript-Definitionen mit Verwendung der wfInfoDB Array.
14. WebFacing Logging:
Wer mehr über die internen Vorgänge erfahren möchte, die bei Ausführung der Anwendung ablaufen, kann das WebFacing Tracing einschalten. Im Verzeichnis WEB-INF/lib befinden sich folgende Dateien: WFRun.jar, WFRun_g.trace und TracingReadme.txt. Zur Aktivierung des Trace Logging muss zuerst die Datei WFRun.jar auf einen beliebigen anderen Namen abgeändert und anschließend die Datei WFRun_g.trace in WFRun.jar geändert werden. Die Datei TracingReadMe.txt enthält detaillierte Informationen über die Nutzung der Tracing-Hilfsmittel.
15. Das CAS DDSRecall Tool:
Die DDS-Definitionen lassen sich aus Display File-Objekten mit einem selbst geschriebenen Tool extrahieren, das sich der iSeries System API QDFRTVFD bedient. Ich habe ein solches Tool (mit dem Namen DDSRecall) entwickelt, das mir die Möglichkeit gibt, WebFacing für 5250-Anwendungen von Kunden durchzuführen, die nicht über den DDS-Quellencode verfügen. Für die Eigenentwicklung eines solchen Tools sollten jedoch gute Kenntnisse in C-Programmierung vorhanden sein und eine Entwicklungszeit von mehreren Monaten eingeplant werden. Computer Application Specialists, Inc. erwägt derzeit, dieses Tool kommerziell verfügbar zu machen.
Ähnliche Artikel:
