Nach langer Zeit mal wieder ein weiterer WGA-Tip, derer es uns mitnichten mangelt (allein, die Zeit fehlt oft um sie in Textform zu giessen):

Der Tag <tml:include> ist der Haupt-Aufhängepunkt für Modularität in WebTML. Dank seiner Einbinde-Funktionalität können wir bestimmte WebTML-Bereiche in eigene Module verpacken die wir dann an den geeigneten Stellen aufrufen. Diese Module parametrisieren wir dann über WebTML-Optionen, welche das Verhalten des Modulcodes steuern, die Namen von zu verwendenden Items übergeben, Codestrecken zum Einbau übergeben usw.

Treibt man dieses Konzept konsequent fort, so wie wir das selbst in unserer internen WGA-Anwendungsentwicklung tun, so kann man schon einmal zu der Eindruck gelangen, dass über die übliche Include-Syntax sehr wenig Funktionalität über sehr viel Code angesteuert wird. So rufen wir in folgendem Beispiel lediglich ein Modul mit zwei Parametern und einem "Body" auf:

Um dieses Problem zu adressieren haben wir mit WGA 4.1 eine Reihe von Abkürzungs-Möglichkeiten eingeführt die man je nach Geschmack einsetzen kann.

Favicons, das sind diese kleinen Grafiken die im Browser zu vielen Webseiten angezeigt werden, meistens direkt vor der URL im Adressfeld. Unten z.B. das Favicon von Google:



Zugegeben, es gibt wichtigere Funktionen zu Websites. Dennoch komplettiert dieses Icon den "Gesamteindruck" einer kommerziellen Site. Oder umgekehrt: Man erwartet hier einfach inzwischen ein aussagekräftiges Logo zum Betreiber eines Webauftritts, da man es von vielen anderen Sites her bereits kennt.

Technisch handelt es sich beim Favicon um ein sehr simples Konzept: Der Browser versucht eine Ressource namens "favicon.ico" ohne sonstige Pfad vom Server zu laden. Findet er eine solche, so wird sie angezeigt.

Und hier stellt sich ein Problem für alle Sites, auf welchen WGA ohne Kontextpfad installiert ist, wo WGA also ausnahmslos alle eingehenden Anfragen des J2EE-Servers verarbeitet. Der Pfad zur favicon-Ressource entspricht keiner üblichen WGA-Ressource und kann auch nicht mit einer solchen belegt werden. Daher gibt WGA eine Fehlermeldung an den Browser zurück der daraufhin die Site ohne Icon anzeigt.

Zwar ist es auch möglich, ein Favicon per <rel>-Tag im HTML-Code einer Webseite selbst zu addressieren. Hier gibt es jedoch Unterschiede darin wie verschiedene Browser diese Daten benötigen, ausserdem ist dies nicht wirklich ein globaler Ansatz für die gesamte Site. Eine andere Möglichkeit ist es, dieses Favicon über "Rewrite"-Funktionalitäten eines vorgelagerten HTTP-Servers anzubieten, was jedoch auch nicht wirklich eine elegant zu nennen ist, insbesondere wenn ansonsten kein HTTP-Server benötigt wird.

Daher besitzt WGA seit Version 4.0.4 selbst eine dedizierte - und bislang wahrscheinlich kaum bekannte - Funktion zum Thema Favicon.

Wir haben ein simples WebTML-Formular um ein Benutzerprofil zu befüllen. Es besitzt vier Felder: Ein Textfeld, ein numerisches Feld sowie zwei Datumsfelder:

Bevor die Daten dieses Formulars irgendwo gespeichert werden möchten wir einige Bedingungen für die Daten sicherstellen:

• Wir möchten dass immer ein Name eingegeben wurde.
  
• Dasselbe wollen wir auch für die Personalnummer, die darüber hinaus natürlich numerisch sein soll
• Wir möchten naturgemäß dass ein Dienstantritts-Datum vor dem Dienstende-Datum liegt
  

Solange dies nicht erfüllt ist wollen wir die Speicherung verweigern.

Nun stellt sich die Frage der Realisierung. Natürlich können wir diese Validierungen manuell in TMLScript programmieren, und zwar bevor wir ebenfalls per TMLScript die Formulardaten speichern. WebTML-Formulare verfügen jedoch über eigene, dedizierte Validierungsfunktionen die in vielen Belangen praktischer sind als der manuelle Weg.

Mit dem Tag <tml:select> können eine Reihe von Konditionen getestet werden, von denen (in der Regel) nur der erste "Treffer" zu einer Aktion führen soll. Einzelne Konditionen und ihre zugehörigen Aktionen werden in <tml:case>-Tags definiert:

Wer <tml:case> nur ohne <tml:select> kennt wird sich hier vielleicht wundern was der Unterschied ist. Das umliegende <tml:select> sorgt dafür dass:

• Nur der erste <tml:case> ausgeführt wird dessen Kondition erfüllt ist. Weitere <tml:case>-Tags werden nicht angerührt, egal ob ihre Kondition erfüllt wäre oder nicht (es sei denn dies sei durch Attribut testall="true" explizit erwünscht)
  
• Der optionale Tag <tml:caseelse> ausgeführt wird falls keine Kondition zuvor erfüllt war.

Oftmals wird in so einem Konstrukt der Wert irgendeines Feldes überprüft und abhängig davon irgendeine spezielle Aktion ausgeführt. Ist das zu überprüfende Feld immer dasselbe so ist die ständige Wiederholung des Feldnamens und des Vergleichs-Operators nicht nur mühsam. Sie ist ebenso fehlerträchtig sowie wartungsunfreundlich. Ändert sich der zu prüfende Feldname so muss man jede einzelne Kondition anfassen.

Für diese Fälle der Verwendung von <tml:select> gibt es seit WGA 4.1eine syntaktische Vereinfachung: Das Attribut "switch":

Wer die WGA Personalisierung im "automatischen" Modus auf einer öffentlichen Website einsetzt, dem wird vielleicht aufgefallen sein dass in seiner Personalisierungsdatenbank sehr viele Benutzerprofile erzeugt werden. Sie sehen dies z.B. anhand der Anzahl der Datensätze in Tabelle "USERPROFILES" (wenn sie eine relationale Datenbank benutzen). Vielleich bemerken sie dann auch, dass die Zahl dieser Profile tatsächlich sehr viel höher als die vermutete Zahl echter Website-Benutzer ist und darüber hinaus kontinuierlich wächst.

Die Ursache für die hohe Zahl sind höchstwahrscheinlich keine echten Browser-Besuche sondern die so genannten "Bots" von Internet-Suchmaschinen die ihre Site in regelmäßigen Abständen besuchen. Diese automatisierten Prozesse rufen turnusmäßig Webseiten quer über das Internet ab und werten ihre Inhalte aus um sie in der Suchmaschinen-Datenbank zu indizieren und letztlich als Suchergebnisse anzubieten.

Anders als für normale Benutzer wird in der Regel für jeden Besuch eines Bots ein separates Benutzerprofil angelegt, das fortan nicht mehr angerührt wird und als "Datenleiche" in ihrer Personalisierungsdatenbank rumliegt. Warum ist das so und wie kann man es vermeiden?

Es gibt typische Operationen in WebTML die immer wieder benötigt werden: Testen ob Items leer oder gefüllt sind, ob Variablen definiert sind, ob sie "true" oder "false" sind. WebTML bietet für diese Operationen Tool-Funktionen an, die mehrere Vorteile gegenüber einer manuellen Programmierung bieten, und deswegen bevorzugt verwendet werden sollten:

• Sie sind "sprechender"
• Sie fassen mehrteilige Operationen komfortabel zusammen
• Sie funktionieren auf allen WGA Content Stores und unter allen WGA-Kompatibilitätseinstellungen (falls z.B..ein Design das Verhalten von WGA 3.3 benötigt)
• Sie besitzen teilweise gewisse optimierte Verhaltensweisen
  

Das Kürzel JMX steht für "Java Management Extensions". Kurz beschrieben handelt es sich bei JMX um eine in die Java-Plattform integrierte Funktionalität, mit welcher Java-Programme sowie die Java-Plattform selbst Metriken über ihre  "Gesundheit" liefern können. Diese können dann, eventuell sogar über das Netzwerk, mit geeigneten Tools ausgelesen und somit ausgewertet werden.

JMX ist für WGA-Administratoren in doppelter Hinsicht interessant:

• WGA liefert über JMX spezifische Laufzeit-Informationen, insbesondere über den Zustand der für die Verbindungen zu relationalen Datenbanken verwendeten Verbindungs-Pools
• Die Java-Laufzeit selbst gibt eine Vielzahl von Daten aus, die für die Optimierung der Performance des Systems verwendet werden können

Da zu kommt dass ein Java-Server Im Problemfall, in welchem eine Website eventuell nicht mehr reagiert, oft immernoch per JMX erreichbar ist und darüber wichtige Informationen über die Ursache des Problems liefern kann.

Im Web werden per Browser erfasste Formulardaten in der Regel über einen so genannten POST-Request zum Server geschickt. Im Unterschied zum GET-Request, über den normalerweise Webseiten angefordert werden, kann der Browser im POST-Request zusätzliche Daten an die Zieladresse des Requests schicken, so wie in diesem Fall halt der Inhalt eines Webseiten-Formulars.

Nun werden in WGA Web-Formulare normalerweise als WebTML-Formulare realisiert. Deswegen erwartet WGA bei POST-Requests, dass diese in der Regel Daten zu WebTML-Formularen enthalten. In diesem Fall stehen diese Daten dann in Form des TMLScript-Objektes "tmlform" auf dem Server zur Verfügung.

Was aber, wenn WGA einmal Formulare verarbeiten soll, welche von einer anderen Quelle stammen, z.B. von einer anderen externen Webseite mit einem normalen HTML-Formular oder von einem ganz anderen externen Programm, welches kein Browser ist?